← Learning Hub Lektion 1 Dauer: ca. 12 Min. Thema: Plattform-Architektur

Das Lakehouse: Databricks auf Wetter-zu-Strom abbilden

Diese Lektion gibt dir das mentale Modell, das du für architektonische Entscheidungen auf Databricks brauchst. Am Ende kannst du skizzieren, wie Wetterdaten durch die Plattform fließen und zu einer Stromprognose werden — und du kannst die Databricks-Komponenten benennen, die für jede Stufe zuständig sind.

Dein Domänenmodell

Bevor wir in Databricks einsteigen, halten wir die Domäne fest, die du modellierst. Jede Architekturentscheidung lässt sich hierauf zurückführen:

Zentrale Domänenbegriffe

Asset-Hierarchie: Ein Windpark ist ein Asset mit einer Geo-Position. Er enthält Turbinen (Sub-Assets). Du brauchst Prognosen auf beiden Ebenen — einzelne Turbine und aggregierter Park.
Räumliche Zuordnung: Wettermodelle liefern Gitterdaten (z. B. 0,25° Auflösung). Du bildest Gitterzellen auf Asset-Standorte ab, um standortspezifisches Wetter zu erhalten.
Zeitreihen überall: Wettervariablen, Stromerzeugung und Telemetrie sind allesamt Zeitreihen — zeitgestempelte Sequenzen, geschlüsselt nach Asset oder Turbine.
Dualer Zugriff: Dieselben Zeitreihendaten müssen für Ad-hoc-Analysen abfragbar sein (Data Scientists, die Muster erkunden) und durch die Produktions-Pipeline fließen (geplante Prognosen für den Handelstisch).

Das Lakehouse-Konzept

Databricks basiert auf der Lakehouse-Architektur — einer einzigen Plattform, die den günstigen, skalierbaren Speicher eines Data Lake mit der Zuverlässigkeit und Performance eines Data Warehouse verbindet. Du musst dich nicht mehr für eines von beiden entscheiden.^[1]

Kernerkenntnis Das Lakehouse beseitigt das „Zwei-System"-Problem. Wetterdaten (groß, semistrukturiert, hochfrequent) und Stromprognosen (strukturiert, abfrageoptimiert) liegen auf derselben Plattform und werden vom selben Catalog governt. Entscheidend: Zeitreihendaten, die einmal in Delta-Tabellen liegen, sind sowohl für Produktions-Pipelines (Workflows/Jobs) als auch für Ad-hoc-Analysten (SQL Warehouses/Notebooks) zugänglich — ganz ohne Duplizierung.

Drei Eigenschaften machen das möglich:

Delta Lake — eine offene Speicherschicht, die ACID-Transaktionen, Schema-Enforcement und Time Travel zu Parquet-Dateien auf Cloud-Objektspeicher (ADLS, S3, GCS) hinzufügt.^[2]
Unity Catalog — eine einheitliche Governance-Schicht für Daten, ML-Modelle und Code. Ein Ort, um Zugriffsrechte zu definieren und Lineage zu verfolgen.
Trennung von Compute — Speicher und Rechenleistung sind entkoppelt. Du skalierst Cluster unabhängig von deinem Datenvolumen.

Die Medaillon-Architektur

Das Standardmuster zur Organisation von Daten im Lakehouse ist die Medaillon-Architektur: drei Schichten (Bronze → Silver → Gold), die Rohdaten schrittweise zu fachlich nutzbaren Assets veredeln.^[3]

Warum das für dein Team zählt

Schicht	Deine Daten	Architektonischer Fokus
Bronze	Rohe NWP-Dateien (ECMWF, GFS), SCADA-Feeds je Turbine, Asset-Register (Parks + Turbinen + Standorte)	Zuverlässige Ingestion, Schema-on-Read, kein Datenverlust, Erhalt der rohen Gitterstruktur
Silver	Wetter-Zeitreihen, auf Asset-Geopositionen abgebildet, Telemetrie je Turbine (UTC-ausgerichtet), Aggregate auf Parkebene	Geo-räumlicher Join (Gitter → Asset), Ausrichtung der Zeitreihen, Modellierung der Asset-Hierarchie, dualer Zugriff (Analyse + Pipeline)
Gold	Stromprognosen je Turbine & je Park, Konfidenzintervalle, Metriken zur Modellgenauigkeit	SLA, Latenz, Granularität (Turbine vs. Park), Bereitstellung an Handels- und Fahrplansysteme

Databricks-Komponenten — die Entscheidungskarte

Als Tech Lead wählst du aus diesen Bausteinen. So bilden sie sich auf Wetter-zu-Strom ab:

Komponente	Was sie leistet	Dein Anwendungsfall
Delta Lake	ACID-Speicherschicht auf Objektspeicher	Alle Tabellen sind Delta. Time Travel reproduziert jede Prognose. Gleichzeitige Lesevorgänge (Analysten) und Schreibvorgänge (Pipeline) sind sicher.
Unity Catalog	Governance: Zugriffskontrolle, Lineage, Auffindbarkeit	Getrennte Catalogs für Dev/Prod. Nachvollziehen, welches Wettermodell + welche Asset-Version welche Prognose erzeugt hat. Asset-Hierarchie als Managed Tables.
Workflows (Jobs)	Orchestrierung mehrstufiger Pipelines	Geplante Pipeline: Wetter einlesen → geografisch auf Assets abbilden → Features bauen → Modell je Park ausführen → Prognose veröffentlichen.
Delta Live Tables	Deklaratives ETL mit eingebauten Qualitätsprüfungen	Erwartungen an Zeitreihen (z. B. „Windgeschwindigkeit ≥ 0", „keine Lücken > 1 h"). Qualitäts-Gates vor der ML-Nutzung.
MLflow	ML-Lebenszyklus: Tracking, Registry, Serving	Experimente je Asset-Typ verfolgen. Champion-Modell registrieren. Vorhersagen je Turbine oder je Park ausliefern.
Cluster	Verwaltetes Spark-Compute	Job-Cluster (kurzlebig) für Pipeline-Läufe. Interaktive Cluster für Data Scientists, die Zeitreihen erkunden.
SQL Warehouses	Serverless SQL-Compute	Analysten fragen Silver-/Gold-Zeitreihen ab. Dashboards zur Prognosegüte je Park. Der „Analyse"-Zugriffspfad.

Das Gesamtbild

So fließt ein einzelner Prognosezyklus durch Databricks:

Dualer Zugriff — die Architektur, die beide Pfade bedient Die Zeitreihentabellen der Silver-Schicht (Wetter je Asset, Telemetrie je Turbine) sind die einzige Quelle der Wahrheit. Die Produktions-Pipeline liest sie nach Zeitplan, um Prognosen zu erzeugen. Analysten fragen dieselben Tabellen interaktiv über SQL Warehouses oder Notebooks ab. Delta Lake macht das sicher: gleichzeitige Lesevorgänge blockieren nie Schreibvorgänge, und mit Time Travel können Analysten sich auf einen konsistenten Snapshot festlegen, ohne die Aktualität der Pipeline zu stören.

Deine erste Architekturentscheidung

Als Tech Lead triffst du sehr früh diese Entscheidung: Delta Live Tables (DLT) oder eigene Spark-Jobs, orchestriert über Workflows?

Kriterium	Delta Live Tables	Eigene Spark-Jobs + Workflows
Einrichtungsaufwand	Geringer — deklaratives SQL/Python	Höher — imperativer Code
Datenqualität	Eingebaute Expectations	Du schreibst die Validierungslogik
Flexibilität	Auf DLT-Muster beschränkt	Volle Kontrolle
Kostentransparenz	Undurchsichtig (Enhanced-Tier-Preise)	Transparente Cluster-Kosten
Komplexe Logik	Schwieriger bei eigenen Dateiformaten	Einfach — schlichter Spark-Code

Empfehlung für Wetter-zu-Strom Wetterdaten kommen in Spezialformaten (GRIB2, NetCDF), die eigene Parsing-Bibliotheken benötigen (cfgrib, xarray). Das spricht bei der Bronze-Ingestion für eigene Spark-Jobs. Silver-/Gold-Transformationen — größtenteils in SQL ausdrückbar — profitieren dagegen von den deklarativen Qualitätsprüfungen in DLT. Ein hybrider Ansatz ist üblich.

Prüfe dein Verständnis

Wo landen rohe GRIB-Wetterdaten in der Medaillon-Architektur zuerst?

In der Bronze-Schicht als rohe, unveränderte Datensätze
In der Silver-Schicht nach Parsing und Validierung
In der Gold-Schicht als fachlich fertige Prognosen
Im Feature Store für den direkten ML-Zugriff

Richtig. Bronze ist die Landezone — roh, unveränderlich, nur anhängend. Hier findet keine Transformation statt. So bleibt die volle Detailtreue für eine spätere Neuverarbeitung erhalten.

Nicht ganz. Bronze ist immer die erste Station. Rohdaten landen unverändert, damit du jederzeit ab Quelle neu verarbeiten kannst, wenn sich deine Transformationslogik ändert.

Welche Databricks-Komponente verfolgt ML-Experimente und liefert das Champion-Prognosemodell aus?

Delta Live Tables mit deklarativen Qualitätserwartungen
Unity Catalog mit zentraler Governance der Modell-Lineage
MLflow für Tracking, Registry und Serving der Modelle
Workflows mit Orchestrierung mehrstufiger Job-Abläufe

Richtig. MLflow deckt den ML-Lebenszyklus durchgängig ab: Experiment-Tracking (Hyperparameter, Metriken), Model Registry (Versionierung, Stage-Promotion) und Model Serving (Echtzeit- oder Batch-Endpunkte).

Die Antwort ist MLflow. Unity Catalog regelt zwar den Zugriff auf Modelle, aber es ist MLflow, das Experimente verfolgt, Modellversionen registriert und Vorhersagen ausliefert.

Warum könntest du für die Bronze-Wetter-Ingestion eigene Spark-Jobs statt Delta Live Tables wählen?

Eigene Jobs bringen fertige Qualitätsprüfungen bereits mit
Delta Live Tables können nicht nach Delta-Tabellen schreiben
Wetterdateien wie GRIB2 brauchen spezielle Parser-Bibliotheken
Eigene Jobs sind stets günstiger als deklarative DLT-Pipelines

Genau. GRIB2 und NetCDF erfordern spezialisierte Bibliotheken (cfgrib, xarray, eccodes), die in imperativem Spark-/Python-Code am besten funktionieren. DLT glänzt bei SQL-ausdrückbaren Transformationen, nicht beim Parsen eigener Binärformate.

Der entscheidende Grund ist die Formatkomplexität. GRIB2 und NetCDF sind domänenspezifische Binärformate, die spezialisierte Parsing-Bibliotheken verlangen — das passt schlecht zum deklarativen Modell von DLT.

Wie ermöglicht das Lakehouse dualen Zugriff — Analysten fragen Zeitreihen ab, während die Produktions-Pipeline neue Daten schreibt?

Zeitreihen werden nächtlich in eine separate Analysedatenbank kopiert
Schreibvorgänge der Pipeline werden während Analyse-Fenstern blockiert
Delta Lakes MVCC erlaubt gleichzeitige Leser und Schreiber je Tabelle
Analysten werden auf Bronze geleitet, die Pipeline allein auf Gold

Richtig. Delta Lake nutzt Multi-Version Concurrency Control (MVCC). Leser sehen einen konsistenten Snapshot, während Schreiber neue Daten anhängen. Keine Sperren, keine Kopien, keine Abstimmung nötig. Analysten können sogar per Time Travel eine bestimmte Version fixieren.

Die Antwort lautet MVCC. Das Transaktionslog von Delta Lake erlaubt viele gleichzeitige Leser und Schreiber ohne gegenseitige Störung. Weder Datenkopien noch Zeitfenster-Tricks sind nötig.

Primärquelle

📖 Empfohlene Lektüre

What is a data lakehouse? — Databricks-Dokumentation. Ca. 10 Min. Lesezeit. Das ist die kanonische Erklärung, wie Delta Lake, Unity Catalog und Compute zusammenspielen. Lies die Abschnitte 1–3 für das Fundament, auf dem diese Lektion aufbaut.

Wie geht es weiter

Jetzt, wo du die Architekturkarte hast, zoomt die nächste Lektion auf die Modellierung von Assets und Zeitreihen in Delta Lake — wie du Tabellen für die Asset-Hierarchie (Park → Turbine) strukturierst, Zeitreihen performant partitionierst und das Muster des dualen Zugriffs ermöglichst.

Weiter: Asset-Hierarchie & Zeitreihen in Delta →

Fragen? Etwas unklar? Frag deinen Lehrer (diesen Agenten) — ich kann jedes Konzept klären, tiefer in eine Komponente einsteigen oder das Tempo anpassen.

Rechtliches: Impressum