Was ist ein offenes Lakehouse? Offene Datenstandards erklärt.

Ein offenes Lakehouse ist ein Data Lakehouse, bei dem jede Ebene (Speicher, Tabellenformat, Engine, Katalog sowie die darüber liegenden ML- und AI-Tools) auf offenen Standards basiert, sodass keine Ebene an einen einzelnen Anbieter gebunden ist.

Ein Data Lakehouse kombiniert den kostengünstigen, skalierbaren Speicher eines Data Lake mit den Verwaltungsfunktionen und Transaktionsgarantien eines Data Warehouse. Ein offenes Lakehouse fügt eine weitere Bedingung hinzu: Jede Ebene der Architektur basiert auf offenen Standards. Die Daten, die verarbeitenden Engines, der steuernde Katalog und die Tools zur Erstellung von Modellen und Anwendungen darauf sind alle Open Source, sodass keine Komponente von einem einzelnen Anbieter abhängt.

Der Begriff „offen“ wird oft verwendet, und das nicht immer ganz ehrlich. Deshalb lohnt es sich, ihn genauer zu definieren. Ein Format kann als offen bezeichnet werden und dennoch praktisch nur über eine einzige Engine nutzbar sein. Ein Katalog kann als offen bezeichnet werden und dennoch an eine einzige Plattform gebunden sein. Speicher bleibt genau so lange portabel, bis Egress-Gebühren den Transfer teuer machen. Ein offenes Lakehouse ist das Ergebnis, wenn diese Einschränkungen auf jeder Ebene wegfallen. Seit Kurzem erstreckt sich dieselbe Offenheit auch auf die AI- und Agenten-Workloads, die nun auf den Daten aufbauen.

Wie unterscheidet sich ein offenes Lakehouse von einem Data Lake und einem Data Warehouse?

Ein offenes Lakehouse kombiniert die Zuverlässigkeit eines Data Warehouse und den kostengünstigen Speicher eines Data Lake in einer einzigen Architektur und fügt eine Regel hinzu, die den anderen beiden fehlt: Jede Ebene muss offen und austauschbar sein. Ein Data Warehouse enthält bereinigte, strukturierte Tabellen für das Reporting, mit starker Governance, aber zu hohen Kosten und wenig Platz für unstrukturierte Daten. Ein Data Lake speichert alles andere, wie Rohdateien, Logs und Bilder, kostengünstig und skalierbar, jedoch ohne Transaktionen, Schemagarantien oder nennenswerte Governance.

Das Lakehouse ist nicht aus dem Nichts entstanden. Jahrelang betrieben Teams beide Systeme nebeneinander, kopierten Daten hin und her und mussten zwei Versionen der Wahrheit miteinander abgleichen. Das Data Lakehouse hat sie zusammengeführt: Verwaltung und Transaktionen im Stil eines Data Warehouse, direkt angewendet auf den kostengünstigen Lake-Speicher. Das offene Lakehouse ist die nächste Entwicklungsstufe dieser Idee. Es behält die kombinierte Architektur bei und fügt die oben genannte Regel hinzu. So erhalten Sie die Zuverlässigkeit eines Warehouse und die Wirtschaftlichkeit eines Lake, ohne dass eine Ebene an einen einzelnen Anbieter gebunden ist.

Offenes vs. proprietäres Lakehouse: Was ist der Unterschied?

Der Unterschied zwischen einem offenen und einem proprietären Lakehouse läuft auf eine Frage hinaus: Wer kann Ihre Daten lesen und welche Engines können darauf ausgeführt werden. Ein proprietäres Lakehouse speichert Daten in Formaten, die nur ein einziger Anbieter lesen kann. Ein Wechsel der Tools kann daher bedeuten, dass Sie alle Ihre Daten neu schreiben oder exportieren müssen. Ein offenes Lakehouse speichert Daten in offenen Formaten, die jede kompatible Engine lesen kann. Sie können also eine Query-Engine hinzufügen, austauschen oder entfernen, ohne Ihre Daten neu schreiben zu müssen.

Was macht ein Lakehouse offen?

Drei Dinge unterscheiden ein offenes Lakehouse von einem proprietären: offene Formate, offene Engines und eine einheitliche Governance.

Den Anfang machen offene Formate. Die Daten liegen in offenen Tabellenformaten wie Delta Lake und Apache Iceberg®, die auf offenen Dateiformaten wie Apache Parquet® aufbauen. Die Spezifikationen sind öffentlich, sodass jede Engine, die sie implementiert, die Daten lesen und schreiben kann – nicht nur die Runtime eines einzelnen Anbieters.

Als Nächstes folgen offene Engines: Auch die Systeme, die die Verarbeitung übernehmen, sind Open Source. Apache Spark® deckt Batch, Streaming, SQL und Machine Learning in einer einzigen Runtime ab. Da die darunter liegenden Tabellen offen sind, können Engines wie DuckDB, Trino oder PyIceberg mit denselben Daten arbeiten, ohne dass eine zweite Kopie erforderlich ist.

Eine einheitliche Governance ist der Teil, den Teams am meisten unterschätzen. Ein einziger Katalog übernimmt die Zugriffskontrolle, Lineage und Auditierung für jedes Format und jede Engine. So ist die Governance direkt an die Daten selbst gebunden, anstatt in jedem Tool, das darauf zugreift, neu eingerichtet werden zu müssen. Unity Catalog übernimmt hier diese Rolle.

Zusammengefasst ist das Ergebnis von der Speicherebene bis zur Serving-Ebene offen: Object Storage als Basis, ein offenes Tabellenformat darüber, eine offene Verarbeitungs-Engine, ein offener Katalog für die Governance und offene Tools für Analytics, Machine Learning und AI-Anwendungen als Abschluss.

Ist „offen“ dasselbe wie Open Source?

Nicht ganz, und der Unterschied ist wichtig. Open Source beschreibt die Lizenz des Codes eines Projekts. „Offen“ im Sinne des Lakehouse ist umfassender: Es deckt offene Datei- und Tabellenformate, offene APIs und Standardwege für die Anbindung von Tools ab sowie ein Ökosystem, in dem viele Engines auf denselben Daten arbeiten. Eine Plattform kann aus Open-Source-Projekten aufgebaut sein und Ihre Daten dennoch einsperren – beispielsweise indem sie in einem Layout gespeichert werden, das nur die eigene Engine gut lesen kann. Der ehrliche Test für Offenheit ist einfach: Sie können Ihre Daten mit jedem kompatiblen Tool lesen und zwischen Tools wechseln, ohne sie neu schreiben zu müssen.

Offenes Tabellenformat vs. offenes Lakehouse: Was ist der Unterschied?

Diese beiden Begriffe werden oft synonym verwendet, was jedoch falsch ist. Ein offenes Tabellenformat ist eine einzelne Ebene: Es fügt datenbankähnliche Funktionen (zuverlässige Updates, Schemaänderungen und Historie) über Dateien im Object Storage hinzu. Ein offenes Lakehouse umfasst alles um diese Ebene herum: den darunter liegenden Speicher sowie Compute, Katalog und Governance darüber. Das Tabellenformat ist eine Komponente. Das Lakehouse ist der gesamte Stack.

Zwei Begriffe aus der Tabelle: ACID bedeutet, dass Datenänderungen zuverlässig abgeschlossen werden, ohne die Tabelle zu beschädigen, und Time Travel bedeutet, dass Sie die Daten so anzeigen oder wiederherstellen können, wie sie zu einem früheren Zeitpunkt ausgesehen haben.

Welche offenen Standards treiben ein offenes Lakehouse an?

Diese Referenzarchitektur basiert auf fünf Open-Source-Standards, die jeweils von einer neutralen Foundation (der Apache Software Foundation oder der Linux Foundation) verwaltet werden und jeweils eine andere Ebene des Stacks abdecken. Ein offenes Lakehouse ist nur so vertrauenswürdig wie die Projekte, auf denen es aufbaut. Und dies sind keine Nischenprojekte: Es sind Standards, auf denen bereits ein Großteil der Branche läuft, und die meisten davon wurden bei Databricks entwickelt. Das ist keine falsche Bescheidenheit, sondern überprüfbar: Anfang 2026 wird Apache Spark von rund 80 % der Fortune 500 genutzt und ist die am weitesten verbreitete Engine für die großflächige Datenverarbeitung. MLflow verzeichnet mehr als 30 Millionen Downloads pro Monat. Delta Lake und Apache Iceberg decken zusammen die überwiegende Mehrheit der produktiven Lakehouse-Tabellen ab, wobei Delta Lake die größte installierte Basis hat.

Zusammen sind das mehr als 90.000 GitHub-Sterne und zweistellige Millionen Downloads pro Monat. Ein Schnappschuss des aktuellen Stands der einzelnen Projekte (GitHub-Sterne Stand Anfang 2026):

Apache Spark

Apache Spark® ist die Verarbeitungs-Engine. Sie wurde 2009 am UC Berkeley AMPLab von dem Team entwickelt, das später Databricks gründete, und der Apache Software Foundation gespendet, wo sie zu einer der am häufigsten genutzten Engines für die Datenverarbeitung im großen Stil wurde. Eine einzige Spark-Runtime verarbeitet Batch-Jobs, Streaming, SQL und Machine Learning. Deshalb kann ein Team eine einzige Engine ausführen, anstatt für jede Art von Workload ein eigenes System zu warten. Im Lakehouse liest Spark Rohdaten, bereitet sie schrittweise auf und schreibt die Ergebnisse als offene Tabellen zurück.

Delta Lake

Delta Lake ist ein Tabellenformat, mit dem sich Objektspeicher wie eine Datenbank verhält und nicht wie eine Ansammlung von Dateien. Zusätzlich zu gewöhnlichen Parquet-Dateien bietet es ACID-Transaktionen, Schema-Erzwingung und Time Travel. So überschreiben sich gleichzeitig ausgeführte Jobs nicht gegenseitig und eine Tabelle kann so abgefragt werden, wie sie zu einem früheren Zeitpunkt aussah. Eine begleitende Bibliothek, Delta Kernel, bündelt die Lese- und Schreiblogik in einer Engine-unabhängigen Komponente. Dadurch können auch andere Engines als Spark das Format einfacher unterstützen. Delta Lake wurde von Databricks entwickelt, das nach wie vor der Hauptmitwirkende ist, und wird als Projekt der Linux Foundation verwaltet.

Apache Iceberg

Iceberg ist ein zweites Tabellenformat, das für sehr große analytische Tabellen und für den reibungslosen Wechsel zwischen Engines entwickelt wurde. Es stammt ursprünglich von Netflix und nicht von Databricks und ist heute ein weit verbreitetes Apache-Projekt. Databricks ist ein Hauptmitwirkende, einschließlich des Iceberg-Gründerteams, das durch die Übernahme von Tabular hinzukam. Seine Tabellenspezifikation und sein REST-Katalog machen es mehreren Engines leicht, dieselben Tabellen gemeinsam zu nutzen. Deshalb kommt es überall dort zum Einsatz, wo mehr als eine Query-Engine verwendet wird. Die Unterstützung von sowohl Delta Lake und Iceberg bedeutet, dass sich ein Team nicht vom ersten Tag an auf ein einziges Format festlegen und für immer mit dieser Entscheidung leben muss.

Unity Catalog

Unity Catalog ist die Governance-Ebene. Es bündelt Zugriffsrichtlinien, die Bereitstellung von Anmeldeinformationen (Credential Vending) und Lineage an einem zentralen Ort, und Engines greifen direkt darüber auf Daten zu, anstatt sie zu umgehen. Da die Regeln im Katalog und nicht in einer bestimmten Engine hinterlegt sind, bleiben Zugriffskontrolle und Lineage konsistent – unabhängig davon, ob eine Abfrage von Spark, DuckDB oder einem anderen Client stammt. Unity Catalog wurde von Databricks entwickelt und ist heute ein Open-Source-Projekt unter der LF AI & Data Foundation, wobei eine verwaltete Version auf Databricks verfügbar ist. Die Open-Source-Version ist neuer als das verwaltete Produkt, und einige Governance-Funktionen befinden sich dort noch in der Entwicklung. Daher lohnt es sich, das Open-Source-Projekt mit Ihren Anforderungen abzugleichen.

Unity Catalog ist nicht der einzige offene Katalog. Apache Polaris, Project Nessie, der Hive Metastore und AWS Glue erfüllen dieselbe Rolle, und der Iceberg-REST-Katalog etabliert sich als gemeinsame Schnittstelle zwischen ihnen. Ein offenes Lakehouse kann jeden davon nutzen. Diese Referenzarchitektur verwendet Unity Catalog, da es Daten-, ML- und AI-Assets gemeinsam unter einem einzigen Modell verwaltet, aber die Katalogebene ist absolut austauschbar.

MLflow

MLflow ist die Ebene für Machine Learning und AI. Es übernimmt das Experiment-Tracking, das Model Packaging, ein Modellregister (Model Registry), die Evaluierung und das Serving. Dieselbe Technologie erstreckt sich nun auch auf AI-Agents: Sie verfolgt (Tracing), was ein Agent getan hat, bewertet seine Ergebnisse anhand von Evaluatoren und stellt ihm ein Gateway mit Budgetgrenzen und Guardrails voran. Modelle und Agents auf derselben offenen Plattform auszuführen, die auch die Daten verwaltet, anstatt in einem separaten, isolierten Stack, macht einen großen Teil des Unterschieds dieser Lakehouse-Version aus. MLflow wurde von Databricks entwickelt, das nach wie vor der Hauptmitwirkende ist, und ist ein Projekt der Linux Foundation.

Wie arbeiten die Ebenen eines offenen Lakehouse zusammen?

Die Ebenen sind über offene Schnittstellen miteinander verbunden, sodass sie ohne proprietäre Behelfslösungen zusammenpassen und jede einzelne Ebene ausgetauscht werden kann, ohne die anderen zu beeinträchtigen. Das macht aus fünf einzelnen Projekten eine einzige Architektur.

Beginnen wir mit den Daten. Spark schreibt Tabellen als Delta Lake oder Iceberg in den Objektspeicher. Da diese Formate offen sind und Delta Kernel sowie der Iceberg-REST-Katalog sie auf neutrale Weise bereitstellen, lesen andere Engines dieselben Dateien direkt. Es muss nichts zuerst in einen proprietären Speicher kopiert werden, und es gibt keinen Exportschritt am Ende.

Die Governance erstreckt sich über das gesamte System. Jede Engine greift über Unity Catalog auf die Daten zu, sodass eine einmal definierte Richtlinie überall durchgesetzt wird. Eine neue Query-Engine zu integrieren bedeutet lediglich, sie auf den Katalog auszurichten, anstatt Zugriffsregeln und Lineage für sie von Grund auf neu zu erstellen.

Modelle und Agents greifen auf dieselben verwalteten Daten zu. Ein in MLflow trainiertes Modell liest die von Spark erstellten Gold-Tabellen. Ein Agent, der eine Frage beantwortet, stellt Abfragen über Unity Catalog unter denselben Richtlinien, die auch für menschliche Analysten gelten würden. Die Lineage, die die Rohdaten mit einem bereitgestellten Modell oder der Antwort eines Agents verbindet, wird dabei lückenlos aufgezeichnet. Die AI-Ebene ist nicht nachträglich aufgepfropft; sie liest und schreibt über dieselbe verwaltete Oberfläche wie alle anderen Komponenten.

Der praktische Nutzen ist die Unabhängigkeit zwischen den Ebenen. Ein Team kann Verarbeitungs-Engines ändern, eine Query-Engine hinzufügen, ein zweites Tabellenformat einführen oder ein anderes Modell-Framework einsetzen, ohne die darüber- oder darunterliegenden Ebenen neu aufbauen zu müssen – denn jede Ebene hängt nur von der offenen Schnittstelle der benachbarten Ebene ab.

Welche Vorteile bietet ein offenes Lakehouse?

Der Hauptvorteil eines offenen Lakehouse ist die Flexibilität: Teams behalten alle Optionen offen, wenn ihre Daten- und AI-Anforderungen wachsen, da keine einzelne Ebene an einen bestimmten Anbieter gebunden ist. Die konkreten Vorteile:

• Kein Lock-in: Offene Formate ermöglichen es Teams, Tools zu wechseln, ohne Daten migrieren oder neu schreiben zu müssen.
• Geringere Kosten: Eine einzige Kopie der Daten in einem kostengünstigen Speicher verhindert die Duplizierung über verschiedene Systeme hinweg.
• Multi-Engine-Unterstützung: Viele verschiedene Engines können auf denselben Daten für BI, SQL und Machine Learning ausgeführt werden.
• Einheitliche Governance: Ein einziger Katalog wendet konsistente Zugriffskontrollen und Lineage an.
• Bereit für AI: Vertrauenswürdige, einheitliche Daten unterstützen das Modelltraining, Feature Stores und AI-Agents.
• Cloud-Freiheit: Workloads können ohne Anpassungen über mehrere Clouds hinweg ausgeführt werden.

Wie skaliert ein offenes Lakehouse, wenn Sie wachsen?

Ein offenes Lakehouse skaliert durch das Hinzufügen von Ebenen, nicht durch einen Plattformwechsel: Sie aktivieren weitere Ebenen, wenn die Arbeit es erfordert, und die anfänglichen Ebenen bleiben bestehen, während neue hinzukommen. Dasselbe Modell passt sowohl für ein Zwei-Personen-Team als auch für ein über mehrere Regionen verteiltes Unternehmen – der Unterschied liegt lediglich darin, wie viele Ebenen aktiviert sind.

• Einfaches ETL. Objektspeicher, Delta-Tabellen und Spark. Rohdaten landen in Bronze, werden in Silver bereinigt und über Gold bereitgestellt. Dieses Medaillon-Setup ist bereits für sich genommen ein vollständiger offener Stack.
• Streaming und Batch zusammen. Wenn Daten direkt bei ihrer Ankunft verarbeitet werden müssen, führen Spark Structured Streaming und der Real-Time Mode Streaming parallel zu Batch auf derselben Engine aus, wobei Spark Declarative Pipelines die Transformationen beschreiben. Ein zweites Streaming-System ist nicht erforderlich.
• Ein gemeinsamer Katalog und die ersten Agenten. Sobald Analysten, Anwendungen, Dashboards und Machine Learning dieselben Daten benötigen, wird Unity Catalog zur gemeinsamen Governance-Ebene, über die sie diese lesen. Hier tauchen meist auch die ersten Agenten auf, die die Datenqualität überwachen, Pipelines entwerfen und die Lineage untersuchen – alles über den Katalog gesteuert wie bei jedem anderen Consumer.
• Enterprise-Skalierung. Über Regionen und Clouds hinweg bietet Unity Catalog Credential Vending, feingranulare Richtlinien, Lakehouse Federation und Delta Sharing, während Spark als verwaltete Flotte auf Kubernetes läuft. Das Fundament ist dasselbe; es gibt lediglich mehr Governance und mehr Rechenleistung.

Wie fügt sich AI in ein offenes Lakehouse ein?

In einem offenen Lakehouse sind AI-Anwendungen und -Agenten erstklassige Workloads (First-Class Workloads), die genau wie jeder andere Datenkonsument gesteuert werden, und kein separates System, das nachträglich drangeflanscht wurde. Die meisten Erklärungen zu Lakehouses enden bei Business Intelligence und Machine Learning, was sich inzwischen wie ein Diagramm aus dem Jahr 2021 liest, an dessen Rand nachträglich eine AI-Box drangeheftet wurde. Agenten als gesteuerte Konsumenten derselben Daten zu behandeln, macht diese Version erst wirklich aktuell.

Da MLflow auf der Plattform läuft, die die Daten verwaltet, gelten für einen Agenten dieselben Regeln wie für alle anderen auch. Er liest über Unity Catalog und sieht daher nur das, was seine Berechtigungen zulassen. Seine Aktivitäten werden nachverfolgt und seine Antworten werden von Evaluatoren in MLflow bewertet, genau wie die Qualität eines Modells überwacht wird. Zudem kann das vorgeschaltete Gateway die Ausgaben begrenzen und Guardrails anwenden. Nichts davon erfordert einen separaten AI-Stack mit einer eigenen Kopie der Daten und einer eigenen, schwächeren Governance, was sonst die übliche Alternative wäre.

Konkret bedeutet das:

• Attribuierung: Ein Agent läuft unter seiner eigenen Identität, sodass jede Aktion auf einen Principal zurückgeführt werden kann, anstatt sich hinter einem gemeinsam genutzten Konto zu verbergen.
• Eingeschränkte Zugangsdaten (Scoped Credentials): Der Katalog gibt kurzlebige, eng begrenzte Zugangsdaten anstelle von langlebigen Schlüsseln aus, sodass der Zugriff eines Agenten wie bei jedem anderen eingeschränkt und widerrufen werden kann.
• Lineage: Die Lese- und Schreibvorgänge eines Agenten werden aufgezeichnet, sodass der Pfad von den Quelldaten über den Abruf bis hin zu einer Antwort für ein Audit rekonstruiert werden kann.
• Ausgaben und Guardrails: Budgetgrenzen und Inhaltskontrollen befinden sich auf Gateway-Ebene, außerhalb des eigenen Codes des Agenten.
• Ausfallverhalten (Failure Mode): Da der Zugriff über den Katalog erfolgt, ist das Verhalten bei Nichtverfügbarkeit des Katalogs eine explizite Designentscheidung – beispielsweise das Verweigern des Zugriffs, anstatt auf direkte, ungesteuerte Lesevorgänge auszuweichen.

Die Identität eines Agenten kann sein eigener Service-Principal oder eine Delegierung des Benutzers sein, der ihn aufgerufen hat (ein On-Behalf-Of-Modell). Diese Entscheidung bestimmt, wie seine Aktionen im Audit-Protokoll (Audit Log) erscheinen. Und der später beschriebene eigenständige MLflow-Pfad bietet Ihnen Tracing und Evaluierung ohne Lakehouse, aber die oben beschriebene, vom Katalog erzwungene Zugriffskontrolle greift erst, wenn Unity Catalog eingerichtet ist.

In der Praxis sieht das konkret so aus: Ein Agent fordert eine Spalte an, für die er keine Berechtigung hat; Unity Catalog verweigert den Lesevorgang, und das Audit-Protokoll erfasst die Identität des Agenten, die angeforderte Tabelle und Spalte, den Zeitpunkt und die Ablehnungsentscheidung. Bei den Abfragen, die ihm erlaubt sind, verknüpft die Lineage seine Antwort mit den spezifischen Gold-Tabellen, die er liest.

Es geht nicht darum, dass Agenten den Rest der Architektur ersetzen. Vielmehr fügen sie sich nahtlos in diese ein. Ein Agent ist ein weiterer Konsument gesteuerter Daten, der mit denselben offenen Tools erstellt und überwacht wird wie die Pipelines und Modelle um ihn herum.

Brauchen Sie wirklich ein offenes Lakehouse?

Nicht immer: Ein offenes Lakehouse ist die richtige Wahl, wenn sich Offenheit und Skalierbarkeit bezahlt machen, und übertrieben (Overkill), wenn dies nicht der Fall ist. Es eignet sich hervorragend, wenn Sie viele Datentypen haben, mehrere Teams oder Engines dieselben Daten gemeinsam nutzen, Multi-Cloud-Anforderungen bestehen oder das klare Ziel verfolgt wird, einen Vendor Lock-in zu vermeiden. Für einen kleinen Workload mit nur einem Tool, einfachen, strukturierten Daten und ohne die Notwendigkeit, zwischen Tools zu wechseln, kann es jedoch zu viel des Guten sein.

Ein pragmatischer Ansatz besteht darin, mit einem Pilotprojekt von begrenztem Umfang zu beginnen, das an eine reale Anforderung geknüpft ist – zum Beispiel die Föderierung einer bestehenden Quelle oder die Migration einer einzelnen Pipeline –, bevor Sie sich für eine vollständige Migration entscheiden. Die Architektur ist so konzipiert, dass sie Schicht für Schicht eingeführt werden kann. Die Entscheidung lautet also nicht „Alles oder nichts“.

Kann man schrittweise auf ein offenes Lakehouse migrieren?

Ja. Ein offenes Lakehouse ist so konzipiert, dass es sich Schicht für Schicht in Ihre bestehende Infrastruktur einfügt, anstatt von Ihnen zu verlangen, dass Sie Ihren aktuellen Stack zuerst komplett abbauen. Die wenigsten Teams fangen bei null an; die meisten nutzen bereits ein Cloud Data Warehouse, EMR, einen Datenkatalog oder befinden sich mitten in einer halbfertigen Iceberg-Migration.

• Bei einem bestehenden Cloud Data Warehouse: Föderieren Sie es über Unity Catalog, sodass Governance und Lineage auch dort greifen, und lassen Sie die Daten, wo sie sind.
• Bei EMR Spark: Verschieben Sie nur die Pipeline-Erstellungsebene (Pipeline-Authoring) zu Spark Declarative Pipelines und behalten Sie die Cluster bei, die Sie bereits betreiben.
• Bei einem separaten Katalog: Lassen Sie Unity Catalog offene Lineage-Events ausgeben, die Ihr bestehender Katalog einliest, sodass beide nebeneinander funktionieren.
• Bei einer angefangenen Iceberg-Migration: Setzen Sie Unity Catalog auf den Katalog auf, den Sie bereits eingerichtet haben, und ändern Sie sonst nichts.

Der Ablauf ist jedes Mal derselbe: Ersetzen Sie eine Schicht durch eine offene Version und lassen Sie den Rest unberührt, bis es einen Grund gibt, etwas daran zu ändern.

Was ist an einem offenen Lakehouse wirklich schwierig?

Ein offenes Lakehouse hat durchaus seine Ecken und Kanten, und eine ehrliche Betrachtung sollte diese auch benennen. Offene Tabellenformate sammeln kleine Dateien an und erfordern regelmäßige Komprimierung (Compaction) und Wartung. Das gleichzeitige Schreiben auf dieselben Tabellen von mehreren Engines aus ist noch weniger ausgereift als das Lesen, weshalb Multi-Engine-Schreibvorgänge Vorsicht erfordern. Die Open-Source-Releases einiger Komponenten hinken ihren verwalteten Versionen bei einigen Funktionen hinterher. Und das Self-Hosting des gesamten Stacks bedeutet echten operativen Aufwand. Offenheit auf Format- und Katalogebene beseitigt zudem nicht jede Form von Lock-in. Verwaltete Runtimes, proprietäre Abfragebeschleuniger und Compute-Preise sind die Bereiche, in denen Plattformen Sie nach wie vor binden – diese sollten unabhängig von den offenen Schichten bewertet werden. Nichts davon spricht gegen die Architektur. Es sind schlicht die ehrlichen Kosten dafür, die Kontrolle über jede Schicht zu haben.

Wie betreibt man ein offenes Lakehouse selbst?

Da jede Schicht Open Source ist, können Sie das Ganze selbst betreiben. Es gibt eine offene Referenzimplementierung, die die Schichten gemeinsam bereitstellt:

Damit werden Apache Spark, Apache Kafka®, Apache Airflow®, Apache Iceberg, Delta Lake, Unity Catalog und MLflow lokal unter Docker gestartet, inklusive Konfigurationen für das Deployment in der Cloud. Wenn Sie anfangs nur die AI-Schicht benötigen, können Sie auch nur mit MLflow starten: Ein pip install und ein paar Zeilen in einer bestehenden Anwendung genügen, und Sie können den Rest später hinzufügen.

Sie können beispielsweise MLflow auf einen bestehenden Agenten verweisen, ohne dass ein Lakehouse darunter liegt:

Ihr LangGraph- oder OpenAI-Agent läuft unverändert weiter, und seine Traces, Prompts und Tool-Aufrufe werden in MLflow angezeigt. Postgres, Ihr Vektorspeicher (Vector Store) und Ihr Modellanbieter bleiben dort, wo sie sind. Das gesteuerte Lakehouse fügen Sie erst dann darunter hinzu, wenn Ihre Agenten gesteuerte Unternehmensdaten benötigen.

Das Referenz-Repository ist unter der Apache-2.0-Lizenz lizenziert und wird vom Databricks Developer Relations Team gepflegt. Es handelt sich dabei nicht um eine neue Technologie, sondern um die fünf oben genannten, bewährten Projekte, die mit Docker verknüpft sind, falls Sie den gesamten Stack an einem Ort haben möchten. Jede Schicht steht zudem für sich allein; das Bundle ist eine Erleichterung, keine Abhängigkeit. Ein offenes Lakehouse selbst zu betreiben ist realistisch, bedeutet aber echte Arbeit, und das Repository spiegelt das wider: Es liefert Hochverfügbarkeitsmuster (High-Availability-Muster), Deployment-Konfigurationen und Observability, sodass Self-Hosting ein tatsächlich unterstützter Weg und nicht nur ein Versprechen ist.

Was ändert ein offenes Lakehouse für Ihre Rolle?

• Wenn Sie SQL oder dbt schreiben: Spark Declarative Pipelines bietet Ihnen dieselbe deklarative, SQL-fokussierte Erstellung (SQL-first Authoring), die Sie von dbt kennen, und fügt Streaming neben Batch-Verarbeitung sowie vollständiges SQL und Python auf einer einzigen Engine hinzu – und das alles auf gesteuerten, offenen Tabellen, die Sie weiterhin über Ihr bestehendes BI-Tool abfragen können.
• Wenn Sie Datenpipelines erstellen: Sie entwerfen diese einmal, beispielsweise mit Spark Declarative Pipelines, und führen Batch- und Streaming-Verarbeitung auf einer einzigen Engine aus.
• Wenn Sie Modelle oder Agenten erstellen: Sie erstellen, evaluieren und stellen diese in MLflow auf Basis derselben gesteuerten Daten bereit, unter denselben Zugriffsregeln wie alle anderen auch.
• Wenn Sie die Plattform selbst betreiben: Sie fügen Ebenen hinzu, wenn das Unternehmen wächst, und können jede einzelne davon austauschen, ohne den Rest auf eine neue Plattform umstellen zu müssen.

Welche Plattformen unterstützen Open Lakehouses?

Mehrere Plattformen implementieren mittlerweile die Prinzipien des Open Lakehouse. Databricks, Snowflake, Google Cloud, Microsoft Fabric, Cloudera, Dremio, Starburst und Qlik bieten alle Produkte in diesem Bereich an. Dies sind Produkte, die auf den Ideen des Open Lakehouse aufbauen, nicht die Architektur selbst, und sie unterscheiden sich darin, wie offen die einzelnen Ebenen tatsächlich sind.

Databricks hat die Kategorie Lakehouse ins Leben gerufen und bietet Performance auf Data-Warehouse-Niveau auf einer offenen Basis, wobei Delta Lake und Apache Iceberg für die Speicherung und Unity Catalog für die Governance eingesetzt werden. Die Databricks-Plattform bietet dies als Managed Service für Teams an, die den Stack nicht selbst betreiben möchten.

Häufig gestellte Fragen

Ist ein Open Lakehouse dasselbe wie ein Data Lakehouse?

Ein Data Lakehouse ist die Architektur: Verwaltung im Stil eines Data Warehouse auf einem Lake-Speicher. Ein Open Lakehouse ist ein Data Lakehouse, bei dem jede Ebene (Speicher, Tabellenformat, Engine, Katalog sowie die darauf aufsetzenden ML- und AI-Tools) Open Source und austauschbar ist, sodass keine Ebene von einem einzelnen Anbieter abhängt.

Iceberg oder Delta Lake: Welches sollte ich verwenden?

Beide sind offene Tabellenformate mit ACID-Transaktionen, Schema-Evolution und Time Travel, und ein Open Lakehouse kann eines von beiden oder beide nutzen. Delta Lake arbeitet eng mit Spark zusammen und ist über Delta Kernel zunehmend auch für andere Engines lesbar. Iceberg ist durch seinen REST-Katalog für den breiten Zugriff über mehrere Engines hinweg ausgelegt. Die Unterstützung beider Formate bedeutet, dass die Entscheidung nicht im Vorfeld getroffen werden muss.

Benötige ich alle fünf Projekte, um ein Open Lakehouse zu haben?

Nein. Die Architektur ist darauf ausgelegt, zu wachsen. Ein einfaches Open Lakehouse besteht lediglich aus Objektspeicher, einem Tabellenformat und Spark. Unity Catalog und MLflow werden hinzugefügt, wenn Governance über viele Consumer hinweg sowie Machine-Learning- oder AI-Workloads eine Rolle spielen.

Kann ich ein Open Lakehouse auch ohne Databricks betreiben?

Ja. Jede Ebene ist Open Source und läuft auf Ihrer eigenen Infrastruktur. Die Referenzimplementierung startet den gesamten Stack lokal mit Docker, und die Machine-Learning-Ebene kann eigenständig mit einem einzigen pip install verwendet werden. Databricks bietet verwaltete Versionen dieser offenen Komponenten an, aber Self-Hosting ist ein unterstützter Weg.

Welche Rolle spielen AI-Agenten in einem Open Lakehouse?

Agenten werden als verwaltete Datenkonsumenten behandelt, nicht als separates System. Sie lesen Daten über Unity Catalog unter denselben Richtlinien wie Personen und andere Engines. Zudem werden sie in MLflow parallel zu Modellen erstellt, nachverfolgt und evaluiert. Dadurch bleibt die AI-Ebene Teil derselben offenen, verwalteten Architektur, anstatt nachträglich aufgesetzt zu werden.

Wie viel kostet ein Open Lakehouse?

Die Open-Source-Komponenten können unter den Lizenzen Apache 2.0 und Linux Foundation kostenlos genutzt werden. Ihre Kosten entstehen durch den Objektspeicher, die genutzten Compute-Ressourcen und den betrieblichen Aufwand für die Wartung des Stacks. Beim Eigenbetrieb tauschen Sie Lizenzkosten gegen Entwicklungszeit ein, während eine verwaltete Plattform wie Databricks auf derselben offenen Basis Entwicklungszeit gegen ein Abonnement eintauscht.

Ist ein Open Lakehouse bereit für den Produktionseinsatz?

Ja. Die fünf Kernprojekte sind ausgereifte Standards, die bereits im großen Stil in der Produktion eingesetzt werden – beispielsweise Apache Spark bei rund 80 % der Fortune-500-Unternehmen und MLflow mit mehr als 30 Millionen Downloads pro Monat. Die wichtigsten Aspekte für den Produktionseinsatz sind betrieblicher Natur: Tabellenwartung und -komprimierung, Sorgfalt bei Schreibvorgängen über mehrere Engines hinweg sowie der Aufwand für das Self-Hosting, wenn Sie keinen Managed Service nutzen.

Apache, Apache Spark, Apache Iceberg, Apache Kafka, Apache Airflow, Apache Parquet und das Apache-Feather-Logo sind entweder eingetragene Marken oder Marken der Apache Software Foundation in den USA und/oder anderen Ländern. Delta Lake, MLflow und Unity Catalog sind Marken von LF Projects, LLC. Alle anderen Marken sind Eigentum ihrer jeweiligen Inhaber.

Um das Ganze in Aktion zu sehen, klonen Sie die Referenzarchitektur und führen Sie sie durchgängig unter github.com/open-lakehouse/open-lakehouse aus. Wenn Sie auf der AI-Seite beginnen, ist MLflow für sich genommen ein guter Einstiegspunkt, und der Rest des Stacks steht bereit, sobald Ihre Modelle und Agenten auf verwaltete Daten zugreifen müssen. Bevorzugen Sie einen vollständig verwalteten Weg? Dieselbe offene Basis bildet das Fundament für die Databricks-Lakehouse-Plattform.

Referenzarchitektur erkunden

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag