Data Lake vs Cloud Data Warehouse : un guide pratique pour les data scientists

Un data lake est un référentiel centralisé qui stocke les données brutes dans leur format d'origine — structurées, semi-structurées et non structurées — à l'aide d'un stockage d'objets cloud à faible coût. Contrairement à un cloud data warehouse, qui impose un schéma prédéfini avant le chargement des données, un data lake applique une structure uniquement au moment de la lecture, ce qui offre aux data scientists et aux data engineers une flexibilité maximale pour travailler avec divers types de données sans transformation préalable. Les deux architectures reposent sur une infrastructure cloud, mais elles répondent à des questions fondamentalement différentes sur la manière de collecter, de traiter et de récupérer les données à grande échelle.

Ce guide est conçu pour les data scientists, les data engineers et les responsables analytiques qui ont besoin d'un cadre de décision pratique, et non d'un discours commercial. À la fin de votre lecture, vous comprendrez les différences clés entre un data lake et un cloud data warehouse, le moment où un data lakehouse comble l'écart, et comment choisir la bonne architecture de stockage de données pour vos charges de travail spécifiques.

Recommandations en un coup d'œil

Avant de plonger dans les détails techniques, voici les conseils pratiques dont la plupart des équipes ont besoin d'entrée de jeu.

Choisissez un data lake lorsque votre besoin principal est de stocker des données brutes multi-formats à l'échelle du pétaoctet pour le machine learning, la data science ou de futurs cas d'usage analytiques qui n'ont pas encore été définis. Les data lakes offrent une évolutivité à un coût par gigaoctet inférieur à celui des cloud data warehouses et prennent en charge tous les types de données sans nécessiter de schéma avant l'ingestion.

Choisissez un cloud data warehouse lorsque votre charge de travail se concentre sur des requêtes SQL rapides et simultanées sur des données d'entreprise structurées — tableaux de bord, rapports financiers, relevés de compte client et analyses opérationnelles, où une faible latence des requêtes et une forte simultanéité importent plus que la flexibilité du stockage.

Choisissez un data lakehouse lorsque votre organisation exécute à la fois des charges de travail de machine learning et de business intelligence, et a besoin d'une plateforme unifiée qui élimine la duplication des données entre un lake et un warehouse. Les lakehouses prennent en charge les transactions ACID directement sur le stockage du lake, ce qui en fait le choix par défaut pratique pour la plupart des plateformes de données modernes.

Qu'est-ce qu'un data lake ?

Un data lake est un référentiel centralisé conçu pour stocker toutes vos données — structurées, semi-structurées et non structurées — dans leur format brut d'origine jusqu'à ce qu'elles soient nécessaires pour l'analyse. Les data lakes sont apparus spécifiquement pour répondre à l'explosion des besoins de stockage de données non structurées que les bases de données relationnelles traditionnelles et les data warehouses ne pouvaient pas prendre en charge de manière économique.

La caractéristique principale d'un data lake est qu'il accepte immédiatement les données en utilisant la méthodologie Extract, Load, Transform (ELT), en appliquant un schéma à la lecture plutôt qu'un schéma à l'écriture. Cela signifie que les data engineers peuvent ingérer des fichiers journaux, des événements JSON, des images, des vidéos, des flux de capteurs et des tables de base de données dans le même système sans avoir à définir au préalable comment ces données seront interrogées. Les data scientists bénéficient d'un accès direct aux données brutes et non traitées, quel que soit leur format d'arrivée, ce qui est essentiel pour le feature engineering et le développement de modèles de machine learning.

Les cloud data lakes fonctionnent généralement sur des services de stockage d'objets — Amazon S3, Azure Data Lake Storage (ADLS) et Google Cloud Storage — qui offrent une capacité pratiquement illimitée. Les data lakes peuvent stocker des pétaoctets d'informations sans limites fixes, et le coût par gigaoctet est nettement inférieur à celui du stockage propriétaire utilisé par les data warehouses existants. Cette évolutivité à un coût par gigaoctet inférieur fait des data lakes le choix pratique pour le stockage de big data lorsque le volume est la préoccupation principale.

Les data lakes prennent en charge tous les types de données — les exports de bases de données structurées, les formats semi-structurés comme JSON et Parquet, et les contenus totalement non structurés comme les corpus de textes, l'audio et les images. Cette polyvalence en fait la zone de destination naturelle pour toute organisation qui doit conserver des données brutes pour des analyses futures, y compris pour des cas d'usage qui n'ont pas encore été définis au moment de l'ingestion.

Cloud Data Warehouses et contexte des bases de données relationnelles

Un cloud data warehouse est une base de données analytique gérée, optimisée pour les requêtes SQL à forte simultanéité sur des données structurées et prêtes pour l'entreprise. Contrairement à une base de données relationnelle conçue pour des charges de travail transactionnelles — insertion et mise à jour de lignes individuelles en temps réel — un cloud data warehouse est conçu pour des charges de travail analytiques qui parcourent de grands volumes de données historiques pour produire des agrégats, des rapports et des tableaux de bord.

Les cloud data warehouses imposent un modèle de schéma à l'écriture : les données doivent être nettoyées, typées et conformes à un schéma prédéfini avant de pouvoir être chargées. Cette contrainte est à l'origine de la plus grande force du warehouse, mais aussi de sa limite la plus importante. Comme chaque ligne de chaque table est conforme à une structure connue, le stockage colonnaire et les techniques d'accélération des requêtes (predicate pushdown, zone maps, mise en cache des résultats) peuvent être appliqués de manière agressive — offrant ainsi les performances de requête inférieures à la seconde que les utilisateurs métier et les data analysts attendent des tableaux de bord.

Les principaux fournisseurs de cloud data warehouses — notamment Amazon Redshift, Google BigQuery, Snowflake et Databricks Lakehouse — ont séparé le calcul du stockage, ce qui signifie que la capacité de requête peut évoluer indépendamment des données stockées. Cette architecture prend en charge les charges de travail à forte simultanéité où des centaines d'utilisateurs exécutent des requêtes simultanées sans conflit. Pour les cas d'usage de business intelligence — rapports sur les revenus, relevés de compte client, analyse des stocks — le cloud data warehouse reste le choix dominant car les performances des requêtes et la cohérence des données sont non négociables.

Là où les cloud data warehouses rencontrent des difficultés, c'est avec les types de données qui ne correspondent pas à un modèle relationnel : texte non structuré, flux de capteurs bruts, embeddings d'images et journaux d'événements semi-structurés. Le chargement de ces données dans un warehouse nécessite un travail de transformation important et conduit souvent à l'exclusion ou à l'approximation de données pour les adapter à un schéma, ce qui nuit à l'exhaustivité requise par les charges de travail de machine learning.

Architecture de data lake et solutions de stockage

L'architecture de data lake est généralement organisée en trois zones, chacune représentant un niveau de qualité des données et de préparation à l'usage métier de plus en plus élevé.

Zone brute (couche Bronze)

La zone brute est la zone de destination initiale pour les données ingérées à partir de systèmes sources externes. Les données arrivent dans leur format d'origine — exports de bases de données, réponses d'API, événements de streaming, fichiers plats — et sont écrites dans le stockage d'objets avec un minimum de transformation. L'objectif est la fidélité : préserver l'enregistrement d'origine afin que l'ensemble du pipeline puisse être rejoué depuis le début si la logique en aval change. Des métadonnées, des horodatages de chargement et des identifiants de source sont ajoutés, mais les données elles-mêmes ne sont pas modifiées.

Zone nettoyée (couche Silver)

Dans la zone nettoyée, les données brutes sont rapprochées, fusionnées et conformées pour obtenir une vue d'entreprise unifiée. Des contrôles de qualité des données sont appliqués, les doublons sont résolus et les données provenant de plusieurs sources sont jointes pour former des entités cohérentes — clients, transactions, produits. Cette couche prend en charge l'analyse exploratoire, les rapports ad hoc et l'expérimentation en data science sans exposer de données brutes et non traitées aux consommateurs en aval.

Zone préparée (couche Gold)

La zone préparée contient des agrégats de niveau métier et prêts pour la production, prêts à être consommés par des tableaux de bord, des analyses opérationnelles et des modèles de machine learning. Les données de cette couche ont franchi toutes les étapes de contrôle qualité et sont organisées dans des structures prêtes à la consommation — schémas en étoile, tables larges, métriques pré-agrégées — qui prennent en charge des requêtes hautes performances. L'architecture médaillon, qui formalise les niveaux Bronze, Silver et Gold en tant qu'étapes de pipeline distinctes, est le modèle le plus largement adopté pour organiser l'architecture de data lake.

Le stockage d'objets est le fondement de ces trois zones. Des formats comme Apache Parquet et Apache ORC offrent un encodage colonnaire qui réduit l'empreinte de stockage et accélère les analyses analytiques. Les formats ouverts dissocient les données du moteur de traitement d'un fournisseur unique, ce qui permet d'interroger les mêmes fichiers à l'aide de plusieurs outils sans avoir à les copier.

Coûts de stockage des données et évolutivité

Les comparaisons de coûts entre les data lakes et les cloud data warehouses doivent prendre en compte séparément le stockage et le calcul, car les architectures modernes dissocient les deux.

Le stockage de data lake sur des niveaux de stockage d'objets cloud est nettement moins cher que le stockage propriétaire de warehouse — souvent d'un ordre de grandeur sur le prix brut par gigaoctet. Pour les organisations qui stockent d'importants volumes de données brutes ou historiques peu fréquemment interrogées, les niveaux de stockage à froid (Amazon S3 Glacier, Azure Archive) réduisent encore les coûts, bien qu'avec une latence de récupération plus élevée. Les data lakes sont plus rentables que les data warehouses précisément parce que le stockage d'objets a été conçu pour la durabilité et l'évolutivité, et non pour les performances des requêtes.

Les cloud data warehouses appliquent une tarification par requête ou par unité de calcul, ce qui les rend rentables pour les charges de travail régulières et à forte valeur ajoutée, mais coûteux pour les requêtes ad hoc ou exploratoires sur de grands ensembles de données. Les modèles de tarification à l'usage sur les cloud data warehouses modernes sont utiles — vous payez pour les requêtes exécutées plutôt que pour une taille de cluster fixe — mais le coût par téraoctet de données traitées reste nettement supérieur à celui du stockage sur lake.

L'implication pratique est que les décisions relatives à l'architecture de stockage des données sont rarement des choix binaires. De nombreuses organisations stockent toutes leurs données dans un lac pour des raisons d'efficacité économique, puis déplacent de manière sélective les ensembles de données préparés vers un entrepôt pour la BI à haute simultanéité. Le coût de duplication lié à la conservation de deux copies — une dans le lac, une dans l'entrepôt — est le principal moteur de l'adoption du lakehouse.

Machine learning et analytique avancée pour les data scientists

Les lacs de données ont été conçus pour le machine learning. La capacité de stocker des données brutes dans leur format natif signifie que les data scientists peuvent accéder à l'intégralité des données historiques — et non à un sous-ensemble pré-agrégé ou limité par un schéma — ce qui est essentiel pour entraîner des modèles de haute qualité.

L'ingénierie des caractéristiques (feature engineering) pour le machine learning nécessite des transformations itératives et exploratoires sur divers types de données. Un data scientist qui entraîne un modèle de détection des fraudes a besoin de journaux de transactions bruts, de données d'empreinte numérique des appareils, de séquences comportementales et de l'historique des comptes — dont la majeure partie ne s'intègre pas facilement dans un schéma relationnel. Les lacs de données garantissent la cohérence fondamentale des données entre diverses applications tout en préservant le format brut requis par les pipelines ML.

Les lacs de données s'intègrent nativement aux outils de data science et d'analytique avancée. Apache Spark, la norme de fait pour le ML distribué à grande échelle, lit directement depuis le stockage d'objets en utilisant des formats ouverts. Les bibliothèques Python utilisées pour l'entraînement des modèles — PyTorch, TensorFlow, scikit-learn — accèdent au stockage du lac via les mêmes API compatibles S3. Les ingénieurs de données peuvent exécuter des pipelines de données en streaming qui alimentent les modèles en caractéristiques en temps réel sans déplacer les données vers un système distinct.

Les entrepôts de données cloud contribuent aux flux de travail ML principalement lors de la phase d'inférence et de scoring. Une fois qu'un modèle est entraîné, le scoring opérationnel sur des tables d'entrepôt structurées — comme l'exécution d'une prédiction d'attrition (churn) sur une table client ou le scoring de prospects dans un export CRM — bénéficie de l'indexation et de l'optimisation des requêtes de l'entrepôt. Une architecture ML mature place le magasin de caractéristiques (feature store) à la frontière : le calcul des caractéristiques brutes se fait dans le lac, tandis que les tables de caractéristiques prêtes pour le service sont matérialisées dans un format accessible à la fois à l'entrepôt et à la couche de service du modèle.

Charges de travail d'analyse de données et de BI

Les charges de travail de business intelligence — tableaux de bord, rapports planifiés, requêtes ad hoc par des analystes commerciaux — ont des exigences qui diffèrent fondamentalement du machine learning. Les utilisateurs de BI ont besoin de réponses à faible latence (moins d'une seconde pour le chargement des tableaux de bord), de résultats cohérents pour les utilisateurs simultanés et de données qui reflètent les définitions métier convenues, et non des valeurs sources brutes.

Les entrepôts de données cloud sont conçus spécifiquement pour répondre à ces exigences. Le stockage colonnaire, la mise en cache des résultats et les vues matérialisées garantissent que les requêtes courantes des tableaux de bord s'exécutent en quelques millisecondes, même lorsque le volume de données augmente. Un contrôle d'accès précis permet aux analystes de données d'interroger les données de leur département sans exposer les enregistrements sensibles d'autres unités commerciales. Les utilisateurs professionnels peuvent exécuter du SQL directement sur des tables structurées sans avoir à comprendre les options de stockage de données sous-jacentes ou les formats de fichiers.

Les lacs de données peuvent prendre en charge les charges de travail de BI via des moteurs de requête SQL — Apache Hive, Presto, Trino, Spark SQL — mais ils offraient traditionnellement des performances de requête inférieures à celles des entrepôts spécialisés. La flexibilité du schéma à la lecture (schema-on-read) s'accompagne d'un surcoût de planification des requêtes qui devient évident en cas de forte simultanéité. Pour les tableaux de bord en temps réel et la business intelligence à haute simultanéité, un entrepôt de données cloud ou un lakehouse doté d'une couche SQL haute performance est le choix approprié.

La diffusion de données en continu (streaming) pour les tableaux de bord en temps réel est de plus en plus courante : relevés de capteurs, parcours de navigation sur les sites web, événements de paiement. Les lacs de données et les entrepôts de données cloud prennent tous deux en charge l'intégration en streaming via des connecteurs vers Kafka, Kinesis et des systèmes similaires, mais la prise en charge par le lac de pipelines de données en streaming sans contraintes de schéma en fait la zone de réception la plus naturelle pour les flux d'événements à grande vitesse et à schéma variable.

Différences clés : Lac de données vs entrepôt de données cloud

La comparaison suivante couvre les dimensions qui comptent le plus dans les décisions d'architecture.

Modèle de schéma

Les lacs de données utilisent le schéma à la lecture (schema-on-read) : la structure est appliquée lorsque les données sont interrogées, et non lorsqu'elles sont écrites. Tout type de données peut être intégré immédiatement sans conception préalable. Les entrepôts de données cloud nécessitent un schéma à l'écriture (schema-on-write) : les données doivent être conformes à une structure prédéfinie avant le chargement, ce qui garantit la qualité des données mais ralentit l'intégration et limite la flexibilité. Cette distinction explique la plupart des autres différences ci-dessous.

Performance des requêtes

Les entrepôts de données cloud offrent des performances de requête supérieures pour les charges de travail structurées basées sur SQL, en particulier en cas de forte simultanéité. Des moteurs colonnaires spécialisés, une mise en cache intelligente et des optimisations de compilation des requêtes produisent des réponses en moins d'une seconde pour les modèles de BI courants. Les moteurs de requête de lacs de données traditionnels sont plus lents pour le SQL simultané, mais se sont considérablement améliorés grâce aux moteurs vectorisés modernes. Les lacs de données restent plus rapides pour le traitement par lots à grande échelle et les charges de travail d'entraînement ML, pour lesquels les coûts de calcul en entrepôt seraient prohibitifs.

Maturité de la gouvernance et de la préparation des données

Les entrepôts de données cloud disposent d'une gouvernance intégrée plus mature : les contrôles d'accès au niveau des tables et des colonnes, les journaux d'audit, le suivi de la lignée des données (data lineage) et les types de données imposés sont des fonctionnalités standard. Les lacs de données traditionnels nécessitent des outils supplémentaires — catalogues de données, couches de gestion des métadonnées, systèmes externes de contrôle d'accès — pour atteindre une maturité de gouvernance équivalente. L'écart s'est considérablement réduit avec des services de catalogue comme Unity Catalog, mais les entrepôts conservent un avantage pour les organisations ayant des exigences de conformité strictes.

Coût par téraoctet

Les lacs de données stockent les données à un coût par téraoctet nettement inférieur à celui des entrepôts de données cloud — souvent 10 à 100 fois moins cher selon le niveau de stockage et la fréquence des requêtes. Pour les volumes de données importants, les données historiques et l'intégration brute, l'avantage de coût du lac est décisif. Pour les données métier préparées et fréquemment interrogées, les performances de l'entrepôt justifient son coût plus élevé.

Types et formats de données pris en charge

Les lacs de données prennent en charge tous les types de données : exports relationnels structurés, JSON et XML semi-structurés, texte non structuré, images, audio et fichiers binaires. Les entrepôts sont optimisés pour les données structurées stockées dans des tables de base de données et offrent un support natif limité ou inexistant pour les données non structurées et semi-structurées. Le stockage de données diverses — des fichiers journaux aux côtés de transactions financières et de métadonnées d'images — est un cas d'usage typique du lac.

Profils d'utilisateurs principaux

Les ingénieurs de données et les data scientists sont les principaux utilisateurs des environnements de lac de données : ils ont besoin d'un accès brut à toutes les données dans leur format natif pour le développement de pipelines et l'entraînement de modèles. Les analystes de données et les utilisateurs professionnels sont les principaux consommateurs des entrepôts de données cloud : ils ont besoin de données propres, fiables et rapides à charger pour les requêtes SQL et les rapports. Les lakehouses de données répondent aux besoins de ces deux profils à partir d'une plateforme unique, ce qui explique principalement leur adoption rapide.

Les lakehouses de données : le pont entre lacs et entrepôts

Un lakehouse de données est une architecture de plateforme de données qui combine le stockage flexible et économique d'un lac de données avec les capacités de gestion des données et les performances de requête d'un entrepôt de données — sur un système unique et unifié. Le lakehouse élimine le coût opérationnel le plus élevé de l'architecture à deux systèmes : la maintenance d'une copie distincte des données préparées dans l'entrepôt.

La couche de stockage transactionnelle est l'innovation clé. Les formats de table ouverts — Delta Lake, Apache Iceberg et Apache Hudi — ajoutent la prise en charge des transactions ACID directement au stockage d'objets. Les transactions ACID garantissent que chaque opération d'écriture réussit complètement ou est entièrement annulée, évitant ainsi la corruption des données due à des écritures simultanées. Cette garantie, que les entrepôts de données fournissent depuis des décennies, n'était historiquement pas disponible dans les lacs de données. Les lakehouses fournissent une prise en charge des transactions ACID pour la fiabilité des données tout en conservant le format ouvert et la structure de coûts du lac.

Delta Lake est le format de table de lakehouse le plus largement adopté. Il stocke les données dans des fichiers Parquet sur le stockage d'objets cloud et conserve un journal des transactions qui enregistre chaque modification de schéma, insertion, mise à jour et suppression. La fonctionnalité Time Travel — interrogeable depuis SQL — permet aux data scientists et aux auditeurs de lire n'importe quel instantané historique d'une table. La compression automatique des fichiers et les index d'omission de données (data skipping) accélèrent les performances des requêtes sans réglage manuel. Delta Lake est une technologie couramment utilisée dans les architectures de lakehouse car elle est open source, indépendante du cloud et s'intègre nativement avec Apache Spark et les moteurs SQL.

Apache Iceberg et Apache Hudi offrent des capacités similaires avec des compromis de conception différents. Iceberg propose une évolution de schéma plus robuste et un partitionnement masqué pour les charges de travail analytiques complexes. Hudi se spécialise dans les mises à jour/insertions (upserts) au niveau des enregistrements et les modèles d'intégration en streaming. Ces trois formats sont de plus en plus interopérables grâce à des normes ouvertes comme Apache XTable.

D'ici 2025, les lakehouses représenteront plus de la moitié des charges de travail analytiques des entreprises — portés par la simplicité opérationnelle de la gestion d'une seule plateforme plutôt que par la synchronisation d'un lac et d'un entrepôt. Pour les organisations qui construisent une nouvelle plateforme de données, le lakehouse est le choix par défaut le plus pratique.

Modèles d'intégration avec les bases de données relationnelles et les magasins de données (data marts)

Comprendre où se situent le lac de données et l'entrepôt de données cloud par rapport aux autres systèmes permet de clarifier quand utiliser l'un ou l'autre.

Les bases de données relationnelles de type Online Transaction Processing (OLTP) — MySQL, PostgreSQL, Oracle — restent le système de référence pour les applications opérationnelles. Elles sont optimisées pour les charges de travail transactionnelles gourmandes en écriture : gestion des commandes, suivi des stocks, authentification des utilisateurs. Les charges de travail analytiques ne doivent pas être exécutées directement sur les bases de données OLTP, car la charge des requêtes entre en concurrence avec les transactions de l'application. Le modèle standard consiste à répliquer les données OLTP dans le lake ou le warehouse via le Change Data Capture (CDC), une technique qui diffuse les modifications au niveau des lignes de la base de données source sous forme d'événements, sans impact sur les performances opérationnelles.

Les data marts sont des sous-ensembles thématiques d'un data warehouse ou d'un lake plus vaste, organisés pour une fonction métier particulière — finance, marketing, chaîne d'approvisionnement. Ils fournissent des ensembles de données préparés et pré-joints que les analystes métier peuvent interroger sans avoir à comprendre l'intégralité du modèle de données de l'entreprise. Les data marts restent pertinents dans les organisations où différents départements ont des exigences de gouvernance divergentes ou lorsque l'isolation des requêtes est nécessaire pour les performances. Dans une architecture lakehouse, les tables de la couche Gold remplissent efficacement la fonction de data mart sans nécessiter de système physique distinct.

ETL (Extract, Transform, Load) est le modèle approprié pour le chargement dans les systèmes de schéma à l'écriture (schema-on-write) : les transformations sont appliquées avant que les données n'entrent dans le warehouse, garantissant ainsi la conformité avec le schéma de destination. ELT (Extract, Load, Transform) est le modèle approprié pour les systèmes de schéma à la lecture (schema-on-read) : les données brutes arrivent d'abord dans le lake, puis les transformations sont appliquées au moment de la requête ou lors des étapes du pipeline. La plupart des plateformes de données modernes utilisent l'ELT pour l'ingestion dans le lake, puis appliquent une préparation de style ETL pour générer les tables de la couche Gold.

Sécurité, gouvernance et conformité

La gouvernance des données dans un cloud data lake nécessite un investissement explicite que les systèmes de warehouse fournissent par défaut.

Le contrôle d'accès au niveau des fichiers — qui empêche les utilisateurs non autorisés de lire les données brutes dans le stockage d'objets — est l'exigence fondamentale. Les fournisseurs cloud proposent des politiques d'accès au niveau des buckets et des préfixes, mais les contrôles précis au niveau des colonnes et des lignes nécessitent une couche de gouvernance supplémentaire. Unity Catalog, la plateforme de gouvernance unifiée de Databricks, fournit des politiques de sécurité au niveau des tables, des colonnes et des lignes sur l'ensemble des tables du lake et du warehouse à partir d'une interface unique, en utilisant la syntaxe SQL DCL standard que les administrateurs de bases de données connaissent déjà.

Le catalogue de données et la gestion des métadonnées constituent la deuxième couche de gouvernance. Un catalogue permet de savoir quelles tables existent, quels sont leurs schémas, à qui elles appartiennent et comment elles ont été produites — c'est le lignage des données (data lineage) de la source à la consommation. Sans catalogue, les data lakes deviennent des marécages de données (data swamps) : des dépôts où les données s'accumulent sans documentation et où les ingénieurs passent plus de temps à chercher les données qu'à les analyser. Le lignage automatisé — qui suit le parcours de transformation depuis l'ingestion Bronze jusqu'aux agrégats Gold, en passant par les jointures Silver — est essentiel pour déboguer les pipelines, valider la conformité et comprendre l'impact des modifications de schéma.

Le chiffrement est requis pour toutes les données au repos et en transit. Le stockage d'objets cloud chiffre par défaut les données au repos à l'aide du chiffrement côté serveur, et le transport est toujours chiffré via TLS. Les organisations ayant des exigences plus strictes gèrent leurs propres clés de chiffrement à l'aide de clés gérées par le client (CMK) via des services de gestion de clés cloud, garantissant ainsi que même le fournisseur cloud ne peut pas déchiffrer les données sans autorisation explicite.

Cadre de décision pour la migration et l'architecture

Choisir entre un data lake, un cloud data warehouse et un data lakehouse nécessite de faire correspondre les capacités architecturales aux exigences des charges de travail.

Commencez par une évaluation de l'adéquation des charges de travail. Répertoriez vos charges de travail analytiques par utilisateur principal (data scientists, analystes, utilisateurs métier), types de données requis (structurées, semi-structurées, non structurées), modèles de requête (batch, interactif, streaming) et exigences de latence (secondes, minutes, heures). Les charges de travail dominées par les rapports SQL structurés correspondent aux warehouses. Les charges de travail nécessitant des types de données divers, l'entraînement de modèles de ML ou une flexibilité future correspondent aux lakes. Les charges de travail mixtes correspondent aux lakehouses.

Évaluez le coût en parallèle des performances. Un data warehouse existant peut offrir des performances acceptable pour les charges de travail actuelles, mais calculez le coût total, y compris le stockage des données brutes hébergées ailleurs, les coûts de duplication des données et la charge d'ingénierie liée à la maintenance des pipelines de synchronisation. Pour la plupart des organisations qui stockent plus de quelques téraoctets de données brutes, l'avantage du coût de stockage du lake s'accentue considérablement avec le temps.

Évaluez honnêtement les compétences de votre équipe. Les cloud data warehouses disposent d'outils plus accessibles pour les équipes d'analyse axées sur le SQL. Les data lakes nécessitent un investissement d'ingénierie plus important dans le développement de pipelines, la gestion des catalogues et les outils de gouvernance. Les lakehouses réduisent cet écart, mais nécessitent toujours des connaissances en Spark ou en traitement distribué équivalent pour les charges de travail à grande échelle.

Pour les organisations qui migrent depuis un data warehouse traditionnel, une approche progressive est la plus efficace. Lors de la phase pilote, identifiez une seule charge de travail à forte valeur ajoutée — un cas d'usage ML spécifique ou un type de données que le warehouse existant gère mal — et intégrez-la dans le lake ou le lakehouse. Mesurez les coûts réels, les performances et les résultats en matière de gouvernance par rapport au système existant avant de procéder à un déploiement plus large. Cela permet d'éviter l'échec classique d'une migration de type « big bang » qui perturbe les analyses en production avant que la nouvelle architecture ne soit validée.

Choisir entre data lake, warehouse et lakehouse

Le cadre de décision se résume à trois parcours basés sur le type de charge de travail principal.

Si votre charge de travail est dominée par le machine learning, l'expérimentation en science des données ou le stockage de volumes importants de données brutes ou non structurées, commencez par un data lake. L'efficacité des coûts et la flexibilité des formats sont des avantages décisifs, et vous pourrez ajouter une couche de requête SQL plus tard, à mesure que vos besoins en matière de reporting évoluent.

Si votre charge de travail est dominée par des analyses SQL structurées, des tableaux de bord à forte simultanéité et des rapports d'activité avec des exigences de latence strictes, et que vos données sont déjà structurées à la source, un cloud data warehouse offre le meilleur rapport performance-prix pour ce cas d'usage spécifique.

Si votre organisation exécute ces deux types de charges de travail — ou prévoit de le faire dans les 12 à 18 mois — optez dès le départ pour une architecture lakehouse. Le coût de la migration ultérieure d'une architecture mature à deux systèmes vers un lakehouse unifié est nettement plus élevé que celui d'une construction initiale sur des bases unifiées.

Dans tous les cas, validez vos hypothèses à l'aide d'un projet pilote avant de vous engager dans une migration complète. Définissez des indicateurs de réussite mesurables avant le début du pilote : latence des requêtes à P95, coût par téraoctet et par mois, délai entre l'ingestion brute et les données prêtes pour l'analyse, et ratio entre la maintenance des pipelines et le développement de nouvelles fonctionnalités. Ces indicateurs fournissent une base objective pour les décisions d'architecture qui, autrement, donneraient lieu à des débats internes.

FAQ et idées reçues

Un data lake remplace-t-il un cloud data warehouse dans tous les cas ?

Un data lake ne remplace pas un cloud data warehouse dans tous les cas. Les data lakes excellent dans le stockage de données brutes multi-formats à faible coût et dans la prise en charge des charges de travail de machine learning, mais les data lakes traditionnels offrent des performances de requête plus lentes pour les charges de travail SQL à forte simultanéité que les warehouses conçus à cet effet. Les organisations ayant des exigences de business intelligence matures bénéficient d'un cloud data warehouse ou d'un lakehouse — une architecture unifiée qui offre des performances de requête de niveau warehouse directement sur le stockage du lake.

En quoi un data lake diffère-t-il d'une base de données relationnelle traditionnelle ?

Un data lake stocke des données brutes dans leur format natif sur un stockage d'objets sans schéma prédéfini, tandis qu'une base de données relationnelle impose un schéma fixe, stocke des données structurées dans des tables de base de données et est optimisée pour les charges de travail transactionnelles — insertion et mise à jour d'enregistrements individuels. Les data lakes sont conçus pour les charges de travail analytiques et de machine learning à l'échelle du pétaoctet ; les bases de données relationnelles sont conçues pour les applications opérationnelles nécessitant des transactions ACID à faible latence sur des lignes individuelles.

Quelle est la différence entre un data lake et un data lakehouse ?

Un data lake stocke des données brutes dans un stockage d'objets sans garanties transactionnelles, ce qui rend complexes les écritures simultanées et l'évolution des schémas. Un data lakehouse ajoute une couche de format de table ouvert — comme Delta Lake, Apache Iceberg ou Apache Hudi — qui fournit un support pour les transactions ACID, l'application des schémas et le contrôle de la qualité des données directement sur le stockage du lake. Les lakehouses offrent à la fois la flexibilité et l'efficacité des coûts d'un lake, ainsi que la fiabilité et les performances de requête d'un warehouse, sans nécessiter de duplication des données.

Quand dois-je utiliser un data mart plutôt qu'un data lake ou un warehouse ?

Utilisez un data mart lorsqu'une fonction métier spécifique — finance, marketing, opérations de vente — nécessite un ensemble de données préparé et pré-joint, optimisé pour les modèles de requête de cette fonction, et lorsque l'isolation de cet ensemble de données de la plateforme de données plus large de l'entreprise est nécessaire pour des raisons de gouvernance ou de performance. Dans une architecture lakehouse, les tables de la couche Gold remplissent efficacement la fonction de data mart, réduisant ainsi le besoin de data marts physiques distincts et la complexité de synchronisation associée.

Qu'est-ce qui transforme un data lake en « marécage de données » (data swamp) et comment l'éviter ?

Un data lake devient un data swamp lorsque les données s'accumulent sans gestion adéquate des métadonnées, sans contrôle de la qualité des données ou sans gouvernance des accès, ce qui empêche les utilisateurs de trouver, de faire confiance ou d'accéder aux données dont ils ont besoin. La prévention nécessite trois contrôles : un catalogue de données qui documente les schémas de table, la propriété et le lignage ; des contrôles de qualité des données appliqués à chaque étape du pipeline (Bronze, Silver, Gold) ; et des contrôles d'accès qui empêchent les écritures non autorisées de polluer les ensembles de données nettoyés. L'architecture médaillon impose une progression de la qualité qui maintient les données brutes isolées des tables de niveau production.

Annexe : Modèles techniques et outils

Exemples d'architectures de traitement par lots (batch) et en continu (streaming). Un modèle d'ingestion par lots standard charge quotidiennement les exportations du système source dans le stockage du lac Bronze, applique des transformations de nettoyage au niveau Silver et matérialise les agrégats Gold pour la consommation BI. Un modèle de streaming utilise Apache Kafka ou des services de streaming d'événements cloud pour acheminer les événements vers le niveau Bronze en quasi-temps réel, avec des mises à jour incrémentielles Silver et Gold gérées par des frameworks de tables de streaming. Les deux modèles s'exécutent sur le même stockage de lac, Delta Lake gérant l'isolation des transactions entre les deux modes d'ingestion.

Outils populaires par couche. Pour l'ingestion : Lakeflow, Apache Kafka, services CDC natifs du cloud. Pour la transformation : Apache Spark (PySpark, Spark SQL), dbt (pour les équipes axées sur SQL). Pour l'orchestration : Apache Airflow, services de workflow natifs du cloud. Pour l'analyse SQL : Databricks Lakehouse, BigQuery, Snowflake, Amazon Redshift. Pour la gouvernance : Unity Catalog, Apache Atlas, services de catalogue natifs du cloud. Pour le ML : MLflow, Apache Spark MLlib, services d'entraînement de modèles natifs du cloud.

Modèles de conception de schéma. Pour les tables BI de la couche Gold, les schémas en étoile de type Kimball — une table de faits centrale entourée de tables de dimensions — restent la norme pour la performance des tableaux de bord. Les tables de faits contiennent des événements (transactions, sessions, conversions) ; les tables de dimensions contiennent des attributs d'entité (client, produit, magasin). Pour les tables de caractéristiques ML, des tables dénormalisées larges avec une ligne par entité et toutes les caractéristiques en colonnes minimisent la complexité des jointures pendant l'entraînement. Pour l'analyse en continu, des tables d'événements en ajout uniquement (append-only) avec un partitionnement sur l'horodatage de l'événement permettent des analyses de plages temporelles efficaces pour les tableaux de bord en temps réel.

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