Écosystème lakehouse, formats, catalogues et moteurs

Résumé

Un lakehouse se compose de quatre briques indépendantes : un format de fichier (Parquet), un format de table (Iceberg, Delta, Hudi, Paimon), un catalogue (qui sait où est la version courante de chaque table) et un moteur de calcul. Les choisir ensemble, avec une matrice de compatibilité, évite l’essentiel des mauvaises surprises. Cette note les compare ; les concepts sont dans Data lake vs lakehouse.

Prérequis

Data lake vs lakehouse pour les notions de snapshot, de manifest et de catalogue, et Parquet, le format de fichier colonnaire pour le format de fichier.

Formats de fichier

Parquet, ORC et Avro (voir Parquet, le format de fichier colonnaire). Parquet (colonnaire, statistiques par bloc, schéma embarqué) est le défaut des lakehouses ; Avro, orienté ligne, sert plutôt à l’ingestion et au streaming. Une taille de fichier de quelques centaines de Mo est souvent visée ; c’est une valeur indicative à ajuster selon le moteur et la charge.

Formats de table

FormatPoint fortÀ surveiller
Apache IcebergSpécification ouverte, schéma par identifiant de colonne, partitionnement caché, API de catalogue REST, large support multi-moteursMaintenance (compaction, expiration) à organiser
Delta LakeProjet ouvert, très intégré à Spark et Databricks, avec des connecteurs hors Databricks (par exemple delta-rs, Trino, Flink) ; mode UniForm pour exposer des métadonnées Iceberg en lectureLe niveau de support hors Databricks varie selon la fonctionnalité
Apache HudiPensé pour l’upsert et le CDC fréquentsÉcosystème moins large côté moteurs
Apache PaimonOrienté streaming (Flink)Plus récent, support moteurs plus restreint

Quand rien ne contraint le choix, Iceberg est la valeur par défaut la mieux soutenue côté catalogues et moteurs ouverts.

Catalogues

Le catalogue répond à : où est la version courante de la table X ? Il rend le commit atomique et peut porter les permissions ; un accès direct au stockage le contourne.

CatalogueTypeRemarque
Hive MetastoreHistorique, auto-hébergéPlus lent et plus limité que les catalogues modernes
AWS GlueManagé AWSAWS uniquement
Unity CatalogDatabricksDelta et Iceberg ; expose aussi une API REST Iceberg
Apache PolarisREST Iceberg, open sourceContrôle d’accès fin, OAuth2 ; statut du projet à vérifier
LakekeeperREST Iceberg, open source, RustLicence Apache, OIDC, autorisation fine par OpenFGA
Project NessieREST IcebergSémantique de branches façon Git
Catalogue JDBCBase SQL comme point de coordinationSimple, sans API REST ni gouvernance intégrée

L’API REST d’Iceberg est devenue la voie d’interopérabilité : les moteurs parlent la même API, donc le catalogue est interchangeable. Confirmer dans la spécification en vigueur avant d’en faire un critère.

Moteurs de calcul

MoteurUsage typiqueRemarque
Apache SparkGros traitements, écritures lourdesIntégration Iceberg la plus mature
TrinoSQL interactif multi-sourcesCatalogue Iceberg configuré par connecteur
DuckDBMono-nœud, légerÉcriture Iceberg via catalogue REST, support récent
Apache FlinkStreamingÉcritures continues
ClickHouseAnalytique rapideLecture Iceberg solide, écriture plus récente et partielle
Moteurs de warehouse managésBI, simplicitéSelon l’éditeur : Choisir entre lake, lakehouse et warehouse

Interopérabilité entre formats

UniForm (Delta vers Iceberg, en lecture) et XTable génèrent les métadonnées d’un autre format sans réécrire les données. À traiter comme une passerelle de transition : deux jeux de métadonnées font deux surfaces de problème.

Notes liées