Data Lakehouse: Architektur, Vorteile und Einsatz im Unternehmen

In vielen Unternehmen sind über die Jahre beide Systeme nebeneinander entstanden: ein Data Warehouse für das Berichtswesen und ein Data Lake für alles, was dort nicht hineinpasst. Beide werden getrennt betrieben und gepflegt, und in weiten Teilen halten sie dieselben Daten vor - mit entsprechendem Aufwand für Betrieb, Lizenzen und Abstimmung zwischen den beiden Welten.

Mehr zu Datenarchitekturen

Offene Tabellenformate: Delta Lake und Apache Iceberg

Das Herzstück eines Lakehouse sind offene Tabellenformate. Sie legen sich als Metadatenschicht über gewöhnliche Parquet-Dateien im Objektspeicher und ergänzen das, was einem reinen Data Lake fehlt: Transaktionssicherheit, Versionierung und Schemaverwaltung.

Zwei Formate dominieren. Delta Lake stammt ursprünglich aus dem Databricks-Umfeld und ist auch das Format, in dem Microsoft Fabric seine Daten in OneLake ablegt. Apache Iceberg entstand bei Netflix und wird heute als Apache-Projekt weiterentwickelt; es ist im Snowflake- und AWS-Umfeld stark verbreitet.

• Databricks 
•  
• Microsoft Fabric

Für die Praxis relevant: Beide Formate nähern sich an, und die grossen Plattformen unterstützen inzwischen beide beziehungsweise ermöglichen den Zugriff über Interoperabilitätsschichten. Die Formatwahl ist damit weniger endgültig, als sie noch vor zwei Jahren war.

ACID-Transaktionen auf Objektspeicher

Klassische Data Lakes kennen keine Transaktionen. Bricht ein Ladevorgang ab, bleiben halb geschriebene Dateien zurück, und wer währenddessen liest, bekommt einen inkonsistenten Stand. Offene Tabellenformate lösen das über ein Transaktionslog: Änderungen werden erst sichtbar, wenn sie vollständig sind. Zusätzlich lässt sich auf frühere Versionen eines Datenstands zugreifen - nützlich für Nachvollziehbarkeit, Fehlersuche und Audits.

Trennung von Speicher und Rechenleistung

Speicher und Rechenleistung skalieren im Lakehouse unabhängig voneinander. Der Speicher liegt dauerhaft und günstig im Objektspeicher; Rechenkapazität wird nur dann bereitgestellt, wenn tatsächlich verarbeitet oder abgefragt wird. Das verändert die Kostenlogik grundlegend: Nicht die Datenmenge treibt die Kosten, sondern die Nutzungsintensität.

Innerhalb eines Lakehouse hat sich ein Schichtenmodell durchgesetzt, das als Medallion-Architektur bezeichnet wird. Es beschreibt, wie Daten schrittweise von Rohdaten zu auswertbaren Kennzahlen veredelt werden.

Der Nutzen des Modells liegt weniger in der Technik als in der Klarheit: Jede Schicht hat einen definierten Zweck, eine definierte Qualitätsstufe und definierte Zugriffsrechte. Wer eine Zahl hinterfragt, kann sie bis zur Rohdatenlieferung zurückverfolgen.

Eine Einschränkung aus der Projektpraxis: Drei Schichten sind eine Konvention, kein Gesetz. Kleine Vorhaben kommen mit zwei aus, komplexe Landschaften brauchen manchmal eine Zwischenschicht. Wer das Modell schematisch anwendet, baut Aufwand auf, der niemandem nützt.