Introduction Architecture Cloud
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.
| Ere | Periode | Caracteristiques | Limites |
|---|---|---|---|
| On-Premise | 2000-2010 | Data centers prives, Teradata, Oracle RAC, licences perpetuelles | CAPEX eleve, scalabilite limitee, delai de provisionnement |
| Cloud IaaS | 2010-2015 | VMs cloud (EC2), Hadoop sur cloud, lift-and-shift | Complexite operationnelle, sous-utilisation des services manages |
| Cloud PaaS/SaaS | 2015-2020 | Services manages (Redshift, BigQuery), separation compute/stockage | Vendor lock-in, couts imprevisibles |
| Cloud-Native | 2020+ | Serverless, Lakehouse, multi-cloud, FinOps, DataOps | Complexite 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.
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.
Data Lakehouse Architecture
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.
| Critere | Data Warehouse | Data Lake | Lakehouse |
|---|---|---|---|
| Transactions ACID | Oui | Non | Oui (via Delta/Iceberg) |
| Formats de donnees | Structurees uniquement | Toutes (struct, semi, non-struct) | Toutes avec schema enforcement |
| Cout de stockage | Eleve ($23/TB/mois Redshift) | Faible ($23/TB/mois S3) | Faible (stockage objet) |
| Performance SQL | Excellente | Variable | Excellente (indexation, caching) |
| Support ML/DS | Limite (export necessaire) | Natif (acces direct fichiers) | Natif (DataFrame + SQL) |
| Gouvernance | Mature (RBAC natif) | Faible (fichiers sur object store) | Unifiee (Unity Catalog) |
| Format ouvert | Non (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.
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.
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
# 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.
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.
AWS Data Platform
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.
| Service | Categorie | Cas d'usage | Modele de cout |
|---|---|---|---|
| S3 | Stockage | Data Lake, archivage, staging | $0.023/Go/mois (Standard) |
| Glue | ETL / Catalogue | Crawlers, jobs Spark, Data Catalog | DPU-heure ($0.44/DPU/h) |
| Athena | Query Engine | Requetes SQL sur S3 (serverless) | $5/To scanne |
| Redshift | Data Warehouse | BI interactive, requetes complexes | A partir de $0.25/h (dc2.large) |
| EMR | Big Data | Spark, Hive, Presto a grande echelle | Instance EC2 + surcharge EMR |
| Kinesis | Streaming | Ingestion temps reel, analytics streaming | $0.015/h/shard (Data Streams) |
| Lake Formation | Gouvernance | Controle d'acces, lineage, catalogage | Gratuit (paiement des services sous-jacents) |
| Step Functions | Orchestration | Pipelines serverless, workflows | $0.025/1000 transitions |
Architecture de reference AWS Data Platform
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.
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 ?
GCP Data Platform
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.
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.
-- 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
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.
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.
Azure & Microsoft Fabric
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.
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.
| Critere | Azure Databricks | Synapse Spark | Microsoft Fabric |
|---|---|---|---|
| Moteur Spark | Optimise (Photon) | Apache Spark standard | Spark + Delta optimise |
| Performance | Excellente (Photon 3-8x) | Bonne | Bonne a tres bonne |
| Gouvernance | Unity Catalog (mature) | Purview integration | Purview + OneLake |
| ML/DS | MLflow natif, Feature Store | Azure ML integration | ML integre (basique) |
| SQL Analytics | Databricks SQL (excellent) | SQL Pools (mature) | DWH integre |
| Streaming | Structured Streaming + DLT | Streaming basique | Real-Time Intelligence |
| Cout | DBU (premium Azure) | Inclus dans Synapse | Capacity 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.
TOGAF pour Data Architects
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.
+-------------------+
| 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 ADM | Application Data | Livrables cles |
|---|---|---|
| Preliminaire | Definir les principes data, le scope, l'equipe architecture | Principes d'architecture data, charte du comite data |
| A. Vision | Aligner la strategie data sur la strategie business | Data Strategy document, architecture vision statement |
| B. Business | Cartographier les processus metier consommateurs de donnees | Catalogue de processus metier, data use cases |
| C. Systemes | Concevoir les modeles de donnees et les flux | Modeles conceptuels/logiques, data flow diagrams, data catalog |
| D. Technologie | Choisir la plateforme cloud, les services, l'infrastructure | Architecture de reference, decision records (ADR) |
| E. Opportunites | Identifier les projets prioritaires et les quick wins | Portfolio de projets data, roadmap priorisee |
| F. Migration | Planifier la migration des donnees et la coexistence | Plan de migration 6R, strategie de coexistence, rollback plan |
| G. Gouvernance | Superviser l'implementation, valider la conformite | Architecture compliance reviews, deviation requests |
| H. Changement | Gerer les evolutions post-deploiement | Change 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.
# 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).
Enterprise Architecture
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.
| Perspective | What (Donnees) | How (Processus) | Where (Reseau) | Who (Personnes) | When (Temps) | Why (Motivation) |
|---|---|---|---|---|---|---|
| Scope (Planificateur) | Inventaire des entites metier | Liste des processus | Sites et localisations | Roles et organisations | Evenements metier | Objectifs strategiques |
| Business (Proprietaire) | Modele conceptuel | Modele de processus | Logistique metier | Workflow metier | Planning metier | Business plan |
| System (Concepteur) | Modele logique de donnees | Architecture applicative | Architecture distribuee | Architecture des roles | Architecture temporelle | Regles metier |
| Technology (Developpeur) | Modele physique | Design systeme | Architecture technologique | Interface utilisateur | Design temporel | Design des regles |
| Detail (Sous-traitant) | Definitions de donnees | Programmes | Architecture reseau | Architecture securite | Definitions temporelles | Definitions des regles |
| Enterprise (Utilisateur) | Donnees operationnelles | Systeme operationnel | Reseau operationnel | Organisation operationnelle | Planning operationnel | Strategie 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 :
+-----------------------------------------------------------------------+ | 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
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.
7. Security Architecture pour Data Platforms
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
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.
| Type | Methode | Standard | Cas d'usage |
|---|---|---|---|
| Au repos | AES-256-GCM | FIPS 140-2 | S3, BigQuery, ADLS |
| En transit | TLS 1.3 | PCI-DSS | APIs, replication, streaming |
| En traitement | Confidential Computing | SGX/SEV | Donnees sensibles en memoire |
| Cles | KMS / HSM | FIPS 140-3 | Gestion centralisee des cles |
# 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
# 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.
{
"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.
8. Quiz - Design de Data Platforms
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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
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
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 :
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
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
{
"$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 :
| Dimension | Metrique | Seuil Typique | Outil de Monitoring |
|---|---|---|---|
| Fraicheur | Temps depuis la derniere mise a jour | < 1h (near real-time) | Monte Carlo, Elementary |
| Disponibilite | Uptime du dataset | 99.9% | Datadog, PagerDuty |
| Completude | % de champs non-null requis | > 99.5% | Great Expectations, Soda |
| Conformite | % de lignes valides selon le schema | 100% | 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.
10. Semantic Layer - La Couche de Sens
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 (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.
# 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.
// 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.
11. Data APIs - Exposer les Donnees comme Produit
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
# 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
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.
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.
# 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.
| Niveau | Outil | TTL Typique | Cas d'usage |
|---|---|---|---|
| CDN / Edge | CloudFront, Fastly | 5-60 min | Metriques publiques, dashboards |
| API Gateway | Kong, Redis | 1-15 min | Requetes frequentes par consumer |
| Application | Redis, Memcached | 5-60 min | Resultats de requetes complexes |
| Pre-aggregation | Cube.js, Materialized Views | 1-24h | Metriques pre-calculees |
| Query Engine | Snowflake Result Cache | 24h | Cache natif du warehouse |
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.
12. Data Virtualization - Acces Unifie sans Copie
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.
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
| Critere | Denodo | Dremio | Trino (ex-Presto) |
|---|---|---|---|
| Type | Enterprise (proprietaire) | Lakehouse Engine (open core) | Open source (distribue) |
| Force | Federation multi-source, UI enterprise, gouvernance | Reflexions Iceberg, acceleration, self-service | Performance SQL, large ecosysteme connecteurs |
| Sources | 200+ connecteurs (SGBD, APIs, SaaS, fichiers) | Data Lakes (S3, ADLS), SGBD, APIs | SGBD, Hive, S3, Kafka, Elasticsearch |
| Caching | Cache multi-niveau intelligent | Reflections (materialized views) | Alluxio, result cache |
| Prix | Licence enterprise (cout eleve) | Open source + Cloud edition | Gratuit (open source) |
| Ideal pour | Grandes entreprises multi-sources | Lakehouse avec query federation | Equipes 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.
-- 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
-- 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
13. Lab Pratique - Data Contracts
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 :
# 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 :
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 :
{
"$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 :
"""
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 :
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 :
"""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
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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
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.
{
"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
ββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β 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.
| Metrique | Formule | Exemple |
|---|---|---|
| Cout par transaction | Cout total / Nb transactions | $0.003 / transaction |
| Cout par utilisateur actif | Cout total / MAU | $1.20 / utilisateur / mois |
| Cout par Go ingere | Cout pipeline / Volume Go | $0.15 / Go |
| Cout par requete analytique | Cout compute / Nb requetes | $0.02 / requete |
| Cout par dollar de revenu | Cout 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.
16. Optimisation des Couts par Plateforme
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).
| Taille | Credits/Heure | Cas d'usage optimal |
|---|---|---|
| X-Small | 1 | Requetes simples, dashboards legers, dev/test |
| Small | 2 | Requetes analytiques moderees, BI standard |
| Medium | 4 | Transformations dbt, requetes complexes |
| Large | 8 | Gros volumes, joins multiples, data science |
| X-Large | 16 | Chargements massifs, requetes tres complexes |
| 2X-Large+ | 32+ | Cas exceptionnels, benchmarks |
-- 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.
-- 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
-- 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%.
{
"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
| Option | Remise | Engagement | Flexibilite | Cas d'usage |
|---|---|---|---|---|
| On-Demand | 0% | Aucun | Maximale | Dev, prototypage, pics imprevus |
| Reserved Instances | 30-72% | 1-3 ans | Faible (type fixe) | Workloads stables et previsibles |
| Savings Plans | 30-66% | 1-3 ans | Moyenne ($/h engage) | Usage stable, types variables |
| Spot Instances | 60-90% | Aucun | Interruptible | Batch, 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%.
17. Monitoring des Couts Cloud
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
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β 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 :
| Tag | Obligatoire | Exemple | Objectif |
|---|---|---|---|
| team | Oui | data-engineering | Attribution a l'equipe responsable |
| project | Oui | customer-360 | Rattachement au projet |
| environment | Oui | production / staging / dev | Identification de l'environnement |
| cost-center | Oui | CC-4200 | Imputation comptable |
| workload-type | Recommande | etl / analytics / ml | Classification du workload |
| data-classification | Recommande | public / internal / confidential | Niveau de sensibilite |
| owner-email | Recommande | jean.dupont@company.com | Contact du responsable |
| auto-shutdown | Optionnel | true / false | Eligible a l'arret automatique |
# 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 :
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 :
| Seuil | Action | Destinataire | Urgence |
|---|---|---|---|
| 50% du budget | Notification informative | FinOps Team | Faible |
| 75% du budget | Alerte + rapport detaille | FinOps + Tech Leads | Moyenne |
| 90% du budget | Alerte urgente + revue obligatoire | FinOps + VP Engineering | Haute |
| 100% du budget | Blocage auto + escalade management | CTO + Finance | Critique |
| Anomalie > 3 sigma | Alerte immediate + investigation | FinOps + On-Call | Critique |
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.
18. Lab : Construire un FinOps Dashboard
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 :
-- 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
-- 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
-- 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
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
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
| Domaine | Exigence | Priorite |
|---|---|---|
| Analytics | Reporting en temps reel des ventes par magasin | P0 - Critique |
| Analytics | Analyse du panier moyen et des parcours clients | P0 - Critique |
| ML | Moteur de recommandation produits personnalise | P1 - Haute |
| ML | Prevision de la demande pour optimiser les stocks | P1 - Haute |
| Data Sharing | Partage de donnees avec les fournisseurs strategiques | P2 - Moyenne |
| Real-time | Detection de fraude en temps reel sur les transactions | P1 - Haute |
| Governance | Conformite RGPD avec gestion du consentement | P0 - Critique |
Exigences Non-Fonctionnelles
| Critere | Cible |
|---|---|
| Disponibilite | 99.9% (8.7h de downtime max/an) |
| Latence (real-time) | < 5 secondes end-to-end |
| Latence (batch) | < 2 heures pour refresh complet |
| Scalabilite | Supporter 3x le volume actuel sans re-architecture |
| Cout cloud cible | < 60% du cout on-premise equivalent (objectif FinOps) |
| Securite | Chiffrement at-rest et in-transit, RBAC, audit complet |
Phase 2 : Design de l'Architecture
βββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββββ
β 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
| Phase | Duree | Livrables | Budget |
|---|---|---|---|
| 1 - Fondations | 3 mois | Infrastructure cloud, CI/CD, governance, tagging | 400K EUR |
| 2 - Data Lakehouse | 4 mois | Ingestion POS + e-commerce, Bronze/Silver/Gold, dbt | 600K EUR |
| 3 - Analytics | 3 mois | Semantic layer, dashboards Looker, KPIs metier | 500K EUR |
| 4 - ML & Real-time | 4 mois | Recommandation, prevision demande, streaming | 700K EUR |
| 5 - Optimisation | 2 mois | FinOps dashboard, data sharing, performance tuning | 300K 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
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) ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
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