Comprendre Parquet, Iceberg et le data lakehouse de BroadIn

Comprendre : Parquet, Iceberg et le data lakehouse de BroadIn

• Méthodes de stockage des données (fichiers et en mémoire)

  • Il existe divers formats de fichiers pour accéder aux données et les stocker
  • Certains systèmes utilisent principalement des formats de données fermés, mais la plupart prennent en charge des formats de données ouverts
  • Parmi les principaux formats de fichiers open source figurent Apache Avro, Parquet, ORC, Arrow, Feather, Protobuf, etc.
  • Ces formats fournissent des spécifications sur la manière d’organiser les données dans leur disposition binaire réelle
  • Parquet prend bien en charge la compression, tandis qu’Avro est adapté à la lecture de blocs de lignes spécifiques
  • Ils prennent en charge l’évolution du schéma et le partitionnement des fichiers, essentiels au traitement parallèle
  • Il est possible de travailler avec ces formats dans divers langages de programmation et outils

• Gestion des données à grande échelle — Iceberg et Delta Lake

  • Il faut un moyen de stocker différentes tables, de faire évoluer chaque schéma individuellement, de partitionner efficacement les données et de permettre aux outils externes de lire facilement le schéma
  • Hive, Iceberg et Delta Lake prennent tous en charge un registre de schémas ou un metastore
  • Iceberg et Delta Lake utilisent Parquet comme format de fichier individuel
  • Iceberg et Delta Lake ne sont ni des moteurs de requête ni des moteurs de stockage, mais des spécifications ouvertes qui permettent aux moteurs de requête d’effectuer le travail
  • Ils rendent possibles l’évolution du partitionnement, l’évolution du schéma, la compression des données, les transactions ACID, l’optimisation efficace des requêtes, le time travel, etc.

• Qu’est-ce qu’un data lake et un data lakehouse ?

  • Un data lake est l’endroit où les entreprises stockent de grandes quantités de données dans des formats bruts tels que des fichiers OCR, Parquet ou CSV
  • Un data lakehouse est une combinaison de fonctionnalités au-dessus d’un data lake, permettant d’exécuter des requêtes SQL, de configurer des traitements batch, de mettre en place la gouvernance des données, etc.
  • Le data lakehouse peut être considéré comme une version de l’entrepôt de données ouvert
  • À mesure que des entrepôts de données comme Snowflake et BigQuery prennent en charge des formats de données ouverts comme Iceberg, la frontière entre entrepôt de données et data lakehouse devient floue

L’avis de GN⁺

• Iceberg et Delta Lake jouent un rôle important comme couche de métadonnées pour gérer des jeux de données à grande échelle. Ils permettent une gestion efficace des données et l’optimisation des requêtes, ce qui les rend utiles aux data scientists et aux ingénieurs.
• Le data lakehouse combine les avantages du data lake et de l’entrepôt de données, en proposant un nouveau paradigme pour la gestion et l’analyse des données. Cela peut offrir de nouvelles possibilités pour renforcer la prise de décision fondée sur les données.
• À mesure que la prise en charge d’Iceberg progresse, les systèmes de gestion et d’analyse des données devraient se standardiser davantage et devenir plus interopérables. Cela apportera plus de flexibilité et d’efficacité dans le choix et l’utilisation des plateformes de données.

[happing94]

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.

[GN⁺]

Commentaires Hacker News

• Apache Iceberg et Delta Lake sont souvent présentés comme des formats de table ouverts, mais il existe en réalité des différences.

  • La spécification du format de table Apache Iceberg est suffisamment claire pour qu’une personne familière des systèmes de bases de données puisse construire et interroger des tables Iceberg sans grande difficulté.
  • À l’inverse, avec la spécification de Delta Lake, il est difficile d’évaluer l’effort nécessaire pour implémenter entièrement la spécification actuelle ou la maintenir à jour dans le temps.
  • La spécification de Delta Lake donne l’impression d’avoir été rétroconçue à partir de la manière dont Databricks a choisi en interne de construire un lakehouse pour des entreprises du Fortune 1000 déçues par Hadoop.
  • Je ne suis pas convaincu que Delta Lake ait une vraie valeur en tant qu’écosystème réellement ouvert.

• Dans l’univers des bases de données, le fait que Delta, Iceberg et Hudi stockent les données sur un stockage comme S3 dans des formats open source représente un changement majeur.

  • Cela signifie qu’une grande partie du stockage et du traitement est standardisée, ce qui facilite le passage d’une base de données à une autre, et permet à la plupart des outils de travailler sur le même ensemble de fichiers de manière transactionnellement sûre.
  • Par exemple, pendant que Snowflake écrit dans les fichiers, un data scientist peut interroger les données en temps réel dans un notebook Jupyter, et ClickHouse peut fournir des analyses orientées utilisateur sur ces mêmes données.
  • Si une entreprise décide de passer de Snowflake à Databricks, cela ne pose pas de gros problème.
  • Aujourd’hui, interroger ces formats sur S3 n’est pas encore aussi rapide qu’une ingestion native, mais la pression du marché poussera tous les éditeurs de bases de données à optimiser les performances.
  • C’est une grande victoire pour l’open source et l’ouverture, car cela permet aux entreprises de posséder leurs données dans des formats ouverts et portables.
  • Les lakehouses ont un impact similaire. Beaucoup d’entreprises ont à la fois un data lake et un data warehouse, et doivent copier les données entre les deux systèmes. Pouvoir interroger le même jeu de données et ne gérer qu’un seul système est tout aussi important.

• Je travaille avec des fichiers Parquet sur S3 depuis des années, sans avoir vraiment compris ce qu’était Iceberg. Mais cet article l’explique bien.

  • Iceberg est un format de métadonnées de base de données pour un jeu de données sous-jacent, qui décrit le schéma, le partitionnement, etc.
  • Dans un DBMS traditionnel, le schéma, le moteur de requête et le format de stockage sont livrés comme un ensemble intégré.
  • Mais dans le big data, on peut construire les composants de la base de données à partir de zéro, puis les combiner librement. On peut 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.

• La meilleure façon de stocker un dataframe Apache Arrow sous forme de fichier sur disque est d’utiliser Feather, mais on peut aussi le convertir au format Apache Parquet.

  • Si l’on veut construire son propre lakehouse non JVM, on peut utiliser Iceberg pour les métadonnées, Parquet pour les données, interroger avec DuckDB à partir de tables Arrow, puis traiter les données via Arrow->Pandas ou Polars.
  • Si on mélange Feather au reste, la stack actuelle du lakehouse Python ne fonctionne pas.

• J’avais déjà entendu parler des data lakes, mais « data lakehouse » donne l’impression d’un endroit où les données de la haute société partent à la pêche en data boat pendant l’été.

• Je gère environ 100 To de données sur GCP, avec BigQuery comme moteur de requête et un partitionnement Hive simple. Je suis satisfait de pouvoir exécuter toutes mes requêtes à très bas coût, mais la latence est devenue assez élevée, même si ce n’est pas un gros problème pour l’entreprise.

  • Je me demande si implémenter Iceberg pourrait améliorer cela. Quelqu’un a-t-il déjà essayé ?

• Iceberg m’enthousiasme beaucoup, mais la dernière fois que j’ai regardé, seules les bibliothèques Spark constituaient une implémentation, et le connecteur Iceberg de Trino dépendait fortement de Hive.

  • L’ensemble de l’industrie semble avoir du mal à divorcer des technologies héritées comme MapReduce, Hive et Spark.
  • Je compte me repencher sur Iceberg et j’espère que ce domaine va progresser. Aujourd’hui, nous avons les outils et la puissance de calcul nécessaires pour traiter des données sans technologies legacy, et toutes les données ne relèvent pas du big data.
  • Au final, le « data engineering » ressemble de plus en plus à du développement backend classique, avec l’application de pratiques de développement standard.
  • J’espère vraiment voir arriver très bientôt une bibliothèque Iceberg en Python pur.

• Je me demande pourquoi personne n’explique tout cela avec des idées plus concrètes. Il faudrait expliquer comment les données sont stockées, comment on s’y connecte et les interroge, ainsi que la vitesse des requêtes, par rapport à la vitesse transactionnelle et à la vitesse « analytique ».

• Dans tous les benchmarks que j’ai vus en ligne, le format Delta Lake semble offrir des performances nettement meilleures qu’Iceberg.

  • Je me demande si cela tient à quelque chose de fondamental dans la spécification, ou si Iceberg a une chance de combler l’écart.

• Je reconnais que ce billet de blog ne sera ni 100 % exhaustif ni le meilleur point de départ pour la plupart des gens.

  • J’aime l’idée que la meilleure manière d’apprendre quelque chose de nouveau est de le réexpliquer à d’autres, et j’ai moi-même commencé à appliquer cela dans les notes de mon site web.