← Learning Hub Lektion 10 Dauer: ca. 14 Min. Thema: Produktionsbetrieb

Kosten, Performance & Betrieb

Diese abschließende Lektion behandelt die betriebliche Realität: Cloud-Ausgaben im Griff behalten, die Performance von Delta-Tabellen optimieren, Cluster effizient dimensionieren und Runbooks für deine produktive Wetter-zu-Strom-Plattform etablieren. Als Tech Lead trägst du die Verantwortung für Kostentransparenz und operative Gesundheit.

Kostenmodell — wohin das Geld fließt

Databricks-Kosten bestehen aus zwei Bestandteilen: Compute (DBUs) und Cloud-Infrastruktur (VMs + Storage).^[1]

Bestandteil	Kostentreiber	Deine Pipeline
Job-Cluster (DBUs)	VM-Größe × Stunden × DBU-Rate	ca. 0,5–2 h Compute pro Tag über 4 Läufe. Die wichtigste Kostenstelle.
SQL Warehouse	Warehouse-Größe × aktive Stunden	Analysten-Abfragen + nachgelagerte Lesezugriffe. Serverless skaliert auf null.
Storage	Gespeicherte GB (Cloud-Blob-Preise)	Delta-Tabellen + Checkpoints. Wächst mit der Aufbewahrungsrichtlinie.
Netzwerk	Egress (Daten, die die Region verlassen)	Gering, außer du bedienst Konsumenten in anderen Regionen.

Geschätzte Monatskosten (illustrativ)

Workload	Konfiguration	Laufzeit pro Tag	Kosten/Monat ca.
Ingestion (4× täglich)	Single-Node E4s (0,5 DBU/h)	4 × 10 Min. = 40 Min.	ca. 50–80 $
Silver-Transformationen (4×)	2 Worker D4s (1,5 DBU/h)	4 × 8 Min. = 32 Min.	ca. 60–100 $
Features + ML-Inferenz (4×)	1 Worker E8s (2 DBU/h)	4 × 5 Min. = 20 Min.	ca. 40–70 $
SQL Warehouse (Analysten)	Serverless, Small	ca. 2 h aktive Abfragen/Tag	ca. 100–200 $
Storage (Delta-Tabellen)	ca. 500 GB, wachsend	—	ca. 10–25 $
Gesamtschätzung			ca. 260–475 $/Monat

Das sind grobe Schätzungen für eine Flotte mittlerer Größe (ca. 50 Turbinen, 10 Parks, Region Europa). Die tatsächlichen Kosten hängen vom Cloud-Anbieter, der DBU-Stufe (Premium vs. Standard) und den Datenmengen ab.

Kostenhebel (größte Wirkung zuerst)

Cluster-Dimensionierung: Nicht überdimensionieren. Single-Node für I/O-Aufgaben, minimale Worker-Zahl für Transformationen.
Job-Cluster statt All-Purpose: Job-Cluster beenden sich nach dem Job. All-Purpose-Cluster kosten rund um die Uhr.
Spot-Instanzen: Für fehlertolerante Worker-Nodes (Transformationen, Features). 60–80 % Ersparnis.
Serverless SQL: Skaliert auf null, wenn nicht abgefragt wird. Keine Leerlaufkosten für Analysten-Workloads.
Datenaufbewahrung: Alte Bronze-Daten per VACUUM räumen. Partitionen jenseits des Aufbewahrungsfensters löschen.

Optimierung von Delta-Tabellen

Delta-Tabellen sammeln mit der Zeit viele kleine Dateien an (durch häufige Appends). Unbeachtet verschlechtert das die Lese-Performance.

OPTIMIZE — kleine Dateien zusammenfassen

-- Wöchentlich ausführen (oder Auto-Optimize übernehmen lassen)
OPTIMIZE prod.silver.weather_ts;
OPTIMIZE prod.silver.power_ts;
OPTIMIZE prod.gold.forecast_ts;

-- Mit Z-ORDER für Performance bei Zeitraum-Abfragen
OPTIMIZE prod.silver.weather_ts ZORDER BY (timestamp);
OPTIMIZE prod.silver.power_ts ZORDER BY (timestamp);

VACUUM — alte Dateiversionen löschen

-- Dateien älter als der Aufbewahrungszeitraum entfernen (Standard: 7 Tage)
-- Nach VACUUM ist Time Travel zu diesen Versionen nicht mehr möglich
VACUUM prod.bronze.weather_raw RETAIN 30 DAYS;
VACUUM prod.silver.weather_ts RETAIN 14 DAYS;
VACUUM prod.gold.forecast_ts RETAIN 7 DAYS;

Auto-Optimize (in Produktion zu bevorzugen)

-- Beim Anlegen der Tabelle aktivieren (in unseren Schemas bereits enthalten):
TBLPROPERTIES (
  'delta.autoOptimize.optimizeWrite' = 'true',  -- größere Dateien schreiben
  'delta.autoOptimize.autoCompact'   = 'true'   -- kleine Dateien kompaktieren
);

-- Das reduziert den Bedarf an manuellem OPTIMIZE, aber Z-ORDER braucht
-- weiterhin regelmäßige explizite OPTIMIZE-Läufe (Auto-Compact macht kein Z-ORDER).

Wartungsaufgabe	Frequenz	Vorgehen
OPTIMIZE + ZORDER	Wöchentlich	Geplanter Wartungs-Job
VACUUM	Wöchentlich	Derselbe Wartungs-Job
ANALYZE TABLE (Statistiken)	Nach großen Ladevorgängen	Verbessert die Query-Planung
Alte Bronze-Partitionen löschen	Monatlich	Durchsetzung der Aufbewahrungsrichtlinie

Leitfaden zur Cluster-Dimensionierung

Aufgabe	Engpass	Passende Größe
GRIB-Download + Parsing	Netzwerk-I/O, Single-Thread-Python (cfgrib)	Single-Node, speicheroptimiert (16 GB+ RAM)
Bronze → Silver (Geo-Join)	Spark-Shuffle für den Join (Broadcast eliminiert ihn)	2–4 Worker, General Purpose. dim_assets broadcasten.
Feature-Berechnung	Window-Funktionen (partitioniert nach Anlage)	2–4 Worker. Daten sind nach asset_id partitioniert = natürliche Parallelität.
ML-Inferenz	Modell-Vorhersage (CPU-gebunden, pandas UDF)	1–2 Worker, ML Runtime. Oder Single-Node bei leichtem Modell (LightGBM).
Gold-Write + Aggregation	Kaum vorhanden — geringes Ausgabevolumen	Teilt sich das Transform-Cluster (Wiederverwendung).

Prinzip der richtigen Dimensionierung

Klein anfangen, messen, und erst hochskalieren, wenn Tasks zu langsam sind. Ein Single-Node-Cluster für die Ingestion und ein Cluster mit 2 Workern für die Transformationen reichen für eine Flotte von 50–200 Turbinen sehr wahrscheinlich aus. Das Cluster beendet sich nach dem Job automatisch — Überdimensionierung kostet dich pro Minute, nicht pro Monat.

Aufbewahrungsrichtlinie für Daten

-- Bronze: Rohwetterdaten für Reprocessing aufbewahren (30–90 Tage)
-- Danach ist Silver die maßgebliche Wahrheit
ALTER TABLE prod.bronze.weather_raw
SET TBLPROPERTIES ('delta.deletedFileRetentionDuration' = '30 days');

-- Silver: unbegrenzt aufbewahren (zentrales analytisches Asset)
-- VACUUM entfernt nur Dateiversionen, keine logischen Daten

-- Gold: Prognosehistorie für Genauigkeits-Tracking behalten (1–2 Jahre)
-- Ältere Prognosen können bei Bedarf in Cold Storage archiviert werden

Schicht	Aufbewahrung	Begründung
Bronze	30–90 Tage	Reprocessing-Fenster. Danach ist Silver die Wahrheit.
Silver	Unbegrenzt (2+ Jahre)	Zentrales analytisches Asset. ML-Training braucht Historie.
Gold	1–2 Jahre	Tracking der Prognosegüte. Regulatorisch, falls einschlägig.
Features	Wie Silver	Training braucht Feature-Historie passend zu den Labels.

Operatives Runbook

Störung: Pipeline-Fehler (Ingestion)

Prüfen: Welche Quelle ist ausgefallen? (Workflow-Run-UI → fehlgeschlagener Task)
Diagnostizieren: API-Timeout? Auth-Fehler? Quelle offline? (Logs prüfen)
Handeln: Bei transientem Fehler → manueller Retry. Bei Quellenausfall → warten, Freshness-SLA prüfen.
Kommunizieren: Bei SLA-Verletzung → nachgelagerte Nutzer informieren (der Handelstisch arbeitet sonst mit veralteter Prognose).

Störung: Nachlassende Modellgenauigkeit

Erkennen: Die Tabelle forecast_accuracy zeigt über 7 Tage steigenden MAE.
Diagnostizieren: Saisonaler Wechsel? Anlagenänderung (neue Turbine)? Update des Wettermodells stromaufwärts?
Handeln: Modell auf aktuellen Daten neu trainieren. Challenger validieren. Bei Verbesserung promoten.
Vorbeugen: Automatisiertes Retraining einplanen (monatlich oder bei erkanntem Drift).

Störung: Langsame Pipeline (Laufzeit-Alarm)

Prüfen: Welcher Task ist langsam? (Zeitleisten-Ansicht des Workflows)
Diagnostizieren: Datenmengen-Spitze? Cluster zu klein? Kleine Dateien (OPTIMIZE nötig)?
Handeln: OPTIMIZE ausführen bei Small-File-Problem. Cluster skalieren, wenn die Datenmenge gewachsen ist. Fehlendes Partition Pruning ergänzen.

Monitoring-Dashboard

Kennzahlen, die auf ein operatives Dashboard gehören (Databricks SQL Dashboard oder extern):

Kennzahl	Quelle	Alarmschwelle
Erfolgsquote der Pipeline	Workflow-Run-Historie	< 95 % über 7 Tage
Pipeline-Laufzeit	Workflow-Run-Historie	> 2× Median
Aktualität von Gold	`MAX(produced_at)` in forecast_ts	> 2 Stunden alt
Prognose-MAE (7-Tage-Rolling)	Tabelle forecast_accuracy	> 20 % über Baseline
Park-Abdeckung	DISTINCT Parks im letzten Gold-Batch	< 100 % der erwarteten Parks
Täglicher DBU-Verbrauch	Databricks Billing API / Account Console	> 2× Tagesbudget
Wachstumsrate des Storage	DESCRIBE DETAIL auf den Tabellen	> 10 % Woche-über-Woche unerwartetes Wachstum

Verständnis prüfen

Die Abfrage-Performance deiner Silver-Tabelle weather_ts hat sich im letzten Monat verschlechtert. Die Tabelle erhält täglich 4 Appends. Wahrscheinlichste Ursache?

Unity Catalog prüft Berechtigungen und verlängert dadurch jede einzelne Abfrage
Das Z-ORDER wurde durch Schema-Evolution in Delta Lake ungültig gemacht
Viele kleine Dateien durch häufige Appends — OPTIMIZE muss sie kompaktieren
Das SQL Warehouse hat automatisch herunterskaliert und muss manuell vergrößert werden

Richtig. Jeder Append erzeugt neue kleine Dateien. Über einen Monat sammeln sich Hunderte davon an. Spark muss jeden Datei-Header öffnen und lesen, was die Scan-Performance verschlechtert. OPTIMIZE fasst sie zu wenigen großen Dateien zusammen. Auto-Compact hilft, aber periodisches explizites OPTIMIZE + ZORDER bleibt nötig.

Die Ansammlung kleiner Dateien ist das klassische Symptom. 4 Appends/Tag × 30 Tage = über 120 kleine Dateien pro Partition. Der Overhead durch das Auflisten der Dateien wird spürbar. OPTIMIZE (Kompaktierung) + ZORDER (Data Skipping) stellen die Performance wieder her.

Du willst die Compute-Kosten der Ingestion-Tasks senken. Welche Änderung hat die größte Wirkung?

Auf einen größeren VM-Typ wechseln, damit die Parsing-Jobs schneller fertig werden
Mehr Worker-Nodes ergänzen, um das Parsen der GRIB2-Dateien zu parallelisieren
Single-Node bestätigen, denn cfgrib läuft ausschließlich im Prozess des Drivers
Von Job-Clustern auf ein dauerhaft laufendes All-Purpose-Cluster zur Wiederverwendung wechseln

Genau. cfgrib/xarray parsen im Python-Prozess des Drivers — die Worker-Nodes stehen während der Ingestion komplett still. Sie zu entfernen (Single-Node-Modus) beseitigt verschwendetes Compute. Ein dauerhaft laufendes Cluster wäre erheblich teurer (Abrechnung rund um die Uhr statt Minuten pro Lauf).

Single-Node ist die Antwort. cfgrib läuft im Python-Prozess des Drivers und lässt sich nicht auf Worker verteilen. Für leerlaufende Worker zu bezahlen ist reine Verschwendung. Und für Batch-Jobs niemals dauerhaft laufende Cluster nutzen — Job-Cluster beenden sich nach dem Lauf.

Bronze-Wetterdaten werden 30 Tage aufbewahrt. Was passiert nach 30 Tagen, wenn du ältere Daten neu verarbeiten musst?

Delta Time Travel holt die Daten trotz abgelaufener Retention aus dem Transaktionslog
Die Daten sind endgültig verloren und aus keiner Databricks-Quelle mehr wiederherstellbar
Silver wird zur Wahrheit — von dort neu rechnen oder erneut von der Quelle laden
VACUUM archiviert alte Bronze-Daten automatisch im Cold Storage für den späteren Zugriff

Richtig. Nachdem VACUUM alte Bronze-Dateien entfernt hat, sind diese Rohdaten aus Databricks verschwunden. Silver (unbegrenzt aufbewahrt) wird zur maßgeblichen Wahrheit. Wenn du wirklich von Grund auf neu verarbeiten musst, lade erneut von der ursprünglichen Wetter-API (ECMWF archiviert Daten über Jahre). Genau deshalb ist die Silver-Aufbewahrung länger.

Nach VACUUM sind Bronze-Daten jenseits der Aufbewahrungsfrist weg. Silver ist deine dauerhafte Wahrheit (unbegrenzt aufbewahrt). Brauchst du die Originalrohdaten erneut, lädst du sie über die Archiv-API des Wetteranbieters nach. VACUUM archiviert nicht — es löscht endgültig.

Primärquelle

📖 Empfohlene Lektüre

Best Practices zur Optimierung von Delta-Lake-Tabellen — behandelt OPTIMIZE, VACUUM, Z-ORDER, Auto-Optimize und Dateiverwaltung. Siehe außerdem Best Practices zur Cluster-Konfiguration für Hinweise zur richtigen Dimensionierung.

Kurszusammenfassung

Du hast jetzt die komplette Databricks-Architektur von Wetter zu Strom durchlaufen:

Lakehouse-Architektur — das mentale Modell
Asset-Hierarchie & Zeitreihen — Tabellendesign
Wetterdaten-Ingestion — GRIB2, APIs, Bronze
Bronze → Silver — Geo-Join, Ableitung, Versionierung
Unity Catalog — Governance und Zugriffssteuerung
Feature Engineering — Feature Store, Point-in-Time
ML-Pipeline — MLflow, Model Registry, Inferenz
Gold-Layer — Bereitstellung nach unten, Konfidenzintervalle
Workflows — Orchestrierung, Zeitpläne, Alarmierung
Kosten & Betrieb — diese Lektion

Wie es weitergeht

Baue einen Prototyp der Pipeline in einem Databricks Workspace (starte mit einer kostenlosen Testversion oder einer Dev-Umgebung)
Lade Beispiel-Wetterdaten von Open-Meteo und implementiere die Bronze-Ingestion
Lege die Unity-Catalog-Struktur (prod/dev/sandbox) früh an — nachträglich ist das deutlich mühsamer
Absolviere den Pfad „Data Engineer Associate“ der Databricks Academy für praktische Labs

← Zurück: Workflows Referenz: Architektur-Spickzettel →

Du hast den Grundlagenkurs abgeschlossen. Bitte deinen Lehrer, ein Thema zu vertiefen, praktische Übungen zu erstellen oder fortgeschrittene Themen zu erkunden (Streaming, Echtzeit-Inferenz, Ensembles aus mehreren Modellen).

Rechtliches: Impressum