Was ist ein Lakehouse?
DatenschichtEin Lakehouse verbindet den flexiblen Rohdatenspeicher eines Data Lake mit der strukturierten Auswertung eines Data Warehouse in einer Umgebung. Statt Daten zwischen zwei Systemen zu kopieren, arbeitet ein Team auf einer offenen Datenschicht mit einheitlichen Formaten wie Delta Lake oder Apache Iceberg - die Basis moderner Datenplattformen wie Databricks und Microsoft Fabric.
Kurz vorwegEin Lakehouse löst das Nebeneinander der Werkzeuge - Governance entscheidet über den Erfolg der Datenschicht. Datenarchitektur-Check starten
Lakehouse: Definition
Ein Lakehouse ist eine Datenarchitektur, die zwei zuvor getrennte Welten zusammenführt: den flexiblen, kostengünstigen Rohdatenspeicher des Data Lake und die strukturierte, verlässliche Auswertung des Data Warehouse. Der Schlüssel ist die offene Datenschicht. Rohdaten liegen in offenen Tabellenformaten wie Delta Lake oder Apache Iceberg direkt auf dem Speicher, zum Beispiel Amazon S3 oder Azure Data Lake Storage. Auf dieser Ebene laufen dann sowohl SQL-Auswertungen als auch Machine-Learning-Pipelines und Data-Engineering-Jobs.
Der praktische Unterschied zum klassischen Modell: Im herkömmlichen Aufbau fließen Daten per ETL aus dem Data Lake in das Data Warehouse - zwei Systeme, zwei Kopien, zwei Verwaltungsschichten. Das Lakehouse löst dieses Nebeneinander auf, indem es eine Datenschicht für beides bereitstellt. Rohdaten bleiben in ihrem Originalformat, strukturierte Auswertungen greifen per SQL direkt darauf zu, ohne dass Daten umkopiert werden müssen.
Verbreitete Implementierungen sind Databricks mit Delta Lake, Microsoft Fabric mit OneLake und offene Stacks mit Apache Iceberg. Allen gemeinsam ist das Prinzip: offene Formate, eine Kopie der Daten, Werkzeuge für Analyse und KI auf derselben Grundlage. Was das Lakehouse nicht löst, ist Governance: Wer welche Daten sehen darf, bleibt eine Frage von Metadaten und Berechtigungen - die Architektur allein schafft keine Ordnung.
- Zweck
- Data Lake und Data Warehouse in einer Datenschicht vereinen
- Kernidee
- Eine Kopie der Daten, offene Formate - Analyse und KI auf derselben Grundlage
- Offene Formate
- Delta Lake, Apache Iceberg, Apache Hudi
- Typische Plattformen
- Databricks, Microsoft Fabric, offene Stacks auf S3/ADLS
- Grenze
- löst das Nebeneinander der Werkzeuge, nicht die Governance-Frage
Wie funktioniert ein Lakehouse?
Der Aufbau folgt dem Weg von der Rohdatenablage bis zur Auswertung in einer Umgebung:
- Rohdaten ablegenDaten aus Quellsystemen werden in ihrem Originalformat in den Speicher geschrieben - wie beim Data Lake, ohne Schema-Zwang vorab.
- In offene Tabellen überführenDaten werden in ein offenes Tabellenformat wie Delta Lake oder Iceberg gelegt, das ACID-Transaktionen und Schema-Evolution erlaubt.
- Gemeinsam nutzenSQL-Auswertungen für Reports, Data-Engineering-Jobs und Machine-Learning-Pipelines arbeiten auf derselben Datenschicht.
- VerwaltenKatalog, Lineage und Berechtigungen legen fest, welche Daten existieren und wer sie lesen darf - die Governance-Schicht über der Technik.
Lakehouse, Data Lake oder Data Warehouse?
Die drei Architekturen lösen unterschiedliche Aufgaben. Die Entscheidung hängt davon ab, was ein Team wirklich braucht.
| Kriterium | Lakehouse | Data Lake / Data Warehouse |
|---|---|---|
| Datenformate | offene Tabellenformate (Delta Lake, Iceberg) | Data Lake: beliebige Rohformate; DWH: starres Schema |
| Aufbereitung | nach Bedarf auf einer Datenschicht | Data Lake: bei Nutzung; DWH: vor dem Laden (ETL) |
| Zweck | Analyse und KI auf denselben Daten | Data Lake: Exploration; DWH: feste Reports |
| Datenkopien | eine Kopie, keine Übertragung zwischen Systemen | klassisch zwei Kopien mit ETL-Brücke |
| Passt zu | Teams, die beides brauchen: flexible Rohdaten und verlässliche Auswertung | getrennte Anforderungen mit klarer Trennung |
Wann lohnt sich ein Lakehouse?
- Data Engineering und Machine Learning auf denselben Daten arbeiten sollen
- eine Kopie der Daten für Analyse und KI genügt und doppelte Haltung vermieden werden soll
- das Team mit SQL und offenen Formaten umgehen kann
- die Datenbasis mitwachsen soll, ohne Architekturwechsel
- nur fest definierte Reports auf stark strukturierten Daten gebraucht werden - ein Data Warehouse reicht
- reine Explorations- und Rohdatenhaltung ohne SQL-Auswertung gewünscht ist - ein Data Lake genügt
- die Organisation noch kein Team für die Pflege offener Formate und Kataloge hat
Die häufigsten Fehler beim Lakehouse-Aufbau
Die meisten Projekte scheitern nicht an der Plattform, sondern an diesen Punkten:
- Governance auf später verschieben: wer welche Daten sehen darf, steht fest, wenn es zu spät ist - das Lakehouse erzwingt keine Ordnung
- Alte ETL-Welt ins Lakehouse kopieren: dieselben Transformationsschritte auf einer neuen Plattform wiederholen, statt Daten in offenen Formaten bereitzustellen
- Metadaten und Katalog ignorieren: ohne Auffindbarkeit wird aus dem Lakehouse ein schwer durchsuchbarer Speicher
- Plattform vor Anforderung wählen: Databricks oder Fabric ist eine Architektur-Entscheidung, die lange bindet - sie braucht einen Anwendungsfall, kein Bauchgefühl
- Kosten ohne Aufräumregeln: veraltete und doppelte Tabellen wachsen unkontrolliert
Was das Lakehouse für KI bedeutet
RAG-Systeme, KI-Agenten und Machine-Learning-Modelle brauchen Daten in ihrer vollen Breite. Das Lakehouse liefert genau diese Breite in offenen Formaten - Modelle lesen direkt aus Delta Lake oder Iceberg, ohne eine separate Export-Schicht. Wer eine saubere, gut dokumentierte Datenschicht hat, kann Retrieval- und Trainingsdaten aus derselben Quelle speisen. Die Qualität der KI steht und fällt dann wie immer mit Metadaten und Berechtigungen, nicht mit der Plattform.
Die Entscheidung für ein Lakehouse ist keine Werkzeugfrage, sondern eine Architekturfrage: Wer Data Engineering, Analytics und Machine Learning auf einer Datenbasis betreiben will, bekommt mit einem Lakehouse eine gemeinsame Grundlage. Wer sie falsch aufbaut - ohne Governance, ohne Katalog, ohne klare Anforderung - erntet denselben Data Swamp wie beim klassischen Data Lake, nur mit mehr Werkzeugen. Die erste Frage ist nie „welche Plattform“, sondern: Welche Auswertungen und KI-Projekte sollen auf welchen Daten laufen?
„Lakehouse ist nur Marketing für einen Data Lake.“ Nein: Das Lakehouse schließt eine echte Lücke. Ein reiner Data Lake liefert keine verlässlichen SQL-Auswertungen, ein Data Warehouse keine flexible Rohdatenhaltung. Das Lakehouse verbindet beides auf offenen Formaten. Was Marketingbegriff bleibt, ist der Hype um einzelne Plattformen - das Konzept dahinter ist die Antwort auf ein reales Nebeneinander zweier Systeme.
Häufige Fragen zu Lakehouse
Was ist der Unterschied zwischen Lakehouse und Data Lake?
Ein Data Lake speichert Rohdaten in beliebigen Formaten ohne Schema-Zwang, bietet aber keine verlässlichen strukturierten Auswertungen. Ein Lakehouse legt die Daten zusätzlich in offene Tabellenformate wie Delta Lake oder Iceberg, die ACID-Transaktionen und SQL-Abfragen erlauben - Analyse und KI auf derselben Datenschicht.
Was ist der Unterschied zwischen Lakehouse und Data Warehouse?
Ein Data Warehouse speichert aufbereitete, strukturierte Daten für fest definierte Reports. Ein Lakehouse verwaltet Rohdaten und strukturierte Auswertungen zusammen auf offenen Formaten. Es ersetzt das klassische Nebeneinander von Lake und Warehouse durch eine gemeinsame Datenschicht.
Welche Plattformen bieten ein Lakehouse an?
Die bekanntesten sind Databricks mit Delta Lake, Microsoft Fabric mit OneLake sowie offene Stacks auf Amazon S3 oder Azure Data Lake Storage mit Apache Iceberg. Die Wahl zwischen ihnen ist eine Architektur-Entscheidung, die länger bindet als ein Modellwechsel - sie sollte auf dem konkreten Anwendungsfall beruhen.
Ob ein Lakehouse Ihre Datenschicht vereinfacht oder ein getrenntes Setup bleibt, entscheidet Ihre Datenlage - wir prüfen das ehrlich mit Ihnen.
Datenarchitektur-Check starten