Guide

Des données continues et à haut volume nécessitent une analyse dans les minutes suivant leur arrivée.

→Pub/Sub pour l'ingestion -> Dataflow (streaming) pour la transformation -> BigQuery avec insertions en streaming ou Storage Write API pour l'analyse.

Pourquoi: Il s'agit du modèle de streaming serverless et auto-évolutif canonique. Le traitement par lots (par exemple, Dataproc) ne répondrait pas aux exigences de faible latence.

Un pipeline de données doit gérer des pics de trafic imprévisibles (par exemple, un volume saisonnier 10 fois supérieur) tout en maintenant une faible latence.

→Utiliser des services entièrement gérés et auto-évolutifs : Pub/Sub pour l'ingestion, Dataflow avec l'auto-scaling activé, et BigQuery pour le stockage.

Pourquoi: Les services gérés adaptent automatiquement les ressources à la charge, évitant les coûts de sur-approvisionnement et garantissant les performances sous trafic de pointe.

Migrer un grand entrepôt de données Hadoop/Hive sur site vers Google Cloud.

→Migrer les données vers Cloud Storage, puis les charger dans BigQuery. Remplacer Hive/Spark SQL par BigQuery pour l'analyse serverless. Utiliser Dataproc pour les tâches Spark qui ne sont pas facilement traduisibles en SQL.

Pourquoi: BigQuery offre un remplacement serverless et haute performance pour les entrepôts de données Hadoop, réduisant la surcharge opérationnelle.

Un pipeline de streaming nécessite que les messages soient traités exactement une fois et dans l'ordre pour chaque entité (par exemple, par symbole boursier).

→Publier des messages vers Pub/Sub avec une clé d'ordonnancement. Traiter avec un pipeline de streaming Dataflow, qui garantit un traitement dans l'ordre pour une clé donnée.

Pourquoi: Les clés d'ordonnancement Pub/Sub combinées à Dataflow fournissent un traitement géré, évolutif, ordonné et exactement une fois sans gestion manuelle de l'état.

Référence↗

Construire un lac de données flexible et évolutif pour prendre en charge les charges de travail par lots et de streaming avec gouvernance des données.

→Utiliser Cloud Storage comme couche de stockage. Utiliser Dataflow pour le traitement par lots et en streaming. Utiliser Dataplex avec Data Catalog pour la gestion des métadonnées, la découverte et la gouvernance.

Pourquoi: Cette architecture découple le stockage et le calcul, permettant l'utilisation de plusieurs moteurs de traitement (Dataflow, Dataproc) sur un magasin de données central avec une gouvernance unifiée.

Un pipeline traitant des données sensibles (par exemple, PHI, PII) doit être conforme aux réglementations telles que HIPAA ou GDPR.

→Activer les journaux d'audit Cloud pour tous les accès aux données. Mettre en œuvre les contrôles de service VPC pour créer un périmètre de sécurité empêchant l'exfiltration de données.

Pourquoi: La journalisation d'audit est essentielle pour le suivi des accès aux données à des fins de conformité. Les contrôles de service VPC offrent une défense solide contre l'exfiltration de données, une exigence clé pour les données sensibles.

Une architecture lambda avec des couches de traitement par lots et rapide séparées doit présenter une vue unifiée des données.

→Utiliser BigQuery pour la couche de service. Utiliser une instruction `MERGE` pour mettre à jour/insérer les données traitées par lots dans une table maître, écrasant les données de streaming pour la même période. Exposer une vue qui `UNION`ne les données historiques par lots avec les données de streaming en temps réel pour la période actuelle.

Pourquoi: Ce modèle fournit à la fois des vues en temps réel à faible latence et une précision historique corrigée par lots sans nécessiter de logique de réconciliation côté client.

Mettre en œuvre une architecture de data mesh décentralisée où les domaines sont propriétaires de leurs produits de données.

→Utiliser Dataplex pour une gouvernance fédérée sur les "lacs" et "zones" spécifiques aux domaines. Utiliser des ensembles de données BigQuery par domaine. Utiliser Analytics Hub pour partager des produits de données entre les domaines.

Pourquoi: Dataplex fournit le plan de gouvernance central tout en permettant l'autonomie des domaines, un principe fondamental du data mesh.

Combiner un lac de données et un entrepôt de données, permettant des tâches Spark sur des données brutes et du SQL rapide sur des données curées.

→Stocker les données dans des formats ouverts (Iceberg, Delta Lake) sur Cloud Storage. Utiliser BigLake pour fournir une couche unifiée de gouvernance et d'accès. Interroger les données depuis Dataproc (Spark) et BigQuery.

Pourquoi: BigLake permet d'interroger les données en place sur Cloud Storage avec les performances de BigQuery et une sécurité fine, unifiant le lac et l'entrepôt.

Concevoir une stratégie de reprise après sinistre pour un entrepôt de données BigQuery critique avec un faible RPO (par exemple, 1 heure).

→Configurer la réplication de jeux de données BigQuery inter-régions pour les jeux de données critiques. Utiliser Terraform ou Dataform pour gérer les définitions de schéma et de vue. Orchestrer le basculement avec Cloud Functions déclenchées par les alertes Cloud Monitoring.

Pourquoi: La réplication inter-régions fournit une copie consultable et continuellement mise à jour dans une région de reprise après sinistre, répondant aux exigences de RPO/RTO faibles pour les données critiques.

Répliquer continuellement les modifications d'une base de données OLTP (par exemple, Oracle, PostgreSQL, MySQL) vers BigQuery avec une faible latence.

→Utiliser Datastream pour effectuer la capture de données modifiées (CDC). Le configurer pour diffuser les modifications directement vers BigQuery, qui les applique à l'aide de sa capacité `MERGE`.

Pourquoi: Datastream est un service CDC géré et serverless qui simplifie la réplication de bases de données en temps réel sans nécessiter de pipelines personnalisés ni de charge significative sur la base de données source.

Référence↗

Un pipeline de streaming Dataflow doit produire des résultats précis fenêtrés par temps d'événement malgré l'arrivée tardive de certains événements (plusieurs heures).

→Configurer les fenêtres temporelles d'événements avec `allowedLateness` défini pour tenir compte du délai. Utiliser des déclencheurs avec des activations précoces pour les résultats préliminaires et des volets accumulés pour inclure les données tardives.

Pourquoi: Le modèle de Dataflow de filigranes, de déclencheurs et de latence autorisée fournit un cadre robuste pour équilibrer l'exhaustivité et la latence lors du traitement de données désordonnées.

Un pipeline Dataflow écrivant dans BigQuery subit des doublons après des redémarrages ou des échecs transitoires.

→Utiliser le récepteur BigQuery Storage Write API (`STORAGE_WRITE_API`) avec la méthode définie sur `at-least-once` (par défaut, anciennement `STREAMING_INSERTS`) ou `exactly-once` (mode `COMMITTED`).

Pourquoi: Le Storage Write API en mode `COMMITTED` fournit des sémantiques exactement une fois intégrées pour le streaming, éliminant le besoin d'une logique de déduplication personnalisée.

Ingérer des données depuis une API REST paginée et limitée en débit à l'aide de Dataflow.

→Utiliser un `SplittableDoFn` pour traiter la source paginée en parallèle. Implémenter une logique de limitation de débit (par exemple, en utilisant un Guava RateLimiter) et un backoff exponentiel pour les réessais au sein du DoFn.

Pourquoi: Un `SplittableDoFn` permet un rééquilibrage dynamique du travail. Le combiner avec une limitation de débit et une logique de réessai crée un modèle résilient et efficace pour la gestion des API externes.

Un flux de données unique doit être écrit vers plusieurs destinations (par exemple, BigQuery, Bigtable, Cloud Storage).

→Dans un pipeline Dataflow unique, après le traitement initial, appliquer plusieurs écritures `PTransform` à la même `PCollection` finale.

Pourquoi: Le modèle de fan-out est très efficace car les données ne sont traitées qu'une seule fois. Il évite le coût et la complexité de l'exécution de plusieurs pipelines distincts lisant la même source.

Un flux à haut volume doit être enrichi en le joignant à une table de dimension à évolution lente (par exemple, profils utilisateur) qui se met à jour périodiquement.

→Utiliser le modèle d'entrée latérale (side input) dans Dataflow. Charger la table de dimension comme une `PCollectionView`. Configurer un déclencheur périodique pour rafraîchir l'entrée latérale selon un horaire, évitant les redémarrages de pipeline.

Pourquoi: Les entrées latérales diffusent les données de dimension à tous les workers pour des recherches rapides en mémoire, évitant les appels API/DB par élément. Le rafraîchissement périodique gère les mises à jour efficacement.

Les charges de travail des clusters Dataproc varient considérablement, entraînant soit un surprovisionnement, soit une sous-performance.

→Créer un cluster Dataproc avec une politique d'auto-scaling. Définir le nombre min/max de workers primaires et secondaires. La politique dimensionnera le cluster en fonction des métriques YARN.

Pourquoi: L'auto-scaling optimise les coûts en adaptant les ressources du cluster à la demande des tâches, en augmentant pour les charges lourdes et en réduisant pendant les périodes d'inactivité.

Un pipeline Dataflow nécessite des binaires personnalisés, des bibliothèques propriétaires ou des versions spécifiques non incluses dans les images de worker standard, et doit s'exécuter dans un VPC sans accès internet.

→Construire une image de conteneur personnalisée avec toutes les dépendances préinstallées. Pousser l'image vers Artifact Registry. Déployer le pipeline à l'aide d'un modèle Flex qui référence le conteneur personnalisé.

Pourquoi: Les modèles Flex avec conteneurs personnalisés offrent un contrôle complet sur l'environnement d'exécution et les dépendances, essentiel pour les environnements hors ligne ou spécialisés.

Une tâche Dataflow ou Spark effectuant un `GroupByKey` est lente car certaines clés ont un nombre disproportionné de valeurs (une "clé chaude").

→Mettre en œuvre une agrégation en deux étapes (salage de clé). D'abord, ajouter un suffixe aléatoire à la clé pour répartir la clé chaude sur plusieurs workers. Agréger partiellement. Ensuite, supprimer le suffixe et agréger les résultats partiels.

Pourquoi: Cette technique de fan-out divise manuellement le travail pour la clé chaude, lui permettant d'être traitée en parallèle et de surmonter le goulot d'étranglement.

Un pipeline de streaming ne doit pas échouer en raison d'enregistrements mal formés. Les enregistrements invalides doivent être isolés pour analyse sans arrêter le traitement.

→Dans un `DoFn`, utiliser un bloc try-catch pour le parsing. Utiliser un DoFn à sorties multiples avec `TupleTag` pour acheminer les enregistrements valides vers la sortie principale et les enregistrements invalides (avec contexte d'erreur) vers une sortie d'erreur séparée. Envoyer la PCollection d'erreur vers une destination de file d'attente de lettres mortes comme un sujet Pub/Sub ou une table BigQuery.

Pourquoi: Ce modèle offre une résilience en isolant les mauvaises données, en évitant les échecs de pipeline et en garantissant que les enregistrements échoués sont capturés pour le débogage et le retraitement.

Les requêtes BigQuery sont lentes et coûteuses, filtrant généralement sur une colonne de date/heure et d'autres colonnes à forte cardinalité (par exemple, `customer_id`).

→Partitionner la table par la colonne de date/heure (par exemple, partitions quotidiennes). Grouper la table par jusqu'à quatre colonnes fréquemment filtrées (par exemple, `customer_id`, `product_category`).

Pourquoi: Le partitionnement réduit les données scannées aux seules périodes pertinentes. Le regroupement trie davantage les données au sein des partitions, minimisant les données scannées pour les filtres sur les colonnes regroupées. C'est le principal modèle d'optimisation des performances de BQ.

Référence↗

L'application nécessite des lectures et des écritures à faible latence (inférieures à 10 ms) pour des ensembles de données massifs (milliards de lignes), comme pour la personnalisation en temps réel ou un magasin de fonctionnalités IoT.

→Utiliser Bigtable. Concevoir une clé de ligne qui prend en charge le modèle d'accès primaire. Pour les séries temporelles, utiliser `entity_id#reverse_timestamp`.

Pourquoi: Bigtable est un magasin de colonnes larges NoSQL optimisé pour les charges de travail à haut débit et faible latence à grande échelle. BigQuery est destiné à l'analyse et a une latence de recherche ponctuelle plus élevée.

Une application transactionnelle nécessite une distribution globale, une évolutivité horizontale et une forte cohérence avec une interface SQL.

→Utiliser Cloud Spanner avec une configuration multi-région.

Pourquoi: Spanner est le seul service qui offre toutes ces capacités : distribué globalement, transactions ACID et un schéma relationnel. Cloud SQL est régional ; Bigtable n'est pas relationnel et a une cohérence éventuelle entre les clusters.

Un entrepôt de données BigQuery contient de grandes quantités de données historiques qui sont interrogées rarement mais doivent être conservées, ce qui entraîne des coûts de stockage élevés.

→Aucune action requise pour les partitions/tables non modifiées pendant 90 jours consécutifs. BigQuery applique automatiquement la tarification du stockage à long terme, une réduction de coût d'environ 50 %.

Pourquoi: Il s'agit d'une optimisation automatique et intégrée. Le déplacement manuel des données vers GCS (sauf pour le niveau Archive) est souvent inutile et ajoute de la complexité.

Les données d'un bucket Cloud Storage ont un modèle d'accès prévisible : fréquentes pendant 30 jours, occasionnelles pendant 90 jours, puis rares.

→Configurer une politique de cycle de vie de bucket pour faire passer les objets : Standard -> Nearline (à 30 jours) -> Coldline (à 90 jours).

Pourquoi: Les politiques de cycle de vie automatisent l'optimisation des coûts en déplaçant les données vers des classes de stockage moins chères à mesure qu'elles sont moins fréquemment consultées.

Une table BigQuery doit appliquer une contrainte de clé unique.

→Appliquer l'unicité dans le pipeline de chargement. Utiliser une instruction `MERGE` avec une logique qui n'insère que si la clé n'existe pas déjà. Alternativement, utiliser un DoFn avec état dans Dataflow pour la déduplication.

Pourquoi: BigQuery n'applique pas les contraintes `PRIMARY KEY` ou `UNIQUE`. L'unicité doit être gérée par le processus de chargement des données.

Une table de dimension dans BigQuery doit conserver un historique complet des modifications pour l'analyse à un point précis dans le temps (SCD Type 2).

→Ajouter les colonnes `valid_from` et `valid_to` de type horodatage. Lorsqu'un changement se produit, utiliser une instruction `MERGE` pour mettre à jour la colonne `valid_to` de l'ancien enregistrement et insérer un nouvel enregistrement.

Pourquoi: C'est le modèle standard pour implémenter SCD Type 2 dans un entrepôt de données. `MERGE` fournit un moyen efficace et atomique d'effectuer les opérations de mise à jour et d'insertion requises.

Une application nécessite une base de données gérée et évolutive pour les documents JSON à schéma flexible avec support transactionnel et besoins de requêtes complexes.

→Utiliser Firestore en mode natif. Utiliser des collections, des documents et des sous-collections pour modéliser les données. Créer des index composites pour les requêtes complexes.

Pourquoi: Firestore est une base de données de documents NoSQL serverless optimisée pour les charges de travail transactionnelles avec de riches capacités de requête, contrairement à Bigtable (clé-valeur) ou BigQuery (analytique).

Besoin d'interroger des données dans Cloud Storage (Parquet, Avro, etc.) via BigQuery tout en appliquant une sécurité fine (ligne/colonne).

→Créer des tables BigLake sur les données Cloud Storage. Appliquer les politiques de sécurité au niveau des lignes et des colonnes de BigQuery aux tables BigLake.

Pourquoi: BigLake étend la gouvernance de BigQuery aux données au format ouvert dans Cloud Storage, permettant une architecture de lac de données unifiée et sécurisée.

Une équipe de science des données doit entraîner des modèles ML sur de grands ensembles de données BigQuery sans déplacer ni exporter les données.

→Utiliser BigQuery ML. Écrire des instructions `CREATE MODEL` en SQL pour entraîner, évaluer et prédire directement dans BigQuery.

Pourquoi: BQML élimine le déplacement des données, simplifie le workflow ML et exploite la puissance de traitement de BigQuery, accélérant l'itération.

Référence↗

Les modèles ML nécessitent des fonctionnalités pour l'entraînement par lots et l'inférence en ligne à faible latence, avec une cohérence entre eux pour éviter les biais.

→Utiliser Vertex AI Feature Store. Ingérer des fonctionnalités par lots ou en streaming. Il fournit un magasin hors ligne (BigQuery) pour l'entraînement et un magasin en ligne (Bigtable) pour le service à faible latence.

Pourquoi: Il s'agit d'un service géré et spécialement conçu qui résout le problème complexe de la cohérence des fonctionnalités, de l'exactitude à un instant donné et des exigences de double service.

Les utilisateurs métier ont besoin de BI en libre-service, mais créent des métriques et des rapports incohérents lorsqu'ils interrogent directement l'entrepôt de données.

→Implémenter une couche sémantique Looker en utilisant LookML. Définir les dimensions, les mesures et les jointures une fois pour toutes. Les utilisateurs explorent le modèle gouverné au lieu des tables brutes.

Pourquoi: LookML fournit une "source unique de vérité" pour la logique métier, garantissant des rapports cohérents et précis tout en permettant l'exploration en libre-service.

Besoin d'implémenter des contrôles automatisés de qualité des données (valeurs nulles, unicité, plages de valeurs) et une surveillance pour les données dans BigQuery et Cloud Storage.

→Utiliser Dataplex Data Quality. Définir des règles en YAML ou utiliser des règles auto-générées à partir du profilage. Planifier des analyses pour surveiller la qualité au fil du temps.

Pourquoi: Dataplex fournit une solution de qualité des données gérée et intégrée qui est plus évolutive et maintenable que les vérifications SQL ou les scripts personnalisés.

Découvrir des regroupements ou segments naturels au sein d'un ensemble de données client sans étiquettes prédéfinies.

→Utiliser BigQuery ML pour entraîner un modèle de clustering `KMEANS` directement sur les données client.

Pourquoi: K-means est un algorithme d'apprentissage non supervisé idéal pour la segmentation. BQML le rend accessible via SQL sans exportation de données.

Activer la recherche sémantique (basée sur le sens, pas sur les mots-clés) sur les données textuelles stockées dans BigQuery.

→Utiliser la fonction `ML.GENERATE_EMBEDDING` avec un modèle de base Vertex AI pour créer des embeddings vectoriels. Les stocker et utiliser la fonction `VECTOR_SEARCH` pour la recherche de similarité.

Pourquoi: Ce modèle intègre de puissantes capacités de recherche sémantique directement dans BigQuery, évitant le besoin d'index de recherche externes comme Elasticsearch.

Intégrer les capacités des grands modèles de langage (LLM) comme la synthèse de texte ou la classification directement dans un workflow d'analyse BigQuery.

→Créer un modèle distant BigQuery ML qui pointe vers un endpoint LLM Vertex AI. Utiliser la fonction `ML.GENERATE_TEXT` dans une requête SQL pour traiter les données textuelles.

Pourquoi: Ceci intègre étroitement l'IA générative dans SQL, permettant aux analystes d'exploiter les LLM sur leurs données sans quitter l'environnement BigQuery ni écrire de code d'application complexe.

Un pipeline de données multi-étapes implique des dépendances complexes, des réessais et des tâches à travers différents services GCP (par exemple, Dataflow, BigQuery, Dataproc).

→Utiliser Cloud Composer (Apache Airflow géré). Définir le workflow comme un Graphe Acyclique Dirigé (DAG) en utilisant Python.

Pourquoi: Composer est l'outil GCP désigné pour l'orchestration de workflows complexes, offrant une gestion robuste des dépendances, la planification, la logique de réessai et la surveillance que les outils plus simples comme Cloud Scheduler n'ont pas.

Une tâche de DAG Airflow qui appelle une API externe échoue fréquemment en raison de problèmes de réseau transitoires.

→Configurer les réessais au niveau de la tâche dans le DAG avec `retry_exponential_backoff=True`. Cela augmente le délai entre les réessais, donnant au système externe le temps de récupérer.

Pourquoi: Le backoff exponentiel est une bonne pratique pour réessayer les échecs transitoires, car il évite de surcharger un système en aval en difficulté avec des requêtes rapides et répétées.

Gérer, versionner, tester et planifier un ensemble complexe de transformations SQL interdépendantes dans BigQuery.

→Utiliser Dataform. Définir les tables et les dépendances dans des fichiers SQLX, utiliser Git pour le contrôle de version, écrire des assertions de qualité des données et planifier les workflows d'exécution.

Pourquoi: Dataform est la solution native de Google Cloud pour l'ELT, offrant la gestion des dépendances, les tests et le contrôle de version pour les transformations BigQuery, promouvant les meilleures pratiques DataOps.

Besoin de comprendre et de visualiser comment les données circulent de la source au rapport final à travers plusieurs services comme BigQuery et Dataflow.

→Utiliser Dataplex, qui capture et affiche automatiquement la lignée des données des services Google Cloud pris en charge dans l'interface utilisateur de Data Catalog.

Pourquoi: Le suivi automatisé de la lignée est crucial pour l'analyse d'impact, le débogage et la gouvernance. Dataplex fournit cette fonctionnalité prête à l'emploi pour les services intégrés.

Une tâche de streaming Dataflow en cours d'exécution doit être mise à jour avec une nouvelle logique sans perte de données ni d'état.

→Lancer la nouvelle version du pipeline en utilisant l'option de ligne de commande `--update` et en spécifiant l'ID de la tâche du pipeline en cours d'exécution. Utiliser le mode `drain` pour permettre à l'ancienne tâche de terminer le traitement des données en cours.

Pourquoi: Le mécanisme de mise à jour sur place de Dataflow offre un moyen de déployer des modifications sur les pipelines de streaming sans interruption, tout en préservant l'état et en garantissant un traitement exactement une fois.

Pour des raisons de conformité, tous les accès en lecture et en écriture aux données sensibles dans BigQuery et Cloud Storage doivent être journalisés et auditables.

→Activer les journaux d'audit Cloud, en particulier les journaux d'accès aux données, pour les services pertinents. Créer un collecteur de journaux pour exporter ces journaux vers BigQuery pour une rétention et une analyse à long terme.

Pourquoi: Les journaux d'audit Cloud fournissent un enregistrement complet et infalsifiable des accès aux données. L'envoi des journaux vers BigQuery permet un audit et des rapports puissants basés sur SQL.

Les ensembles de données, tables et contrôles d'accès BigQuery doivent être gérés en tant que code pour la répétabilité et le versionnement (Infrastructure as Code).

→Définir toutes les ressources BigQuery (ensembles de données, tables, politiques IAM) dans des fichiers de configuration Terraform (`.tf`). Gérer les déploiements via un pipeline CI/CD.

Pourquoi: Terraform est la norme pour l'IaC sur GCP, permettant une gestion auditée, versionnée et cohérente de l'infrastructure de données, empêchant la dérive de configuration manuelle.

Un modèle ML en production présente une dégradation des performances au fil du temps.

→Implémenter la surveillance de modèle Vertex AI. Configurer une tâche de surveillance pour détecter le décalage entre l'entraînement et le service et la dérive de prédiction en comparant le trafic de production à une référence. Configurer des alertes pour déclencher une investigation ou un réentraînement automatisé.

Pourquoi: La performance du modèle se dégrade en raison de la dérive des données. Une surveillance proactive est essentielle pour la détecter et maintenir la précision du modèle, justifiant le réentraînement.