Google PDE: Stockage des données, lacs de données et formats de fichiers — 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.

Vue d’ensemble

Le stockage de données sur Google Cloud couvre le stockage d’objets bruts, les lacs de données organisés (curated) et les formats optimisés pour l’analytique. La construction de lacs de données fiables, gouvernés et performants exige des choix judicieux en matière de classes de stockage, de paramètres de buckets, d’emplacements, de formats de fichiers, de structure de table et de cycle de vie. Cette section détaille les compromis de conception, les modes de défaillance à éviter et les modèles qui s’alignent avec BigQuery, Spark et les pipelines de streaming à grande échelle.

Fondations de Cloud Storage : classes, buckets, cohérence et cycle de vie

Cloud Storage est la fondation durable et hautement disponible pour les fichiers bruts et organisés.

Classes de stockage
- Standard (chaud) : accès fréquent, latence la plus faible. Aucune durée de stockage minimale.
- Nearline (froid) : accès peu fréquent (~mensuel). Minimum de 30 jours ; des frais de récupération s’appliquent.
- Coldline (plus froid) : accès peu fréquent (~trimestriel). Minimum de 90 jours ; frais de récupération plus élevés.
- Archive (le plus froid) : conservation à long terme (~annuel). Minimum de 365 jours ; frais de récupération les plus élevés.
- Autoclass peut effectuer une transition automatique entre les classes ; vérifiez que les frais de suppression anticipée et les modèles d’accès n’érodent pas les économies.
Emplacements des buckets et réplication
- Région : idéal pour la localité des données et la conformité au sein d’une seule zone géographique.
- Double région : deux régions appairées avec réplication automatique ; la réplication turbo valide les réplicas rapidement avec un RPO mesuré en minutes ; idéal pour la reprise après sinistre (DR) à faible RPO.
- Multi-région : géo-distribué au sein d’un continent pour une large disponibilité, la distribution de contenu et l’analytique couvrant une vaste zone.
- Choisissez les emplacements pour respecter les lois sur la résidence des données et pour minimiser l’egress/la latence vers les services de calcul (Dataproc, Dataflow, tables externes BigQuery).
Cohérence et sémantique
- Cloud Storage offre une cohérence forte et globale de type lecture après écriture (read-after-write), lecture après mise à jour des métadonnées et listage après écriture.
- Les écritures d’objets sont atomiques et immuables ; un « renommage » est un modèle de copie puis suppression. Concevez des copies idempotentes et vérifiez les sommes de contrôle (checksums) pour éviter les migrations partielles.
Modèles d’accès et performance
- Les imports composites parallèles et les imports pouvant être repris améliorent le débit pour les fichiers volumineux.
- Les lectures de plages (range reads) permettent des pieds de page colonnaires efficaces et des lectures sélectives.
- Évitez les nombreux fichiers de petite taille (<8 Mo) qui augmentent la surcharge de métadonnées/listage ; regroupez ou compactez-les en objets plus volumineux.
- GZIP n’est pas fractionnable (splittable) pour les lectures distribuées ; préférez Parquet/ORC/Avro+Snappy pour un traitement scalable.
Cycle de vie, conservation et gestion des versions
- Les règles de conservation au niveau du bucket et les blocages d’objets (basés sur des événements ou temporaires) renforcent l’immuabilité pour la conformité et pour réduire les suppressions accidentelles.
- La gestion des versions d’objets conserve les générations précédentes ; utile pour la récupération après un écrasement/une suppression. Surveillez la croissance des coûts de stockage.
- Les règles de cycle de vie automatisent les transitions et les suppressions. Exemple (JSON) pour déplacer les données plus anciennes vers un stockage plus froid et les supprimer après un an : { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
- Modes de défaillance : frais de suppression anticipée si vous effectuez une transition trop agressive ; les verrouillages de conservation ne peuvent pas être raccourcis ; la gestion des versions sans compactage peut augmenter les coûts.
Transferts et migration
- Utilisez Storage Transfer Service pour les déplacements parallélisés avec points de contrôle depuis des environnements sur site (on-prem) ou d’autres clouds ; Transfer Appliance pour les pétaoctets hors ligne.
- Validez l’intégrité avec CRC32C/MD5 et des préconditions de correspondance de génération pour éviter les conditions de concurrence (races).
- Préférez gsutil/gcloud storage avec -m (parallèle) et les sommes de contrôle ; évitez les goulots d’étranglement SFTP pour l’ingestion de volumes élevés.

Gouvernance unifiée du lac de données avec BigLake et Dataplex

BigLake et Dataplex standardisent la sécurité et la gouvernance sur les fichiers et les tables.

BigLake
- Expose les données de Cloud Storage sous forme de tables gérées par BigQuery (externes) avec des contrôles d’accès fins et uniformes, y compris des politiques d’accès au niveau des lignes et des tags de politique au niveau des colonnes.
- Permet l’élagage de colonnes (column pruning) et la délégation de prédicats (predicate pushdown) pour Parquet/ORC, réduisant les octets analysés et l’egress vers des moteurs comme BigQuery, Spark sur Dataproc et Dataflow.
- Centralise l’audit via Cloud Logging et l’application centralisée des politiques ; un plan de contrôle unique pour les fichiers du lac de données et les tables de l’entrepôt.
Dataplex
- Organise les données en lacs, zones (brutes, organisées, de confiance) et assets (buckets, datasets) ; gère les métadonnées, la lignée des données (lineage) et les règles de qualité des données.
- S’intègre avec les tags de politique pour les colonnes sensibles et prend en charge le principe du moindre privilège via IAM aux niveaux du lac/de la zone/de l’asset.
- Encourage la standardisation des noms, du partitionnement et de la gestion des schémas dans les environnements multi-équipes pour éviter les « tiroirs fourre-tout ».
Modèles de gouvernance
- Implémentez des modèles de type un dataset par locataire (tenant) et un bucket par zone ; évitez les fuites de données entre locataires.
- Utilisez les politiques d’accès au niveau des lignes et les tags de politique de colonne pour les PII. Restreignez l’accès à l’API aux identités approuvées.
- Auditez les accès avec Cloud Logging ; acheminez les journaux filtrés vers Pub/Sub pour une surveillance en temps réel.

Formats de fichiers, compression et comportement des requêtes

Le choix du bon format a des effets de premier ordre sur les coûts et les performances.

Formats colonnes (Parquet, ORC)
- Points forts : élagage de colonnes (column pruning), délégation de prédicats (predicate pushdown), encodage et compression par colonne, statistiques et fichiers divisibles (splittable).
- Inconvénients : utilisation CPU plus élevée au moment de l’écriture ; l’évolution du schéma doit être gérée avec soin (par ex., l’ajout de colonnes est sûr ; les changements de type sont risqués).
- Compression : Snappy pour la vitesse, ZSTD pour de meilleurs ratios là où il est pris en charge. Évitez GZIP pour les formats colonnes, sauf si des contraintes d’interopérabilité l’exigent.
Avro, orienté ligne
- Points forts : évolution du schéma avec un typage fort, compression au niveau du bloc, divisible (splittable) ; excellent pour les zones d’atterrissage (landing zones) de streaming et l’échange de données.
- Inconvénients : moins efficace pour l’analyse (scan) que les formats colonnes ; convertir en Parquet/ORC dans les zones organisées (curated zones).
CSV et JSON (semi-structurés)
- CSV : lisible par l’homme, surcharge la plus faible lorsque les valeurs sont simples ; absence de schéma, de types et de cohérence dans l’échappement des caractères ; coûteux à analyser (parser) à grande échelle.
- JSON : auto-descriptif et flexible ; le format JSON délimité par des sauts de ligne (newline-delimited) est requis pour des lectures distribuées et évolutives ; verbeux et gourmand en CPU à analyser.
- Lorsque c’est possible, stockez les données brutes en CSV/JSON, puis validez-les et convertissez-les en Avro/Parquet pour l’analyse.
Tables externes BigQuery et BigLake
- Les tables externes Parquet/ORC bénéficient de la délégation de prédicats (pushdown) et de l’élagage de colonnes ; ce n’est généralement pas le cas pour les tables CSV/JSON, ce qui entraîne un plus grand nombre d’octets analysés (scanned bytes).
- Les tables externes CSV compressées (GZIP) ne peuvent pas être divisées entre les workers ; attendez-vous à des lectures plus lentes.
- Exemple : création d’une table BigLake au format Parquet avec des partitions de type Hive : CREATE EXTERNAL TABLE lake.sales WITH CONNECTION us.biglake_conn OPTIONS ( format = ‘PARQUET’, hive_partitioning_mode = ‘AUTO’, hive_partitioning_source_uri_prefix = ‘gs://corp-raw/sales/’, uris = [‘gs://corp-raw/sales/date=/region=/part-*.parquet’] );

Structure, partitionnement, ingénierie de la performance, résidence des données et migration

Structure et partitionnement des objets
- Adopter des chemins de type Hive pour les partitions et les clés de clustering : gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
- Maintenir la taille des fichiers individuels dans la plage de 128 à 1024 Mo pour équilibrer le parallélisme et la surcharge des tâches. Éviter d’avoir des millions de fichiers par partition.
- Atténuer les problèmes liés aux petits fichiers en :
  - Regroupant les téléversements côté client.
  - Utilisant des tâches de compactage Dataflow/Spark pour fusionner les petits fichiers en dehors des heures de pointe.
  - Archivant les petits fichiers d’origine et n’exposant que les données compactées à l’analytique.
Partitionnement et clustering dans BigQuery
- Partitionner sur le temps d’ingestion ou une colonne de filtre à haute cardinalité (par ex., event_date). Éviter le sur-partitionnement (par ex., par minute) qui fait exploser les métadonnées.
- Clusteriser par les dimensions fréquemment filtrées/triées (jusqu’à quatre). Le clustering augmente la localité des données et réduit le nombre d’octets analysés.
- Préférer les tables natives BigQuery pour l’analytique interactive intensive ; utiliser BigLake/externe pour un accès gouverné au lac de données, le partage entre moteurs et l’isolation des coûts.
Implications sur les performances des requêtes
- Les formats colonnes réduisent considérablement les coûts d’analyse externe ; les tables externes CSV/JSON nécessitent souvent une analyse complète des fichiers.
- Les garanties de cohérence éliminent le besoin de délais artificiels pour les lectures Cloud Storage, mais les systèmes en aval (par ex., les insertions en streaming dans BigQuery) peuvent présenter un court délai de visibilité des données — concevoir avec des watermarks ou des délais de lecture si nécessaire.
Résidence, durabilité et récupération des données
- Sélectionner les emplacements des buckets/datasets pour respecter les contraintes de résidence ; colocaliser la puissance de calcul pour réduire l’egress et la latence.
- Utiliser le mode bi-régional avec la réplication turbo pour un RPO faible ; le versioning et les politiques de rétention pour la récupération après une erreur humaine ou une attaque par ransomware.
- Pour la reprise après sinistre (DR), répliquer les buckets vers un projet/une région distinct(e) en utilisant la réplication de bucket et protéger avec des frontières IAM distinctes.
Migration et validation sécurisées
- Planifier en plusieurs phases : amorçage (transfert en masse), synchronisation incrémentielle (copie par mtime/fenêtrée), basculement (source en lecture seule) et validation post-basculement.
- Valider avec des sommes de contrôle, des décomptes, des totaux d’octets et un décodage d’échantillons. Pour les données tabulaires, comparer les nombres de lignes et les agrégats de hachage :

undefined

Utiliser des préconditions (ifGenerationMatch) pour empêcher les écrasements lors d’une copie parallèle. Conserver une fenêtre de restauration avec le versioning ou en conservant la source.
Après la migration, activer le cycle de vie et Autoclass selon le nouveau profil d’accès ; éviter d’activer le verrouillage de rétention (retention lock) tant que les validations ne sont pas terminées.

Scénario de problème pratique

Acme Retail reçoit quotidiennement des fichiers CSV d’un partenaire logistique dans un bucket Cloud Storage régional. Les fichiers contiennent occasionnellement des lignes malformées. Acme doit réceptionner, valider, convertir dans un format prêt pour l’analytique et charger dans BigQuery pour des tableaux de bord en quasi-temps réel, tout en conservant les lignes incorrectes pour inspection et en appliquant la gouvernance.

Approche :

Réceptionner et gouverner les données brutes dans Dataplex
- Créer un lac Dataplex avec un asset de zone brute (raw zone) mappé sur gs://acme-raw/logistics/.
- Justification : Gouvernance, métadonnées et lignage des données centralisés. Appliquer l’IAM au niveau de la zone et marquer les champs sensibles avec des policy tags pour une application en aval.
Appliquer le cycle de vie et la rétention
- Appliquer une politique de rétention de 30 jours sur le bucket et activer le versioning des objets sur acme-raw.
- Justification : Protège contre l’écrasement/la suppression accidentels par le partenaire ; une rétention courte équilibre le coût et la capacité de récupération. Le versioning facilite l’annulation (rollback) des livraisons défectueuses.
Valider et ingérer avec un pipeline de traitement par lots (batch) Dataflow
- Déclencher une tâche Dataflow quotidienne sur les notifications de finalisation d’objet. Lire le CSV avec un schéma et une validation par enregistrement ; écrire les enregistrements valides dans une table de pré-production (staging) BigQuery (partitionnée par event_date) et router les erreurs d’analyse/validation vers une table de rebut (dead-letter) BigQuery.
- Justification : Dataflow fournit une analyse syntaxique parallèle et évolutive ainsi qu’une gestion robuste des rebuts, afin que les analystes puissent inspecter les lignes incorrectes. Cela reflète les meilleures pratiques pour une qualité de CSV hétérogène.
Compacter et convertir en Parquet dans une zone organisée (curated zone)
- Le même pipeline écrit les données validées dans gs://acme-curated/logistics/date=YYYY-MM-DD/ sous forme de fichiers Parquet d’une taille d’environ 256 à 512 Mo.
- Justification : Parquet permet l’élagage de colonnes (column pruning) et la délégation de prédicats (predicate pushdown) dans BigQuery et Spark, ce qui réduit les octets analysés et améliore la latence ; le compactage atténue la surcharge liée aux petits fichiers provenant du mode de livraison du partenaire.
Exposer l’analytique gouvernée via BigLake
- Créer une table externe BigLake sur le chemin Parquet organisé avec l’auto-partitionnement Hive ; appliquer des policy tags au niveau des colonnes et des politiques d’accès aux lignes pour les filtres spécifiques au partenaire.
- Justification : Accès uniforme et affiné sur BigQuery et Spark avec un audit centralisé. L’élagage de partition (partition pruning) réduit les coûts d’analyse sur les filtres de date.
Charger les agrégats critiques dans une table native BigQuery
- Pour les tableaux de bord à forte sollicitation (hot), exécuter une tâche BigQuery planifiée qui ingère les N derniers jours depuis la table externe Parquet organisée vers une table native partitionnée et clusterisée.
- Justification : Le stockage natif accélère la BI à haute concurrence tandis que la table externe BigLake reste le système de référence (system-of-record) gouverné pour un accès plus large.
Surveiller et alerter avec Cloud Logging et Pub/Sub
- Créer un récepteur de journaux (log sink) filtrant les résultats des tâches de chargement Dataflow et BigQuery vers Pub/Sub ; intégrer avec l’outil de surveillance pour des alertes instantanées sur les échecs ou les taux élevés de lignes incorrectes.
- Justification : Visibilité opérationnelle ciblée et spécifique à la table sans interrogation active (polling) ; prend en charge les pratiques SRE.
Optimiser la classe de stockage et la résidence des données
- Conserver le Parquet organisé en classe Standard pendant 14 jours, puis passer en Coldline après 30 jours via une règle de cycle de vie ; stocker les buckets bruts et organisés dans la même région que les datasets BigQuery pour éviter l’egress.
- Justification : Équilibre les performances de lecture à chaud avec le coût. La colocalisation maintient la conformité et minimise la latence et les frais d’egress.
Valider la qualité de bout en bout
- Après chaque exécution, comparer les décomptes et les agrégats de hachage entre les tables de staging, externe organisée et native BigQuery ; mettre en quarantaine les anomalies.
- Justification : Détection précoce de la dérive de schéma ou des régressions d’ingestion ; les hachages cryptographiques ou par empreinte (fingerprint) fournissent une assurance légère sans nécessiter de nouvelles analyses complètes.

Cette conception fournit une ingestion résiliente avec analyse des rebuts, un format Parquet prêt pour l’analytique pour des requêtes efficaces, une gouvernance centralisée via Dataplex et BigLake, et des politiques de cycle de vie optimisées en termes de coûts, tout en respectant le principe du moindre privilège et en garantissant des opérations auditables.

← Architecture et conception de l’ingénierie des données · Tous les domaines · Analytique BigQuery et ingénierie d’entrepôt de données →

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