Google PDE: Messaging, Event-Ingestion und Echtzeitdienste — 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.

Ereignisgesteuerte Integration, Eventarc und Kafka-Interoperabilität

• Eventarc und CloudEvents
  • Eventarc leitet Ereignisse von Google Cloud-Diensten (und benutzerdefinierten Quellen über Pub/Sub) an Cloud Run, GKE oder Workflows weiter und verwendet dabei die CloudEvents-Spezifikation. Attribute wie Typ, Quelle und Betreff ermöglichen eine feingranulare Filterung und Prüfbarkeit.
  • Verwenden Sie Attributfilter, um den Fan-Out zu minimieren und die nachgelagerte Last (Downstream Load) zu reduzieren.
  • Die Zustellung erfolgt nach dem At-least-once-Prinzip; Handler sollten nach Möglichkeit idempotent und zustandslos (stateless) gestaltet werden.
• Beispiel für einen Eventarc-Trigger: gcloud eventarc triggers create gcs-finalize-to-run
  –destination-run-service=ingestor
  –event-filters=“type=google.cloud.storage.object.v1.finalized”
  –event-filters=“bucket=my-data-bucket”
  –service-account=eventarc-sa@PROJECT_ID.iam.gserviceaccount.com
• Kafka-Interoperabilität und verwaltete Migration
  • Dataflow-Vorlagen verbinden Kafka <-> Pub/Sub für eine schrittweise Migration. Spiegeln Sie Topics mit beibehaltenen Schlüsseln; stellen Sie zuerst die Consumer um, dann die Producer, oder nutzen Sie Dual-Write während des Übergangs.
  • Pub/Sub Lite bietet partitioniertes, kapazitätsbasiertes Streaming mit schlüsselbasiertem Routing und geringeren Kosten; es ist regional/zonal und eignet sich für Kafka-ähnliche Workloads, bei denen vorhersagbare Kapazität und die Reihenfolge pro Partition im Vordergrund stehen.
  • Überlegungen zur Migration:
    • Reihenfolge (Ordering): Ordnen Sie Kafka-Schlüssel den Pub/Sub-Ordnungsschlüsseln (Ordering Keys) oder Lite-Partitionen zu.
    • Offsets: Führen Sie Offsets als Nachrichtenattribute für Diagnosezwecke mit; Consumer können sich nach der Migration nicht auf Kafka-Offsets verlassen.
    • Zustellung (Delivery): Akzeptieren Sie das At-least-once-Prinzip; erzwingen Sie Idempotenz auf der nachgelagerten Seite (downstream).
    • Schemata: Migrieren Sie Definitionen aus der Confluent Schema Registry zu Pub/Sub-Schemata oder standardisieren Sie auf Protobuf/Avro mit kompatiblen Evolutionsregeln.

Muster für Streaming-Ingestion, Durchsatz, Skalierung, Sicherheit und Betrieb

• Echtzeit-Ingestion-Muster
  • Pub/Sub -> Dataflow -> BigQuery: Verwenden Sie den BigQuery Storage Write API-Sink für hohen Durchsatz und Idempotenz mit Stream-Offsets; leiten Sie Fehler zur Überprüfung in eine Dead-Letter-Tabelle um.
  • Pub/Sub -> Dataflow -> Cloud Storage: Archivieren Sie Roh-Events zur Wiederverarbeitung; verwenden Sie gefensterte, komprimierte Schreibvorgänge, um Kosten und Latenz auszugleichen.
  • Pub/Sub -> operationale Speicher: Schreiben Sie in Bigtable für Abfragen mit geringer Latenz, in Spanner für stark konsistente Transaktionen oder in Cloud SQL/Firestore je nach Workload-Anforderungen. Stellen Sie idempotente Upserts sicher, die durch eine eindeutige Event-ID geschlüsselt sind.
• Mindestens einmalige Zustellung (At-least-once), Duplikatvermeidung und Idempotenz
  • Führen Sie eine eindeutige event_id und event_time in jeder Nachricht mit; erzwingen Sie produzentenseitige UUIDs.
  • BigQuery-Streaming-Deduplizierung: Setzen Sie die insertId oder verwenden Sie die Storage Write API mit geordneten Streams; sichern Sie Abfragen dennoch mit Deduplizierungslogik ab.
  • Beispiel für Deduplizierung zur Abfragezeit: WITH ranked AS ( SELECT t.*, ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time DESC) AS rn FROM dataset.events t ) SELECT * EXCEPT(rn) FROM ranked WHERE rn = 1;
  • Geben Sie bei Push-Endpunkten nur nach erfolgreicher Verarbeitung 2xx zurück; andernfalls ist mit einer erneuten Zustellung zu rechnen.
• Nachrichtendurchsatz, Kontingente und Skalierung
  • Publisher: Fassen Sie Nachrichten in Batches zusammen und verwenden Sie Verbindungen wieder; parallelisieren Sie über mehrere Clients. Verwenden Sie viele Ordering-Keys, um geordnete Workloads zu skalieren.
  • Abonnenten: Bevorzugen Sie Streaming-Pull mit Flusskontrolle (max outstanding bytes/messages). Dimensionieren Sie Ack-Deadlines entsprechend der Verarbeitungszeit und verlängern Sie sie bei Bedarf.
  • Überwachen Sie den Publish- und Subscribe-Durchsatz und beantragen Sie bei wachsendem Volumen Kontingenterhöhungen; planen Sie Puffer ein (z. B. das Zweifache des erwarteten Spitzenwerts), um Lastspitzen abzufangen.
• Konsistenz und Verfügbarkeit
  • BigQuery-Streaming ist für die Sichtbarkeit von Abfragen eventuell konsistent; warten Sie bei interaktiven Abfragen, die gestreamte Zeilen enthalten müssen, basierend auf der beobachteten Latenz (z. B. das Zweifache der P50-Verfügbarkeitsverzögerung) oder entwerfen Sie ein Design mit an Wasserzeichen ausgerichteten Aggregationen in Dataflow und fragen Sie materialisierte Ergebnisse ab.
• Sicherheit
  • IAM: Vergeben Sie Rollen mit den geringsten Rechten (pubsub.publisher an Producer für das Topic; pubsub.subscriber an Consumer für die Subscription). Verwenden Sie dedizierte Service Accounts für jeden Workload.
  • Push-Authentifizierung: Konfigurieren Sie Push-Subscriptions so, dass OIDC-Tokens von einem Service Account angehängt werden; erzwingen Sie die Validierung der Audience am Endpunkt. Bevorzugen Sie private Cloud Run-Endpunkte für integrierte Authentifizierung und TLS.
  • Verschlüsselung: Pub/Sub verschlüsselt Daten während der Übertragung und im Ruhezustand; verwenden Sie CMEK für Topics für vom Kunden verwaltete Schlüssel. Wenden Sie VPC Service Controls an, um das Risiko der Datenexfiltration zu verringern. Verwenden Sie bei Bedarf clientseitige Verschlüsselung für sensible Payload-Felder.
• Betriebsdiagnose von Verzögerungen, erneuten Zustellungen und Abonnentenfehlern
  • Überwachung mit Cloud Monitoring:
    • subscription/num_undelivered_messages und oldest_unacked_message_age für den Rückstand.
    • expired_ack_deadline_count, um verpasste Acks zu erkennen, die Duplikate verursachen.
    • publish_request_count und pull_request_count für den Durchsatz.
  • Untersuchen Sie fehlende Dashboard-Events, indem Sie einen bekannten Datensatz erneut durch die Pipeline leiten und die Ergebnisse der einzelnen Stufen vergleichen, um die fehlerhafte Transformation oder den fehlerhaften Sink zu isolieren.
  • Für Dataflow-Streaming:
    • Verwenden Sie Autoscaling mit einem angemessenen maxWorkers-Wert, um die Last von vielen Quellen abzufangen.
    • Führen Sie bei inkompatiblen Updates ein „Drain“ der Pipelines durch, damit laufende Arbeiten abgeschlossen werden können und Datenverlust vermieden wird.
  • Für BigQuery-Insert-Benachrichtigungen leiten Sie Cloud Logging-Audit-Einträge über einen Sink, der auf bestimmte Tabellen gefiltert ist, zur Alarmierung an ein Pub/Sub-Topic weiter.

Praktisches Problemszenario

Contoso Freight benötigt eine globale Echtzeit-Eventing-Plattform, um 10.000 IoT-Telemetrienachrichten pro Minute von LKWs zu erfassen, Events anzureichern, interaktive Analysen zu ermöglichen und Workflows bei Datei-Uploads von externen Partnern auszulösen. Einige CSVs von Partnern enthalten fehlerhafte Zeilen, und das Analyseteam muss Fehler untersuchen können, ohne den Stream zu blockieren.

1. Erstellen der Kernschicht für Messaging und Schema

• Aktion: Definieren Sie ein Avro-Schema für Telemetriedaten und hängen Sie es an ein Pub/Sub-Topic telemetry an, wobei die Schema-Erzwingung auf require gesetzt ist. Aktivieren Sie die Nachrichtenreihenfolge und veröffentlichen Sie mit ordering_key = hash(device_id).
• Begründung: Die Schema-Erzwingung auf Topic-Ebene weist fehlerhafte Events frühzeitig zurück. Die gerätebezogene Reihenfolge unterstützt bei Bedarf eine geordnete Verarbeitung, während das Hashing der Schlüssel den Durchsatz aufrechterhält.

2. Bereitstellen von Subscriptions mit Isolation und Dead-Lettering

• Aktion: Erstellen Sie eine Pull-Subscription telemetry-stream-sub für Dataflow mit einem Dead-Letter-Topic telemetry-dlt und max_delivery_attempts=10. Fügen Sie eine BigQuery-Subscription telemetry-raw-bq hinzu, um Roh-Events in einer zeitpartitionierten Tabelle für Herkunft (Lineage) und Wiederholung (Replay) zu speichern.
• Begründung: Die DLQ isoliert „Poison Messages“ zur Untersuchung. Eine separate BigQuery-Subscription bietet einen wartungsarmen Exportpfad zur Aufbewahrung von Roh-Events, unabhängig von der Verarbeitungspipeline.

3. Erstellen einer Dataflow-Streaming-Pipeline für Anreicherung und Sinks

• Aktion: Ingestieren Sie Daten von telemetry-stream-sub mittels Streaming-Pull mit Flusskontrolle. Validieren Sie gegen das Schema, reichern Sie die Daten mit Referenzdaten an und berechnen Sie gefensterte Aggregate. Schreiben Sie in BigQuery unter Verwendung der Storage Write API mit einem benannten Stream und insertId = event_id; schreiben Sie stündlich Roh-Backups in Cloud Storage; leiten Sie fehlerhafte/fehlgeschlagene Datensätze in eine Dead-Letter-Tabelle in BigQuery um.
• Begründung: Die Storage Write API ermöglicht Schreibvorgänge mit hohem Durchsatz und geringer Latenz mit Idempotenz über insertId/Stream-Offsets. Eine Dead-Letter-Tabelle unterstützt die Überprüfung, ohne den Stream zu blockieren, und Cloud Storage-Archive ermöglichen die Wiederholung.

4. Handhabung von Duplikaten und eventueller Konsistenz in der Analytik

• Aktion: Für interaktive Abfragen, die Duplikate ausschließen müssen, veröffentlichen Sie event_id und event_time in jedem Datensatz und verwenden Sie eine Deduplizierungs-View: CREATE OR REPLACE VIEW analytics.latest_events AS SELECT * EXCEPT(rn) FROM ( SELECT e.*, ROW_NUMBER() OVER (PARTITION BY event_id ORDER BY event_time DESC) rn FROM analytics.events e ) WHERE rn = 1; Führen Sie eine kurze Abfrageverzögerung ein, die auf der beobachteten BigQuery-Streaming-Verfügbarkeit basiert (z. B. das Zweifache der medianen Latenz).
• Begründung: Die „At-least-once“-Zustellung erfordert idempotente Schreibvorgänge und eine Deduplizierung zur Abfragezeit. Eine Wartezeit reduziert das Übersehen von „in-flight“-Zeilen aufgrund der Latenz bei der Sichtbarkeit von Streaming-Daten.

5. Integration von Partner-Dateien (File Drops) mit Eventarc

• Aktion: Konfigurieren Sie Eventarc so, dass Cloud Storage object.finalized-Events für den Bucket partner-drops an einen Cloud Run-Service weitergeleitet werden. Dieser startet einen Batch-Dataflow-Job, um CSVs in BigQuery zu laden, und sendet Parsing-Fehler an eine Dead-Letter-Tabelle.
• Begründung: Eventarc ermöglicht eine ereignisgesteuerte Orchestrierung mit CloudEvents-Filterung nach Bucket und Objektpräfix. Ein Batch-Dataflow-Job trennt fehlerhafte Zeilen zur Analyse, während die korrekten Daten zeitnah geladen werden.

6. Absicherung der Plattform

• Aktion: Verwenden Sie unterschiedliche Service Accounts: Producer erhalten pubsub.publisher für das Topic telemetry; der Dataflow Worker SA erhält pubsub.subscriber für die Subscription telemetry-stream-sub sowie Schreibzugriff auf die Ziel-Datasets in BigQuery und Cloud Storage; der Eventarc-Trigger verwendet einen dedizierten SA mit Invoker-Rechten für Cloud Run. Aktivieren Sie CMEK für das telemetry-Topic und die BigQuery-Datasets. Konfigurieren Sie eventuelle Push-Endpunkte mit OIDC und Audience-Prüfungen.
• Begründung: IAM nach dem Prinzip der geringsten Rechte (Least Privilege) und CMEK erfüllen Sicherheits- und Compliance-Anforderungen; eine authentifizierte Zustellung verhindert Spoofing.

7. Zuverlässiger Betrieb und Skalierung

• Aktion: Richten Sie Dataflow-Autoscaling mit einem großzügigen maxWorkers-Wert ein, um Spitzenlasten abzufangen. Überwachen Sie subscription/oldest_unacked_message_age und expired_ack_deadline_count; lösen Sie Alarme aus, wenn Schwellenwerte überschritten werden. Führen Sie bei Pipeline-Änderungen, die die Kompatibilität beeinträchtigen, ein Deployment mit „Drain“ durch, um Nachrichtenverlust zu vermeiden. Wenn der Lag zunimmt, erhöhen Sie die Parallelität der Abonnenten und verlängern Sie die Ack-Deadlines proportional zur Verarbeitungszeit.
• Begründung: Proaktives Monitoring erkennt Verzögerungen (Lag) und erneute Zustellungen frühzeitig. Autoscaling und angepasste Ack-Deadlines verhindern „Duplicate Storms“. Das „Draining“ sichert „in-flight“-Nachrichten während Upgrades.

Dieses Design bietet eine resiliente, sichere und beobachtbare Echtzeit-Ingestion mit ereignisgesteuerter Batch-Integration, unterstützt Duplikat-Toleranz und Schema-Evolution und ermöglicht schnelle Analysen, während fehlerhafte Daten zur gezielten Behebung isoliert werden.

← Stream-Verarbeitung mit Dataflow und Apache Beam · Alle Domänen · Spark →

Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →

Google durchsuchen →