Data Lake vs Warehouse vs Lakehouse, formats Parquet/Delta/Iceberg, comparatif Snowflake / BigQuery / Databricks.
Depuis les années 1990, l'architecture data a évolué selon trois paradigmes successifs :
| Paradigme | Période | Représentants | Force | Limite |
|---|---|---|---|---|
| Data Warehouse | 1990-2010 | Teradata, Oracle, SQL Server | Performance SQL analytique, ACID | Schéma rigide, cher, mal pour non-structuré |
| Data Lake | 2010-2020 | Hadoop HDFS, S3, GCS | Stockage massif tout format | "Data swamp", gouvernance faible |
| Lakehouse | 2020- | Databricks Delta, Iceberg, Snowflake | SQL + ACID + tout format + schéma évolutif | Maturité variable selon usage |
Armbrust M. et al., « Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics », CIDR 2021, cidrdb.org/cidr2021 — papier fondateur signé Databricks/UC Berkeley.
Les workloads analytiques scannent quelques colonnes sur des millions de lignes. Stocker par colonne permet :
| Format | Type | ACID | Time travel | Schema evolution | Usage |
|---|---|---|---|---|---|
| Parquet | Columnar fichier | Non (immutable) | Non | Limitée | Standard Data Lake |
| ORC | Columnar fichier | Non | Non | Limitée | Hive, Presto |
| Avro | Row-based | Non | Non | Excellente | Kafka, streaming |
| Delta Lake | Parquet + log JSON | Oui | Oui (versionning) | Oui | Databricks, mainstream |
| Apache Iceberg | Parquet + métastore | Oui | Oui | Oui | Vendor-neutral, Snowflake |
| Apache Hudi | Parquet + delta logs | Oui | Oui | Oui | Uber, streaming intensif |
Lancé en 2014 sur AWS, étendu à Azure et GCP. Stockage et compute séparés, paiement à l'usage (par seconde, par crédit). Multi-cluster compute (warehouses XS à 6XL). Pas d'infrastructure à gérer.
| Composant | Rôle |
|---|---|
| Virtual Warehouse | Compute (clusters MPP) |
| Storage (micro-partitions) | Données Parquet propriétaire, immuables, clustered |
| Cloud Services Layer | Metadata, query planning, security |
| Time Travel | Restaurer données passées (1-90 jours) |
| Snowpark | Python/Scala/Java pour transformations |
Service serverless, paiement à la requête (TB scannés) ou capacity-based (slots). Architecture Dremel (Google 2010). BigLake permet de requêter du Parquet/Iceberg externe (multi-cloud).
Lakehouse construit sur Delta Lake + Apache Spark. Notebooks collaboratifs, MLflow intégré, Unity Catalog pour gouvernance.
| Comparaison | Snowflake | BigQuery | Databricks |
|---|---|---|---|
| Modèle pricing | Crédits par seconde | $ par TB scanné ou slots | DBU par instance |
| Format natif | Micro-partitions Snowflake | Capacitor (proprietaire) | Delta Lake (Parquet + log) |
| SQL | Excellent (ANSI) | Excellent (Google SQL) | Bon (Spark SQL) |
| ML intégré | Snowpark ML, Cortex | BigQuery ML | MLflow, AutoML |
| Notebooks | Snowsight | Colab integration | Natifs collaboratifs |
| Open / Vendor lock-in | Vendor | Vendor | Open (Delta open-sourced) |
Pattern Databricks largement adopté pour structurer un Lakehouse :
| Couche | Contenu | Transformation | Usage |
|---|---|---|---|
| Bronze (Raw) | Données brutes telles qu'ingérées | Aucune (sauf ajout metadata : ingestion_ts, source_file) | Audit, replay, debug |
| Silver (Cleansed) | Dédupliqué, typé, schéma normalisé | Validation, déduplication, joins, conformément aux dimensions | Self-service analytics, ML features |
| Gold (Curated) | Métriques business, agrégats finaux | Agrégations, KPI métier, joints dimensionnels | BI (Looker, Tableau, Power BI) |
# Bronze
df_bronze = spark.read.json("s3://lake/raw/events/2026/05/27/")
df_bronze.write.format("delta").mode("append").save("s3://lake/bronze/events/")
# Silver
df_silver = (spark.read.format("delta").load("s3://lake/bronze/events/")
.filter("user_id IS NOT NULL")
.dropDuplicates(["event_id"])
.withColumn("event_ts", to_timestamp("ts"))
.withColumn("ingestion_dt", current_date()))
df_silver.write.format("delta").mode("overwrite").save("s3://lake/silver/events/")
# Gold
df_gold = (spark.read.format("delta").load("s3://lake/silver/events/")
.groupBy("country", "event_type", to_date("event_ts").alias("event_dt"))
.count()
.orderBy("event_dt"))
df_gold.write.format("delta").mode("overwrite").save("s3://lake/gold/event_daily/")
Le DWH historique appliquait ETL : Extract → Transform (Informatica, SSIS) → Load. Le stockage cher imposait de transformer avant.
Avec le stockage objet bon marché et les warehouses scalables, le pattern ELT domine : Extract → Load (raw) → Transform (SQL dans le warehouse, via dbt). Avantages : reproductibilité, versioning Git, debug facile.
| Catalogue | Éditeur | Particularité |
|---|---|---|
| Unity Catalog | Databricks | Permissions granulaires, lineage automatique |
| AWS Glue Data Catalog | AWS | Compatible Hive Metastore, intégré Athena/EMR |
| Apache Polaris | Snowflake (OSS) | Iceberg-native, open standard |
| OpenMetadata | Open-source | Discovery, lineage, qualité |
| DataHub | LinkedIn (OSS) | Lineage colonne par colonne |
La leçon suivante est également gratuite. Découvrez-la sans inscription.
Leçon 2 — Continuer →Choisis quels cookies tu acceptes — modifiable à tout moment.