Google Cloud Associate Data Practitioner
Zuletzt überprüft: Mai 2026
Eine übersichtliche Referenz der Architekturmuster, die in der ADP-Prüfung getestet werden. Von oben nach unten lesen oder zu einem Abschnitt springen.
Große Batch-Dateien (CSV, Parquet, Avro) aus Cloud Storage in BigQuery laden.
Einen BigQuery-Ladejob verwenden. Einen Wildcard-URI (z.B. `gs://bucket/path/*`) angeben, um mehrere Dateien in einem einzigen Job zu laden.
Warum: Dies ist die schnellste und kostengünstigste Methode für die Batch-Aufnahme. Ladejobs sind kostenlos. Sie vermeiden die pro-Zeile-Kosten des Streamings.
Hochvolumige Echtzeitdaten (IoT, Clickstream) mit Transformationspotenzial aufnehmen.
Pub/Sub -> Dataflow -> BigQuery.
Warum: Kanonisches skalierbares Streaming-Muster. Pub/Sub bietet einen dauerhaften, skalierbaren Puffer. Dataflow ermöglicht komplexe Transformationen, Fensterung und Exactly-Once-Verarbeitung.
Eine operative Datenbank (MySQL, PostgreSQL, Oracle) mit geringer Latenz nach BigQuery replizieren und alle Änderungen (Einfügungen, Aktualisierungen, Löschungen) erfassen.
Datastream für Change Data Capture (CDC) verwenden.
Warum: Spezifisch für wirkungsarme Echtzeit-CDC entwickelt. Es übernimmt die anfängliche Auffüllung und streamt fortlaufende Änderungen direkt nach BigQuery.
Komplexe Datenvalidierung, -anreicherung oder -transformation (z.B. Flattening verschachtelter JSON/XML) vor dem Laden nach BigQuery durchführen.
Eine Dataflow-Pipeline mit benutzerdefinierten Apache Beam-Transformationen (z.B. ParDo) verwenden.
Warum: Dataflow bietet maximale Flexibilität für benutzerdefinierten Code (Python/Java), komplexe Logik und das Weiterleiten ungültiger Datensätze an eine Dead-Letter-Queue.
Terabyte oder Petabyte von Daten von einer anderen Cloud (z.B. S3) oder einem lokalen Rechenzentrum in Cloud Storage übertragen.
Für Cloud-zu-Cloud-Transfers den Storage Transfer Service verwenden. Für On-Premises-Umgebungen mit begrenzter Netzwerkbandbreite die Transfer Appliance verwenden.
Warum: STS ist ein verwalteter Hochleistungsdienst für Online-Übertragungen. Die Transfer Appliance ist für Offline-Übertragungen (physischer Versand), wenn das Netzwerk der Engpass ist.
Daten, die in Cloud Storage oder Amazon S3 gespeichert sind, direkt aus BigQuery abfragen, ohne sie zu laden.
Eine BigQuery External Table erstellen. Für eine einheitliche Governance mit Spark eine BigLake Table verwenden.
Warum: Vermeidet Datenreplikation und Speicherkosten in BigQuery. BigLake ergänzt eine fein granulare Sicherheit (auf Zeilen-/Spaltenebene) und Governance für Objektspeicherdaten.
Eine Aufnahmepipeline muss sich automatisch anpassen, wenn neue Spalten zu Quelldateien (JSON, Avro) hinzugefügt werden.
Den BigQuery-Ladejob mit `schemaUpdateOptions` auf `ALLOW_FIELD_ADDITION` konfigurieren.
Warum: Automatisiert die Schema-Evolution. BigQuery fügt die neuen Spalten dem Tabellenschema hinzu, ohne den Ladejob fehlschlagen zu lassen.
Hochvolumige Daten mit Exactly-Once-Semantik zu geringeren Kosten als die ältere Streaming-API nach BigQuery streamen.
Die BigQuery Storage Write API verwenden.
Warum: Bietet höheren Durchsatz und geringere Kosten als die ältere `insertAll` API, mit starken Garantien wie Exactly-Once-Zustellung innerhalb eines Streams.
Einen komplexen Workflow mit mehreren abhängigen Aufgaben (z.B. Dataflow, BigQuery, Cloud Functions) nach einem Zeitplan orchestrieren.
Cloud Composer (verwaltetes Apache Airflow) verwenden.
Warum: Der Standard für die Orchestrierung komplexer Workflows. Bietet DAGs zur Definition von Abhängigkeiten, Zeitplanung, Wiederholungen, Benachrichtigungen und ein umfangreiches Operator-Ökosystem.
Ein Cloud Composer DAG muss anhalten und warten, bis eine bestimmte Datei in einem Cloud Storage Bucket erscheint, bevor es fortfährt.
Den `GCSObjectExistenceSensor` im Airflow DAG verwenden.
Warum: Dies ist das idiomatische Airflow "Sensor"-Muster zum Warten auf externe Bedingungen. Es ist effizienter als eine benutzerdefinierte Abfrageschleife in einem PythonOperator.
Eine Streaming-Dataflow-Pipeline muss Ereignisse nach Zeitstempel korrekt aggregieren, selbst wenn Ereignisse ungeordnet oder verspätet eintreffen.
Ereigniszeit-Fensterung mit Watermarks verwenden und `allowedLateness` konfigurieren.
Warum: Diese Kernfunktion von Dataflow/Beam gruppiert Daten korrekt basierend auf dem Zeitpunkt des Ereignisses, nicht auf dem Zeitpunkt der Verarbeitung. `allowedLateness` verhindert, dass verspätete Daten verworfen werden.
Großskalige, nicht-interaktive Apache Spark-Jobs für Batch-Verarbeitung oder ML ausführen.
Einen Dataproc-Cluster verwenden. Für maximale Kosteneinsparungen einen ephemeren Cluster mit Spot VMs (ehemals Preemptible VMs) verwenden.
Warum: Dataproc ist der verwaltete Spark/Hadoop-Dienst. Ephemere Cluster existieren nur für die Dauer des Jobs, und Spot VMs bieten hohe Rabatte für fehlertolerante Workloads.
Eine standardisierte Dataflow-Pipeline erstellen, die von verschiedenen Teams mit variierenden Parametern (z.B. Eingabe-/Ausgabe-Pfade) ausgeführt werden kann.
Die Pipeline als Dataflow Flex Template verpacken.
Warum: Flex Templates sind der moderne Standard für wiederverwendbare Dataflow-Jobs. Sie sind containerbasiert, unterstützen benutzerdefinierte Abhängigkeiten und akzeptieren Laufzeitparameter.
Eine Aufgabe in einem Cloud Composer DAG schlägt aufgrund temporärer externer Probleme (z.B. API-Ratenbegrenzung, Ressourcenkonflikte) zeitweise fehl.
`retries` und `retry_delay` mit `retry_exponential_backoff=True` für die Aufgabe konfigurieren.
Warum: Dies macht die Pipeline widerstandsfähiger, indem fehlgeschlagene Aufgaben mit zunehmenden Verzögerungen automatisch wiederholt werden, wodurch transiente Probleme oft ohne manuelles Eingreifen gelöst werden.
Eine Dataflow-Streaming-Pipeline gerät in Rückstand und weist eine hohe Systemlatenz oder Datenaktualität auf.
Dataflow-Überwachungsmetriken untersuchen. Prüfen, ob die Autoskalierung das `maxNumWorkers`-Limit erreicht. `maxNumWorkers` erhöhen oder auf einen größeren Maschinentyp wechseln.
Warum: Hohe Systemlatenz ist ein primärer Indikator für unzureichende Verarbeitungskapazität. Die Pipeline benötigt mehr oder größere Worker, um mit dem Datenzufluss Schritt zu halten.
Eine große BigQuery-Tabelle für Abfragekosten und -leistung optimieren.
Die Tabelle nach einer häufig gefilterten Zeiteinheitsspalte (z.B. Transaktionsdatum) partitionieren. Die Tabelle nach anderen Spalten mit hoher Kardinalität und häufiger Filterung (z.B. `customer_id`) clustern.
Warum: Partitionierung ist die effektivste Methode, um Kosten und Latenz durch Reduzierung der gescannten Datenmenge zu senken. Clustering verbessert die Leistung zusätzlich durch Sortieren der Daten innerhalb von Partitionen.
Verhindern, dass Daten aus einem sensiblen BigQuery-Datensatz an ein nicht autorisiertes Ziel (z.B. einen öffentlichen GCS-Bucket) kopiert werden, selbst von einem Benutzer mit gültigen Anmeldeinformationen.
VPC Service Controls verwenden, um einen Dienstperimeter um das Projekt zu erstellen, das den BigQuery-Datensatz enthält.
Warum: VPC Service Controls fungieren als "virtuelle Firewall" für GCP-Dienste und verhindern, dass Daten den Perimeter verlassen. Dies ist eine kritische Defense-in-Depth-Kontrolle gegen Datenexfiltration.
Den Zugriff auf sensible Spalten (z.B. PII) in einer BigQuery-Tabelle auf autorisierte Gruppen beschränken, während andere die restlichen Spalten abfragen dürfen.
Data Catalog verwenden, um eine Taxonomie und Policy Tags zu erstellen. Policy Tags auf sensible Spalten anwenden und die Rolle "Fine-Grained Reader" an autorisierte Gruppen vergeben.
Warum: Dies ist die native, skalierbare Methode für die Sicherheit auf Spaltenebene in BigQuery. Sie bietet eine zentralisierte Governance, ohne separate Ansichten erstellen und verwalten zu müssen.
Eine Tabelle filtern, sodass Benutzer nur Zeilen sehen können, die sie betreffen (z.B. Verkaufsleiter sehen nur Daten ihrer eigenen Region).
Eine Row-Level Security Policy für die Tabelle erstellen, die Zeilen basierend auf `SESSION_USER()` filtert.
Warum: Bietet dynamisches, prädikatbasiertes Filtern zur Abfragezeit. Dies ist sicherer und besser verwaltbar als das Erstellen einer autorisierten Ansicht für jeden Benutzer oder jede Rolle.
Daten nach einer festgelegten Aufbewahrungsfrist automatisch aus einer BigQuery-Tabelle löschen, um Vorschriften einzuhalten (z.B. Daten löschen, die älter als 7 Jahre sind).
Für Zeitreihendaten eine Partitionsablaufzeit für die zeitpartitionierte Tabelle festlegen. Für andere Tabellen die Standard-Tabellenablaufzeit festlegen.
Warum: Dies ist eine integrierte "Set-and-Forget"-Funktion, die die Einhaltung von Vorschriften ohne manuelle Bereinigungsskripte oder externe Orchestrierung gewährleistet.
Eine BigQuery-Tabelle wurde versehentlich geändert oder gelöscht.
BigQuery Time Travel verwenden, um die Tabelle so abzufragen, wie sie zu einem Zeitpunkt vor dem Vorfall existierte, unter Verwendung von `FOR SYSTEM_TIME AS OF`.
Warum: BigQuery verwaltet automatisch eine 7-tägige Historie der Tabellendaten. Dies ermöglicht eine sofortige Wiederherstellung innerhalb des Time-Travel-Fensters, ohne aus Backups wiederherstellen zu müssen.
Datenressourcen (BigQuery, GCS) in einer gesamten Organisation entdecken, verwalten, sichern und überwachen.
Dataplex verwenden.
Warum: Dataplex fungiert als intelligente Datenplattform und bietet eine einheitliche Oberfläche für Datengovernance, -qualität, -herkunft, -erkennung und Lebenszyklusmanagement über unterschiedliche Datensilos hinweg.
Verstehen und visualisieren, wie Daten von Quellsystemen, durch Transformationsjobs, zu finalen Berichtstabellen fließen.
Dataplex Data Lineage verwenden.
Warum: Erfasst automatisch Lineage-Informationen aus BigQuery-, Data Fusion- und Composer-Logs, um eine interaktive, grafische Ansicht von Datenabhängigkeiten für Wirkungsanalyse und Auditing bereitzustellen.
Vorhersehbare Abfrageleistung und -kosten für kritische Workloads gewährleisten und "Slot-Konflikte" durch andere Benutzer vermeiden.
BigQuery Editions (kapazitätsbasierte Preisgestaltung) erwerben. Reservierungen erstellen, um einen Pool von Slots bestimmten Projekten oder Ordnern zuzuweisen.
Warum: Wechselt von einem gemeinsamen On-Demand-Pool zu einer dedizierten Rechenkapazität, wodurch Ressourcen für kritische Jobs garantiert und eine vorhersehbare Abrechnung ermöglicht werden.
Alle Datenbestände in BigQuery und Cloud Storage scannen, um PII und andere sensible Daten automatisch zu identifizieren und zu klassifizieren.
Einen Cloud Data Loss Prevention (DLP) Erkennungs-Scan-Job konfigurieren.
Warum: Cloud DLP verwendet Hunderte von vordefinierten Detektoren, um sensible Daten in großem Maßstab zu finden. Es kann mit Data Catalog integriert werden, um automatisch Policy Tags für die Governance anzuwenden.
Eine containerisierte Anwendung (auf GKE oder Cloud Run) muss sich sicher bei BigQuery authentifizieren, ohne Dienstkontoschlüssel verwalten zu müssen.
Workload Identity verwenden.
Warum: Die empfohlene Best Practice für die Service-zu-Service-Authentifizierung. Es ordnet ein Kubernetes-Dienstkonto einem GCP IAM-Dienstkonto zu und verwendet kurzlebige, automatisch rotierende Tokens.
Zur Einhaltung von Vorschriften einen Bericht über alle Benutzer erstellen, die eine sensible BigQuery-Tabelle in den letzten 90 Tagen abgefragt haben.
Die BigQuery Data Access Audit-Logs aktivieren und abfragen, die zur Analyse an einen BigQuery-Datensatz weitergeleitet werden können.
Warum: Data Access Logs bieten eine unveränderliche Aufzeichnung darüber, wer wann auf welche Daten zugegriffen hat. Sie sind unerlässlich für Sicherheits- und Compliance-Audits, müssen aber explizit aktiviert werden.
Identifizieren, welche Benutzer oder Abfragen für hohe BigQuery-Kosten verantwortlich sind.
Die `INFORMATION_SCHEMA.JOBS`-Ansicht abfragen.
Warum: Diese Metadatenansicht enthält detaillierte Informationen für jede ausgeführte Abfrage, einschließlich des Benutzers, der abgerechneten Bytes und der verbrauchten Slots, was eine präzise Kostenattribution und -analyse ermöglicht.
Komplexe analytische Berechnungen durchführen, wie laufende Summen, Rangfolgen innerhalb von Gruppen (z.B. Top N pro Kategorie) oder den Vergleich einer Zeile mit einer vorhergehenden Zeile.
BigQuery SQL Window Functions verwenden (`SUM() OVER (...)`, `RANK() OVER (...)`, `LAG() OVER (...)`).
Warum: Die Standard- und effizienteste SQL-Methode zur Durchführung von Berechnungen über eine Menge von Tabellenzeilen, die in irgendeiner Weise mit der aktuellen Zeile verbunden sind.
Interaktive, sich automatisch aktualisierende Dashboards auf BigQuery-Daten für Business-Benutzer erstellen und teilen, die kein SQL schreiben.
Looker Studio verwenden.
Warum: Das native, kostenlose GCP-Visualisierungstool. Es verbindet sich direkt mit BigQuery und ermöglicht das Teilen über einen einfachen Link, wobei Datenquellen-Anmeldeinformationen getrennt vom Benutzerzugriff verwaltet werden.
Business-Analysten ermöglichen, vertraute Tabellenkalkulationstools (Pivot-Tabellen, Diagramme, Formeln) zu verwenden, um Terabytes an Daten in BigQuery zu analysieren.
Connected Sheets verwenden.
Warum: Bietet eine Live-Verbindung von Google Sheets zu BigQuery. Die gesamte Verarbeitung und Berechnung erfolgt in BigQuery, wodurch die Größen- und Leistungsgrenzen einer herkömmlichen Tabellenkalkulation umgangen werden.
Ein Looker Studio-Dashboard, das große, komplexe Aggregationen abfragt, ist langsam und kostspielig.
Eine BigQuery Materialized View erstellen, um die Aggregationen vorab zu berechnen. Die Looker Studio-Datenquelle auf die Materialized View verweisen.
Warum: Materialisierte Ansichten berechnen teure Abfrageergebnisse vorab und cachen sie. Dies verbessert die Dashboard-Leistung erheblich und reduziert die Abfragekosten für wiederholte Workloads.
Ein Machine-Learning-Modell (z.B. für Klassifikation, Regression oder Prognose) mit Daten aus BigQuery erstellen, trainieren und bereitstellen.
BigQuery ML (BQML) verwenden.
Warum: Demokratisiert ML, indem es Benutzern ermöglicht, Modelle mit der Standard-SQL `CREATE MODEL`-Syntax zu trainieren. Das Modell lebt und läuft innerhalb von BigQuery, was Bereitstellung und Vorhersage vereinfacht.
Zukünftige Geschäftsmetriken (z.B. Umsatz, Nachfrage) basierend auf historischen Zeitreihendaten prognostizieren.
BigQuery ML mit dem `ARIMA_PLUS`-Modelltyp verwenden.
Warum: `ARIMA_PLUS` ist ein speziell entwickeltes BQML-Modell für die Zeitreihenprognose, das Trends, Saisonalität, Feiertage und Anomalieerkennung automatisch handhabt.
Eine BigQuery-Abfrage, die eine sehr große Faktentabelle (TBs) mit einer kleinen Dimensionstabelle (<100MB) verbindet, ist langsam.
Sicherstellen, dass BigQuery einen Broadcast Join verwendet. Obwohl oft automatisch, kann der Abfrageplan überprüft oder bei Bedarf ein `JOIN`-Hint verwendet werden.
Warum: Ein Broadcast Join sendet die gesamte kleine Tabelle an jeden Verarbeitungsslot, wodurch ein kostspieliges und langsames Daten-Shuffle der großen Tabelle über das Netzwerk vermieden wird.
Ein BigQuery ML-Modell muss regelmäßig (z.B. wöchentlich) mit neuen Daten neu trainiert werden, um Modelldrift zu verhindern.
Eine BigQuery Scheduled Query verwenden, um eine `CREATE OR REPLACE MODEL`-Anweisung auszuführen.
Warum: Dies ist die einfachste und am besten integrierte Methode zur Automatisierung des BQML-Nachtrainings. Sie erfordert keine externen Dienste wie Composer oder Cloud Functions.
Ein kollaboratives Filter-Empfehlungssystem erstellen (z.B. "Benutzer, die X gekauft haben, kauften auch Y").
BigQuery ML mit dem `MATRIX_FACTORIZATION`-Modelltyp verwenden.
Warum: Dieses Modell wurde speziell für Empfehlungsaufgaben basierend auf Benutzer-Artikel-Interaktionsdaten entwickelt.
