Databricks Lakehouse: wenn der Data Lake endlich auf das Warehouse trifft

Ein Jahrzehnt lang betrieb jede ernsthafte Datenplattform zwei Systeme. Einen Data Lake, um alles in günstigen Objektspeicher zu kippen, und ein Data Warehouse, das die sauberen, modellierten Tabellen lieferte, die das Business tatsächlich abfragte. Zwei Kopien der Daten, zwei Sätze von Pipelines, zwei Rechnungen und ein Dauerstreit darüber, welches davon die Wahrheit enthielt.

Das Lakehouse ist der Versuch, diese Trennung in eine einzige zusammenfallen zu lassen. Databricks hat weder den Speicher noch das Dateiformat erfunden, aber es hat das Muster in etwas verpackt, das ein Team in Produktion betreiben kann. Nach mehreren solcher Projekte ist hier, was real und was Marketing ist.

Zwei Welten, und warum Teams beide betrieben

Ein Data Lake ist Objektspeicher — Azure Data Lake Storage Gen2, S3, GCS — mit Rohdateien in beliebigem Format. Er ist günstig, skaliert ins Unendliche und ist schema-on-read: Die Struktur legst du beim Abfragen fest, nicht beim Schreiben. Der Preis dafür ist, dass ein Lake ohne Disziplin zum Sumpf wird. Keine Transaktionen, keine Schema-Prüfung, keine einfache Möglichkeit, eine einzelne Zeile zu aktualisieren.

Ein Warehouse ist das Gegenteil. Strukturierte Tabellen, ACID-Garantien, schnelles SQL, echte Governance. Der Preis ist Starrheit und Kosten: Du zahlst für das Laden der Daten, du zahlst für proprietären Speicher, und Machine-Learning-Workloads, die Rohdateien wollen, passen nicht ins Modell.

Beide zu betreiben bedeutet, Daten zwischen ihnen zu kopieren und die Kopien auf ewig abzugleichen. Die Lakehouse-Frage ist einfach: Was wäre, wenn sich der Lake wie ein Warehouse verhalten könnte, ohne eine zweite Kopie?

Was ein Lakehouse wirklich ist

Der Trick ist ein offenes Tabellenformat, das über den Dateien im Objektspeicher liegt. Bei Databricks ist das Delta Lake: Parquet-Datendateien plus ein Transaktionslog. Dieses Log ist das ganze Spiel. Es gibt dir:

• ACID-Transaktionen — gleichzeitige Schreibvorgänge beschädigen eine Tabelle nicht mehr.
• Schema-Prüfung und -Evolution — schlechte Daten werden abgewiesen, gute Änderungen werden versioniert.
• Time Travel — frage die Tabelle so ab, wie sie letzten Dienstag war, oder mache eine fehlerhafte Ladung rückgängig.
• Upserts und Löschungen — MERGE funktioniert, was für die GDPR-Löschung und Change-Data-Capture zählt.

Da die Daten als offenes Parquet in deinem eigenen Speicherkonto bleiben, bedient eine einzige Kopie alles: SQL-Dashboards, Streaming-Jobs und ML-Training lesen dieselben Tabellen. Kein Lock-in auf den Bytes, kein Export-Schritt. Das ist der Lohn.

Die Medallion-Architektur

Das Lakehouse gibt dir die Primitive; die Medallion-Architektur ist, wie du sie ordentlich hältst. Die Daten fließen durch drei Qualitätsstufen:

1. Bronze — Rohaufnahme, genau so, wie sie ankam. Nur Append, auditierbar, niemals bearbeitet.
2. Silber — bereinigt, dedupliziert, konformiert. Verknüpft und typisiert, aber noch granular.
3. Gold — Aggregate auf Geschäftsebene und Sternschemata, die Dashboards und Berichte konsumieren.

Die Disziplin zählt mehr als das Werkzeug. Bronze ist deine Versicherungspolice: Wenn eine Silber-Transformation falsch ist, verarbeitest du erneut aus Bronze, statt aus der Quelle neu aufzunehmen. Lass es weg und du verlierst die Fähigkeit, die Historie zu reparieren.

Unity Catalog: die Governance, die du nicht nachträglich anschrauben kannst

Unity Catalog ist das Stück, das die meisten unterschätzen. Es ist eine einzige Governance-Schicht über alle Workspaces: feingranulare Zugriffskontrolle, Spalten- und Zeilenmaskierung und — der Teil, der dich in einem Audit rettet — automatische Lineage. Du kannst sehen, welcher Bericht von welcher Gold-Tabelle abhängt, die von welchem Silber-Job abhängt, bis zurück zur Rohdatei.

Governance ist nichts, was man nachrüstet, wenn man bereits fünfhundert Tabellen hat und niemand weiß, wer was lesen darf. Schalte sie bei Tabelle eins ein. Die Kosten, sie später zu migrieren, sind brutal.

Leistung: Photon und das SQL-Warehouse

Der alte Einwand gegen Lakes war die Geschwindigkeit: Dateien abzufragen konnte nicht mit einem getunten Warehouse mithalten. Zwei Dinge haben die Lücke geschlossen. Photon ist eine in C++ geschriebene, vektorisierte Query-Engine, die SQL- und DataFrame-Workloads beschleunigt, ohne deinen Code zu ändern. Und die SQL-Warehouses von Databricks geben Analysten einen vertrauten Endpunkt: Sie verbinden ein BI-Tool und fragen Gold-Tabellen ab, ohne zu ahnen, dass darunter Objektspeicher liegt.

Speicher und Compute sind getrennt, also skalierst du die Query-Cluster für einen schweren Monatsabschluss hoch und danach wieder herunter, ohne die Daten anzufassen. Diese Elastizität ist, wo die Cloud-Ökonomie wirklich zu deinen Gunsten ausschlägt — dieselbe Disziplin, für die ich in ruhigen KI-Plattformen plädiere.

Wann das Lakehouse die falsche Antwort ist

Es ist kein universelles Upgrade. Sei ehrlich zur Skalierung:

• Kleine, rein relationale Daten. Wenn alles bequem in Postgres passt und du nur BI bedienst, ist ein verwaltetes Warehouse einfacher und günstiger. Ein Lakehouse ist Maschinerie, die du nicht brauchst.
• Keine Engineering-Kapazität. Delta, Cluster und der Medallion-Fluss sind echte operative Oberfläche. Ein winziges Team ertrinkt.
• Reine, stabile Sternschemata ohne ML oder Streaming. Das Lakehouse glänzt, wenn die Workloads gemischt sind. Wenn deine es nie sein werden, ist die Flexibilität totes Gewicht.

---

Das Lakehouse verdient sich seinen Platz, wenn du wirklich beide Welten hast — Roh- und Streaming-Daten, die ML speisen, und saubere Tabellen, die das Business speisen — und du es leid bist, zweimal dafür zu zahlen, sie synchron zu halten. Fang mit Delta und den Medallion-Stufen an, aktiviere Unity Catalog sofort und lass Photon sich um die Geschwindigkeit kümmern. Als Nächstes in dieser Reihe: wie Microsoft mit Fabric, OneLake und Copilot Studio dieselbe Partie spielt.