Cheatsheet - Phase 4 : Architecture Cloud Data Platform

Reference rapide pour l'architecte data cloud

1. AWS Data Services - Resume

CategorieServiceUsage PrincipalTarification
IngestionAmazon KinesisStreaming temps reelPar shard/heure + volume
IngestionAWS DMSMigration de bases de donneesPar instance de replication
IngestionAmazon AppFlowIntegration SaaS (Salesforce, SAP)Par flux execute
IngestionAmazon MSKApache Kafka managePar broker/heure
TraitementAWS GlueETL serverless (Spark)Par DPU/heure
TraitementAmazon EMRHadoop/Spark clustersPar instance EC2 + surcharge EMR
TraitementAWS LambdaMicro-traitements event-drivenPar requete + duree
TraitementAWS Step FunctionsOrchestration de workflowsPar transition d'etat
StockageAmazon S3Object storage (Data Lake)Par Go/mois + requetes
StockageAWS Lake FormationGouvernance Data LakeGratuit (services sous-jacents payants)
StockageAmazon RDS / AuroraBases relationnelles gereesPar instance + stockage
ServingAmazon RedshiftData WarehousePar noeud/heure ou Serverless
ServingAmazon AthenaRequetes SQL sur S3Par To de donnees scannees
ServingAmazon QuickSightBI et visualisationPar utilisateur/mois
MLAmazon SageMakerMachine LearningPar 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

CategorieServiceUsage PrincipalTarification
IngestionPub/SubMessaging temps reelPar volume de messages
IngestionDatastreamCDC (Change Data Capture)Par Go traite
IngestionTransfer ServiceTransfert de donnees en masseGratuit (egress payant)
TraitementDataflowApache Beam manage (batch+stream)Par vCPU + memoire + stockage
TraitementDataprocHadoop/Spark managesPar VM + surcharge Dataproc
TraitementCloud ComposerApache Airflow managePar environnement + compute
TraitementDataformTransformation SQL dans BigQueryInclus avec BigQuery
StockageCloud Storage (GCS)Object storagePar Go/mois + operations
StockageCloud SQLMySQL/PostgreSQL/SQL ServerPar instance + stockage
StockageCloud SpannerBDD relationnelle distribuee globalePar noeud/heure + stockage
StockageBigtableNoSQL wide-column (IoT, timeseries)Par noeud/heure + stockage
ServingBigQueryData Warehouse serverlessOn-demand (par To) ou Slots
ServingLookerBI et analyticsPar licence utilisateur
MLVertex AIPlateforme ML unifieePar 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

CategorieServiceUsage PrincipalTarification
IngestionEvent HubsStreaming evenementsPar unite de debit/heure
IngestionData FactoryETL/ELT orchestrationPar activite + pipeline
IngestionIoT HubIngestion IoTPar edition + messages
TraitementSynapse AnalyticsAnalytics unifie (SQL+Spark)Serverless ou pools dedies
TraitementHDInsightHadoop/Spark/Kafka managesPar VM + stockage
TraitementDatabricks (Azure)Plateforme LakehousePar DBU + VM
StockageADLS Gen2Data Lake (HNS sur Blob)Par Go/mois + operations
StockageCosmos DBNoSQL multi-modele globalPar RU/s + stockage
StockageSQL DatabaseSQL Server managePar vCore ou DTU
ServingPower BIBI et reportingPar utilisateur ou capacite
GouvernanceMicrosoft PurviewCatalogue et lignage de donneesPar capacite
PlateformeMicrosoft FabricPlateforme analytique unifieePar 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

CoucheObjectifQualiteAcces
BronzeCopie fidele des sourcesAucun nettoyageData Engineers uniquement
SilverDonnees conformees et nettoyeesTests de qualite appliquesData Scientists, Analystes avances
GoldMetriques business-readyValidee et documenteeBusiness Users, BI

5. Comparaison des Open Table Formats

CritereApache IcebergDelta LakeApache Hudi
OrigineNetflix (2017), ApacheDatabricks (2019), Linux FoundationUber (2016), Apache
Transactions ACIDOui (snapshot isolation)Oui (optimistic concurrency)Oui (MVCC)
Time TravelOui (snapshots)Oui (versioning)Oui (timeline)
Schema EvolutionExcellente (full evolution)Bonne (merge schema)Bonne
Partition EvolutionOui (hidden partitioning)Non (necessite rewrite)Non
Moteurs compatiblesSpark, Flink, Trino, Dremio, Snowflake, BigQuerySpark, Flink, Trino (connecteur)Spark, Flink, Presto
Upsert / MergeMerge Into (v2)Merge Into natifNatif (Copy-on-Write / Merge-on-Read)
CompactionRewrite data filesOptimize + Z-OrderCompaction inline/async
Adoption 2024-2025En forte croissance (standard emergent)Dominant sur DatabricksNiche (streaming CDC)
RecommandationMulti-moteur, vendor-neutralEcosysteme DatabricksCDC / 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)

Matrice TOGAF pour les Donnees

ArtefactVueAudience
Catalogue d'entitesBusinessProduct Owners, Metier
Modele logiqueLogiqueData Architects, Analystes
Diagramme de fluxLogique/PhysiqueData Engineers, Architects
Modele physiquePhysiqueData Engineers, DBA
Diagramme de securiteTransverseCISO, DPO, Architects
Plan de migrationTransitionProgram 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

StrategieSnowflakeBigQueryDatabricks
ComputeAuto-suspend warehouses (1-5 min), multi-cluster scalingSlot reservations (flex/annual), BI Engine cacheSpot/Preemptible instances, Photon engine
StockageClustering keys, micro-partitions, transient tablesPartitionnement, clustering, materialized viewsDelta optimize, Z-Order, vacuum
RequetesResult cache, query acceleration, resource monitorsRequetes sur colonnes specifiques, LIMIT avant devAdaptive query, disk cache, broadcast join
GouvernanceResource Monitors avec alertes et suspend autoCustom quotas par projet, budget alertsCluster policies, pool instances
Economie typique30-60% avec auto-suspend + clustering40-70% avec partitionnement + flat-rate25-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

OutilApprocheDefinitionConsommationPricing
MetricFlow (dbt)YAML declaratifsemantic_models + metrics en YAMLdbt Cloud API → Tableau, Hex, ModeInclus dbt Cloud Team
Cube.devAPI-firstJavaScript/YAML schemasREST, GraphQL, SQL API + cacheOpen source + Cloud
LookMLLangage proprietaireLookML models dans LookerLooker uniquementLicence Google Looker
AtScaleVirtual OLAPCube OLAP virtuelExcel, Tableau, PowerBIEnterprise
# 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.

11. Data APIs - REST vs GraphQL vs gRPC

CritereRESTGraphQLgRPC
FormatJSONJSONProtobuf (binaire)
PerformanceBonneMoyenneExcellente (5-10x REST)
FlexibiliteEndpoints fixesClient choisit les champsSchema strict
StreamingNon natifSubscriptionsBidirectionnel natif
Cas d'usage dataAPIs publiques, CRUDDashboards, apps relationnellesML serving, microservices internes

Bonnes Pratiques API Data

12. Data Virtualization - Federation vs Materialisation

CritereFederation (Virtualization)Materialisation (ETL/ELT)
DonneesRestent a la sourceCopiees dans le DWH
FraicheurTemps reelSelon frequence ETL
PerformanceLimitee par source la plus lenteOptimale (donnees locales)
Ideal pourExploration, prototypage, real-timeBI production, ML, reporting

Outils de Virtualization

OutilTypePoint fort
TrinoOpen Source+30 connecteurs, federation multi-sources
DremioCommercialReflections (cache auto), Iceberg natif, UI self-service
DenodoCommercialEnterprise-grade, gouvernance avancee, lineage
StarburstCommercialTrino entreprise avec securite et support

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.

14. Strategie de Tagging pour l'Attribution des Couts

Tags Obligatoires

TagValeurs possiblesUsage
teamdata-engineering, analytics, ml, financeAttribution par equipe
projectcustomer-360, revenue-dashboard, churn-modelAttribution par projet
environmentprod, staging, devIsolation des couts
cost_centerCC-1234, CC-5678Chargeback comptable

Implementation par Plateforme

PlateformeMecanisme de Tagging
SnowflakeObject Tags + Query Tags + Resource Monitors
BigQueryLabels sur datasets, tables et jobs
AWSResource Tags + Cost Allocation Tags + Organizations
DatabricksCluster Tags + Job Tags + Unity Catalog
AzureResource Tags + Management Groups + Purview