Data Lake & Lakehouse
Le sous-service de stockage et d'ingestion sous les Fondations de données. Un lakehouse sur formats de tables ouverts avec ingestion en flux et CDC, lignage, gestion des lettres mortes et index de retrieval. Un substrat pour l'analytique, l'IA et les outils opérationnels.
Ce que c'est
Data Lake & Lakehouse est le sous-service de stockage et d'ingestion sous les Fondations de données. C'est le substrat où vivent vos tables : des fichiers Parquet sur stockage objet (S3, GCS ou Azure Blob), gérés par un format de table ouvert (Iceberg, Delta Lake ou Hudi) qui ajoute transactions ACID, évolution des schémas et voyage dans le temps tout en restant ouvert à n'importe quel moteur de calcul. C'est aussi la plomberie d'ingestion qui remplit ces tables : lots, sources en flux, CDC depuis les bases opérationnelles, et les contrats qui gardent tout cela honnête.
Pourquoi un lakehouse, pas un entrepôt ni un lac brut
Un lac brut (fichiers déposés sur stockage objet sans discipline de schéma) devient un marécage en un an. Personne ne trouve rien, les requêtes sont lentes, rien n'est cohérent. Un entrepôt traditionnel offre la correction mais vous verrouille sur un fournisseur de calcul et s'accommode mal du contenu non structuré dont l'IA a besoin. Un lakehouse garde le stockage ouvert et bon marché d'un lac et ajoute la correction d'un entrepôt par-dessus : ACID, évolution de schéma, voyage dans le temps, statistiques colonne. Les mêmes fichiers servent un outil BI, un notebook et le retrieval d'un agent, sans copies ni dérive.
Ce que nous construisons
Un format de table ouvert sur votre stockage objet, dimensionné à votre charge. Des chemins d'ingestion à la cadence des données : flux Kafka, Kinesis ou Pulsar ; CDC Debezium pour les bases opérationnelles ; lots pour les sources quotidiennes. Chaque chemin passe par des contrats d'ingestion (forme, fraîcheur, propriétaire, budget d'erreur) avec portes de qualité qui routent les enregistrements défaillants vers une table de lettres mortes. Lignage colonne. Un catalogue (Unity Catalog, Polaris, DataHub ou OpenMetadata) pour la découvrabilité. Des transformations prêtes pour le retrieval (découpage, embeddings, index hybrides BM25 + dense) à côté des tables analytiques, pour qu'une même source de vérité serve un tableau de bord et une citation.
- Format de table ouvert (Iceberg, Delta ou Hudi) sur stockage objet
- Ingestion en flux (Kafka, Kinesis, Pulsar) et CDC (Debezium)
- Contrats de source avec propriétaires nommés et SLO de fraîcheur
- Lignage colonne et ligne avec analyse d'impact
- Portes de qualité à l'ingestion avec tables de lettres mortes
- Index de retrieval hybrides (BM25 + embeddings denses)
- Catalogue et découverte (Unity Catalog, Polaris, DataHub ou OpenMetadata)
Comment il s'inscrit sous les Fondations de données
Les Fondations de données sont le parapluie : la stratégie, le graphe source, la discipline opérationnelle. Le Lakehouse est l'un de leurs deux sous-services de livraison (l'autre est la Base de connaissance prête pour les LLM). Un mandat fréquent demande les deux. Le lakehouse héberge la vérité structurée (transactions, comptes, télémétrie, événements), la base de connaissance héberge la vérité non structurée (documents, contrats, billets, conversations), et ils partagent le lignage et les contrôles d'accès définis à la couche Fondations. Pointer l'IA vers un lakehouse sans base de connaissance, ou l'inverse, est une raison fréquente d'un plafond sur ce que vos agents peuvent faire.
Où nous traçons la ligne
Pas un argumentaire fournisseur. Iceberg, Delta et Hudi conviennent à des patrons d'accès différents ; nous recommandons selon vos lectures, écritures et calcul. Les formats ouverts réduisent le verrouillage : les mêmes fichiers Parquet sont lisibles par Spark, Trino, DuckDB, Snowflake, BigQuery ou Databricks. Changer de moteur reste un travail d'adaptation, pas un changement d'une ligne. Contrats d'ingestion et portes de qualité sont une discipline continue, pas un projet qui finit.
Quand commencer
Signaux : charges analytiques éparpillées entre entrepôt, notebooks et seaux S3 ad hoc sans gouvernance ; pilotes IA qui créent chacun leurs propres pipelines faute de substrat gouverné ; sources en flux (événements, IoT, télémétrie applicative) qui ne sont pas encore citoyens de première classe ; frais d'entrepôt premium pour des données qui devraient vivre sur stockage objet. Points de départ : consolider les charges analytiques sur un lakehouse pour que retrieval et BI partagent une source de vérité, ajouter contrats d'ingestion et lignage à un pipeline d'entrepôt existant, ou exécuter une preuve de 4 semaines sur une source à haute valeur migrée de bout en bout avec contrats, portes de qualité et index de retrieval.
Lectures connexes
La carte propriétaire des systèmes opérationnels d'une organisation — schémas, documents, code, tickets, événements, propriétaires et permissions — reliés par les relations dont un agent a besoin pour retrouver, citer et agir.
Contrats, validation, lignage, fraîcheur et propriété pour des données qu'un agent peut utiliser sans risque — pas un projet de nettoyage ponctuel, mais une discipline opérationnelle continue.
Pipelines de retrieval qui combinent découpage, embeddings, filtrage par métadonnées, recherche hybride par mots-clés, reranking, permissions et évaluation — pas juste des lookups au plus proche voisin.
Une architecture qui combine l'économie du lac de données (stockage objet, formats ouverts) avec les garanties d'entrepôt (transactions ACID, évolution de schéma, voyage dans le temps) afin que l'analytique, le retrieval et l'IA convergent sur un seul substrat.
Accords explicites entre une source de données et ses consommateurs — forme, fraîcheur, propriétaire et budget d'erreur — qui rendent les pannes de pipeline attribuables au lieu de mystérieuses.