1. AWS Data Services - Resume
| Categorie | Service | Usage Principal | Tarification |
| Ingestion | Amazon Kinesis | Streaming temps reel | Par shard/heure + volume |
| Ingestion | AWS DMS | Migration de bases de donnees | Par instance de replication |
| Ingestion | Amazon AppFlow | Integration SaaS (Salesforce, SAP) | Par flux execute |
| Ingestion | Amazon MSK | Apache Kafka manage | Par broker/heure |
| Traitement | AWS Glue | ETL serverless (Spark) | Par DPU/heure |
| Traitement | Amazon EMR | Hadoop/Spark clusters | Par instance EC2 + surcharge EMR |
| Traitement | AWS Lambda | Micro-traitements event-driven | Par requete + duree |
| Traitement | AWS Step Functions | Orchestration de workflows | Par transition d'etat |
| Stockage | Amazon S3 | Object storage (Data Lake) | Par Go/mois + requetes |
| Stockage | AWS Lake Formation | Gouvernance Data Lake | Gratuit (services sous-jacents payants) |
| Stockage | Amazon RDS / Aurora | Bases relationnelles gerees | Par instance + stockage |
| Serving | Amazon Redshift | Data Warehouse | Par noeud/heure ou Serverless |
| Serving | Amazon Athena | Requetes SQL sur S3 | Par To de donnees scannees |
| Serving | Amazon QuickSight | BI et visualisation | Par utilisateur/mois |
| ML | Amazon SageMaker | Machine Learning | Par instance + stockage |
Astuce AWS : Utilisez S3 Intelligent-Tiering pour reduire automatiquement les couts de stockage de 40-70% sur les donnees peu accedees.
2. GCP Data Services - Resume
| Categorie | Service | Usage Principal | Tarification |
| Ingestion | Pub/Sub | Messaging temps reel | Par volume de messages |
| Ingestion | Datastream | CDC (Change Data Capture) | Par Go traite |
| Ingestion | Transfer Service | Transfert de donnees en masse | Gratuit (egress payant) |
| Traitement | Dataflow | Apache Beam manage (batch+stream) | Par vCPU + memoire + stockage |
| Traitement | Dataproc | Hadoop/Spark manages | Par VM + surcharge Dataproc |
| Traitement | Cloud Composer | Apache Airflow manage | Par environnement + compute |
| Traitement | Dataform | Transformation SQL dans BigQuery | Inclus avec BigQuery |
| Stockage | Cloud Storage (GCS) | Object storage | Par Go/mois + operations |
| Stockage | Cloud SQL | MySQL/PostgreSQL/SQL Server | Par instance + stockage |
| Stockage | Cloud Spanner | BDD relationnelle distribuee globale | Par noeud/heure + stockage |
| Stockage | Bigtable | NoSQL wide-column (IoT, timeseries) | Par noeud/heure + stockage |
| Serving | BigQuery | Data Warehouse serverless | On-demand (par To) ou Slots |
| Serving | Looker | BI et analytics | Par licence utilisateur |
| ML | Vertex AI | Plateforme ML unifiee | Par ressource consommee |
Astuce GCP : BigQuery est ideal pour commencer - aucun cluster a gerer, vous ne payez que les requetes executees. Utilisez le partitionnement et le clustering pour reduire les couts de 80%+.
3. Azure Data Services - Resume
| Categorie | Service | Usage Principal | Tarification |
| Ingestion | Event Hubs | Streaming evenements | Par unite de debit/heure |
| Ingestion | Data Factory | ETL/ELT orchestration | Par activite + pipeline |
| Ingestion | IoT Hub | Ingestion IoT | Par edition + messages |
| Traitement | Synapse Analytics | Analytics unifie (SQL+Spark) | Serverless ou pools dedies |
| Traitement | HDInsight | Hadoop/Spark/Kafka manages | Par VM + stockage |
| Traitement | Databricks (Azure) | Plateforme Lakehouse | Par DBU + VM |
| Stockage | ADLS Gen2 | Data Lake (HNS sur Blob) | Par Go/mois + operations |
| Stockage | Cosmos DB | NoSQL multi-modele global | Par RU/s + stockage |
| Stockage | SQL Database | SQL Server manage | Par vCore ou DTU |
| Serving | Power BI | BI et reporting | Par utilisateur ou capacite |
| Gouvernance | Microsoft Purview | Catalogue et lignage de donnees | Par capacite |
| Plateforme | Microsoft Fabric | Plateforme analytique unifiee | Par CU (Capacity Units) |
Astuce Azure : Microsoft Fabric unifie Data Factory, Synapse, Power BI et Data Activator en une seule plateforme SaaS avec facturation simplifiee par capacite.
4. Composants du Lakehouse
ARCHITECTURE LAKEHOUSE - COMPOSANTS CLES
=========================================
COUCHE SERVING : BI (Looker, PowerBI, Tableau) | ML (MLflow, SageMaker) | APIs
|
COUCHE GOLD : Tables agreges, metriques business, dimensions conformees
| Transformations : dbt, Spark SQL, Dataform
|
COUCHE SILVER : Donnees nettoyees, deduplication, validation de qualite
| Outils : Great Expectations, Soda, dbt tests
|
COUCHE BRONZE : Donnees brutes, schema-on-read, append-only
| Ingestion : CDC, batch loads, streaming
|
FORMAT DE TABLE : Apache Iceberg | Delta Lake | Apache Hudi
| Fonctionnalites : ACID, Time Travel, Schema Evolution
|
STOCKAGE OBJET : S3 | GCS | ADLS Gen2 | MinIO (on-premise)
Format : Parquet (colonnes), ORC, Avro (lignes)
Medallion Architecture - Regles
| Couche | Objectif | Qualite | Acces |
| Bronze | Copie fidele des sources | Aucun nettoyage | Data Engineers uniquement |
| Silver | Donnees conformees et nettoyees | Tests de qualite appliques | Data Scientists, Analystes avances |
| Gold | Metriques business-ready | Validee et documentee | Business Users, BI |
5. Comparaison des Open Table Formats
| Critere | Apache Iceberg | Delta Lake | Apache Hudi |
| Origine | Netflix (2017), Apache | Databricks (2019), Linux Foundation | Uber (2016), Apache |
| Transactions ACID | Oui (snapshot isolation) | Oui (optimistic concurrency) | Oui (MVCC) |
| Time Travel | Oui (snapshots) | Oui (versioning) | Oui (timeline) |
| Schema Evolution | Excellente (full evolution) | Bonne (merge schema) | Bonne |
| Partition Evolution | Oui (hidden partitioning) | Non (necessite rewrite) | Non |
| Moteurs compatibles | Spark, Flink, Trino, Dremio, Snowflake, BigQuery | Spark, Flink, Trino (connecteur) | Spark, Flink, Presto |
| Upsert / Merge | Merge Into (v2) | Merge Into natif | Natif (Copy-on-Write / Merge-on-Read) |
| Compaction | Rewrite data files | Optimize + Z-Order | Compaction inline/async |
| Adoption 2024-2025 | En forte croissance (standard emergent) | Dominant sur Databricks | Niche (streaming CDC) |
| Recommandation | Multi-moteur, vendor-neutral | Ecosysteme Databricks | CDC / streaming lourd |
Tendance 2025 : Apache Iceberg devient le standard de facto grace a son adoption par Snowflake, BigQuery, AWS, Dremio et sa compatibilite multi-moteur. Privilegiez Iceberg pour les nouveaux projets.
6. TOGAF - Checklist des Artefacts Data Architecture
Phase C - Architecture des Donnees (ADM)
- Data Entity / Business Object Catalog - Liste des entites metier
- Logical Data Model - Modele conceptuel des relations entre entites
- Data Dissemination Diagram - Flux de donnees entre systemes
- Data Lifecycle Diagram - Etats des donnees (creation, archivage, purge)
- Data Security Diagram - Classification et protections par niveau
- Data Migration Diagram - Plan de migration depuis les systemes legacy
- Data Flow Diagrams - Flux detailles entre composants techniques
- Physical Data Model - Schema physique (tables, colonnes, types, index)
Matrice TOGAF pour les Donnees
| Artefact | Vue | Audience |
| Catalogue d'entites | Business | Product Owners, Metier |
| Modele logique | Logique | Data Architects, Analystes |
| Diagramme de flux | Logique/Physique | Data Engineers, Architects |
| Modele physique | Physique | Data Engineers, DBA |
| Diagramme de securite | Transverse | CISO, DPO, Architects |
| Plan de migration | Transition | Program Managers, Engineers |
7. Checklist Securite des Donnees
Defense en Profondeur - 6 Couches
Couche 1 - RESEAU : VPC, Private Link, Firewall, IP Whitelisting
Couche 2 - IDENTITE : IAM, SSO/SAML, MFA, Service Accounts
Couche 3 - ACCES : RBAC, ABAC, Row-Level Security, Column-Level Security
Couche 4 - CHIFFREMENT : At-rest (AES-256), In-transit (TLS 1.3), BYOK/CMK
Couche 5 - MASQUAGE : Dynamic Data Masking, Tokenisation, Anonymisation
Couche 6 - AUDIT : Logging, SIEM, Alertes, Data Access History
Exemples de Code Securite
-- Row-Level Security (Snowflake)
CREATE OR REPLACE ROW ACCESS POLICY region_policy
AS (region VARCHAR) RETURNS BOOLEAN ->
CURRENT_ROLE() = 'ADMIN'
OR region = CURRENT_SESSION()::region_allowed;
-- Column-Level Security (BigQuery)
CREATE OR REPLACE ROW ACCESS POLICY
project.dataset.table_policy
ON project.dataset.customers
GRANT TO ("group:analysts@company.com")
FILTER USING (country = SESSION_USER_COUNTRY());
-- Dynamic Data Masking (Snowflake)
CREATE MASKING POLICY email_mask AS (val STRING)
RETURNS STRING ->
CASE
WHEN CURRENT_ROLE() IN ('ADMIN','DATA_STEWARD')
THEN val
ELSE REGEXP_REPLACE(val, '.+@', '***@')
END;
Zero Trust Data : Ne jamais faire confiance implicitement. Chaque acces aux donnees doit etre authentifie, autorise, chiffre et audite, meme au sein du reseau interne.
8. Template de Data Contract
---
# Data Contract v1.0
dataContractSpecification: "0.9.3"
id: "urn:datacontract:orders:v2"
info:
title: "Orders Data Contract"
version: "2.1.0"
owner: "team-commerce"
contact:
email: "data-commerce@company.com"
description: "Contrat pour les donnees de commandes clients"
servers:
production:
type: "bigquery"
project: "prod-analytics"
dataset: "commerce"
models:
orders:
description: "Table des commandes"
fields:
order_id:
type: "string"
required: true
unique: true
description: "Identifiant unique de la commande"
customer_id:
type: "string"
required: true
pii: true
classification: "confidential"
order_date:
type: "timestamp"
required: true
total_amount:
type: "decimal"
required: true
description: "Montant total en euros"
status:
type: "string"
enum: ["pending", "confirmed", "shipped", "delivered", "cancelled"]
quality:
type: "SodaCL"
specification:
checks for orders:
- row_count > 0
- freshness(order_date) < 2h
- duplicate_count(order_id) = 0
- invalid_percent(status) = 0
sla:
availability: "99.9%"
freshness: "2 hours"
latency_p95: "5 seconds"
support_response: "4 hours"
terms:
usage: "analytics, reporting, ml-training"
retention: "7 years"
gdpr: "Contains PII - requires DPA"
9. FinOps - Optimisation des Couts Data
Strategies par Plateforme
| Strategie | Snowflake | BigQuery | Databricks |
| Compute | Auto-suspend warehouses (1-5 min), multi-cluster scaling | Slot reservations (flex/annual), BI Engine cache | Spot/Preemptible instances, Photon engine |
| Stockage | Clustering keys, micro-partitions, transient tables | Partitionnement, clustering, materialized views | Delta optimize, Z-Order, vacuum |
| Requetes | Result cache, query acceleration, resource monitors | Requetes sur colonnes specifiques, LIMIT avant dev | Adaptive query, disk cache, broadcast join |
| Gouvernance | Resource Monitors avec alertes et suspend auto | Custom quotas par projet, budget alerts | Cluster policies, pool instances |
| Economie typique | 30-60% avec auto-suspend + clustering | 40-70% avec partitionnement + flat-rate | 25-50% avec spot + Photon |
Cycle FinOps
+-----------+
/ INFORM \ Visibilite : Dashboards de couts
/ (Voir) \ Tags, Labels, Showback reports
+--------+--------+
|
+--------v--------+
\ OPTIMIZE / Actions : Right-sizing, Reserved Instances
\ (Agir) / Auto-scaling, Storage tiering, Query tuning
+----+-----+
|
+-------v--------+
\ OPERATE / Gouvernance : Budgets, Alertes, Policies
\ (Gouverner)/ Chargeback, Equipes responsabilisees
+----------+
|
+---------> Boucle continue (iteration mensuelle)
Formules Cles
Cout par To traite = Cout total compute / Volume total traite
Cout par requete = Cout warehouse / Nombre de requetes
Cout par utilisateur = Cout total plateforme / Nombre utilisateurs actifs
ROI Data Platform = (Valeur business generee - Cout total) / Cout total
Taux d'utilisation = Heures actives / Heures provisionnees x 100
Regle des 80/20 FinOps : 20% des requetes consomment 80% des couts. Identifiez et optimisez d'abord les top consumers avec les query history de votre plateforme.
10. Semantic Layer - Comparaison des Outils
| Outil | Approche | Definition | Consommation | Pricing |
| MetricFlow (dbt) | YAML declaratif | semantic_models + metrics en YAML | dbt Cloud API → Tableau, Hex, Mode | Inclus dbt Cloud Team |
| Cube.dev | API-first | JavaScript/YAML schemas | REST, GraphQL, SQL API + cache | Open source + Cloud |
| LookML | Langage proprietaire | LookML models dans Looker | Looker uniquement | Licence Google Looker |
| AtScale | Virtual OLAP | Cube OLAP virtuel | Excel, Tableau, PowerBI | Enterprise |
# dbt MetricFlow - Exemple de metrique
metrics:
- name: revenue
type: simple
type_params:
measure: total_revenue
- name: avg_order_value
type: derived
type_params:
expr: total_revenue / order_count
metrics: [total_revenue, order_count]
Headless BI : definissez les metriques UNE SEULE fois dans la semantic layer, consommez-les partout (BI, notebooks, APIs, LLMs). Plus jamais de chiffres contradictoires entre equipes.
13. Microsoft Fabric - Architecture OneLake
MICROSOFT FABRIC - ARCHITECTURE UNIFIEE
========================================
┌─────────┐ ┌──────────┐ ┌──────────┐ ┌───────────┐ ┌────────┐
│ Data │ │ Data │ │ Data │ │ Real-Time │ │ Power │
│ Factory │ │ Engineer.│ │ Science │ │ Analytics │ │ BI │
└────┬────┘ └────┬─────┘ └────┬─────┘ └─────┬─────┘ └───┬────┘
└──────────┬┴───────────┬┴──────────────┘ │
v v v
┌─────────────────────────────────────────────────────┐
│ OneLake │
│ (Stockage unifie - Delta/Parquet) │
│ Shortcuts : liens vers ADLS, S3, GCS │
└─────────────────────────────────────────────────────┘
Facturation : CU (Capacity Units) - unifiee
OneLake = "One Drive pour les donnees d'entreprise". Tous les workloads Fabric (Data Engineering, Data Science, BI) partagent le meme stockage. Les Shortcuts permettent d'acceder a des donnees multi-cloud sans copie.