Google PDE: BigQuery Analytics und Warehouse-Engineering — 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

BigQuery ist ein serverloses, spaltenbasiertes MPP-Analyse-Warehouse, das Speicherung von Rechenleistung trennt und dadurch nahezu unbegrenzte Skalierbarkeit, ANSI SQL und integrierte Governance bietet. Das Warehouse-Engineering in BigQuery erfordert eine ausgewogene Balance zwischen Schemadesign (Partitionierung, Clustering, Denormalisierung vs. Normalisierung, verschachtelte Datensätze), Ingestion-Mustern (Batch-Ladevorgänge, Streaming, Storage Write API) und Workload-Management (On-Demand- vs. kapazitätsbasierte Editionen und Reservierungen). Robuste Sicherheit (autorisierte Ansichten, Zeilen-/Spaltenrichtlinien, Policy-Tags) existiert neben Kostenkontrollen und Performance-Tools, um die Anzahl gescannter Bytes zu minimieren und die Latenz zu reduzieren. Dieser Abschnitt behandelt die Kerndesignprinzipien, den Betrieb und die Fehlermodi, die Sie in der Produktion antizipieren müssen.

Speicherung und Semantik: Datasets, Tabellen, Ansichten und Lake-Zugriff

• Datasets, Tabellen, Ansichten:

  • Datasets definieren den Geltungsbereich für IAM und Governance. Verwenden Sie mandantenspezifische Datasets zur Isolation und zur klaren Abrechnung.
  • Standardtabellen speichern Daten nativ; Partitionen und Clustering steuern das Layout und das Pruning (Datenreduktion).
  • Ansichten kapseln SQL-Logik, ohne Daten zu speichern. Autorisierte Ansichten ermöglichen es einem Ansichtsbesitzer, eingeschränkte Teilmengen für andere Projekte oder Mandanten freizugeben, während die zugrunde liegenden Tabellen verborgen bleiben.
  • Materialisierte Ansichten (MVs) speichern vorberechnete Ergebnisse dauerhaft und werden automatisch aktualisiert. Die Abfrageumschreibung (Query Rewrite) nutzt MVs transparent, wenn sie kompatibel sind; inkompatible Prädikate oder Funktionen umgehen sie.
  • Externe Tabellen verweisen auf Daten in Cloud Storage, Google Drive oder Google Sheets. Sie vermeiden die Datenaufnahme (Ingestion), tauschen aber Durchsatz und Funktionsunterstützung gegen Komfort ein. Für wiederholte Analysen sollten die Daten in native Tabellen aufgenommen werden.

• Partitionierung, Clustering und verschachtelte Datensätze:

  • Partitionieren Sie nach Aufnahmezeit, DATE/TIMESTAMP/DATETIME oder einem Ganzzahlbereich, um Scans zu reduzieren (Pruning). Verwenden Sie WHERE-Filter für die Partitionsspalte oder Dekoratoren wie _PARTITIONDATE, um Pruning zu ermöglichen.
  • Clustern Sie nach Spalten mit hoher Kardinalität, die häufig gefiltert oder für Joins verwendet werden (bis zu 8). BigQuery führt das Reclustering automatisch durch; wiederholte kleine DML-Operationen können die Clustering-Qualität vorübergehend beeinträchtigen.
  • Verschachtelte und wiederholte Datensätze (STRUCT, ARRAY) bilden Eins-zu-viele-Beziehungen ohne den Overhead von Joins ab. Verwenden Sie UNNEST mit Bedacht; wiederholtes UNNEST bei großen Arrays kann zu einer dramatischen Vervielfachung der Daten führen (Fan-Out).

• Denormalisierung vs. Normalisierung:

  • Denormalisieren Sie Dimensionsattribute in Faktentabellen, um Joins zu minimieren und spaltenbasierte Scans auszunutzen; dies ist ideal für leseintensive Analysen.
  • Normalisieren Sie, wenn Schreibverstärkung (Write Amplification), Update-Hotspots oder Self-Joins zu Konflikten oder Komplexität führen (z. B. die Trennung von Stammdaten der Patienten und Besuchstabellen, um eine Explosion durch Self-Joins zu vermeiden). Ziehen Sie einen hybriden Ansatz in Betracht: normalisierte Kernentitäten mit breiten, denormalisierten Fakten oder verschachtelten Kindelementen.

• Materialisierte Ansichten: Designüberlegungen

  • Am besten geeignet für stabile, inkrementelle Aggregate über partitionierte Basistabellen. Die Aktualisierung von MVs erfolgt asynchron; nachgelagerte Nutzer sollten Zeitfenster mit veralteten Daten (Staleness) tolerieren oder als Fallback die Basistabellen abfragen.
  • Filtern und gruppieren Sie nach der Partitionsspalte für eine inkrementelle Aktualisierung. Nicht-deterministische Funktionen, nicht unterstützte Joins oder UDFs können MVs für die Abfrageumschreibung disqualifizieren.

• Föderierte Abfragen, BigLake und Pushdown:

  • Föderierte Abfragen lesen externe Systeme (z. B. Cloud SQL) direkt mit SQL aus. Sie sind praktisch für leichte Joins oder einmalige explorative Analysen, haben aber eine höhere Latenz und engere Kontingente; extrahieren Sie die Daten für intensive Analysen nach BigQuery.
  • BigLake-Tabellen vereinheitlichen die Governance von Lake und Warehouse mit Kontrollen auf Spalten- und Zeilenebene über Daten in Cloud Storage oder offenen Tabellenformaten (wie Parquet). Prädikat- und Projektions-Pushdown reduzieren die heruntergeladene Byte-Menge; bei großen Scans ist die Aufnahme in native Tabellen für maximale Leistung dennoch zu bevorzugen.

• Wildcard-Tabellen und Legacy-Shards:

  • Wildcard-Abfragen sind ein veraltetes Muster für nach Datum aufgeteilte (geshardete) Tabellen. Bevorzugen Sie die native Partitionierung, aber wenn nötig: SELECT … FROM bigquery-public-data.noaa_gsod.gsod* WHERE _TABLE_SUFFIX >= ‘2010’.

Abfrageoptimierung und Workload-Management

• Partitions-Pruning und Clustering:

  • Immer nach der Partitionsspalte filtern, um das Scannen kalter Partitionen zu vermeiden. Verwenden Sie BETWEEN mit engen Fenstern.
  • Clustering-Schlüssel nach Selektivität ordnen; frühere Schlüssel sollten mit häufigen Filtern und Joins übereinstimmen. Vermeiden Sie das Clustering nach Spalten mit sehr niedriger Kardinalität.

• Optimierung des Abfrageplans:

  • Verwenden Sie EXPLAIN und Ausführungsdetails, um schiefe Joins (skewed joins), große Shuffles oder nicht bereinigte Scans (non-pruned scans) zu finden.
  • Reduzieren Sie Spalten frühzeitig mit SELECT-Listen und Unterabfragen; BigQuery ist spaltenorientiert und verwirft ungenutzte Spalten effizient.
  • Bevorzugen Sie approximative Aggregationen (z. B. APPROX_QUANTILES) für Geschwindigkeits-/Kosten-Kompromisse bei großen Datenmengen.
  • Wenden Sie Deduplizierung mit Fensterfunktionen an, wenn Ingest-Quellen Ereignisse wiederholen könnten:
    • SELECT * EXCEPT(rn) FROM (SELECT t.*, ROW_NUMBER() OVER (PARTITION BY unique_id ORDER BY event_ts DESC) rn FROM my_table t) WHERE rn = 1;

• Joins und Denormalisierung:

  • Legen Sie Join-Schlüssel als Clustering-Schlüssel zusammen ab, um Shuffle zu reduzieren. Bloom-Filter oder Vorab-Aggregationen können bei extremer Datenschiefe (extreme skew) helfen.
  • Denormalisieren Sie kleine, sich langsam ändernde Dimensionen (slowly changing dimensions) in Faktentabellen, um „heiße“ Joins (hot joins) zu vermeiden. Bei sehr breiten Dimensionen mit häufigen Updates normalisieren Sie und verlassen Sie sich auf Clustering-Schlüssel und materialisierte Joins.

• Workload-Management, Slots, Editionen und Autoscaling:

  • On-Demand: BigQuery skaliert die Rechenleistung pro Abfrage elastisch; Sie zahlen pro gescanntem TB. Kontrollieren Sie die Kosten durch eine Obergrenze für abgerechnete Bytes (maximum bytes billed) und Partitions-Pruning.
  • Kapaz

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

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

Google durchsuchen →