1. Warum GCP-Diagramme zaehlen
Deine GCP-Datenplattform ist unsichtbar. Services laufen in der Cloud, Daten fliessen via APIs, Ausfaelle passieren leise. Ein gutes Diagramm macht das Unsichtbare sichtbar—zeigt Fluesse, Speicherorte und Zugriff.
Die Kosten schlechter Dokumentation
Ohne klare Diagramme suchen Teams 40% der Zeit in Cloud Console, IAM-Policies und Dataflow-Jobs. Das sind 16 Stunden pro Woche Seniorzeit fuer Archäologie.
Ein gutes GCP-Diagramm liefert drei Effekte:
Schnelleres Debugging
Wenn Daten fehlen, zeigt das Diagramm genau Bucket, Dataflow-Job und BigQuery-Tabelle. Kein Raten.
Onboarding
Neue verstehen die Plattform in 30 Minuten statt 3 Monaten. Zeig das Diagramm, nicht nur Terraform.
Security Review
Auditoren sehen IAM-Grenzen, VPC Service Controls und Datenzugriffe auf einen Blick.
Aus der Praxis
Ich kam in Teams mit Doku "schau in die Konsole". Wochen bis zum Verstehen. Teams mit klaren Diagrammen? Produktiv am ersten Tag. Doku ist keine Last—sie ist Speed.
2. Zentrale GCP-Datenservices
GCP hat 100+ Services, aber moderne Plattformen nutzen einen Kern von 8-12. So funktionieren sie und so setzt du sie im Diagramm ein.
Cloud Storage
StorageObjektspeicher fuer den Data Lake. Haelt rohe, verarbeitete und kuratierte Daten in jeder Groesse.
Nutze wenn: du Daten jeder Menge speichern musst. Organisiere mit Prefixen: gs://bucket/raw/, processed/, curated/
BigQuery
WarehouseServerloses, skalierendes Warehouse. Schnelle SQL-Queries, ML-Integration, kein Cluster-Management.
Nutze wenn: aktive Analytics, BI-Dashboards, ML-Training. Lade Daten fuer Performance nach BigQuery, nutze externe Tabellen fuer Flexibilitaet.
Dataflow
Stream + BatchVereinigt Stream- und Batch-Processing auf Basis Apache Beam. Autoscaling, serverlos.
Nutze wenn: Streaming, Fensterlogik, komplexe Transformationen. Einmal Beam-Code, als Stream oder Batch ausfuehren.
Pub/Sub
MessagingMessaging fuer Event-Architekturen. Entkoppelt Producer und Consumer, garantiert Zustellung.
Nutze wenn: Real-time-Ingestion, Event-Streams, Microservices-Kommunikation. Paart mit Dataflow fuer Stream-Processing.
Cloud Composer
OrchestrierungManaged Airflow fuer Workflows. Plane und ueberwache Pipelines als DAGs.
Nutze wenn: komplexe Abhaengigkeiten, Batch-Jobs mit Zeitplan, Koordination vieler Services.
Dataproc
Spark/HadoopManaged Spark/Hadoop-Cluster. Schnelle Provisionierung, integriert mit Cloud Storage.
Nutze wenn: vorhandene Spark-Jobs, komplexe ML-Workloads oder Dataflow nicht passt. Oft guenstiger fuer lange Batch-Jobs.
| Service | Kategorie | Haupt-Use-Case | Preismodell |
|---|---|---|---|
| Cloud Storage | Storage | Data Lake, Archive | Pro GB |
| BigQuery | Warehouse | Analytics, BI, ML | Pro TB Scan |
| Dataflow | Processing | ETL, Streaming | Pro vCPU-Stunde |
| Pub/Sub | Messaging | Event Streaming | Pro GB |
| Cloud Composer | Orchestrierung | Workflow Mgmt | Pro Environment |
| Dataproc | Processing | Spark/Hadoop | Pro vCPU-Stunde |
3. Haeufige GCP-Architektur-Patterns
Die meisten GCP-Plattformen folgen einem dieser erprobten Muster. Waehle nach Latenz, Datenvolumen und Team-Skills.
Pattern 1: BigQuery-zentriert (Standard)
Einfach, guenstig, serverloses Analytics
Am besten fuer:
- • die meisten Analytics-Workloads
- • Teams ohne Spark-Know-how
- • budgetsensitive Projekte
- • schnellen Start
Kernservices:
- • Cloud Storage (roh)
- • BigQuery (Warehouse)
- • Cloud Functions (leichte ETL)
- • Cloud Scheduler (Orchestrierung)
Pro: Minimaler Ops-Aufwand. BigQuery handled Scaling, Optimierung und Backups. Kosteneffizient bei <1TB pro Tag.
Pattern 2: Streaming mit Dataflow
Echtzeit fuer Event-Systeme
Am besten fuer:
- • Real-time Dashboards
- • Event-getriebene Architekturen
- • IoT/Sensor-Daten
- • Fenster- und Aggregationslogik
Kernservices:
- • Pub/Sub (Ingestion)
- • Dataflow (Transformation)
- • BigQuery (Serving)
- • Cloud Monitoring (Observability)
Pro: Sehr niedrige Latenz, ein Code fuer Batch und Streaming, auto-scaling.
Pattern 3: Data Lake mit Medaillon
Mehrzonen-Speicher fuer grosse Batch-Lasten
Am besten fuer:
- • grosse Batch-Verarbeitung
- • vorhandene Spark-Pipelines
- • komplexes Feature Engineering
- • Kostenoptimierung bei Volumen
Layer:
- • Bronze: roh, unveraenderlich
- • Silver: bereinigt, konform
- • Gold: business-ready
- • BigQuery: Query-Layer
Note: Mehr Ops-Aufwand. Nutze Dataflow, wenn kein Spark-Know-how oder Streaming noetig ist.
Pattern 4: Modern Data Stack mit dbt
ELT mit Transformation im Warehouse
Am besten fuer:
- • SaaS-Datenintegration
- • Analytics-Engineering-Teams
- • SQL-first Transformationen
- • versionierte Modelle
Kern-Tools:
- • Fivetran (EL-Connectoren)
- • dbt (Transformation)
- • BigQuery (Compute + Storage)
- • Looker (BI)
Pro: Schneller Start, ideal fuer Analytics-Teams. Kein Infra-Management. Versionierung fuer Transformationen.
Pattern waehlen
Starte mit Pattern 1 (BigQuery-zentriert), ausser besondere Anforderungen. Es ist am einfachsten, kosteneffizient und ops-light. Fuege Dataflow, Dataproc, dbt hinzu, wenn Streaming, Spark oder komplexe Logik noetig sind.
4. Design-Prozess Schritt fuer Schritt
So entwirfst du ein GCP-Architekturdiagramm, das dem Team wirklich hilft.
Datenquellen mappen
Liste alle Quellen. Sei konkret: API, DB-Replikation, File-Drop oder Event-Stream?
Beispiele:
- • PostgreSQL (Cloud SQL) - Replikation via Datastream
- • Salesforce API - stündlich via Cloud Functions
- • Web Events - Streaming via Pub/Sub
- • CSV-Files - Drop in Cloud-Storage-Bucket
Ingestion-Layer definieren
Wie kommen Daten nach GCP? Passe Methode an die Quelle an.
Entscheidungsbaum:
- • Real-time Events? → Pub/Sub
- • API Polling? → Cloud Functions + Scheduler
- • DB-Replikation? → Datastream
- • SaaS-Connectoren? → Fivetran/Airbyte
Storage-Layer bauen
Strukturiere Cloud-Storage-Buckets nach Reifegrad. Nenne Bucket-Namen im Diagramm.
Bucket-Struktur:
- • gs://company-data-raw/ - unveraendert
- • gs://company-data-staging/ - Zwischenstufe
- • gs://company-data-curated/ - analytics-ready
- • gs://company-data-archive/ - Archiv
Transformation modellieren
Zeige, wie Daten bereinigt, gejoint, aggregiert werden. Inkludiere Jobnamen und Zeitplan.
Optionen:
- • BigQuery Scheduled Queries - einfache SQL-Transformation
- • Dataflow Jobs - komplex/Streaming
- • dbt-Modelle - versionierte SQL
- • Dataproc Jobs - Spark/PySpark
Serving-Layer definieren
Wo konsumieren Nutzer Daten? Nenne Datasets und Tabellennamen.
BigQuery-Datasets:
- • project.raw_data - Quellkopien
- • project.staging - Zwischenmodelle
- • project.analytics - BI-ready
- • project.ml_features - Training
Orchestrierung & Monitoring
Zeige Scheduling und Monitoring. Wo gehen Alerts hin?
Bausteine:
- • Cloud Composer DAGs fuer komplexe Workflows
- • Cloud Scheduler fuer einfache Cron-Jobs
- • Cloud Monitoring fuer Metriken & Alerts
- • Cloud Logging fuer Debugging
Zugriffsmuster dokumentieren
Zeige, wer Daten konsumiert und wie. Inkludiere Service Accounts und IAM-Rollen, wo relevant.
Konsumententypen:
- • Looker/Data Studio Dashboards
- • ML-Modelle (Vertex AI)
- • Reverse ETL in operative Systeme
- • Data APIs fuer Apps
5. Diagramm Best Practices
Ein Diagramm hilft nur, wenn es genutzt wird. Diese Prinzipien halten es nuetzlich.
Echte Ressourcennamen
Schreib nicht "BigQuery Dataset". Schreib "analytics_prod", damit es in der Console auffindbar ist.
❌ Cloud Storage Bucket
Flussrichtung zeigen
Pfeile sind wichtig. Zeige klar, wohin Daten gehen.
Zeitplaene dazu
Annotiere Batch-Jobs mit Cron. "Taeglich 2 Uhr" oder "alle 15 Min" setzt Erwartung.
Nach Layern strukturieren
Gruppiere nach Ingestion, Storage, Transformation, Serving. So ist es scanbar.
Kritische Pfade markieren
Markiere Pipelines fuer Executive-Dashboards. Wenn sie fallen, merken es alle.
Versionieren
Datumiere Diagramme. `Update Dez $2026` zeigt Frische.
Haeufige Fehler
- • Generische Labels statt echter Namen
- • Jedes Table zeigen—fokussiere auf Fluesse
- • Logische und physische Ebenen mischen
- • Nicht aktualisieren nach Infra-Aenderung
Aus der Praxis
Die besten Diagramme werden im Incident geoeffnet. Wenn das Team beim Debuggen dein Diagramm nutzt, passt es. Wenn es sofort die Console oeffnet, braucht das Diagramm mehr Detail.
6. Tools fuer GCP-Diagramme
| Tool | Am besten fuer | GCP-Icons | Collaboration | Preis |
|---|---|---|---|---|
| Datadef | Data-spezifische Diagramme | ✅ Built-in | ✅ Echtzeit | Free Tier |
| Lucidchart | Allgemeine Architektur | ✅ Offizielle Library | ✅ Stark | $7.95/Monat |
| Draw.io | Einfache Diagramme | ✅ Import Library | ⚠️ Basic | Free |
| Miro | Workshops | ⚠️ Manuell | ✅ Teamfreundlich | $8/Monat |
| Google Slides | Schnelle Skizzen | ❌ Keine | ✅ Sharing | Free |
Offizielle GCP-Icons
Google stellt Icon-Sets fuer Architekturdiagramme bereit. Konsistente Icons sind sofort erkennbar.
GCP Icons downloaden →Diagram-as-Code
Fuer Teams, die Code bevorzugen, generiert die Diagrams-Python-Library Architektur aus Code.
Diagrams Library ansehen →7. GCP Diagramm-Checklist
Datenquellen klar benannt
Systemname, Frequenz, Methode (API, Pub/Sub, File Drop).
Ingestion-Layer zeigt Methode
Pub/Sub fuer Streaming, Cloud Functions fuer Polling, Datastream fuer Replikation.
Storage-Layer nutzt echte Bucket-Namen
gs://company-data-raw statt "Cloud Storage Bucket".
Transformationen mit Zeitplan
Dataflow stuendlich, dbt taeglich 3 Uhr—Cadence sichtbar.
BigQuery-Datasets benannt
project.raw_data, project.analytics—nicht nur "BigQuery".
Flussrichtung eindeutig
Klare Pfeile Quelle → Transformation → Ziel.
IAM-Grenzen sichtbar
Welche Service Accounts greifen wo zu.
Monitoring & Alerts drin
Logs? Alerts? Cloud Monitoring nennen.
Kritische Pfade markiert
Pipelines fuer Executive-Dashboards hervorgehoben.
Diagramm datiert/versioniert
Last updated: Dez 2026. In Git.
Pro Tip
Der "New Hire Test"
Zeig das Diagramm einer neuen Person und frage: "Wo wuerdest du schauen, wenn dieses Dashboard keine Daten bekommt?" Antwort in 30 Sekunden = gut. Rueckfragen = mehr Detail.
8. Haeufige Fragen
Welche Kern-Services braucht eine GCP-Datenplattform?
Cloud Storage, BigQuery, Dataflow, Pub/Sub, Cloud Composer, Dataproc und Data Catalog.
Was ist die Medaillon-Architektur in GCP?
Bronze (roh) → Silver (bereinigt) → Gold (aggregiert) in Cloud Storage, bewegt durch Dataflow/Dataproc, Analytics in BigQuery.
Cloud Storage oder BigQuery?
Cloud Storage fuer Rohdaten/Archive; BigQuery fuer aktive Analytics. Typisch: Ingest nach Storage → transformieren → nach BigQuery laden.
Wie dokumentiere ich Datenfluss in GCP?
Zeige Quelle → Ingestion (Pub/Sub/Cloud Functions/Dataflow) → Storage (Buckets pro Zone) → Transformation (Dataflow/Dataproc) → Serving (BigQuery) → Konsumenten (Looker/Data Studio/ML). Mit Bucket-Namen, Dataset-IDs, Jobdetails.
Dataflow oder Dataproc?
Dataflow fuer Streaming, Beam-Code, weniger Ops. Dataproc fuer vorhandene Spark-Jobs, volle Cluster-Kontrolle, lange Batch-Lasten. Dataflow einfacher, Dataproc oft guenstiger bei grossen Batch-Jobs.
Wie oft Diagramm aktualisieren?
Bei jedem Service-Zuwachs, Flow-Aenderung oder kritischer Pipeline-Aenderung. Quartalsweise Review, in Git mit Terraform lagern.
Baue dein GCP Data Platform Diagramm
Erstelle klare Diagramme deiner GCP-Datenplattform mit BigQuery, Cloud Storage, Dataflow und allen Kernservices. Minuten statt Stunden.