Google PCA: Stockage des données, bases de données et architecture analytique — Guide d'étude

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Fait partie du Google Professional Cloud Architect — 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.

Magasins de données opérationnels et mise en cache

Cloud SQL

• Haute disponibilité : HA régionale avec réplication synchrone vers une instance de secours ; basculement automatique généralement en quelques secondes à quelques minutes. Le point de terminaison de l’instance reste le même, minimisant les changements applicatifs.
• Réplicas en lecture : intra-régionaux ou inter-régionaux, asynchrones ; utiles pour la mise à l’échelle en lecture (read scale-out) et la reprise après sinistre (DR). Surveillez le décalage (lag) ; des lectures de données obsolètes (stale reads) peuvent affecter l’exactitude.
• Sauvegardes et PITR : sauvegardes planifiées plus restauration à un instant T (point-in-time recovery) à l’aide des journaux de transactions (généralement une fenêtre de 7 jours, selon le moteur). Testez la restauration régulièrement.
• Connectivité privée : l’IP privée via l’appairage de VPC (VPC peering) réduit l’exposition et la latence ; planifiez les plages d’adresses IP pour éviter les chevauchements.
• Migration : Database Migration Service prend en charge les migrations à faible temps d’arrêt depuis des environnements sur site (on-prem) ou d’autres clouds ; pour les liaisons à fort volume, préférez Dedicated ou Partner Interconnect plutôt qu’un VPN pour réduire la perte de paquets et la latence.

Compromis et modes de défaillance

• Les basculements HA réinitialisent les connexions ; les applications doivent réessayer avec un backoff exponentiel. Les fenêtres de maintenance peuvent dégrader brièvement les performances.
• Les transactions de longue durée augmentent le décalage de réplication et le temps de récupération PITR.
• Le sur-provisionnement du stockage est une assurance peu coûteuse ; le sous-provisionnement des IOPS provoque des défaillances latentes en période de pic.

Cloud Spanner

• Échelle mondiale et cohérence : lectures/écritures fortement cohérentes (strongly consistent) entre les régions grâce à TrueTime et à la validation en deux phases (two-phase commit). Choisissez une configuration régionale pour la plus faible latence en écriture ; multi-régionale pour une plus grande disponibilité et des lectures mondiales.
• Transactions : cohérence externe et entièrement ACID sur les lignes et les tables ; les transactions en lecture seule (read-only) se mettent à l’échelle sur les réplicas.
• Conception du schéma : choisissez des clés primaires qui évitent les points chauds (hotspots) ; utilisez des tables entrelacées (interleaved tables) pour la localité ; tenez compte de l’amplification en écriture (write amplification) et du comportement de remplissage (backfill) des index secondaires.
• Régionalité : le placement de la région leader détermine la latence en écriture ; une configuration multi-régionale ajoute des coûts de quorum et une latence de validation (commit).

Compromis

• La latence en écriture augmente avec l’empreinte géographique ; évitez le multi-région sauf si la disponibilité et la distribution mondiale le justifient.
• Le coût de base est plus élevé que celui des bases de données sur VM à nœud unique ; la planification de la capacité doit s’aligner sur les SLO et la croissance.

Firestore, Bigtable, Memorystore et sélection

• Firestore : base de données de documents pour les backends mobiles/web ; cohérence forte (strong consistency) pour les documents uniques ; sécurité fine ; indexation automatique. Méfiez-vous de la contention sur les documents fréquemment mis à jour ; utilisez des compteurs distribués et des écritures par lots (batched writes).
• Bigtable : base de données à colonnes larges (wide-column), à l’échelle du pétaoctet, à très faible latence pour les séries temporelles et l’IoT ; concevez les clés de ligne (row keys) pour éviter les hotspots (par ex., hachage ou salage) ; mise à l’échelle par nœuds et clusters ; routage multi-cluster pour la disponibilité. La réplication est asynchrone ; la cohérence forte est par cluster.
• Memorystore for Redis : cache en mémoire ; le niveau de base (Basic) est une instance unique (sans HA) ; le niveau Standard fournit un réplica et un basculement automatique (de brèves déconnexions sont possibles). Traitez-le comme un cache, pas comme une source de vérité ; les fonctionnalités de persistance réduisent la volatilité mais ne remplacent pas les sauvegardes de base de données.

Sélection en fonction de la charge de travail

• Relationnel avec jointures/ACID et échelle modérée : Cloud SQL.
• Relationnel mondial avec mise à l’échelle horizontale et cohérence externe : Cloud Spanner.
• Séries temporelles/télémétrie à haut débit ou clé-valeur de très grande taille : Bigtable.
• Modèles de documents centrés sur l’application avec requêtes hiérarchiques : Firestore.
• Accélération éphémère et limitation de débit (rate limiting) : Memorystore.

Analytique, ingestion et traitement

BigQuery

• Datasets : frontières logiques de sécurité et de facturation ; adoptez des conventions de nommage par domaine et par étape du cycle de vie.
• Partitionnement : par date d’ingestion ou par colonne pour le filtrage temporel ; également partitionnement par plage d’entiers. Utilisez le partitionnement par unité de temps sur

undefined

pour élaguer les analyses (scans).

• Clustering : jusqu’à quatre colonnes pour colocaliser les données associées sur le stockage ; améliore les performances et le coût des requêtes sélectives.
• Réservations : gérez les slots dédiés via des réservations et des attributions ; utilisez les flex slots pour les expérimentations en rafale ; isolez les charges de travail critiques pour éviter la pénurie (starvation).
• Contrôle d’accès : IAM au niveau du projet et du dataset ; contrôle au niveau des tables/colonnes avec des politiques au niveau des lignes (row-level policies) et des tags de règles (policy tags) ; partagez des données organisées via des vues et des routines autorisées.

Exemple utile :

undefined

undefined

Compromis et modes de défaillance

• Un mauvais partitionnement entraîne des analyses de table complètes (full-table scans) et une flambée des coûts.
• Le clustering n’est utile que lorsque les filtres ou les jointures incluent les colonnes clusterisées ; des remaniements fréquents peuvent en réduire l’avantage.
• Le sous-provisionnement de slots met les tâches en file d’attente ; le sur-provisionnement augmente les coûts. Surveillez l’utilisation des slots et le spilled shuffle.

Ingestion et traitement des données

• Pub/Sub : livraison mondiale, durable, au moins une fois (at-least-once) ; les clés d’ordonnancement (ordering keys) garantissent l’ordre par clé avec des compromis sur le débit. Concevez des consommateurs idempotents.
• Dataflow : traitement unifié par lots (batch) et en flux (streaming) avec autoscaling, traitement avec état (stateful) à sémantique “exactement une fois” (exactly-once), fenêtrage (windowing) et déclencheurs (triggers) ; Streaming Engine décharge la gestion de l’état. Utilisez des files de messages morts (dead-letter topics) et des sources rejouables.
• Dataproc : Spark/Hadoop géré pour le code et les écosystèmes existants ; clusters éphémères ou avec autoscaling ; à utiliser pour les bibliothèques de ML ou lorsque le portage est coûteux.

Compromis entre traitement par lots et en flux

• Le streaming réduit la latence et prend en charge le temps réel, mais augmente la complexité (état, watermarking, données en retard) et les coûts récurrents.
• Le traitement par lots simplifie l’exactitude et le contrôle des coûts ; acceptable lorsque les SLA tolèrent un délai.
• Modèles hybrides : stockez les événements bruts dans Cloud Storage, envoyez en flux les KPI agrégés vers BigQuery, et exécutez des recalculs nocturnes par lots pour garantir l’exactitude.

Modèles d’entrepôt de données (Warehouse)

• Warehouse : BigQuery comme système d’analyse ; vues matérialisées et requêtes planifiées pour servir la BI.
• Lakehouse : gérez les données dans Cloud Storage avec des formats ouverts ; exposez-les via BigLake à BigQuery avec une sécurité cohérente.

Gouvernance, protection et performance

Gouvernance et sécurité des données

• Métadonnées et lignage : utiliser Data Catalog pour les métadonnées techniques et métier ; activer la capture du lignage depuis Dataflow, BigQuery et Dataproc pour tracer les dépendances.
• Qualité : appliquer des règles avec la qualité des données Dataplex et orchestrer les vérifications dans Composer ou Dataform ; mettre en quarantaine les enregistrements incorrects.
• Périmètres d’accès : VPC Service Controls autour de BigQuery et Cloud Storage pour réduire le risque d’exfiltration ; Conditions IAM pour un accès contextuel ; CMEK pour le contrôle cryptographique ; balises de politique (policy tags) pour les restrictions au niveau des colonnes.
• Rétention : aligner la rétention des buckets Cloud Storage, le time travel des tables BigQuery (configurable jusqu’à 7 jours) et l’expiration des datasets/tables avec les exigences légales.

Sauvegarde, PITR et protection contre la suppression

• Valider les sauvegardes : restaurer périodiquement les sauvegardes Cloud SQL et Spanner dans des environnements isolés et exécuter des sommes de contrôle (checksums) et des validations au niveau applicatif.
• Bigtable : activer le PITR pour récupérer à un horodatage précis dans la période de rétention configurée ; tester les restaurations au niveau de la table ou du cluster.
• Spanner : utiliser les sauvegardes pour la reprise après sinistre ; exploiter les lectures obsolètes (stale reads) dans la période de rétention des versions pour les requêtes d’audit.
• Cloud Storage : activer le versioning des objets et le verrouillage de la rétention du bucket (bucket retention lock) pour se prémunir contre les suppressions accidentelles ; répliquer vers un projet distinct pour l’isolation des erreurs d’opérateur.
• BigQuery : utiliser le time travel et les snapshots de table ; éviter les suppressions (drops) sur les datasets de production avec des approbations requises et une protection contre la suppression au niveau du dataset.

Performance des données et contrôle des coûts

• Éviter les clés surchargées (hot keys) : distribuer les clés de ligne Bigtable (préfixes de hachage), choisir des clés primaires Spanner qui randomisent les élections de leader, partitionner (shard) les compteurs Firestore.
• Index : maintenir les index SQL et NoSQL nécessaires ; dans BigQuery, clusteriser sur les filtres courants ; dans Cloud SQL, surveiller les requêtes lentes et exécuter régulièrement vacuum/analyze sur Postgres.
• Planification de la capacité : établir une base de référence avec des tests de charge ; définir des SLO et des budgets d’erreur ; surveiller l’utilisation des slots BigQuery, les latences CPU/lecture-modification-écriture de Bigtable, le CPU/IOPS de Cloud SQL et le backlog de Pub/Sub.
• Contrôles des coûts : utiliser les engagements de slots BigQuery pour les charges de travail stables, Autoclass pour Cloud Storage, compacter les tables Bigtable et ajuster les filtres de Bloom, faire expirer les anciennes partitions et datasets, et mettre en œuvre des budgets et des alertes par équipe.

Scénario de problème pratique

Le groupe de distribution Acme a besoin d’une plateforme unifiée d’analyse des parcours de navigation (clickstream) et des commandes, à faible latence. Exigences : KPIs en temps réel en moins de 10 secondes, analyse historique sur cinq ans avec SQL, objectifs de reprise inférieurs à une heure, résidence stricte des données aux États-Unis et prévention de la perte accidentelle de données.

1. Réceptionner les événements bruts et mettre en œuvre une ingestion durable

• Créer des buckets Cloud Storage bi-régionaux us-central1/us-east1 pour les zones brutes (raw) et préparées (curated) ; activer Autoclass et le versioning des objets sur la zone brute.
• Justification : le bi-régional répond aux exigences de durabilité et de résidence ; le versioning protège contre les mauvais remplissages (backfills) ; Autoclass optimise automatiquement les coûts de stockage.

2. Diffuser les événements de manière fiable avec Pub/Sub et Dataflow

• Publier les événements de parcours de navigation et de commande sur des sujets Pub/Sub avec des clés d’ordonnancement par user_id ; implémenter un pipeline de streaming Dataflow pour valider, dédupliquer, enrichir et dériver la sortie vers BigQuery (KPIs temps réel) et Cloud Storage (parquet dans la zone préparée).
• Justification : Pub/Sub fournit une livraison mondiale, durable et au moins une fois (at-least-once) ; Dataflow offre un état à sémantique de livraison unique (exactly-once) et l’autoscaling ; la dérivation maintient un modèle lakehouse pour le retraitement.

3. Servir les fonctionnalités temps réel dans Bigtable et Redis

• Écrire un sous-ensemble d’événements enrichis dans Bigtable avec une clé de ligne salée user_id#timestamp ; utiliser Memorystore for Redis comme cache frontal pour les sessions les plus récentes.
• Justification : Bigtable offre des écritures à faible latence et haut débit pour les séries temporelles ; le salage évite les points chauds (hotspots) ; Redis réduit la latence de queue pour la personnalisation en direct.

4. Entreposer et optimiser les requêtes dans BigQuery

• Créer des datasets partitionnés par event_date et clusterisés par user_id, channel. Utiliser des vues matérialisées pour les KPIs et des compactages planifiés pour les chargements de petits fichiers ; acheter une réservation de slots de base avec un petit tampon de slots flexibles pour les pics d’activité.
• Justification : le partitionnement et la clusterisation élaguent les analyses (scans) et réduisent les coûts ; les vues matérialisées accélèrent les tableaux de bord ; les réservations limitent les coûts et protègent les charges de travail critiques de la mise en file d’attente.

5. Gouverner l’accès et empêcher l’exfiltration

• Appliquer IAM au niveau du dataset pour les groupes d’analystes ; utiliser des balises de politique (policy tags) pour restreindre les colonnes PII et des vues autorisées pour l’accès des fournisseurs. Appliquer les VPC Service Controls autour de BigQuery et Cloud Storage ; utiliser CMEK pour les datasets réglementés.
• Justification : principe de moindre privilège aux niveaux du dataset et de la colonne ; VPC SC réduit le risque d’exfiltration de données ; CMEK satisfait aux exigences de contrôle cryptographique.

6. Mettre en œuvre les sauvegardes, le PITR et les tests de restauration

• Activer le PITR de Bigtable pour 7 à 14 jours ; créer des sauvegardes hebdomadaires Spanner ou Cloud SQL pour les magasins de commandes transactionnels ; créer des snapshots quotidiens des tables critiques de BigQuery et s’appuyer sur le time travel pour les erreurs. Effectuer des exercices de restauration trimestriels dans un projet isolé.
• Justification : les options de récupération à plusieurs niveaux traitent les erreurs logiques et les sinistres ; les exercices réguliers valident les RPO/RTO et les guides opérationnels (runbooks).

7. Contrôler la rétention et le cycle de vie des données

• Appliquer une règle de cycle de vie pour purger les objets bruts après 30 jours et les objets préparés après cinq ans ; verrouiller une politique de rétention au niveau du bucket qui respecte la conformité. Définir l’expiration par défaut des datasets/tables BigQuery pour les datasets transitoires.
• Justification : l’application automatique réduit le risque opérationnel ; le verrouillage de la rétention empêche l’affaiblissement accidentel ou non autorisé de la politique.

8. Surveiller la performance et les coûts, et atténuer les points chauds (hotspots)

• Suivre l’utilisation des slots BigQuery, les octets analysés et la simultanéité des requêtes BI ; surveiller le CPU de Bigtable et la latence de lecture-modification-écriture ; alerter sur le backlog de Pub/Sub. Si des points chauds (hotspots) sur user_id apparaissent, augmenter la largeur du sel et effectuer un backfill des clés via Dataflow.
• Justification : la télémétrie continue détecte les goulots d’étranglement de manière précoce ; les changements proactifs de stratégie de clé préservent les SLO sans réarchitecture complète.

9. Fournir une connectivité privée et une isolation

• Pour les dépendances hybrides, utiliser Partner ou Dedicated Interconnect avec Cloud Router ; s’assurer que les plages IP ne se chevauchent pas ; utiliser Private Service Connect pour les points de terminaison de services gérés.
• Justification : les chemins privés réduisent la latence et la perte de paquets ; une planification IP claire et PSC assurent l’isolation et un routage prévisible.

10. Opérationnaliser la fiabilité

• Activer les pipelines Dataflow en mode canary et les vues BigQuery en mode bleu/vert ; imposer l’évolution du schéma via les approbations de Data Catalog ; intégrer les files d’attente de lettres mortes (dead-letter queues) avec la réponse aux incidents.
• Justification : les déploiements contrôlés limitent le rayon d’impact ; les changements de schéma gouvernés maintiennent la qualité des données ; les DLQ garantissent qu’aucune donnée n’est perdue lors des incidents.

← Calcul · Tous les domaines · Réseau →

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

Parcourir Google →