Google PDE: Orchestration de workflows et automatisation de pipelines — 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’orchestration des workflows et l’automatisation des pipelines coordonnent les tâches de données entre les services afin que l’ingestion, la transformation, les contrôles de qualité et la publication se déroulent de manière fiable, sécurisée et rentable. Dans Google Cloud, l’orchestration doit s’aligner sur le modèle d’exécution de chaque charge de travail : batch planifié, flux événementiel, ad-hoc ou tâches de longue durée. Les objectifs de conception sont la répétabilité, l’idempotence, l’observabilité, le moindre privilège et la promotion sécurisée entre les environnements.

Choix clés :

Orchestration de batch centrée sur le code avec Cloud Composer (Apache Airflow) pour les DAGs, les dépendances de tâches et la planification avancée.
Chorégraphie d’API sans serveur avec Cloud Workflows pour des séquences légères, événementielles et inter-services.
Points de terminaison d’exécution tels que les jobs Cloud Run ou les jobs Dataproc, déclenchés par Cloud Scheduler pour le cron ou Eventarc pour les événements.
Orchestration native SQL avec Dataform pour les transformations BigQuery, les assertions et la gestion des versions.

Le modèle opérationnel met l’accent sur les nouvelles tentatives avec un backoff exponentiel limité, les délais d’attente (timeouts), les SLA, le rattrapage (catchup) et les remplissages (backfills), la conception de tâches idempotentes pour des réexécutions sûres, et une gestion robuste des échecs avec capture dans une file de messages morts (dead-letter). La sécurité est appliquée via des comptes de service par pipeline, l’isolation des secrets, la paramétrisation et un IAM au moindre privilège. Le CI/CD, l’infrastructure en tant que code (IaC) et une télémétrie complète parachèvent une approche prête pour la production.

Orchestration sur Google Cloud : Outils et Patrons

Cloud Composer (Airflow)

Les DAGs définissent des graphes d’exécution acycliques dirigés avec des dépendances explicites. Utilisez la TaskFlow API ou des opérateurs (par ex., BigQuery, Dataflow, Dataproc, Cloud Run) pour exprimer les tâches. Les Sensors et les opérateurs différables (deferrable operators) réduisent la charge du planificateur pour les conditions d’attente (par ex., la finalisation d’un objet dans Cloud Storage ou l’apparition d’une partition dans BigQuery).
Planification : les expressions cron, start_date, end_date et catchup contrôlent les exécutions historiques. Utilisez catchup pour les remplissages (backfills) ; désactivez-le pour les cibles adjacentes au streaming ou non idempotentes. Limitez la concurrence avec max_active_runs et les pools pour protéger les systèmes en aval.
Dépendances : set_upstream/set_downstream ou dépendances taskflow. Pour une orchestration basée sur les métadonnées, générez des tâches dynamiquement à partir d’une table de contrôle BigQuery (par ex., une liste de clients/partitions) en utilisant le mappage de tâches dynamique (dynamic task mapping), ce qui maintient le temps d’analyse du DAG stable et rend les tâches pilotées par les données.
Exemple de fragment de DAG (concis) :

undefined

Cloud Workflows, Cloud Scheduler, jobs Cloud Run et exécution événementielle

Cloud Workflows orchestre les API Google et les points de terminaison HTTP avec des nouvelles tentatives intégrées, des boucles, des branches parallèles et une logique de compensation. Il est idéal pour un flux de contrôle léger entre des services tels que BigQuery, Dataflow, Batch et les jobs Cloud Run.
Cloud Scheduler déclenche des Workflows, des sujets Pub/Sub ou des services HTTP pour une automatisation de type cron. Pour un batch quotidien à 02:00, planifiez un Workflow qui lance un job Dataflow ou un job Dataproc.
Les jobs Cloud Run exécutent des étapes de batch conteneurisées avec une nouvelle tentative automatique et un minimum d’opérations. Ils se marient bien avec Workflows pour des tâches de données en plusieurs étapes ou pour le pré/post-traitement autour de Dataflow ou BigQuery.
Événementiel : utilisez Eventarc pour router la finalisation d’objet Cloud Storage, les messages Pub/Sub ou les Audit Logs vers Cloud Run ou Workflows. Pour les notifications d’insertion de job BigQuery sur une seule table, créez un récepteur (sink) Cloud Logging avec un filtre avancé vers Pub/Sub, puis déclenchez votre consommateur à partir de ce sujet.

Dataform : workflows SQL pour BigQuery

Modélisez des graphes de dépendances avec ref(), définissez des tables/vues/incrémentiels, et orchestrez les constructions (builds) par tags ou planifications. Dataform compile le SQLX en plans d’exécution ordonnés, permettant une orchestration basée sur les métadonnées à partir de définitions déclaratives.
Les assertions garantissent la qualité des données. Une assertion est une requête qui doit renvoyer zéro ligne pour réussir. Exemple d’assertion :

undefined

Versions et contrôles de dépôt : stockez le code dans un dépôt, utilisez des branches et des revues de code, et promouvez les versions (releases) taguées vers les environnements (par ex., dev, test, prod) avec des variables spécifiques à l’environnement. Validez les déploiements via des vérifications CI/CD et les résultats des assertions.

Dataproc, Dataflow et patrons de stockage

Pour la réutilisation de Hadoop/Spark avec un minimum d’opérations, utilisez Dataproc avec le GCS connector pour persister les données au-delà de la durée de vie du cluster et minimiser le coût du disque persistant. Créez des clusters éphémères par job pour l’isolation et le contrôle des coûts ; orchestrez avec Composer ou Workflows.
Pour l’ingestion en batch avec des lignes mal formées, exécutez Dataflow pour écrire les enregistrements valides dans BigQuery et router les erreurs d’analyse/validation vers une table BigQuery de messages morts (dead-letter) pour inspection.

Fiabilité, gestion des pannes et idempotence

Nouvelles tentatives, délais d’attente et backoff

Utilisez un backoff exponentiel limité pour les pannes transitoires et plafonnez les fenêtres de nouvelles tentatives totales au SLA de la tâche. Par exemple, un frontend ou une tâche qui interroge une base de données toutes les 15 minutes devrait effectuer des nouvelles tentatives avec un backoff exponentiel jusqu’à 15 minutes, puis remonter une défaillance contrôlée.
Configurez le execution_timeout par tâche et les SLA globaux du DAG dans Airflow ; dans Workflows, définissez des délais d’attente par étape et des politiques de nouvelle tentative avec max_doublings et max_retry_duration. Pour les jobs Cloud Run, définissez le nombre de nouvelles tentatives et le backoff.

Backfills, rattrapage et gestion des pannes

Activez le rattrapage (catchup) pour le recalcul historique lorsque les tâches sont idempotentes et que les sources sont partitionnées par date. Pour les sorties non déterministes ou les effets de bord externes, envisagez des DAG dédiés au backfill ou des tables d’audit en écriture pour suivre ce qui a été produit.
Utilisez des sujets/tables de lettres mortes (dead-letter) pour les échecs au niveau de l’enregistrement dans les transformations en streaming/batch. Pour Dataflow en mode batch, capturez les lignes incorrectes avec des tags d’erreur et agrégez les métriques d’erreur ; pour le streaming, utilisez les DLQ Pub/Sub.

Conception de tâches idempotentes et réexécutions

BigQuery : préférez MERGE ou INSERT avec des clés de déduplication ; utilisez insertId pour dédoublonner les insertions en streaming. Pour le traitement par lots (batch), écrivez dans une table de staging puis effectuez un MERGE dans la cible au sein d’une étape transactionnellement sûre pour permettre des réexécutions complètes.
Cloud Storage : utilisez des préconditions de génération et des noms d’objets déterministes (par ex., préfixe/date/hash) afin que les réexécutions écrasent les données en toute sécurité et uniquement lorsque c’est attendu.
Pub/Sub et Dataflow : concevez pour une livraison de type « au moins une fois » (at-least-once). Incluez des identifiants de message (par ex., ID de paquet, horodatage logique de l’événement) pour que les systèmes en aval puissent dédoublonner et raisonner sur le retard. Si les règles métier acceptent une sémantique où « le premier événement traité l’emporte », documentez ce compromis et surveillez les décalages (skew) ; sinon, déterminez les gagnants par heure de l’événement avec des critères de départage (tie-breakers).
Reprise après une défaillance partielle : partitionnez les sorties par run_id ou par date, écrivez des marqueurs d’achèvement et faites en sorte que les tâches en aval dépendent de ces marqueurs. Ne retraitez que les partitions marquées comme incomplètes.

Dépannage et scalabilité

Lorsqu’un tableau de bord en streaming manque des événements mais que Pub/Sub montre qu’ils sont présents, exécutez un jeu de données fixe et connu à travers le pipeline Dataflow pour isoler les défauts de transformation. Validez le fenêtrage (windowing), les déclencheurs (triggers) et le retard autorisé (allowed lateness).
Mode de défaillance courant : créer un pipeline de streaming sans fenêtrage/déclencheurs appropriés pour les sources non bornées ou utiliser une fenêtre partitionnée (sharded window) de manière incorrecte peut faire échouer la création du pipeline ou provoquer des explosions de l’état (state blowups).
Mettez à l’échelle Dataflow via le nombre maximal de workers et l’algorithme d’autoscaling ; pour les pics de charge (par ex., 50 000 installations), augmentez le nombre maximal de workers pour permettre une mise à l’échelle horizontale pendant les pics.

Sécurité, paramétrage, environnements et CI/CD

Paramétrage et gestion de la configuration

Externalisez la configuration par environnement. Dans Composer, utilisez les Variables, les Connexions et les variables d’environnement ; utilisez des modèles (template) pour les paramètres du DAG par date d’exécution ou partition. Dans Workflows, utilisez des arguments d’exécution (runtime) et des workflows distincts par environnement, ou lisez la configuration depuis Secret Manager.
Utilisez une orchestration pilotée par les métadonnées en lisant une table de contrôle (par ex., un dataset de configuration BigQuery) qui liste les clients, les sources ou les partitions. Générez les tâches dynamiquement afin que les modifications de code soient découplées des changements pilotés par les données.

Secrets, comptes de service et moindre privilège

Stockez les informations d’identification dans Secret Manager et référencez-les à l’exécution. Évitez d’intégrer des secrets dans le code ou dans les Variables Airflow.
Attribuez un compte de service distinct par pipeline avec les rôles IAM minimaux nécessaires. Pour un accès réglementé à BigQuery, isolez les données client dans des datasets distincts, n’accordez des rôles spécifiques au dataset qu’aux utilisateurs approuvés et restreignez l’accès à l’API BigQuery aux principaux (principals) approuvés. Pour le multitenancy, créez un dataset par client et ne liez que les rôles appropriés.

CI/CD et infrastructure as code

Gérez l’infrastructure (environnements Composer, Workflows, jobs Scheduler, sujets Pub/Sub, récepteurs de journaux) avec Terraform. Utilisez des modules pour standardiser les projets/environnements, les secrets et les comptes de service.
Compilez (build) et testez le code du pipeline avec Cloud Build ou GitHub Actions. Automatisez les tests unitaires, le linting SQL, les exécutions à blanc (dry-runs) Dataform et la validation des DAG Airflow. Promouvez les artefacts via des tags ; pour Composer, empaquetez les DAG sous forme de bundles déployables ; pour Dataform, utilisez des branches de release qui sont promues après la réussite des assertions.
Promotion des déploiements : dev → test → prod via des projets distincts et des configurations paramétrées. Utilisez la livraison continue avec des portes d’approbation manuelles et des fenêtres de changement pour les promotions à haut risque.

← Ingestion · Tous les domaines · Machine Learning →

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