Qu'est-ce qu'un lakehouse ouvert ? Les standards de données ouverts expliqués.

Un lakehouse ouvert est un data lakehouse dans lequel chaque couche (stockage, format de table, moteur, catalogue et outils de ML et d'AI au-dessus) est construite sur des standards ouverts, de sorte qu'aucune couche n'est verrouillée par un seul fournisseur.

Un data lakehouse associe le stockage évolutif et économique d'un data lake aux fonctionnalités de gestion et aux garanties transactionnelles d'un data warehouse. Un lakehouse ouvert ajoute une condition supplémentaire : chaque couche de l'architecture est construite sur des standards ouverts. Les données, les moteurs qui les traitent, le catalogue qui les gère et les outils qui permettent de concevoir des modèles et des applications au-dessus sont tous open source, de sorte qu'aucun d'entre eux ne dépend d'un seul fournisseur.

Le terme « ouvert » est souvent galvaudé, et pas toujours de manière honnête. C'est pourquoi il est important de le définir clairement. Un format peut être qualifié d'ouvert tout en n'étant exploitable en pratique que via un seul moteur. Un catalogue peut être dit ouvert tout en restant lié à une seule plateforme. Le stockage reste portable jusqu'à ce que les frais de transfert de données (egress) rendent son déplacement coûteux. Un lakehouse ouvert est ce que vous obtenez lorsque ces contraintes sont éliminées à tous les niveaux. Plus récemment, cette même ouverture s'est étendue aux charges de travail d'AI et d'agents actuellement développées sur les données.

En quoi un lakehouse ouvert diffère-t-il d'un data lake et d'un data warehouse ?

Un lakehouse ouvert combine la fiabilité d'un data warehouse et le stockage économique d'un data lake au sein d'une même architecture, tout en ajoutant une règle qui fait défaut aux deux autres : chaque couche doit être ouverte et interchangeable. Un data warehouse contient des tables propres et structurées pour le reporting, avec une gouvernance forte, mais à un coût élevé et avec peu de place pour les données non structurées. Un data lake stocke tout le reste, comme les fichiers bruts, les journaux d'activité (logs) et les images, à moindre coût et à grande échelle, mais sans transactions, sans garanties de schéma ni réelle gouvernance.

Le lakehouse n'est pas né de nulle part. Pendant des années, les équipes ont fait coexister les deux systèmes, copiant les données de l'un à l'autre et tentant de concilier deux versions de la vérité. Le data lakehouse les a fusionnés : une gestion et des transactions de type data warehouse appliquées directement sur un stockage lake économique. Le lakehouse ouvert est la prochaine étape de cette idée. Il conserve cette architecture combinée et y ajoute la règle mentionnée ci-dessus, offrant ainsi la fiabilité d'un warehouse et les avantages économiques d'un lake, sans lier aucune couche à un fournisseur unique.

Lakehouse ouvert vs propriétaire : quelle est la différence ?

La différence entre un lakehouse ouvert et un lakehouse propriétaire se résume à une question : qui peut lire vos données et quels moteurs peuvent les exploiter. Un lakehouse propriétaire stocke les données dans des formats que seul un fournisseur spécifique peut lire, de sorte que changer d'outil peut nécessiter de réécrire ou de réexporter l'intégralité de vos données. Un lakehouse ouvert stocke les données dans des formats ouverts que n'importe quel moteur compatible peut lire, ce qui vous permet d'ajouter, de remplacer ou de supprimer un moteur de requête sans avoir à réécrire vos données.

Qu'est-ce qui rend un lakehouse ouvert ?

Trois éléments distinguent un lakehouse ouvert d'un lakehouse propriétaire : des formats ouverts, des moteurs ouverts et une gouvernance unifiée.

Tout commence par les formats ouverts. Les données résident dans des formats de table ouverts, Delta Lake et Apache Iceberg®, reposant sur des formats de fichiers ouverts comme Apache Parquet®. Les spécifications sont publiques, de sorte que tout moteur qui les implémente peut lire et écrire les données, et pas seulement l'environnement d'exécution d'un seul fournisseur.

Viennent ensuite les moteurs ouverts : les systèmes qui effectuent le traitement sont également open source. Apache Spark® prend en charge le traitement par lots (batch), le streaming, le SQL et le machine learning au sein d'un seul environnement d'exécution. De plus, comme les tables sous-jacentes sont ouvertes, des moteurs comme DuckDB, Trino ou PyIceberg peuvent exploiter les mêmes données sans nécessiter de seconde copie.

La gouvernance unifiée est l'aspect que les équipes sous-estiment souvent. Un seul catalogue gère le contrôle d'accès, le lignage (lineage) et l'audit pour chaque format et chaque moteur. Ainsi, la gouvernance est directement rattachée aux données elles-mêmes, plutôt que d'être recréée au sein de chaque outil qui les utilise. Unity Catalog joue ce rôle ici.

Associez tous ces éléments et vous obtenez un système ouvert, de la couche de stockage à la couche de service : un stockage objet sous-jacent, un format de table ouvert au-dessus, un moteur de traitement ouvert, un catalogue ouvert pour la gouvernance et des outils ouverts pour l'analytique, le machine learning et les applications d'AI en amont.

Le terme « ouvert » est-il synonyme d'open source ?

Pas tout à fait, et la différence est de taille. L'open source décrit la licence du code d'un projet. L'ouverture, au sens du lakehouse, est plus large : elle englobe des formats de fichiers et de tables ouverts, des APIs ouvertes et des méthodes standardisées de connexion pour les outils, ainsi qu'un écosystème où de nombreux moteurs collaborent sur les mêmes données. Une plateforme peut être construite à partir de projets open source tout en emprisonnant vos données, par exemple en les stockant dans une structure que seul son propre moteur parvient à lire correctement. Le véritable test d'ouverture est simple : vous devez pouvoir lire vos données avec n'importe quel outil compatible et passer d'un outil à l'autre sans avoir à les réécrire.

Format de table ouvert vs lakehouse ouvert : quelle est la différence ?

Ces deux termes sont souvent utilisés de manière interchangeable, à tort. Un format de table ouvert constitue une seule couche : il ajoute des fonctionnalités de type base de données (mises à jour fiables, modifications de schéma et historique) au-dessus des fichiers stockés dans un stockage objet. Un lakehouse ouvert englobe tout ce qui entoure cette couche : le stockage sous-jacent ainsi que le calcul (compute), le catalogue et la gouvernance au-dessus. Le format de table est un composant. Le lakehouse représente l'intégralité de la pile (stack).

Deux termes du tableau : ACID signifie que les modifications de données s'effectuent de manière fiable sans corrompre la table, et le voyage dans le temps (time travel) signifie que vous pouvez visualiser ou restaurer les données telles qu'elles apparaissaient à un moment antérieur.

Quels standards ouverts alimentent un lakehouse ouvert ?

Cette architecture de référence est construite à partir de cinq standards open source, chacun étant régi par une fondation neutre (l'Apache Software Foundation ou la Linux Foundation) et chacun gérant une couche différente de la pile. Un lakehouse ouvert n'est fiable que si les projets sur lesquels il repose le sont aussi. Et il ne s'agit pas de projets de niche : ce sont des standards sur lesquels repose déjà une grande partie de l'industrie, et la plupart d'entre eux ont été créés chez Databricks. Ce n'est pas de la fausse modestie, c'est un fait vérifiable : début 2026, Apache Spark est utilisé par environ 80 % du Fortune 500 et s'impose comme le moteur le plus largement adopté pour le traitement de données à grande échelle. MLflow dépasse les 30 millions de téléchargements par mois. Delta Lake et Apache Iceberg couvrent à eux deux la grande majorité des tables lakehouse en production, Delta Lake possédant la plus grande base installée.

Ensemble, cela représente plus de 90 000 étoiles GitHub et des dizaines de millions de téléchargements par mois. Un aperçu de la situation de chaque projet (étoiles GitHub début 2026) :

Apache Spark

Apache Spark® est le moteur de traitement. Il a été créé à l'AMPLab de l'UC Berkeley en 2009 par l'équipe qui a ensuite fondé Databricks, et a été fait don à la Apache Software Foundation, où il est devenu l'un des moteurs les plus largement utilisés pour le traitement de données à grande échelle. Un seul runtime Spark gère les traitements par lots (batch), le streaming, le SQL et le machine learning, c'est pourquoi une équipe peut exécuter un moteur unique plutôt que de maintenir un système différent pour chaque type de charge de travail. Dans le lakehouse, Spark lit les données brutes, les affine par étapes et réécrit les résultats sous forme de tables ouvertes.

Delta Lake

Delta Lake est un format de table qui permet au stockage d'objets de se comporter comme une base de données plutôt que comme un simple tas de fichiers. En plus des fichiers Parquet ordinaires, il ajoute des transactions ACID, l'application de schémas et le voyage dans le temps (time travel), de sorte que les tâches simultanées ne corrompent pas les écritures des unes et des autres, et qu'une table puisse être interrogée telle qu'elle apparaissait à un moment antérieur. Une bibliothèque complémentaire, Delta Kernel, regroupe la logique de lecture et d'écriture dans un composant indépendant du moteur, ce qui permet aux moteurs autres que Spark de prendre plus facilement en charge ce format. Delta Lake a été créé chez Databricks, qui en reste le principal contributeur, et est géré comme un projet de la Linux Foundation.

Apache Iceberg

Iceberg est un deuxième format de table, conçu pour de très grandes tables analytiques et pour migrer proprement entre les moteurs. Il est issu de Netflix plutôt que de Databricks, et est aujourd'hui un projet Apache largement adopté. Databricks en est un contributeur majeur, y compris l'équipe fondatrice d'Iceberg qui a rejoint l'entreprise lors de l'acquisition de Tabular. Sa spécification de table et son catalogue REST permettent à plusieurs moteurs de partager facilement les mêmes tables, c'est pourquoi on le retrouve partout où plusieurs moteurs de requête sont utilisés. La prise en charge de Delta Lake et d'Iceberg signifie qu'une équipe n'a pas à s'engager sur un seul format dès le premier jour et à devoir assumer ce choix indéfiniment.

Unity Catalog

Unity Catalog est la couche de gouvernance. Il centralise les politiques d'accès, la distribution d'identifiants et le lignage (lineage), et les moteurs accèdent aux données par son intermédiaire plutôt qu'en le contournant. Comme les règles résident dans le catalogue plutôt qu'au sein d'un moteur spécifique, le contrôle d'accès et le lignage restent cohérents, que la requête provienne de Spark, de DuckDB ou d'un autre client. Unity Catalog a été créé chez Databricks et est désormais un projet open source sous l'égide de la LF AI & Data Foundation, avec une version gérée disponible sur Databricks. La version open source est plus récente que le produit géré, et quelques fonctionnalités de gouvernance y sont encore en cours de finalisation ; il convient donc de vérifier si le projet open source répond à vos exigences.

Unity Catalog n'est pas le seul catalogue ouvert. Apache Polaris, Project Nessie, Hive Metastore et AWS Glue jouent le même rôle, et le catalogue REST d'Iceberg s'impose comme une interface partagée entre eux. Un lakehouse ouvert peut utiliser n'importe lequel d'entre eux. Cette architecture de référence utilise Unity Catalog car il gouverne ensemble les actifs de données, de ML et d'AI sous un modèle unique, mais la couche de catalogue est véritablement interchangeable.

MLflow

MLflow est la couche dédiée au machine learning et à l'AI. Il gère le suivi des expériences, le packaging des modèles, un registre de modèles, l'évaluation et le déploiement (serving), et ce même mécanisme s'étend désormais aux agents d'AI : tracer les actions d'un agent, évaluer ses résultats par rapport à des évaluateurs, et placer devant lui une passerelle avec des limites de budget et des garde-fous. L'exécution de modèles et d'agents sur la même plateforme ouverte qui gouverne les données, plutôt que dans une pile technologique distincte et isolée, est en grande partie ce qui différencie cette version du lakehouse. MLflow a été créé chez Databricks, qui en reste le principal contributeur, et est un projet de la Linux Foundation.

Comment les couches d'un lakehouse ouvert fonctionnent-elles ensemble ?

Les couches se connectent via des interfaces ouvertes, de sorte qu'elles s'assemblent sans dépendance propriétaire et que n'importe laquelle d'entre elles peut être remplacée sans perturber les autres. C'est ce qui transforme cinq projets en une architecture unique.

Commencez par les données. Spark écrit des tables dans le stockage d'objets sous forme de Delta Lake ou d'Iceberg. Comme ces formats sont ouverts, et parce que Delta Kernel et le catalogue REST d'Iceberg les exposent de manière neutre, d'autres moteurs lisent directement les mêmes fichiers. Rien n'a besoin d'être copié au préalable dans un stockage propriétaire, et il n'y a pas d'étape d'exportation à la sortie.

La gouvernance englobe l'ensemble. Chaque moteur accède aux données via Unity Catalog, de sorte qu'une politique écrite une seule fois est appliquée partout. Intégrer un nouveau moteur de requête consiste simplement à le pointer vers le catalogue, et non à recréer de toutes pièces des règles d'accès et un lignage.

Les modèles et les agents s'appuient sur les mêmes données gouvernées. Un modèle entraîné dans MLflow lit les tables Gold produites par Spark. Un agent répondant à une question effectue des requêtes via Unity Catalog selon les mêmes politiques qu'un analyste humain. Le lignage reliant l'entrée brute à un modèle déployé ou à la réponse d'un agent est enregistré tout au long du processus. La couche d'AI n'est pas simplement greffée à la fin ; elle lit et écrit à travers la même surface gouvernée que tout le reste.

Le gain concret réside dans l'indépendance entre les couches. Une équipe peut changer de moteur de traitement, ajouter un moteur de requête, adopter un second format de table ou remplacer un framework de modèle par un autre sans avoir à restructurer les couches supérieures ou inférieures, car chaque couche dépend uniquement de l'interface ouverte de sa voisine.

Quels sont les avantages d'un lakehouse ouvert ?

Le principal avantage d'un lakehouse ouvert est la flexibilité : les équipes gardent leurs options ouvertes à mesure que leurs besoins en données et en AI évoluent, car aucune couche n'est verrouillée par un fournisseur. Les avantages spécifiques :

• Pas de dépendance : les formats ouverts permettent aux équipes de changer d'outils sans avoir à migrer ou à réécrire les données.
• Coûts réduits : une seule copie des données dans un stockage économique évite de les dupliquer sur plusieurs systèmes.
• Multi-moteur : plusieurs moteurs peuvent s'exécuter sur les mêmes données pour la BI, le SQL et le machine learning.
• Gouvernance unifiée : un catalogue unique applique des contrôles d'accès et un lignage cohérents.
• Prêt pour l'AI : des données fiables et unifiées facilitent l'entraînement des modèles, les feature stores et les agents d'AI.
• Liberté du cloud : les charges de travail peuvent s'exécuter sur plusieurs clouds sans avoir à être recréées.

Comment un lakehouse ouvert évolue-t-il avec votre croissance ?

Un lakehouse ouvert évolue en ajoutant des couches, et non en changeant de plateforme : vous activez de nouvelles couches au fur et à mesure des besoins, et les premières couches restent en place lorsque les suivantes arrivent. La même structure convient aussi bien à une équipe de deux personnes qu'à une entreprise répartie sur plusieurs régions ; la différence réside simplement dans le nombre de couches activées.

• ETL de base. Stockage d'objets, tables Delta et Spark. Les données brutes arrivent dans la couche Bronze, sont nettoyées dans la couche Silver et sont distribuées depuis la couche Gold. Cette configuration en médaillon constitue à elle seule une pile ouverte complète.
• Streaming et batch réunis. Lorsque les données doivent être traitées à leur arrivée, Spark Structured Streaming et le Real-Time Mode exécutent le streaming aux côtés du batch sur le même moteur, avec Spark Declarative Pipelines pour décrire les transformations. Un second système de streaming n'est pas nécessaire.
• Un catalogue partagé et les premiers agents. Dès que les analystes, les applications, les tableaux de bord et le machine learning ont tous besoin des mêmes données, Unity Catalog devient la couche de gouvernance commune par laquelle ils y accèdent. C'est généralement là aussi qu'apparaissent les premiers agents, qui surveillent la qualité des données, conçoivent des pipelines et explorent le lignage, le tout gouverné via le catalogue comme pour n'importe quel autre consommateur.
• À l'échelle de l'entreprise. À travers les régions et les clouds, Unity Catalog ajoute la distribution d'identifiants, des politiques de sécurité fines, la Fédération de Lakehouse et Delta Sharing, tandis que Spark s'exécute en tant que flotte managée sur Kubernetes. Les fondations sont les mêmes ; il y a simplement plus de gouvernance et plus de ressources de calcul.

Comment l'AI s'intègre-t-elle dans un lakehouse ouvert ?

Dans un lakehouse ouvert, les applications et agents AI sont des charges de travail de premier plan, gouvernés exactement comme n'importe quel autre consommateur de données, et non un système distinct greffé après coup. La plupart des explications sur le lakehouse s'arrêtent à la business intelligence et au machine learning, ce qui ressemble aujourd'hui à un schéma de 2021 sur lequel on aurait agrafé une case AI sur le côté. Traiter les agents comme des consommateurs gouvernés des mêmes données est ce qui rend cette version réellement actuelle.

Puisque MLflow s'exécute sur la plateforme qui gouverne les données, un agent est soumis aux mêmes règles que tout le monde. Il lit à travers Unity Catalog, de sorte qu'il ne voit que ce que ses autorisations lui permettent. Son activité est tracée et ses réponses sont évaluées par des évaluateurs dans MLflow, de la même manière que la qualité d'un modèle est suivie, et la passerelle située en amont peut plafonner les dépenses et appliquer des garde-fous. Rien de tout cela ne nécessite une pile AI distincte avec sa propre copie des données et sa propre gouvernance plus faible, ce qui est l'alternative habituelle.

Concrètement :

• Attribution : un agent s'exécute sous sa propre identité, de sorte que chaque action est tracée jusqu'à un principal plutôt que d'être masquée derrière un compte partagé.
• Identifiants restreints : le catalogue distribue des identifiants temporaires et limités plutôt que des clés à longue durée de vie, de sorte que l'accès d'un agent peut être limité et révoqué comme celui de n'importe qui d'autre.
• Lignage : les lectures et écritures d'un agent sont enregistrées, de sorte que le chemin allant des données sources à la réponse, en passant par la récupération, peut être reconstitué pour un audit.
• Dépenses et garde-fous : les limites budgétaires et les contrôles de contenu résident au niveau de la passerelle, en dehors du propre code de l'agent.
• Mode de défaillance : comme l'accès passe par le catalogue, ce qui se produit lorsque le catalogue est indisponible est un choix de conception explicite, comme le refus d'accès plutôt que le recours à des lectures directes et non gouvernées.

L'identité d'un agent peut être son propre principal de service ou une délégation de l'utilisateur qui l'a invoqué (un modèle « au nom de »), et ce choix détermine la manière dont ses actions apparaissent dans le journal d'audit. De plus, le parcours autonome de MLflow décrit plus loin vous offre le traçage et l'évaluation sans lakehouse, mais le contrôle d'accès appliqué par le catalogue décrit ci-dessus ne s'applique qu'une fois Unity Catalog en place.

En pratique, c'est très concret. Un agent demande une colonne pour laquelle il n'a pas reçu d'autorisation ; Unity Catalog refuse la lecture, et le journal d'audit enregistre l'identité de l'agent, la table et la colonne demandées, l'heure et la décision de refus. Pour les requêtes autorisées, le lignage relie sa réponse aux tables Gold spécifiques qu'il lit.

Le but n'est pas que les agents remplacent le reste de l'architecture. C'est plutôt qu'ils s'y intègrent. Un agent est un consommateur de données gouvernées de plus, construit et surveillé avec les mêmes outils ouverts que les pipelines et les modèles qui l'entourent.

Avez-vous réellement besoin d'un lakehouse ouvert ?

Pas toujours : un lakehouse ouvert est le bon choix lorsque l'ouverture et l'échelle se justifient, et s'avère superflu dans le cas contraire. C'est une excellente solution lorsque vous avez de nombreux types de données, plusieurs équipes ou moteurs partageant les mêmes données, des exigences multi-cloud ou un objectif clair d'éviter la dépendance vis-à-vis d'un fournisseur. Cela peut être excessif pour une petite charge de travail mono-outil avec des données simples et structurées, sans besoin de passer d'un outil à un autre.

Une approche pratique consiste à commencer par un projet pilote à portée limitée lié à un besoin réel, par exemple en fédérant une source existante ou en déplaçant un pipeline, avant de s'engager dans une migration complète. L'architecture est conçue pour être adoptée couche par couche, le choix ne se résume donc pas à tout ou rien.

Pouvez-vous migrer vers un lakehouse ouvert de manière progressive ?

Oui. Un lakehouse ouvert est conçu pour s'intégrer à ce que vous utilisez déjà, couche par couche, plutôt que de vous demander de démanteler d'abord votre stack existante. Rares sont les équipes qui partent de zéro ; la plupart exploitent déjà un data warehouse cloud, EMR, un catalogue de données ou une migration Iceberg à moitié terminée.

• Sur un data warehouse cloud existant : fédérez-le via Unity Catalog afin que la gouvernance et le lignage l'atteignent, et laissez les données là où elles se trouvent.
• Sur EMR Spark : déplacez uniquement la couche de création de pipelines vers Spark Declarative Pipelines et conservez les clusters que vous utilisez déjà.
• Sur un catalogue distinct : faites en sorte que Unity Catalog émette des événements de lignage ouverts que votre catalogue existant ingère, afin que les deux fonctionnent côte à côte.
• À mi-chemin d'une migration vers Iceberg : placez Unity Catalog au-dessus du catalogue que vous avez déjà configuré et ne changez rien d'autre.

La démarche est la même à chaque fois : remplacez une couche par une version ouverte et ne touchez pas au reste tant qu'il n'y a pas de raison de le faire.

Qu'est-ce qui est réellement difficile avec un lakehouse ouvert ?

Un lakehouse ouvert présente de vraies difficultés, et un compte rendu honnête doit les nommer. Les formats de table ouverts accumulent de petits fichiers et nécessitent un compactage et une maintenance réguliers. L'écriture dans les mêmes tables à partir de plusieurs moteurs à la fois est encore moins mature que la lecture, de sorte que les écritures multi-moteurs nécessitent de la prudence. Les versions open source de certains composants sont en retard sur leurs versions managées pour quelques fonctionnalités. Et l'auto-hébergement de l'ensemble de la stack représente un véritable travail opérationnel. L'ouverture au niveau des couches de format et de catalogue n'efface pas non plus toutes les formes de dépendance. Les environnements d'exécution managés, les accélérateurs de requêtes propriétaires et la tarification du calcul sont les aspects par lesquels les plateformes vous lient encore, et ils méritent d'être évalués séparément des couches ouvertes. Rien de tout cela ne remet en cause l'architecture. C'est le coût honnête de la maîtrise de chaque couche.

Comment exécuter vous-même un lakehouse ouvert ?

Puisque chaque couche est open source, vous pouvez exécuter l'ensemble vous-même. Il existe une implémentation de référence ouverte qui permet de déployer toutes les couches ensemble :

Cela démarre Apache Spark, Apache Kafka®, Apache Airflow®, Apache Iceberg, Delta Lake, Unity Catalog et MLflow localement sous Docker, avec configurations pour le déploiement dans le cloud. Si tout ce dont vous avez besoin au départ est la couche AI, vous pouvez commencer avec MLflow seul : un pip install et quelques lignes dans une application existante suffisent, et vous pourrez ajouter le reste plus tard.

Par exemple, vous pouvez pointer MLflow vers un agent existant sans lakehouse sous-jacent :

Votre agent LangGraph ou OpenAI s'exécute sans modification, et ses traces, prompts et appels d'outils apparaissent dans MLflow. Votre Postgres, votre base de données vectorielle (vector store) et votre fournisseur de modèles restent là où ils sont. Vous n'ajoutez le lakehouse gouverné en dessous que lorsque vos agents ont besoin de données d'entreprise gouvernées.

Le dépôt de référence est sous licence Apache 2.0 et maintenu par l'équipe de relations développeurs de Databricks. Il ne s'agit pas d'une nouvelle technologie : ce sont les cinq projets éprouvés ci-dessus, reliés entre eux avec Docker pour les cas où vous souhaitez avoir toute la stack au même endroit. Chaque couche est également autonome ; le pack est une commodité, pas une dépendance. Exécuter soi-même un lakehouse ouvert est réaliste, mais c'est un véritable travail, et le dépôt le traite comme tel : il fournit des modèles de haute disponibilité, des configurations de déploiement et de l'observabilité afin que l'auto-hébergement soit une voie réellement prise en charge et pas seulement une promesse.

Qu'est-ce qu'un lakehouse ouvert change pour votre rôle ?

• Si vous écrivez du SQL ou du dbt : Spark Declarative Pipelines vous offre la même création déclarative et axée sur le SQL que vous connaissez avec dbt, et ajoute le streaming aux côtés du batch ainsi que du SQL et du Python complets sur un seul moteur, le tout sur des tables ouvertes gouvernées que vous pouvez toujours interroger depuis votre outil BI existant.
• Si vous construisez des pipelines de données : vous les concevez une seule fois, par exemple avec Spark Declarative Pipelines, et vous exécutez le batch et le streaming sur un seul moteur.
• Si vous construisez des modèles ou des agents : vous les construisez, les évaluez et les servez dans MLflow par rapport aux mêmes données gouvernées, selon les mêmes règles d'accès que tout le monde.
• Si vous gérez la plateforme : vous ajoutez des couches à mesure que l'entreprise grandit, et vous pouvez remplacer n'importe laquelle d'entre elles sans devoir re-plateformer le reste.

Quelles plateformes prennent en charge les lakehouses ouverts ?

Plusieurs plateformes implémentent désormais les principes du lakehouse ouvert. Databricks, Snowflake, Google Cloud, Microsoft Fabric, Cloudera, Dremio, Starburst et Qlik proposent tous des produits dans ce domaine. Il s'agit de produits basés sur les concepts du lakehouse ouvert, et non de l'architecture elle-même, et ils diffèrent par le niveau d'ouverture réel de chaque couche.

Databricks a créé la catégorie du lakehouse et offre des performances de niveau data warehouse sur une base ouverte, en utilisant Delta Lake et Apache Iceberg pour le stockage et Unity Catalog pour la gouvernance. La plateforme Databricks propose cela sous forme de service géré pour les équipes qui préfèrent ne pas gérer la pile elles-mêmes.

Foire aux questions

Un lakehouse ouvert est-il identique à un data lakehouse ?

Un data lakehouse est l'architecture : une gestion de style data warehouse sur un stockage de type lake. Un lakehouse ouvert est un data lakehouse dans lequel chaque couche (stockage, format de table, moteur, catalogue, ainsi que les outils ML et AI situés au-dessus) est open source et interchangeable, de sorte qu'aucune couche ne dépend d'un seul fournisseur.

Iceberg ou Delta Lake : lequel dois-je utiliser ?

Les deux sont des formats de table ouverts avec des transactions ACID, l'évolution des schémas et le voyage dans le temps, et un lakehouse ouvert peut utiliser l'un ou l'autre, ou les deux. Delta Lake s'associe étroitement avec Spark et, via Delta Kernel, est de plus en plus lisible par d'autres moteurs ; Iceberg est conçu pour un large accès multi-moteur via son catalogue REST. Prendre en charge les deux signifie que le choix n'a pas à être fait dès le départ.

Ai-je besoin des cinq projets pour avoir un lakehouse ouvert ?

Non. L'architecture est conçue pour évoluer. Un lakehouse ouvert de base se compose simplement d'un stockage d'objets, d'un format de table et de Spark. Unity Catalog et MLflow sont ajoutés lorsque la gouvernance pour de nombreux consommateurs, ainsi que les charges de travail de machine learning ou d'AI, entrent en jeu.

Puis-je exécuter un lakehouse ouvert sans Databricks ?

Oui. Chaque couche est open source et s'exécute sur votre propre infrastructure. L'implémentation de référence démarre l'ensemble de la pile localement avec Docker, et la couche de machine learning peut être utilisée seule avec une simple commande pip install. Databricks propose des versions gérées de ces composants ouverts, mais l'auto-hébergement est une option prise en charge.

Où se situent les agents d'AI dans un lakehouse ouvert ?

Les agents sont traités comme des consommateurs de données gouvernés, et non comme un système distinct. Ils lisent via Unity Catalog selon les mêmes politiques que les utilisateurs et les autres moteurs, et ils sont créés, suivis et évalués dans MLflow aux côtés des modèles, ce qui maintient la couche d'AI au sein de la même architecture ouverte et gouvernée plutôt que de l'ajouter après coup.

Combien coûte un lakehouse ouvert ?

Les composants open source sont gratuits sous les licences Apache 2.0 et Linux Foundation ; vos coûts résident dans le stockage d'objets, le calcul que vous exécutez et l'effort opérationnel pour maintenir la pile. Le gérer vous-même permet d'échanger les coûts de licence contre du temps d'ingénierie, tandis qu'une plateforme gérée comme Databricks échange le temps d'ingénierie contre un abonnement, sur cette même base ouverte.

Un lakehouse ouvert est-il prêt pour la production ?

Oui. Les cinq projets clés sont des standards matures déjà déployés en production à grande échelle, par exemple Apache Spark dans environ 80 % du Fortune 500 et MLflow avec plus de 30 millions de téléchargements par mois. Les principales considérations de production sont opérationnelles : la maintenance et le compactage des tables, la prudence avec les écritures multi-moteurs et le travail d'auto-hébergement si vous n'utilisez pas de service géré.

Apache, Apache Spark, Apache Iceberg, Apache Kafka, Apache Airflow, Apache Parquet et le logo Apache feather sont soit des marques déposées, soit des marques commerciales de l'Apache Software Foundation aux États-Unis et/ou dans d'autres pays. Delta Lake, MLflow et Unity Catalog sont des marques commerciales de LF Projects, LLC. Toutes les autres marques appartiennent à leurs propriétaires respectifs.

Pour voir l'ensemble fonctionner, clonez l'architecture de référence et exécutez-la de bout en bout sur github.com/open-lakehouse/open-lakehouse. Si vous commencez du côté de l'AI, MLflow seul est un bon point d'entrée, et le reste de la pile est là lorsque vos modèles et agents ont besoin de données gouvernées. Vous préférez une approche entièrement gérée ? Cette même base ouverte alimente la plateforme lakehouse Databricks.

Explorer l'architecture de référence

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original