Google PCA: Datenspeicherung, Datenbanken und Analytics-Architektur — Lernleitfaden

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

Teil des Google Professional Cloud Architect — Lernleitfaden. Üben Sie mit verifizierten Antworten im Google-Prüfungscenter, oder absolvieren Sie zeitlich begrenzte Übungstests auf ExamRoll.io.

Überblick

Das Entwerfen von Datenspeichern, Datenbanken und Analyselösungen auf Google Cloud erfordert die Abstimmung von Workload-Mustern auf die passenden Dienste, während Aspekte wie Langlebigkeit, Verfügbarkeit, Zugriffskontrolle, Kosten und betriebliche Ausfallsicherheit berücksichtigt werden. Dieser Abschnitt behandelt Objektspeicher und Lifecycle-Governance, operative Datenbanken und Caches, Analytics-Warehousing und -Verarbeitung, Ingestion-Architekturen sowie Praktiken für Governance, Schutz und Leistung. Er beleuchtet Designentscheidungen, betriebliche Überlegungen und häufige Fehlermodi oder Kompromisse.

Speicher- und Objektarchitektur

Design von Cloud Storage-Buckets

Standort: Wählen Sie eine Region für latenz- und kostensensible Workloads; eine Dual-Region für Geschäftskontinuität mit vorhersagbarem Failover; eine Multi-Region für globalen Lesezugriff. Dual-Regionen bieten optionale Turbo-Replikation für ein SLA-gestütztes, niedriges RPO; andernfalls erfolgt die Replikation asynchron.
Namespace und Trennung: Verwenden Sie separate Buckets für verschiedene Datendomänen, Umgebungen und Vertraulichkeitsstufen. Nutzen Sie einheitlichen Zugriff auf Bucket-Ebene und die Verhinderung des öffentlichen Zugriffs für konsistente Berechtigungen.
Speicherklassen: Standard für „heiße“ Daten; Nearline für seltenen Zugriff (monatlich); Coldline für vierteljährlichen Zugriff; Archive für langfristige Aufbewahrung. Autoclass kann die Zuweisung zu Speicherklassen automatisch mit minimalem Betriebsaufwand optimieren.
Lebenszyklusrichtlinien: Automatisieren Sie die Verschiebung und Löschung nach Alter, Speicherklasse oder Objektpräfix. Beispiel zum Löschen von Objekten, die älter als 90 Tage sind: { “rule”: [ { “action”: {“type”: “Delete”}, “condition”: {“age”: 90} } ] } Anwenden mit: gsutil lifecycle set lifecycle.json gs://my-bucket
Aufbewahrung und Legal Holds: Konfigurieren Sie Aufbewahrungsrichtlinien für Buckets und sperren Sie diese optional, um eine Verkürzung zu verhindern (Compliance). Ereignisbasierte Holds und Objektversionierung ermöglichen die Wiederherstellung nach versehentlichem Löschen oder Überschreiben.
Replikation: Wählen Sie eine Dual-Region für synchrone Konsistenzsemantik an der API mit Hintergrundreplikation über zwei Regionen; nutzen Sie Bucket-zu-Bucket-Replikation (für projekt- oder standortübergreifende Kopien), um spezielle RPO/RTO-Anforderungen oder die Funktionstrennung zu erfüllen.

Fehlermodi und Kompromisse

Eine falsche Zuordnung der Speicherklasse erhöht Kosten und Latenz. Autoclass reduziert dies, fügt aber einen Verwaltungsaufwand pro Objekt hinzu.
Eine Aufbewahrungssperre ist unumkehrbar; testen Sie Richtlinien in Nicht-Produktionsumgebungen.
Replikation verbessert die Langlebigkeit, kann aber die Schreiblatenz und die Kosten erhöhen; entwerfen Sie Lese-/Schreibpfade für gezielte Standorte.

Muster

Data Lake: Roh- und kuratierte Zonen auf Cloud Storage; Governance über Dataplex; externalisierte Schemata in Data Catalog.
Archivierung: Archive-Klasse mit Aufbewahrungssperre für Compliance, mit externen Tabellen in BigQuery oder On-Demand-Wiederherstellung für seltene Analysen.
Lakehouse: Verwenden Sie BigLake, um den Zugriff über Cloud Storage und BigQuery hinweg mit einheitlicher Sicherheit zu vereinheitlichen.

Operative Datenspeicher und Caching

Cloud SQL

Hochverfügbarkeit: regionale HA mit synchroner Replikation auf eine Standby-Instanz; automatisches Failover typischerweise innerhalb von Sekunden bis zu ein paar Minuten. Der Instanz-Endpunkt bleibt derselbe, was Anwendungsänderungen minimiert.
Lesereplikas: innerhalb der Region oder regionsübergreifend, asynchron; gut für die Skalierung von Lesevorgängen (Read Scale-out) und Disaster Recovery (DR). Replikationsverzögerung (Lag) überwachen; veraltete Lesevorgänge (Stale Reads) können die Korrektheit beeinträchtigen.
Backups und PITR: geplante Backups plus Point-in-Time-Recovery (PITR) unter Verwendung von Transaktionsprotokollen (in der Regel ein Fenster von bis zu 7 Tagen, je nach Engine). Wiederherstellung regelmäßig testen.
Private Konnektivität: private IP über VPC-Peering reduziert die Angriffsfläche und Latenz; IP-Bereiche planen, um Überschneidungen zu vermeiden.
Migration: Der Database Migration Service unterstützt Migrationen mit geringer Ausfallzeit von On-Premises oder anderen Clouds; für Verbindungen mit hohem Volumen Dedicated oder Partner Interconnect gegenüber VPN bevorzugen, um Paketverluste und Latenz zu reduzieren.

Abwägungen und Fehlermodi

HA-Failover setzen Verbindungen zurück; Anwendungen müssen Wiederholungsversuche mit Backoff implementieren. Wartungsfenster können die Leistung kurzzeitig beeinträchtigen.
Lang andauernde Transaktionen erhöhen die Replikationsverzögerung und die Wiederherstellungszeit bei PITR.
Überprovisionierter Speicher ist eine günstige Versicherung; unterprovisionierte IOPS verursachen latente Ausfälle bei Spitzenlast.

Cloud Spanner

Globale Skalierung und Konsistenz: stark konsistente Lese-/Schreibvorgänge über Regionen hinweg durch TrueTime und Zwei-Phasen-Commit. Regional für die niedrigste Schreiblatenz wählen; Multi-Region für höhere Verfügbarkeit und globale Lesevorgänge.
Transaktionen: externe Konsistenz und vollständige ACID-Konformität über Zeilen und Tabellen hinweg; schreibgeschützte Transaktionen skalieren über Replikate.
Schemadesign: Primärschlüssel wählen, die Hotspots vermeiden; verschachtelte (interleaved) Tabellen für Lokalität verwenden; die Schreibverstärkung (Write Amplification) und das Backfill-Verhalten von sekundären Indizes berücksichtigen.
Regionalität: Die Platzierung der Leader-Region bestimmt die Schreiblatenz; Multi-Region fügt Quorum-Kosten und Commit-Latenz hinzu.

Abwägungen

Die Schreiblatenz wächst mit der geografischen Ausdehnung; Multi-Region vermeiden, es sei denn, Verfügbarkeit und globale Verteilung rechtfertigen dies.
Die Grundkosten sind höher als bei Single-Node-VM-Datenbanken; die Kapazitätsplanung muss auf SLOs und Wachstum abgestimmt sein.

Firestore, Bigtable, Memorystore und Auswahl

Firestore: Dokumentendatenbank für Mobile-/Web-Backends; starke Konsistenz für einzelne Dokumente; feingranulare Sicherheit; automatische Indizierung. Vorsicht vor Konkurrenzsituationen (Contention) bei häufig aktualisierten Dokumenten; verteilte Zähler und Batch-Schreibvorgänge verwenden.
Bigtable: Wide-Column-Datenbank im Petabyte-Maßstab für Zeitreihen und IoT mit extrem niedriger Latenz; Zeilenschlüssel (Row Keys) so gestalten, dass Hotspots vermieden werden (z. B. durch Hashing oder Salting); Skalierung über Knoten und Cluster; Multi-Cluster-Routing für Verfügbarkeit. Die Replikation ist asynchron; starke Konsistenz gilt pro Cluster.
Memorystore for Redis: In-Memory-Cache; der Basic-Tier ist eine Einzelinstanz (keine HA); der Standard-Tier bietet ein Replikat und automatisches Failover (kurze Verbindungsunterbrechungen möglich). Als Cache behandeln, nicht als „Source of Truth“; Persistenzfunktionen reduzieren die Volatilität, ersetzen aber keine Datenbank-Backups.

Workload-basierte Auswahl

Relational mit Joins/ACID und moderater Skalierung: Cloud SQL.
Global relational mit horizontaler Skalierung und externer Konsistenz: Cloud Spanner.
Zeitreihen/Telemetrie mit hohem Durchsatz oder sehr große Key-Value-Daten: Bigtable.
App-zentrierte Dokumentenmodelle mit hierarchischen Abfragen: Firestore.
Ephemere Beschleunigung und Ratenbegrenzung (Rate Limiting): Memorystore.

Analyse, Erfassung und Verarbeitung

BigQuery

Datasets: logische Grenzen für Sicherheit und Abrechnung; Namenskonventionen nach Domäne und Lebenszyklusphase einführen.
Partitionierung: nach Aufnahmezeit (Ingestion-Time) oder spaltenbasiert für zeitliche Filterung; auch Partitionierung nach Ganzzahlbereichen (Integer Range). Zeitbasierte Partitionierung für event_ts verwenden, um Scans zu reduzieren (Pruning).
Clustering: bis zu vier Spalten, um zusammengehörige Daten auf dem Speicher gemeinsam zu lokalisieren (Co-Location); verbessert die Leistung und Kosten selektiver Abfragen.
Reservations: dedizierte Slots über Reservierungen und Zuweisungen verwalten; Flex Slots für stoßweise (bursty) Experimente nutzen; kritische Workloads isolieren, um Ressourcenmangel (Starvation) zu vermeiden.
Zugriffskontrolle: IAM auf Projekt- und Dataset-Ebene; Tabellen-/Spaltenkontrolle mit zeilenbasierten Richtlinien (Row-Level Policies) und Policy Tags; kuratierte Daten über autorisierte Ansichten (Authorized Views) und Routinen teilen.

Nützliches Beispiel: bq mk –dataset myproj:analytics bq mk –table –time_partitioning_field=event_ts –clustering_fields=user_id,device_type myproj:analytics.events ./schema.json

Abwägungen und Fehlermodi

Schlechte Partitionierung führt zu vollständigen Tabellenscans und unkontrollierten Kosten.
Clustering hilft nur, wenn Filter oder Joins die geclusterten Spalten einbeziehen; häufiges Umsortieren kann den Nutzen verringern.
Unterprovisionierung von Slots führt zu Warteschlangen bei Jobs; Überprovisionierung erhöht die Kosten. Slot-Auslastung und „Spilled Shuffle“ überwachen.

Datenerfassung und -verarbeitung

Pub/Sub: globale, dauerhafte Zustellung mit „At-least-once“-Garantie; Sortierschlüssel (Ordering Keys) erzwingen eine Reihenfolge pro Schlüssel mit Kompromissen beim Durchsatz. Idempotente Consumer entwerfen.
Dataflow: einheitliche Batch- und Streaming-Verarbeitung mit Autoscaling, zustandsbehafteter „Exactly-once“-Verarbeitung, Windowing und Triggern; die Streaming Engine lagert den Zustand (State) aus. Dead-Letter-Topics und wiederabspielbare Quellen verwenden.
Dataproc: verwaltetes Spark/Hadoop für bestehenden Code und Ökosysteme; ephemere Cluster oder Autoscaling; für ML-Bibliotheken oder wenn eine Portierung kostspielig ist, verwenden.

Abwägungen: Batch vs. Streaming

Streaming reduziert die Latenz und unterstützt Echtzeit, erhöht aber die Komplexität (Zustand, Watermarking, verspätete Daten) und die laufenden Kosten.
Batch vereinfacht die Korrektheit und Kostenkontrolle; akzeptabel, wenn SLAs Verzögerungen tolerieren.
Hybride Muster: Roh-Events in Cloud Storage speichern, aggregierte KPIs zu BigQuery streamen und nächtliche Batch-Neuberechnungen zur Gewährleistung der Genauigkeit durchführen.

Warehouse-Muster

Warehouse: BigQuery als Analysesystem; materialisierte Ansichten und geplante Abfragen für die Bereitstellung von BI-Daten.
Lakehouse: Daten in Cloud Storage in offenen Formaten verwalten; über BigLake für BigQuery mit konsistenter Sicherheit bereitstellen.

Governance, Schutz und Leistung

Data-Governance und Sicherheit

Metadaten und Herkunft (Lineage): Verwenden Sie Data Catalog für technische und geschäftliche Metadaten; aktivieren Sie die Erfassung der Herkunft von Dataflow, BigQuery und Dataproc, um Abhängigkeiten nachzuverfolgen.
Qualität: Setzen Sie Regeln mit Dataplex Data Quality durch und orchestrieren Sie Prüfungen in Composer oder Dataform; stellen Sie fehlerhafte Datensätze unter Quarantäne.
Zugriffsgrenzen: VPC Service Controls um BigQuery und Cloud Storage, um das Exfiltrationsrisiko zu reduzieren; IAM Conditions für kontextsensitiven Zugriff; CMEK für kryptografische Kontrolle; Policy Tags für Einschränkungen auf Spaltenebene.
Aufbewahrung: Richten Sie die Aufbewahrung von Cloud Storage-Buckets, BigQuery Table Time Travel (konfigurierbar bis zu 7 Tage) und das Ablaufen von Datasets/Tabellen an den gesetzlichen Anforderungen aus.

Backup, PITR und Löschschutz

Backups validieren: Stellen Sie Cloud SQL- und Spanner-Backups regelmäßig in isolierten Umgebungen wieder her und führen Sie Prüfsummen sowie Validierungen auf Anwendungsebene durch.
Bigtable: Aktivieren Sie PITR, um zu einem Zeitstempel innerhalb einer konfigurierten Aufbewahrungsfrist wiederherzustellen; testen Sie Wiederherstellungen auf Tabellen- oder Cluster-Ebene.
Spanner: Nutzen Sie Backups für die Disaster Recovery; verwenden Sie Stale Reads innerhalb der Versionsaufbewahrung für Audit-Abfragen.
Cloud Storage: Aktivieren Sie Objektversionierung und Bucket Retention Lock, um sich vor versehentlichen Löschungen zu schützen; replizieren Sie in ein separates Projekt zur Isolierung von Bedienerfehlern.
BigQuery: Nutzen Sie Time Travel und Tabellen-Snapshots; vermeiden Sie das Löschen (DROP) von Produktions-Datasets durch erforderliche Genehmigungen und Löschschutz auf Dataset-Ebene.

Datenleistung und Kostenkontrolle

Hot Keys vermeiden: Verteilen Sie Bigtable-Zeilenschlüssel (Hash-Präfixe), wählen Sie Spanner-Primärschlüssel, die Leadership Elections randomisieren, und sharden Sie Firestore-Zähler.
Indizes: Pflegen Sie notwendige SQL- und NoSQL-Indizes; clustern Sie in BigQuery nach gängigen Filtern; überwachen Sie in Cloud SQL langsame Abfragen und führen Sie regelmäßig VACUUM/ANALYZE für Postgres durch.
Kapazitätsplanung: Erstellen Sie eine Baseline mit Lasttests; legen Sie SLOs und Fehlerbudgets fest; überwachen Sie die BigQuery-Slot-Auslastung, Bigtable-CPU-/Read-Modify-Write-Latenzen, Cloud SQL-CPU/IOPS und den Pub/Sub-Backlog.
Kostenkontrollen: Verwenden Sie BigQuery-Slot-Commitments für gleichbleibende Workloads, Autoclass für Cloud Storage, komprimieren Sie Bigtable-Tabellen und optimieren Sie Bloom-Filter, lassen Sie alte Partitionen und Datasets ablaufen und implementieren Sie team-spezifische Budgets und Benachrichtigungen.

Praktisches Problemszenario

Die Acme Retail Group benötigt eine einheitliche Analyseplattform für Clickstreams und Bestellungen mit niedriger Latenz. Anforderungen: Echtzeit-KPIs innerhalb von 10 Sekunden, historische Analyse über fünf Jahre mit SQL, Wiederherstellungsziele von unter einer Stunde, strikte Datenresidenz in den USA und Verhinderung von versehentlichem Datenverlust.

Roh-Events landen und eine dauerhafte Erfassung implementieren

Erstellen Sie Dual-Region us-central1/us-east1 Cloud Storage-Buckets für Roh- und kuratierte Zonen; aktivieren Sie Autoclass und Objektversionierung für die Rohdaten.
Begründung: Dual-Region erfüllt die Anforderungen an Langlebigkeit und Residenz; Versionierung schützt vor fehlerhaften Backfills; Autoclass optimiert die Speicherkosten automatisch.

Events zuverlässig mit Pub/Sub und Dataflow streamen

Veröffentlichen Sie Clickstream- und Bestell-Events in Pub/Sub-Themen mit Ordnungsschlüsseln (Ordering Keys) pro user_id; implementieren Sie eine Dataflow-Streaming-Pipeline, um die Ausgabe zu validieren, zu deduplizieren, anzureichern und an BigQuery (Hot-KPIs) und Cloud Storage (Parquet in der kuratierten Zone) zu verzweigen.
Begründung: Pub/Sub bietet eine globale, dauerhafte At-least-once-Zustellung; Dataflow bietet Exactly-once-Zustand und Autoscaling; die Verzweigung erhält ein Lakehouse-Muster für die Wiederverarbeitung.

Echtzeit-Features in Bigtable und Redis bereitstellen

Schreiben Sie eine Teilmenge der angereicherten Events in Bigtable mit einem gesalzenen Zeilenschlüssel user_id#timestamp; verwenden Sie Memorystore for Redis als Front-Cache für die neuesten Sitzungen.
Begründung: Bigtable liefert Schreibvorgänge mit niedriger Latenz und hohem Durchsatz für Zeitreihen; Salting vermeidet Hotspots; Redis reduziert die Tail-Latenz für die Live-Personalisierung.

Daten im Warehouse speichern und Abfragen in BigQuery optimieren

Erstellen Sie Datasets, die nach event_date partitioniert und nach user_id, channel geclustert sind. Verwenden Sie materialisierte Ansichten für KPIs und geplante Komprimierungen für das Laden kleiner Dateien; erwerben Sie eine Basis-Slot-Reservierung mit einem kleinen Puffer an Flex-Slots für Lastspitzen.
Begründung: Partitionierung und Clustering reduzieren Scans (Pruning) und senken die Kosten; materialisierte Ansichten beschleunigen Dashboards; Reservierungen begrenzen die Kosten und schützen kritische Workloads vor Warteschlangen.

Zugriff steuern und Exfiltration verhindern

Wenden Sie IAM auf Dataset-Ebene für Analystengruppen an; verwenden Sie Policy Tags zur Einschränkung von PII-Spalten und autorisierte Ansichten für den Zugriff durch Anbieter. Setzen Sie VPC Service Controls um BigQuery und Cloud Storage durch; verwenden Sie CMEK für regulierte Datasets.
Begründung: Least-Privilege-Prinzip auf Dataset- und Spaltenebene; VPC SC reduziert das Risiko der Datenexfiltration; CMEK erfüllt die Anforderungen an die kryptografische Kontrolle.

Backups, PITR und Wiederherstellungstests implementieren

Aktivieren Sie Bigtable PITR für 7–14 Tage; erstellen Sie wöchentliche Spanner- oder Cloud SQL-Backups für transaktionale Bestellspeicher; erstellen Sie täglich Snapshots von kritischen BigQuery-Tabellen und verlassen Sie sich bei Fehlern auf Time Travel. Führen Sie vierteljährliche Wiederherstellungsübungen in einem isolierten Projekt durch.
Begründung: Mehrschichtige Wiederherstellungsoptionen adressieren logische Fehler und Katastrophen; regelmäßige Übungen validieren RPO/RTO und Runbooks.

Datenaufbewahrung und Lebenszyklus steuern

Wenden Sie eine Lebenszyklusregel an, um Roh-Objekte nach 30 Tagen und kuratierte nach fünf Jahren zu löschen; sperren Sie eine Aufbewahrungsrichtlinie auf Bucket-Ebene, die die Compliance-Anforderungen erfüllt. Legen Sie für temporäre Datasets eine standardmäßige Ablaufzeit für BigQuery-Datasets/-Tabellen fest.
Begründung: Automatische Durchsetzung reduziert das Betriebsrisiko; eine gesperrte Aufbewahrungsrichtlinie verhindert eine versehentliche oder unautorisierte Abschwächung der Richtlinie.

Leistung und Kosten überwachen und Hotspots entschärfen

Verfolgen Sie die BigQuery-Slot-Auslastung, die gescannten Bytes und die Gleichzeitigkeit von BI-Abfragen; überwachen Sie die Bigtable-CPU- und Read-Modify-Write-Latenz; lassen Sie sich bei einem Pub/Sub-Backlog benachrichtigen. Wenn user_id-Hotspots auftreten, erhöhen Sie die Breite des Salts und aktualisieren Sie die Schlüssel per Backfill über Dataflow.
Begründung: Kontinuierliche Telemetrie findet Engpässe frühzeitig; proaktive Änderungen der Schlüsselstrategie erhalten die SLOs ohne eine komplette Neuarchitektur.

Private Konnektivität und Isolation bereitstellen

Verwenden Sie für hybride Abhängigkeiten Partner oder Dedicated Interconnect mit Cloud Router; stellen Sie nicht überlappende IP-Bereiche sicher; verwenden Sie Private Service Connect für Endpunkte von verwalteten Diensten.
Begründung: Private Pfade reduzieren Latenz und Paketverlust; eine klare IP-Planung und PSC erzwingen Isolation und vorhersagbares Routing.

Zuverlässigkeit operationalisieren

Aktivieren Sie Canary-Dataflow-Pipelines und Blue/Green-BigQuery-Ansichten; erzwingen Sie die Schema-Weiterentwicklung durch Genehmigungen im Data Catalog; integrieren Sie Dead-Letter-Queues mit dem Incident Response.
Begründung: Kontrollierte Rollouts begrenzen den Explosionsradius (Blast Radius); gesteuerte Schemaänderungen erhalten die Datenqualität; DLQs stellen sicher, dass bei Vorfällen keine Daten verloren gehen.

← Compute · Alle Domänen · Vernetzung →

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