Comprendre Parquet, Iceberg et les data lakehouses
(davidgomes.com)- Les technologies de stockage de données ne forment pas un bloc monolithique : elles se répartissent en plusieurs couches distinctes, comme les formats de fichier, les formats mémoire, la couche de métadonnées de table et l’architecture lakehouse
- Avro, Parquet, ORC et Arrow sont des formats qui définissent la disposition binaire des données ; Parquet excelle dans la compression en colonnes et les traitements analytiques, tandis qu’Avro est mieux adapté aux traitements ligne par ligne
- Iceberg et Delta Lake ne sont pas des formats de fichier, mais une couche supérieure de métadonnées qui permet la gestion de tables à grande échelle au-dessus de fichiers comme Parquet
- Un data lakehouse consiste à ajouter des fonctions d’entrepôt de données comme les requêtes SQL, les traitements batch et la gouvernance au-dessus de fichiers bruts stockés dans des systèmes comme S3
- Même les entrepôts de données comme Snowflake et BigQuery prennent désormais en charge des formats ouverts comme Iceberg, ce qui brouille progressivement la frontière entre data warehouse et lakehouse
Différence entre formats de fichier et formats mémoire
- Les formats open source conçus pour optimiser le stockage et l’accès aux données diffèrent par leur mode de stockage et leur emplacement d’usage
- Apache Avro : binaire, stockage en lignes (
rowstore), fichier - Apache Parquet : binaire, stockage en colonnes (
columnstore), fichier - Apache ORC : binaire, stockage en colonnes, fichier
- Apache Arrow : binaire, stockage en colonnes, mémoire
- Protocol Buffers : langage neutre vis-à-vis des langages pour définir des structures de données, dont l’implémentation peut relever d’un stockage en lignes ou en colonnes
- CSV : format texte à la structure très simple
- Apache Avro : binaire, stockage en lignes (
- Lorsqu’on enregistre un DataFrame Apache Arrow sur disque, on utilise le plus souvent Feather, mais une conversion vers d’autres formats comme Parquet est aussi possible
- Des systèmes comme Snowflake, Redshift, Athena et Hive prennent en charge la lecture et l’écriture de formats ouverts comme de formats de stockage propriétaires, mais l’étendue du support des formats ouverts varie selon les produits
Ce que les formats définissent réellement
- Un format de fichier est une spécification qui détermine comment les données sont réellement agencées au niveau binaire
- Parquet est très performant pour la compression, tandis qu’Avro, avec son stockage en lignes, est plus adapté à la lecture de blocs de lignes spécifiques
- Parquet comme Avro prennent tous deux en charge l’évolution du schéma, ce qui permet de modifier le schéma des nouvelles données sans réécrire l’ensemble des données existantes
- Les deux formats prennent aussi en charge le découpage des fichiers, un point clé pour le traitement parallèle des données
- Le dépôt Apache Parquet inclut la spécification effective du format de fichier ainsi qu’une implémentation de référence en Java
- Parquet peut être lu et écrit depuis de nombreux langages et outils ; dans Pandas, on peut aussi enregistrer un DataFrame dans un fichier Parquet local avec
to_parquet - Presto/Trino, Spark, DuckDB, Hive, Dremio, Impala, AWS Athena et Apache Drill sont des exemples de moteurs capables de manipuler des fichiers Parquet
Pourquoi les formats de fichier seuls ne suffisent pas pour gérer des données à grande échelle
- Un format de fichier individuel ne définit que la structure d’un seul fichier ; cela ne suffit donc pas pour administrer des jeux de données volumineux et en évolution constante
- Le stockage de nombreuses tables, l’évolution de schéma table par table, les requêtes sur un état passé, le partitionnement efficace, la lecture de schémas par des outils externes et le stockage de statistiques pour l’optimisation de requêtes basée sur les coûts exigent une couche supérieure
- Cette couche comprend un format de table et un registre de schémas ou metastore
- Confluent Schema Registry prend en charge Avro et Protobuf, et convient davantage aux données de streaming, qui ont tendance à être stockées par lignes
Où se situent Hive, Iceberg et Delta Lake
- Facebook a publié Hive en 2009 avec son propre format de métadonnées de table, et Hive a ensuite évolué pour prendre en charge plusieurs formats
- Netflix a développé Iceberg pour dépasser les limites de performance et de scalabilité de Hive
- Databricks a développé Delta Lake comme alternative à Iceberg, avant de le publier en open source
- Iceberg et Delta Lake utilisent tous deux Parquet comme format de fichier sous-jacent
- Hive, Delta Lake et Iceberg prennent tous en charge un concept équivalent à un registre de schémas ou à un metastore
- Le HMS (Hive MetaStore) de Hive peut en pratique s’appuyer sur presque n’importe quel SGBDR
- Iceberg dispose des Iceberg Catalogs
- Databricks propose Unity Catalog
- Ces catalogues et metastores peuvent aussi servir à la gouvernance des données, notamment pour gérer quels utilisateurs ou quelles équipes ont accès à quelles tables
Les fonctions prises en charge par Iceberg et Delta Lake
- Delta Lake et Iceberg ne sont ni des moteurs de requête ni des moteurs de stockage en eux-mêmes, mais des spécifications ouvertes qui permettent aux moteurs de requête de fonctionner
- Les deux résolvent le même problème de manière différente, et Delta Lake fait l’objet de débats sur son ouverture en raison d’une diversité de contributeurs plus faible qu’Iceberg
- La prise en charge d’Iceberg progresse rapidement dans de nombreux data warehouses et lakehouses comme Redshift, BigQuery, Snowflake, Athena et Dremio
- Iceberg et Delta Lake fournissent les fonctionnalités nécessaires à l’exploitation de tables à grande échelle
- partitionnement
- évolution du schéma
- compression des données
- transactions ACID sur les modifications de schéma
- optimisation efficace des requêtes grâce à l’élagage des colonnes, au
predicate pushdownet à la collecte de statistiques - time travel pour interroger l’état des données à un instant donné
- Iceberg prend en charge l’évolution du partitionnement, ce qui permet de modifier la stratégie de partitionnement d’une table ou sa clé de partitionnement sans réécrire toutes les données existantes
- Chez Netflix, les changements de partitionnement constituaient une difficulté majeure, et c’est l’une des raisons qui ont conduit à la création d’Iceberg
Formats propriétaires et pression autour du support d’Iceberg
- La spécification Iceberg gagne rapidement en popularité comme format pris en charge par de nombreux systèmes
- Les produits reposant sur des formats propriétaires subissent une pression croissante : ils doivent à la fois tirer le maximum de performance de leur propre format et prendre en charge Iceberg ou Delta Lake d’une manière ou d’une autre
- Iceberg pourrait devenir une case à cocher incontournable que tous les systèmes de base de données devront un jour prendre en charge
- Pour des raisons de performance, il est possible qu’Iceberg ne remplace jamais complètement les formats de données propriétaires
- Lorsqu’un format de données est conçu pour un seul moteur de requête, les développeurs de bases de données peuvent en extraire une efficacité maximale et innover plus rapidement
Data lake et data lakehouse
- Un data lake est l’endroit où une entreprise stocke de grands volumes de données sous forme de fichiers bruts comme Parquet ou CSV
- Un data warehouse stocke les données de manière plus structurée, sous forme de tables SQL dotées d’un schéma et de schémas de base de données
- Un data lakehouse combine un data lake avec des fonctions comme l’exécution de requêtes SQL, les traitements batch et la mise en place de la gouvernance des données
- En combinant Iceberg avec un moteur de requête et d’autres composants complémentaires, on peut construire un data lakehouse au-dessus d’un data lake
- Par le passé, il fallait adopter un data warehouse ou un SGBD plus traditionnel pour disposer de ce type de fonctionnalités
- Les data lakehouses utilisent un stockage centralisé comme HDFS ou des blob stores cloud tels que S3 comme emplacement de stockage pour l’ensemble des données, puis optimisent les moteurs de requête pour fonctionner rapidement au-dessus de ce stockage
- Databricks et Dremio sont des exemples de produits de type data lakehouse
- À mesure que des entrepôts comme Snowflake et BigQuery ajoutent la prise en charge de formats de données ouverts comme Iceberg, la distinction entre data warehouse et data lakehouse devient de plus en plus floue
2 commentaires
J’étais en train de comparer Iceberg et Delta Lake, et c’est bien que ce soit résumé de façon aussi claire.
Cela correspond presque exactement à l’analyse et à l’opinion que j’avais.
Le benchmark réalisé en ligne utilisait Spark, et le Head of DevRel de Tabular a écrit que ce benchmark pouvait servir de référence, mais n’avait pas une grande signification.
S’il faut faire un choix en tant qu’open source, Iceberg semble être la seule option.
Le résumé est bon, mais ce serait encore mieux s’il y avait aussi les liens de référence.
Avis sur Hacker News
Apache Iceberg et Delta Lake sont souvent regroupés comme des formats de table ouverts (Open Table Format), mais en pratique ils semblent assez différents.
La spécification d’Iceberg se trouve sur https://iceberg.apache.org/spec/ et, pour quelqu’un qui connaît les systèmes de bases de données, elle semble permettre de créer et d’interroger des tables Iceberg sans grande difficulté.
À l’inverse, côté Delta Lake, c’est https://github.com/delta-io/delta/blob/master/PROTOCOL.md ; il est difficile ne serait-ce que d’estimer la quantité de travail nécessaire pour implémenter entièrement la spécification actuelle, et suivre cette énorme spécification en constante évolution paraît encore plus décourageant.
Franchement, la spécification Delta Lake se lit comme un document qui aurait rétro-ingéniéré les compromis d’implémentation apparus lorsque Databricks a construit rapidement des lakehouses pour des entreprises du Fortune 1000 échaudées par Hadoop.
Je ne suis toujours pas convaincu qu’adopter Delta Lake revienne vraiment à entrer dans un écosystème ouvert, et j’aimerais avoir des éléments rassurants sur ce point.
Au passage, l’historique GitHub n’est pas non plus rassurant : https://github.com/delta-io/delta/commits/master/PROTOCOL.md
On dirait que des fonctionnalités et corrections arbitraires arrivent sous forme de PR d’ingénieurs Databricks, puis sont aussitôt approuvées par un ingénieur senior de Databricks.
Mais dans ce cas, ils ne peuvent pas prétendre qu’il s’agit d’un format ouvert piloté par la communauté. À moins que ce ne soit la version façon Animal Farm où « certains sont plus égaux que d’autres ».
Pour utiliser des fonctionnalités comme les colonnes calculées ou les contraintes de vérification, il faut aussi prendre en charge les expressions Spark SQL, et leur documentation est encore plus pauvre.
C’est presque uniquement open source de nom, et je pense qu’il ne faut pas leur faire confiance.
J’ai aussi utilisé Delta Lake, et en pratique j’ai rencontré beaucoup de limites frustrantes et d’arêtes vives. Au final, nous avons complètement abandonné ce projet, et j’avais aussi étudié Iceberg à l’époque.
Iceberg et Hudi avaient des ensembles de fonctionnalités conçus de manière plus cohérente, mais bénéficiaient de moins de support ; j’espère que cela s’améliorera à l’avenir.
Ces six derniers mois, j’ai eu l’impression qu’Iceberg avait du mal à fournir des outils pour les utilisateurs hors de l’écosystème JVM, tandis que Delta prenait de l’avance. De ce point de vue, Delta est beaucoup plus accessible.
À titre de comparaison, SQL Server le fait bien mieux. Les tables en stockage orienté colonnes (columnstore indexes, l’équivalent interne à l’engine de Parquet/ORC) sont immuables, et les deltas sont stockés dans un B-Tree pour la compressibilité, l’accessibilité et la vitesse.
À un moment donné, le stockage en colonnes est défragmenté, fusionné ou reconstruit en partie ou en totalité, puis le B-Tree est supprimé et repart de zéro à mesure que de nouveaux changements s’accumulent.
Faire cela en JSON est, pour le dire gentiment, un signe d’une mauvaise époque.
N’importe quoi me semblerait préférable à Delta Lake, et Iceberg en particulier paraît meilleur.
Bon article. Je manipule depuis des années des fichiers Parquet sur S3, mais je ne savais pas exactement ce qu’était Iceberg ; l’article l’explique bien.
Iceberg est un format de métadonnées de base de données qui décrit notamment le schéma et le partitionnement du jeu de données sous-jacent.
La plupart des gens utilisent des conventions de partitionnement Hive comme
/key3=000/key2=002/, mais Iceberg va plus loin en exposant davantage de structure au moteur de requête.Dans un SGBD traditionnel comme Postgres, le schéma, le moteur de requête et le format de stockage sont fournis dans un même package.
Mais dans le big data, on peut assembler les composants de base de données à partir de zéro et les mélanger : utiliser Iceberg comme format de métadonnées, DuckDB comme moteur de requête, Parquet comme format de stockage et S3 comme support de stockage.
C’est un grand changement dans le monde des bases de données. Grâce à Delta, Iceberg et Hudi, les données sont généralement stockées dans un format open source sur S3.
Quand une grande partie du stockage et du traitement est standardisée, il devient plus facile de passer d’une base de données à une autre, et presque tous les outils finissent par pouvoir manipuler de manière transactionnellement sûre le même ensemble de fichiers.
Par exemple, pendant que Snowflake écrit dans des fichiers, un data scientist peut les interroger en temps réel dans un Jupyter notebook, et ClickHouse peut fournir des analyses destinées aux utilisateurs sur ces mêmes données tout en conservant des garanties de cohérence.
Si, plus tard, l’entreprise décide de passer de Snowflake à Databricks, ce n’est plus une si grosse affaire.
Pour l’instant, interroger ces formats sur S3 n’est pas aussi rapide qu’un chargement natif, mais la pression du marché forcera tous les fournisseurs de bases de données à optimiser les performances, qui finiront par se rapprocher de celles des données chargées nativement.
C’est une grande victoire pour l’ouverture, l’open source, et pour le fait que les entreprises possèdent leurs données dans des formats ouverts et portables.
Le lakehouse a les mêmes implications. Beaucoup d’entreprises ont à la fois un data lake et un data warehouse, et finissent par copier les données de l’un à l’autre.
N’avoir qu’un seul système pour interroger et gérer le même jeu de données a, de la même façon, un impact considérable.
C’est une période très intéressante pour travailler dans le data engineering.
À l’avenir, on peut imaginer envoyer des plans d’exécution non seulement à plusieurs moteurs répartis dans le cloud, mais aussi à des machines locales.
Pour Snowflake, il vaudrait peut-être mieux fermer boutique et rendre des dizaines de milliards de dollars aux investisseurs. Garder les données enfermées dans son écosystème, c’est tout leur modèle économique.
Je serais curieux de connaître de bons exemples de standards ouverts qui ont poussé des entreprises à abandonner des technologies propriétaires.
Je suis fortement en désaccord avec l’idée selon laquelle « la meilleure façon d’enregistrer des dataframes Apache Arrow dans un fichier disque est Feather, et on peut aussi les convertir vers Apache Parquet, etc. ».
Si l’on veut construire soi-même un lakehouse non-JVM, la meilleure configuration consiste à utiliser Iceberg comme métadonnées, Parquet comme données, DuckDB comme moteur de requête, et à interroger sous forme de tables Arrow.
Le coût de lecture directe de Parquet vers Arrow est très faible, puis on peut transmettre le résultat à Pandas ou Polars. On peut le faire directement ou via un service basé sur Arrow Flight.
Ajouter Feather là-dedans fait que toute la stack Python actuelle pour les lakehouses fonctionne mal.
Cela a peut-être changé, mais Parquet me semble toujours être le choix le plus pérenne.
J’avais déjà entendu parler de data lake, mais « data lakehouse » donne l’impression d’un endroit où les données de la haute société vont l’été faire du bateau et pêcher des données.
Beaucoup d’entreprises stockent leurs données dans un data lake et utilisent un warehouse pour fournir de la BI à des outils comme Tableau ou PowerBI. Elles finissent alors par copier les données entre les deux.
Un data lakehouse, qui interroge directement le lake tout en appliquant transactions et gouvernance à un seul jeu de données, peut énormément simplifier la stack et réduire les coûts.
Chaque fois que je l’entends ou que je le lis, ça sonne assez bizarre dans ma tête.
J’ai particulièrement de grands espoirs pour Iceberg, parce que c’est open source.
Cela dit, la dernière fois que j’ai regardé, les seules implémentations étaient des bibliothèques Spark, et le connecteur Iceberg de Trino (anciennement Presto, un moteur SQL) dépendait fortement de Hive.
J’avais l’impression que tout le secteur avait du mal à divorcer de l’héritage de MapReduce, Hive et, osons le dire, Spark.
Je n’ai pas réexaminé Iceberg depuis, mais je compte le faire bientôt, et j’espère vraiment voir ce domaine progresser.
Nous avons désormais les outils et la puissance de calcul pour traiter les données sans technologies legacy, et toutes les données ne sont pas du big data.
Heureusement, le data engineering ressemble donc de plus en plus au développement backend classique, avec des pratiques de développement ordinaires qui s’installent.
J’espère voir dans un avenir très proche une bibliothèque Iceberg pure Python.
Énormément d’efforts ont été nécessaires pour supprimer cette dépendance.
J’ai lancé Databend en une heure, et je me suis dit qu’avec une implémentation Rust, la portabilité serait meilleure qu’avec Java/Hive, ce qui le rendrait plus facile à utiliser correctement à l’avenir.
Je ne comprends pas pourquoi tout cela n’est pas expliqué plus concrètement.
J’aimerais qu’on dise comment les données sont stockées, comment on s’y connecte et comment on les interroge, ainsi que la rapidité des requêtes. Par exemple, la différence entre la vitesse des transactions et la vitesse des requêtes analytiques.
Nous traitons actuellement environ 100 To de données sur GCP, avec BigQuery comme moteur de requête, et nous utilisons un partitionnement Hive simple du type
/key3=000/key2=002/Nous pouvons exécuter toutes les requêtes que nous voulons, et les coûts sont extrêmement bas, donc nous en sommes satisfaits
En revanche, la latence augmente pas mal, même si ce n’est pas un point très critique pour nous. Je me demande quand même si l’adoption d’Iceberg améliorerait cet aspect
Je serais curieux de savoir si quelqu’un a ce genre d’expérience ; globalement, cette architecture est vraiment excellente
L’objectif principal de ce type de technologie est la gestion de données à grande échelle, mais elle étend aussi les capacités offertes par les formats de stockage bruts comme Parquet. Cela peut donc aider, mais il faut déterminer si c’est réellement nécessaire
Je n’ai pas utilisé BigQuery, mais il existe peut-être des fonctionnalités similaires
Il faut d’abord définir ce qu’on entend ici par « latence » et à quel niveau correspond « assez élevée »
Les entrepôts de données analytiques sont conçus pour un traitement par lots efficace, et la recherche d’un enregistrement unique n’est pas l’objectif principal de cette architecture. Pour des recherches rapides, il faut du caching ou de l’indexation
Dans certains cas, ajouter simplement
limit 1à une recherche sur un seul enregistrement peut suffire à résoudre le problèmeIl faut vérifier que vous utilisez un format de stockage efficace comme Parquet, puis contrôler la taille des fichiers pour voir s’il n’y a pas de « small file problem »
Ensuite, il faut aussi vérifier que vous utilisez les fonctionnalités BigQuery pertinentes. Exécutez
explainsur les requêtes avant et après ces vérifications ; si vous n’utilisez pas de clé de partition ou de colonne indexée, aucun système big data ne renverra instantanément les résultats d’une rechercheSi vous n’utilisez pas les tables BigQuery comme entrée pour des calculs à haut débit, je me concentrerais sur l’optimisation des outils BI ou sur la création de tables analytiques qui évitent la latence côté utilisateur final
Par exemple, nous avons récemment matérialisé des jointures entre tables de faits/dimensions et des opérations
COALESCEpour créer une grande table dédiée à l’analyseConceptuellement, elle se situe « en dehors » de l’architecture classique d’un data warehouse, mais comme elle existe dans dbt, nous avons pu conserver la qualité des données et le lignage
Grâce à cela, nous avons supprimé des calculs fixes Tableau et réduit d’environ 95 % les temps de chargement/regroupement pour les utilisateurs finaux
En revanche, pour des requêtes fédérées sur GCS/S3, cela peut accélérer les choses
J’aime beaucoup cette attitude : « Cet article n’est pas exhaustif à 100 %, et ce ne sera probablement pas le meilleur point de départ pour la plupart des gens. C’est parce que je l’écris pour moi-même. J’ai le sentiment que la meilleure façon d’apprendre quelque chose de nouveau est de me forcer à l’expliquer à quelqu’un d’autre »
J’ai moi aussi commencé à adopter cette approche sur papier et dans les notes de mon site web
J’avais beaucoup d’attentes quant à une plongée dans l’ère Iceberg pour des stockages Parquet plus managés
Mais la prise en charge des entrées/sorties GPU rapides (GPUDirect/cuFile) a encore plusieurs années de retard
Résultat : chaque fois que j’essaie de proposer cela à des clients pour des workloads IA, je me heurte à ce mur
Cela finira probablement par arriver ; c’est davantage une question de « quand » que de « est-ce possible ». Ce serait vraiment formidable de pouvoir avoir le meilleur des deux mondes
Pour le stockage de texte, Parquet suffit aujourd’hui
PyTorch Data Loader et TF Data fournissent des clients multithreadés qui préchargent en parallèle, remplissent des tampons mémoire, puis échangent avec le GPU
Je suis d’accord sur le fait que S3 peut devenir le goulot d’étranglement ici. C’est pourquoi nous plaçons HopsFS au-dessus de S3 comme cache NVMe cohérent, globalement distribué
Anyscale a aussi fait quelque chose de similaire avec un cache NVMe local pour S3
Un autre format de fichier intéressant est Lance : c’est un peu comme Parquet, mais pour les données d’images. Il ajoute un index d’E/S aléatoires rapides pour retrouver les images à l’intérieur du fichier