Le paysage de l'ingénierie des données a connu un changement radical. Pendant des années, les organisations étaient contraintes de choisir entre l'évolutivité et l'efficacité économique des data lakes et la performance, la gouvernance et la conformité ACID des data warehouses. L'émergence de l'architecture « Lakehouse » a effectivement démoli cette dichotomie, offrant une pile unifiée qui exploite le stockage à faible coût du stockage objet (comme S3 ou GCS) tout en fournissant la fiabilité transactionnelle d'une base de données.
Au cœur du Lakehouse moderne se trouvent les formats de tables ouverts : Apache Iceberg, Delta Lake et Apache Hudi. Ces technologies reposent sur le stockage objet et introduisent des couches de métadonnées qui gèrent l'évolution du schéma, le voyage dans le temps (time travel) et l'exécution de requêtes haute performance. Dans cet article, nous explorerons le fonctionnement de ces technologies et leur mise en œuvre.
La Trinité des Formats de Tables Ouverts
Bien que les trois formats visent à résoudre le même problème, ils ont des origines et des forces distinctes.
Delta Lake
Maintenu par Databricks, Delta Lake apporte les transactions ACID aux data lakes. Il est construit sur des fichiers Parquet et utilise un journal de transaction basé sur JSON pour suivre les modifications. Delta Lake est particulièrement performant dans l'écosystème Apache Spark et offre une excellente intégration avec les flux de travail d'apprentissage automatique (machine learning).
Apache Iceberg
Créé par Netflix et désormais un projet Apache de premier niveau, Iceberg se concentre sur l'analyse haute performance et la large compatibilité. Il sépare les métadonnées des données, permettant à plusieurs moteurs de calcul (Spark, Trino, Flink, Presto) de lire et d'écrire dans la même table sans verrouillage fournisseur (vendor lock-in). Iceberg est souvent salué pour son évolution supérieure des partitions et son isolement des instantanés (snapshot isolation).
Apache Hudi
Hoodie (Hudi), originaire d'Uber, est spécialisé dans le traitement incrémental. Il permet des opérations d'insertion-mise à jour (upserts) et de suppression à grande échelle, ce qui le rend idéal pour l'analyse en temps réel et les pipelines de capture des modifications des données (CDC). Si votre cas d'utilisation nécessite des mises à jour fréquentes des enregistrements existants, Hudi est souvent le choix supérieur.
Mise en œuvre pratique avec Spark et Delta Lake
Examinons un exemple pratique de création d'une table Delta à l'aide de PySpark. Cet exemple montre comment activer le voyage dans le temps et l'application du schéma, deux fonctionnalités critiques pour la fiabilité des données.
from pyspark.sql import SparkSession
# Initialiser la session Spark avec le support Delta Lake
spark = SparkSession.builder \
.appName("DeltaLakeExample") \
.config("spark.sql.extensions", "io.delta.sql.DeltaSparkSessionExtension") \
.config("spark.sql.catalog.spark_catalog", "org.apache.spark.sql.delta.catalog.DeltaCatalog") \
.getOrCreate()
# Écrire des données dans une table Delta avec application du schéma
data = [(1, "Alice", 30), (2, "Bob", 25)]
df = spark.createDataFrame(data, ["id", "name", "age"])
# Enregistrer au format Delta
df.write.format("delta") \
.mode("overwrite") \
.option("mergeSchema", "true") \
.save("/data/delta/lakehouse_table")
# Voyage dans le temps : Interroger les données telles qu'elles étaient il y a 1 heure
# df_historical = spark.read.format("delta").option("timestampAsOf", "1 hour ago").load("/data/delta/lakehouse_table")
Gestion des métadonnées et gouvernance
Un composant critique de toute architecture lakehouse est la gestion des métadonnées. Que vous choisissiez Iceberg ou Delta, vous devez vous assurer que votre référentiel de métadonnées est hautement disponible et sauvegardé. Ces formats s'appuient sur un fichier manifeste (dans Iceberg) ou un journal de transaction (dans Delta) pour suivre l'état des données. Si ces métadonnées sont perdues, les fichiers de données peuvent devenir illisibles ou incohérents.
De plus, l'intégration de ces formats de tables avec un catalogue unifié comme Apache Hive ou AWS Glue permet une gouvernance centralisée. Cela garantit que la découverte des données, le contrôle d'accès et le suivi de la lignée (lineage) sont cohérents sur tous les moteurs de calcul, qu'ils exécutent des requêtes SQL interactives sur Trino ou un traitement par lots sur Spark.
Conclusion
Le choix entre Iceberg, Delta Lake et Hudi dépend souvent de votre pile technologique existante et des exigences spécifiques de votre charge de travail. Cependant, la tendance vers les formats de tables ouverts est indéniable. En découplant le stockage du calcul et en introduisant des couches de métadonnées robustes, les organisations peuvent construire des plateformes de données évolutives, économiques et hautement fiables. Lors de la conception de votre prochaine architecture de données, considérez non seulement où vos données sont stockées, mais aussi comment vos couches de métadonnées gouvernent leur intégrité et leur accessibilité.