🟥 Niveau 3 : Avancé
🏛️ Data Architecture Patterns & Decision Making
Bienvenue dans ce module où tu vas apprendre à concevoir des architectures data et à prendre des décisions techniques éclairées. C'est le passage du "je sais coder" à "je sais architecturer".
Prérequis
| Niveau | Compétence |
|---|---|
| ✅ Requis | Tous les modules précédents (M01-M33) |
| ✅ Requis | Expérience sur des projets data réels |
| 💡 Recommandé | Avoir été confronté à des choix d'architecture |
🎯 Objectifs du module
À la fin de ce module, tu seras capable de :
- Connaître les patterns d'architecture data majeurs
- Appliquer un framework de décision structuré
- Rédiger des Architecture Decision Records (ADR)
- Faire du capacity planning réaliste
- Éviter les anti-patterns classiques
- Adapter l'architecture au contexte (startup vs enterprise)
1. Introduction : L'Art de l'Architecture Data
1.1 Qu'est-ce qu'un Architecte Data ?
┌─────────────────────────────────────────────────────────────────────────────┐
│ ÉVOLUTION DU DATA ENGINEER │
│ │
│ Junior Senior Staff/Principal │
│ ────── ────── ─────────────── │
│ │
│ "Comment faire" "Quoi faire" "Pourquoi faire" │
│ │
│ • Exécute les • Conçoit les • Définit la vision │
│ tâches pipelines • Prend les décisions │
│ • Suit les • Choisit les d'architecture │
│ patterns outils • Anticipe les │
│ • Apprend • Résout les problèmes futurs │
│ problèmes • Influence l'org │
│ complexes │
│ │
│ Focus: Code Focus: Système Focus: Stratégie │
└─────────────────────────────────────────────────────────────────────────────┘
1.2 Les Questions Fondamentales
Avant tout choix technique, pose-toi ces questions :
| Question | Pourquoi c'est important |
|---|---|
| Quel problème résout-on ? | Éviter le solutionnisme technologique |
| Quelles sont les contraintes ? | Budget, équipe, deadline, legacy |
| Quelle est l'échelle ? | 1 GB vs 1 PB = architectures très différentes |
| Quelle latence est acceptable ? | Batch vs Streaming |
| Qui va maintenir ? | Complexité vs compétences équipe |
| Comment ça va évoluer ? | Anticipation vs over-engineering |
1.3 Le Principe de la Solution la Plus Simple
┌─────────────────────────────────────────────────────────────────────────────┐
│ COMPLEXITÉ vs VALEUR │
│ │
│ Valeur │
│ Business │ ┌──── Zone Danger │
│ ▲ │ ╱ (over-engineering) │
│ │ │ ┌──────────╱ │
│ │ │ ╱ │
│ │ │ ╱ Zone Optimale │
│ │ │ ╱ (bon trade-off) │
│ │ │ ╱ │
│ │ │────╱ │
│ │ │ ╱ Zone Simple │
│ │ │ ╱ (MVP, quick wins) │
│ │ └──────────────────────────────────────────▶ │
│ Complexité Technique │
│ │
│ RÈGLE : Commence simple, complexifie seulement quand NÉCESSAIRE │
└─────────────────────────────────────────────────────────────────────────────┘
2. Patterns d'Architecture Data
2.1 Lambda vs Kappa vs Delta Architecture
┌─────────────────────────────────────────────────────────────────────────────┐
│ LAMBDA ARCHITECTURE │
│ │
│ ┌──────────────────┐ │
│ │ Batch Layer │ │
│ ┌───▶│ (Spark Batch) │───┐ │
│ ┌─────────┐ │ └──────────────────┘ │ ┌─────────────────┐ │
│ │ Source │─────┤ ├───▶│ Serving Layer │ │
│ └─────────┘ │ ┌──────────────────┐ │ └─────────────────┘ │
│ └───▶│ Speed Layer │───┘ │
│ │ (Streaming) │ │
│ └──────────────────┘ │
│ │
│ ✅ Accurate (batch) + Fast (streaming) │
│ ❌ 2 codebases à maintenir │
│ ❌ Complexité opérationnelle │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ KAPPA ARCHITECTURE │
│ │
│ ┌─────────┐ ┌──────────────────┐ ┌─────────────────┐ │
│ │ Source │────▶│ Stream Layer │────▶│ Serving Layer │ │
│ └─────────┘ │ (Kafka + Flink)│ └─────────────────┘ │
│ └──────────────────┘ │
│ │
│ ✅ Une seule codebase │
│ ✅ Simplicité opérationnelle │
│ ❌ Reprocessing = rejouer tout le stream │
│ ❌ Pas idéal pour ML training (besoin de batch) │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ DELTA ARCHITECTURE (Lakehouse) │
│ │
│ ┌─────────┐ ┌──────────────────┐ ┌─────────────────┐ │
│ │ Source │────▶│ Unified Layer │────▶│ Serving Layer │ │
│ └─────────┘ │ (Delta Lake) │ └─────────────────┘ │
│ │ │ │
│ │ Batch + Stream │ │
│ │ Same code/table │ │
│ └──────────────────┘ │
│ │
│ ✅ Une seule codebase │
│ ✅ Time travel pour reprocessing │
│ ✅ ACID transactions │
│ ✅ Batch et streaming sur mêmes tables │
└─────────────────────────────────────────────────────────────────────────────┘
2.2 Matrice de Décision : Lambda vs Kappa vs Delta
| Critère | Lambda | Kappa | Delta |
|---|---|---|---|
| Complexité ops | 🔴 Haute | 🟢 Basse | 🟢 Basse |
| Reprocessing | 🟢 Facile | 🔴 Difficile | 🟢 Facile |
| Latence | 🟡 Mixte | 🟢 Temps réel | 🟡 Near real-time |
| ML Training | 🟢 Bon | 🔴 Difficile | 🟢 Bon |
| Coût | 🔴 Élevé | 🟢 Modéré | 🟢 Modéré |
| Quand choisir | Legacy, besoins spécifiques | Pure streaming | Recommandé par défaut |
2.3 Batch vs Streaming vs Hybrid
┌─────────────────────────────────────────────────────────────────────────────┐
│ QUAND UTILISER QUOI ? │
│ │
│ BATCH STREAMING HYBRID │
│ ───── ───────── ────── │
│ │
│ • Reports quotidiens • Fraud detection • La plupart │
│ • ML training • Real-time reco des cas │
│ • Data warehouse refresh • Alerting │
│ • Backfill historique • IoT monitoring Batch pour │
│ • Live dashboards historique, │
│ Latence: heures Latence: secondes Streaming pour │
│ temps réel │
│ │
│ 💡 RÈGLE : Si "temps réel" n'est pas un VRAI besoin business, │
│ commence par BATCH. C'est plus simple et moins cher. │
└─────────────────────────────────────────────────────────────────────────────┘
2.4 Questions pour Choisir Batch vs Streaming
| Question | Si OUI → | Si NON → |
|---|---|---|
| Le business perd de l'argent si latence > 1 min ? | Streaming | Batch |
| Les données arrivent en continu 24/7 ? | Streaming | Batch |
| L'équipe a de l'expérience streaming ? | Streaming OK | Batch d'abord |
| Budget ops illimité ? | Streaming OK | Batch moins cher |
| Use case = alerting/fraud/monitoring ? | Streaming | Batch souvent OK |
2.5 Data Lake vs Data Warehouse vs Lakehouse
┌─────────────────────────────────────────────────────────────────────────────┐
│ DATA LAKE vs WAREHOUSE vs LAKEHOUSE │
│ │
│ DATA LAKE DATA WAREHOUSE LAKEHOUSE │
│ ───────── ────────────── ───────── │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ S3/GCS │ │ Snowflake │ │ Delta Lake │ │
│ │ (files) │ │ Redshift │ │ Iceberg │ │
│ │ │ │ BigQuery │ │ │ │
│ │ Raw + Semi │ │ Structured │ │ Unified │ │
│ │ structured │ │ only │ │ │ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ ✅ Cheap storage ✅ Fast queries ✅ Best of both │
│ ✅ Flexible ✅ ACID ✅ ACID │
│ ✅ All data types ✅ Governance ✅ Open formats │
│ ❌ No ACID ❌ Expensive ✅ ML + Analytics │
│ ❌ Query perf ❌ Vendor lock-in ✅ Streaming │
│ ❌ Data swamp risk ❌ ETL required │
│ │
│ 📅 2010s 📅 2000s-now 📅 2020s+ │
└─────────────────────────────────────────────────────────────────────────────┘
2.6 Recommandation Moderne
┌─────────────────────────────────────────────────────────────────────────────┐
│ RECOMMANDATION 2024+ │
│ │
│ DÉFAUT : Lakehouse (Delta/Iceberg) + Compute séparé (Spark/Trino) │
│ │
│ EXCEPTIONS : │
│ │
│ • Équipe 100% SQL, pas de ML → Cloud DW (Snowflake, BigQuery) │
│ • Budget serré, petit volume → DuckDB + Parquet │
│ • Enterprise legacy → Conserver DW existant, ajouter Lake │
│ • Real-time OLAP → ClickHouse/Druid en complément │
└─────────────────────────────────────────────────────────────────────────────┘
2.7 Patterns de Data Modeling
┌─────────────────────────────────────────────────────────────────────────────┐
│ MEDALLION ARCHITECTURE │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ BRONZE │────▶│ SILVER │────▶│ GOLD │ │
│ │ (Raw) │ │ (Cleaned) │ │ (Aggregated)│ │
│ └─────────────┘ └─────────────┘ └─────────────┘ │
│ │
│ • Ingestion brute • Déduplication • Business metrics │
│ • Append-only • Validation • Dimensional models │
│ • Schemaless OK • Enrichissement • Ready for BI │
│ • Schema enforced │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ DIMENSIONAL MODELING (Kimball) │
│ │
│ ┌───────────────┐ │
│ │ dim_date │ │
│ └───────┬───────┘ │
│ ┌───────────────┐ │ ┌───────────────┐ │
│ │ dim_customer │───────────┼───────────│ dim_product │ │
│ └───────────────┘ │ └───────────────┘ │
│ ┌──────┴──────┐ │
│ │ fact_sales │ │
│ └─────────────┘ │
│ │
│ ✅ Optimisé pour BI/reporting │
│ ✅ Facile à comprendre │
│ ❌ Redondance (dénormalisation) │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ DATA VAULT │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │ HUB │────▶│ LINK │◀────│ HUB │ │
│ │(Customer)│ │ (Order) │ │(Product)│ │
│ └────┬────┘ └─────────┘ └────┬────┘ │
│ │ │ │
│ ┌────▼────┐ ┌────▼────┐ │
│ │SATELLITE│ │SATELLITE│ │
│ │(attrs) │ │(attrs) │ │
│ └─────────┘ └─────────┘ │
│ │
│ ✅ Historisation complète │
│ ✅ Flexibilité (ajout sources facile) │
│ ❌ Complexe à implémenter │
│ ❌ Queries plus complexes │
└─────────────────────────────────────────────────────────────────────────────┘
2.8 Quand Utiliser Quel Modeling ?
| Pattern | Quand l'utiliser | Quand éviter |
|---|---|---|
| Medallion | Lakehouse, ETL moderne, ML | Petit projet sans layers |
| Dimensional (Kimball) | BI/Reporting, DW classique | Data science, ML features |
| Data Vault | Enterprise, audit strict, multi-sources | Startup, MVP, équipe petite |
| One Big Table (OBT) | Analytics simple, ML features | Beaucoup de dimensions |
3. Framework de Décision
3.1 Le Process de Décision
┌─────────────────────────────────────────────────────────────────────────────┐
│ FRAMEWORK DE DÉCISION ARCHITECTURE │
│ │
│ 1. DEFINE 2. DISCOVER 3. DECIDE 4. DOCUMENT │
│ ────────── ────────── ──────── ───────── │
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ Quel │ │ Quelles │ │ Évaluer │ │ ADR │ │
│ │ problème │─────▶│ options │──────▶│ trade- │──────▶│ (écrit) │ │
│ │ ? │ │ ? │ │ offs │ │ │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ • Requirements • 3-5 options • Matrice • Contexte │
│ • Constraints • Recherche • PoC si doute • Décision │
│ • Success criteria • Benchmarks • Consensus • Conséquences │
└─────────────────────────────────────────────────────────────────────────────┘
3.2 Template de Requirements
pythonVoir le code
# Template de Requirements pour une décision d'architecture
requirements_template = """
# ═══════════════════════════════════════════════════════════════
# REQUIREMENTS DOCUMENT
# ═══════════════════════════════════════════════════════════════
## 1. Contexte
- Projet : [Nom du projet]
- Date : [Date]
- Auteur : [Ton nom]
- Stakeholders : [Qui est impacté]
## 2. Problème à résoudre
[Description claire du problème en 2-3 phrases]
## 3. Functional Requirements (FR)
- FR1 : [Ce que le système DOIT faire]
- FR2 : [Ce que le système DOIT faire]
- FR3 : [...]
## 4. Non-Functional Requirements (NFR)
### Performance
- Latence max : [X secondes/minutes]
- Throughput : [X events/sec ou X GB/jour]
- Concurrent users : [X]
### Scalabilité
- Volume actuel : [X GB]
- Volume dans 1 an : [X GB]
- Volume dans 3 ans : [X GB]
### Disponibilité
- SLA cible : [99.9% ?]
- Downtime acceptable : [X heures/mois]
- RTO (Recovery Time) : [X heures]
- RPO (Data Loss) : [X minutes]
### Sécurité
- Données sensibles : [Oui/Non]
- Compliance : [GDPR, HIPAA, SOC2...]
- Encryption : [At rest, in transit]
## 5. Contraintes
- Budget : [X €/mois]
- Timeline : [Date de livraison]
- Équipe : [X personnes, compétences]
- Legacy : [Systèmes existants à intégrer]
- Vendor : [Restrictions cloud/vendor]
## 6. Critères de succès
- [ ] [Critère mesurable 1]
- [ ] [Critère mesurable 2]
- [ ] [Critère mesurable 3]
"""
print(requirements_template)3.3 Matrice de Décision
pythonVoir le code
import pandas as pd
# Exemple : Choisir un orchestrateur
criteria = {
'Critère': [
'Facilité d\'apprentissage',
'Scalabilité',
'Communauté/Support',
'Coût opérationnel',
'Intégration cloud',
'Fonctionnalités avancées'
],
'Poids': [3, 4, 3, 4, 3, 2], # Importance 1-5
'Airflow': [3, 5, 5, 3, 4, 5], # Score 1-5
'Prefect': [4, 4, 3, 4, 3, 4],
'Dagster': [3, 4, 3, 4, 3, 5],
'Step Functions': [4, 5, 4, 5, 5, 3]
}
df = pd.DataFrame(criteria)
# Calcul des scores pondérés
for option in ['Airflow', 'Prefect', 'Dagster', 'Step Functions']:
df[f'{option}_weighted'] = df['Poids'] * df[option]
# Totaux
totals = {
'Option': ['Airflow', 'Prefect', 'Dagster', 'Step Functions'],
'Score Total': [
df['Airflow_weighted'].sum(),
df['Prefect_weighted'].sum(),
df['Dagster_weighted'].sum(),
df['Step Functions_weighted'].sum()
]
}
print("📊 MATRICE DE DÉCISION : Choix d'Orchestrateur")
print("="*60)
print(df[['Critère', 'Poids', 'Airflow', 'Prefect', 'Dagster', 'Step Functions']].to_string(index=False))
print("\n📈 SCORES TOTAUX (pondérés) :")
print("-"*40)
for opt, score in zip(totals['Option'], totals['Score Total']):
print(f" {opt:20} : {score}")
print("\n✅ Recommandation : " + totals['Option'][totals['Score Total'].index(max(totals['Score Total']))])4. Architecture Decision Records (ADR)
4.1 Pourquoi Documenter les Décisions ?
┌─────────────────────────────────────────────────────────────────────────────┐
│ PROBLÈME CLASSIQUE │
│ │
│ Nouveau développeur : "Pourquoi on utilise Kafka et pas RabbitMQ ?" │
│ │
│ Équipe : "Euh... c'était là quand je suis arrivé." │
│ "Je crois que c'est Jean qui a décidé, mais il est parti." │
│ "On a toujours fait comme ça." │
│ │
│ RÉSULTAT : │
│ • Décisions remises en question sans contexte │
│ • Mêmes erreurs répétées │
│ • Perte de temps à rediscuter │
│ │
│ SOLUTION : Architecture Decision Records (ADR) │
└─────────────────────────────────────────────────────────────────────────────┘
4.2 Format ADR
pythonVoir le code
# Template ADR (Architecture Decision Record)
adr_template = """
# ADR-001 : [Titre de la décision]
## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]
## Date
2024-XX-XX
## Context
[Quel est le problème ? Pourquoi cette décision est nécessaire ?]
## Decision Drivers
- [Driver 1 : ex. "Besoin de traiter 10K events/sec"]
- [Driver 2 : ex. "Équipe familière avec Python"]
- [Driver 3 : ex. "Budget limité à X€/mois"]
## Considered Options
1. [Option A]
2. [Option B]
3. [Option C]
## Decision
[Quelle option a été choisie et POURQUOI]
## Consequences
### Positives
- [Conséquence positive 1]
- [Conséquence positive 2]
### Negatives
- [Conséquence négative 1]
- [Trade-off accepté]
### Risks
- [Risque identifié et mitigation]
## Related
- [Lien vers ADR connexes]
- [Lien vers documentation]
"""
print(adr_template)pythonVoir le code
# Exemple concret d'ADR
adr_example = """
# ADR-003 : Choix de Delta Lake comme Table Format
## Status
Accepted
## Date
2024-03-15
## Context
Notre Data Lake sur S3 souffre de plusieurs problèmes :
- Pas de transactions ACID (corruptions lors d'échecs de jobs)
- Pas de schema enforcement (colonnes manquantes non détectées)
- Updates/deletes impossibles (GDPR compliance)
- Pas de time travel pour debug
Nous devons choisir un table format pour résoudre ces problèmes.
## Decision Drivers
- Besoin d'ACID pour éviter les corruptions
- Support GDPR (delete user data)
- Équipe utilise déjà Spark 3.x
- Pas de budget pour Databricks
- Préférence pour l'open source
## Considered Options
1. **Delta Lake (OSS)** - Format Databricks, maintenant open source
2. **Apache Iceberg** - Format Netflix, très actif
3. **Apache Hudi** - Format Uber, orienté CDC
4. **Rester sur Parquet brut** - Status quo
## Decision
Nous choisissons **Delta Lake (Open Source)** car :
1. Meilleure intégration Spark (notre stack principale)
2. Documentation extensive et communauté active
3. Migration facile depuis Parquet (CONVERT TO DELTA)
4. Fonctionnalités matures (MERGE, time travel, schema evolution)
5. Pas de dépendance à Databricks (version OSS suffit)
Iceberg était un close second, mais l'écosystème Spark+Delta
est plus mature en 2024.
## Consequences
### Positives
- ACID transactions → plus de corruptions
- Time travel → debug et audit facilités
- Schema enforcement → erreurs détectées tôt
- MERGE → GDPR compliance possible
### Negatives
- Légère courbe d'apprentissage équipe
- Vacuum à scheduler régulièrement
- Pas de support Trino natif (workaround existe)
### Risks
- Databricks pourrait réduire investissement OSS
→ Mitigation : Iceberg comme plan B, migration possible
## Related
- ADR-001 : Choix de S3 comme storage
- ADR-002 : Choix de Spark comme compute engine
"""
print(adr_example)4.3 Organisation des ADRs
docs/
└── architecture/
└── decisions/
├── README.md # Index des ADRs
├── 0001-use-s3-storage.md
├── 0002-choose-spark.md
├── 0003-delta-lake.md
├── 0004-airflow-orchestration.md
└── template.md # Template pour nouvelles ADRs
4.4 Bonnes Pratiques ADR
| ✅ DO | ❌ DON'T |
|---|---|
| Écrire au moment de la décision | Écrire des mois après |
| Inclure le contexte complet | Supposer que le lecteur sait |
| Documenter les options rejetées | Ne documenter que le choix final |
| Lister les trade-offs acceptés | Prétendre que c'est parfait |
| Mettre à jour le status | Laisser des ADRs obsolètes actifs |
5. Sizing & Capacity Planning
5.1 Estimer le Storage
pythonVoir le code
# Calculator de Storage
def estimate_storage(
events_per_day: int,
avg_event_size_bytes: int,
retention_days: int,
compression_ratio: float = 0.1, # Parquet/Delta = ~10x compression
replication_factor: int = 1,
growth_rate_monthly: float = 0.1 # 10% growth/month
) -> dict:
"""
Estime le storage nécessaire pour un Data Lake.
"""
# Calcul de base
raw_daily_gb = (events_per_day * avg_event_size_bytes) / (1024**3)
compressed_daily_gb = raw_daily_gb * compression_ratio
# Avec retention
total_gb = compressed_daily_gb * retention_days * replication_factor
# Projection 1 an avec croissance
monthly_growth = 1 + growth_rate_monthly
total_1year_gb = total_gb * (monthly_growth ** 12)
return {
"daily_raw_gb": round(raw_daily_gb, 2),
"daily_compressed_gb": round(compressed_daily_gb, 2),
"total_current_gb": round(total_gb, 2),
"total_1year_gb": round(total_1year_gb, 2),
"monthly_cost_s3_standard": round(total_gb * 0.023, 2), # $0.023/GB
"monthly_cost_1year": round(total_1year_gb * 0.023, 2),
}
# Exemple : E-commerce
result = estimate_storage(
events_per_day=10_000_000, # 10M events/jour
avg_event_size_bytes=500, # 500 bytes/event (JSON)
retention_days=365, # 1 an de rétention
compression_ratio=0.1, # Parquet compresse ~10x
growth_rate_monthly=0.15 # 15% croissance/mois
)
print("📊 ESTIMATION STORAGE")
print("="*50)
print(f" Daily raw data : {result['daily_raw_gb']} GB")
print(f" Daily compressed : {result['daily_compressed_gb']} GB")
print(f" Total current : {result['total_current_gb']} GB ({result['total_current_gb']/1024:.1f} TB)")
print(f" Total in 1 year : {result['total_1year_gb']} GB ({result['total_1year_gb']/1024:.1f} TB)")
print(f"\n💰 COÛT S3 (Standard)")
print(f" Current monthly : ${result['monthly_cost_s3_standard']}")
print(f" In 1 year monthly : ${result['monthly_cost_1year']}")5.2 Estimer le Compute
pythonVoir le code
# Calculator de Compute Spark
def estimate_spark_cluster(
data_to_process_gb: float,
processing_time_target_hours: float,
complexity_factor: float = 1.0, # 1.0 = simple ETL, 2.0 = joins complexes, 3.0 = ML
memory_per_gb_data: float = 2.0, # 2GB RAM pour 1GB data (rule of thumb)
) -> dict:
"""
Estime la taille d'un cluster Spark.
"""
# Mémoire totale nécessaire
total_memory_gb = data_to_process_gb * memory_per_gb_data * complexity_factor
# Throughput cible
throughput_gb_per_hour = data_to_process_gb / processing_time_target_hours
# Sizing nodes (ex: r5.2xlarge = 64GB RAM, 8 cores)
node_memory_gb = 64
node_cores = 8
num_nodes = max(1, int(total_memory_gb / (node_memory_gb * 0.75))) # 75% usable
# Coût (r5.2xlarge on-demand = ~$0.50/hour)
hourly_cost = num_nodes * 0.50
job_cost = hourly_cost * processing_time_target_hours
return {
"total_memory_needed_gb": round(total_memory_gb, 0),
"throughput_gb_per_hour": round(throughput_gb_per_hour, 1),
"recommended_nodes": num_nodes,
"total_cores": num_nodes * node_cores,
"total_memory_gb": num_nodes * node_memory_gb,
"hourly_cost": round(hourly_cost, 2),
"job_cost": round(job_cost, 2),
}
# Exemple : Job ETL quotidien
result = estimate_spark_cluster(
data_to_process_gb=500, # 500 GB à traiter
processing_time_target_hours=2, # En 2 heures max
complexity_factor=1.5, # ETL avec quelques joins
)
print("🖥️ ESTIMATION CLUSTER SPARK")
print("="*50)
print(f" Memory needed : {result['total_memory_needed_gb']} GB")
print(f" Throughput target : {result['throughput_gb_per_hour']} GB/hour")
print(f"\n📊 CLUSTER SIZING (r5.2xlarge)")
print(f" Nodes recommended : {result['recommended_nodes']}")
print(f" Total cores : {result['total_cores']}")
print(f" Total memory : {result['total_memory_gb']} GB")
print(f"\n💰 COÛT")
print(f" Hourly : ${result['hourly_cost']}")
print(f" Per job : ${result['job_cost']}")
print(f" Monthly (1 job/day) : ${result['job_cost'] * 30:.0f}")5.3 Règles de Capacity Planning
┌─────────────────────────────────────────────────────────────────────────────┐
│ RÈGLES DE SIZING │
│ │
│ STORAGE │
│ ─────── │
│ • Prévoir 2-3x le volume actuel pour la croissance │
│ • Parquet/Delta = 5-10x compression vs JSON/CSV │
│ • Ajouter 20% pour les metadata, logs, temp files │
│ │
│ SPARK MEMORY │
│ ──────────── │
│ • 2-4 GB RAM par 1 GB de données à traiter │
│ • Joins/aggregations complexes = x2 ou x3 │
│ • Broadcast joins si une table < 10 MB │
│ │
│ SPARK PARALLELISM │
│ ───────────────── │
│ • 2-4 partitions par core │
│ • Partition size idéale = 128 MB - 256 MB │
│ • Trop de partitions = overhead scheduling │
│ │
│ KAFKA │
│ ───── │
│ • Partitions = throughput / 10 MB/s (par partition) │
│ • Replication factor = 3 (production) │
│ • Retention = jours nécessaires pour replay │
│ │
│ CLICKHOUSE │
│ ────────── │
│ • 1 core = ~100-500 MB/s scan rate │
│ • RAM = 10-20% du dataset fréquemment queryé │
└─────────────────────────────────────────────────────────────────────────────┘
6. Anti-Patterns à Éviter
6.1 Resume-Driven Development
┌─────────────────────────────────────────────────────────────────────────────┐
│ ❌ RESUME-DRIVEN DEVELOPMENT │
│ │
│ "On devrait utiliser Kubernetes + Kafka + Flink + Delta Lake + │
│ GraphQL + Terraform + ArgoCD pour notre dashboard interne │
│ qui a 10 utilisateurs." │
│ │
│ SYMPTÔMES : │
│ • Choisir une techno parce que "ça fait bien sur le CV" │
│ • Over-engineering pour des use cases simples │
│ • Stack incompréhensible par l'équipe │
│ • Coûts d'infrastructure disproportionnés │
│ │
│ SOLUTION : │
│ • "Boring technology" d'abord │
│ • Justifier CHAQUE ajout de complexité │
│ • Demander : "Est-ce que PostgreSQL suffirait ?" │
└─────────────────────────────────────────────────────────────────────────────┘
6.2 Cargo Cult Architecture
┌─────────────────────────────────────────────────────────────────────────────┐
│ ❌ CARGO CULT ARCHITECTURE │
│ │
│ "Netflix utilise X, donc on devrait utiliser X." │
│ │
│ SYMPTÔMES : │
│ • Copier l'architecture des FAANG sans comprendre le contexte │
│ • Ignorer les différences d'échelle (10 users vs 100M users) │
│ • Ignorer les différences de budget et d'équipe │
│ │
│ RÉALITÉ : │
│ • Netflix a des milliers d'ingénieurs │
│ • Leur échelle justifie la complexité │
│ • Ce qui marche pour eux ne marchera pas pour toi │
│ │
│ SOLUTION : │
│ • Comprendre POURQUOI ils ont fait ce choix │
│ • Évaluer si tes contraintes sont similaires │
│ • Adapter, ne pas copier aveuglément │
└─────────────────────────────────────────────────────────────────────────────┘
6.3 Autres Anti-Patterns
| Anti-Pattern | Description | Solution |
|---|---|---|
| Premature Optimization | Optimiser avant de mesurer | Mesurer d'abord, optimiser ensuite |
| Golden Hammer | "Spark pour tout !" | Choisir l'outil adapté au problème |
| Not Invented Here | Refuser les solutions existantes | Évaluer buy vs build objectivement |
| Analysis Paralysis | Trop d'analyse, pas d'action | Time-box les décisions, PoC rapides |
| Shiny Object Syndrome | Adopter chaque nouvelle techno | Attendre la maturité, évaluer les risques |
| Distributed Monolith | Microservices trop couplés | Si tout doit être déployé ensemble = monolith |
7. Case Studies
7.1 Startup vs Enterprise
┌─────────────────────────────────────────────────────────────────────────────┐
│ STARTUP (< 50 personnes, < $1M ARR) │
│ │
│ CONTRAINTES : ARCHITECTURE RECOMMANDÉE : │
│ • Budget limité • Managed services (BigQuery, │
│ • Équipe petite (1-3 DE) Snowflake, Fivetran) │
│ • Time-to-market critique • Pas de Kubernetes │
│ • Besoins qui changent vite • PostgreSQL > Data Lake │
│ • dbt Cloud > dbt Core │
│ RÈGLE : Minimiser l'ops, • Éviter le self-hosted │
│ maximiser la vélocité │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ SCALE-UP (50-500 personnes, $10M+ ARR) │
│ │
│ CONTRAINTES : ARCHITECTURE RECOMMANDÉE : │
│ • Volume croissant rapidement • Lakehouse (Delta/Iceberg) │
│ • Équipe data 5-20 personnes • Spark + Kubernetes │
│ • Besoin de gouvernance • Airflow managed ou K8s │
│ • Multi-équipes consomment data • Data Catalog (DataHub) │
│ • Data Contracts │
│ RÈGLE : Investir dans la plateforme, │
│ mais rester pragmatique │
└─────────────────────────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────────────────────────┐
│ ENTERPRISE (500+ personnes) │
│ │
│ CONTRAINTES : ARCHITECTURE RECOMMANDÉE : │
│ • Legacy systems à intégrer • Data Mesh │
│ • Compliance stricte (GDPR, SOX) • Platform team dédié │
│ • Équipes data 50+ personnes • Self-serve analytics │
│ • Multi-cloud possible • Strong governance │
│ • Budgets importants • Lineage & cataloging │
│ • Hybrid cloud │
│ RÈGLE : Gouvernance + autonomie │
│ des domaines │
└─────────────────────────────────────────────────────────────────────────────┘
7.2 Case Study : E-Commerce
┌─────────────────────────────────────────────────────────────────────────────┐
│ CASE STUDY : E-COMMERCE PLATFORM │
│ │
│ CONTEXTE : │
│ • 1M commandes/jour │
│ • 50M products │
│ • Besoin : Real-time inventory, recommendations, fraud detection │
│ │
│ ARCHITECTURE : │
│ │
│ ┌─────────────┐ ┌─────────┐ ┌─────────────┐ │
│ │ Sources │────▶│ Kafka │────▶│ Flink │──┬──▶ Redis (reco) │
│ │ (orders, │ │ │ │ (streaming) │ │ │
│ │ clicks, │ └────┬────┘ └─────────────┘ └──▶ Alerts (fraud)│
│ │ inventory) │ │ │
│ └─────────────┘ │ ┌─────────────┐ ┌─────────────┐ │
│ └─────────▶│ Spark │────▶│ Delta Lake │ │
│ │ (batch) │ │ (Lakehouse) │ │
│ └─────────────┘ └──────┬──────┘ │
│ │ │
│ ┌──────▼──────┐ │
│ │ ClickHouse │ │
│ │ (dashboards)│ │
│ └─────────────┘ │
│ │
│ DÉCISIONS CLÉS : │
│ • Kafka : source of truth pour events │
│ • Flink : real-time pour fraud (< 1s latency) │
│ • Spark : batch pour ML training, heavy transformations │
│ • ClickHouse : OLAP pour dashboards (vs query Delta direct) │
└─────────────────────────────────────────────────────────────────────────────┘
7.3 Case Study : FinTech
┌─────────────────────────────────────────────────────────────────────────────┐
│ CASE STUDY : FINTECH (Trading Platform) │
│ │
│ CONTEXTE : │
│ • Compliance stricte (audit, GDPR) │
│ • Low latency critique (< 100ms) │
│ • Data retention 7 ans │
│ • Exactitude 100% requise │
│ │
│ DÉCISIONS SPÉCIFIQUES : │
│ │
│ 1. IMMUTABILITÉ │
│ • Append-only tables (jamais update/delete) │
│ • Event sourcing pattern │
│ • Full audit trail │
│ │
│ 2. EXACTITUDE │
│ • Decimal types (jamais float pour l'argent !) │
│ • Idempotency sur tous les pipelines │
│ • Reconciliation batch quotidienne │
│ │
│ 3. RETENTION │
│ • Hot storage : 30 jours (SSD) │
│ • Warm storage : 1 an (HDD) │
│ • Cold storage : 7 ans (S3 Glacier) │
│ • Lifecycle policies automatisées │
│ │
│ 4. COMPLIANCE │
│ • Data Catalog obligatoire │
│ • PII tagging automatique │
│ • Access logs + alerts │
└─────────────────────────────────────────────────────────────────────────────┘
8. Checklist Architecture Review
Utilise cette checklist pour valider une architecture avant de l'implémenter :
pythonVoir le code
# Checklist Architecture Review
checklist = """
# ═══════════════════════════════════════════════════════════════
# ARCHITECTURE REVIEW CHECKLIST
# ═══════════════════════════════════════════════════════════════
## 1. PROBLEM DEFINITION
- [ ] Le problème business est clairement défini
- [ ] Les requirements sont documentés
- [ ] Les success criteria sont mesurables
- [ ] Les contraintes sont identifiées (budget, temps, équipe)
## 2. SOLUTION FIT
- [ ] La solution résout le problème (pas plus, pas moins)
- [ ] Les alternatives ont été considérées
- [ ] Une solution plus simple a été évaluée
- [ ] L'ADR est rédigé
## 3. SCALABILITÉ
- [ ] Volume actuel supporté
- [ ] Croissance 1 an anticipée
- [ ] Croissance 3 ans anticipée
- [ ] Bottlenecks identifiés et plan de mitigation
## 4. RELIABILITY
- [ ] SLA défini et réaliste
- [ ] Single points of failure identifiés
- [ ] Disaster recovery plan
- [ ] Monitoring et alerting prévu
## 5. OPÉRABILITÉ
- [ ] L'équipe a les compétences nécessaires
- [ ] Documentation prévue
- [ ] Runbooks pour incidents
- [ ] On-call rotation définie
## 6. COÛTS
- [ ] Coûts estimés (storage, compute, licenses)
- [ ] Budget approuvé
- [ ] Optimisations identifiées (spot instances, reserved, etc.)
- [ ] Alertes coûts configurées
## 7. SÉCURITÉ
- [ ] Données sensibles identifiées
- [ ] Encryption at rest et in transit
- [ ] Access control (RBAC)
- [ ] Audit logging
## 8. ÉVOLUTIVITÉ
- [ ] Architecture modulaire
- [ ] Pas de vendor lock-in critique
- [ ] Migration possible si besoin
- [ ] Backward compatibility considérée
## VALIDATION FINALE
- [ ] Review par un pair
- [ ] Stakeholders informés
- [ ] Go/No-Go decision
"""
print(checklist)9. Exercices Pratiques
Exercice 1 : Analyse de Requirements
Une startup de livraison de repas te demande de concevoir leur data platform :
- 50K commandes/jour, croissance 20%/mois
- Besoin de dashboards temps réel pour les opérations
- Équipe : 2 data engineers (expérience Python/SQL)
- Budget : $5K/mois max
- Timeline : 2 mois pour le MVP
Questions :
- Quels sont les requirements fonctionnels et non-fonctionnels ?
- Quelle architecture recommandes-tu ? Pourquoi ?
- Quels outils spécifiques ?
- Quels sont les risques et mitigations ?
Exercice 2 : ADR Writing
Rédige un ADR complet pour le choix suivant :
"Utiliser Airflow plutôt que Prefect pour l'orchestration"
Inclus : context, options considérées, décision, conséquences.
Exercice 3 : Capacity Planning
Une plateforme IoT génère :
- 10,000 devices
- Chaque device envoie 1 event/seconde
- Chaque event = 200 bytes
- Retention : 90 jours
Calcule :
- Volume quotidien (raw et compressé)
- Volume total avec retention
- Coût S3 mensuel estimé
- Sizing Kafka (partitions recommandées)
Exercice 4 : Anti-Pattern Detection
Analyse cette proposition d'architecture et identifie les anti-patterns :
"Pour notre app interne avec 50 utilisateurs, je propose :
- Kubernetes cluster avec 10 nodes
- Kafka avec 100 partitions
- Flink pour le streaming
- Cassandra pour le stockage
- Elasticsearch pour le search
- Custom ML pipeline from scratch"
Exercice 5 : Case Study Analysis
Compare les architectures data de :
- Uber (https://eng.uber.com/)
- Airbnb (https://medium.com/airbnb-engineering)
- Spotify (https://engineering.atspotify.com/)
Pour chaque :
- Quels sont leurs principaux défis data ?
- Quelles solutions ont-ils adoptées ?
- Qu'est-ce qui est applicable à une entreprise plus petite ?
📚 Ressources
Articles & Blogs
- Designing Data-Intensive Applications — Martin Kleppmann (THE book)
- Architecture of Open Source Applications
- High Scalability Blog
- Netflix Tech Blog
ADR Resources
Architecture Patterns
➡️ Prochaine étape
👉 Module suivant : 35_leadership_tradeoffs — Leadership & Trade-offs in Data Engineering
🎉 Félicitations ! Tu maîtrises maintenant les patterns d'architecture et la prise de décision.