Google PDE: Architecture et conception de l'ingénierie des données — Guide d'étude

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

Fait partie du Google Professional Data Engineer — Guide d’étude. Entraînez-vous avec des réponses vérifiées dans le centre d’examens Google, ou passez des tests chronométrés sur ExamRoll.io.

Aperçu

L’architecture et la conception de l’ingénierie des données sur Google Cloud équilibrent les frontières de domaine, les modèles de traitement et les capacités des services pour fournir des plateformes de données fiables, évolutives et rentables. Les conceptions efficaces rendent le stockage, le calcul, l’orchestration et la diffusion évolutifs indépendamment ; codifient les contrats pour que les domaines interagissent ; et valident les risques de manière précoce avec des objectifs de niveau de service (SLO) mesurables. Cette section résume les styles architecturaux canoniques (data mesh, data lake, data warehouse, lakehouse, magasins opérationnels), les modes de traitement (batch, micro-batch, streaming, événementiel, lambda) et les compromis entre l’évolutivité, la latence, la disponibilité, la cohérence et le coût. Elle couvre également le placement régional et multi-cloud, l’évolution des schémas, le cycle de vie des données de bout en bout, la sélection des services en fonction de la charge de travail et les pratiques de validation basées sur les risques, adaptées à Google Cloud.

Paradigmes architecturaux et modèles de traitement

• Data mesh, domaines et produits de données :
  • Permettre aux équipes de domaine de publier des « produits de données » avec une propriété, des SLO, des politiques d’accès et une documentation clairs. Utiliser Dataplex pour définir des domaines, gouverner les métadonnées et appliquer des politiques cohérentes sur BigQuery et Cloud Storage. Les produits peuvent exposer des ensembles de données BigQuery, des sujets Pub/Sub ou des chemins Cloud Storage avec des contrats appliqués via les schémas Pub/Sub et les schémas de table BigQuery.
• Data lake :
  • Stockage brut au format ouvert (Parquet/Avro) dans Cloud Storage avec gestion du cycle de vie et versionnage. Convient aux charges de travail hétérogènes (Spark sur Dataproc, Dataflow, Presto/Trino) et à la portabilité multi-cloud. Compromis : sémantique de cohérence à terme (eventual consistency) dans les stockages d’objets ; concevoir pour l’idempotence et la déduplication basée sur les métadonnées.
• Data warehouse :
  • Analyses organisées et gouvernées dans BigQuery. Optimisé pour le SQL ANSI, la séparation du stockage/calcul et la sécurité fine. Compromis : les insertions en streaming présentent une brève obsolescence des données au moment de la requête ; préférer les chargements par lots ou les insertions avec des requêtes mises en mémoire tampon pour des SLA de fraîcheur stricts.
• Lakehouse :
  • Mélanger le stockage de data lake ouvert avec les capacités d’un data warehouse. Sur Google Cloud, stocker les données Parquet/Avro dans Cloud Storage ; utiliser les tables externes BigQuery pour des raisons économiques et les tables gérées BigQuery pour la performance et la gouvernance. Dataflow ou Dataproc maintient une sémantique de fusion de type ACID avec des stratégies de partitionnement/clustering.
• Architecture de magasin opérationnel :
  • Magasins transactionnels ou clé-valeur à faible latence pour les applications. Choisir Cloud SQL pour l’OLTP traditionnel, Cloud Spanner pour le SQL globalement cohérent avec une mise à l’échelle horizontale, et Bigtable pour les modèles d’accès à très haut débit et à colonnes larges. Séparer les magasins opérationnels de l’analytique ; utiliser le CDC (Datastream) pour capturer les changements dans Pub/Sub, Cloud Storage ou BigQuery.

Modèles de traitement et quand les utiliser :

• Batch (par lots) : Transformations périodiques à grande échelle (par ex., génération nocturne de caractéristiques). Outils : Dataflow batch, Dataproc. Modes de défaillance : expirations des tâches de longue durée, asymétrie (skew) ; atténuer avec l’autoscaling et le repartitionnement.
• Micro-batch (par micro-lots) : Petits lots fréquents (par ex., chaque minute) pour équilibrer la fraîcheur avec la stabilité et le coût. Dans BigQuery, utiliser des requêtes planifiées ou Dataflow avec des fenêtres fixes.
• Streaming (en flux) : Latence de la milliseconde à la seconde sur des données non bornées. Utiliser Pub/Sub + Dataflow. Gérer les événements en retard/désordonnés avec des fenêtres temporelles d’événement et des watermarks ; assurer l’idempotence pour éviter les doublons.
• Événementiel : Déclenché par des changements (finalisation GCS, messages Pub/Sub). Utiliser Cloud Functions ou Cloud Run pour des réactions sans état (stateless) et Dataflow pour un traitement avec état (stateful). Compromis : coûts par événement vs débit.
• Modèle Lambda : Maintenir des chemins de streaming et de batch pour la précision et le retraitement. La complexité double ; envisager une simplification de type Kappa où tout est rejouable à partir d’un journal immuable (archivage de Pub/Sub vers Cloud Storage).

Exemple court de configuration de streaming Dataflow pour les données en retard :

events
  .apply(Window.into(FixedWindows.of(Duration.standardMinutes(5)))
    .withAllowedLateness(Duration.standardMinutes(10))
    .accumulatingFiredPanes());

Propriété de domaine, produits de données et contrats

• Propriété et SLO :
  • Chaque équipe de domaine définit et exploite ses produits de données avec des SLO de disponibilité, de latence et de qualité des données. Publier les SLO via les catalogues Dataplex et les surveiller avec les SLI de Cloud Monitoring (par ex., complétude des partitions dans les délais).
• Contrats et interopérabilité :
  • Appliquer les schémas avec Pub/Sub Schema Registry (Avro/Proto) et les schémas de table BigQuery. Pour l’ingestion de CSV, valider dans Dataflow et router les lignes mal formées vers une table de lettres mortes (dead-letter) pour triage. Interopérer avec des formats ouverts dans Cloud Storage et les tables externes BigQuery lorsque plusieurs moteurs doivent lire les mêmes données.
• Évolution des schémas :
  • Privilégier les changements rétrocompatibles : ajouter des colonnes nullables, ajouter des champs optionnels dans Avro/Proto, éviter les renommages/suppressions sans fenêtres de dépréciation. Communiquer les changements via des contrats versionnés et des calendriers de dépréciation.
  • Exemple BigQuery (ajout de colonne rétrocompatible) :

ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;

• Impact sur les consommateurs :
  • Maintenir un versionnage sémantique des schémas ; publier à la fois v1 et v2 pendant la migration. Pour le streaming, router vers des sujets versionnés ou inclure un champ de version de schéma. Fournir des vues autorisées dans BigQuery pour isoler les consommateurs des changements physiques.
• Gouvernance et lignage :
  • Utiliser Dataplex et Data Catalog pour les métadonnées, les tags (par ex., PII) et le lignage. Appliquer la sécurité au niveau des lignes et des colonnes dans BigQuery. Pour la prévention de la perte de données, intégrer Cloud DLP dans l’ingestion (par ex., transformations Cloud Run ou Dataflow) pour tokeniser ou expurger les champs sensibles avant le stockage.

Compromis non fonctionnels et topologie de déploiement

• Scalabilité :
  • BigQuery s’adapte de manière élastique pour l’analytique ; Bigtable s’adapte de manière linéaire avec le nombre de nœuds mais nécessite une conception soignée des clés de ligne (par exemple, des préfixes hachés ou alternés) pour éviter le hotspotting. L’autoscaling de Dataflow réagit aux backlogs ; concevez pour la contre-pression (backpressure) en tirant parti du contrôle de flux de Pub/Sub.
• Latence :
  • Le streaming vers BigQuery offre des insertions à faible latence, mais les requêtes peuvent présenter un léger décalage ; concevez des requêtes avec un tampon de fraîcheur ou des fenêtres basées sur des watermarks. Pour des lectures à grande échelle en moins de 100 ms, précalculez et servez les données depuis Bigtable ou Memorystore.
• Disponibilité et cohérence :
  • Cloud Spanner fournit du SQL fortement cohérent et distribué à l’échelle mondiale. Bigtable offre une haute disponibilité avec une cohérence à terme (eventual consistency) entre les clusters. La disponibilité de BigQuery est régionale ou multirégionale ; matérialisez les jeux de données critiques en multirégion pour la résilience.
• Coût :
  • Optimisez BigQuery avec le partitionnement et le clustering pour réduire les octets analysés. Pour les petits fichiers sur des liaisons réseau limitées, regroupez-les par lots ou en paquets pour réduire la surcharge des RPC. Utilisez BigQuery BI Engine pour des tableaux de bord interactifs mis en cache, le cas échéant.
• Régional, multirégional, hybride et multicloud :
  • Une conception régionale réduit la latence et les coûts ; le stockage multirégional (par exemple, BigQuery multirégion US/EU, Cloud Storage dual-région/multirégion) augmente la durabilité et les options de localité. Pour la reprise après sinistre (DR), définissez les RPO/RTO et répliquez les jeux de données critiques. Dans les scénarios hybrides, utilisez Datastream pour le CDC et les Transfer Appliances ou le Storage Transfer Service pour la migration en masse. Pour le multicloud, standardisez sur des formats ouverts dans Cloud Storage et utilisez des solutions de calcul portables (Apache Beam/Dataflow, Spark sur Dataproc) tout en tenant compte des frais de sortie (egress) et de la surcharge opérationnelle.

Superposition des couches, cycle de vie et sélection des services

• Séparation des couches :
  • Stockage : Cloud Storage pour les données brutes/bronze et l’archivage ; BigQuery pour l’analytique préparée/de desserte ; Bigtable pour l’accès par clé à faible latence ; Spanner/Cloud SQL pour l’OLTP.
  • Calcul : Dataflow pour le streaming/batch serverless ; Dataproc pour les écosystèmes Spark/Hadoop ; BigQuery pour l’ELT au sein de l’entrepôt ; Cloud Run/Functions pour les microservices événementiels.
  • Orchestration : Cloud Composer (Airflow) ou Workflows pour la chorégraphie de DAG et d’API ; Scheduler pour les déclencheurs de type cron.
  • Desserte : Bigtable ou Spanner pour les lectures en ligne ; BigQuery pour la BI ; Looker/BI Engine pour les tableaux de bord ; Memorystore pour la mise en cache.
• Cycle de vie des données :
  • Ingestion : Pub/Sub pour les flux ; Storage Transfer ou gsutil pour les fichiers ; Data Transfer Service pour le SaaS. Valider, dédupliquer et déposer les données brutes immuables dans Cloud Storage avec la gestion des versions d’objets.
  • Traitement : Utiliser Dataflow ou BigQuery pour transformer les données brutes en silver (nettoyées, conformées), puis en gold (data marts prêts à l’emploi).
  • Desserte : Publier des vues/tables BigQuery pour l’analytique ; précalculer des caractéristiques ou des prédictions vers Bigtable pour les API.
  • Conservation et archivage : Appliquer les règles de cycle de vie de Cloud Storage pour faire passer les données aux niveaux Coldline/Archive ; utiliser le partitionnement temporel de BigQuery avec expiration de partition pour la rétention. Activer CMEK si nécessaire et VPC Service Controls pour la protection contre l’exfiltration de données.
• Sélection des services en fonction des caractéristiques de la charge de travail :
  • Séries temporelles à haut débit avec des lignes larges et une faible latence : Bigtable.
  • OLTP global à cohérence forte avec SQL ANSI : Cloud Spanner.
  • Transactions relationnelles traditionnelles à une échelle modeste : Cloud SQL.
  • Analytique à l’échelle du pétaoctet avec SQL ANSI et séparation du stockage/calcul : BigQuery.
  • Ingestion et traitement en temps réel : Pub/Sub + Dataflow.
  • Traitements batch Spark/Hadoop ou outillage spécifique à une bibliothèque : Dataproc.

Exemple court de partitionnement BigQuery :

CREATE TABLE ops.events
PARTITION BY DATE(event_ts)
CLUSTER BY device_id AS
SELECT * FROM staging.events_clean;

Scénario de problème pratique

Contoso Mobility exploite une flotte mondiale de trottinettes électriques et a besoin d’une solution d’ingestion, de traitement, de stockage et d’analyse en temps réel pour la télémétrie des trajets et la facturation. Ils doivent prendre en charge des millions d’événements par minute, des règles de fraude en moins d’une seconde, des tableaux de bord à jour, des contrôles de confidentialité et des opérations multirégionales résilientes.

Approche :

1. Établir l’ingestion d’événements avec Cloud Pub/Sub.

• Justification : Pub/Sub fournit un point de terminaison mondial unique, une mise en tampon durable et une mise à l’échelle horizontale pour le trafic en rafales des appareils. Utiliser des clés ordonnées par trottinette pour préserver l’ordre intra-appareil pour des fenêtres d’une heure.

2. Mettre en œuvre le traitement en streaming avec Cloud Dataflow (Apache Beam).

• Justification : L’autoscaling de Dataflow gère les pics de charge et offre des récepteurs à sémantique exactly-once lorsqu’il est combiné avec des clés idempotentes. Utiliser des fenêtres basées sur le temps de l’événement et des watermarks pour gérer la télémétrie en retard ou désordonnée. Émettre une sortie principale vers les flux de données préparées et une sortie secondaire pour les enregistrements non distribuables (dead-letter).
• Configuration :

.withAllowedLateness(Duration.standardMinutes(15))
.discardingFiredPanes();

3. Persister les données brutes et préparées dans Cloud Storage et BigQuery, respectivement.

• Justification : Déposer les fichiers Avro bruts (bronze) dans un bucket Cloud Storage birégional pour la relecture et l’audit. Écrire les flux préparés (silver) dans des tables BigQuery partitionnées pour l’analytique, avec un clustering sur scooter_id pour des recherches ponctuelles efficaces. Appliquer un petit tampon de fraîcheur sur les requêtes des tableaux de bord pour éviter l’obsolescence transitoire du streaming.

4. Servir les recherches opérationnelles et les vérifications de fraude depuis Cloud Bigtable.

• Justification : L’évaluation des règles en moins de 100 ms nécessite un accès aléatoire à faible latence. Précalculer les agrégats (par ex., trajets par appareil par fenêtre de 5 minutes) dans Dataflow et les écrire dans Bigtable en utilisant une clé de ligne avec un préfixe haché (par ex., h(prefix)+device_id+window_start) pour éviter le hotspotting et paralléliser les lectures sur les tablettes.

5. Gérer la facturation transactionnelle dans Cloud Spanner.

• Justification : La facturation nécessite un SQL globalement cohérent, une cohérence forte et une haute disponibilité. Utiliser un leader dans la zone géographique principale avec des réplicas en lecture seule dans les régions secondaires pour réduire les latences de lecture pour les portails clients.

6. Appliquer la gouvernance avec Dataplex, Data Catalog et Cloud DLP.

• Justification : Classifier les champs PII, taguer les jeux de données et appliquer la sécurité au niveau des colonnes dans BigQuery. Intégrer Cloud DLP dans le pipeline Dataflow pour tokeniser les attributs sensibles avant le stockage. Les domaines Dataplex reflètent la propriété organisationnelle ; chaque domaine publie des produits de données documentés avec des SLO.

7. Orchestrer et exploiter avec Cloud Composer et Cloud Monitoring.

• Justification : Composer coordonne les remplissages batch (backfills), les compactions et la matérialisation de caractéristiques ML. Monitoring observe les SLI de bout en bout : le backlog de Pub/Sub, le retard du watermark de Dataflow, la complétude des partitions BigQuery et les latences de queue de Bigtable. Alerter sur les violations de SLO ; mettre à l’échelle automatiquement Dataflow en fonction de la croissance du backlog.

8. Optimiser les coûts et le cycle de vie avec le partitionnement et la hiérarchisation des données.

• Justification : Les tables BigQuery sont partitionnées par event_ts avec une rétention de 90 jours, et clusterisées par scooter_id. Cloud Storage utilise des règles de cycle de vie pour faire passer les données brutes à Coldline après 30 jours et à Archive après 180 jours. Des tâches BigQuery planifiées compactent les petits fichiers de micro-batch en objets Parquet plus volumineux pour réduire la surcharge liée au nombre de fichiers pour les tâches Spark en aval.

9. Valider les risques et la résilience.

• Justification : Effectuer des tests de charge à 2x le pic attendu pour valider les quotas de Pub/Sub et l’autoscaling de Dataflow. Réaliser un exercice de basculement régional : les jeux de données multirégionaux de BigQuery et les buckets birégionaux maintiennent la disponibilité ; l’instance multirégionale de Spanner maintient un RPO=0 et le RTO configuré via un basculement automatique. Utiliser l’Infrastructure as Code (Terraform) avec validation des politiques pour imposer CMEK et VPC Service Controls.

Cette architecture sépare nettement les responsabilités : Pub/Sub met en tampon l’ingestion, Dataflow effectue les calculs, Cloud Storage et BigQuery stockent et servent l’analytique, Bigtable accélère les lectures opérationnelles, et Spanner garantit des transactions cohérentes. Elle équilibre la scalabilité et la latence tout en maîtrisant les coûts grâce au partitionnement, au clustering, aux politiques de cycle de vie et à l’autoscaling, et elle intègre la gouvernance et la fiabilité par le biais de produits de données documentés, de contrats et d’une validation continue.

Tous les domaines · Stockage des données →

Entraînez-vous sur ces questions → · Tests chronométrés sur ExamRoll.io →

Parcourir Google →