Guide - ADP Google Cloud Associate Data Practitioner

Charger des fichiers batch volumineux (CSV, Parquet, Avro) depuis Cloud Storage vers BigQuery.

Utiliser une tâche de chargement BigQuery. Spécifiez un URI générique (par exemple, `gs://bucket/path/*`) pour charger plusieurs fichiers en une seule tâche.

Pourquoi: C'est la méthode la plus rapide et la plus rentable pour l'ingestion par lots. Les tâches de chargement sont gratuites. Cela évite les coûts par ligne du streaming.

Référence

Ingérer des données en temps réel et à haut volume (IoT, clickstream) avec un potentiel de transformation.

Pub/Sub -> Dataflow -> BigQuery.

Pourquoi: Modèle de streaming évolutif canonique. Pub/Sub fournit un tampon durable et évolutif. Dataflow permet des transformations complexes, le fenêtrage et le traitement "exactly-once".

Répliquer une base de données opérationnelle (MySQL, PostgreSQL, Oracle) vers BigQuery avec une faible latence, en capturant toutes les modifications (insertions, mises à jour, suppressions).

Utiliser Datastream pour la Capture de Données Modifiées (CDC).

Pourquoi: Conçu spécifiquement pour la CDC en temps réel à faible impact. Il gère le remplissage initial et diffuse les modifications continues directement vers BigQuery.

Référence

Effectuer des validations, enrichissements ou transformations de données complexes (par exemple, aplatir des JSON/XML imbriqués) avant le chargement dans BigQuery.

Utiliser un pipeline Dataflow avec des transformations Apache Beam personnalisées (par exemple, ParDo).

Pourquoi: Dataflow offre une flexibilité maximale pour le code personnalisé (Python/Java), la logique complexe et le routage des enregistrements invalides vers une file d'attente de lettres mortes.

Transférer des téraoctets ou des pétaoctets de données d'un autre cloud (par exemple, S3) ou d'un centre de données sur site vers Cloud Storage.

Pour le transfert de cloud à cloud, utiliser Storage Transfer Service. Pour le transfert sur site avec une bande passante réseau limitée, utiliser Transfer Appliance.

Pourquoi: STS est un service géré et performant pour les transferts en ligne. Transfer Appliance est destiné aux transferts hors ligne (expédition physique) lorsque le réseau est le goulot d'étranglement.

Interroger des données résidant dans Cloud Storage ou Amazon S3 directement depuis BigQuery sans les charger.

Créer une table externe BigQuery. Pour une gouvernance unifiée avec Spark, utiliser une table BigLake.

Pourquoi: Évite la duplication des données et les coûts de stockage dans BigQuery. BigLake ajoute une sécurité granulaire (au niveau des lignes/colonnes) et une gouvernance sur les données de stockage d'objets.

Référence

Un pipeline d'ingestion doit s'adapter automatiquement lorsque de nouvelles colonnes sont ajoutées aux fichiers sources (JSON, Avro).

Configurer la tâche de chargement BigQuery avec `schemaUpdateOptions` défini sur `ALLOW_FIELD_ADDITION`.

Pourquoi: Automatise l'évolution du schéma. BigQuery ajoute les nouvelles colonnes au schéma de la table sans faire échouer la tâche de chargement.

Diffuser des données à haut volume vers BigQuery avec une sémantique "exactly-once" à un coût inférieur à l'API de streaming héritée.

Utiliser l'API BigQuery Storage Write.

Pourquoi: Offre un débit plus élevé et des coûts inférieurs à l'ancienne API `insertAll`, avec des garanties solides comme la livraison "exactly-once" au sein d'un flux.

Référence

Orchestrer un workflow complexe avec plusieurs tâches dépendantes (par exemple, Dataflow, BigQuery, Cloud Functions) selon un calendrier.

Utiliser Cloud Composer (Apache Airflow géré).

Pourquoi: La norme pour l'orchestration de workflows complexes. Fournit des DAGs pour définir les dépendances, la planification, les tentatives, les alertes et un riche écosystème d'opérateurs.

Un DAG Cloud Composer doit faire une pause et attendre qu'un fichier spécifique apparaisse dans un bucket Cloud Storage avant de continuer.

Utiliser le `GCSObjectExistenceSensor` dans le DAG Airflow.

Pourquoi: C'est le modèle idiomatique de "capteur" Airflow pour attendre des conditions externes. C'est plus efficace qu'une boucle de sondage personnalisée dans un PythonOperator.

Un pipeline de streaming Dataflow doit agréger correctement les événements par horodatage, même si les événements arrivent dans le désordre ou en retard.

Utiliser le fenêtrage temporel des événements avec des filigranes (watermarks) et configurer `allowedLateness`.

Pourquoi: Cette fonctionnalité principale de Dataflow/Beam regroupe correctement les données en fonction du moment où l'événement s'est produit, et non du moment où il a été traité. `allowedLateness` empêche la suppression des données tardives.

Exécuter des tâches Apache Spark non interactives et à grande échelle pour le traitement par lots ou le ML.

Utiliser un cluster Dataproc. Pour des économies maximales, utiliser un cluster éphémère avec des VM Spot (anciennement VM préemptibles).

Pourquoi: Dataproc est le service Spark/Hadoop géré. Les clusters éphémères n'existent que pendant la durée de la tâche, et les VM Spot offrent des remises importantes pour les charges de travail tolérantes aux pannes.

Créer un pipeline Dataflow standardisé qui peut être exécuté par différentes équipes avec des paramètres variables (par exemple, chemins d'entrée/sortie).

Empaqueter le pipeline en tant que modèle Dataflow Flex (Flex Template).

Pourquoi: Les Flex Templates sont la norme moderne pour les tâches Dataflow réutilisables. Ils sont basés sur des conteneurs, prennent en charge les dépendances personnalisées et acceptent les paramètres d'exécution.

Une tâche dans un DAG Cloud Composer échoue par intermittence en raison de problèmes externes temporaires (par exemple, limitation du taux d'API, contention de ressources).

Configurer `retries` et `retry_delay` avec `retry_exponential_backoff=True` pour la tâche.

Pourquoi: Cela rend le pipeline résilient en relançant automatiquement les tâches échouées avec des délais croissants, résolvant souvent les problèmes transitoires sans intervention manuelle.

Un pipeline de streaming Dataflow prend du retard, affichant une latence système ou une fraîcheur des données élevée.

Examiner les métriques de surveillance Dataflow. Vérifier si l'autoscaling atteint la limite `maxNumWorkers`. Augmenter `maxNumWorkers` ou passer à un type de machine plus grand.

Pourquoi: Une latence système élevée est un indicateur principal d'une capacité de traitement insuffisante. Le pipeline a besoin de plus de workers ou de workers plus grands pour suivre l'afflux de données.

Optimiser une grande table BigQuery pour le coût et la performance des requêtes.

Partitionner la table par une colonne d'unité de temps fréquemment filtrée (par exemple, date de transaction). Regrouper la table par d'autres colonnes à forte cardinalité et fréquemment filtrées (par exemple, `customer_id`).

Pourquoi: Le partitionnement est le moyen le plus efficace de réduire les coûts et la latence en élaguant la quantité de données analysées. Le regroupement améliore encore les performances en triant les données au sein des partitions.

Référence

Empêcher la copie de données d'un ensemble de données BigQuery sensible vers une destination non autorisée (par exemple, un bucket GCS public), même par un utilisateur ayant des identifiants valides.

Utiliser les Contrôles de Service VPC pour créer un périmètre de service autour du projet contenant l'ensemble de données BigQuery.

Pourquoi: Les Contrôles de Service VPC agissent comme un "pare-feu virtuel" pour les services GCP, empêchant les données de quitter le périmètre. C'est un contrôle essentiel de défense en profondeur contre l'exfiltration de données.

Référence

Restreindre l'accès aux colonnes sensibles (par exemple, PII) dans une table BigQuery aux groupes autorisés, tout en permettant aux autres d'interroger les colonnes restantes.

Utiliser Data Catalog pour créer une taxonomie et des tags de stratégie (policy tags). Appliquer les tags de stratégie aux colonnes sensibles et accorder le rôle "Fine-Grained Reader" aux groupes autorisés.

Pourquoi: C'est la méthode native et évolutive pour la sécurité au niveau des colonnes dans BigQuery. Elle offre une gouvernance centralisée sans avoir besoin de créer et de gérer des vues distinctes.

Filtrer une table afin que les utilisateurs ne puissent voir que les lignes qui les concernent (par exemple, les directeurs des ventes ne voient que les données de leur propre région).

Créer une politique de sécurité au niveau des lignes (Row-Level Security Policy) sur la table qui filtre les lignes en fonction de `SESSION_USER()` .

Pourquoi: Fournit un filtrage dynamique basé sur des prédicats au moment de la requête. C'est plus sécurisé et gérable que de créer une vue autorisée pour chaque utilisateur ou rôle.

Supprimer automatiquement les données d'une table BigQuery après une période de rétention spécifiée pour se conformer aux réglementations (par exemple, supprimer les données de plus de 7 ans).

Pour les données de séries temporelles, définir une expiration de partition sur la table partitionnée par temps. Pour les autres tables, définir l'expiration par défaut de la table.

Pourquoi: C'est une fonctionnalité intégrée "définir et oublier" qui assure la conformité sans scripts de nettoyage manuels ni orchestration externe.

Une table BigQuery a été accidentellement modifiée ou supprimée.

Utiliser BigQuery Time Travel pour interroger la table telle qu'elle existait à un instant précis avant l'incident, en utilisant `FOR SYSTEM_TIME AS OF`.

Pourquoi: BigQuery maintient automatiquement un historique de 7 jours des données de table. Cela permet une récupération instantanée dans la fenêtre de voyage dans le temps sans avoir besoin de restaurer à partir de sauvegardes.

Référence

Découvrir, gérer, sécuriser et surveiller les actifs de données (BigQuery, GCS) à l'échelle d'une organisation entière.

Utiliser Dataplex.

Pourquoi: Dataplex agit comme un "data fabric" intelligent, offrant un panneau unifié pour la gouvernance des données, la qualité, la lignée, la découverte et la gestion du cycle de vie à travers des silos de données disparates.

Comprendre et visualiser comment les données circulent depuis les systèmes sources, à travers les tâches de transformation, jusqu'aux tables de reporting finales.

Utiliser Dataplex Data Lineage.

Pourquoi: Capture automatiquement les informations de lignée à partir des journaux BigQuery, Data Fusion et Composer pour fournir une vue interactive basée sur des graphes des dépendances de données pour l'analyse d'impact et l'audit.

Assurer des performances et des coûts de requête prévisibles pour les charges de travail critiques, en évitant la "contention de slots" des autres utilisateurs.

Acheter des éditions BigQuery (tarification basée sur la capacité). Créer des réservations pour dédier un pool de slots à des projets ou dossiers spécifiques.

Pourquoi: Passe d'un pool partagé et à la demande à une capacité de calcul dédiée, garantissant les ressources pour les tâches critiques et offrant une facturation prévisible.

Analyser tous les actifs de données dans BigQuery et Cloud Storage pour identifier et classer automatiquement les PII et autres données sensibles.

Configurer une tâche d'analyse de découverte Cloud Data Loss Prevention (DLP).

Pourquoi: Cloud DLP utilise des centaines de détecteurs prédéfinis pour trouver des données sensibles à grande échelle. Il peut s'intégrer à Data Catalog pour appliquer automatiquement des tags de stratégie pour la gouvernance.

Une application conteneurisée (sur GKE ou Cloud Run) doit s'authentifier en toute sécurité auprès de BigQuery sans gérer les clés de compte de service.

Utiliser Workload Identity.

Pourquoi: La meilleure pratique recommandée pour l'authentification de service à service. Elle mappe un compte de service Kubernetes à un compte de service IAM GCP, en utilisant des jetons de courte durée et automatiquement renouvelés.

Pour la conformité, générer un rapport de tous les utilisateurs ayant interrogé une table BigQuery sensible au cours des 90 derniers jours.

Activer et interroger les journaux d'audit d'accès aux données de BigQuery, qui peuvent être acheminés vers un ensemble de données BigQuery pour analyse.

Pourquoi: Les journaux d'accès aux données fournissent un enregistrement immuable de qui a accédé à quelles données et quand. Ils sont essentiels pour les audits de sécurité et de conformité, mais doivent être explicitement activés.

Identifier quels utilisateurs ou quelles requêtes sont responsables des coûts élevés de BigQuery.

Interroger la vue `INFORMATION_SCHEMA.JOBS`.

Pourquoi: Cette vue de métadonnées contient des informations détaillées pour chaque exécution de requête, y compris l'utilisateur, les octets facturés et les slots consommés, permettant une attribution et une analyse précises des coûts.

Effectuer des calculs analytiques complexes comme les totaux cumulés, le classement au sein de groupes (par exemple, les N meilleurs par catégorie) ou la comparaison d'une ligne à une ligne précédente.

Utiliser les fonctions de fenêtre SQL de BigQuery (`SUM() OVER (...)`, `RANK() OVER (...)`, `LAG() OVER (...)`).

Pourquoi: La méthode SQL standard et la plus efficace pour effectuer des calculs sur un ensemble de lignes de table qui sont liées d'une manière ou d'une autre à la ligne actuelle.

Créer et partager des tableaux de bord interactifs et à rafraîchissement automatique sur les données BigQuery pour les utilisateurs métier qui n'écrivent pas de SQL.

Utiliser Looker Studio.

Pourquoi: L'outil de visualisation natif et gratuit de GCP. Il se connecte directement à BigQuery et permet le partage via un simple lien, gérant les identifiants de source de données séparément de l'accès utilisateur.

Référence

Permettre aux analystes métier d'utiliser des outils de feuille de calcul familiers (tableaux croisés dynamiques, graphiques, formules) pour analyser des téraoctets de données dans BigQuery.

Utiliser les Feuilles Connectées (Connected Sheets).

Pourquoi: Fournit une connexion en direct de Google Sheets à BigQuery. Tout le traitement et le calcul ont lieu dans BigQuery, contournant les limites de taille et de performance d'une feuille de calcul traditionnelle.

Un tableau de bord Looker Studio qui interroge de grandes agrégations complexes est lent et coûteux.

Créer une vue matérialisée BigQuery pour pré-calculer les agrégations. Pointer la source de données Looker Studio vers la vue matérialisée.

Pourquoi: Les vues matérialisées pré-calculent et mettent en cache les résultats de requêtes coûteuses. Cela améliore considérablement les performances des tableaux de bord et réduit les coûts de requête pour les charges de travail répétitives.

Construire, entraîner et servir un modèle de machine learning (par exemple, pour la classification, la régression ou la prévision) en utilisant des données résidant dans BigQuery.

Utiliser BigQuery ML (BQML).

Pourquoi: Démocratise le ML en permettant aux utilisateurs d'entraîner des modèles avec la syntaxe SQL standard `CREATE MODEL`. Le modèle réside et s'exécute dans BigQuery, simplifiant le déploiement et la prédiction.

Référence

Prévoir les métriques commerciales futures (par exemple, ventes, demande) basées sur des données de séries temporelles historiques.

Utiliser BigQuery ML avec le type de modèle `ARIMA_PLUS`.

Pourquoi: `ARIMA_PLUS` est un modèle BQML spécialement conçu pour la prévision de séries temporelles qui gère automatiquement les tendances, la saisonnalité, les jours fériés et la détection d'anomalies.

Une requête BigQuery joignant une très grande table de faits (TBs) avec une petite table de dimensions (<100 Mo) est lente.

S'assurer que BigQuery utilise une jointure de diffusion (broadcast join). Bien que souvent automatique, vous pouvez vérifier le plan de requête ou utiliser un indice `JOIN` si nécessaire.

Pourquoi: Une jointure de diffusion envoie l'intégralité de la petite table à chaque slot de traitement, évitant un coûteux et lent brassage de données de la grande table à travers le réseau.

Un modèle BigQuery ML doit être réentraîné régulièrement (par exemple, chaque semaine) sur de nouvelles données pour éviter la dérive du modèle.

Utiliser une requête planifiée BigQuery pour exécuter une instruction `CREATE OR REPLACE MODEL`.

Pourquoi: C'est le moyen le plus simple et le plus intégré d'automatiser le réentraînement de BQML. Il ne nécessite aucun service externe comme Composer ou Cloud Functions.

Construire un système de recommandation par filtrage collaboratif (par exemple, "les utilisateurs qui ont acheté X ont également acheté Y").

Utiliser BigQuery ML avec le type de modèle `MATRIX_FACTORIZATION`.

Pourquoi: Ce modèle est spécifiquement conçu pour les tâches de recommandation basées sur les données d'interaction utilisateur-élément.