Le carburant idéal : l'évolution des formats de tableaux dans le Lakehouse
- Databricks
- Databricks
- 5 min de lecture
Tobias Vogler
Le choix de l'architecture de stockage et de métadonnées constitue le fondement le plus important, mais aussi souvent le plus sous-estimé, d'une plateforme de données moderne. Des choix inadaptés à ce stade entraînent des goulots d'étranglement au niveau des performances, des incohérences dans les données et une explosion des coûts de stockage.
Tout comme une fusée ne pardonne pas un mauvais carburant, une plateforme de données ne pardonne pas un mauvais choix de format. Ce wiki dissipe l'idée fausse selon laquelle les formats de fichiers tels qu'Apache Parquet et les formats de table tels que Delta Lake seraient des technologies concurrentes. Il raconte comment, en tant que couches symbiotiques, ils définissent le Data Lakehouse moderne – et pourquoi le choix du bon carburant est déterminant pour le succès ou l'échec de votre plateforme de données.
Table des matières
1. Résumé : La synthèse entre l'entrepôt de données et le lac de données
L'histoire de l'architecture moderne des données est marquée par un dilemme apparemment insoluble. D'un côté, il y avait l'entrepôt de données (Data Warehouse) classique. Il offrait des transactions ACID fiables (Atomicity, Consistency, Isolation, Durability – c'est-à-dire atomicité, cohérence, isolation et durabilité), une concurrence stricte (accès parallèles), la validation des schémas et des opérations performantes sur les données via le langage DML (Data Manipulation Language, comme UPDATE ou DELETE). Le prix à payer était toutefois élevé : des limites inhérentes au système propriétaire, un manque de flexibilité face aux données non structurées telles que les vidéos ou les textes libres, ainsi qu’un couplage rigide entre la puissance de calcul (Compute) et le stockage (Storage), ce qui rendait les projets de mise à l’échelle extrêmement coûteux.
D'un autre côté, le lac de données séduisait par sa liberté et sa rentabilité : un stockage cloud peu coûteux (stockage objet), une séparation stricte entre la puissance de calcul et le stockage, et la possibilité de stocker n'importe quel volume de données, structurées ou non. Cela semble prometteur. Mais sans structure organisatrice, ces lacs de données se sont rapidement transformés en marécages de données (Data Swamps) inutilisables : la sécurité des transactions, les garanties multi-utilisateurs et une gestion fiable des schémas faisaient tout simplement défaut.
La solution moderne s'appelle Data Lakehouse – et elle est en effet aussi élégante qu'elle en a l'air. Au lieu de réinventer la roue, elle s'appuie sur une couche de métadonnées intelligente (appelée « Table Format ») directement sur des formats de fichiers existants et hautement efficaces. Le résultat est révolutionnaire sur le plan architectural : pour la première fois, une plateforme allie la fiabilité, la gouvernance et la sécurité des transactions d’un entrepôt de données classique à la rentabilité, à l’ouverture et à l’évolutivité d’un lac de données. Pas de compromis – mais le meilleur des deux mondes, sur une infrastructure commune et ouverte.
2. Les réservoirs : pourquoi Parquet est le conteneur universel pour les données analytiques
Avant de pouvoir choisir le bon carburant, il nous faut le réservoir adapté. Notre parcours commence au niveau des fichiers proprement dits. Dans ce domaine, Apache Parquet s’est imposé comme la norme de facto mondiale pour les charges de travail analytiques. Parquet ne stocke pas les données relationnelles et tabulaires ligne par ligne (comme les fichiers CSV ou JSON traditionnels), mais dans des blocs de colonnes hautement compressés (stockage en colonnes).
Cette architecture physique permet au moteur de requêtes d'exploiter deux mécanismes d'optimisation fondamentaux dès l'accès en lecture :
- Élagage des colonnes (projection des colonnes) : si une requête analytique ne nécessite que 3 des 150 colonnes d'une table, le moteur ne lit physiquement que les blocs correspondant à ces 3 colonnes. Les opérations de lecture et d'écriture (E/S) restantes sont ainsi totalement supprimées.
- Predicate Pushdown (filtrage par ligne) : les fichiers Parquet contiennent, dans leurs pieds de page (footers), des valeurs statistiques minimales et maximales pour chaque bloc de données. Le moteur peut ainsi déterminer, avant même la lecture effective de fichiers entiers, si un enregistrement recherché (par exemple, ID_client = 45982) peut exister dans ce bloc. Les partitions de fichiers non pertinentes sont immédiatement ignorées.
Le défaut de conception : pourquoi les lames de parquet non traitées se déforment
Bien que le format de fichier Parquet soit extrêmement efficace, il se heurte à une limite logique lorsqu'il est utilisé isolément dans des scénarios d'entreprise. Dans la pratique, une table métier se compose de milliers de fichiers Parquet individuels. En l'absence d'une instance de niveau supérieur, cela entraîne des problèmes considérables :
Lorsqu'un processus ETL (Extract, Transform, Load) écrit de nouveaux fichiers alors qu'un analyste interroge la même table, ce dernier constate des incohérences dans les états partiels, car il n'existe aucun contrôle d'accès parallèle. De plus, chaque opération UPDATE ou DELETE nécessite la lecture, la modification et la réécriture complètes de millions de lignes dans de nouveaux fichiers, ce qui nuit considérablement aux performances.
En somme, utiliser Parquet sans couche de métadonnées revient à faire la même chose que quelqu'un qui ferait le plein de diesel par erreur : le réservoir est plein, mais le moteur ne démarre tout simplement pas.
3. Contrôle de mission : Delta Lake en tant que couche de stockage intelligente
C'est là qu'intervient Delta Lake. Delta Lake n'est pas un nouveau format de fichier, mais une couche de métadonnées ouverte qui opère directement sur les fichiers Parquet. Il fait office de « cerveau » qui redonne aux fichiers physiques la fiabilité mathématique d'une base de données relationnelle.
Au cœur de cette technologie se trouve le protocole de transaction basé sur JSON, appelé « Transaction Log » (ou « Delta Log »). Chaque commande d'écriture, de suppression ou de mise à jour est enregistrée de manière séquentielle dans ce journal sous la forme d'une entrée d'état atomique (commit). Ce n'est qu'une fois l'entrée correctement enregistrée dans le journal que la modification est considérée comme effective pour les moteurs de requête en aval.
Les principales fonctionnalités du protocole Delta en détail :
4. Le marché libre : Delta Lake, Apache Iceberg et Apache Hudi
Dans une architecture multicloud moderne, Delta Lake n'est pas seul. Il partage le marché des formats de table ouverts avec deux autres grandes initiatives open source : Apache Iceberg et Apache Hudi. Tous trois utilisent Parquet comme base physique, mais se distinguent fondamentalement par leur philosophie architecturale.
Comparaison technique des formats de tableaux :
Réorientation 2026 : le passage à Iceberg et Polaris
Comme le montrent les dernières évolutions du marché – notamment le rachat du moteur de requêtes Dremio par SAP en mai 2026 –, le privilège d'exclusivité dont bénéficiaient jusqu'à présent certains formats est en train de disparaître. Le SAP BDC (Business Data Cloud) s'ouvre nativement à Apache Iceberg et au catalogue ouvert Polaris.
Pour les architectes d'entreprise, cela signifie que les plateformes doivent être de plus en plus conçues de manière indépendante des formats. Afin d’éviter la prolifération redoutée des catalogues (Unity Catalog pour Databricks, Polaris pour SAP/Dremio/Snowflake), il est vivement recommandé de mettre en place une couche d’orchestration de catalogues de niveau supérieur (telle qu’Atlan ou Collibra) ainsi que l’encapsulation via le MCP (Model Context Protocol) pour les scénarios d’IA.
5. Conclusion et recommandations architecturales
Une combinaison judicieuse de structures de fichiers physiques et de formats de tables intelligents est le moteur qui permet à votre projet Lakehouse de rester sur la bonne voie. Elle transforme les couches de stockage non structurées en plateformes d'analyse agiles et fiables sur le plan transactionnel, prêtes à décoller.
Pour votre feuille de route architecturale, l'équipe d'experts de s-peers formule trois recommandations claires :
- Évitez les bases de données Parquet brutes : ne stockez jamais les données critiques pour votre activité sous forme de Parquet brut, sans couche de métadonnées. La charge administrative liée à la gestion manuelle des schémas et aux solutions de contournement en matière de concurrence finira inévitablement par vous rattraper.
- Préservez la dissociation : tirez parti des atouts intrinsèques de ces architectures – veillez à séparer strictement les ressources de calcul et de stockage.
- Compatibilité multiformat : concevez votre plateforme de manière à ce qu'elle puisse exploiter à la fois les structures Delta et Iceberg via des interfaces de catalogue REST ouvertes. Cela vous permettra de protéger vos investissements contre les éventuels revirements stratégiques des grands éditeurs de plateformes.
Votre architecture est unique – Discutons-en
Le choix de la couche de métadonnées appropriée et l'orchestration de vos catalogues sont déterminants pour la pérennité de vos initiatives en matière de BI et d'IA. Ensemble, nous analysons votre environnement SAP et cloud existant et mettons en place une base de données performante et à l'épreuve des pannes.
Le guide Databricks d'Andreas & Yvonne
Vous voulez toutes les informations importantes en un coup d'œil ?
Téléchargez dès maintenant le guide gratuit de SAP Databricks !
Votre stratégie de données est individuelle - votre conseil devrait l'être aussi
Le choix du format approprié et du niveau technologique adéquat dépend fortement de vos cas d'utilisation spécifiques, qu'il s'agisse de données en streaming, de traitements par lots volumineux ou de charges de travail analytiques complexes.
Discutons sans engagement de l'architecture la mieux adaptée à vos données et à vos objectifs. Veuillez nous contacter pour un entretien individuel.
