Handbuch

Kontinuierliche, hochvolumige Daten erfordern eine Analyse innerhalb weniger Minuten nach dem Eintreffen.

→Pub/Sub für die Aufnahme -> Dataflow (Streaming) für die Transformation -> BigQuery mit Streaming-Einfügungen oder Storage Write API für die Analyse.

Warum: Dies ist das kanonische serverlose, automatisch skalierende Streaming-Muster. Die Batch-Verarbeitung (z. B. Dataproc) würde die Anforderungen an geringe Latenz nicht erfüllen.

Eine Datenpipeline muss unvorhersehbare Verkehrsspitzen (z. B. 10x saisonales Volumen) bewältigen und dabei eine geringe Latenz beibehalten.

→Verwenden Sie vollständig verwaltete, automatisch skalierende Dienste: Pub/Sub für die Aufnahme, Dataflow mit aktivierter Autoskalierung und BigQuery für die Speicherung.

Warum: Verwaltete Dienste skalieren Ressourcen automatisch an die Last an, wodurch Kosten für Überprovisionierung vermieden und die Leistung bei Spitzenverkehr sichergestellt wird.

Migrieren Sie ein großes lokales Hadoop/Hive Data Warehouse zu Google Cloud.

→Migrieren Sie Daten zu Cloud Storage und laden Sie sie dann in BigQuery. Ersetzen Sie Hive/Spark SQL durch BigQuery für serverlose Analysen. Verwenden Sie Dataproc für Spark-Jobs, die nicht einfach in SQL übersetzt werden können.

Warum: BigQuery bietet einen serverlosen, hochleistungsfähigen Ersatz für Hadoop Data Warehouses und reduziert den Betriebsaufwand.

Eine Streaming-Pipeline erfordert, dass Nachrichten genau einmal und in der richtigen Reihenfolge für jede Entität (z. B. pro Aktiensymbol) verarbeitet werden.

→Veröffentlichen Sie Nachrichten in Pub/Sub mit einem Ordnungsschlüssel. Verarbeiten Sie sie mit einer Dataflow-Streaming-Pipeline, die eine geordnete Verarbeitung für einen bestimmten Schlüssel garantiert.

Warum: Pub/Sub-Ordnungsschlüssel in Kombination mit Dataflow bieten eine verwaltete, skalierbare, geordnete und genau einmalige Verarbeitung ohne manuelle Zustandsverwaltung.

Referenz↗

Erstellen Sie einen flexiblen, skalierbaren Data Lake, der sowohl Batch- als auch Streaming-Workloads mit Data Governance unterstützt.

→Verwenden Sie Cloud Storage als Speicherschicht. Verwenden Sie Dataflow sowohl für die Batch- als auch für die Stream-Verarbeitung. Verwenden Sie Dataplex mit Data Catalog für Metadatenmanagement, Erkennung und Governance.

Warum: Diese Architektur entkoppelt Speicher und Compute und ermöglicht die Verwendung mehrerer Verarbeitungs-Engines (Dataflow, Dataproc) auf einem zentralen Datenspeicher mit vereinheitlichter Governance.

Eine Pipeline, die sensible Daten (z. B. PHI, PII) verarbeitet, muss Vorschriften wie HIPAA oder GDPR einhalten.

→Aktivieren Sie Cloud Audit Logs für alle Datenzugriffe. Implementieren Sie VPC Service Controls, um einen Sicherheitsperimeter zu schaffen, der die Datenexfiltration verhindert.

Warum: Audit-Logging ist entscheidend für die Nachverfolgung des Datenzugriffs zur Einhaltung von Vorschriften. VPC Service Controls bieten eine starke Verteidigung gegen Datenexfiltration, eine zentrale Anforderung für sensible Daten.

Eine Lambda-Architektur mit separaten Batch- und Geschwindigkeitsschichten muss eine einheitliche Ansicht der Daten präsentieren.

→Verwenden Sie BigQuery für die Serving-Schicht. Verwenden Sie eine `MERGE`-Anweisung, um Batch-verarbeitete Daten in eine Master-Tabelle zu aktualisieren/einzufügen, wobei Streaming-Daten für den gleichen Zeitraum überschrieben werden. Stellen Sie eine View bereit, die historische Batch-Daten mit Echtzeit-Streaming-Daten für den aktuellen Zeitraum mittels `UNION` verbindet.

Warum: Dieses Muster bietet sowohl Echtzeitansichten mit geringer Latenz als auch batch-korrigierte historische Genauigkeit, ohne dass eine clientseitige Abstimmungslogik erforderlich ist.

Implementieren Sie eine dezentrale Data-Mesh-Architektur, bei der Domänen ihre Datenprodukte besitzen.

→Verwenden Sie Dataplex für eine föderierte Governance über domänenspezifische "Lakes" und "Zones". Verwenden Sie BigQuery-Datasets pro Domäne. Verwenden Sie Analytics Hub, um Datenprodukte zwischen Domänen zu teilen.

Warum: Dataplex bietet die zentrale Governance-Ebene und ermöglicht gleichzeitig Domänenautonomie, ein Kernprinzip des Data Mesh.

Kombinieren Sie einen Data Lake und ein Data Warehouse, um Spark-Jobs auf Rohdaten und schnelles SQL auf kuratierten Daten zu ermöglichen.

→Speichern Sie Daten in offenen Formaten (Iceberg, Delta Lake) in Cloud Storage. Verwenden Sie BigLake, um eine vereinheitlichte Governance- und Zugriffsebene bereitzustellen. Fragen Sie Daten sowohl von Dataproc (Spark) als auch von BigQuery ab.

Warum: BigLake ermöglicht die Abfrage von Daten direkt in Cloud Storage mit BigQuery-Leistung und fein abgestimmter Sicherheit, wodurch Lake und Warehouse vereint werden.

Entwerfen Sie eine Disaster-Recovery-Strategie für ein kritisches BigQuery Data Warehouse mit einem niedrigen RPO (z. B. 1 Stunde).

→Konfigurieren Sie die BigQuery-regionsübergreifende Dataset-Replikation für kritische Datasets. Verwenden Sie Terraform oder Dataform, um Schema- und View-Definitionen zu verwalten. Orchestrieren Sie das Failover mit Cloud Functions, die durch Cloud Monitoring-Alarme ausgelöst werden.

Warum: Die regionsübergreifende Replikation bietet eine kontinuierlich aktualisierte, abfragbare Kopie in einer DR-Region und erfüllt die Anforderungen an niedrige RPO/RTO für kritische Daten.

Replizieren Sie kontinuierlich Änderungen von einer OLTP-Datenbank (z. B. Oracle, PostgreSQL, MySQL) mit geringer Latenz nach BigQuery.

→Verwenden Sie Datastream, um Change Data Capture (CDC) durchzuführen. Konfigurieren Sie es so, dass Änderungen direkt an BigQuery gestreamt werden, das diese mithilfe seiner `MERGE`-Funktionalität anwendet.

Warum: Datastream ist ein verwalteter, serverloser CDC-Dienst, der die Datenbankreplikation in Echtzeit vereinfacht, ohne dass benutzerdefinierte Pipelines oder eine erhebliche Last der Quelldatenbank erforderlich sind.

Referenz↗

Eine Dataflow-Streaming-Pipeline muss trotz einiger Stunden verspätet eintreffender Ereignisse genaue ereigniszeitgesteuerte Fensterergebnisse liefern.

→Konfigurieren Sie Ereigniszeitfenster mit `allowedLateness`, um die Verzögerung zu berücksichtigen. Verwenden Sie Trigger mit frühen Auslösungen für vorläufige Ergebnisse und akkumulierende ausgelöste Bereiche, um verspätete Daten einzubeziehen.

Warum: Das Dataflow-Modell aus Watermarks, Triggern und erlaubter Verspätung bietet ein robustes Framework, um Vollständigkeit und Latenz beim Umgang mit unsortierten Daten in Einklang zu bringen.

Eine Dataflow-Pipeline, die nach BigQuery schreibt, erlebt Duplikate nach Neustarts oder vorübergehenden Fehlern.

→Verwenden Sie den BigQuery Storage Write API Sink (`STORAGE_WRITE_API`) mit der Methode `at-least-once` (Standard, früher `STREAMING_INSERTS`) oder `exactly-once` (`COMMITTED`-Modus).

Warum: Die Storage Write API im `COMMITTED`-Modus bietet integrierte Exactly-Once-Semantik für das Streaming, wodurch die Notwendigkeit einer benutzerdefinierten Deduplizierungslogik entfällt.

Nehmen Sie Daten von einer paginierten, ratenbegrenzten REST-API mit Dataflow auf.

→Verwenden Sie eine `SplittableDoFn`, um die paginierte Quelle parallel zu verarbeiten. Implementieren Sie Ratenbegrenzungslogik (z. B. mithilfe eines Guava RateLimiters) und exponentielles Backoff für Wiederholungen innerhalb der DoFn.

Warum: Eine `SplittableDoFn` ermöglicht ein dynamisches Neuausbalancieren der Arbeit. Die Kombination mit Ratenbegrenzungs- und Wiederholungslogik schafft ein robustes und effizientes Muster für die Handhabung externer APIs.

Ein einzelner Datenstrom muss in mehrere Ziele geschrieben werden (z. B. BigQuery, Bigtable, Cloud Storage).

→Wenden Sie in einer einzigen Dataflow-Pipeline nach der anfänglichen Verarbeitung mehrere `PTransform`-Writer auf dieselbe endgültige `PCollection` an.

Warum: Das Fan-Out-Muster ist hocheffizient, da die Daten nur einmal verarbeitet werden. Es vermeidet die Kosten und Komplexität, die beim Ausführen mehrerer separater Pipelines, die aus derselben Quelle lesen, entstehen.

Ein Hochvolumen-Stream muss durch einen Join mit einer sich langsam ändernden Dimensionstabelle (z. B. Benutzerprofile) angereichert werden, die periodisch aktualisiert wird.

→Verwenden Sie das Side-Input-Muster in Dataflow. Laden Sie die Dimensionstabelle als `PCollectionView`. Konfigurieren Sie einen periodischen Trigger, um den Side-Input nach einem Zeitplan zu aktualisieren und Pipeline-Neustarts zu verhindern.

Warum: Side-Inputs senden die Dimensionsdaten an alle Worker für schnelle In-Memory-Lookups, wodurch API/DB-Aufrufe pro Element vermieden werden. Die periodische Aktualisierung verarbeitet Updates effizient.

Dataproc-Cluster-Workloads variieren erheblich, was entweder zu Überprovisionierung oder Unterperformance führt.

→Erstellen Sie einen Dataproc-Cluster mit einer Autoscaling-Richtlinie. Definieren Sie die minimale/maximale Anzahl primärer und sekundärer Worker. Die Richtlinie skaliert den Cluster basierend auf YARN-Metriken.

Warum: Autoscaling optimiert Kosten, indem es Cluster-Ressourcen an die Job-Nachfrage anpasst, bei hohen Lasten hochskaliert und in Leerlaufzeiten herunterskaliert.

Eine Dataflow-Pipeline erfordert benutzerdefinierte Binärdateien, proprietäre Bibliotheken oder spezifische Versionen, die nicht in Standard-Worker-Images enthalten sind, und muss in einer VPC ohne Internetzugang ausgeführt werden.

→Erstellen Sie ein benutzerdefiniertes Container-Image mit allen vorinstallierten Abhängigkeiten. Pushen Sie das Image in Artifact Registry. Stellen Sie die Pipeline mithilfe eines Flex-Templates bereit, das auf den benutzerdefinierten Container verweist.

Warum: Flex Templates mit benutzerdefinierten Containern bieten vollständige Kontrolle über die Laufzeitumgebung und Abhängigkeiten, was für Offline- oder spezialisierte Umgebungen entscheidend ist.

Ein Dataflow- oder Spark-Job, der eine `GroupByKey` durchführt, ist langsam, weil einige Schlüssel unverhältnismäßig viele Werte haben (ein "Hot Key").

→Implementieren Sie eine zweistufige Aggregation (Key Salting). Hängen Sie zuerst ein zufälliges Suffix an den Schlüssel an, um den Hot Key auf mehrere Worker aufzuteilen. Aggregieren Sie teilweise. Zweitens entfernen Sie das Suffix und aggregieren die Teilergebnisse.

Warum: Diese Fanout-Technik zerlegt die Arbeit für den Hot Key manuell, wodurch er parallel verarbeitet und der Engpass überwunden werden kann.

Eine Streaming-Pipeline darf nicht aufgrund fehlerhafter Datensätze fehlschlagen. Ungültige Datensätze müssen für die Analyse isoliert werden, ohne die Verarbeitung anzuhalten.

→Verwenden Sie in einer `DoFn` einen Try-Catch-Block für die Analyse. Verwenden Sie eine Multi-Output-DoFn mit `TupleTag`, um gültige Datensätze zum Hauptausgang und ungültige Datensätze (mit Fehlerkontext) zu einem separaten Fehlerausgang zu leiten. Leiten Sie die Fehler-PCollection an ein Dead-Letter-Ziel wie ein Pub/Sub-Thema oder eine BigQuery-Tabelle weiter.

Warum: Dieses Muster bietet Resilienz, indem es fehlerhafte Daten isoliert, Pipeline-Fehler verhindert und sicherstellt, dass fehlgeschlagene Datensätze zur Fehlerbehebung und erneuten Verarbeitung erfasst werden.

BigQuery-Abfragen sind langsam und teuer, typischerweise filtern sie nach einer Datums-/Uhrzeitspalte und anderen Spalten mit hoher Kardinalität (z. B. `customer_id`).

→Partitionieren Sie die Tabelle nach der Datums-/Uhrzeitspalte (z. B. tägliche Partitionen). Clustern Sie die Tabelle nach bis zu vier häufig gefilterten Spalten (z. B. `customer_id`, `product_category`).

Warum: Die Partitionierung reduziert die gescannten Daten auf nur relevante Zeiträume. Clustering sortiert Daten innerhalb von Partitionen weiter, wodurch die für Filter auf geclusterten Spalten gescannten Daten minimiert werden. Dies ist das primäre BQ-Leistungsoptimierungsmuster.

Referenz↗

Die Anwendung erfordert Lese- und Schreibvorgänge mit geringer Latenz (unter 10 ms) für massive Datensätze (Milliarden von Zeilen), z. B. für Echtzeit-Personalisierung oder einen IoT Feature Store.

→Verwenden Sie Bigtable. Entwerfen Sie einen Row Key, der das primäre Zugriffsmuster unterstützt. Für Zeitreihen verwenden Sie `entity_id#reverse_timestamp`.

Warum: Bigtable ist ein NoSQL Wide-Column Store, der für Workloads mit hohem Durchsatz und geringer Latenz im großen Maßstab optimiert ist. BigQuery ist für Analysen gedacht und hat eine höhere Point-Lookup-Latenz.

Eine transaktionale Anwendung erfordert globale Verteilung, horizontale Skalierbarkeit und starke Konsistenz mit einer SQL-Schnittstelle.

→Verwenden Sie Cloud Spanner mit einer Multi-Region-Konfiguration.

Warum: Spanner ist der einzige Dienst, der all diese Funktionen bietet: global verteilt, ACID-Transaktionen und ein relationales Schema. Cloud SQL ist regional; Bigtable ist nicht relational und hat eine eventuelle Konsistenz zwischen Clustern.

Ein BigQuery Data Warehouse enthält große Mengen historischer Daten, die selten abgefragt werden, aber aufbewahrt werden müssen, was zu hohen Speicherkosten führt.

→Für Partitionen/Tabellen, die 90 aufeinanderfolgende Tage lang unverändert bleiben, ist keine Aktion erforderlich. BigQuery wendet automatisch die Langzeitspeicherpreise an, was einer Kostenreduzierung von ca. 50 % entspricht.

Warum: Dies ist eine automatische, integrierte Optimierung. Das manuelle Verschieben von Daten nach GCS (außer für die Archivschicht) ist oft unnötig und erhöht die Komplexität.

Daten in einem Cloud Storage Bucket haben ein vorhersehbares Zugriffsmuster: häufig für 30 Tage, gelegentlich für 90 Tage, dann selten.

→Konfigurieren Sie eine Bucket-Lifecycle-Richtlinie, um Objekte zu übertragen: Standard -> Nearline (nach 30 Tagen) -> Coldline (nach 90 Tagen).

Warum: Lifecycle-Richtlinien automatisieren die Kostenoptimierung, indem sie Daten in günstigere Speicherklassen verschieben, sobald diese seltener aufgerufen werden.

Eine BigQuery-Tabelle muss eine Unique-Key-Constraint erzwingen.

→Erzwingen Sie die Eindeutigkeit in der Lade-Pipeline. Verwenden Sie eine `MERGE`-Anweisung mit einer Logik, die nur dann einfügt, wenn der Schlüssel noch nicht existiert. Alternativ verwenden Sie eine zustandsbehaftete DoFn in Dataflow zur Deduplizierung.

Warum: BigQuery erzwingt keine `PRIMARY KEY`- oder `UNIQUE`-Constraints. Die Eindeutigkeit muss durch den Datenladeprozess verwaltet werden.

Eine Dimensionstabelle in BigQuery muss eine vollständige Historie der Änderungen für die Point-in-Time-Analyse (SCD Typ 2) pflegen.

→Fügen Sie `valid_from`- und `valid_to`-Timestamp-Spalten hinzu. Wenn eine Änderung auftritt, verwenden Sie eine `MERGE`-Anweisung, um den `valid_to`-Wert des alten Datensatzes zu aktualisieren und einen neuen Datensatz einzufügen.

Warum: Dies ist das Standardmuster für die Implementierung von SCD Typ 2 in einem Data Warehouse. `MERGE` bietet eine effiziente, atomare Methode zur Durchführung der erforderlichen Update- und Insert-Operationen.

Eine Anwendung erfordert eine verwaltete, skalierbare Datenbank für JSON-Dokumente mit flexiblem Schema, Transaktionsunterstützung und komplexen Abfrageanforderungen.

→Verwenden Sie Firestore im Native-Modus. Nutzen Sie Collections, Documents und Subcollections zur Modellierung der Daten. Erstellen Sie zusammengesetzte Indizes für komplexe Abfragen.

Warum: Firestore ist eine serverlose NoSQL-Dokumentendatenbank, die für transaktionale Workloads mit umfangreichen Abfragefunktionen optimiert ist, im Gegensatz zu Bigtable (Key-Value) oder BigQuery (analytisch).

Müssen Daten in Cloud Storage (Parquet, Avro, etc.) über BigQuery abfragen und dabei eine feingranulare (Zeilen-/Spalten-) Sicherheit durchsetzen.

→Erstellen Sie BigLake-Tabellen über den Cloud Storage-Daten. Wenden Sie BigQuery-Sicherheitsrichtlinien auf Zeilen- und Spaltenebene auf die BigLake-Tabellen an.

Warum: BigLake erweitert die BigQuery-Governance auf Daten im offenen Format in Cloud Storage und ermöglicht eine sichere, einheitliche Data-Lakehouse-Architektur.

Ein Data-Science-Team muss ML-Modelle auf großen BigQuery-Datensätzen trainieren, ohne Daten zu verschieben oder zu exportieren.

→Verwenden Sie BigQuery ML. Schreiben Sie `CREATE MODEL`-Anweisungen in SQL, um direkt in BigQuery zu trainieren, zu evaluieren und Vorhersagen zu treffen.

Warum: BQML eliminiert die Datenverschiebung, vereinfacht den ML-Workflow und nutzt die Rechenleistung von BigQuery, wodurch die Iteration beschleunigt wird.

Referenz↗

ML-Modelle erfordern Features sowohl für das Batch-Training als auch für die Online-Inferenz mit geringer Latenz, mit Konsistenz zwischen ihnen, um Schiefe zu vermeiden.

→Verwenden Sie Vertex AI Feature Store. Nehmen Sie Features über Batch oder Streaming auf. Es bietet einen Offline-Speicher (BigQuery) für das Training und einen Online-Speicher (Bigtable) für die Bereitstellung mit geringer Latenz.

Warum: Dies ist ein zweckmäßiger, verwalteter Dienst, der das komplexe Problem der Feature-Konsistenz, der Punkt-in-Zeit-Korrektheit und der Dual-Serving-Anforderungen löst.

Geschäftsanwender benötigen Self-Service BI, erstellen aber inkonsistente Metriken und Berichte, wenn sie das Data Warehouse direkt abfragen.

→Implementieren Sie eine Looker Semantic Layer mit LookML. Definieren Sie Dimensionen, Measures und Joins einmal. Benutzer erkunden das verwaltete Modell anstelle von Rohdatenbanktabellen.

Warum: LookML bietet eine "Single Source of Truth" für die Geschäftslogik und gewährleistet konsistente und genaue Berichterstellung, während es gleichzeitig Self-Service-Exploration ermöglicht.

Müssen automatisierte Datenqualitätsprüfungen (Nullwerte, Eindeutigkeit, Wertebereiche) und Überwachung für Daten in BigQuery und Cloud Storage implementieren.

→Verwenden Sie Dataplex Data Quality. Definieren Sie Regeln in YAML oder verwenden Sie automatisch generierte Regeln aus der Profilerstellung. Planen Sie Scans, um die Qualität im Laufe der Zeit zu überwachen.

Warum: Dataplex bietet eine verwaltete, integrierte Datenqualitätslösung, die skalierbarer und wartbarer ist als benutzerdefinierte SQL-Prüfungen oder Skripte.

Entdecken Sie natürliche Gruppierungen oder Segmente innerhalb eines Kundendatensatzes ohne vordefinierte Labels.

→Verwenden Sie BigQuery ML, um ein `KMEANS`-Clustering-Modell direkt auf den Kundendaten zu trainieren.

Warum: K-means ist ein unüberwachtes Lernverfahren, ideal für die Segmentierung. BQML macht es über SQL zugänglich, ohne Datenexport.

Ermöglichen Sie semantische Suche (basierend auf Bedeutung, nicht auf Schlüsselwörtern) über Textdaten, die in BigQuery gespeichert sind.

→Verwenden Sie die Funktion `ML.GENERATE_EMBEDDING` mit einem Vertex AI Foundation Model, um Vektoreinbettungen zu erstellen. Speichern Sie diese und verwenden Sie die Funktion `VECTOR_SEARCH` für die Ähnlichkeitssuche.

Warum: Dieses Muster integriert leistungsstarke semantische Suchfunktionen direkt in BigQuery und vermeidet die Notwendigkeit externer Suchindizes wie Elasticsearch.

Integrieren Sie Funktionen großer Sprachmodelle (LLM) wie Textzusammenfassung oder Klassifizierung direkt in einen BigQuery-Analyse-Workflow.

→Erstellen Sie ein BigQuery ML Remote-Modell, das auf einen Vertex AI LLM-Endpunkt verweist. Verwenden Sie die Funktion `ML.GENERATE_TEXT` innerhalb einer SQL-Abfrage, um Textdaten zu verarbeiten.

Warum: Dies integriert generative KI eng in SQL, wodurch Analysten LLMs auf ihren Daten nutzen können, ohne die BigQuery-Umgebung zu verlassen oder komplexen Anwendungscode schreiben zu müssen.

Eine mehrstufige Datenpipeline umfasst komplexe Abhängigkeiten, Wiederholungsversuche und Aufgaben über verschiedene GCP-Dienste hinweg (z. B. Dataflow, BigQuery, Dataproc).

→Verwenden Sie Cloud Composer (verwaltetes Apache Airflow). Definieren Sie den Workflow als Directed Acyclic Graph (DAG) mit Python.

Warum: Composer ist das dafür vorgesehene GCP-Tool für komplexe Workflow-Orchestrierung und bietet robustes Abhängigkeitsmanagement, Planung, Wiederholungslogik und Überwachung, die einfacheren Tools wie Cloud Scheduler fehlen.

Eine Airflow DAG-Aufgabe, die eine externe API aufruft, schlägt aufgrund vorübergehender Netzwerkprobleme häufig fehl.

→Konfigurieren Sie aufgabenspezifische Wiederholungsversuche im DAG mit `retry_exponential_backoff=True`. Dies erhöht die Verzögerung zwischen den Wiederholungen, wodurch das externe System Zeit zur Wiederherstellung erhält.

Warum: Exponentielles Backoff ist eine Best Practice für das Wiederholen vorübergehender Fehler, da es verhindert, dass ein überlastetes nachgeschaltetes System mit schnellen, wiederholten Anfragen überfordert wird.

Verwalten, versionieren, testen und planen Sie eine komplexe Reihe voneinander abhängiger SQL-Transformationen in BigQuery.

→Verwenden Sie Dataform. Definieren Sie Tabellen und Abhängigkeiten in SQLX-Dateien, verwenden Sie Git für die Versionskontrolle, schreiben Sie Datenqualitäts-Assertions und planen Sie Ausführungs-Workflows.

Warum: Dataform ist die native Google Cloud-Lösung für ELT, die Abhängigkeitsmanagement, Tests und Versionskontrolle für BigQuery-Transformationen bietet und Best Practices für DataOps fördert.

Müssen verstehen und visualisieren, wie Daten von der Quelle bis zum Endbericht über mehrere Dienste wie BigQuery und Dataflow fließen.

→Verwenden Sie Dataplex, das automatisch die Datenherkunft von unterstützten Google Cloud-Diensten in der Data Catalog-Benutzeroberfläche erfasst und anzeigt.

Warum: Automatisierte Herkunftsverfolgung ist entscheidend für die Auswirkungsanalyse, Fehlersuche und Governance. Dataplex bietet dies sofort einsatzbereit für integrierte Dienste.

Ein laufender Dataflow-Streaming-Job muss mit neuer Logik aktualisiert werden, ohne Daten oder Zustand zu verlieren.

→Starten Sie die neue Pipeline-Version mithilfe der Befehlszeilenoption `--update` und geben Sie die Job-ID der laufenden Pipeline an. Verwenden Sie den `drain`-Modus, damit der alte Job die gerade verarbeiteten Daten beenden kann.

Warum: Der In-Place-Update-Mechanismus von Dataflow bietet eine Möglichkeit zur Bereitstellung von Änderungen an Streaming-Pipelines ohne Ausfallzeiten, wobei der Zustand erhalten bleibt und eine genau einmalige Verarbeitung garantiert wird.

Zur Einhaltung von Vorschriften müssen alle Lese- und Schreibzugriffe auf sensible Daten in BigQuery und Cloud Storage protokolliert und prüfbar sein.

→Aktivieren Sie Cloud Audit Logs, insbesondere Datenzugriffs-Logs, für die relevanten Dienste. Erstellen Sie eine Log-Senke, um diese Logs zur Langzeitaufbewahrung und Analyse nach BigQuery zu exportieren.

Warum: Cloud Audit Logs bieten eine manipulationssichere, umfassende Aufzeichnung des Datenzugriffs. Das Sinken von Logs nach BigQuery ermöglicht leistungsstarke SQL-basierte Audits und Berichte.

BigQuery-Datasets, -Tabellen und Zugriffssteuerungen müssen als Code für Wiederholbarkeit und Versionierung (Infrastructure as Code) verwaltet werden.

→Definieren Sie alle BigQuery-Ressourcen (Datasets, Tabellen, IAM-Richtlinien) in Terraform-Konfigurationsdateien (`.tf`). Verwalten Sie Bereitstellungen über eine CI/CD-Pipeline.

Warum: Terraform ist der Standard für IaC auf GCP und ermöglicht eine geprüfte, versionskontrollierte und konsistente Verwaltung der Dateninfrastruktur, wodurch manuelle Konfigurationsabweichungen verhindert werden.

Ein ML-Modell in Produktion zeigt im Laufe der Zeit eine sich verschlechternde Leistung.

→Implementieren Sie Vertex AI Model Monitoring. Konfigurieren Sie einen Überwachungsauftrag, um Training-Serving-Skew und Prediction Drift zu erkennen, indem Sie den Produktionsverkehr mit einer Baseline vergleichen. Richten Sie Warnungen ein, um Untersuchungen oder automatisiertes Retraining auszulösen.

Warum: Die Modellleistung verschlechtert sich aufgrund von Daten-Drift. Proaktive Überwachung ist unerlässlich, um dies zu erkennen und die Modellgenauigkeit aufrechtzuerhalten, was ein Retraining rechtfertigt.