Google PDE: Datenspeicherung, Data Lakes und Dateiformate — Lernleitfaden
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
Die Datenspeicherung auf Google Cloud umfasst rohen Objektspeicher, kuratierte Data Lakes und für Analysen optimierte Formate. Der Aufbau zuverlässiger, kontrollierter und performanter Data Lakes erfordert sorgfältige Entscheidungen bei Speicherklassen, Bucket-Einstellungen, Standorten, Dateiformaten, Tabellenlayouts und dem Lebenszyklus. Dieser Abschnitt beschreibt Design-Kompromisse, zu vermeidende Fehlermodi und Muster, die auf BigQuery, Spark und Streaming-Pipelines im großen Maßstab abgestimmt sind.
Cloud Storage-Grundlagen: Klassen, Buckets, Konsistenz und Lebenszyklus
Cloud Storage ist die langlebige, hochverfügbare Grundlage für rohe und kuratierte Dateien.
Speicherklassen
- Standard (heiß): häufiger Zugriff, niedrigste Latenz. Keine Mindestspeicherdauer.
- Nearline (kühl): seltener Zugriff (~monatlich). 30 Tage Mindestdauer; Abrufgebühren fallen an.
- Coldline (kälter): seltener Zugriff (~vierteljährlich). 90 Tage Mindestdauer; höhere Abrufgebühren.
- Archive (am kältesten): Langzeitaufbewahrung (~jährlich). 365 Tage Mindestdauer; höchste Abrufgebühren.
- Autoclass kann automatisch zwischen den Klassen wechseln; überprüfen Sie, ob Gebühren für vorzeitiges Löschen und Zugriffsmuster die Einsparungen nicht zunichtemachen.
Bucket-Standorte und Replikation
- Region: am besten für Datenlokalität und Compliance innerhalb einer einzelnen geografischen Region.
- Dual-Region: zwei gekoppelte Regionen mit automatischer Replikation; Turbo-Replikation überträgt Replikate schnell mit einem in Minuten gemessenen RPO; ideal für DR mit niedrigem RPO.
- Multi-Region: geoverteilt innerhalb eines Kontinents für breite Verfügbarkeit, Inhaltsverteilung und Analysen, die ein großes Gebiet umfassen.
- Wählen Sie Standorte, um die Gesetze zur Datenresidenz zu erfüllen und den Egress/die Latenz zu Compute-Diensten (Dataproc, Dataflow, externe BigQuery-Tabellen) zu minimieren.
Konsistenz und Semantik
- Cloud Storage bietet starke globale Konsistenz für Lesevorgänge nach Schreibvorgängen (read-after-write), Lesevorgänge nach Metadaten-Updates (read-after-metadata-update) und Auflistungen nach Schreibvorgängen (list-after-write).
- Objektschreibvorgänge sind atomar und unveränderlich; ein „Umbenennen“ ist ein Muster aus Kopieren und anschließendem Löschen (copy+delete). Entwerfen Sie idempotente Kopiervorgänge und überprüfen Sie Prüfsummen, um unvollständige Migrationen zu verhindern.
Zugriffsmuster und Leistung
- Parallele zusammengesetzte Uploads und wiederaufnehmbare Uploads verbessern den Durchsatz für große Dateien.
- Bereichslesezugriffe (Range Reads) ermöglichen effiziente spaltenbasierte Footer und selektive Lesevorgänge.
- Vermeiden Sie viele kleine Dateien (<8 MB), die den Metadaten-/Auflistungs-Overhead erhöhen; fassen Sie sie in Batches zusammen oder komprimieren Sie sie zu größeren Objekten.
- GZIP ist für verteilte Lesevorgänge nicht aufteilbar (splittable); bevorzugen Sie Parquet/ORC/Avro+Snappy für skalierbare Verarbeitung.
Lebenszyklus, Aufbewahrung und Versionierung
- Aufbewahrungsrichtlinien auf Bucket-Ebene und Objektsperren (ereignisbasiert oder temporär) erzwingen Unveränderlichkeit für Compliance-Zwecke und zur Reduzierung versehentlicher Löschungen.
- Die Objektversionierung bewahrt frühere Generationen auf; nützlich für die Wiederherstellung nach Überschreibungen/Löschungen. Überwachen Sie das Wachstum der Speicherkosten.
- Lebenszyklusregeln automatisieren Übergänge und Löschungen. Beispiel (JSON), um ältere Daten in kältere Speicherklassen zu verschieben und nach einem Jahr zu löschen: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
- Fehlermodi: Gebühren für vorzeitiges Löschen, wenn Sie zu aggressiv überführen; Aufbewahrungssperren können nicht verkürzt werden; Versionierung ohne Komprimierung kann die Kosten in die Höhe treiben.
Übertragungen und Migration
- Verwenden Sie den Storage Transfer Service für parallelisierte, mit Checkpoints versehene Verschiebungen von On-Premises oder anderen Clouds; die Transfer Appliance für Petabytes an Offline-Daten.
- Validieren Sie die Integrität mit CRC32C/MD5 und Vorbedingungen für die Generationsübereinstimmung (generation-match), um Race Conditions zu verhindern.
- Bevorzugen Sie gsutil/gcloud storage mit -m (parallel) und Prüfsummen; vermeiden Sie SFTP-Engpässe bei hohem Ingress-Volumen.
Einheitliche Lake-Governance mit BigLake und Dataplex
BigLake und Dataplex standardisieren Sicherheit und Governance über Dateien und Tabellen hinweg.
BigLake
- Stellt Cloud Storage-Daten als von BigQuery verwaltete Tabellen (extern) mit einheitlichen, feingranularen Zugriffskontrollen bereit, einschließlich Zeilenzugriffsrichtlinien und Richtlinien-Tags auf Spaltenebene.
- Ermöglicht Column Pruning und Predicate Pushdown für Parquet/ORC, was die gescannten Bytes und den Egress zu Engines wie BigQuery, Spark on Dataproc und Dataflow reduziert.
- Zentralisiert die Auditierung über Cloud Logging und die zentrale Durchsetzung von Richtlinien; eine einzige Steuerungsebene für Lake-Dateien und Warehouse-Tabellen.
Dataplex
- Organisiert Daten in Lakes, Zonen (roh, kuratiert, vertrauenswürdig) und Assets (Buckets, Datasets); verwaltet Metadaten, Herkunft (Lineage) und Datenqualitätsregeln.
- Integriert sich mit Richtlinien-Tags für sensible Spalten und unterstützt das Prinzip der geringsten Rechte (Least Privilege) über IAM auf Lake-, Zonen- und Asset-Ebene.
- Fördert standardisierte Namensgebung, Partitionierung und Schema-Verwaltung in Umgebungen mit mehreren Teams, um „Daten-Rumpelkammern“ zu vermeiden.
Governance-Muster
- Implementieren Sie Muster wie Dataset-pro-Mandant und Bucket-pro-Zone; vermeiden Sie das Durchsickern von Daten zwischen Mandanten (Cross-Tenant Data Bleed).
- Verwenden Sie Zeilenzugriffsrichtlinien und Spalten-Richtlinien-Tags für PII. Beschränken Sie den API-Zugriff auf genehmigte Identitäten.
- Auditieren Sie den Zugriff mit Cloud Logging; leiten Sie gefilterte Logs zur Echtzeitüberwachung an Pub/Sub weiter.
Dateiformate, Komprimierung und Abfrageverhalten
Die Wahl des richtigen Formats hat direkte Auswirkungen auf Kosten und Leistung.
Spaltenorientierte Formate (Parquet, ORC)
- Stärken: Column Pruning (Spalteneliminierung), Predicate Pushdown, Kodierung und Komprimierung pro Spalte, Statistiken und aufteilbare Dateien.
- Nachteile: höhere CPU-Auslastung beim Schreiben; Schema-Evolution muss sorgfältig verwaltet werden (z. B. das Hinzufügen von Spalten ist sicher; Typänderungen sind riskant).
- Komprimierung: Snappy für Geschwindigkeit, ZSTD für bessere Kompressionsraten, wo unterstützt. Vermeiden Sie GZIP für spaltenorientierte Formate, es sei denn, Interoperabilitätsanforderungen erfordern es.
Zeilenorientiertes Avro
- Stärken: Schema-Evolution mit starker Typisierung, Komprimierung auf Blockebene, aufteilbar; hervorragend für Landing Zones im Streaming-Bereich und den Datenaustausch.
- Nachteile: weniger scan-effizient für Analysen als spaltenorientierte Formate; in kuratierten Zonen in Parquet/ORC konvertieren.
CSV und JSON (semistrukturiert)
- CSV: menschenlesbar, geringster Overhead bei einfachen Werten; fehlendes Schema, keine Typen und inkonsistentes Escaping; aufwendig zu parsen bei großen Datenmengen.
- JSON: selbstbeschreibend und flexibel; für skalierbare, verteilte Lesevorgänge ist zeilengetrenntes JSON (Newline-Delimited JSON) erforderlich; ausführlich (verbose) und CPU-intensiv zu parsen.
- Wo möglich, rohe CSV/JSON-Daten speichern (landen), dann validieren und für Analysen in Avro/Parquet konvertieren.
Externe Tabellen und BigLake-Tabellen in BigQuery
- Externe Parquet/ORC-Tabellen profitieren von Pushdown und Column Pruning; CSV/JSON-Tabellen typischerweise nicht, was zu mehr gescannten Bytes führt.
- Komprimierte externe CSV-Tabellen (GZIP) können nicht auf mehrere Worker aufgeteilt werden; rechnen Sie mit langsameren Lesevorgängen.
- Beispiel: Erstellen einer Parquet-BigLake-Tabelle mit Partitionen im Hive-Stil:
CREATE EXTERNAL TABLE lake.sales
WITH CONNECTION
us.biglake_connOPTIONS ( format = ‘PARQUET’, hive_partitioning_mode = ‘AUTO’, hive_partitioning_source_uri_prefix = ‘gs://corp-raw/sales/’, uris = [‘gs://corp-raw/sales/date=/region=/part-*.parquet’] );
Layout, Partitionierung, Performance-Engineering, Datenresidenz und Migration
Objekt-Layout und Partitionierung
- Verwenden Sie Pfade im Hive-Stil für Partitionen und Clustering-Schlüssel: gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
- Halten Sie die Größe einzelner Dateien im Bereich von 128–1024 MB, um eine ausgewogene Parallelität und einen geringen Task-Overhead zu gewährleisten. Vermeiden Sie Millionen von Dateien pro Partition.
- Beheben Sie Probleme mit kleinen Dateien durch:
- Bündelung von Uploads auf Client-Seite.
- Verwendung von Dataflow/Spark-Komprimierungs-Jobs, um kleine Dateien außerhalb der Spitzenzeiten zusammenzuführen.
- Archivierung der ursprünglichen kleinen Dateien und Bereitstellung nur der komprimierten Daten für die Analyse.
BigQuery-Partitionierung und -Clustering
- Partitionieren Sie nach Aufnahmezeit (Ingestion Time) oder einer Filterspalte mit hoher Kardinalität (z. B. event_date). Vermeiden Sie eine übermäßige Partitionierung (z. B. pro Minute), die die Metadaten aufbläht.
- Clustern Sie nach häufig gefilterten/sortierten Dimensionen (bis zu vier). Clustering erhöht die Datenlokalität und reduziert die Anzahl der gescannten Bytes.
← Data Engineering-Architektur und -Design · Alle Domänen · BigQuery Analytics und Warehouse-Engineering →
Diese Fragen üben → · Zeitlich begrenzte Übung auf ExamRoll.io →
Pass the whole exam — not just this question
You found this answer. Get every verified question and explanation in one place, and save hours of prep. Free to start.
Bestehe deine Prüfung →