Les problèmes de la spécification Iceberg
- Problème fondamental de la spécification Iceberg : la spécification Iceberg n’est pas une tentative sérieuse de résoudre les problèmes de métadonnées des data lakes à grande échelle.
- Leçon historique : dans la première partie, l’auteur est revenu à l’histoire pour tirer les leçons du passé et a présenté le « problème de gestion de l’espace » que les bases de données doivent résoudre.
- Composantes du problème :
- fragmentation de l’espace
- contrôle de concurrence fin
- atomicité sur plusieurs objets
- inadéquation entre les lignes et les fichiers
- accès aux métadonnées à faible latence et à haut débit
- Importance des formats ouverts : l’auteur est totalement favorable à l’utilisation de formats ouverts dans toute la stack et se dit particulièrement enthousiaste à l’idée d’utiliser Parquet comme format de stockage commun pour les données tabulaires structurées.
- Différence entre les fichiers Parquet et les tables de base de données : ce n’est pas parce qu’un ensemble de fichiers Parquet est réuni qu’il devient une table de base de données. Une table de base de données est plus qu’un simple ensemble de lignes.
Résumé du problème des métadonnées
- Problème de gestion de l’espace : l’auteur réinsiste sur les multiples problèmes qu’une base de données doit résoudre.
- Nécessité des métadonnées : pour faire apparaître plusieurs fichiers Parquet comme une table de base de données, les métadonnées suivantes sont nécessaires :
- une liste des emplacements de tous les fichiers qui composent la table
- des métadonnées approximatives pour chaque fichier
- un mécanisme de contrôle transactionnel permettant d’ajouter ou de supprimer des fichiers
- un moyen de faire évoluer le schéma de la table
- Trouver l’emplacement des fichiers : pour traiter un ensemble de fichiers Parquet comme une table unique, il faut un mécanisme permettant de localiser les fichiers.
- Importance des métadonnées : chaque fichier a besoin de métadonnées supplémentaires pour trouver rapidement les lignes intéressantes.
Fichiers Parquet et tables de base de données
- Définition de Parquet : Parquet fournit un format de données tabulaires auto-descriptif.
- Définition d’une table de base de données : une table de base de données n’est pas simplement un ensemble de lignes ; elle nécessite diverses métadonnées et un contrôle transactionnel.
- Conditions pour utiliser des fichiers Parquet comme une table :
- une liste des emplacements des fichiers
- les métadonnées de chaque fichier
- un mécanisme de contrôle transactionnel pour l’ajout et la suppression de fichiers
- un moyen de faire évoluer le schéma de la table
- Différence entre fichier et table : le fait que des fichiers Parquet partagent la même disposition de colonnes ne les fait pas ressembler à une table de base de données.
Fichiers manifest et listes
- Processus d’ajout de données : pour qu’un client Iceberg ajoute des données à une table, il doit suivre les étapes suivantes :
- écrire un ou plusieurs fichiers Parquet à un emplacement donné (par exemple S3)
- écrire un fichier manifest pointant vers les fichiers créés à l’étape 1
- écrire une nouvelle liste de manifests
- Format des fichiers manifest : les fichiers manifest et les listes sont au format AVRO, compressé et auto-descriptif.
- Contenu des fichiers manifest : un fichier manifest contient des pointeurs vers les fichiers Parquet ainsi que des métadonnées pour chaque colonne.
- Problème de taille des métadonnées : stocker les métadonnées de cette manière les rend plus volumineuses que nécessaire et ne permet pas de compresser en reconnaissant les chaînes communes entre fichiers.
Une charge accrue pour les clients
- Responsabilité du client : dans toute la spécification Iceberg, le client doit effectuer une quantité énorme de tenue de registres pour des changements simples.
- Problème d’exactitude des métadonnées : si le client en écrit une partie de travers, le commit du nouveau snapshot doit être vérifié de façon exhaustive, notamment pour confirmer que les données des manifests ont été correctement écrites.
- Problème de sécurité : comme le client doit écrire une liste de manifests pointant vers tous les fichiers manifest, les emplacements de tous les fichiers S3 se retrouvent exposés.
- Importance de la sécurité des données : étant donné la valeur des données, il est légitime de se demander pourquoi la spécification ne traite pas la sécurité comme une priorité absolue.
Les failles de la sécurité au niveau des lignes
- Nécessité de la sécurité au niveau des lignes : même dans des pays à régulation relativement souple comme les États-Unis, une sécurité au niveau des lignes est nécessaire pour protéger les données sensibles.
- Le RGPD en Europe : en Europe, des lois comme le RGPD imposent une vigilance encore plus grande concernant l’accès aux données.
- Problème d’accès aux données côté client : un client peut ajouter des données à la table, mais il est impossible de restreindre son accès aux données déjà existantes.
- Gravité du problème de sécurité : le fait que la spécification ne traite pas la sécurité en priorité doit amener à s’interroger sur la valeur accordée aux informations d’un data lake.
Le rôle des fichiers de métadonnées
- Écriture des fichiers de métadonnées : après avoir écrit les fichiers Parquet, le client doit créer le fichier manifest correspondant, lire la liste de manifests existante, en générer une nouvelle, puis committer les données.
- Processus de commit : le commit s’effectue en écrivant un fichier de métadonnées (
<prefix>.metadata.json).
- Choix du format JSON : la raison pour laquelle le fichier de métadonnées est au format JSON n’est pas claire, ce qui donne une impression de « conception par comité ».
- Répétition des métadonnées : le fichier de métadonnées liste tous les snapshots, ce qui gaspille de l’espace du fait de la répétition d’informations.
La complexité du processus de commit
- Problème d’atomicité : il faut faire du nouveau fichier de métadonnées le fichier courant le plus récent et le remplacer atomiquement avec l’ancien fichier de métadonnées.
- Complexité de la procédure de commit : pour committer une nouvelle version de métadonnées V+1, il faut effectuer les étapes suivantes :
- générer un nouveau fichier de métadonnées de table à partir des métadonnées actuelles
- écrire ces nouvelles métadonnées de table dans un fichier unique
- demander au metastore de remplacer le pointeur de métadonnées de la table de V à V+1
- Gestion de l’échec du swap : si le swap échoue, cela signifie qu’un autre writer a déjà créé V+1, et le client doit repartir à l’étape 1.
- Problème de condition de concurrence : lorsque plusieurs clients sont en concurrence, il faut relire le fichier de métadonnées écrit par le client précédent et recréer la liste de manifests ainsi que le fichier de métadonnées.
Les limites du contrôle de concurrence optimiste
- Réalité de la concurrence : si l’on ne s’attend pas à une contention sur une ressource, peu importe le type de contrôle de concurrence utilisé.
- Quand la contention est attendue : si deux clients essaient de modifier la même valeur, il faut utiliser un mécanisme de verrouillage.
- Limites du contrôle de concurrence optimiste : dans Iceberg, deux écritures concurrentes entrent toujours en conflit, à cause de la façon dont la spécification est conçue.
- Pire sémantique de verrouillage : la spécification applique la pire sémantique de verrouillage aux métadonnées, alors que si l’on veut seulement ajouter des données, aucune coordination entre clients ne devrait être nécessaire.
Les limites du swap de métadonnées
- Centralisation des métadonnées : en centralisant les métadonnées de la table dans un fichier unique, Iceberg crée un point unique de contention pour toutes les écritures.
- Charge pour le client lors des retries : en cas d’échec, le client doit lire les données écrites par le client précédent et régénérer la liste de manifests ainsi que le fichier de métadonnées.
- Vitesse du swap de métadonnées : le service qui effectue le swap de métadonnées doit gérer les retries, ce qui entraîne une baisse des performances.
- Nombre limité de commits : à cause d’une implémentation de concurrence simpliste, le nombre de commits est limité par le temps nécessaire au remplacement atomique du fichier de métadonnées.
La nécessité d’une base de données
- Localiser le fichier de métadonnées : un snapshot de table Iceberg est entièrement décrit par le fichier
metadata.json.
- Contradiction de l’idée : Iceberg essaie de définir un format de métadonnées reposant uniquement sur des fichiers, mais finit malgré tout par avoir besoin d’une base de données.
- Avantages d’une base de données : les bases de données modernes peuvent traiter des centaines de milliers d’écritures et évoluer de façon distribuée.
- Comparaison entre système de fichiers et base de données : stocker les métadonnées dans une base de données est plus efficace que de les stocker dans des fichiers.
Fragmentation et gonflement des métadonnées
- Croissance du fichier metadata.json : le fichier
metadata.json pointe vers le snapshot le plus récent, et chaque fichier de métadonnées contient un pointeur inverse vers le snapshot précédent.
- Augmentation continue des métadonnées : les métadonnées continuent de grossir, ce qui nuit aux performances du data lake.
- Nécessité d’un nettoyage régulier des métadonnées : si l’on ajoute continuellement des données au data lake, il faut nettoyer les métadonnées.
- Coût des requêtes HTTP : le processus de suppression des fichiers de métadonnées entraîne des requêtes HTTP, ce qui peut générer des coûts.
Lecture des données et planification des requêtes
- Rôle des fichiers manifest : les fichiers manifest contiennent les métadonnées des fichiers Parquet.
- Complexité de la planification des requêtes : pour exécuter une requête, il faut lire séquentiellement la liste de manifests puis les fichiers manifest.
- Problème de coût : les lectures sur S3 ont un coût, ce qui affecte la vitesse d’exécution des requêtes.
- Problème de fragmentation des métadonnées : lorsque les métadonnées sont fragmentées, la planification des requêtes devient plus complexe et l’accès aux données plus difficile.
Le cache et les difficultés de planification des requêtes
- Mise en cache des manifests : il est possible de mettre les manifests en cache, mais cela reste inefficace car la taille des métadonnées continue d’augmenter.
- Maintien de la validité du cache : il faut s’assurer que le cache est à jour, ce qui entraîne des coûts et une complexité supplémentaires.
- Charge côté client : tous les clients doivent mettre les métadonnées en cache, ce qui génère des millions de requêtes HTTP.
- Complexité accrue : l’usage du data lake devient plus complexe, ce qui appelle des solutions supplémentaires pour y remédier.
Conclusion sur l’idée
- Critique de l’idée : la spécification Iceberg n’est pas une spécification sérieuse pour les métadonnées de data lake et cumule plusieurs problèmes.
- Résumé des problèmes : Iceberg ajoute les métadonnées avec des opérations en O(n), ne gère pas les commits inter-tables et ne résout pas le problème du gonflement des métadonnées.
- Limites en matière de passage à l’échelle : Iceberg n’est pas adapté au scaling et transfère une complexité excessive aux clients.
- Question posée à l’industrie : l’auteur s’interroge sur les raisons pour lesquelles ce type de problèmes apparaît dans l’industrie IT.
Aucun commentaire pour le moment.