Google PDE: Workflow-Orchestrierung und Pipeline-Automatisierung — Lernleitfaden

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

Teil des Google Professional Data Engineer — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Workflow-Orchestrierung und Pipeline-Automatisierung koordinieren Datenaufgaben über verschiedene Dienste hinweg, sodass die Erfassung, Transformation, Qualitätsprüfung und Veröffentlichung zuverlässig, sicher und kosteneffizient erfolgen. In Google Cloud muss die Orchestrierung auf das Ausführungsmodell jeder Workload abgestimmt sein: geplante Batch-Jobs, ereignisgesteuerte Streaming-Jobs, Ad-hoc-Jobs oder langlebige Jobs. Die Designziele sind Wiederholbarkeit, Idempotenz, Beobachtbarkeit (Observability), das Prinzip der geringsten Rechte (Least Privilege) und die sichere Beförderung (Promotion) durch Umgebungen.

Wichtige Auswahlmöglichkeiten:

Code-zentrierte Batch-Orchestrierung mit Cloud Composer (Apache Airflow) für DAGs, Aufgabenabhängigkeiten und erweiterte Zeitplanung.
Serverless API-Choreografie mit Cloud Workflows für leichtgewichtige, ereignisgesteuerte, dienstübergreifende Sequenzen.
Ausführungsendpunkte wie Cloud Run-Jobs oder Dataproc-Jobs, die durch Cloud Scheduler für Cron-Jobs oder durch Eventarc für Ereignisse ausgelöst werden.
SQL-native Orchestrierung mit Dataform für BigQuery-Transformationen, Assertions und Release-Management.

Das Betriebsmodell legt den Schwerpunkt auf Wiederholungsversuche mit begrenztem exponentiellem Backoff, Timeouts, SLAs, Catchup und Backfills, idempotentes Task-Design für sichere Wiederholungen und eine robuste Fehlerbehandlung mit Erfassung in einer Dead-Letter-Queue. Die Sicherheit wird durch Servicekonten pro Pipeline, Isolierung von Secrets, Parametrisierung und IAM mit geringsten Rechten durchgesetzt. CI/CD, Infrastructure as Code und umfassende Telemetrie vervollständigen einen produktionsreifen Ansatz.

Orchestrierung in Google Cloud: Werkzeuge und Muster

Cloud Composer (Airflow)

DAGs definieren gerichtete azyklische Ausführungsgraphen mit expliziten Abhängigkeiten. Verwenden Sie die TaskFlow API oder Operatoren (z. B. BigQuery, Dataflow, Dataproc, Cloud Run), um Aufgaben auszudrücken. Sensoren und aufschiebbare (deferrable) Operatoren reduzieren die Scheduler-Last bei Wartebedingungen (z. B. Objektfinalisierung in Cloud Storage oder das Erscheinen einer Partition in BigQuery).
Zeitplanung: Cron-Ausdrücke, start_date, end_date und catchup steuern historische Ausführungen. Verwenden Sie catchup für Backfills; deaktivieren Sie es für Streaming-nahe oder nicht-idempotente Ziele. Begrenzen Sie die Parallelität mit max_active_runs und Pools, um nachgelagerte Systeme zu schützen.
Abhängigkeiten: set_upstream/set_downstream oder TaskFlow-Abhängigkeiten. Für eine metadatengesteuerte Orchestrierung generieren Sie Aufgaben dynamisch aus einer BigQuery-Steuerungstabelle (z. B. eine Liste von Kunden/Partitionen) mithilfe von dynamischem Task-Mapping. Dies hält die DAG-Parse-Zeit stabil und macht die Aufgaben datengesteuert.
Beispiel (kurz) für ein DAG-Fragment:

undefined

Cloud Workflows, Cloud Scheduler, Cloud Run-Jobs und ereignisgesteuerte Ausführung

Cloud Workflows orchestriert Google-APIs und HTTP-Endpunkte mit integrierten Wiederholungsversuchen, Schleifen, parallelen Zweigen und Kompensationslogik. Es ist ideal für einen leichten Kontrollfluss über Dienste wie BigQuery, Dataflow, Batch und Cloud Run-Jobs hinweg.
Cloud Scheduler löst Workflows, Pub/Sub-Themen oder HTTP-Dienste für eine Automatisierung im Cron-Stil aus. Für einen täglichen Batch-Job um 02:00 Uhr planen Sie einen Workflow, der einen Dataflow-Job oder einen Dataproc-Job startet.
Cloud Run-Jobs führen containerisierte Batch-Schritte mit automatischer Wiederholung und minimalem Betriebsaufwand aus. Sie lassen sich gut mit Workflows für mehrstufige Datenaufgaben oder für die Vor-/Nachverarbeitung rund um Dataflow oder BigQuery kombinieren.
Ereignisgesteuert: Verwenden Sie Eventarc, um die Finalisierung von Cloud Storage-Objekten, Pub/Sub-Nachrichten oder Audit-Logs an Cloud Run oder Workflows weiterzuleiten. Um Benachrichtigungen über Insert-Jobs für eine einzelne Tabelle in BigQuery zu erhalten, erstellen Sie eine Cloud Logging-Senke mit einem erweiterten Filter zu Pub/Sub und lösen Sie dann Ihren Consumer von diesem Thema aus.

Dataform: SQL-Workflows für BigQuery

Modellieren Sie Abhängigkeitsgraphen mit ref(), definieren Sie Tabellen/Views/inkrementelle Tabellen und orchestrieren Sie Builds nach Tags oder Zeitplänen. Dataform kompiliert SQLX in geordnete Ausführungspläne und ermöglicht so eine metadatengesteuerte Orchestrierung aus deklarativen Definitionen.
Assertions stellen die Datenqualität sicher. Eine Assertion ist eine Abfrage, die null Zeilen zurückgeben muss, um erfolgreich zu sein. Beispiel für eine Assertion: – definitions/assert_non_negative_prices.sqlx config { type: “assertion” } SELECT 1 FROM ${ref(‘prices_daily’)} WHERE price < 0 LIMIT 1
Releases und Repository-Steuerung: Speichern Sie Code in einem Repository, verwenden Sie Branches und Reviews und befördern Sie getaggte Releases in Umgebungen (z. B. dev, test, prod) mit umgebungsspezifischen Variablen. Steuern Sie Deployments durch CI/CD-Prüfungen und Assertion-Ergebnisse.

Dataproc, Dataflow und Speichermuster

Für die Wiederverwendung von Hadoop/Spark mit minimalem Betriebsaufwand verwenden Sie Dataproc mit dem GCS-Connector, um Daten über die Lebensdauer des Clusters hinaus zu persistieren und die Kosten für persistente Festplatten zu minimieren. Erstellen Sie ephemere Cluster pro Job zur Isolation und Kostenkontrolle; orchestrieren Sie diese mit Composer oder Workflows.
Für die Batch-Ingestion mit fehlerhaften Zeilen führen Sie Dataflow aus, um valide Datensätze in BigQuery zu schreiben und Parse-/Validierungsfehler zur Überprüfung in eine Dead-Letter-Tabelle in BigQuery weiterzuleiten.

Zuverlässigkeit, Fehlerbehandlung und Idempotenz

Wiederholungsversuche, Timeouts und Backoff

Verwenden Sie begrenzten exponentiellen Backoff für vorübergehende Fehler und begrenzen Sie die gesamten Wiederholungsfenster auf das SLA des Jobs. Beispielsweise sollte ein Frontend oder eine Aufgabe, die alle 15 Minuten eine Datenbank abfragt, mit exponentiellem Backoff bis zu 15 Minuten lang Wiederholungsversuche unternehmen und dann einen kontrollierten Fehler auslösen.
Konfigurieren Sie in Airflow aufgabenspezifische execution_timeout und globale DAG-SLAs; in Workflows legen Sie schrittspezifische Timeouts und Wiederholungsrichtlinien mit max_doublings und max_retry_duration fest. Für Cloud Run-Jobs legen Sie die Anzahl der Wiederholungsversuche und den Backoff fest.

Backfills, Catchup und Fehlerbehandlung

Aktivieren Sie Catchup für die Neuberechnung historischer Daten, wenn Aufgaben idempotent sind und Quellen nach Datum partitioniert sind. Bei nicht-deterministischen Ausgaben oder externen Nebeneffekten sollten Sie reine Backfill-DAGs oder Write-Audit-Tabellen in Betracht ziehen, um zu verfolgen, was produziert wurde.
Verwenden Sie Dead-Letter-Topics/Tabellen für Fehler auf Datensatzebene bei Streaming-/Batch-Transformationen. Für Batch-Dataflow erfassen Sie fehlerhafte Zeilen mit Fehler-Tags und aggregieren Sie Fehlermetriken; für Streaming verwenden Sie Pub/Sub-DLQs.

Idempotentes Aufgabendesign und Wiederholungen

BigQuery: Bevorzugen Sie MERGE oder INSERT mit Deduplizierungsschlüsseln; verwenden Sie insertId, um Streaming-Inserts zu deduplizieren. Für Batch schreiben Sie in eine Staging-Tabelle und führen dann innerhalb eines transaktionssicheren Schritts einen MERGE in das Ziel durch, um vollständige Wiederholungen zu ermöglichen.
Cloud Storage: Verwenden Sie Generations-Vorbedingungen und deterministische Objektnamen (z. B. Präfix/Datum/Hash), damit Wiederholungen nur dann sicher überschreiben, wenn dies erwartet wird.
Pub/Sub und Dataflow: Für eine „at-least-once“-Zustellung (mindestens einmalige Zustellung) konzipieren. Fügen Sie Nachrichten-Identifikatoren (z. B. Paket-ID, logischer Ereigniszeitstempel) hinzu, damit nachgelagerte Systeme deduplizieren und Verspätungen analysieren können. Wenn die Geschäftsregeln eine „first processed event wins“-Semantik (das zuerst verarbeitete Ereignis gewinnt) akzeptieren, dokumentieren Sie diesen Kompromiss und überwachen Sie auf Abweichungen (Skew); andernfalls ermitteln Sie die Gewinner nach Ereigniszeit mit Tie-Breakern.
Wiederherstellung nach Teilfehlern: Partitionieren Sie Ausgaben nach run_id oder Datum, schreiben Sie Abschlussmarkierungen (Completion Markers) und machen Sie nachgelagerte Aufgaben von diesen Markierungen abhängig. Verarbeiten Sie nur Partitionen neu, die als unvollständig markiert sind.

Fehlerbehebung und Skalierbarkeit

Wenn in einem Streaming-Dashboard Ereignisse fehlen, diese aber in Pub/Sub vorhanden sind, führen Sie einen bekannten, festen Datensatz durch die Dataflow-Pipeline, um Transformationsfehler zu isolieren. Validieren Sie Windowing, Trigger und die zulässige Verspätung (allowed lateness).
Häufiger Fehlermodus: Das Erstellen einer Streaming-Pipeline ohne geeignetes Windowing/Trigger für unbegrenzte Quellen (unbounded sources) oder die falsche Verwendung eines Sharded Window kann zum Scheitern der Pipeline-Erstellung oder zu einer Explosion des Zustands (State Blowups) führen.
Skalieren Sie Dataflow über die maximale Anzahl an Workern und den Autoscaling-Algorithmus; bei Lastspitzen (z. B. 50.000 Installationen) erhöhen Sie die maximale Worker-Anzahl, um während der Spitzen eine horizontale Skalierung zu ermöglichen.

Sicherheit, Parametrisierung, Umgebungen und CI/CD

Parametrisierung und Konfigurationsmanagement

Externalisieren Sie die Konfiguration nach Umgebung. Verwenden Sie in Composer Variables, Connections und Umgebungsvariablen; erstellen Sie Vorlagen für DAG-Parameter nach Ausführungsdatum oder Partition. Verwenden Sie in Workflows Laufzeitargumente und separate Workflows pro Umgebung oder lesen Sie die Konfiguration aus dem Secret Manager.
Nutzen Sie metadatengesteuerte Orchestrierung, indem Sie eine Steuerungstabelle (z. B. ein BigQuery-Konfigurations-Dataset) lesen, die Clients, Quellen oder Partitionen auflistet. Generieren Sie Aufgaben dynamisch, sodass Codeänderungen von datengesteuerten Änderungen entkoppelt sind.

Secrets, Service Accounts und Least Privilege (Prinzip der geringsten Rechte)

Speichern Sie Anmeldeinformationen im Secret Manager und referenzieren Sie diese zur Laufzeit. Vermeiden Sie es, Secrets in Code oder Airflow Variables einzubetten.
Weisen Sie jeder Pipeline einen eigenen Service Account mit den minimal erforderlichen IAM-Rollen zu. Für regulierten BigQuery-Zugriff isolieren Sie Kundendaten in separaten Datasets, gewähren Sie Dataset-spezifische Rollen nur genehmigten Benutzern und beschränken Sie den Zugriff auf die BigQuery API auf genehmigte Principals. Für Mandantenfähigkeit (Multitenancy) erstellen Sie pro Mandant ein Dataset und binden nur die entsprechenden Rollen.

CI/CD und Infrastructure as Code

Verwalten Sie die Infrastruktur (Composer-Umgebungen, Workflows, Scheduler-Jobs, Pub/Sub-Topics, Log-Senken) mit Terraform. Verwenden Sie Module zur Standardisierung von Projekten/Umgebungen, Secrets und Service Accounts.
Erstellen und testen Sie Pipeline-Code mit Cloud Build oder GitHub Actions. Automatisieren Sie Unit-Tests, SQL-Linting, Dataform-Dry-Runs und die Validierung von Airflow-DAGs. Promoten Sie Artefakte über Tags; für Composer packen Sie DAGs als bereitstellbare Bundles; für Dataform verwenden Sie Release-Branches, die nach erfolgreichen Assertions promotet werden.
Deployment-Promotion: dev → test → prod über separate Projekte und parametrisierte Konfigurationen. Nutzen Sie Continuous Delivery mit manuellen Genehmigungs-Gates und Änderungsfenstern für Promotions mit hohem Risiko.

Observability, Benachrichtigungen und Runbooks

Telemetrie und Benachrichtigungen

Leiten Sie alle Orchestrierungs-Logs mit strukturierten Feldern (pipeline, dag_id, run_id, task_id, partition) an Cloud Logging weiter. Exportieren Sie Fehler-Logs über logbasierte Messwerte an Monitoring. Benachrichtigungen für:
- Verpasste Zeitpläne oder SLA-Verletzungen
- Aufeinanderfolgende Task-Fehler
- Wachstum des Backlogs (z. B. nicht bestätigte Pub/Sub-Nachrichten, Dataflow-Systemverzögerung)
- Fehler bei Zusicherungen zur Datenqualität
Cloud Composer: Überwachen Sie die Dauer von DAGs/Tasks, die Erfolgsrate, die Warteschlangentiefe und den Zustand des Schedulers. Konfigurieren Sie on_failure_callback für Paging und Runbooks zur Fehlerbehebung.
Cloud Workflows: Überprüfen Sie Ausführungs-Logs und Schrittlatenzen; fügen Sie explizite Wiederholungsversuche und Fehler-Handler hinzu; geben Sie benutzerdefinierte Logs mit Korrelations-IDs aus.
Benachrichtigungen über Tabellenänderungen in BigQuery: Erstellen Sie eine Logging-Senke auf Projektebene mit einem erweiterten Filter für Einfüge-Jobs, die auf eine bestimmte Tabelle abzielen, und exportieren Sie diese nach Pub/Sub; Ihr Überwachungstool abonniert das Topic für sofortige Benachrichtigungen ohne Störungen durch andere Tabellen.

Runbook-Design

Dokumentieren Sie für jede Pipeline Auslöser, Abhängigkeiten, SLAs, Rollback-/Wiederholungsverfahren und sichere Schritte zum Backfilling. Fügen Sie „Fixed-Dataset-Replay“ für Dataflow hinzu, wie ein Streaming-Job geleert wird, wie fehlgeschlagene Partitionen erneut verarbeitet werden und wie DLQ-Nachrichten behoben werden.
Erfassen Sie gängige Fehlersignaturen (z. B. permission denied, quota exceeded, schema mismatch) mit Entscheidungsbäumen und Eskalationspfaden.

Praktisches Problemszenario

Acme Retail Analytics muss tägliche CSV-Lieferungen von Partnern verarbeiten, die gelegentlich fehlerhafte Zeilen enthalten, die validen Daten transformieren und in BigQuery laden und die fehlerhaften Zeilen zur Untersuchung aufzeigen. Zudem wünschen sie eine ereignisgesteuerte Anreicherung für Preisaktualisierungen in Nahezu-Echtzeit und eine sichere Überführung von der Entwicklungs- in die Produktionsumgebung.

Vorgehensweise:

Speicher und Ereignis-Trigger
- Erstellen Sie einen dedizierten Cloud Storage-Bucket mit Objektversionierung und einheitlichem Zugriff auf Bucket-Ebene. Aktivieren Sie Benachrichtigungen über den Abschluss von Objekten (object finalize) an Pub/Sub über Eventarc.
- Begründung: Der Abschluss eines Objekts ist ein zuverlässiges Ereignis, um die nachgelagerte Verarbeitung auszulösen; die Versionierung unterstützt Wiederholungen und Audits.
Batch-Verarbeitung mit Dead-Letter-Handling
- Verwenden Sie Cloud Composer, um täglich um 02:00 Uhr einen Airflow-DAG mit aktiviertem Catchup zu planen. Der DAG startet einen Dataflow-Batch-Job, der CSVs parst, das Schema validiert und valide Datensätze in BigQuery schreibt, indem er deterministische Staging-Tabellen verwendet und dann mittels MERGE in partitionierte Zieltabellen zusammenführt. Leiten Sie fehlerhafte/fehlgeschlagene Datensätze in eine BigQuery Dead-Letter-Tabelle weiter.
- Begründung: Dataflow skaliert das Parsen/Validieren; MERGE stellt Idempotenz sicher; die Erfassung in einer Dead-Letter-Tabelle ermöglicht die Untersuchung, ohne die Pipeline zu blockieren, was dem empfohlenen Muster für fehlerhafte Zeilen entspricht.
Ereignisgesteuerte Anreicherung
- Stellen Sie einen Cloud Run-Job bereit, der eine leichtgewichtige Anreicherung für inkrementelle Preisaktualisierungen durchführt. Lösen Sie ihn über Cloud Workflows aus, die auf Pub/Sub-Nachrichten von Eventarc lauschen, wenn tagsüber kleine Aktualisierungsdateien eintreffen.
- Begründung: Serverless-Container mit Workflows bieten eine latenzarme Orchestrierung mit geringem Betriebsaufwand für kleine Ereignisse, während aufwendige Transformationen im Batch-Modus verbleiben.
Zuverlässigkeitskontrollen
- Konfigurieren Sie Wiederholungsversuche mit exponentiellem Backoff für transiente Fehler in Dataflow- und Cloud Run-Jobs und begrenzen Sie die gesamte Wiederholungszeit auf das DAG-SLA. Legen Sie in Airflow Ausführungs-Timeouts pro Task und on_failure-Callbacks fest; in Workflows setzen Sie max_doublings und max_retry_duration.
- Begründung: Begrenzter Backoff schont SLAs und verhindert ausufernde Wiederholungsversuche.
Sicherheit und Prinzip der geringsten Rechte
- Führen Sie jede Komponente unter einem dedizierten Servicekonto aus: Composer Orchestrator SA, Dataflow Worker SA, Cloud Run Job SA. Vergeben Sie nur die erforderlichen Rollen: GCS-Lesezugriff auf den Ingest-Bucket für Dataflow, BigQuery dataEditor für die Zieldatensätze und Viewer für die Logs. Speichern Sie Secrets im Secret Manager und referenzieren Sie sie zur Laufzeit.
- Begründung: Setzt das Prinzip der geringsten Rechte durch und isoliert den „Blast Radius“ (Schadensradius).
Metadatengesteuerte Orchestrierung
- Führen Sie eine BigQuery-Kontrolltabelle, die Partnerquellen, Dateimuster und Zieldatensätze auflistet. Zur Laufzeit des DAGs fragt Airflow diese Tabelle ab und verwendet dynamisches Task-Mapping, um für jeden Partner eigene Tasks zu erzeugen.
- Begründung: Das Hinzufügen eines Partners wird zu einer Datenänderung, nicht zu einer Code-Änderung, was das Bereitstellungsrisiko verringert.
Observability und Benachrichtigungen
- Geben Sie strukturierte Logs mit run_id und partner_id aus. Erstellen Sie Benachrichtigungsrichtlinien für SLA-Verletzungen von DAGs, Dataflow-Systemverzögerungen und nicht leere Dead-Letter-Zähler. Konfigurieren Sie für BigQuery-Inserts in die Zieltabelle eine Cloud Logging-Senke mit einem erweiterten Filter für diese Tabelle, die an ein Pub/Sub-Topic sendet, das vom Überwachungstool von Acme konsumiert wird.
- Begründung: Feingranulare Benachrichtigungen ermöglichen eine schnelle Triage ohne Störsignale.
CI/CD und Promotion
- Verwalten Sie die Infrastruktur (Buckets, Pub/Sub, Eventarc, Composer, Workflows, BigQuery-Datasets) in Terraform. Verwenden Sie Cloud Build, um die Syntax von Airflow-DAGs zu validieren, Unit-Tests auszuführen und in einer dev-Composer-Umgebung bereitzustellen. Führen Sie die Promotion in die Test- und Prod-Umgebung mit parametrisierten Konfigurationen und manuellen Genehmigungs-Gates durch, nachdem Dataform-Assertions und Integrationstests erfolgreich waren.
- Begründung: Deklarative, wiederholbare Deployments und sichere Promotion über Umgebungen hinweg.
Runbook und Wiederherstellung
- Dokumentieren Sie die Schritte zur Wiederholung eines bestimmten Datums: Wiederherstellen der CSV-Datei aus der Objektversionierung, erneutes Ausführen des Dataflow-Jobs für diese Partition, MERGE der Ergebnisse und Überprüfen der DLQ-Datensätze. Fügen Sie ein „Fixed-Dataset-Replay“-Verfahren hinzu, um Transformationsfehler zu isolieren, falls Diskrepanzen auftreten.
- Begründung: Idempotentes Design und dokumentierte Wiederherstellung vereinfachen die Behebung von Teilfehlern.