Introduction Architecture Cloud

45 min Intermediaire

Objectifs de la lecon

  • Comprendre l'evolution du cloud computing pour les architectures data
  • Maitriser les strategies multi-cloud et leurs implications pour un Data Architect
  • Distinguer les approches cloud-native et lift-and-shift
  • Appliquer le framework des 6R pour planifier une migration cloud

Apres avoir accompagne plus de 40 migrations cloud dans des contextes allant de la startup a la banque systemique, je peux vous dire que le cloud n'est pas une destination, c'est un modele operationnel. La plus grande erreur que je vois ? Des equipes qui deplacent leurs serveurs on-premise vers EC2 et appellent ca une "transformation cloud". Le vrai cloud, c'est repenser votre architecture pour exploiter l'elasticite, le pay-per-use et les services manages. Mon conseil : commencez toujours par le "pourquoi" avant le "comment".

L'evolution du Cloud pour la Data

Le cloud computing a radicalement transforme la maniere dont les organisations gerent leurs donnees. En moins de 15 ans, nous sommes passes de data centers physiques avec des cycles d'approvisionnement de 6 mois a des infrastructures elastiques deployables en quelques minutes. Cette evolution n'est pas qu'une question de technologie : c'est un changement fondamental dans l'economie de la donnee.

ErePeriodeCaracteristiquesLimites
On-Premise2000-2010Data centers prives, Teradata, Oracle RAC, licences perpetuellesCAPEX eleve, scalabilite limitee, delai de provisionnement
Cloud IaaS2010-2015VMs cloud (EC2), Hadoop sur cloud, lift-and-shiftComplexite operationnelle, sous-utilisation des services manages
Cloud PaaS/SaaS2015-2020Services manages (Redshift, BigQuery), separation compute/stockageVendor lock-in, couts imprevisibles
Cloud-Native2020+Serverless, Lakehouse, multi-cloud, FinOps, DataOpsComplexite de choix, competences rares, gouvernance distribuee

Les 5 caracteristiques essentielles du Cloud (NIST)

1. Self-service a la demande : provisionnement sans intervention humaine.
2. Acces reseau large bande : disponible via le reseau standard.
3. Mise en commun des ressources (pooling) : multi-tenant avec isolation.
4. Elasticite rapide : scale-up et scale-down automatiques.
5. Service mesure (pay-per-use) : facturation a l'usage reel.

Strategies Multi-Cloud

Le multi-cloud consiste a utiliser les services de plusieurs fournisseurs cloud simultanement. Selon Flexera 2024, 87% des entreprises ont adopte une strategie multi-cloud. Mais attention : multi-cloud ne signifie pas utiliser le meme workload sur plusieurs clouds. C'est plutot choisir le meilleur cloud pour chaque cas d'usage.

Avantages du Multi-Cloud

  • Eviter le vendor lock-in strategique
  • Exploiter les forces de chaque provider (BigQuery pour l'analytics, AWS pour le ML, Azure pour l'ecosysteme Microsoft)
  • Negocier de meilleurs tarifs par mise en concurrence
  • Conformite reglementaire (residences des donnees)
  • Resilience inter-cloud pour les workloads critiques

Risques du Multi-Cloud

  • Complexite operationnelle multipliee par le nombre de clouds
  • Couts de transfert de donnees (egress fees) entre clouds
  • Competences rares : trouver des equipes maitrisant 2-3 clouds
  • Gouvernance fragmentee si pas d'outil unifie
  • Integration et monitoring plus complexes

Cloud-Native vs Lift-and-Shift

Deux approches radicalement differentes pour migrer vers le cloud, avec des implications majeures sur les couts, la performance et la maintenabilite a long terme.

Spectre des strategies de migration cloud
  EFFORT MINIMAL                                              EFFORT MAXIMAL
  BENEFICE MINIMAL                                            BENEFICE MAXIMAL
       |                                                           |
       v                                                           v
  +----------+    +-----------+    +----------+    +-----------+    +----------+    +-----------+
  | RETAIN   |    | REHOST    |    | REPLATFORM|   | REFACTOR  |    | REARCHITECT|  | REBUILD   |
  | (Garder) |    | (Lift &   |    | (Lift &   |   | (Adapter  |    | (Repenser)|  | (Repartir |
  |          |--->| Shift)    |--->| Tinker)   |-->| le code)  |--->|           |-->| de zero)  |
  | On-prem  |    | VM -> EC2 |    | VM -> RDS |   | Conteneurs|    | Serverless|  | Cloud-    |
  |          |    |           |    | + managed |   | + K8s     |    | + managed |  | native    |
  +----------+    +-----------+    +----------+    +-----------+    +----------+    +-----------+
       R1              R2              R3               R4              R5              R6

Le Framework des 6R de Migration

Retain (R1) : Garder on-premise. Pour les workloads avec des contraintes reglementaires ou un ROI negatif de migration.
Rehost (R2) : Lift-and-shift pur. Migration rapide mais peu d'optimisation. Economie de 10-20% sur l'infra.
Replatform (R3) : Lift-and-tinker. Remplacement des composants par des services manages (ex: Oracle -> RDS). Economie de 30-40%.
Refactor (R4) : Adaptation du code pour exploiter les services cloud. Conteneurisation, decoupage en microservices.
Rearchitect (R5) : Reconception de l'architecture en cloud-native. Serverless, event-driven, fully managed.
Rebuild (R6) : Reconstruction complete. Quand l'application legacy est trop obsolete pour etre migree.

Capital One : Migration 100% Cloud AWS

Capital One, l'une des plus grandes banques americaines, a complete sa migration a 100% vers AWS en 2020, fermant ses derniers data centers. Cette migration de 8 ans a implique :

  • Migration de plus de 1 000 applications et des petaoctets de donnees financieres
  • Adoption d'une architecture cloud-native avec microservices et serverless (Lambda, Step Functions)
  • Reduction de 50% du nombre d'outils de data management
  • Mise en conformite PCI-DSS et SOX dans le cloud avec encryption et IAM avances
  • Creation d'un framework interne "Cloud Custodian" pour la gouvernance automatisee (open-source)

Lecon cle : Capital One a choisi une approche progressive avec une strategie R3-R5 selon les workloads, et non un big bang.

GE Digital : Echec de la plateforme Predix Cloud

General Electric a investi plus de 7 milliards de dollars dans Predix, sa plateforme cloud IoT industrielle. Le projet a largement echoue pour plusieurs raisons :

  • Tentative de construire un cloud proprietaire au lieu d'utiliser les hyperscalers existants
  • Sous-estimation massive de la complexite operationnelle d'un cloud platform
  • Absence de strategie multi-cloud : les clients industriels ne voulaient pas dependre d'un seul fournisseur
  • Manque de competences cloud internes et recrutement insuffisant

Lecon cle : construire son propre cloud est rarement justifie. Les hyperscalers (AWS, GCP, Azure) investissent des milliards par an en R&D.

Le Lift-and-Shift sans optimisation

Migrer des serveurs on-premise vers des VMs cloud (EC2, Compute Engine) sans repenser l'architecture est le piege le plus courant. Resultat typique : les couts cloud depassent les couts on-premise de 30-50% car les VMs sont surdimensionnees, allumees 24/7, et n'exploitent ni l'elasticite ni les services manages.

Solution : Avant toute migration, realisez un assessment complet avec right-sizing. Identifiez les quick wins (passage a des services manages pour les bases de donnees, auto-scaling pour les workloads variables) et planifiez une roadmap de modernisation post-migration.

Votre premiere strategie de migration cloud

Vous etes nomme Data Architect dans un groupe industriel europeen. L'infrastructure data actuelle comprend :

  • Un data warehouse Oracle Exadata de 20 TB (critique, 200 utilisateurs BI)
  • Un cluster Hadoop de 50 noeuds pour le data lake (sous-utilise a 30%)
  • 15 serveurs ETL Informatica PowerCenter avec 500 jobs
  • Des contraintes RGPD strictes (donnees dans l'UE uniquement)

Quelle strategie 6R appliquez-vous a chaque composant ? Quel cloud provider choisissez-vous et pourquoi ? Quel est votre calendrier sur 24 mois ?

Conseil : le Data Gravity

Le concept de "Data Gravity" stipule que les applications et services sont attires vers les donnees, pas l'inverse. Plus vos donnees sont volumineuses dans un cloud, plus il est couteux et complexe de les deplacer. Choisissez votre cloud strategiquement des le debut, car le cout de changement augmente exponentiellement avec le volume.

Quelles sont les 6 strategies de migration cloud (6R) ?
Retain (garder on-premise), Rehost (lift-and-shift), Replatform (lift-and-tinker avec services manages), Refactor (adapter le code), Rearchitect (reconcevoir en cloud-native), Rebuild (reconstruire de zero). Chaque strategie represente un compromis entre effort de migration et benefices cloud obtenus.
Qu'est-ce que le Data Gravity et pourquoi est-ce important pour un Data Architect ?
Le Data Gravity est le principe selon lequel les applications et services sont attires vers l'endroit ou les donnees sont stockees. Plus le volume de donnees est important dans un cloud, plus le cout de migration (egress fees) et la latence rendent difficile le changement de provider. Le Data Architect doit anticiper ce phenomene dans ses choix d'architecture initiale.
Pourquoi le lift-and-shift pur est-il souvent plus couteux que l'on-premise ?
Parce que les VMs cloud sont facturees a l'heure et souvent surdimensionnees (meme taille que l'on-premise). Sans auto-scaling, reserved instances, et services manages, on paie le premium du cloud sans ses benefices. Le TCO est typiquement 30-50% plus eleve qu'on-premise pour un lift-and-shift non optimise.

Data Lakehouse Architecture

60 min Avance

Objectifs de la lecon

  • Comprendre l'architecture Lakehouse et son positionnement par rapport au Data Warehouse et au Data Lake
  • Maitriser la Medallion Architecture (Bronze / Silver / Gold) en profondeur
  • Comprendre les mecanismes internes de Delta Lake (transaction log, time travel, Z-ordering)
  • Decouvrir Unity Catalog et la gouvernance unifiee des donnees

Le Lakehouse est probablement l'evolution architecturale la plus significative de la derniere decennie en data engineering. J'ai deploye des Lakehouses chez des clients allant de la fintech a l'industrie pharmaceutique, et la promesse est reelle : un seul systeme pour le BI, le data science et le streaming. Mais la cle du succes, c'est la rigueur dans l'implementation de la Medallion Architecture. Sans discipline sur les couches Bronze/Silver/Gold, vous retombez dans le "data swamp" du Data Lake classique.

Du Data Warehouse au Lakehouse

Le Lakehouse combine les meilleures caracteristiques du Data Warehouse (transactions ACID, schema enforcement, performance SQL) et du Data Lake (stockage ouvert, support de tous les types de donnees, cout reduit). Cette convergence resout les limitations historiques des deux approches.

CritereData WarehouseData LakeLakehouse
Transactions ACIDOuiNonOui (via Delta/Iceberg)
Formats de donneesStructurees uniquementToutes (struct, semi, non-struct)Toutes avec schema enforcement
Cout de stockageEleve ($23/TB/mois Redshift)Faible ($23/TB/mois S3)Faible (stockage objet)
Performance SQLExcellenteVariableExcellente (indexation, caching)
Support ML/DSLimite (export necessaire)Natif (acces direct fichiers)Natif (DataFrame + SQL)
GouvernanceMature (RBAC natif)Faible (fichiers sur object store)Unifiee (Unity Catalog)
Format ouvertNon (format proprietaire)Oui (Parquet, ORC)Oui (Delta, Iceberg, Hudi)

La Medallion Architecture en profondeur

La Medallion Architecture (ou architecture multi-hop) organise les donnees en trois couches de qualite croissante. Chaque couche a un role precis et des regles strictes.

Medallion Architecture - Bronze / Silver / Gold
  SOURCES                    BRONZE (Raw)              SILVER (Cleaned)          GOLD (Business)
 +----------+            +------------------+       +------------------+      +------------------+
 | APIs     |            | Donnees brutes   |       | Donnees nettoyees|      | Modeles metier   |
 | Bases DD |----------->| Format source    |------>| Dedupliquees     |----->| Agregations      |
 | Fichiers |  Ingestion | Append-only      | Clean | Typees           | Agg  | KPIs             |
 | Streams  |            | Partitionnees    |       | Validees         |      | Dimensionnel     |
 +----------+            | par date         |       | Schema enforce   |      | Pret pour BI/ML  |
                         +------------------+       +------------------+      +------------------+
                               |                          |                         |
                          Retention:               Retention:                 Retention:
                          1-7 ans                  1-3 ans                   Indefinie
                          (compliance)             (replay)                  (business)

                          Schema:                  Schema:                   Schema:
                          Schema-on-read           Schema-on-write           Star/Snowflake
                          Pas de validation        Validation stricte        Modeles metier

                          Qualite:                 Qualite:                  Qualite:
                          Aucun controle           Regles de qualite         SLA de qualite
                          Donnees "as-is"          appliquees                garanti

Regles d'or de la Medallion Architecture

Bronze : Jamais de transformation. Les donnees arrivent telles quelles. Ajoutez des metadonnees d'ingestion (timestamp, source, batch_id). Utilisez le partitionnement par date d'ingestion.
Silver : Deduplication, nettoyage des types, validation des schemas, resolution des references. C'est la couche la plus critique pour la qualite.
Gold : Modeles dimensionnels (faits/dimensions), agregations metier, KPIs precalcules. Optimises pour la performance de lecture. C'est ici que vit la "verite metier".

Delta Lake : les mecanismes internes

Delta Lake est un format de stockage open-source qui apporte les transactions ACID au stockage objet (S3, ADLS, GCS). Il repose sur un transaction log (journal de transactions) qui enregistre chaque operation de maniere atomique.

Structure Delta Lake sur Object Store
s3://my-lakehouse/bronze/orders/
  _delta_log/
    00000000000000000000.json    # Creation de la table
    00000000000000000001.json    # Premier INSERT (add files)
    00000000000000000002.json    # MERGE operation
    00000000000000000003.json    # UPDATE operation
    00000000000000000010.checkpoint.parquet  # Checkpoint (snapshot)
  year=2024/
    month=01/
      part-00000-xxxx.snappy.parquet
      part-00001-xxxx.snappy.parquet
    month=02/
      part-00000-yyyy.snappy.parquet
PySpark - Delta Lake Operations
# Ecriture en Bronze (append-only)
df_raw = spark.readStream \
    .format("kafka") \
    .option("subscribe", "orders") \
    .load()

df_raw.writeStream \
    .format("delta") \
    .outputMode("append") \
    .option("checkpointLocation", "/checkpoints/orders_bronze") \
    .toTable("bronze.orders")

# Transformation Bronze -> Silver avec MERGE (upsert)
from delta.tables import DeltaTable

silver_table = DeltaTable.forName(spark, "silver.orders")
bronze_new = spark.read.table("bronze.orders") \
    .filter("ingestion_date = current_date()")

silver_table.alias("target").merge(
    bronze_new.alias("source"),
    "target.order_id = source.order_id"
).whenMatchedUpdateAll() \
 .whenNotMatchedInsertAll() \
 .execute()

# Time Travel : lire une version anterieure
df_yesterday = spark.read \
    .format("delta") \
    .option("versionAsOf", 42) \
    .table("silver.orders")

# Ou par timestamp
df_point_in_time = spark.read \
    .format("delta") \
    .option("timestampAsOf", "2024-01-15 10:00:00") \
    .table("silver.orders")

Z-Ordering : optimisation des requetes analytiques

Le Z-Ordering reorganise physiquement les donnees dans les fichiers Parquet pour co-localiser les valeurs proches sur plusieurs colonnes. Si vos requetes filtrent souvent sur country et date, un Z-Order sur ces colonnes peut reduire le scan de donnees de 90%.

OPTIMIZE silver.orders ZORDER BY (country, order_date)

Unity Catalog : gouvernance unifiee

Unity Catalog est la solution de gouvernance de Databricks qui offre un namespace a 3 niveaux (catalog.schema.table), le controle d'acces fin (row-level, column-level), le lineage automatique, et la decouverte de donnees.

Hierarchie Unity Catalog
  METASTORE (niveau compte)
    |
    +-- CATALOG: production
    |     +-- SCHEMA: bronze
    |     |     +-- TABLE: orders
    |     |     +-- TABLE: customers
    |     |     +-- TABLE: products
    |     +-- SCHEMA: silver
    |     |     +-- TABLE: orders_cleaned
    |     |     +-- TABLE: customers_master
    |     +-- SCHEMA: gold
    |           +-- TABLE: daily_revenue
    |           +-- TABLE: customer_360
    |
    +-- CATALOG: development
    |     +-- SCHEMA: sandbox_alice
    |     +-- SCHEMA: sandbox_bob
    |
    +-- CATALOG: analytics
          +-- SCHEMA: marketing
          +-- SCHEMA: finance

Comcast : Migration vers le Lakehouse Databricks

Comcast, le plus grand cabloperateur americain, a migre son infrastructure data vers un Lakehouse Databricks unifie pour gerer les donnees de plus de 30 millions d'abonnes :

  • Remplacement de multiples data warehouses et data lakes fragmentes par un Lakehouse unique
  • Implementation de la Medallion Architecture avec plus de 2 000 tables Delta
  • Reduction du temps de preparation des donnees de 80% grace au pipeline Bronze/Silver/Gold standardise
  • Unification du BI et du ML sur la meme plateforme, eliminant les copies de donnees entre systemes
  • Economie de 40% sur les couts d'infrastructure par rapport a l'architecture precedente

DataSwamp Corp (anonymise) : le Lakehouse mal implemente

Une entreprise de e-commerce a deploye un Lakehouse sans discipline architecturale. En 18 mois :

  • La couche Bronze contenait des transformations metier (violation du principe raw-only)
  • Aucune deduplication en Silver : les memes commandes apparaissaient 3 a 5 fois
  • La couche Gold etait absente : chaque equipe creait ses propres agregations, generant des chiffres contradictoires
  • Pas de Unity Catalog : 400 tables sans documentation, sans lineage, sans controle d'acces

Correction : 6 mois de refactoring avec une equipe dedicee, implementation stricte de la Medallion Architecture et deploiement d'Unity Catalog.

Le "Lakehouse" qui est en realite un Data Lake deguise

Utiliser Delta Lake uniquement pour le stockage sans implementer les transactions ACID, le schema enforcement, ni la gouvernance. On obtient un "Data Lake avec des fichiers Delta" et non un veritable Lakehouse. La valeur du Lakehouse vient de la combinaison format ouvert + transactions + gouvernance + performance SQL.

Solution : Activez systematiquement le schema enforcement (mergeSchema controle), implementez les contraintes CHECK et NOT NULL, et deployez Unity Catalog des le premier jour.

Quelles sont les trois couches de la Medallion Architecture et leur role ?
Bronze (Raw) : donnees brutes, append-only, aucune transformation, schema-on-read. Silver (Cleaned) : donnees nettoyees, dedupliquees, typees, avec schema-on-write et validation. Gold (Business) : modeles metier, agregations, KPIs, optimises pour la consommation BI et ML. Chaque couche augmente la qualite et la valeur des donnees.
Comment Delta Lake garantit-il les transactions ACID sur un object store ?
Delta Lake utilise un transaction log (_delta_log/) qui enregistre chaque operation de maniere atomique dans des fichiers JSON. Le log utilise le verrouillage optimiste : chaque ecriture verifie que le log n'a pas change depuis sa lecture. Les checkpoints periodiques (fichiers Parquet) evitent de relire tout l'historique. Ce mecanisme offre atomicite, coherence, isolation (snapshot) et durabilite.
Qu'est-ce que le Z-Ordering dans Delta Lake ?
Le Z-Ordering est une technique d'optimisation qui reorganise physiquement les donnees dans les fichiers Parquet pour co-localiser les lignes ayant des valeurs proches sur les colonnes specifiees. Cela permet au data skipping de Delta Lake d'eliminer plus de fichiers lors des requetes filtrees sur ces colonnes, reduisant potentiellement le volume scanne de 90%.

AWS Data Platform

60 min Avance

Objectifs de la lecon

  • Maitriser les services data fondamentaux d'AWS : S3, Glue, Athena, Redshift, EMR
  • Comprendre AWS Lake Formation et son role dans la gouvernance
  • Orchestrer des pipelines avec Step Functions et EventBridge
  • Concevoir une architecture data complete sur AWS

AWS est le leader inconteste du cloud avec plus de 32% de parts de marche. Son ecosysteme data est le plus riche mais aussi le plus complexe : plus de 15 services lies a la data. Mon conseil apres avoir deploye des dizaines d'architectures AWS : ne tombez pas dans le piege de vouloir utiliser tous les services. Pour 80% des cas d'usage, le trio S3 + Glue + Athena suffit. Ajoutez Redshift uniquement si vous avez des besoins de BI interactive avec des requetes complexes sur des teraoctets.

Vue d'ensemble des services data AWS

AWS propose un ecosysteme data complet couvrant l'ingestion, le stockage, le traitement, l'analyse et la gouvernance. Le Data Architect doit maitriser les forces et faiblesses de chaque service pour faire les bons choix.

ServiceCategorieCas d'usageModele de cout
S3StockageData Lake, archivage, staging$0.023/Go/mois (Standard)
GlueETL / CatalogueCrawlers, jobs Spark, Data CatalogDPU-heure ($0.44/DPU/h)
AthenaQuery EngineRequetes SQL sur S3 (serverless)$5/To scanne
RedshiftData WarehouseBI interactive, requetes complexesA partir de $0.25/h (dc2.large)
EMRBig DataSpark, Hive, Presto a grande echelleInstance EC2 + surcharge EMR
KinesisStreamingIngestion temps reel, analytics streaming$0.015/h/shard (Data Streams)
Lake FormationGouvernanceControle d'acces, lineage, catalogageGratuit (paiement des services sous-jacents)
Step FunctionsOrchestrationPipelines serverless, workflows$0.025/1000 transitions

Architecture de reference AWS Data Platform

Architecture Data Platform Complete sur AWS
  SOURCES                   INGESTION               STOCKAGE (S3)            TRAITEMENT           CONSOMMATION
 +----------+           +--------------+         +------------------+     +---------------+    +---------------+
 | APIs     |---------->| Kinesis Data |-------->| s3://bronze/     |---->| AWS Glue      |--->| Amazon        |
 | SaaS     |           | Firehose     |         | (raw data)       |     | (ETL Spark)   |    | Athena (SQL)  |
 +----------+           +--------------+         +------------------+     +---------------+    +---------------+
 | Databases|---------->| AWS DMS      |-------->| s3://silver/     |---->| Amazon EMR    |--->| Amazon        |
 | (RDS,    |           | (CDC)        |         | (cleaned)        |     | (Spark/Hive)  |    | Redshift      |
 | Oracle)  |           +--------------+         +------------------+     +---------------+    | (BI DWH)      |
 +----------+           | AWS Glue     |-------->| s3://gold/       |                          +---------------+
 | Fichiers |---------->| Crawlers     |         | (business)       |                          | Amazon        |
 | (SFTP)   |           +--------------+         +------------------+                          | QuickSight    |
 +----------+                                           |                                      +---------------+
                                                        v                                      | SageMaker     |
                                                 +--------------+                              | (ML)          |
                                                 | AWS Lake     |                              +---------------+
                                                 | Formation    |
                                                 | (Gouvernance)|
                                                 +--------------+
                                                        |
                         +------------------------------+-----------------------------+
                         |                              |                             |
                  +------v------+              +--------v-------+            +--------v-------+
                  | Glue Data   |              | Fine-grained   |            | CloudWatch     |
                  | Catalog     |              | Access Control |            | Monitoring     |
                  | (Metadonnees)|             | (Row/Column)   |            | & Alertes      |
                  +-------------+              +----------------+            +----------------+

Amazon S3 : le coeur du Data Lake AWS

S3 est le fondement de toute architecture data sur AWS. Sa durabilite de 99.999999999% (11 neufs), son cout faible et son integration avec tous les services AWS en font le choix naturel pour le stockage.

Bonnes pratiques S3 pour un Data Lake

Partitionnement : Organisez vos donnees par date (s3://bucket/bronze/orders/year=2024/month=01/day=15/). Cela permet a Athena et Glue de faire du partition pruning.
Format : Utilisez Parquet ou Delta pour les donnees analytiques. Compression Snappy pour le meilleur compromis taille/vitesse.
Classes de stockage : S3 Standard pour les donnees actives, S3-IA pour les donnees rarement accedees (>30 jours), Glacier pour l'archivage (>90 jours).
Lifecycle policies : Automatisez la transition entre classes de stockage pour optimiser les couts.

AWS Glue et le Data Catalog

AWS Glue est un service ETL serverless base sur Apache Spark. Son composant le plus precieux est le Glue Data Catalog, qui sert de metastore central compatible Hive pour tout l'ecosysteme AWS.

AWS Glue ETL Job (PySpark)
import sys
from awsglue.transforms import *
from awsglue.utils import getResolvedOptions
from awsglue.context import GlueContext
from pyspark.context import SparkContext

sc = SparkContext()
glueContext = GlueContext(sc)
spark = glueContext.spark_session

# Lecture depuis le Glue Data Catalog (Bronze)
orders_bronze = glueContext.create_dynamic_frame.from_catalog(
    database="bronze_db",
    table_name="orders",
    push_down_predicate="year='2024' AND month='01'"
)

# Transformation Bronze -> Silver
orders_silver = orders_bronze.toDF() \
    .dropDuplicates(["order_id"]) \
    .filter("amount > 0 AND status IS NOT NULL") \
    .withColumn("amount", col("amount").cast("decimal(10,2)")) \
    .withColumn("processed_at", current_timestamp())

# Ecriture en Silver (format Parquet partitionne)
orders_silver.write \
    .mode("overwrite") \
    .partitionBy("year", "month") \
    .format("parquet") \
    .saveAsTable("silver_db.orders_cleaned")

Amazon Redshift : le Data Warehouse AWS

Redshift est le DWH cloud d'AWS, base sur PostgreSQL modifie avec un stockage colonnaire et un traitement massivement parallele (MPP). Redshift Serverless elimine la gestion des clusters.

Redshift : quand l'utiliser (et quand l'eviter)

Utilisez Redshift : quand vous avez des requetes BI complexes avec des jointures multiples sur des tables de plusieurs To, des utilisateurs concurrents (50+), et un besoin de latence sub-seconde.
Evitez Redshift : pour du stockage de donnees brutes (utilisez S3), pour des requetes ad-hoc peu frequentes (utilisez Athena), ou si votre volume est inferieur a 500 Go (Athena sera plus economique).

Netflix : Architecture Data sur AWS

Netflix est le plus grand client data d'AWS et a construit une architecture de reference que beaucoup d'entreprises cherchent a emuler :

  • Stockage : Plus de 100 PB sur S3, avec un data lake partitionne par domaine metier
  • Ingestion : Kafka pour le streaming (700 milliards d'evenements/jour), DMS pour les CDC des bases relationnelles
  • Traitement : Spark sur EMR pour le batch, Flink pour le streaming, avec Titus (conteneurs) pour le ML
  • Orchestration : Maestro, leur orchestrateur interne, gerant plus de 500 000 jobs/jour
  • Analytics : Druid pour les analyses temps reel, Presto/Trino pour le SQL interactif
  • Gouvernance : Metacat, leur catalogue de donnees interne, federant les metadonnees de tous les systemes

Lecon cle : Netflix a construit des outils internes la ou les services AWS etaient insuffisants, tout en restant 100% sur l'infrastructure AWS.

Tout mettre dans Redshift

Un reflexe courant est de charger toutes les donnees dans Redshift, y compris les donnees brutes et les archives. Resultat : des couts de stockage Redshift 10x plus eleves que S3, des performances degradees par le volume, et une complexite de gestion accrue.

Solution : Utilisez Redshift Spectrum pour requeter les donnees S3 directement depuis Redshift sans les charger. Gardez dans Redshift uniquement les tables Gold frequemment requetees. Archivez sur S3 avec des Lifecycle Policies.

Conception d'une architecture AWS pour un e-commerce

Un e-commerce genere 10 millions de transactions/jour, 50 Go de logs web/jour, et 500 Go de donnees produit. Les besoins sont : dashboard temps reel des ventes, analytics marketing (segmentation clients), et modeles de recommandation ML. Budget cloud : 15 000 EUR/mois.

Quels services AWS choisissez-vous pour chaque couche ? Comment organisez-vous le data lake S3 ? Quelle strategie d'optimisation des couts implementez-vous ?

Quelle est la difference entre Athena et Redshift, et quand utiliser chacun ?
Athena est un moteur de requete serverless qui scanne S3 directement, facture au To scanne ($5/To), et ne necessite aucune infrastructure. Ideal pour les requetes ad-hoc et les faibles volumes. Redshift est un DWH MPP avec stockage dedie, ideal pour les requetes BI complexes, les jointures multiples et la concurrence elevee. Regle : <500 Go ou requetes peu frequentes = Athena. >500 Go avec BI intensive = Redshift.
Quel est le role d'AWS Lake Formation ?
Lake Formation centralise la gouvernance du Data Lake AWS. Il simplifie la creation du data lake (ingestion, nettoyage, catalogage), fournit un controle d'acces fin (row-level et column-level security) sur les donnees S3, et s'integre avec le Glue Data Catalog pour les metadonnees. Il remplace les politiques IAM complexes par un modele de permissions declaratif.

GCP Data Platform

60 min Avance

Objectifs de la lecon

  • Maitriser BigQuery : architecture, optimisation, partitionnement et clustering
  • Comprendre Dataflow (Apache Beam) pour le traitement batch et streaming unifie
  • Utiliser Dataproc, Pub/Sub et Cloud Composer pour une architecture complete
  • Decouvrir Dataplex pour la gouvernance du Data Lake GCP

GCP est le cloud des donnees par excellence. BigQuery, c'est probablement le service cloud le plus elegant jamais concu pour l'analytics. Zero infrastructure, zero index, zero tuning, et des performances qui rivalisent avec des clusters de 100 noeuds. J'ai vu des equipes migrer de Redshift a BigQuery et diviser leurs couts par 3 tout en ameliorant les performances. Mais attention : BigQuery a ses propres regles. Si vous essayez de l'utiliser comme un SGBD transactionnel, vous allez droit dans le mur.

BigQuery : l'arme secrete de GCP

BigQuery est un data warehouse serverless et multi-cloud base sur l'architecture Dremel de Google. Il separe completement le stockage (Colossus) et le compute (Dremel), permettant une scalabilite quasi-infinie sans gestion d'infrastructure.

Architecture interne de BigQuery
  CLIENT (SQL)
       |
       v
  +--------------------+
  | API BigQuery       |    Routage, authentification, quotas
  +--------------------+
       |
       v
  +--------------------+
  | Query Optimizer    |    Analyse SQL, plan d'execution, estimation cout
  +--------------------+
       |
       v
  +--------------------+
  | Dremel Engine      |    Execution distribuee en arbre (root -> mixers -> leaf)
  |  +------+          |
  |  | Root |          |       Root Server : coordination
  |  +--+---+          |
  |     |              |
  |  +--+--+  +--+--+ |
  |  |Mixer|  |Mixer| |       Mixers : agregation intermediaire
  |  +--+--+  +--+--+ |
  |    / \      / \    |
  |  Leaf Leaf Leaf Leaf|      Leaf Servers : scan des donnees
  +--------------------+
       |
       v
  +--------------------+
  | Colossus (GFS)     |    Stockage distribue (format Capacitor columnar)
  +--------------------+
       |
       v
  +--------------------+
  | Jupiter Network    |    Reseau interne Google (1 Pb/s de bande passante)
  +--------------------+

Optimisation BigQuery : les 4 leviers

1. Partitionnement : Partitionnez par date (PARTITION BY DATE(created_at)). Reduction de scan typique : 90%+.
2. Clustering : Ordonnez les donnees au sein des partitions (CLUSTER BY country, category). Jusqu'a 4 colonnes.
3. Materialised Views : Precalculez les agregations frequentes. BigQuery les met a jour automatiquement.
4. BI Engine : Cache in-memory pour les dashboards. Latence sub-seconde meme sur des To de donnees.

SQL - BigQuery Optimisations
-- Table partitionnee et clusterisee
CREATE TABLE gold.daily_revenue
PARTITION BY DATE(order_date)
CLUSTER BY country, product_category
AS
SELECT
    DATE(order_date) as order_date,
    country,
    product_category,
    COUNT(*) as nb_orders,
    SUM(amount) as total_revenue,
    AVG(amount) as avg_order_value
FROM silver.orders_cleaned
GROUP BY 1, 2, 3;

-- Vue materialisee (mise a jour automatique)
CREATE MATERIALIZED VIEW gold.hourly_revenue_mv
AS
SELECT
    TIMESTAMP_TRUNC(order_timestamp, HOUR) as hour,
    country,
    SUM(amount) as revenue,
    COUNT(*) as orders
FROM silver.orders_cleaned
GROUP BY 1, 2;

-- Requete optimisee (scanne uniquement les partitions necessaires)
SELECT country, SUM(total_revenue)
FROM gold.daily_revenue
WHERE order_date BETWEEN '2024-01-01' AND '2024-01-31'
  AND country IN ('FR', 'DE', 'ES')
GROUP BY country;
-- Scan estime : 50 Mo au lieu de 2 To sans partitionnement

Architecture Data Platform complete GCP

Architecture de Reference GCP Data Platform
  SOURCES                 INGESTION                STOCKAGE               TRAITEMENT           CONSOMMATION
 +----------+          +--------------+         +-----------------+    +----------------+   +----------------+
 | Apps     |--------->| Pub/Sub      |-------->| GCS (Data Lake) |    | Dataflow       |   | BigQuery       |
 | (events) |          | (streaming)  |         | gs://bronze/    |--->| (Apache Beam)  |-->| (SQL Analytics)|
 +----------+          +--------------+         | gs://silver/    |    +----------------+   +----------------+
 | Databases|--------->| Datastream   |         | gs://gold/      |    | Dataproc       |   | Looker         |
 | (Cloud   |          | (CDC)        |-------->|                 |--->| (Spark/Hadoop) |-->| (BI Dashboards)|
 | SQL)     |          +--------------+         +-----------------+    +----------------+   +----------------+
 +----------+          | Cloud Data   |                |               | BigQuery       |   | Vertex AI      |
 | SaaS     |--------->| Fusion       |                |               | (SQL transform)|   | (ML Platform)  |
 | (APIs)   |          | (low-code)   |                v               +----------------+   +----------------+
 +----------+          +--------------+         +--------------+
                              |                 | Dataplex     |         ORCHESTRATION
                              |                 | (Gouvernance)|       +----------------+
                              +---------------->| Data Catalog |       | Cloud Composer |
                                                | Data Quality |       | (Airflow)      |
                                                +--------------+       +----------------+

Dataflow : le traitement unifie batch/streaming

Dataflow est le service manage de Google pour Apache Beam. Son avantage unique : un seul pipeline peut s'executer en batch ou en streaming sans modification de code. Google l'utilise en interne pour traiter les donnees de Search, YouTube et Ads.

Python - Pipeline Dataflow (Apache Beam)
import apache_beam as beam
from apache_beam.options.pipeline_options import PipelineOptions

options = PipelineOptions([
    '--runner=DataflowRunner',
    '--project=my-project',
    '--region=europe-west1',
    '--temp_location=gs://my-bucket/temp',
    '--streaming'  # Supprimer pour batch
])

with beam.Pipeline(options=options) as p:
    (p
     | 'Read from Pub/Sub' >> beam.io.ReadFromPubSub(
           topic='projects/my-project/topics/orders')
     | 'Parse JSON' >> beam.Map(parse_order_json)
     | 'Filter Valid' >> beam.Filter(lambda x: x['amount'] > 0)
     | 'Window 5min' >> beam.WindowInto(
           beam.window.FixedWindows(300))  # 5 minutes
     | 'Aggregate' >> beam.CombinePerKey(sum)
     | 'Write to BigQuery' >> beam.io.WriteToBigQuery(
           'my-project:silver.orders_stream',
           schema='country:STRING,revenue:FLOAT,window_start:TIMESTAMP',
           write_disposition=beam.io.BigQueryDisposition.WRITE_APPEND)
    )

Spotify : Architecture Data sur GCP

Spotify a migre l'integralite de son infrastructure data de ses propres data centers vers GCP en 2018. Avec plus de 600 millions d'utilisateurs, leur architecture data est l'une des plus sophistiquees au monde :

  • Stockage : GCS pour le data lake (plusieurs PB), BigQuery pour l'analytics (10 000+ requetes/jour)
  • Streaming : Pub/Sub + Dataflow pour traiter les evenements d'ecoute en temps reel (plus de 1 milliard d'events/jour)
  • Orchestration : Cloud Composer (Airflow manage) avec plus de 20 000 DAGs en production
  • ML : Vertex AI pour les modeles de recommandation (Discover Weekly, Daily Mix)
  • Gouvernance : Dataplex + Lexikon (outil interne) pour le catalogage de plus de 100 000 datasets

Lecon cle : Spotify a standardise sur BigQuery comme point d'acces unifie pour tous les analystes et data scientists, simplifiant l'acces aux donnees et la gouvernance.

Ignorer le modele de cout de BigQuery

BigQuery facture au volume scanne ($5/To en on-demand). Un SELECT * sur une table de 10 To coute $50 par requete. Sans partitionnement ni clustering, les couts peuvent exploser tres rapidement. J'ai vu un client depenser 15 000 EUR en un mois parce que ses analystes lancaient des SELECT * sans filtre sur des tables massives.

Solution : Activez les quotas par utilisateur, partitionnez systematiquement vos tables, utilisez le mode flat-rate (slots reserves) si votre consommation depasse $10 000/mois, et formez vos analystes a toujours previsualiser le cout de la requete avant execution.

Quelle est l'architecture interne de BigQuery et pourquoi est-elle performante ?
BigQuery repose sur trois composants separes : Dremel (moteur de requete distribue en arbre), Colossus (systeme de fichiers distribue pour le stockage columnar), et Jupiter (reseau interne de Google a 1 Pb/s). Cette separation permet un scaling independant du stockage et du compute, et le reseau Jupiter elimine le goulot d'etranglement I/O classique des systemes distribues.
Quel est l'avantage principal de Dataflow par rapport a Spark ?
Dataflow (Apache Beam) offre un modele de programmation unifie batch/streaming : le meme code s'execute en batch ou en streaming sans modification. De plus, Dataflow est entierement serverless avec auto-scaling, alors que Spark (meme sur Dataproc) necessite de dimensionner et gerer un cluster. Dataflow gere aussi nativement les watermarks et le traitement event-time.

Azure & Microsoft Fabric

60 min Avance

Objectifs de la lecon

  • Comprendre Azure Synapse Analytics et son integration avec l'ecosysteme Microsoft
  • Maitriser Azure Data Factory pour l'orchestration des pipelines
  • Decouvrir Microsoft Fabric et sa vision unifiee de la data platform
  • Comparer Databricks sur Azure avec les services natifs Azure

Azure est le choix naturel pour les entreprises deja investies dans l'ecosysteme Microsoft (Office 365, Dynamics, Power BI). Avec Microsoft Fabric, lance en 2023, Microsoft propose une vision radicalement differente : une plateforme unifiee qui integre ingestion, stockage, traitement, analytics et BI dans un seul produit. C'est ambitieux, et les premiers retours sont prometteurs, mais la maturite n'est pas encore au niveau des services separes. Mon conseil : evaluez Fabric pour les nouveaux projets, mais ne migrez pas vos architectures existantes sans une analyse approfondie.

Azure Synapse Analytics

Synapse est le service analytics unifie d'Azure qui combine data warehousing (ex-SQL DW), data lake integration, Spark, et pipelines dans une seule interface. C'est la reponse d'Azure au besoin de convergence warehouse + lake.

Architecture Azure Data Platform
  SOURCES                 INGESTION                 STOCKAGE                TRAITEMENT          CONSOMMATION
 +----------+          +---------------+         +------------------+    +----------------+   +----------------+
 | Dynamics |--------->| Azure Data    |-------->| ADLS Gen2        |    | Synapse        |   | Power BI       |
 | 365      |          | Factory       |         | (Data Lake)      |--->| Spark Pools    |-->| (Dashboards)   |
 +----------+          | (Orchestration|         | abfss://bronze/  |    +----------------+   +----------------+
 | SQL      |--------->| & ETL)        |         | abfss://silver/  |    | Synapse        |   | Azure ML       |
 | Server   |          +---------------+         | abfss://gold/    |--->| SQL Pools      |-->| (ML Platform)  |
 +----------+          | Event Hubs    |         +------------------+    | (Serverless ou |   +----------------+
 | IoT      |--------->| (Streaming)   |-------->|                  |    |  Dedicated)    |   | Azure          |
 | Devices  |          +---------------+         |                  |    +----------------+   | Databricks     |
 +----------+          | Azure Stream  |         |                  |    | Databricks     |   | (Notebooks)    |
                       | Analytics     |         |                  |--->| (Spark avance) |   +----------------+
                       +---------------+         +------------------+    +----------------+
                                                        |
                                                 +------v-------+
                                                 | Microsoft    |
                                                 | Purview      |
                                                 | (Gouvernance)|
                                                 +--------------+

Microsoft Fabric : la plateforme unifiee

Microsoft Fabric est une plateforme SaaS qui unifie tous les services data dans un seul produit. Elle repose sur OneLake, un data lake unique pour toute l'organisation, et integre nativement Power BI, Data Factory, Synapse et des capacites ML.

Les composants de Microsoft Fabric

OneLake : Un data lake unique et centralise (base sur ADLS Gen2) avec des shortcuts pour federer les donnees multi-cloud.
Data Factory : Orchestration et ingestion de donnees avec 150+ connecteurs.
Synapse Data Engineering : Notebooks Spark pour le traitement a grande echelle.
Synapse Data Warehouse : DWH SQL entierement manage avec format Delta/Parquet.
Power BI : Visualisation et BI integree nativement dans la plateforme.
Real-Time Intelligence : Ingestion et analytics streaming basees sur Kusto (KQL).
Data Activator : Alertes et actions automatiques basees sur les changements de donnees.

Avantages de Fabric

  • Experience unifiee : un seul produit au lieu de 10 services
  • OneLake elimine les silos de donnees et les copies
  • Licence unique (Capacity Units) simplifiant le FinOps
  • Integration native Power BI = Time-to-insight reduit
  • Format ouvert (Delta/Parquet) evite le lock-in de stockage

Limites de Fabric (2024)

  • Maturite limitee pour les workloads de production critiques
  • Moins de flexibilite que des services independants
  • Gouvernance encore en evolution (vs Purview standalone)
  • Lock-in plateforme : tout repose sur l'ecosysteme Microsoft
  • Capacity Units parfois difficiles a prevoir et optimiser

Databricks sur Azure vs Services Natifs

Un choix frequent sur Azure est d'opter pour Azure Databricks (partenariat strategique) au lieu de Synapse Spark. Les deux sont bases sur Apache Spark, mais les differences sont significatives.

CritereAzure DatabricksSynapse SparkMicrosoft Fabric
Moteur SparkOptimise (Photon)Apache Spark standardSpark + Delta optimise
PerformanceExcellente (Photon 3-8x)BonneBonne a tres bonne
GouvernanceUnity Catalog (mature)Purview integrationPurview + OneLake
ML/DSMLflow natif, Feature StoreAzure ML integrationML integre (basique)
SQL AnalyticsDatabricks SQL (excellent)SQL Pools (mature)DWH integre
StreamingStructured Streaming + DLTStreaming basiqueReal-Time Intelligence
CoutDBU (premium Azure)Inclus dans SynapseCapacity Units

Microsoft Purview : la gouvernance Azure

Purview est le service de gouvernance unifie d'Azure. Il offre le catalogage automatique (scan de 100+ sources), le lineage de bout en bout, la classification sensible (PII, PHI), et le glossaire metier. Il scanne automatiquement ADLS, Synapse, SQL Server, Power BI et meme des sources multi-cloud (S3, BigQuery). C'est l'equivalent Azure de AWS Lake Formation + Glue Catalog.

ABN AMRO : Architecture Data Azure pour une banque europeenne

ABN AMRO, l'une des plus grandes banques neerlandaises, a migre son infrastructure data vers Azure pour servir 5 millions de clients :

  • Migration de l'on-premise vers Azure Synapse + ADLS Gen2 avec une approche Medallion
  • Azure Data Factory pour orchestrer plus de 800 pipelines d'ingestion quotidiens
  • Microsoft Purview pour la conformite reglementaire bancaire (DORA, RGPD, MiFID II)
  • Power BI Premium pour plus de 2 000 utilisateurs BI internes
  • Integration Databricks pour les modeles de risque de credit et de detection de fraude

Lecon cle : la combinaison Synapse + Databricks sur Azure permet de couvrir a la fois le BI traditionnel et le data science avance.

Ignorer la gravite des donnees Microsoft

Les organisations utilisant Office 365, Dynamics 365, et SharePoint ont deja des teraoctets de donnees dans l'ecosysteme Microsoft. Choisir AWS ou GCP comme cloud data primaire oblige a deplacer ces donnees, generant des couts d'egress, de la latence et de la complexite. L'inverse est vrai aussi : si vos donnees core sont dans AWS S3, migrer vers Azure uniquement pour Power BI n'a pas de sens.

Solution : Evaluez ou reside la majorite de vos donnees et applications avant de choisir votre cloud data. La gravite des donnees existantes doit peser autant que les capacites techniques dans votre decision.

Qu'est-ce que OneLake dans Microsoft Fabric et pourquoi est-ce important ?
OneLake est un data lake unique et centralise pour toute l'organisation, base sur ADLS Gen2. Son innovation est le concept de "shortcuts" : des liens vers des donnees stockees ailleurs (S3, GCS, autre tenant) sans copie. Cela elimine les silos de donnees et les duplications. Toutes les workloads Fabric (Spark, SQL, Power BI) accedent aux memes donnees via OneLake.
Quand privilegier Azure Databricks par rapport a Synapse Spark ?
Privilegiez Databricks quand vous avez des besoins avances en ML (MLflow, Feature Store), des workloads Spark lourds necessitant Photon (3-8x plus rapide), un besoin de gouvernance mature (Unity Catalog), ou du streaming complexe (Delta Live Tables). Privilegiez Synapse quand vous etes 100% ecosysteme Microsoft, que vos besoins Spark sont simples, ou que vous voulez une solution integree avec SQL Pools et Data Factory.

TOGAF pour Data Architects

50 min Intermediaire

Objectifs de la lecon

  • Comprendre le framework TOGAF et son Architecture Development Method (ADM)
  • Appliquer le cycle ADM specifiquement a l'architecture de donnees
  • Maitriser le Content Metamodel et les Building Blocks de TOGAF
  • Mettre en place un cadre de gouvernance architecturale

TOGAF est souvent percu comme un framework bureaucratique et lourd. Et c'est vrai si vous essayez de tout appliquer a la lettre. Mais en tant que Data Architect, vous n'avez besoin que de 20% de TOGAF pour couvrir 80% de vos besoins. Le cycle ADM vous donne une methode structuree pour passer du besoin metier a l'architecture technique. Le Content Metamodel vous donne un langage commun avec les enterprise architects. Et le framework de gouvernance vous donne la legitimite pour imposer des standards. Mon conseil : adoptez TOGAF comme une boite a outils, pas comme une bible.

Le Framework TOGAF

TOGAF (The Open Group Architecture Framework) est le framework d'architecture d'entreprise le plus utilise au monde, adopte par plus de 80% des entreprises du Fortune 500. Il fournit une methode structuree pour concevoir, planifier, implementer et gouverner une architecture d'entreprise.

Les 4 domaines d'architecture TOGAF

Business Architecture : Strategie metier, organisation, processus, gouvernance.
Data Architecture : Structure des donnees, modeles, flux, gouvernance des donnees.
Application Architecture : Applications individuelles, interactions, integration.
Technology Architecture : Infrastructure, reseaux, plateformes techniques.
Le Data Architect opere principalement dans le domaine Data, mais doit comprendre les trois autres pour aligner ses decisions.

Le Cycle ADM (Architecture Development Method)

L'ADM est le coeur de TOGAF. C'est un cycle iteratif en 8 phases (plus une phase preliminaire et la gestion des exigences au centre) qui guide la creation d'une architecture d'entreprise.

Cycle ADM de TOGAF applique a la Data Architecture
                        +-------------------+
                        |   Preliminaire    |
                        | (Cadrage, outils, |
                        |  principes)       |
                        +---------+---------+
                                  |
                        +---------v---------+
                        |  A. Vision        |
                        |  Architecture     |
                        |  (Objectifs data) |
                        +---------+---------+
                                  |
              +-------------------+-------------------+
              |                                       |
    +---------v---------+               +-------------v-----+
    |  B. Architecture  |               |  C. Architecture   |
    |  Business         |               |  Systemes Info     |
    |  (Processus data) |               |  (Data + Applis)   |
    +---------+---------+               +---------+----------+
              |                                   |
              +-------------------+-------------------+
                                  |
                        +---------v---------+
                        |  D. Architecture  |
                        |  Technologique    |
                        |  (Infrastructure) |
                        +---------+---------+
                                  |
                        +---------v---------+
                +-------| E. Opportunites   |
                |       |  & Solutions      |--------+
                |       +---------+---------+        |
                |                                    |
      +---------v---------+               +----------v--------+
      |  F. Planning      |               |  G. Gouvernance   |
      |  Migration        |               |  Implementation   |
      +---------+---------+               +---------+---------+
                |                                   |
                +-------------------+-------------------+
                                    |
                          +---------v---------+
                          |  H. Gestion du    |
                          |  Changement       |
                          +-------------------+

                    +---------------------------+
                    | CENTRE : Gestion des      |
                    | Exigences (Requirements    |
                    | Management) - en continu   |
                    +---------------------------+

ADM applique a un projet Data Platform

Voici comment appliquer concretement chaque phase ADM a la conception d'une Data Platform cloud :

Phase ADMApplication DataLivrables cles
PreliminaireDefinir les principes data, le scope, l'equipe architecturePrincipes d'architecture data, charte du comite data
A. VisionAligner la strategie data sur la strategie businessData Strategy document, architecture vision statement
B. BusinessCartographier les processus metier consommateurs de donneesCatalogue de processus metier, data use cases
C. SystemesConcevoir les modeles de donnees et les fluxModeles conceptuels/logiques, data flow diagrams, data catalog
D. TechnologieChoisir la plateforme cloud, les services, l'infrastructureArchitecture de reference, decision records (ADR)
E. OpportunitesIdentifier les projets prioritaires et les quick winsPortfolio de projets data, roadmap priorisee
F. MigrationPlanifier la migration des donnees et la coexistencePlan de migration 6R, strategie de coexistence, rollback plan
G. GouvernanceSuperviser l'implementation, valider la conformiteArchitecture compliance reviews, deviation requests
H. ChangementGerer les evolutions post-deploiementChange requests, impact assessments, updated architecture

Content Metamodel et Building Blocks

Le Content Metamodel de TOGAF definit les entites et relations que toute architecture doit documenter. Pour le Data Architect, les entites cles sont :

Entites du Metamodel pour la Data Architecture

Data Entity : Concept metier modelise en donnees (Client, Commande, Produit).
Logical Data Component : Regroupement logique d'entites (Domaine Client, Domaine Finance).
Physical Data Component : Implementation physique (table BigQuery, topic Kafka, fichier S3).
Application Component : Application qui produit ou consomme des donnees.
Technology Component : Infrastructure supportant les donnees (cluster Spark, instance Redshift).
Ces entites doivent etre tracees depuis le besoin metier jusqu'a l'implementation technique.

YAML - Architecture Building Block (ABB) pour Data Platform
# Architecture Building Block: Ingestion Layer
building_block:
  name: "Data Ingestion Layer"
  type: "Architecture Building Block (ABB)"
  domain: "Data Architecture"
  description: >
    Composant d'architecture responsable de l'extraction
    des donnees depuis les systemes sources et de leur
    chargement dans le Data Lake en couche Bronze.

  capabilities:
    - Batch ingestion (schedules, full/incremental)
    - Change Data Capture (CDC) temps reel
    - API ingestion (REST, GraphQL)
    - File ingestion (SFTP, S3, GCS)

  quality_attributes:
    - Exactly-once delivery guarantee
    - Schema evolution support
    - Retry and dead-letter queue
    - Monitoring and alerting

  solution_building_blocks:  # SBB = implementations concretes
    aws: "AWS Glue + DMS + Kinesis Firehose"
    gcp: "Datastream + Pub/Sub + Cloud Data Fusion"
    azure: "Azure Data Factory + Event Hubs"

  governance:
    owner: "Data Platform Team"
    review_cycle: "Trimestriel"
    compliance: ["RGPD", "SOC2"]

Gouvernance architecturale

TOGAF propose un cadre de gouvernance qui donne au Data Architect les outils pour imposer des standards, valider les decisions et gerer les derogations.

Mise en place d'un Architecture Review Board (ARB)

Vous devez creer un comite de revue architecturale pour votre Data Platform. Definissez :

  • La composition du comite (qui sont les membres votants ?)
  • Les criteres declenchant une revue (seuil de cout, impact sur les donnees sensibles, nouveau service cloud)
  • Le processus de decision (unanimite, majorite, droit de veto du Lead Architect ?)
  • Le modele de "deviation request" pour les exceptions aux standards
  • La frequence des revues et le processus d'escalade

ING Bank : TOGAF applique a la transformation data

ING, le groupe bancaire neerlandais, a utilise TOGAF pour structurer sa transformation data a l'echelle de 40 pays :

  • Phase A (Vision) : Definition d'une "One Data Platform" unifiee pour remplacer 200+ silos de donnees
  • Phase C (Data Architecture) : Modelisation d'un domaine data unifie avec 500+ entites metier standardisees
  • Phase D (Technologie) : Selection d'une architecture multi-cloud (AWS + Azure) avec des building blocks reutilisables
  • Phase G (Gouvernance) : Architecture Review Board global avec des representants de chaque pays
  • Resultat : reduction de 60% des initiatives data redondantes et acceleration du time-to-market des produits data de 12 a 3 mois

TOGAF comme frein a l'innovation

Appliquer TOGAF de maniere rigide et bureaucratique, en exigeant une documentation exhaustive pour le moindre changement. Resultat : les equipes contournent le processus, creent des architectures "shadow IT", et le framework perd toute credibilite.

Solution : Adoptez une approche "lightweight TOGAF" : appliquez les phases ADM avec des livrables legers (ADR d'une page plutot que des documents de 50 pages), automatisez la documentation via le code (architecture-as-code), et differenciez le niveau de gouvernance selon le risque (fast-track pour les changements mineurs, revue complete pour les decisions structurantes).

Quelles sont les 4 domaines d'architecture TOGAF ?
Business Architecture (strategie, processus), Data Architecture (modeles, flux, gouvernance des donnees), Application Architecture (applications, integrations), Technology Architecture (infrastructure, plateformes). Le Data Architect travaille principalement sur le domaine Data mais doit comprendre les interactions avec les 3 autres domaines.
Quelle est la difference entre un ABB et un SBB dans TOGAF ?
Un Architecture Building Block (ABB) definit les capacites et exigences d'un composant de maniere agnostique de la technologie (ex: "Data Ingestion Layer" avec ses capacites batch/streaming). Un Solution Building Block (SBB) est l'implementation concrete d'un ABB avec des technologies specifiques (ex: "AWS Glue + Kinesis Firehose"). L'ABB est reutilisable ; le SBB est specifique a un contexte.

Enterprise Architecture

55 min Avance

Objectifs de la lecon

  • Comprendre le Zachman Framework et son application a l'architecture de donnees
  • Maitriser l'architecture Data Mesh : principes, topologies et mise en oeuvre
  • Appliquer le Domain-Driven Design (DDD) a la modelisation data
  • Comparer les approches centralisees, federees et Data Mesh

L'Enterprise Architecture pour la data, c'est l'art de creer des systemes qui survivent aux reorganisations, aux fusions-acquisitions et aux changements de strategie. Le Data Mesh est la tendance la plus discutee depuis 2020, mais attention : ce n'est pas pour tout le monde. J'ai vu des organisations de 50 personnes essayer d'implementer un Data Mesh avec 3 domains et 2 data engineers. Resultat : une complexite organisationnelle disproportionnee. Le Data Mesh est pertinent quand vous avez 10+ domaines metier, 50+ personnes dans la data, et une maturite organisationnelle suffisante.

Le Zachman Framework

Le Zachman Framework, cree par John Zachman en 1987, est une matrice 6x6 qui structure la description d'une entreprise en croisant les perspectives (lignes) avec les interrogations fondamentales (colonnes). C'est un outil de classification, pas une methodologie.

PerspectiveWhat (Donnees)How (Processus)Where (Reseau)Who (Personnes)When (Temps)Why (Motivation)
Scope (Planificateur)Inventaire des entites metierListe des processusSites et localisationsRoles et organisationsEvenements metierObjectifs strategiques
Business (Proprietaire)Modele conceptuelModele de processusLogistique metierWorkflow metierPlanning metierBusiness plan
System (Concepteur)Modele logique de donneesArchitecture applicativeArchitecture distribueeArchitecture des rolesArchitecture temporelleRegles metier
Technology (Developpeur)Modele physiqueDesign systemeArchitecture technologiqueInterface utilisateurDesign temporelDesign des regles
Detail (Sous-traitant)Definitions de donneesProgrammesArchitecture reseauArchitecture securiteDefinitions temporellesDefinitions des regles
Enterprise (Utilisateur)Donnees operationnellesSysteme operationnelReseau operationnelOrganisation operationnellePlanning operationnelStrategie operationnelle

Zachman pour le Data Architect

Utilisez la colonne "What" du Zachman Framework comme guide pour vos livrables data : du scope (quelles entites metier existent ?) au modele physique (quelles tables, partitions, index ?). Chaque ligne doit etre coherente avec les autres : si une entite "Client" existe au niveau conceptuel, elle doit se retrouver dans le modele logique et physique.

Data Mesh : les 4 principes fondamentaux

Le Data Mesh, propose par Zhamak Dehghani en 2019, est un paradigme organisationnel et architectural qui decentralise la propriete des donnees vers les equipes domaine. Il repose sur 4 principes fondamentaux :

Les 4 principes du Data Mesh
  +-----------------------------------------------------------------------+
  |                        DATA MESH                                       |
  |                                                                       |
  |  +-------------------------------+  +-------------------------------+ |
  |  | 1. DOMAIN OWNERSHIP           |  | 2. DATA AS A PRODUCT          | |
  |  |                               |  |                               | |
  |  | Chaque domaine metier est     |  | Les donnees exposees sont     | |
  |  | responsable de ses donnees    |  | traitees comme un produit :   | |
  |  | de bout en bout (production,  |  | SLA, documentation, qualite,  | |
  |  | qualite, exposition).         |  | decouverte, interoperabilite. | |
  |  +-------------------------------+  +-------------------------------+ |
  |                                                                       |
  |  +-------------------------------+  +-------------------------------+ |
  |  | 3. SELF-SERVE DATA PLATFORM   |  | 4. FEDERATED COMPUTATIONAL   | |
  |  |                               |  |    GOVERNANCE                 | |
  |  | Plateforme en self-service    |  | Gouvernance federee : regles  | |
  |  | qui abstrait la complexite    |  | globales definies par un      | |
  |  | infra et permet aux domaines  |  | comite, appliquees localement | |
  |  | de deployer sans dependance.  |  | par chaque domaine.           | |
  |  +-------------------------------+  +-------------------------------+ |
  +-----------------------------------------------------------------------+

Architecture Data Mesh en pratique

Topologie Data Mesh
  DOMAINE: VENTES                DOMAINE: MARKETING            DOMAINE: FINANCE
  +---------------------+       +---------------------+       +---------------------+
  | Data Product:       |       | Data Product:       |       | Data Product:       |
  | "Orders"            |       | "Campaigns"         |       | "Revenue"           |
  |                     |       |                     |       |                     |
  | Owner: Sales Team   |       | Owner: Mktg Team    |       | Owner: Finance Team |
  | SLA: 99.9%, <1h lag|       | SLA: 99.5%, <4h lag|       | SLA: 99.99%, exact  |
  |                     |       |                     |       |                     |
  | +-------+ +-------+|       | +-------+ +-------+|       | +-------+ +-------+|
  | |Bronze | |Silver ||       | |Bronze | |Silver ||       | |Bronze | |Silver ||
  | |       | |       ||       | |       | |       ||       | |       | |       ||
  | +-------+ +-------+|       | +-------+ +-------+|       | +-------+ +-------+|
  | +-------+          |       | +-------+          |       | +-------+          |
  | | Gold  | (expose) |       | | Gold  | (expose) |       | | Gold  | (expose) |
  | | API   |==========|=======|=| API   |==========|=======|=| API   |          |
  | +-------+          |       | +-------+          |       | +-------+          |
  +---------------------+       +---------------------+       +---------------------+
           |                            |                            |
           +----------------------------+----------------------------+
                                        |
                    +-------------------v-------------------+
                    |    SELF-SERVE DATA PLATFORM            |
                    |    (Infrastructure as a Service)       |
                    |                                       |
                    | - Data Product template (Terraform)   |
                    | - CI/CD pipelines automatises         |
                    | - Monitoring & observabilite unifie   |
                    | - Data Catalog federe                 |
                    | - Schema Registry                     |
                    +---------------------------------------+
                                        |
                    +-------------------v-------------------+
                    |    FEDERATED GOVERNANCE                |
                    |                                       |
                    | - Standards de nommage globaux         |
                    | - Politiques de qualite minimales      |
                    | - Interoperabilite des schemas         |
                    | - Classification & securite           |
                    +---------------------------------------+

Domain-Driven Design (DDD) pour la Data

Le DDD, theorise par Eric Evans, est fondamental pour le Data Mesh car il definit comment decouper les domaines et modeliser les donnees autour du langage metier (Ubiquitous Language).

Concepts DDD essentiels pour le Data Architect

Bounded Context : Perimetre au sein duquel un modele de donnees est coherent et non ambigu. "Client" peut signifier des choses differentes en Ventes (acheteur) et en Support (demandeur). Chaque bounded context a son propre modele.
Aggregate : Groupe d'entites traitees comme une unite de coherence. Une Commande avec ses Lignes de commande forme un aggregate.
Domain Event : Evenement metier significatif (CommandeCreee, PaiementRecu). Base de l'architecture event-driven et du CDC.
Anti-Corruption Layer (ACL) : Interface de traduction entre deux bounded contexts pour eviter la contamination des modeles.

Architecture Centralisee (Data Warehouse)

  • Equipe data centrale proprietaire de toutes les donnees
  • Un seul modele de donnees enterprise-wide
  • Controle fort mais goulot d'etranglement
  • Adapte aux petites/moyennes organisations (<500 personnes)
  • Time-to-market : semaines a mois

Architecture Data Mesh

  • Chaque domaine est proprietaire de ses data products
  • Modeles par domaine avec interoperabilite
  • Autonomie des equipes mais complexite de coordination
  • Adapte aux grandes organisations (500+ personnes, 10+ domaines)
  • Time-to-market : jours a semaines

Zalando : Implementation d'un Data Mesh

Zalando, le geant europeen du e-commerce (50 millions de clients actifs), est l'un des exemples les plus documentes d'implementation Data Mesh :

  • Decoupage en 15+ domaines autonomes (Fashion, Logistics, Payments, Marketing, etc.)
  • Chaque domaine publie ses data products via une plateforme self-serve basee sur AWS
  • Data Product Canvas : chaque data product est documente avec un canvas standardise (owner, SLA, schema, qualite)
  • Governance federee avec un Data Council regroupant les data leads de chaque domaine
  • Resultat : passage de 6 mois a 2 semaines pour rendre un nouveau jeu de donnees disponible en production

MidSize Corp (anonymise) : Data Mesh premature

Une entreprise de 300 employes avec une equipe data de 8 personnes a tente d'implementer un Data Mesh complet :

  • Definition de 12 "domaines" avec 12 "data product owners"... mais seulement 8 data engineers pour les supporter
  • Chaque domaine devait construire et operer son propre pipeline, mais les competences techniques etaient concentrees dans l'equipe data centrale
  • La plateforme self-serve n'etait pas assez mature : les domaines passaient 80% de leur temps sur l'infrastructure au lieu de la valeur metier
  • Apres 12 mois, retour a une architecture centralisee avec des "domaines virtuels" (domain-oriented mais equipe centralisee)

Lecon cle : le Data Mesh necessite une maturite organisationnelle et technique. Commencez par un modele "Data Mesh lite" (ownership organisationnel decentralise, execution technique centralisee) avant de decentraliser completement.

Le Data Mesh sans plateforme self-serve

Decentraliser la propriete des donnees sans fournir une plateforme self-serve mature revient a demander a chaque equipe de reinventer la roue. Chaque domaine cree son propre pipeline avec des technologies differentes, des standards differents, et aucune interoperabilite. On obtient des silos distribues au lieu de silos centralises : c'est pire.

Solution : Investissez d'abord dans la plateforme self-serve (templates de data products, CI/CD, monitoring, catalogue). Quand les domaines peuvent deployer un data product en moins d'une journee sans aide, vous etes prets pour le Data Mesh.

Lab : Cartographie d'un Data Mesh

Exercice pratique de decomposition en domaines pour une entreprise fictive de retail omnicanal.

Etape 1 : Identifier les Bounded Contexts

L'entreprise RetailCo a les activites suivantes : vente en magasin, e-commerce, programme de fidelite, supply chain, finance, RH. Identifiez les bounded contexts et les entites principales de chacun. Notez les entites partagees (Client, Produit) et comment elles different entre les contextes.

Etape 2 : Definir les Data Products

Pour chaque domaine identifie, definissez au moins un data product expose. Specifiez : le nom, la description, le SLA (fraicheur, disponibilite), le schema (colonnes cles), le format d'exposition (API, table SQL, fichier Parquet) et les consommateurs principaux.

Etape 3 : Concevoir la Self-Serve Platform

Dessinez l'architecture de la plateforme self-serve qui supportera ces data products. Incluez : le choix du cloud provider et les services utilises, le template Terraform/Pulumi pour un data product standard, le pipeline CI/CD, le monitoring et les SLA.

Quels sont les 4 principes fondamentaux du Data Mesh ?
1. Domain Ownership : chaque domaine metier est responsable de ses donnees de bout en bout. 2. Data as a Product : les donnees exposees sont traitees comme un produit (SLA, qualite, documentation). 3. Self-Serve Data Platform : plateforme qui abstrait la complexite infrastructure. 4. Federated Computational Governance : regles globales definies centralement, appliquees localement par les domaines.
Qu'est-ce qu'un Bounded Context en DDD et pourquoi est-ce crucial pour la data ?
Un Bounded Context est un perimetre au sein duquel un modele de donnees est coherent et non ambigu. Par exemple, "Client" peut signifier un acheteur en Ventes et un ticket en Support. Chaque bounded context a son propre modele, evitant les ambiguites. C'est crucial pour la data car cela definit les limites des data products dans un Data Mesh et evite de forcer un modele unique artificiel.
Quand le Data Mesh est-il adapte et quand faut-il l'eviter ?
Le Data Mesh est adapte quand l'organisation a 10+ domaines metier distincts, 50+ personnes dans la data, une maturite DevOps et une plateforme self-serve. Il faut l'eviter dans les petites equipes (<20 personnes data), les organisations sans culture DevOps, ou quand la plateforme self-serve n'est pas mature. Alternative : "Data Mesh lite" avec ownership decentralise mais execution centralisee.

7. Security Architecture pour Data Platforms

40 min Avance

Objectifs

  • Comprendre et appliquer le modele Zero Trust aux architectures data
  • Maitriser les strategies de chiffrement au repos et en transit
  • Implementer les modeles RBAC et ABAC pour le controle d'acces
  • Concevoir des strategies de data masking et tokenisation
  • Mettre en place un audit logging robuste et conforme GDPR/SOC2

La securite ne doit jamais etre une reflexion apres coup. J'ai vu des entreprises perdre des millions a cause de breches de donnees qui auraient pu etre evitees avec une architecture Zero Trust des le depart. Un Data Architect doit penser securite a chaque couche de la stack, du stockage a la consommation.

Le Modele Zero Trust pour les Donnees

Le Zero Trust repose sur un principe fondamental : "Ne jamais faire confiance, toujours verifier." Dans le contexte des data platforms, cela signifie que chaque acces aux donnees doit etre authentifie, autorise et chiffre, independamment de l'origine de la requete.

Les 5 Piliers du Zero Trust Data

  • Verification explicite : Chaque requete est authentifiee via identite, device, localisation et comportement
  • Moindre privilege : Acces strictement limite au minimum necessaire pour chaque role
  • Microsegmentation : Les donnees sont isolees en zones de securite granulaires
  • Chiffrement omnipresent : Donnees chiffrees au repos, en transit et en cours de traitement
  • Surveillance continue : Monitoring temps reel de tous les acces et anomalies
Architecture Zero Trust - Data Platform
  Utilisateur/Service
        |
   [Identity Provider]     ← MFA + SSO (Okta, Azure AD)
        |
   [API Gateway]           ← Rate Limiting + WAF
        |
   [Policy Engine]         ← OPA / Cedar / Rego
        |
   β”Œβ”€β”€β”€β”€β”΄β”€β”€β”€β”€β”
   β”‚  RBAC   β”‚  +  ABAC    ← Controle d'acces hybride
   β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”˜
        |
   [Data Catalog]          ← Classification automatique
        |
   β”Œβ”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
   β”‚  Data Platform       β”‚
   β”‚  β”Œβ”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”      β”‚
   β”‚  β”‚Lakeβ”‚ β”‚ DWHβ”‚      β”‚  ← Chiffrement AES-256
   β”‚  β””β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”˜      β”‚
   β”‚  [Audit Log]         β”‚  ← Journalisation complete
   β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Chiffrement au Repos et en Transit

Le chiffrement est la premiere ligne de defense contre les acces non autorises. Une strategie de chiffrement complete couvre trois etats des donnees : au repos, en transit et en cours de traitement.

TypeMethodeStandardCas d'usage
Au reposAES-256-GCMFIPS 140-2S3, BigQuery, ADLS
En transitTLS 1.3PCI-DSSAPIs, replication, streaming
En traitementConfidential ComputingSGX/SEVDonnees sensibles en memoire
ClesKMS / HSMFIPS 140-3Gestion centralisee des cles
Terraform - KMS & Chiffrement S3
# Cle KMS pour chiffrement des donnees
resource "aws_kms_key" "data_platform_key" {
  description             = "Cle de chiffrement Data Platform"
  deletion_window_in_days = 30
  enable_key_rotation     = true  # Rotation automatique annuelle

  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [
      {
        Sid    = "AllowKeyAdmins"
        Effect = "Allow"
        Principal = { AWS = "arn:aws:iam::role/KeyAdmin" }
        Action    = "kms:*"
        Resource  = "*"
      },
      {
        Sid    = "AllowDataTeamEncrypt"
        Effect = "Allow"
        Principal = { AWS = "arn:aws:iam::role/DataEngineer" }
        Action = [
          "kms:Encrypt", "kms:Decrypt",
          "kms:GenerateDataKey"
        ]
        Resource = "*"
      }
    ]
  })
}

# Bucket S3 avec chiffrement obligatoire
resource "aws_s3_bucket_server_side_encryption_configuration" "data_lake" {
  bucket = aws_s3_bucket.data_lake.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm     = "aws:kms"
      kms_master_key_id = aws_kms_key.data_platform_key.arn
    }
    bucket_key_enabled = true  # Reduit les appels KMS
  }
}

RBAC vs ABAC : Controle d'Acces

Le choix entre RBAC (Role-Based Access Control) et ABAC (Attribute-Based Access Control) depend de la granularite requise. En pratique, une approche hybride est souvent la meilleure solution.

RBAC - Role-Based

  • Roles predeterminΓ©s : analyst, engineer, admin
  • Simple a implementer et auditer
  • Ideal pour les petites equipes
  • Limites : explosion des roles a grande echelle
  • Exemple : Un data analyst peut lire les tables gold

ABAC - Attribute-Based

  • Policies basees sur des attributs dynamiques
  • Granularite fine : departement, projet, sensibilite
  • Scalable pour les grandes organisations
  • Complexite accrue de gestion
  • Exemple : Acces si departement=finance ET classification<confidentiel
Rego (Open Policy Agent)
# Politique ABAC avec OPA pour acces aux donnees
package data.access

default allow = false

# Regle 1 : Les data engineers accedent a toutes les tables non-PII
allow {
    input.role == "data_engineer"
    input.table_classification != "PII"
    input.action == "SELECT"
}

# Regle 2 : Les analystes finance accedent aux tables finance
allow {
    input.role == "analyst"
    input.department == "finance"
    input.table_domain == "finance"
    input.action == "SELECT"
    not contains_pii(input.columns)
}

# Regle 3 : Masquage automatique des colonnes PII
mask_columns[col] {
    input.role != "data_privacy_officer"
    col := input.columns[_]
    col.classification == "PII"
}

contains_pii(columns) {
    columns[_].classification == "PII"
}

Data Masking et Tokenisation

Le data masking et la tokenisation sont essentiels pour proteger les donnees sensibles tout en preservant leur utilite analytique. Plusieurs techniques existent selon le niveau de protection requis.

Techniques de Masquage

  • Masquage statique : Remplacement irreversible dans les environnements de dev/test
  • Masquage dynamique : Transformation a la volee selon le role de l'utilisateur (ex: Dynamic Data Masking dans Snowflake)
  • Tokenisation : Remplacement par un token reversible stocke dans un coffre-fort
  • K-anonymite : Generalisation des quasi-identifiants pour garantir au moins k individus identiques
  • Differential Privacy : Ajout de bruit statistique pour proteger les individus dans les agregats

Audit Logging et Conformite

Un systeme d'audit robuste est indispensable pour la conformite GDPR, SOC2, HIPAA et PCI-DSS. Chaque acces aux donnees doit etre journalise, immutable et analysable.

JSON - Schema d'Audit Log
{
  "event_id": "evt_2025_0612_abc123",
  "timestamp": "2025-06-12T14:32:05.123Z",
  "actor": {
    "user_id": "usr_42",
    "role": "data_analyst",
    "department": "marketing",
    "ip_address": "10.0.1.42",
    "auth_method": "SSO_MFA"
  },
  "action": {
    "type": "DATA_READ",
    "resource": "gold.customers",
    "columns_accessed": ["name", "email_masked", "segment"],
    "columns_masked": ["email", "phone"],
    "row_count": 15420,
    "query_hash": "sha256:abc123..."
  },
  "context": {
    "purpose": "campaign_analysis",
    "data_classification": "CONFIDENTIAL",
    "policy_applied": "marketing_read_v3",
    "consent_verified": true
  },
  "result": "ALLOWED"
}

Exigences GDPR pour l'Audit

Le RGPD impose la traΓ§abilite complete des acces aux donnees personnelles. Vous devez pouvoir repondre a la question : "Qui a accede a quelles donnees personnelles, quand, pourquoi et avec quel consentement ?" Les logs doivent etre conserves au minimum 3 ans et etre immutables (Write Once Read Many).

Capital One - Breach 2019 et Lecons Apprises

En 2019, Capital One a subi une des plus grandes breches de donnees bancaires : 106 millions de dossiers clients exposes. La cause ? Un WAF mal configure sur AWS qui a permis un SSRF (Server-Side Request Forgery) donnant acces aux metadata IAM.

  • Cause racine : Role IAM trop permissif attache a un WAF expose publiquement
  • Impact : 80 000 numeros de comptes bancaires, 140 000 numeros de securite sociale
  • Lecon 1 : Appliquer le principe du moindre privilege a CHAQUE composant
  • Lecon 2 : Bloquer l'acces aux metadata d'instance (IMDSv2 obligatoire)
  • Lecon 3 : Monitorer les requetes anormales en temps reel avec des alertes automatiques
  • Resultat : Amende de 80M$ et refonte complete de l'architecture de securite

La Securite comme Reflexion Apres Coup

L'une des erreurs les plus courantes est de concevoir la data platform d'abord, puis de "rajouter la securite" ensuite. Ce pattern conduit systematiquement a :

  • Des credentials en dur dans le code source (detectees dans 15% des repos publics selon GitGuardian)
  • Des buckets S3 publics par defaut (cause de 30% des breches cloud)
  • Des roles IAM avec des permissions wildcard (*) "temporaires" qui deviennent permanentes
  • Aucune rotation des cles de chiffrement ni des secrets

Solution : Adopter le "Security by Design" - integrer la securite dans chaque decision architecturale des la phase de conception, pas en fin de projet.

Scenario : Banque Europeenne sous DORA

Vous etes Data Architect pour une banque europeenne soumise a la reglementation DORA (Digital Operational Resilience Act). Votre mission : concevoir une data platform conforme avec :

  • Chiffrement bout en bout avec gestion des cles on-premise (HSM)
  • Audit trail immutable avec retention de 7 ans
  • Tests de resilience operationnelle numerique trimestriels
  • Isolation des donnees par juridiction (data residency EU)
  • Capacite de reponse aux incidents en moins de 4 heures

Approche recommandee : Architecture multi-region EU avec chiffrement BYOK (Bring Your Own Key), audit centralise sur un SIEM dedie, et exercices de red team reguliers sur les acces data.

Quelle est la difference entre le chiffrement CMK et BYOK dans un contexte cloud ?
Le CMK (Customer Managed Key) est une cle geree par le client mais stockee dans le KMS du cloud provider. Le BYOK (Bring Your Own Key) permet d'importer une cle generee dans un HSM on-premise vers le KMS cloud, offrant un controle total sur le cycle de vie de la cle. BYOK est prefere pour les reglementations strictes (banque, sante) car le client peut revoquer la cle a tout moment.
Qu'est-ce que le principe de "defense en profondeur" applique aux data platforms ?
La defense en profondeur consiste a superposer plusieurs couches de securite independantes : reseau (VPC, firewalls), identite (IAM, MFA), application (API Gateway, WAF), donnees (chiffrement, masking), et monitoring (SIEM, alertes). Si une couche est compromise, les autres continuent de proteger les donnees. C'est le fondement du Zero Trust applique aux architectures data.

8. Quiz - Design de Data Platforms

20 min Evaluation

Objectifs

  • Valider vos connaissances sur les architectures cloud data platform
  • Verifier votre comprehension des services AWS, GCP et Azure
  • Tester votre maitrise des patterns Data Lakehouse
  • Evaluer votre capacite a concevoir des architectures securisees

Ce quiz couvre l'ensemble du Module 4.1. Prenez le temps de bien lire chaque question et toutes les options avant de repondre. Un score de 75% ou plus indique une bonne maitrise des concepts. Si vous obtenez moins de 6 bonnes reponses, revisitez les lecons 1 a 7 avant de continuer.

Quiz Design de Data Platforms

Q1. Quel est le principal avantage d'une architecture Data Lakehouse par rapport a un Data Lake traditionnel ?

Un cout de stockage inferieur
La combinaison de la flexibilite du Data Lake avec les garanties ACID et la gouvernance d'un Data Warehouse
Une vitesse de requete toujours superieure
L'elimination complete du besoin de transformation des donnees

Bonne reponse ! Le Data Lakehouse combine le stockage ouvert et flexible du Data Lake (fichiers Parquet/ORC) avec les transactions ACID, le schema enforcement et la gouvernance d'un Data Warehouse, grace a des formats de table comme Delta Lake, Apache Iceberg ou Apache Hudi.

Q2. Quel service AWS est recommande pour orchestrer des pipelines de donnees complexes avec des dependances entre taches ?

AWS Lambda
Amazon Kinesis
AWS Step Functions combine avec Amazon MWAA (Managed Airflow)
Amazon SQS

Bonne reponse ! AWS Step Functions permet d'orchestrer des workflows complexes avec des machines a etats, tandis qu'Amazon MWAA (Managed Workflows for Apache Airflow) offre une orchestration basee sur DAGs Python, ideale pour les pipelines data avec des dependances multiples.

Q3. Dans une architecture GCP, quel service est le plus adapte pour du traitement stream en temps reel avec exactly-once semantics ?

Google Cloud Dataflow (Apache Beam) avec Pub/Sub
Google Cloud Functions
Google Cloud Composer
Google Cloud Storage triggers

Bonne reponse ! Google Cloud Dataflow, base sur Apache Beam, offre un traitement unifie batch et stream avec des garanties exactly-once. Combine avec Pub/Sub pour l'ingestion, c'est la solution de reference pour le streaming temps reel sur GCP.

Q4. Quel est le role du format de table Apache Iceberg dans une architecture Lakehouse ?

Remplacer les bases de donnees relationnelles
Fournir un format de table ouvert avec time-travel, schema evolution, partition evolution et transactions ACID sur des fichiers stockes dans un data lake
Compresser les fichiers Parquet
Gerer l'authentification des utilisateurs du data lake

Bonne reponse ! Apache Iceberg est un format de table ouvert qui ajoute des capacites de Data Warehouse (ACID, time-travel, schema evolution, partition pruning) aux fichiers stockes dans un data lake. Il est supporte par Spark, Trino, Flink, Dremio et de plus en plus de moteurs.

Q5. Quelle approche de securite est recommandee pour une data platform cloud moderne ?

Securite perimetrique avec un firewall unique
Faire confiance au reseau interne de l'entreprise
Zero Trust avec chiffrement bout en bout, RBAC/ABAC, audit logging et defense en profondeur
Securite uniquement au niveau applicatif

Bonne reponse ! Le modele Zero Trust ("ne jamais faire confiance, toujours verifier") est le standard pour les data platforms cloud. Il combine chiffrement omnipresent, controle d'acces granulaire (RBAC+ABAC), audit logging immutable et defense en profondeur a chaque couche.

Q6. Quel est l'avantage principal de Microsoft Fabric par rapport a une architecture Azure traditionnelle avec plusieurs services separes ?

Un cout systematiquement inferieur
Une plateforme unifiee SaaS avec OneLake, compute partage et integration native de tous les workloads data (ingestion, engineering, science, BI)
Une meilleure compatibilite avec les outils open source
L'absence de besoin de gouvernance des donnees

Bonne reponse ! Microsoft Fabric unifie l'ensemble des workloads data dans une seule plateforme SaaS. OneLake fournit un stockage unique base sur Delta Lake / Parquet, le compute est partage via des Capacity Units, et tous les personas (engineer, analyst, scientist) travaillent dans un environnement integre.

Q7. Dans le cadre TOGAF, quelle phase est la plus pertinente pour un Data Architect qui concoit une data platform ?

Phase A : Architecture Vision
Phase C : Information Systems Architecture (sous-phase Data Architecture)
Phase E : Opportunities and Solutions
Phase H : Architecture Change Management

Bonne reponse ! La Phase C de TOGAF couvre l'Architecture des Systemes d'Information, avec une sous-phase dediee a la Data Architecture. C'est dans cette phase que le Data Architect definit les modeles de donnees, les flux, le stockage et la gouvernance de la data platform.

Q8. Quel pattern est recommande pour migrer progressivement un data warehouse on-premise vers le cloud ?

Big Bang : tout migrer en une seule fois
Strangler Fig Pattern avec une couche de virtualisation pour basculer progressivement les workloads
Reconstruire entierement sans reutiliser les modeles existants
Dupliquer indefiniment les donnees dans les deux environnements

Bonne reponse ! Le Strangler Fig Pattern permet une migration progressive en routant graduellement les requetes de l'ancien systeme vers le nouveau via une couche de virtualisation ou d'abstraction. Cela reduit les risques, permet des rollbacks et offre une validation progressive de chaque composant migre.

Conseil de revision

Si vous avez obtenu moins de 6 bonnes reponses sur 8, revisitez les lecons 1 a 7 avant de continuer vers le Module 4.2. Les concepts d'architecture cloud, de Lakehouse et de securite sont fondamentaux pour la suite.

9. Data Contracts - L'Accord Formel des Donnees

35 min Avance

Objectifs

  • Comprendre le concept de Data Contract et son role dans les architectures modernes
  • Maitriser la definition de schemas avec Protobuf et JSON Schema
  • Definir des SLAs de donnees (fraicheur, qualite, disponibilite)
  • Implementer le versioning et la gouvernance des contrats
  • Gerer l'ownership et la responsabilite des producteurs de donnees

Les Data Contracts sont probablement l'innovation la plus importante en architecture data depuis le Data Mesh. Avant les contrats, les pipelines cassaient constamment parce que les producteurs modifiaient les schemas sans prevenir les consommateurs. Un Data Contract transforme un accord implicite en une specification explicite, testable et versionnable. Uber, Airbnb et Netflix les ont adoptes avec des resultats spectaculaires.

Qu'est-ce qu'un Data Contract ?

Un Data Contract est un accord formel entre un producteur de donnees et ses consommateurs. Il definit precisement ce que le producteur s'engage a fournir : le schema, la qualite, la fraicheur, la disponibilite et les conditions d'evolution des donnees.

Les 6 Composants d'un Data Contract

  • Schema : Structure des donnees (colonnes, types, nullable, contraintes)
  • SLA : Garanties de fraicheur, disponibilite et latence
  • Qualite : Regles de validation (unicite, completude, domaine de valeurs)
  • Ownership : Equipe productrice responsable et contact d'escalade
  • Semantique : Description metier de chaque champ et de son interpretation
  • Evolution : Regles de versioning, deprecation et migration
Cycle de Vie d'un Data Contract
  Producteur                    Consommateur
      |                              |
      |  1. PROPOSE (Draft)          |
      |-----------------------------β†’|
      |                              |
      |  2. REVIEW (Feedback)        |
      |←-----------------------------|
      |                              |
      |  3. PUBLISH (v1.0.0)         |
      |-----------------------------β†’|
      |                              |
      |  4. MONITOR (SLA checks)     |
      |←- - - - - - - - - - - - - - β†’|
      |                              |
      |  5. EVOLVE (v1.1.0)          |
      |-----------------------------β†’|
      |                              |
      |  6. DEPRECATE (sunset v1.0)  |
      |-----------------------------β†’|

Schema Definition avec YAML

Le format le plus adopte pour les Data Contracts est le YAML, combine avec des specifications de schema en JSON Schema ou Protobuf. Voici un contrat complet :

YAML - Data Contract
dataContractSpecification: 0.9.3
id: urn:datacontract:checkout:orders
info:
  title: Orders Data Contract
  version: 1.2.0
  status: active
  description: |
    Contrat pour les donnees de commandes du domaine Checkout.
    Produit par l'equipe Checkout, consomme par Finance et Analytics.
  owner: team-checkout
  contact:
    name: Marie Dupont
    email: checkout-data@company.com
    slack: "#checkout-data-support"

servers:
  production:
    type: snowflake
    account: company.eu-west-1
    database: ANALYTICS
    schema: CHECKOUT

models:
  orders:
    description: Table des commandes validees
    type: table
    fields:
      order_id:
        type: string
        format: uuid
        required: true
        unique: true
        description: Identifiant unique de la commande
        pii: false
      customer_id:
        type: string
        required: true
        pii: true
        classification: confidential
        description: Identifiant du client (donnee PII)
      order_date:
        type: timestamp
        required: true
        description: Date et heure de la commande (UTC)
      total_amount:
        type: decimal
        precision: 10
        scale: 2
        required: true
        minimum: 0
        description: Montant total en euros TTC
      status:
        type: string
        required: true
        enum: [pending, confirmed, shipped, delivered, cancelled]
        description: Statut actuel de la commande

quality:
  type: SodaCL
  specification:
    checks for orders:
      - row_count > 0
      - duplicate_count(order_id) = 0
      - missing_percent(customer_id) < 0.1
      - invalid_percent(status) = 0
      - avg(total_amount) between 20 and 500
      - freshness(order_date) < 2h

sla:
  freshness: 2 hours
  availability: 99.9%
  latency: < 30 seconds (query p95)
  update_frequency: every 15 minutes

terms:
  usage: internal-analytics
  limitations: |
    Ne pas utiliser pour du marketing direct sans consentement.
    Les donnees PII doivent etre masquees en dehors du domaine Finance.
  billing: chargeback au domaine consommateur

Protobuf vs JSON Schema

Protobuf

  • Typage strict natif
  • Compatibilite avant/arriere par design
  • Serialisation binaire performante
  • Ideal pour les APIs et le streaming
  • Adopte par Uber, Google, Netflix
Protobuf
syntax = "proto3";
package checkout;

message Order {
  string order_id = 1;
  string customer_id = 2;
  google.protobuf.Timestamp order_date = 3;
  int64 total_amount_cents = 4;
  OrderStatus status = 5;

  enum OrderStatus {
    PENDING = 0;
    CONFIRMED = 1;
    SHIPPED = 2;
    DELIVERED = 3;
    CANCELLED = 4;
  }
}

JSON Schema

  • Lisible par les humains
  • Large ecosysteme d'outils
  • Validation flexible
  • Ideal pour les APIs REST et les fichiers
  • Standard ouvert largement adopte
JSON Schema
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "order_id": {
      "type": "string",
      "format": "uuid"
    },
    "total_amount": {
      "type": "number",
      "minimum": 0,
      "multipleOf": 0.01
    },
    "status": {
      "type": "string",
      "enum": ["pending","confirmed",
               "shipped","delivered",
               "cancelled"]
    }
  },
  "required": ["order_id","status"]
}

SLAs et Monitoring des Contrats

Les SLAs (Service Level Agreements) donnent aux consommateurs des garanties mesurables. Un bon SLA couvre quatre dimensions :

DimensionMetriqueSeuil TypiqueOutil de Monitoring
FraicheurTemps depuis la derniere mise a jour< 1h (near real-time)Monte Carlo, Elementary
DisponibiliteUptime du dataset99.9%Datadog, PagerDuty
Completude% de champs non-null requis> 99.5%Great Expectations, Soda
Conformite% de lignes valides selon le schema100%dbt tests, Contract tests

Uber - Implementation des Data Contracts a Grande Echelle

Uber a ete un pionnier dans l'adoption des Data Contracts pour gerer ses milliers de datasets internes. Face a des ruptures de pipeline constantes causees par des changements de schema non communiques, Uber a developpe une solution complete :

  • Probleme : Plus de 200 incidents de pipeline par mois dus a des changements de schema non coordonnes entre les 100+ equipes productrices
  • Solution : Plateforme "Databook" avec des contrats formels entre producteurs et consommateurs
  • Schema Registry : Registre centralise base sur Protobuf avec validation automatique a chaque changement
  • Breaking Change Detection : CI/CD qui detecte les changements incompatibles et bloque le deploiement
  • Resultat : Reduction de 85% des incidents de pipeline en 6 mois, delai de decouverte des problemes passe de jours a minutes

Pas de Versioning des Contrats

L'absence de versioning semantique (SemVer) dans les Data Contracts est une source majeure de dysfonctionnements :

  • Symptome : Un producteur ajoute une colonne NOT NULL et casse tous les consommateurs du jour au lendemain
  • Cause : Aucune distinction entre changements backward-compatible et breaking changes
  • Impact : Pipelines en echec, dashboards incorrects, perte de confiance dans les donnees
  • Solution : Adopter SemVer (MAJOR.MINOR.PATCH) - MAJOR pour les breaking changes, MINOR pour les ajouts retrocompatibles, PATCH pour les corrections. Automatiser la validation dans la CI/CD.
Qu'est-ce qu'un breaking change dans un Data Contract ?
Un breaking change est une modification du contrat qui peut casser les consommateurs existants : suppression d'un champ, changement de type, renommage de colonne, ajout d'une contrainte NOT NULL, ou modification d'un enum. Ces changements necessitent un increment de version MAJOR et une periode de deprecation avec support multi-versions.

10. Semantic Layer - La Couche de Sens

35 min Avance

Objectifs

  • Comprendre le concept de Semantic Layer et son role dans la stack data moderne
  • Maitriser la Metrics Layer et la definition de metriques unifiees
  • Implementer une Semantic Layer avec dbt Metrics (MetricFlow) et Cube.js
  • Concevoir un modele semantique universel (Universal Semantic Model)
  • Evaluer les approches Headless BI et leurs avantages

La Semantic Layer est la reponse au probleme numero un des organisations data : "Pourquoi le chiffre d'affaires est different entre le dashboard Finance et celui de Marketing ?" Quand chaque outil BI calcule les metriques a sa facon, c'est le chaos. La Semantic Layer centralise les definitions metier dans un seul endroit, garantissant que "revenu" signifie la meme chose partout.

Le Probleme des Metriques Incoherentes

Dans une organisation typique, les metriques business sont definies dans de multiples endroits : les modeles dbt, les dashboards Tableau, les notebooks Jupyter, les spreadsheets Excel. Chaque outil a sa propre logique de calcul, ce qui conduit inevitablement a des chiffres differents pour la meme metrique.

Avant vs Apres la Semantic Layer
  AVANT (Chaos)                    APRES (Semantic Layer)
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”                     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚ Tableau   β”‚ β†’ revenue = X      β”‚ Tableau   │──┐
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜                     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β”‚
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”                     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚ Looker   β”‚ β†’ revenue = Y      β”‚ Looker   │──┼──│  Semantic   β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜                     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β”‚  β”‚   Layer     β”‚
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”                     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”‚  β”‚             β”‚
  β”‚ Python   β”‚ β†’ revenue = Z      β”‚ Python   β”‚β”€β”€β”˜  β”‚ revenue =   β”‚
  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜                     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β”‚ SUM(amount) β”‚
                                                    β”‚ WHERE       β”‚
  X β‰  Y β‰  Z  (probleme!)          X = Y = Z       β”‚ status =    β”‚
                                   (coherent!)      β”‚ 'completed' β”‚
                                                    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

La Metrics Layer

La Metrics Layer est le composant central de la Semantic Layer. Elle definit les metriques business de maniere declarative, independamment des outils de consommation.

Composants d'une Metrics Layer

  • Entites (Entities) : Les objets metier de reference (client, commande, produit)
  • Dimensions : Attributs de regroupement et filtrage (pays, categorie, date)
  • Metriques (Measures) : Calculs agreges definis une seule fois (revenue, CAC, LTV)
  • Relations (Joins) : Liens entre entites pour enrichir les analyses
  • Caching : Pre-calcul des metriques frequentes pour la performance

dbt Metrics avec MetricFlow

MetricFlow est le moteur de metriques de dbt, acquis par dbt Labs. Il permet de definir des metriques semantiques directement dans les projets dbt, accessibles depuis n'importe quel outil via l'API dbt Semantic Layer.

YAML - dbt Semantic Layer (MetricFlow)
# models/semantic/sem_orders.yml
semantic_models:
  - name: orders
    defaults:
      agg_time_dimension: order_date
    description: Modele semantique des commandes
    model: ref('fct_orders')

    entities:
      - name: order_id
        type: primary
      - name: customer_id
        type: foreign
      - name: product_id
        type: foreign

    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
      - name: country
        type: categorical
      - name: order_status
        type: categorical

    measures:
      - name: order_total
        agg: sum
        expr: total_amount
        description: Montant total des commandes
      - name: order_count
        agg: count
        expr: order_id
        description: Nombre de commandes
      - name: avg_order_value
        agg: average
        expr: total_amount
        description: Panier moyen

# metrics/revenue.yml
metrics:
  - name: revenue
    type: derived
    label: "Chiffre d'Affaires"
    description: |
      Chiffre d'affaires total = somme des montants
      des commandes avec statut 'completed'.
    type_params:
      expr: order_total
      metrics:
        - name: order_total
          filter: |
            {{ Dimension('order_status') }} = 'completed'

  - name: revenue_per_customer
    type: ratio
    label: "Revenue par Client"
    description: Revenu moyen par client unique
    type_params:
      numerator: revenue
      denominator:
        name: customers
        filter: |
          {{ Dimension('order_status') }} = 'completed'

Cube.js - Semantic Layer Open Source

Cube.js (rebaptise Cube) est une plateforme de Semantic Layer open source qui se positionne entre les sources de donnees et les outils de consommation. Il offre une API universelle (REST, GraphQL, SQL) pour acceder aux metriques.

JavaScript - Cube.js Schema
// schema/Orders.js
cube('Orders', {
  sql: `SELECT * FROM analytics.fct_orders`,

  joins: {
    Customers: {
      relationship: 'belongsTo',
      sql: `${CUBE}.customer_id = ${Customers}.id`
    },
    Products: {
      relationship: 'belongsTo',
      sql: `${CUBE}.product_id = ${Products}.id`
    }
  },

  measures: {
    count: { type: 'count' },
    totalRevenue: {
      type: 'sum',
      sql: 'total_amount',
      filters: [{ sql: `${CUBE}.status = 'completed'` }],
      format: 'currency'
    },
    avgOrderValue: {
      type: 'avg',
      sql: 'total_amount',
      format: 'currency'
    },
    conversionRate: {
      type: 'number',
      sql: `${completedCount} / NULLIF(${count}, 0) * 100`,
      format: 'percent'
    }
  },

  dimensions: {
    id: { sql: 'id', type: 'number', primaryKey: true },
    status: { sql: 'status', type: 'string' },
    createdAt: { sql: 'created_at', type: 'time' },
    country: { sql: 'country', type: 'string' }
  },

  preAggregations: {
    // Cache pre-calcule pour les requetes frequentes
    dailyRevenue: {
      measures: [totalRevenue, count],
      timeDimension: createdAt,
      granularity: 'day',
      refreshKey: { every: '1 hour' }
    }
  }
});

Headless BI

Le Headless BI est un paradigme ou la couche semantique est decouplΓ©e de la couche de visualisation. Les metriques sont definies et gerees centralement, puis consommees par n'importe quel outil via des APIs.

BI Traditionnel

  • Metriques definies DANS l'outil BI
  • Logique dupliquee par outil
  • Vendor lock-in sur la couche semantique
  • Incoherences entre outils
  • Exemples : Tableau, Power BI natif

Headless BI

  • Metriques definies HORS de l'outil BI
  • Source unique de verite
  • Outils interchangeables
  • Coherence garantie partout
  • Exemples : Cube + Superset, dbt Metrics + Hex

Airbnb - Minerva, la Semantic Layer Interne

Airbnb a construit Minerva, une Semantic Layer interne, pour resoudre le probleme des metriques incoherentes a travers ses centaines d'equipes :

  • Probleme : Plus de 100 definitions differentes de "nuits reservees" a travers les dashboards Airbnb, chacune avec des filtres et exclusions differents
  • Solution : Minerva centralise TOUTES les definitions de metriques dans un systeme unique et versionne
  • Architecture : Couche declarative YAML β†’ moteur de calcul Spark β†’ cache pre-calcule β†’ API unifiee
  • Governance : Chaque metrique a un owner designe, un processus de review et une certification
  • Resultat : Reduction de 90% des tickets "pourquoi les chiffres sont differents", et adoption par 95% des equipes analytics
  • Impact : Les decisions strategiques d'Airbnb (pricing, expansion geographique) reposent desormais sur une source unique de verite

Metriques Definies dans les Outils BI

Definir les metriques directement dans Tableau, Power BI ou Looker est l'anti-pattern le plus repandu et le plus destructeur pour la confiance dans les donnees :

  • Symptome : Le CEO recoit trois chiffres de revenue differents de trois equipes differentes
  • Cause : Chaque equipe a defini "revenue" dans son propre outil avec ses propres filtres
  • Impact : Perte de confiance dans les donnees, decisions basees sur des chiffres incorrects, heures perdues en reconciliation
  • Solution : Extraire les definitions de metriques dans une Semantic Layer independante (dbt Metrics, Cube, LookML) et les exposer via une API unifiee a tous les outils

Universal Semantic Model (USM)

Le concept de Universal Semantic Model vise a creer un standard ouvert pour les definitions de metriques, independant de tout vendeur. L'initiative est portee par dbt Labs, Cube et d'autres acteurs de la Modern Data Stack. L'objectif : definir une metrique une seule fois et la rendre accessible depuis n'importe quel outil, n'importe quelle API, n'importe quel langage.

Quelle est la difference entre une Semantic Layer et un Data Catalog ?
Un Data Catalog (ex: DataHub, Atlan) documente et decouvre les donnees existantes (metadata, lineage, owners). La Semantic Layer va plus loin en definissant les metriques business et en servant de couche de calcul entre les donnees brutes et les consommateurs. Le Catalog dit "cette table existe et contient X colonnes", la Semantic Layer dit "voici comment calculer le revenue a partir de cette table".

11. Data APIs - Exposer les Donnees comme Produit

35 min Avance

Objectifs

  • Comparer REST et GraphQL pour l'exposition de donnees
  • Concevoir des API Gateway patterns pour les data platforms
  • Implementer le rate limiting et le throttling pour proteger les sources
  • Mettre en place des strategies de caching multi-niveaux
  • Appliquer les bonnes pratiques de versioning et documentation des Data APIs

Les Data APIs transforment les donnees en produits consommables. Au lieu de donner acces directement aux tables de la base, vous exposez des endpoints bien definis, documentes et securises. C'est le passage d'un modele "self-service SQL" a un modele "Data as a Service". Les meilleures data platforms combinent les deux approches selon les cas d'usage.

REST vs GraphQL pour les Donnees

Le choix entre REST et GraphQL depend du pattern de consommation. REST excelle pour les acces simples et previsibles, GraphQL pour les requetes complexes et flexibles.

REST pour Data APIs

  • Endpoints predictibles (/api/v2/orders)
  • Caching HTTP natif (ETags, Cache-Control)
  • Simple a implementer et monitorer
  • Ideal pour les datasets bien definis
  • Probleme : over-fetching et under-fetching
REST API Endpoints
# Endpoints REST pour donnees
GET /api/v2/orders
  ?status=completed
  &date_from=2025-01-01
  &date_to=2025-06-30
  &fields=order_id,total,status
  &page=1&limit=100

GET /api/v2/orders/{id}
GET /api/v2/metrics/revenue
  ?granularity=monthly
  &dimension=country

GraphQL pour Data APIs

  • Requete exactement les champs necessaires
  • Un seul endpoint pour tout
  • Federation de sources multiples
  • Ideal pour les UIs et consommateurs varies
  • Probleme : N+1 queries, complexite de cache
GraphQL Query
query OrdersWithCustomer {
  orders(
    filter: {
      status: COMPLETED,
      dateRange: {
        from: "2025-01-01",
        to: "2025-06-30"
      }
    },
    limit: 100
  ) {
    orderId
    total
    customer {
      name
      segment
    }
  }
}

API Gateway Patterns

L'API Gateway est le point d'entree unique pour toutes les Data APIs. Il centralise l'authentification, le rate limiting, le monitoring et le routage.

Architecture API Gateway pour Data Platform
  Consommateurs
  β”Œβ”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”
  β”‚App Webβ”‚ β”‚Mobile β”‚ β”‚Partnerβ”‚
  β””β”€β”€β”€β”¬β”€β”€β”€β”˜ β””β”€β”€β”€β”¬β”€β”€β”€β”˜ β””β”€β”€β”€β”¬β”€β”€β”€β”˜
      β”‚         β”‚         β”‚
      β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                β”‚
       β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”
       β”‚   API Gateway    β”‚  ← Kong / AWS API GW / Apigee
       β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”β”‚
       β”‚  β”‚ Auth (JWT)  β”‚β”‚  ← Authentification
       β”‚  β”‚ Rate Limit  β”‚β”‚  ← Protection
       β”‚  β”‚ Cache (CDN) β”‚β”‚  ← Performance
       β”‚  β”‚ Monitoring  β”‚β”‚  ← Observabilite
       β”‚  β”‚ Versioning  β”‚β”‚  ← Compatibilite
       β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜β”‚
       β””β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                β”‚
    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
    β”‚           β”‚           β”‚
β”Œβ”€β”€β”€β”΄β”€β”€β”€β”  β”Œβ”€β”€β”€β”΄β”€β”€β”€β”  β”Œβ”€β”€β”€β”΄β”€β”€β”€β”
β”‚REST   β”‚  β”‚GraphQLβ”‚  β”‚gRPC   β”‚
β”‚Orders β”‚  β”‚Federatβ”‚  β”‚Stream β”‚
β”‚API    β”‚  β”‚Gatewayβ”‚  β”‚API    β”‚
β””β”€β”€β”€β”¬β”€β”€β”€β”˜  β””β”€β”€β”€β”¬β”€β”€β”€β”˜  β””β”€β”€β”€β”¬β”€β”€β”€β”˜
    β”‚          β”‚          β”‚
β”Œβ”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”
β”‚      Data Platform          β”‚
β”‚  Warehouse / Lake / Cache   β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Rate Limiting et Protection

Le rate limiting protege vos sources de donnees contre la surcharge. Il est essentiel de definir des quotas par consommateur et par type de requete.

YAML - Configuration Rate Limiting (Kong)
# Configuration Kong API Gateway
plugins:
  - name: rate-limiting
    config:
      # Limites par tier de consommateur
      policy: redis
      redis_host: redis-cluster.internal
      limits:
        - tier: free
          second: 5
          minute: 100
          hour: 1000
        - tier: standard
          second: 50
          minute: 1000
          hour: 50000
        - tier: premium
          second: 200
          minute: 5000
          hour: unlimited

  - name: request-size-limiting
    config:
      allowed_payload_size: 10  # MB

  - name: response-ratelimiting
    config:
      # Limiter le volume de donnees retournees
      limits:
        max_rows:
          second: null
          minute: 100000  # Max 100K rows/min

  - name: bot-detection
    config:
      deny:
        - "scrapy"
        - "wget"
      allow:
        - "company-internal-client"

Strategies de Caching

Le caching est fondamental pour les Data APIs performantes. Une strategie multi-niveaux optimise a la fois la latence et la charge sur le data warehouse.

NiveauOutilTTL TypiqueCas d'usage
CDN / EdgeCloudFront, Fastly5-60 minMetriques publiques, dashboards
API GatewayKong, Redis1-15 minRequetes frequentes par consumer
ApplicationRedis, Memcached5-60 minResultats de requetes complexes
Pre-aggregationCube.js, Materialized Views1-24hMetriques pre-calculees
Query EngineSnowflake Result Cache24hCache natif du warehouse
Python - Caching Multi-Niveaux (FastAPI)
from fastapi import FastAPI, Depends, Header
from fastapi_cache import FastAPICache
from fastapi_cache.backends.redis import RedisBackend
import hashlib, json

app = FastAPI(title="Data API v2")

# Cache decorator avec TTL dynamique selon le type de requete
def cache_key_builder(func, *args, **kwargs):
    """Cle de cache basee sur les parametres de la requete"""
    params = json.dumps(kwargs, sort_keys=True, default=str)
    return f"data_api:{func.__name__}:{hashlib.md5(params.encode()).hexdigest()}"

@app.get("/api/v2/metrics/revenue")
@cache(expire=900, key_builder=cache_key_builder)  # 15 min
async def get_revenue(
    granularity: str = "monthly",
    date_from: str = None,
    date_to: str = None,
    dimension: str = None,
    api_key: str = Header(...)
):
    # Verification du quota
    consumer = await verify_api_key(api_key)
    await check_rate_limit(consumer)

    # Requete vers la Semantic Layer
    result = await semantic_layer.query(
        metric="revenue",
        granularity=granularity,
        filters={"date_range": [date_from, date_to]},
        group_by=[dimension] if dimension else []
    )

    return {
        "metric": "revenue",
        "data": result,
        "metadata": {
            "freshness": "2025-06-12T14:00:00Z",
            "cache_hit": False,
            "query_time_ms": 245
        }
    }

Stripe - Data API comme Produit Interne

Stripe a construit une plateforme de Data APIs internes pour permettre a ses equipes d'acceder aux donnees de maniere standardisee et securisee :

  • Approche : Chaque domaine (payments, billing, fraud) expose ses donnees via des APIs bien documentees
  • API Gateway : Gateway centralise avec authentification OAuth2, rate limiting par equipe, et audit logging complet
  • Caching : Strategie 3 niveaux (edge CDN, Redis, materialized views) reduisant la charge warehouse de 70%
  • Documentation : OpenAPI specs auto-generees avec examples et sandbox pour les developpeurs
  • Resultat : Time-to-data reduit de semaines a heures pour les nouvelles equipes, et zero incident de surcharge du warehouse

Acces Direct au Data Warehouse sans API

Donner un acces SQL direct au data warehouse a tous les consommateurs est tentant mais dangereux :

  • Probleme : Requetes non optimisees qui consomment des ressources massives (un SELECT * sans LIMIT)
  • Securite : Impossible de controler finement les colonnes et lignes accessibles par consommateur
  • Couts : Facture Snowflake/BigQuery qui explose a cause de requetes non controlees
  • Solution : Exposer les donnees via des APIs avec des quotas, du caching et des requetes pre-optimisees. Reserver l'acces SQL direct aux data engineers et analysts certifies.
Quand choisir GraphQL plutot que REST pour une Data API ?
Choisissez GraphQL quand : (1) les consommateurs ont besoin de combiner des donnees de plusieurs domaines en une seule requete, (2) les patterns de consommation sont tres varies (mobile vs web vs API), (3) vous voulez federer plusieurs sources via Apollo Federation. Choisissez REST quand : (1) les endpoints sont simples et bien definis, (2) le caching HTTP est crucial, (3) l'equipe a peu d'experience GraphQL.

12. Data Virtualization - Acces Unifie sans Copie

35 min Avance

Objectifs

  • Comprendre le principe de la Data Virtualization et ses differences avec l'ETL
  • Maitriser les outils leaders : Denodo, Dremio et Trino
  • Concevoir une architecture de query federation performante
  • Optimiser les performances avec le caching, le pushdown et le partitioning
  • Identifier les cas d'usage adaptes a la virtualisation vs la materialisation

La Data Virtualization est souvent mal comprise. Ce n'est PAS un remplacement de l'ETL ou du data warehouse. C'est un complement strategique pour les cas ou la copie physique est couteuse, non necessaire ou impossible (reglementaire). L'astuce est de savoir QUAND virtualiser et quand materialiser. Un bon Data Architect maitrise les deux approches.

Qu'est-ce que la Data Virtualization ?

La Data Virtualization cree une couche d'abstraction logique qui permet d'interroger des sources de donnees heterogenes comme si elles etaient dans une seule base de donnees, sans copier physiquement les donnees. Les requetes sont decomposees, envoyees aux sources, et les resultats sont assembles a la volee.

Architecture Data Virtualization
  Consommateurs
  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”
  β”‚Tableau β”‚ β”‚Python  β”‚ β”‚App     β”‚
  β””β”€β”€β”€β”€β”¬β”€β”€β”€β”˜ β””β”€β”€β”€β”¬β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”¬β”€β”€β”€β”€β”˜
       β”‚         β”‚          β”‚
       β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                 β”‚  SQL / JDBC / ODBC
     β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
     β”‚  Couche Virtualization β”‚
     β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”‚
     β”‚  β”‚ Query Optimizer  β”‚ β”‚  ← Plan d'execution optimal
     β”‚  β”‚ Pushdown Engine  β”‚ β”‚  ← Delegue aux sources
     β”‚  β”‚ Cache Manager    β”‚ β”‚  ← Cache intelligent
     β”‚  β”‚ Security Layer   β”‚ β”‚  ← Row/Column level
     β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β”‚
     β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                 β”‚
     β”Œβ”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”Όβ”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”
     β”‚       β”‚       β”‚       β”‚
  β”Œβ”€β”€β”΄β”€β”€β” β”Œβ”€β”€β”΄β”€β”€β” β”Œβ”€β”€β”΄β”€β”€β” β”Œβ”€β”€β”΄β”€β”€β”
  β”‚Postgrβ”‚ β”‚S3   β”‚ β”‚Salesβ”‚ β”‚Mongoβ”‚
  β”‚SQL   β”‚ β”‚Lake β”‚ β”‚forceβ”‚ β”‚DB   β”‚
  β””β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”˜
  Sources physiques (pas de copie)

Comparaison des Outils

CritereDenodoDremioTrino (ex-Presto)
TypeEnterprise (proprietaire)Lakehouse Engine (open core)Open source (distribue)
ForceFederation multi-source, UI enterprise, gouvernanceReflexions Iceberg, acceleration, self-servicePerformance SQL, large ecosysteme connecteurs
Sources200+ connecteurs (SGBD, APIs, SaaS, fichiers)Data Lakes (S3, ADLS), SGBD, APIsSGBD, Hive, S3, Kafka, Elasticsearch
CachingCache multi-niveau intelligentReflections (materialized views)Alluxio, result cache
PrixLicence enterprise (cout eleve)Open source + Cloud editionGratuit (open source)
Ideal pourGrandes entreprises multi-sourcesLakehouse avec query federationEquipes techniques, ad-hoc analytics

Query Federation et Pushdown

Le query pushdown est la technique cle pour la performance en Data Virtualization. L'idee est de "pousser" le maximum de traitements (filtres, projections, aggregations) vers les sources, plutot que de tout rapatrier dans le moteur de virtualisation.

SQL - Query Federation avec Trino
-- Requete federee qui interroge 3 sources differentes
-- Trino decompose et optimise automatiquement

SELECT
    c.customer_name,
    c.segment,
    o.total_orders,
    o.total_revenue,
    s.satisfaction_score,
    s.nps
FROM
    -- Source 1 : PostgreSQL (CRM)
    postgresql.crm.customers c
JOIN (
    -- Source 2 : Data Lake S3 (Iceberg)
    SELECT
        customer_id,
        COUNT(*) as total_orders,
        SUM(amount) as total_revenue
    FROM iceberg.analytics.orders
    WHERE order_date >= DATE '2025-01-01'  -- Pushdown vers S3
      AND status = 'completed'              -- Pushdown filter
    GROUP BY customer_id                    -- Pushdown aggregation
) o ON c.id = o.customer_id
LEFT JOIN
    -- Source 3 : MongoDB (Surveys)
    mongodb.surveys.satisfaction s
    ON c.id = s.customer_id
WHERE
    c.segment = 'enterprise'  -- Pushdown vers PostgreSQL
ORDER BY o.total_revenue DESC
LIMIT 100;

Optimisation des Performances

5 Strategies d'Optimisation

  • 1. Pushdown maximal : Verifier que les filtres, projections et aggregations sont pousses aux sources (EXPLAIN ANALYZE)
  • 2. Caching intelligent : Materialiser les jointures frequentes avec un TTL adapte a la fraicheur requise
  • 3. Partitionnement : Exploiter le partition pruning des sources (date, region) pour reduire le scan
  • 4. Statistiques : Maintenir des statistiques a jour sur les sources pour que l'optimiseur choisisse le bon plan
  • 5. Data locality : Privilegier les jointures entre sources proches (meme region, meme cloud) pour minimiser le transfert reseau
SQL - Dremio Reflections (Materialisation Intelligente)
-- Creer une Reflection (vue materialisee) dans Dremio
-- pour accelerer les requetes frequentes

-- Reflection brute : cache une copie optimisee des donnees
ALTER DATASET iceberg.analytics.orders
  CREATE RAW REFLECTION orders_raw
  USING DISPLAY (order_id, customer_id, order_date, amount, status)
  PARTITION BY (order_date)
  DISTRIBUTE BY (customer_id)
  SORT BY (order_date DESC);

-- Reflection aggregee : pre-calcul des metriques
ALTER DATASET iceberg.analytics.orders
  CREATE AGGREGATE REFLECTION orders_daily_agg
  USING DIMENSIONS (order_date, status)
  MEASURES (amount (SUM, COUNT, MIN, MAX), order_id (COUNT))
  PARTITION BY (order_date);

-- Dremio choisit automatiquement la meilleure Reflection
-- en fonction de la requete de l'utilisateur
SELECT
    DATE_TRUNC('month', order_date) as month,
    SUM(amount) as revenue,
    COUNT(*) as order_count
FROM iceberg.analytics.orders
WHERE order_date >= '2025-01-01'
GROUP BY 1
ORDER BY 1;
-- β†’ Dremio utilise orders_daily_agg automatiquement

Groupe LVMH - Data Virtualization pour Federation Multi-Marques

Le groupe LVMH (Louis Vuitton, Dior, Sephora, etc.) utilise la Data Virtualization pour federer les donnees de ses 75+ maisons sans centraliser physiquement les donnees dans un seul data warehouse :

  • Probleme : Chaque maison a son propre systeme data (SAP, Salesforce, systemes proprietaires). Centraliser les donnees est juridiquement complexe (entites legales separees) et politiquement sensible
  • Solution : Couche de virtualisation Denodo qui federe les donnees en temps reel sans copie physique
  • Architecture : Chaque maison conserve ses donnees dans son systeme. Denodo fournit une vue unifiee "Groupe" pour les KPIs consolides
  • Securite : Chaque maison ne voit que ses propres donnees detaillees, le holding voit les aggregats
  • Resultat : Vision consolidee du groupe en temps reel, respect de l'autonomie de chaque maison, conformite GDPR car les donnees PII ne quittent jamais le systeme source

Virtualiser des Requetes Analytiques Lourdes

Utiliser la Data Virtualization pour des requetes analytiques complexes (jointures de milliards de lignes, aggregations multi-dimensions) est une erreur frequente :

  • Symptome : Requetes qui prennent 30 minutes au lieu de 3 secondes, timeout frequent
  • Cause : Le moteur de virtualisation rapatrie trop de donnees des sources car les pushdown ne fonctionnent pas pour les jointures complexes
  • Impact : Performance catastrophique, surcharge des systemes sources, frustration des utilisateurs
  • Regle : Virtualiser pour les requetes operationnelles (temps reel, faible volume). Materialiser (ETL/ELT) pour les requetes analytiques lourdes (historique, gros volumes, aggregations complexes).

Scenario : Choisir Virtualisation vs Materialisation

Votre entreprise a les cas d'usage suivants. Pour chacun, indiquez si vous recommandez la virtualisation (V) ou la materialisation (M) :

  • Dashboard temps reel des commandes en cours : V - faible volume, besoin de fraicheur, acces a la source transactionnelle
  • Rapport mensuel de revenue par pays et categorie : M - aggregation lourde sur historique, besoin de performance, calcul complexe
  • Vue unifiee client CRM + support + facturation : V - federation de 3 sources, faible volume par client, besoin de vision temps reel
  • Modele ML d'entrainement sur 2 ans de donnees : M - volume massif, calcul intensif, pas besoin de temps reel
  • API de conformite GDPR (droit d'acces) : V - besoin de lister les donnees dans TOUTES les sources sans les copier
Qu'est-ce que le "query pushdown" et pourquoi est-ce critique pour la Data Virtualization ?
Le query pushdown consiste a deleguer le maximum d'operations (filtres WHERE, projections SELECT, aggregations GROUP BY) directement aux systemes sources plutot que de rapatrier toutes les donnees dans le moteur de virtualisation. C'est critique car sans pushdown, une requete avec un filtre sur 1% des donnees rapatrierait 100% des lignes pour les filtrer localement, causant des latences catastrophiques et une surcharge reseau. L'optimiseur doit analyser les capacites de chaque source pour maximiser le pushdown.

13. Lab Pratique - Data Contracts

45 min Pratique

Objectifs

  • Creer un Data Contract complet au format YAML pour un domaine metier
  • Implementer la validation automatique du contrat avec des outils open source
  • Mettre en place un pipeline CI/CD pour la gouvernance des contrats
  • Tester les schemas avec des donnees reelles et gerer les violations
  • Automatiser la detection de breaking changes dans les contrats

Ce lab est concu pour vous donner une experience pratique complete. Vous allez creer un Data Contract de A a Z, l'implementer avec des outils reels et mettre en place un pipeline CI/CD qui valide automatiquement chaque modification. A la fin de ce lab, vous aurez un template reutilisable dans vos projets professionnels.

Lab : Implementation Complete de Data Contracts

Etape 1 : Structure du Projet

Commencez par creer la structure de repertoires pour votre projet de Data Contracts :

Bash - Structure du Projet
# Creer la structure du projet
mkdir -p data-contracts/{contracts,schemas,tests,scripts,ci}

# Structure finale :
data-contracts/
β”œβ”€β”€ contracts/              # Contrats YAML par domaine
β”‚   β”œβ”€β”€ checkout/
β”‚   β”‚   └── orders.yaml
β”‚   └── customer/
β”‚       └── customers.yaml
β”œβ”€β”€ schemas/                # JSON Schemas de validation
β”‚   └── contract-schema.json
β”œβ”€β”€ tests/                  # Tests de validation
β”‚   β”œβ”€β”€ test_contracts.py
β”‚   └── test_data_quality.py
β”œβ”€β”€ scripts/                # Scripts utilitaires
β”‚   β”œβ”€β”€ validate.py
β”‚   └── breaking_change_detector.py
β”œβ”€β”€ ci/                     # Configuration CI/CD
β”‚   └── github-actions.yml
β”œβ”€β”€ pyproject.toml
└── README.md

Etape 2 : Creer le Data Contract YAML

Creez un contrat complet pour le domaine Checkout. Ce contrat definit le schema, les SLAs, la qualite et les regles d'evolution :

YAML - contracts/checkout/orders.yaml
dataContractSpecification: 0.9.3
id: urn:datacontract:checkout:orders:v2
info:
  title: Orders Data Contract
  version: 2.1.0
  status: active
  description: |
    Contrat de donnees pour les commandes du domaine Checkout.
    Ce contrat definit les garanties fournies par l'equipe
    Checkout aux consommateurs (Finance, Analytics, Marketing).
  owner: team-checkout
  contact:
    name: Marie Dupont
    email: checkout-data@company.com
    slack: "#checkout-data-support"
    oncall: "https://pagerduty.com/team-checkout"

servers:
  production:
    type: snowflake
    account: company.eu-west-1
    database: ANALYTICS
    schema: CHECKOUT_V2
  staging:
    type: snowflake
    account: company-staging.eu-west-1
    database: ANALYTICS_STAGING
    schema: CHECKOUT_V2

models:
  orders:
    description: Table des commandes validees et traitees
    type: table
    fields:
      order_id:
        type: string
        format: uuid
        required: true
        unique: true
        pii: false
        description: Identifiant unique UUID v4 de la commande
        example: "550e8400-e29b-41d4-a716-446655440000"

      customer_id:
        type: string
        required: true
        pii: true
        classification: confidential
        description: Identifiant du client (PII - masquer hors Finance)

      order_date:
        type: timestamp
        required: true
        description: Date et heure UTC de la commande

      total_amount:
        type: decimal
        precision: 10
        scale: 2
        required: true
        minimum: 0
        maximum: 999999.99
        description: Montant total TTC en euros

      currency:
        type: string
        required: true
        pattern: "^[A-Z]{3}$"
        default: "EUR"
        description: Code devise ISO 4217

      status:
        type: string
        required: true
        enum:
          - pending
          - confirmed
          - processing
          - shipped
          - delivered
          - cancelled
          - refunded
        description: Statut actuel de la commande

      channel:
        type: string
        required: true
        enum: [web, mobile_app, marketplace, store]
        description: Canal d'acquisition de la commande

      updated_at:
        type: timestamp
        required: true
        description: Derniere mise a jour (utilise pour le CDC)

quality:
  type: SodaCL
  specification:
    checks for orders:
      - row_count > 0
      - duplicate_count(order_id) = 0
      - missing_percent(customer_id) = 0
      - missing_percent(order_date) = 0
      - invalid_percent(status) = 0
      - invalid_percent(channel) = 0
      - avg(total_amount) between 15 and 500
      - max(total_amount) < 1000000
      - freshness(updated_at) < 2h
      - schema:
          name: Validate schema
          fail:
            when required column missing:
              - order_id
              - customer_id
              - order_date
              - total_amount
              - status
            when wrong type:
              order_id: varchar
              total_amount: decimal

sla:
  freshness:
    target: 2 hours
    critical: 4 hours
  availability:
    target: 99.9%
    measurement_window: 30 days
  latency:
    p95: 30 seconds
    p99: 60 seconds
  update_frequency: every 15 minutes
  incident_response:
    severity_1: 30 minutes
    severity_2: 4 hours

terms:
  usage:
    - internal-analytics
    - financial-reporting
    - marketing-with-consent
  limitations: |
    - Donnees PII (customer_id) masquees hors du domaine Finance
    - Pas d'export vers des systemes externes sans approbation DPO
    - Retention maximale de 7 ans (obligation legale)
  billing: chargeback-by-query-volume

changelog:
  - version: 2.1.0
    date: 2025-06-01
    changes: "Ajout du champ 'channel' (non-breaking)"
  - version: 2.0.0
    date: 2025-03-15
    changes: "Breaking: renommage 'amount' β†’ 'total_amount', ajout 'currency'"
  - version: 1.0.0
    date: 2024-09-01
    changes: "Version initiale du contrat"

Etape 3 : Schema de Validation du Contrat

Creez un JSON Schema pour valider la structure meme de vos contrats YAML. Cela garantit que tous les contrats respectent un format standard :

JSON - schemas/contract-schema.json
{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "Data Contract Schema",
  "type": "object",
  "required": [
    "dataContractSpecification", "id", "info",
    "models", "quality", "sla"
  ],
  "properties": {
    "dataContractSpecification": {
      "type": "string",
      "pattern": "^[0-9]+\\.[0-9]+\\.[0-9]+$"
    },
    "id": {
      "type": "string",
      "pattern": "^urn:datacontract:"
    },
    "info": {
      "type": "object",
      "required": ["title", "version", "owner", "contact"],
      "properties": {
        "title": { "type": "string", "minLength": 5 },
        "version": {
          "type": "string",
          "pattern": "^[0-9]+\\.[0-9]+\\.[0-9]+$"
        },
        "status": {
          "type": "string",
          "enum": ["draft", "active", "deprecated", "retired"]
        },
        "owner": { "type": "string" },
        "contact": {
          "type": "object",
          "required": ["email"],
          "properties": {
            "name": { "type": "string" },
            "email": { "type": "string", "format": "email" },
            "slack": { "type": "string" }
          }
        }
      }
    },
    "sla": {
      "type": "object",
      "required": ["freshness", "availability"]
    }
  }
}

Etape 4 : Script de Validation Python

Implementez le script de validation qui verifie la conformite des contrats et detecte les breaking changes :

Python - scripts/validate.py
"""
Validation des Data Contracts
- Validation du schema YAML
- Detection de breaking changes
- Verification des SLAs
"""
import yaml
import json
import sys
from pathlib import Path
from jsonschema import validate, ValidationError
from deepdiff import DeepDiff

class ContractValidator:
    def __init__(self, schema_path: str):
        with open(schema_path) as f:
            self.schema = json.load(f)

    def validate_contract(self, contract_path: str) -> dict:
        """Valider un contrat contre le schema."""
        with open(contract_path) as f:
            contract = yaml.safe_load(f)

        errors = []
        warnings = []

        # 1. Validation du schema
        try:
            validate(instance=contract, schema=self.schema)
        except ValidationError as e:
            errors.append(f"Schema invalide: {e.message}")

        # 2. Verification des champs requis dans les modeles
        for model_name, model in contract.get('models', {}).items():
            for field_name, field in model.get('fields', {}).items():
                if field.get('pii') and not field.get('classification'):
                    warnings.append(
                        f"Champ PII '{field_name}' dans '{model_name}' "
                        f"sans classification de securite"
                    )
                if field.get('required') and field.get('type') is None:
                    errors.append(
                        f"Champ requis '{field_name}' sans type defini"
                    )

        # 3. Verification du SLA
        sla = contract.get('sla', {})
        if 'freshness' not in sla:
            errors.append("SLA de fraicheur manquant")
        if 'availability' not in sla:
            errors.append("SLA de disponibilite manquant")

        return {
            "valid": len(errors) == 0,
            "errors": errors,
            "warnings": warnings,
            "contract": contract
        }

    def detect_breaking_changes(
        self, old_path: str, new_path: str
    ) -> dict:
        """Detecter les breaking changes entre deux versions."""
        with open(old_path) as f:
            old = yaml.safe_load(f)
        with open(new_path) as f:
            new = yaml.safe_load(f)

        breaking = []
        non_breaking = []

        old_models = old.get('models', {})
        new_models = new.get('models', {})

        for model_name in old_models:
            if model_name not in new_models:
                breaking.append(
                    f"BREAKING: Modele '{model_name}' supprime"
                )
                continue

            old_fields = old_models[model_name].get('fields', {})
            new_fields = new_models[model_name].get('fields', {})

            # Champs supprimes
            for field in old_fields:
                if field not in new_fields:
                    breaking.append(
                        f"BREAKING: Champ '{field}' supprime "
                        f"de '{model_name}'"
                    )

            # Champs modifies
            for field in old_fields:
                if field in new_fields:
                    old_type = old_fields[field].get('type')
                    new_type = new_fields[field].get('type')
                    if old_type != new_type:
                        breaking.append(
                            f"BREAKING: Type de '{field}' change "
                            f"de '{old_type}' a '{new_type}'"
                        )

                    # Nouveau required
                    was_required = old_fields[field].get('required', False)
                    is_required = new_fields[field].get('required', False)
                    if not was_required and is_required:
                        breaking.append(
                            f"BREAKING: '{field}' est devenu required"
                        )

            # Nouveaux champs (non-breaking)
            for field in new_fields:
                if field not in old_fields:
                    non_breaking.append(
                        f"NON-BREAKING: Nouveau champ '{field}' "
                        f"dans '{model_name}'"
                    )

        return {
            "has_breaking_changes": len(breaking) > 0,
            "breaking_changes": breaking,
            "non_breaking_changes": non_breaking
        }


if __name__ == "__main__":
    validator = ContractValidator("schemas/contract-schema.json")

    # Valider tous les contrats
    contracts_dir = Path("contracts")
    all_valid = True

    for contract_file in contracts_dir.rglob("*.yaml"):
        print(f"\nValidation: {contract_file}")
        result = validator.validate_contract(str(contract_file))

        if result["valid"]:
            print(f"  βœ“ Contrat valide")
        else:
            print(f"  βœ— Contrat invalide")
            all_valid = False
            for err in result["errors"]:
                print(f"    ERREUR: {err}")

        for warn in result["warnings"]:
            print(f"    ATTENTION: {warn}")

    sys.exit(0 if all_valid else 1)

Etape 5 : Pipeline CI/CD

Mettez en place un pipeline GitHub Actions qui valide automatiquement chaque modification de contrat et bloque les breaking changes non autorises :

YAML - ci/github-actions.yml
name: Data Contract CI/CD

on:
  pull_request:
    paths:
      - 'contracts/**'
      - 'schemas/**'

jobs:
  validate-contracts:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0  # Historique complet pour diff

      - name: Setup Python
        uses: actions/setup-python@v5
        with:
          python-version: '3.11'

      - name: Install dependencies
        run: |
          pip install pyyaml jsonschema deepdiff soda-core

      - name: Validate contract schemas
        run: python scripts/validate.py

      - name: Detect breaking changes
        run: |
          # Comparer avec la branche main
          git diff --name-only origin/main -- contracts/ | while read file; do
            if git show origin/main:$file > /tmp/old_contract.yaml 2>/dev/null; then
              echo "Checking breaking changes: $file"
              python -c "
          from scripts.validate import ContractValidator
          v = ContractValidator('schemas/contract-schema.json')
          result = v.detect_breaking_changes('/tmp/old_contract.yaml', '$file')
          if result['has_breaking_changes']:
              print('BREAKING CHANGES DETECTED:')
              for bc in result['breaking_changes']:
                  print(f'  - {bc}')
              exit(1)
          else:
              print('No breaking changes.')
              for nbc in result['non_breaking_changes']:
                  print(f'  - {nbc}')
          "
            fi
          done

      - name: Run data quality checks
        if: github.event.pull_request.labels.*.name == 'test-data'
        run: |
          # Verifier la qualite des donnees avec SodaCL
          soda scan -d production -c soda/configuration.yml \
            contracts/checkout/orders.yaml

      - name: Comment PR with results
        uses: actions/github-script@v7
        with:
          script: |
            github.rest.issues.createComment({
              issue_number: context.issue.number,
              owner: context.repo.owner,
              repo: context.repo.repo,
              body: '## Data Contract Validation\n\n' +
                    'βœ… Schema validation passed\n' +
                    'βœ… No breaking changes detected\n' +
                    'βœ… SLA requirements met'
            })

Etape 6 : Tests de Validation des Donnees

Creez des tests automatises qui verifient que les donnees reelles respectent le contrat :

Python - tests/test_contracts.py
"""Tests de validation des Data Contracts."""
import pytest
import yaml
from pathlib import Path
from scripts.validate import ContractValidator

SCHEMA_PATH = "schemas/contract-schema.json"
CONTRACTS_DIR = Path("contracts")

@pytest.fixture
def validator():
    return ContractValidator(SCHEMA_PATH)

def get_all_contracts():
    """Decouvrir tous les contrats YAML."""
    return list(CONTRACTS_DIR.rglob("*.yaml"))

@pytest.mark.parametrize("contract_path", get_all_contracts())
def test_contract_schema_valid(validator, contract_path):
    """Chaque contrat doit etre valide selon le schema."""
    result = validator.validate_contract(str(contract_path))
    assert result["valid"], \
        f"Contrat invalide: {result['errors']}"

@pytest.mark.parametrize("contract_path", get_all_contracts())
def test_contract_has_owner(contract_path):
    """Chaque contrat doit avoir un owner defini."""
    with open(contract_path) as f:
        contract = yaml.safe_load(f)
    owner = contract.get("info", {}).get("owner")
    assert owner, f"Owner manquant dans {contract_path}"

@pytest.mark.parametrize("contract_path", get_all_contracts())
def test_contract_has_sla(contract_path):
    """Chaque contrat doit definir des SLAs."""
    with open(contract_path) as f:
        contract = yaml.safe_load(f)
    sla = contract.get("sla", {})
    assert "freshness" in sla, "SLA fraicheur manquant"
    assert "availability" in sla, "SLA disponibilite manquant"

@pytest.mark.parametrize("contract_path", get_all_contracts())
def test_pii_fields_classified(contract_path):
    """Les champs PII doivent avoir une classification."""
    with open(contract_path) as f:
        contract = yaml.safe_load(f)
    for model_name, model in contract.get("models", {}).items():
        for field_name, field in model.get("fields", {}).items():
            if field.get("pii"):
                assert field.get("classification"), \
                    f"Champ PII '{field_name}' dans " \
                    f"'{model_name}' sans classification"

@pytest.mark.parametrize("contract_path", get_all_contracts())
def test_semver_format(contract_path):
    """La version doit suivre le format SemVer."""
    with open(contract_path) as f:
        contract = yaml.safe_load(f)
    version = contract.get("info", {}).get("version", "")
    parts = version.split(".")
    assert len(parts) == 3, \
        f"Version '{version}' non conforme SemVer"
    for part in parts:
        assert part.isdigit(), \
            f"Version '{version}' non conforme SemVer"

GoCardless - Data Contracts en Production avec CI/CD

GoCardless, la fintech britannique, a implemente un systeme de Data Contracts automatise avec une approche CI/CD complete :

  • Approche : Chaque dataset a un contrat YAML versionne dans un repository Git dedie
  • CI/CD : Chaque Pull Request sur un contrat declenche une validation automatique du schema, une detection de breaking changes, et des tests de qualite sur les donnees de staging
  • Breaking Changes : Les breaking changes necessitent l'approbation du data governance board et une periode de deprecation de 30 jours minimum
  • Monitoring : Les SLAs definis dans les contrats sont automatiquement monitores avec des alertes PagerDuty en cas de violation
  • Resultat : Zero breaking change non detecte en production depuis 18 mois, delai de resolution des incidents data reduit de 80%

Contrats sans Validation Automatique

Ecrire des Data Contracts sans les valider automatiquement est aussi inutile qu'ecrire des tests unitaires sans les executer :

  • Symptome : Les contrats existent dans un wiki ou un fichier Confluence, mais personne ne les respecte
  • Cause : Aucun mecanisme automatise pour verifier la conformite des donnees avec le contrat
  • Impact : Les contrats deviennent obsoletes, les equipes perdent confiance et reviennent au mode "freestyle"
  • Solution : Integrer la validation des contrats dans la CI/CD (comme dans ce lab). Chaque push de donnees doit etre valide contre le contrat. Les violations bloquent le deploiement ou declenchent des alertes.

Checklist de Completion du Lab

Verifiez que vous avez realise toutes les etapes :

  • Structure de projet creee avec repertoires contracts/, schemas/, tests/, scripts/, ci/
  • Contrat YAML complet avec schema, SLAs, qualite, ownership et changelog
  • JSON Schema de validation des contrats fonctionnel
  • Script Python de validation et detection de breaking changes
  • Pipeline GitHub Actions configure et operationnel
  • Tests pytest parametres pour la validation automatique

14. Quiz - Data Contracts & APIs

20 min Evaluation

Objectifs

  • Valider vos connaissances sur les Data Contracts et leur implementation
  • Verifier votre comprehension de la Semantic Layer et des Data APIs
  • Tester votre maitrise de la Data Virtualization
  • Evaluer votre capacite a concevoir des contrats de donnees robustes

Ce quiz couvre l'ensemble du Module 4.2. Prenez le temps de bien lire chaque question. Un score de 75% ou plus indique une bonne maitrise des concepts. En cas d'erreur, revisitez les lecons correspondantes avant de continuer.

Quiz Data Contracts & APIs

Q1. Quel est le role principal d'un Data Contract dans une architecture data moderne ?

Remplacer les pipelines ETL traditionnels
Definir un accord formel entre producteurs et consommateurs de donnees sur le schema, la qualite et les SLA
Centraliser toutes les donnees dans un seul data warehouse
Automatiser la generation de documentation technique

Bonne reponse ! Un Data Contract est un accord formel entre producteurs et consommateurs definissant le schema, les regles de qualite, les SLA et les conditions d'evolution des donnees. C'est le fondement de la gouvernance decentralisee dans un Data Mesh.

Q2. Dans un Data Contract au format Protobuf, quel avantage majeur offre-t-il par rapport a JSON Schema ?

Il est plus lisible par les humains
Il supporte nativement les commentaires
Il garantit la compatibilite ascendante et descendante avec un typage strict et une serialisation binaire performante
Il est supporte par tous les navigateurs web

Bonne reponse ! Protobuf offre un typage strict, une serialisation binaire compacte et performante, et des regles natives de compatibilite ascendante/descendante grace au systeme de numerotation des champs. C'est ideal pour les contrats a haute performance.

Q3. Quelle est la fonction principale d'une Semantic Layer dans une architecture data ?

Stocker les donnees brutes dans un data lake
Fournir une couche d'abstraction metier unifiee entre les sources de donnees et les consommateurs
Remplacer les bases de donnees relationnelles
Gerer l'authentification des utilisateurs

Bonne reponse ! La Semantic Layer fournit une couche d'abstraction metier qui traduit les structures techniques en concepts comprehensibles par les utilisateurs, garantissant des metriques coherentes et une gouvernance centralisee des definitions.

Q4. Quel outil est specifiquement concu pour implementer une Semantic Layer dans un environnement dbt ?

dbt Metrics Layer (MetricFlow)
Apache Airflow
Terraform
Kubernetes

Bonne reponse ! dbt Metrics Layer (base sur MetricFlow) permet de definir des metriques semantiques directement dans les projets dbt, assurant la coherence des definitions metier a travers tous les outils de consommation.

Q5. Quelle strategie de versioning est recommandee pour les Data APIs exposant des donnees critiques ?

Pas de versioning, toujours ecraser l'API existante
Versioning dans l'URL (ex: /api/v2/) avec deprecation progressive et support multi-versions
Creer une nouvelle API avec un nom different a chaque changement
Utiliser uniquement des headers HTTP custom

Bonne reponse ! Le versioning dans l'URL est la pratique la plus repandue et la plus explicite. Il permet de maintenir plusieurs versions simultanement, de communiquer clairement les deprecations et de migrer progressivement les consommateurs.

Q6. Quel est l'avantage principal de la Data Virtualization par rapport a l'ETL traditionnel ?

Elle est toujours plus rapide en termes de performance
Elle elimine la duplication des donnees en fournissant un acces en temps reel aux sources sans copie physique
Elle ne necessite aucune configuration
Elle remplace completement le besoin de bases de donnees

Bonne reponse ! La Data Virtualization cree une couche d'abstraction qui interroge les sources en temps reel sans copier les donnees. Cela reduit la latence de mise a disposition, elimine la duplication et simplifie la gouvernance, bien qu'elle puisse etre moins performante pour les requetes analytiques lourdes.

Q7. Dans une architecture Data Mesh, comment les Data Contracts facilitent-ils la gouvernance federee ?

En centralisant toutes les decisions dans une equipe unique
En permettant a chaque domaine de definir et publier ses propres contrats tout en respectant des standards globaux d'interoperabilite
En eliminant le besoin de documentation
En imposant un schema unique pour toutes les donnees

Bonne reponse ! Dans un Data Mesh, les Data Contracts permettent l'autonomie des domaines tout en garantissant l'interoperabilite. Chaque equipe de domaine est responsable de ses contrats, mais ceux-ci doivent respecter des standards globaux (formats, conventions de nommage, niveaux de SLA).

Q8. Quel pattern GraphQL est recommande pour federer plusieurs Data APIs dans une architecture microservices ?

GraphQL Monolith
GraphQL REST Wrapper
Apollo Federation avec un Gateway unifie et des sous-graphes autonomes par domaine
GraphQL sans schema

Bonne reponse ! Apollo Federation permet de composer un supergraph a partir de sous-graphes independants. Chaque equipe maintient son sous-graphe autonome, et le Gateway Apollo federe les requetes de maniere transparente pour les consommateurs. C'est le standard de facto pour le GraphQL a grande echelle.

Conseil de revision

Si vous avez obtenu moins de 6 bonnes reponses sur 8, revisitez les lecons 10 a 13 avant de continuer vers le module FinOps. Les concepts de Data Contracts et Semantic Layer sont fondamentaux pour la suite de la formation.

15. FinOps Principles - Gestion Financiere du Cloud

35 min Avance

Objectifs

  • Comprendre le framework FinOps et ses principes fondateurs
  • Maitriser le lifecycle FinOps : Inform, Optimize, Operate
  • Appliquer les concepts de Unit Economics aux couts cloud
  • Implementer des strategies de Cost Allocation, Showback et Chargeback
  • Decouvrir le framework FOCUS pour la standardisation des donnees de couts

Le FinOps est devenu une discipline incontournable pour tout Data Architect. J'ai vu des entreprises reduire leurs couts cloud de 40% a 60% simplement en appliquant ces principes. La cle ? Rendre les couts visibles et responsabiliser chaque equipe. Un bon architecte ne concoit pas seulement pour la performance, il concoit aussi pour l'efficience economique.

Qu'est-ce que le FinOps ?

Le FinOps (Financial Operations) est une pratique culturelle et une discipline operationnelle qui rapproche les equipes engineering, finance et business pour optimiser la valeur commerciale du cloud. Il ne s'agit pas simplement de reduire les couts, mais de maximiser la valeur business par dollar depense.

Les 6 Principes FinOps

  • Les equipes doivent collaborer : Finance, Engineering et Business travaillent ensemble
  • Chacun est responsable de ses couts cloud : Ownership decentralise
  • Un groupe centralise pilote le FinOps : Le Cloud Center of Excellence (CCoE)
  • Les rapports doivent etre accessibles et en temps reel : Transparence totale
  • Les decisions sont guidees par la valeur business : Pas seulement par le cout
  • Le modele de cout variable du cloud doit etre exploite : Tirer parti de l'elasticite

Le Framework FOCUS

Le FOCUS (FinOps Open Cost & Usage Specification) est un standard ouvert qui normalise les donnees de couts et d'usage cloud entre les differents fournisseurs. Developpe par la FinOps Foundation, il permet de comparer les couts AWS, GCP et Azure dans un format unique.

FOCUS Schema
{
  "BillingAccountId": "123456789",
  "BillingAccountName": "Production Account",
  "ChargePeriodStart": "2025-01-01T00:00:00Z",
  "ChargePeriodEnd": "2025-02-01T00:00:00Z",
  "ChargeType": "Usage",
  "BilledCost": 15420.50,
  "EffectiveCost": 12850.30,
  "ServiceCategory": "Compute",
  "ServiceName": "Amazon EC2",
  "ResourceId": "i-0abc123def456",
  "Region": "eu-west-1",
  "AvailabilityZone": "eu-west-1a",
  "Tags": {
    "team": "data-engineering",
    "project": "lakehouse",
    "environment": "production",
    "cost-center": "CC-4200"
  }
}

FOCUS : Pourquoi c'est essentiel

Avant FOCUS, chaque cloud provider avait son propre format de facturation (AWS CUR, GCP Billing Export, Azure Cost Management). FOCUS unifie ces formats, permettant une vue consolidee multi-cloud. Adopte par AWS, Google Cloud, Microsoft Azure et Oracle Cloud depuis 2024.

Le Lifecycle FinOps : Inform, Optimize, Operate

Cycle de vie FinOps
    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
    β”‚              FINOPS LIFECYCLE                         β”‚
    β”‚                                                      β”‚
    β”‚         β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”                                 β”‚
    β”‚    β”Œβ”€β”€β”€β–Ίβ”‚  INFORM  │───────┐                         β”‚
    β”‚    β”‚    β”‚          β”‚       β”‚                          β”‚
    β”‚    β”‚    β”‚ Visibiliteβ”‚       β–Ό                         β”‚
    β”‚    β”‚    β”‚ Allocationβ”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”                   β”‚
    β”‚    β”‚    β”‚ Benchmarksβ”‚  β”‚ OPTIMIZE β”‚                   β”‚
    β”‚    β”‚    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β”‚          β”‚                    β”‚
    β”‚    β”‚                  β”‚ Rightsizingβ”‚                   β”‚
    β”‚    β”‚                  β”‚ Reservationsβ”‚                  β”‚
    β”‚    β”‚    β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”‚ Spot/Preemptβ”‚                 β”‚
    β”‚    β”‚    β”‚ OPERATE  β”‚β—„β”€β”˜β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜                   β”‚
    β”‚    β”‚    β”‚          β”‚                                  β”‚
    β”‚    └────│ Policies β”‚                                  β”‚
    β”‚         β”‚ Governanceβ”‚                                 β”‚
    β”‚         β”‚ Automationβ”‚                                 β”‚
    β”‚         β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜                                  β”‚
    β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Phase 1 : Inform (Visibilite)

La phase Inform consiste a rendre les couts visibles et comprehensibles pour toutes les parties prenantes. C'est la fondation du FinOps.

  • Tagging Strategy : Mettre en place un plan de tags obligatoires (team, project, environment, cost-center)
  • Cost Allocation : Attribuer chaque dollar depense a un proprietaire identifie
  • Dashboards : Creer des tableaux de bord accessibles a tous les niveaux
  • Anomaly Detection : Configurer des alertes sur les ecarts de couts

Phase 2 : Optimize (Optimisation)

Une fois la visibilite acquise, l'optimisation cible les gaspillages et les opportunites d'economie.

  • Rightsizing : Ajuster la taille des ressources a l'usage reel
  • Reserved Instances / Savings Plans : Engagements a 1-3 ans pour des remises de 30-72%
  • Spot / Preemptible : Utiliser les capacites excessives a -60% a -90%
  • Storage Tiering : Migrer les donnees froides vers des classes de stockage moins cheres

Phase 3 : Operate (Gouvernance)

La phase Operate instaure les politiques et l'automatisation pour maintenir les gains dans la duree.

  • Policies : Regles automatiques (ex: arreter les instances dev le week-end)
  • Budgets & Alertes : Seuils budgetaires avec escalade automatique
  • Continuous Improvement : Revues FinOps hebdomadaires avec les equipes

Unit Economics : Mesurer la Valeur

Les Unit Economics mesurent le cout cloud par unite de valeur business. Au lieu de regarder le cout total, on mesure le cout par transaction, par utilisateur, ou par Go traite.

MetriqueFormuleExemple
Cout par transactionCout total / Nb transactions$0.003 / transaction
Cout par utilisateur actifCout total / MAU$1.20 / utilisateur / mois
Cout par Go ingereCout pipeline / Volume Go$0.15 / Go
Cout par requete analytiqueCout compute / Nb requetes$0.02 / requete
Cout par dollar de revenuCout cloud / Revenu$0.08 / $1 revenu

L'indicateur cle

Le ratio Cout Cloud / Revenu est l'indicateur FinOps le plus strategique. Les entreprises SaaS performantes visent un ratio inferieur a 15%. Au-dela de 25%, c'est un signal d'alarme.

Showback vs Chargeback

Showback

Visibilite sans facturation interne

  • Montre les couts par equipe sans impacter le budget
  • Sensibilise sans creer de friction
  • Ideal pour demarrer le FinOps
  • Responsabilisation douce

Chargeback

Facturation interne reelle

  • Chaque equipe paie reellement ses couts cloud
  • Forte incitation a l'optimisation
  • Necessite un tagging precis et mature
  • Risque de comportements contre-productifs

Spotify : Transformation FinOps a Grande Echelle

Spotify a reduit ses couts GCP de 40% en 18 mois grace a une approche FinOps structuree :

  • Phase 1 : Implementation d'un tagging obligatoire avec 98% de couverture en 6 mois
  • Phase 2 : Dashboards Showback par squad, revues hebdomadaires des couts
  • Phase 3 : Migration vers le Chargeback - chaque squad gere son budget cloud
  • Phase 4 : Automatisation du rightsizing avec Committed Use Discounts (CUD)
  • Resultat : Economie de $10M+ par an tout en doublant le volume de donnees traitees

Chargeback sans maturite

Implementer le Chargeback trop tot, avant d'avoir un tagging fiable et une culture FinOps etablie, cree des conflits entre equipes et des comportements d'evitement (equipes qui "cachent" des ressources dans d'autres comptes). Commencez toujours par le Showback.

Quelle est la difference entre EffectiveCost et BilledCost dans FOCUS ?
Le BilledCost est le montant facture brut. Le EffectiveCost integre les remises (Reserved Instances, Savings Plans, credits negocies). La difference entre les deux represente vos economies realisees grace aux engagements.
Quels sont les 3 personas cles du FinOps ?
1) FinOps Practitioner : pilote la pratique, cree les rapports, anime les revues. 2) Engineering Lead : responsable de l'optimisation technique (rightsizing, spot). 3) Finance/Procurement : gere les engagements, negocie les contrats, valide les budgets.

16. Optimisation des Couts par Plateforme

40 min Avance

Objectifs

  • Maitriser les leviers d'optimisation Snowflake : warehouse sizing, auto-suspend, clustering
  • Optimiser BigQuery : slots, partitioning, BI Engine
  • Reduire les couts Databricks : spot instances, Photon engine
  • Exploiter les options AWS : Reserved Instances, Spot, Savings Plans
  • Comparer les modeles de pricing entre plateformes

Chaque plateforme cloud a ses propres leviers d'optimisation. Un Data Architect doit connaitre ces specificites pour choisir la bonne plateforme ET la bonne configuration. J'ai vu des equipes diviser par 4 leur facture Snowflake simplement en ajustant la taille des warehouses et l'auto-suspend. La connaissance fine du pricing model est un superpower.

Optimisation Snowflake

Warehouse Sizing

Le choix de la taille du warehouse impacte directement les couts. Un warehouse trop grand gaspille des credits, un warehouse trop petit rallonge les requetes (et peut couter plus cher au final).

TailleCredits/HeureCas d'usage optimal
X-Small1Requetes simples, dashboards legers, dev/test
Small2Requetes analytiques moderees, BI standard
Medium4Transformations dbt, requetes complexes
Large8Gros volumes, joins multiples, data science
X-Large16Chargements massifs, requetes tres complexes
2X-Large+32+Cas exceptionnels, benchmarks
SQL - Snowflake
-- Strategie multi-warehouse optimisee
-- Warehouse dedie au chargement (ETL)
CREATE WAREHOUSE IF NOT EXISTS WH_ETL_LOAD
  WAREHOUSE_SIZE = 'MEDIUM'
  AUTO_SUSPEND = 60          -- Suspend apres 1 min d'inactivite
  AUTO_RESUME = TRUE
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 3      -- Auto-scaling jusqu'a 3 clusters
  SCALING_POLICY = 'ECONOMY' -- Privilegie l'economie vs la performance
  COMMENT = 'ETL loading - auto-scale economy mode';

-- Warehouse dedie aux analystes (BI)
CREATE WAREHOUSE IF NOT EXISTS WH_ANALYTICS
  WAREHOUSE_SIZE = 'SMALL'
  AUTO_SUSPEND = 120         -- 2 min, les analystes font des pauses
  AUTO_RESUME = TRUE
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 5
  SCALING_POLICY = 'STANDARD'
  COMMENT = 'Analytics queries - responsive scaling';

-- Warehouse dbt (transformations)
CREATE WAREHOUSE IF NOT EXISTS WH_DBT_TRANSFORM
  WAREHOUSE_SIZE = 'LARGE'
  AUTO_SUSPEND = 30          -- Suspend rapide entre les runs
  AUTO_RESUME = TRUE
  INITIALLY_SUSPENDED = TRUE -- Demarre eteint
  COMMENT = 'dbt transformations - large pour parallelisme';

-- Resource Monitor pour controler les couts
CREATE RESOURCE MONITOR RM_MONTHLY
  CREDIT_QUOTA = 5000
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 75 PERCENT DO NOTIFY
    ON 90 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE WH_ETL_LOAD SET RESOURCE_MONITOR = RM_MONTHLY;

Auto-Suspend : Le parametre le plus important

Le parametre AUTO_SUSPEND est le levier #1 d'economie Snowflake. Un warehouse a 60 secondes au lieu de 600 secondes (defaut) peut reduire les couts de 40%+. Regle d'or : ETL = 30-60s, BI interactive = 120-300s, Dev = 60s.

Clustering Keys

Les clustering keys optimisent les performances de requete en organisant physiquement les micro-partitions. Elles reduisent le volume de donnees scannees, donc les credits consommes.

SQL - Snowflake
-- Avant : scan complet de 500 Go a chaque requete
-- Apres clustering : scan de 12 Go seulement

ALTER TABLE sales.fact_transactions
  CLUSTER BY (transaction_date, store_region);

-- Verifier l'efficacite du clustering
SELECT SYSTEM$CLUSTERING_INFORMATION(
  'sales.fact_transactions',
  '(transaction_date, store_region)'
);
-- Objectif : average_depth proche de 1.0

Optimisation BigQuery

Modeles de Pricing

On-Demand (par requete)

  • $6.25 par To scanne
  • Pas d'engagement
  • Ideal si < 1 To/jour
  • Premiere To gratuite/mois
  • Risque : requetes couteuses imprevues

Capacity (Slots)

  • Autoscaler : $0.04/slot/heure
  • Editions : $0.048-$0.06/slot/heure
  • Ideal si > 1 To/jour
  • Cout predictible
  • Baseline + burst configurable
SQL - BigQuery
-- Partitioning : reduire le volume scanne
CREATE TABLE `project.dataset.events`
PARTITION BY DATE(event_timestamp)
CLUSTER BY user_id, event_type
AS SELECT * FROM `project.dataset.events_raw`;

-- Requete optimisee avec filtre sur partition
SELECT user_id, COUNT(*) as event_count
FROM `project.dataset.events`
WHERE DATE(event_timestamp) BETWEEN '2025-01-01' AND '2025-01-31'
  AND event_type = 'purchase'
GROUP BY user_id;
-- Scanne uniquement les partitions de janvier
-- au lieu de la table entiere

-- BI Engine : cache en memoire pour les dashboards
-- Activation via reservation BI Engine (1 Go minimum)
-- Reduit la latence a < 1 seconde et ne consomme
-- pas de slots pour les requetes en cache

BigQuery : 3 regles d'or

1) Toujours partitionner par date et clusterer par colonnes de filtre frequentes. 2) Utiliser SELECT explicite (jamais SELECT *). 3) Activer BI Engine pour les dashboards Looker/Data Studio - gain de 10x sur les couts de requetes recurrentes.

Optimisation Databricks

Spot Instances & Photon

Databricks permet d'utiliser des Spot Instances (AWS) ou Preemptible VMs (GCP) pour les worker nodes, reduisant les couts compute de 60 a 90%.

JSON - Databricks Cluster Config
{
  "cluster_name": "etl-production-optimized",
  "spark_version": "14.3.x-scala2.12",
  "node_type_id": "i3.xlarge",
  "driver_node_type_id": "i3.xlarge",
  "autoscale": {
    "min_workers": 2,
    "max_workers": 20
  },
  "aws_attributes": {
    "first_on_demand": 1,
    "availability": "SPOT_WITH_FALLBACK",
    "spot_bid_price_percent": 60,
    "zone_id": "eu-west-1a"
  },
  "runtime_engine": "PHOTON",
  "autotermination_minutes": 15,
  "custom_tags": {
    "team": "data-engineering",
    "cost-center": "CC-4200",
    "workload": "etl-batch"
  }
}

Photon Engine

Photon est le moteur d'execution vectorise natif C++ de Databricks. Il accelere les requetes SQL et les transformations Spark de 2x a 8x par rapport au moteur Spark classique. Malgre un cout DBU 30% plus eleve, le temps d'execution reduit resulte souvent en une economie nette de 20-50% grace a la reduction du temps cluster.

AWS : Reserved Instances, Spot & Savings Plans

OptionRemiseEngagementFlexibiliteCas d'usage
On-Demand0%AucunMaximaleDev, prototypage, pics imprevus
Reserved Instances30-72%1-3 ansFaible (type fixe)Workloads stables et previsibles
Savings Plans30-66%1-3 ansMoyenne ($/h engage)Usage stable, types variables
Spot Instances60-90%AucunInterruptibleBatch, ETL, ML training

Strategie hybride optimale

Pour une plateforme data typique, la repartition optimale est :

  • 60-70% Reserved / Savings Plans : Couverture de la baseline stable (data warehouse, orchestrateur, services permanents)
  • 20-30% Spot Instances : Workloads batch tolerants aux interruptions (ETL, training ML, Spark)
  • 5-10% On-Demand : Pics de charge imprevus, dev/test, nouvelles experimentations

Pinterest : Optimisation Multi-Levier

Pinterest a reduit sa facture AWS de $20M par an grace a une strategie d'optimisation multi-plateforme :

  • Spot Instances : 80% des clusters Spark migres vers Spot, economie de $8M/an
  • Graviton (ARM) : Migration des instances vers AWS Graviton, gain de 20% prix/performance
  • S3 Intelligent-Tiering : 40% du stockage migre automatiquement vers des classes moins cheres
  • Reserved Capacity : Engagement Savings Plans pour la baseline, remise moyenne de 45%
  • Rightsizing automatise : Outils internes pour redimensionner les instances sous-utilisees

Le syndrome du "toujours On-Demand"

Garder 100% de ses instances en On-Demand est l'un des gaspillages les plus courants. Si vous avez un workload stable depuis plus de 3 mois, il devrait etre couvert par un Reserved Instance ou Savings Plan. Chaque dollar de baseline non-engage est un dollar gaspille a 30-70%.

Quelle est la difference entre Reserved Instances et Savings Plans sur AWS ?
Reserved Instances sont liees a un type d'instance specifique dans une region donnee (ex: m5.xlarge us-east-1). Savings Plans sont un engagement en $/heure applicable a n'importe quel type d'instance/region (Compute SP) ou dans une famille (EC2 Instance SP). Les Savings Plans offrent plus de flexibilite avec des remises similaires.

17. Monitoring des Couts Cloud

35 min Intermediaire

Objectifs

  • Concevoir des dashboards de couts efficaces et actionnables
  • Implementer la detection d'anomalies sur les depenses cloud
  • Configurer des alertes budgetaires multi-niveaux
  • Definir une strategie de tagging robuste et enforceable
  • Mettre en place un monitoring en temps reel des couts

Le monitoring des couts est la colonne vertebrale du FinOps. Sans visibilite, pas d'optimisation. J'insiste toujours sur un point : un dashboard que personne ne regarde ne sert a rien. Concevez vos dashboards pour l'action, pas pour l'information. Chaque graphique doit repondre a la question "Que dois-je faire maintenant ?".

Architecture d'un Systeme de Monitoring des Couts

Architecture Monitoring FinOps
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                  SOURCES DE DONNEES COUT                     β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚ AWS CUR  β”‚ GCP      β”‚ Azure    β”‚ Snowflakeβ”‚ Databricks     β”‚
β”‚ (S3)     β”‚ Billing  β”‚ Cost Mgmtβ”‚ Usage    β”‚ Usage          β”‚
β”‚          β”‚ Export   β”‚ Export   β”‚ Views    β”‚ Logs           β”‚
β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
     β”‚          β”‚          β”‚          β”‚          β”‚
     β–Ό          β–Ό          β–Ό          β–Ό          β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚              INGESTION & NORMALISATION (FOCUS)              β”‚
β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”                  β”‚
β”‚  β”‚ Fivetran β”‚  β”‚ dbt      β”‚  β”‚ Custom   β”‚                  β”‚
β”‚  β”‚ / Airbyteβ”‚  β”‚ Transformβ”‚  β”‚ Scripts  β”‚                  β”‚
β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜                  β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                          β”‚
                          β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚              DATA WAREHOUSE (Couche Analytique)              β”‚
β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”     β”‚
β”‚  β”‚  Tables FOCUS normalisees + metriques derivees     β”‚     β”‚
β”‚  β”‚  - cost_daily_by_service                           β”‚     β”‚
β”‚  β”‚  - cost_daily_by_team                              β”‚     β”‚
β”‚  β”‚  - unit_economics_metrics                          β”‚     β”‚
β”‚  β”‚  - anomaly_scores                                  β”‚     β”‚
β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜     β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                          β”‚
              β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
              β–Ό           β–Ό           β–Ό
        β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β” β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
        β”‚ Dashboardsβ”‚ β”‚ Alertes  β”‚ β”‚ Rapports β”‚
        β”‚ (Looker/ β”‚ β”‚ (Slack/  β”‚ β”‚ (PDF/    β”‚
        β”‚  Grafana)β”‚ β”‚  Teams)  β”‚ β”‚  Email)  β”‚
        β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜ β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Strategie de Tagging

Le tagging est le fondement de toute attribution de couts. Sans tags fiables, le FinOps est impossible. Voici une strategie de tagging enterprise-grade :

TagObligatoireExempleObjectif
teamOuidata-engineeringAttribution a l'equipe responsable
projectOuicustomer-360Rattachement au projet
environmentOuiproduction / staging / devIdentification de l'environnement
cost-centerOuiCC-4200Imputation comptable
workload-typeRecommandeetl / analytics / mlClassification du workload
data-classificationRecommandepublic / internal / confidentialNiveau de sensibilite
owner-emailRecommandejean.dupont@company.comContact du responsable
auto-shutdownOptionneltrue / falseEligible a l'arret automatique
Terraform - Tag Enforcement
# Policy Terraform pour imposer le tagging obligatoire
resource "aws_organizations_policy" "require_tags" {
  name        = "RequireMandatoryTags"
  description = "Impose les tags obligatoires sur toutes les ressources"
  type        = "TAG"
  content     = jsonencode({
    tags = {
      team = {
        tag_key = {
          "@@assign" = "team"
        }
        enforced_for = {
          "@@assign" = [
            "ec2:instance",
            "s3:bucket",
            "rds:db",
            "redshift:cluster",
            "glue:job"
          ]
        }
      }
      environment = {
        tag_key = {
          "@@assign" = "environment"
        }
        tag_value = {
          "@@assign" = ["production", "staging", "development"]
        }
        enforced_for = {
          "@@assign" = [
            "ec2:instance",
            "s3:bucket",
            "rds:db"
          ]
        }
      }
      cost-center = {
        tag_key = {
          "@@assign" = "cost-center"
        }
        enforced_for = {
          "@@assign" = [
            "ec2:instance",
            "s3:bucket",
            "rds:db"
          ]
        }
      }
    }
  })
}

Detection d'Anomalies

La detection d'anomalies identifie automatiquement les ecarts de couts inhabituels avant qu'ils n'explosent la facture. Plusieurs approches sont possibles :

Python - Detection d'anomalies de couts
import pandas as pd
import numpy as np
from datetime import datetime, timedelta

def detect_cost_anomalies(df_costs, sensitivity=2.0):
    """
    Detecte les anomalies de couts avec une approche
    basee sur la moyenne mobile et l'ecart-type.

    Args:
        df_costs: DataFrame avec colonnes [date, service, daily_cost]
        sensitivity: multiplicateur d'ecart-type (2.0 = 95% CI)

    Returns:
        DataFrame avec anomalies detectees
    """
    anomalies = []

    for service in df_costs['service'].unique():
        svc_data = df_costs[df_costs['service'] == service].copy()
        svc_data = svc_data.sort_values('date')

        # Moyenne mobile sur 14 jours
        svc_data['rolling_mean'] = svc_data['daily_cost'].rolling(
            window=14, min_periods=7
        ).mean()

        # Ecart-type mobile
        svc_data['rolling_std'] = svc_data['daily_cost'].rolling(
            window=14, min_periods=7
        ).std()

        # Seuils
        svc_data['upper_bound'] = (
            svc_data['rolling_mean']
            + sensitivity * svc_data['rolling_std']
        )

        # Detecter les anomalies
        svc_data['is_anomaly'] = (
            svc_data['daily_cost'] > svc_data['upper_bound']
        )

        # Calculer le score d'anomalie (nombre d'ecarts-types)
        svc_data['anomaly_score'] = np.where(
            svc_data['rolling_std'] > 0,
            (svc_data['daily_cost'] - svc_data['rolling_mean'])
            / svc_data['rolling_std'],
            0
        )

        anomalies.append(svc_data[svc_data['is_anomaly']])

    result = pd.concat(anomalies, ignore_index=True)
    return result.sort_values('anomaly_score', ascending=False)

# Exemple d'utilisation
# anomalies = detect_cost_anomalies(cost_data, sensitivity=2.5)
# Envoyer les alertes pour anomaly_score > 3.0 (critique)

Budget Alerts Multi-Niveaux

Les alertes budgetaires doivent etre configurees en cascade avec des actions progressives :

SeuilActionDestinataireUrgence
50% du budgetNotification informativeFinOps TeamFaible
75% du budgetAlerte + rapport detailleFinOps + Tech LeadsMoyenne
90% du budgetAlerte urgente + revue obligatoireFinOps + VP EngineeringHaute
100% du budgetBlocage auto + escalade managementCTO + FinanceCritique
Anomalie > 3 sigmaAlerte immediate + investigationFinOps + On-CallCritique
Terraform - AWS Budget Alert
resource "aws_budgets_budget" "data_platform_monthly" {
  name         = "data-platform-monthly"
  budget_type  = "COST"
  limit_amount = "50000"
  limit_unit   = "USD"
  time_unit    = "MONTHLY"

  cost_filter {
    name   = "TagKeyValue"
    values = ["user:project$data-platform"]
  }

  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 75
    threshold_type            = "PERCENTAGE"
    notification_type         = "FORECASTED"
    subscriber_email_addresses = ["finops@company.com"]
    subscriber_sns_topic_arns  = [aws_sns_topic.finops_alerts.arn]
  }

  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 90
    threshold_type            = "PERCENTAGE"
    notification_type         = "ACTUAL"
    subscriber_email_addresses = [
      "finops@company.com",
      "vp-engineering@company.com"
    ]
    subscriber_sns_topic_arns = [aws_sns_topic.finops_critical.arn]
  }

  notification {
    comparison_operator       = "GREATER_THAN"
    threshold                 = 100
    threshold_type            = "PERCENTAGE"
    notification_type         = "ACTUAL"
    subscriber_email_addresses = [
      "cto@company.com",
      "finance@company.com"
    ]
  }
}

Monitoring Temps Reel

Le monitoring en temps reel detecte les problemes de couts avant qu'ils n'apparaissent sur la facture mensuelle. Les outils natifs cloud (AWS Cost Explorer, GCP Billing) ont un delai de 24-48h. Pour du vrai temps reel, il faut des solutions complementaires.

Stack de monitoring temps reel

  • CloudWatch Metrics + Lambda : Monitoring des metriques de consommation en quasi temps reel (5 min)
  • Kubecost : Monitoring des couts Kubernetes en temps reel avec allocation par namespace/pod
  • Infracost : Estimation des couts dans les Pull Requests avant le deploiement
  • Vantage / CloudZero : Plateformes FinOps avec detection d'anomalies en temps reel

Startup FinTech : $1.2M de Facture Surprise AWS

Une startup FinTech a decouvert une facture AWS de $1.2 million pour un seul mois, contre $80K habituellement :

  • Cause racine : Un developpeur a lance un cluster EMR de 200 instances r5.4xlarge pour un test de performance et a oublie de l'arreter pendant 3 semaines
  • Absence de tagging : Le cluster n'avait aucun tag, impossible a attribuer rapidement
  • Pas d'alertes : Aucun budget AWS configure, aucune alerte sur les depassements
  • Detection tardive : Decouvert uniquement lors de la reception de la facture mensuelle
  • Lecon : Apres cet incident, l'entreprise a deploye des alertes budgetaires, un tagging obligatoire via AWS SCP, et une politique d'auto-termination sur tous les clusters temporaires

Pas de gouvernance des couts

L'absence de gouvernance des couts est le premier anti-pattern FinOps. Sans tags obligatoires, sans alertes budgetaires et sans revues regulieres, les couts cloud derivent inevitablement. La regle : chaque ressource doit etre taguee, chaque budget doit avoir des alertes, et chaque equipe doit revoir ses couts chaque semaine.

Quel est le delai typique de detection d'anomalie avec les outils natifs cloud (AWS Cost Explorer, GCP Billing) ?
Les outils natifs cloud ont un delai de 24 a 48 heures pour refleter les couts reels. C'est pourquoi il est essentiel de completer avec du monitoring quasi temps reel (CloudWatch, Kubecost) pour detecter les anomalies critiques avant qu'elles n'apparaissent dans la facturation.

18. Lab : Construire un FinOps Dashboard

45 min Avance

Objectifs

  • Construire un pipeline d'ingestion des donnees de couts cloud
  • Creer un dashboard FinOps interactif avec alertes
  • Implementer des recommandations d'optimisation automatiques
  • Configurer des notifications Slack/Teams pour les anomalies

Ce lab vous guide dans la construction d'un vrai dashboard FinOps. L'objectif n'est pas de creer un outil parfait, mais de comprendre les composants cles et comment ils s'interconnectent. Dans la realite, vous utiliserez souvent des outils SaaS (Vantage, CloudZero, Kubecost), mais comprendre le fonctionnement interne vous permettra de mieux les configurer et les evaluer.

Lab : FinOps Cost Monitoring Dashboard

Etape 1 : Modelisation des Donnees de Couts (dbt)

Commencez par creer les modeles dbt pour normaliser les donnees de couts au format FOCUS :

SQL - dbt model: stg_aws_costs.sql
-- models/staging/stg_aws_costs.sql
WITH raw_cur AS (
    SELECT * FROM {{ source('aws_billing', 'cost_usage_report') }}
),

normalized AS (
    SELECT
        -- Identifiants FOCUS
        bill_payer_account_id    AS billing_account_id,
        line_item_usage_account_id AS sub_account_id,

        -- Periodes
        DATE(line_item_usage_start_date) AS usage_date,
        line_item_usage_start_date AS charge_period_start,
        line_item_usage_end_date   AS charge_period_end,

        -- Classification
        line_item_product_code   AS service_name,
        product_product_family   AS service_category,
        line_item_resource_id    AS resource_id,
        product_region           AS region,

        -- Couts
        line_item_unblended_cost AS billed_cost,
        COALESCE(
            reservation_effective_cost,
            savings_plan_savings_plan_effective_cost,
            line_item_unblended_cost
        ) AS effective_cost,

        -- Tags
        resource_tags_user_team        AS tag_team,
        resource_tags_user_project     AS tag_project,
        resource_tags_user_environment AS tag_environment,
        resource_tags_user_cost_center AS tag_cost_center,

        -- Meta
        line_item_line_item_type AS charge_type
    FROM raw_cur
    WHERE line_item_line_item_type NOT IN ('Credit', 'Refund')
)

SELECT * FROM normalized

Etape 2 : Modele d'Agregation par Equipe

SQL - dbt model: mart_cost_by_team.sql
-- models/marts/mart_cost_by_team.sql
WITH daily_costs AS (
    SELECT
        usage_date,
        COALESCE(tag_team, 'untagged') AS team,
        COALESCE(tag_project, 'unknown') AS project,
        COALESCE(tag_environment, 'unknown') AS environment,
        service_category,
        SUM(billed_cost)    AS total_billed_cost,
        SUM(effective_cost) AS total_effective_cost,
        COUNT(DISTINCT resource_id) AS resource_count
    FROM {{ ref('stg_aws_costs') }}
    GROUP BY 1, 2, 3, 4, 5
),

with_moving_avg AS (
    SELECT
        *,
        AVG(total_effective_cost) OVER (
            PARTITION BY team, service_category
            ORDER BY usage_date
            ROWS BETWEEN 13 PRECEDING AND CURRENT ROW
        ) AS cost_14d_avg,

        STDDEV(total_effective_cost) OVER (
            PARTITION BY team, service_category
            ORDER BY usage_date
            ROWS BETWEEN 13 PRECEDING AND CURRENT ROW
        ) AS cost_14d_stddev,

        -- Variation jour sur jour
        LAG(total_effective_cost) OVER (
            PARTITION BY team, service_category
            ORDER BY usage_date
        ) AS prev_day_cost
    FROM daily_costs
),

final AS (
    SELECT
        *,
        -- Score d'anomalie
        CASE
            WHEN cost_14d_stddev > 0 THEN
                (total_effective_cost - cost_14d_avg) / cost_14d_stddev
            ELSE 0
        END AS anomaly_score,

        -- Variation en pourcentage
        CASE
            WHEN prev_day_cost > 0 THEN
                ROUND((total_effective_cost - prev_day_cost)
                  / prev_day_cost * 100, 2)
            ELSE 0
        END AS day_over_day_pct,

        -- Flag anomalie
        CASE
            WHEN cost_14d_stddev > 0
            AND (total_effective_cost - cost_14d_avg)
                / cost_14d_stddev > 2.5
            THEN TRUE
            ELSE FALSE
        END AS is_anomaly
    FROM with_moving_avg
)

SELECT * FROM final

Etape 3 : Recommandations d'Optimisation Automatiques

SQL - dbt model: mart_optimization_recommendations.sql
-- models/marts/mart_optimization_recommendations.sql
WITH idle_resources AS (
    -- Ressources avec cout mais utilisation faible
    SELECT
        resource_id,
        service_name,
        tag_team,
        SUM(effective_cost) AS monthly_cost,
        'IDLE_RESOURCE' AS recommendation_type,
        'Ressource potentiellement inutilisee - '
        || 'verifier l''utilisation' AS recommendation,
        SUM(effective_cost) * 0.9 AS estimated_savings
    FROM {{ ref('stg_aws_costs') }}
    WHERE usage_date >= CURRENT_DATE - INTERVAL '30 days'
    AND service_category = 'Compute'
    GROUP BY 1, 2, 3
    HAVING SUM(effective_cost) > 100
    AND COUNT(DISTINCT usage_date) < 5
),

untagged_resources AS (
    -- Ressources sans tags obligatoires
    SELECT
        resource_id,
        service_name,
        'unknown' AS tag_team,
        SUM(effective_cost) AS monthly_cost,
        'MISSING_TAGS' AS recommendation_type,
        'Tags obligatoires manquants - '
        || 'ajouter team, project, environment' AS recommendation,
        0 AS estimated_savings
    FROM {{ ref('stg_aws_costs') }}
    WHERE usage_date >= CURRENT_DATE - INTERVAL '30 days'
    AND (tag_team IS NULL OR tag_project IS NULL)
    GROUP BY 1, 2
    HAVING SUM(effective_cost) > 50
),

spot_candidates AS (
    -- Instances On-Demand qui pourraient etre Spot
    SELECT
        resource_id,
        service_name,
        COALESCE(tag_team, 'unknown') AS tag_team,
        SUM(effective_cost) AS monthly_cost,
        'SPOT_CANDIDATE' AS recommendation_type,
        'Instance On-Demand eligible Spot - '
        || 'economie potentielle de 60-90%' AS recommendation,
        SUM(effective_cost) * 0.7 AS estimated_savings
    FROM {{ ref('stg_aws_costs') }}
    WHERE usage_date >= CURRENT_DATE - INTERVAL '30 days'
    AND charge_type = 'Usage'
    AND service_name = 'AmazonEC2'
    AND tag_environment IN ('development', 'staging')
    GROUP BY 1, 2, 3
    HAVING SUM(effective_cost) > 200
)

SELECT * FROM idle_resources
UNION ALL
SELECT * FROM untagged_resources
UNION ALL
SELECT * FROM spot_candidates
ORDER BY estimated_savings DESC

Etape 4 : Alertes Slack avec Python

Python - Alerte Slack FinOps
import requests
import json
from datetime import datetime

SLACK_WEBHOOK_URL = "https://hooks.slack.com/services/T.../B.../..."

def send_finops_alert(anomalies_df, recommendations_df):
    """
    Envoie un resume quotidien FinOps sur Slack
    avec anomalies et recommandations.
    """
    # Section anomalies
    anomaly_text = ""
    critical = anomalies_df[anomalies_df['anomaly_score'] > 3.0]
    if len(critical) > 0:
        anomaly_text = "*Anomalies critiques detectees :*\n"
        for _, row in critical.head(5).iterrows():
            anomaly_text += (
                f"  - {row['team']} / {row['service_category']}: "
                f"${row['total_effective_cost']:.0f} "
                f"(+{row['day_over_day_pct']:.0f}% vs veille, "
                f"score: {row['anomaly_score']:.1f})\n"
            )

    # Section recommandations
    top_savings = recommendations_df.head(5)
    reco_text = "*Top 5 recommandations d'optimisation :*\n"
    total_savings = 0
    for _, row in top_savings.iterrows():
        reco_text += (
            f"  - [{row['recommendation_type']}] "
            f"{row['recommendation']} "
            f"(${row['estimated_savings']:.0f}/mois)\n"
        )
        total_savings += row['estimated_savings']

    # Construction du message Slack
    payload = {
        "blocks": [
            {
                "type": "header",
                "text": {
                    "type": "plain_text",
                    "text": f"FinOps Daily Report - "
                            f"{datetime.now():%d/%m/%Y}"
                }
            },
            {
                "type": "section",
                "text": {
                    "type": "mrkdwn",
                    "text": anomaly_text if anomaly_text
                            else "*Aucune anomalie detectee*"
                }
            },
            {"type": "divider"},
            {
                "type": "section",
                "text": {
                    "type": "mrkdwn",
                    "text": reco_text
                }
            },
            {
                "type": "section",
                "text": {
                    "type": "mrkdwn",
                    "text": f"*Economie potentielle totale : "
                            f"${total_savings:,.0f}/mois*"
                }
            }
        ]
    }

    response = requests.post(
        SLACK_WEBHOOK_URL,
        json=payload,
        headers={"Content-Type": "application/json"}
    )
    return response.status_code == 200

Etape 5 : Validation et Tests

Validez votre dashboard en verifiant les points suivants :

  • Les donnees de couts s'actualisent quotidiennement
  • Les anomalies avec un score > 3.0 declenchent une alerte Slack
  • Les recommandations incluent les economies potentielles estimees
  • Les ressources sans tags sont identifiees et flaggees
  • Le dashboard affiche le cout par equipe, par service et par environnement

Pour aller plus loin

Dans un contexte reel, ajoutez : 1) Un rapport PDF hebdomadaire automatise envoye aux managers, 2) Des previsions de couts avec Prophet ou ARIMA, 3) L'integration avec Infracost pour les estimations pre-deploy dans les PR, 4) Un score de couverture de tagging par equipe.

19. Projet : Architecture d'une Cloud Data Platform Retail

60 min Avance

Objectifs

  • Concevoir une architecture cloud data platform complete pour une entreprise retail
  • Definir les exigences fonctionnelles et non-fonctionnelles
  • Choisir et justifier les technologies pour chaque couche
  • Planifier l'implementation en phases avec budget et timeline
  • Integrer les principes FinOps des la conception

Ce projet synthetise tout ce que vous avez appris dans la Phase 4. Vous allez concevoir une architecture complete, comme vous le feriez pour un client reel. Il n'y a pas de reponse unique : l'important est la coherence de vos choix architecturaux et votre capacite a les justifier. Documentez chaque decision avec un ADR (Architecture Decision Record).

Contexte du Projet

RetailCo - Transformation Data Cloud

RetailCo est un retailer francais avec 500 magasins, un site e-commerce et 8 millions de clients. L'entreprise souhaite migrer son infrastructure data on-premise vers le cloud pour accelerer l'innovation data-driven.

  • Chiffre d'affaires : 2.5 milliards EUR
  • Budget IT annuel : 3% du CA (75M EUR), dont 15M pour la data
  • Volume de donnees : 50 To actuels, croissance 30%/an
  • Sources : POS (caisses), e-commerce, CRM, supply chain, IoT (capteurs magasins)
  • Equipe data : 40 personnes (15 engineers, 10 analystes, 8 data scientists, 7 governance)
  • Exigences reglementaires : RGPD, donnees hebergees en EU

Phase 1 : Exigences et Contraintes

Exigences Fonctionnelles

DomaineExigencePriorite
AnalyticsReporting en temps reel des ventes par magasinP0 - Critique
AnalyticsAnalyse du panier moyen et des parcours clientsP0 - Critique
MLMoteur de recommandation produits personnaliseP1 - Haute
MLPrevision de la demande pour optimiser les stocksP1 - Haute
Data SharingPartage de donnees avec les fournisseurs strategiquesP2 - Moyenne
Real-timeDetection de fraude en temps reel sur les transactionsP1 - Haute
GovernanceConformite RGPD avec gestion du consentementP0 - Critique

Exigences Non-Fonctionnelles

CritereCible
Disponibilite99.9% (8.7h de downtime max/an)
Latence (real-time)< 5 secondes end-to-end
Latence (batch)< 2 heures pour refresh complet
ScalabiliteSupporter 3x le volume actuel sans re-architecture
Cout cloud cible< 60% du cout on-premise equivalent (objectif FinOps)
SecuriteChiffrement at-rest et in-transit, RBAC, audit complet

Phase 2 : Design de l'Architecture

Architecture Cloud Data Platform - RetailCo
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                        SOURCES                                   β”‚
β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€
β”‚  POS    β”‚ E-comm   β”‚  CRM     β”‚ Supply   β”‚  IoT Capteurs        β”‚
β”‚ (batch) β”‚ (stream) β”‚ (CDC)    β”‚ (API)    β”‚  (stream)            β”‚
β””β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
     β”‚         β”‚          β”‚          β”‚          β”‚
     β–Ό         β–Ό          β–Ό          β–Ό          β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                    INGESTION LAYER                                β”‚
β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”      β”‚
β”‚  β”‚ Fivetran β”‚  β”‚ Kafka /   β”‚  β”‚ Debezium β”‚  β”‚ Cloud    β”‚      β”‚
β”‚  β”‚ (batch)  β”‚  β”‚ Pub/Sub   β”‚  β”‚ (CDC)    β”‚  β”‚ Functionsβ”‚      β”‚
β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β”‚ (stream)  β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜      β”‚
β”‚                β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜                                     β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                         β”‚
                         β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                    STORAGE LAYER (Lakehouse)                      β”‚
β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”       β”‚
β”‚  β”‚              Cloud Storage (S3 / GCS)                 β”‚       β”‚
β”‚  β”‚         Delta Lake / Apache Iceberg (Open Format)     β”‚       β”‚
β”‚  β”œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€       β”‚
β”‚  β”‚  Bronze  β”‚  Silver  β”‚        Gold               β”‚       β”‚
β”‚  β”‚  (Raw)   β”‚(Cleaned) β”‚  (Business-ready)         β”‚       β”‚
β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”΄β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜       β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                         β”‚
                         β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                    COMPUTE LAYER                                  β”‚
β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”      β”‚
β”‚  β”‚Snowflake β”‚  β”‚ Databricksβ”‚  β”‚ Spark    β”‚  β”‚ Flink    β”‚      β”‚
β”‚  β”‚(SQL/BI)  β”‚  β”‚ (ML/ETL)  β”‚  β”‚(batch)   β”‚  β”‚(stream)  β”‚      β”‚
β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜      β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”¬β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
                         β”‚
              β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”Όβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
              β–Ό          β–Ό          β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚ Semantic β”‚  β”‚   ML     β”‚  β”‚   Data Sharing   β”‚
β”‚ Layer    β”‚  β”‚ Platform β”‚  β”‚   (Snowflake     β”‚
β”‚ (dbt +   β”‚  β”‚ (MLflow +β”‚  β”‚    Marketplace)  β”‚
β”‚  Looker) β”‚  β”‚  Sagemakerβ”‚ β”‚                  β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜
              β”‚          β”‚          β”‚
              β–Ό          β–Ό          β–Ό
β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”
β”‚                    CONSUMPTION LAYER                              β”‚
β”‚  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”  β”Œβ”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”      β”‚
β”‚  β”‚ Looker   β”‚  β”‚ Notebook β”‚  β”‚ APIs     β”‚  β”‚ Reverse  β”‚      β”‚
β”‚  β”‚ (BI)     β”‚  β”‚ (DS)     β”‚  β”‚ (Apps)   β”‚  β”‚ ETL      β”‚      β”‚
β”‚  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜  β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜      β”‚
β””β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”€β”˜

Phase 3 : Decisions Architecturales (ADR)

ADR-001 : Choix du Cloud Provider - GCP

Contexte : RetailCo n'a pas d'existant cloud significatif.

Decision : GCP comme cloud principal, avec Snowflake en SaaS multi-cloud.

Justification : GCP offre le meilleur rapport qualite-prix pour les workloads analytiques (BigQuery), des regions EU (Belgique, Pays-Bas, Zurich) pour la conformite RGPD, et une integration native avec Looker. Snowflake en surcouche pour le SQL warehouse et le data sharing avec les fournisseurs.

Risques : Lock-in GCP attenue par l'usage de formats ouverts (Iceberg, Delta) et Snowflake multi-cloud.

ADR-002 : Architecture Lakehouse avec Formats Ouverts

Decision : Architecture Medallion (Bronze/Silver/Gold) sur GCS avec Apache Iceberg.

Justification : Iceberg offre le time-travel, le schema evolution, et l'interoperabilite entre Snowflake, Spark et BigQuery. Les donnees restent dans un format ouvert, evitant le vendor lock-in.

ADR-003 : Strategie FinOps - Budget et Optimisation

Decision : Budget cloud annuel de 3.5M EUR (23% du budget data), avec objectif de 2.8M EUR apres optimisation.

Justification : Repartition cible : 60% Committed Use Discounts, 25% Spot/Preemptible, 15% On-Demand. Tagging obligatoire des le jour 1. Revues FinOps hebdomadaires. Showback par domaine (marketing, supply chain, finance).

Phase 4 : Plan d'Implementation

PhaseDureeLivrablesBudget
1 - Fondations3 moisInfrastructure cloud, CI/CD, governance, tagging400K EUR
2 - Data Lakehouse4 moisIngestion POS + e-commerce, Bronze/Silver/Gold, dbt600K EUR
3 - Analytics3 moisSemantic layer, dashboards Looker, KPIs metier500K EUR
4 - ML & Real-time4 moisRecommandation, prevision demande, streaming700K EUR
5 - Optimisation2 moisFinOps dashboard, data sharing, performance tuning300K EUR

Carrefour : Migration Cloud Data Platform

Carrefour a realise une transformation similaire avec GCP et BigQuery comme socle analytique :

  • Echelle : 12 000 magasins, 80 millions de clients, 20+ pays
  • Migration : 18 mois pour migrer depuis un data warehouse on-premise Teradata
  • Architecture : BigQuery + Dataflow (streaming) + Vertex AI (ML) + Looker (BI)
  • Resultats : Temps de traitement divise par 10, cout TCO reduit de 45%, time-to-insight de jours a minutes
  • FinOps : Equipe FinOps dediee de 4 personnes, flat-rate BigQuery avec slots partages

Livrable attendu

Pour ce projet, produisez un document de 5-10 pages incluant : 1) Contexte et exigences (reprendre et adapter), 2) Diagramme d'architecture complet, 3) 3 ADRs minimum avec justification, 4) Plan d'implementation phase avec budget, 5) Strategie FinOps detaillee avec KPIs. Presentez votre projet comme si vous etiez devant un comite d'architecture.

20. Examen Final - Phase 4 : Architecture Cloud Data Platform

30 min Evaluation Finale

Objectifs

  • Evaluer votre maitrise globale de l'architecture cloud data platform
  • Valider vos competences sur le design, les data contracts, les APIs et le FinOps
  • Verifier votre capacite a prendre des decisions architecturales justifiees
  • Confirmer votre preparation pour la Phase 5 : Engineering Avancee

Cet examen final couvre l'integralite de la Phase 4. Il teste non seulement vos connaissances theoriques mais aussi votre capacite a appliquer ces concepts dans des scenarios reels. Un score de 80% ou plus est requis pour valider la phase. Prenez votre temps, relisez chaque question attentivement, et justifiez mentalement votre choix avant de repondre.

Examen Final Phase 4 - Architecture Cloud Data Platform

Q1. Quelle architecture est la plus adaptee pour combiner les avantages du data lake (cout, flexibilite) et du data warehouse (performance, gouvernance) ?

Data Lake classique avec Hadoop HDFS
Data Lakehouse avec formats ouverts (Delta Lake / Iceberg)
Data Warehouse traditionnel on-premise
Base de donnees NoSQL distribuee

Correct ! Le Data Lakehouse combine stockage objet economique (lake) avec des capacites ACID, schema enforcement et performances SQL (warehouse) grace a des formats de table ouverts comme Delta Lake et Apache Iceberg.

Q2. Dans l'architecture Medallion (Bronze/Silver/Gold), quelle couche contient les donnees nettoyees, deduplicees et conformees mais non encore agregees pour un cas d'usage specifique ?

Bronze
Silver
Gold
Platinum

Correct ! La couche Silver contient les donnees nettoyees, deduplicees, conformees et validees. Elle represente la "single source of truth" de l'entreprise avant l'agregation specifique a un cas d'usage (qui se fait en Gold).

Q3. Quel service AWS est le plus adapte pour orchestrer des pipelines ETL serverless avec des transformations Spark, sans gerer de clusters ?

AWS EMR
AWS Lambda
AWS Glue
Amazon Redshift

Correct ! AWS Glue est un service ETL serverless qui execute des jobs Spark sans necessite de provisionner ou gerer des clusters. Il integre un catalogue de metadonnees (Glue Data Catalog) et supporte les transformations PySpark et Spark SQL.

Q4. Dans le framework TOGAF applique a la data architecture, quel livrable definit les principes, standards et guidelines qui gouvernent la conception de l'architecture data ?

Architecture Building Blocks (ABB)
Architecture Principles Document
Solution Building Blocks (SBB)
Architecture Requirements Specification

Correct ! L'Architecture Principles Document definit les principes fondamentaux qui guident toutes les decisions architecturales. Par exemple : "Les donnees sont un actif de l'entreprise", "Preference pour les formats ouverts", "Security by design".

Q5. Quel modele de securite est recommande pour une architecture data cloud moderne selon le principe Zero Trust ?

Securite perimetrique avec firewall reseau uniquement
Authentification basee sur IP source
Verification d'identite systematique a chaque acces avec RBAC, chiffrement end-to-end et audit continu
Acces ouvert avec monitoring post-hoc

Correct ! Le modele Zero Trust impose de ne jamais faire confiance par defaut : chaque requete est authentifiee et autorisee. Combine avec le RBAC (Role-Based Access Control), le chiffrement at-rest et in-transit, et l'audit continu, il forme la base de la securite cloud moderne.

Q6. Quel est le role principal du Semantic Layer dans une stack data moderne ?

Stocker les donnees de reference
Fournir des definitions metier coherentes et centralisees des metriques accessibles a tous les outils de consommation
Remplacer le data warehouse
Gerer les pipelines ETL

Correct ! Le Semantic Layer centralise les definitions metier (KPIs, metriques, dimensions) pour garantir que tous les outils de consommation (BI, notebooks, APIs) utilisent les memes calculs et definitions, eliminant les ecarts entre rapports.

Q7. Dans un Data Contract, quel element definit le temps de reponse garanti et les conditions de disponibilite du dataset ?

Le schema definition
Le SLA (Service Level Agreement)
Le data lineage
Le changelog

Correct ! Le SLA dans un Data Contract definit les engagements de service : disponibilite (ex: 99.9%), fraicheur (ex: donnees mises a jour toutes les heures), temps de reponse, et les procedures en cas de non-respect de ces engagements.

Q8. Quelle technologie est la plus adaptee pour virtualiser l'acces a des donnees reparties entre PostgreSQL, MongoDB et S3 sans les copier ?

Apache Kafka
Trino (anciennement PrestoSQL) ou Dremio
Apache Airflow
Terraform

Correct ! Trino et Dremio sont des moteurs de Data Virtualization qui permettent de requeter des sources heterogenes (relationnelles, NoSQL, object storage) via une interface SQL unifiee sans deplacer les donnees. Trino excelle en federation de requetes, Dremio ajoute une couche de reflexion (cache) pour les performances.

Q9. Dans le lifecycle FinOps, quelle phase consiste a mettre en place la visibilite des couts, l'allocation et les benchmarks ?

Optimize
Operate
Inform
Transform

Correct ! La phase Inform est la premiere du lifecycle FinOps. Elle etablit la visibilite en implementant le tagging, l'allocation des couts, les dashboards et les benchmarks. Sans Inform, les phases Optimize et Operate ne peuvent pas fonctionner efficacement.

Q10. Quel parametre Snowflake a le plus grand impact sur la reduction des couts de credit ?

WAREHOUSE_SIZE
AUTO_SUSPEND (avec une valeur basse)
MAX_CLUSTER_COUNT
SCALING_POLICY

Correct ! AUTO_SUSPEND est le parametre le plus impactant. Un warehouse qui se suspend apres 60 secondes au lieu de 600 (defaut) peut reduire les couts de 40%+. C'est la premiere optimisation a implementer sur tout compte Snowflake.

Q11. Pour un workload Spark batch quotidien tolerant aux interruptions sur AWS, quelle combinaison est la plus economique ?

Cluster EMR avec 100% On-Demand instances
Cluster EMR avec driver On-Demand et workers Spot Instances (fallback On-Demand)
Cluster EMR avec Reserved Instances sur 3 ans
AWS Lambda pour chaque transformation

Correct ! La combinaison optimale pour un batch tolerant aux interruptions est un driver On-Demand (stabilite du coordinateur) avec des workers Spot (economie de 60-90%). Le fallback On-Demand assure que le job se termine meme si des Spot sont reclamees. Les Reserved ne sont pas adaptees aux workloads intermittents.

Q12. Lors de la conception d'une architecture data platform pour une entreprise soumise au RGPD, quel principe architectural est le plus important a integrer des le debut ?

Performance-first : optimiser les temps de requete avant tout
Cost-first : minimiser les couts cloud en priorite
Privacy-by-design : integrer la protection des donnees personnelles dans l'architecture elle-meme (residency, pseudonymisation, droit a l'oubli, consentement)
Speed-first : livrer rapidement puis ajuster la conformite

Correct ! Le Privacy-by-Design est un principe fondamental du RGPD (Article 25). Il impose d'integrer la protection des donnees des la conception : data residency en EU, pseudonymisation native, mecanismes de suppression (droit a l'oubli), gestion du consentement. Retrofiter la conformite RGPD apres coup est extremement couteux et risque.

Resultats et prochaines etapes

10-12 bonnes reponses : Excellent ! Vous maitrisez l'architecture cloud data platform. Passez a la Phase 5.
7-9 bonnes reponses : Bon niveau. Revisez les lecons correspondant a vos erreurs avant de continuer.
Moins de 7 : Reprenez les modules 4.1, 4.2 et 4.3 avant de tenter a nouveau l'examen.

Recap : Les 10 Competences Cles du Data Architect Cloud

  • 1. Concevoir des architectures Lakehouse avec formats ouverts (Iceberg, Delta)
  • 2. Maitriser les services data des 3 clouds majeurs (AWS, GCP, Azure)
  • 3. Appliquer TOGAF et les frameworks enterprise a la data architecture
  • 4. Concevoir la securite Zero Trust et la conformite RGPD by design
  • 5. Definir et enforcer des Data Contracts entre producteurs et consommateurs
  • 6. Implementer une Semantic Layer pour la coherence metier
  • 7. Concevoir des Data APIs scalables (REST, GraphQL, gRPC)
  • 8. Appliquer les principes FinOps : Inform, Optimize, Operate
  • 9. Optimiser les couts par plateforme (Snowflake, BigQuery, Databricks)
  • 10. Monitorer les couts et detecter les anomalies en continu