3/3+180 XP

Das Lakehouse: Analytics und ML vereinen

Der Kopierjob für 200 Millionen Dollar

2019 betrieb eine große europäische Bank genau das Analytics-Setup, das die meisten Unternehmen heute noch betreiben: ein Teradata-Warehouse für die Regulatorik- und BI-Teams und einen Hadoop-Lake für die Data Scientists. Dazwischen liefen 40 nächtliche ETL-Jobs, deren einziger Zweck darin bestand, Daten aus einem System in das andere zu kopieren, damit beide Seiten annähernd dieselben Zahlen sahen. Das Reconciliation-Team existierte *ausschließlich* dazu, zu erklären, warum die „Kundenzahl“ des Warehouse und die „Kundenzahl“ des Lake um 3 % voneinander abwichen.

Als die Bank schließlich die Kosten dieser Doppelung zusammenrechnete, Speicher doppelt bezahlt, Pipelines doppelt gepflegt, zwei Governance-Regime und ein Headcount, dessen Job Reconciliation war, überschritt die Summe über die Lebensdauer der Plattform neun Stellen. Kein einziger Insight ist daraus entstanden. Das ist die Steuer, die man für zwei Kopien der Wahrheit zahlt.

Das Lakehouse ist im Kern eine architektonische Wette darauf, dass man diese Steuer nicht länger zahlen muss. In dieser Lektion geht es darum, ob sich diese Wette für *Ihre* Organisation auszahlt, denn für eine nennenswerte Minderheit von Unternehmen ist die Trennung in zwei Systeme weiterhin die richtige Entscheidung.

Was das Lakehouse tatsächlich verändert

Das Muster Warehouse plus Lake kennen Sie bereits. Das Lakehouse erfindet keine neuen Nutzerbedürfnisse; es verschiebt die Grenze zwischen Storage und Compute so, dass eine governte Kopie der Daten sowohl BI als auch ML bedienen kann.

Der Mechanismus, der das möglich macht, ist das offene Table-Format, Delta Lake, Apache Iceberg oder Apache Hudi. Wer diese Ebene versteht, versteht die gesamte Architektur; wer sie überspringt, für den klingt jeder Anbieter-Pitch identisch.

Ein roher Data Lake bestand nur aus Dateien (Parquet, ORC) in Object Storage. Günstig, skalierbar und dumm: keine Transaktionen, keine Schema-Durchsetzung, keine Möglichkeit, eine einzelne Zeile zu aktualisieren, ohne eine ganze Partition neu zu schreiben. Deshalb konnte man darauf keine ernsthafte BI betreiben. Das Table-Format legt eine Metadatenschicht *über* diese Dateien und liefert damit, was ein Warehouse immer hatte:

ACID-Transaktionen, gleichzeitige Schreibvorgänge beschädigen keine Leseoperationen.
Schema-Durchsetzung und -Evolution, schlechte Daten werden beim Schreiben abgewiesen; Spalten können sicher ergänzt werden.
Time Travel, Abfrage der Tabelle in einem früheren Versionsstand, was ML-Reproduzierbarkeit und Audit verändert.
Upserts und Deletes, entscheidend für das DSGVO-„Recht auf Vergessenwerden“ und CDC-Ingestion.

Die strategische Konsequenz: Ihre Daten liegen einmal, in Dateien offenen Formats in Ihrem eigenen Object Storage, und *mehrere Engines* greifen darauf zu. Eine SQL-Engine bedient den BI-Analysten. Ein Spark- oder Python-Cluster bedient den Data Scientist. Eine Streaming-Engine schreibt frische Events in dieselben Tabellen. Niemand kopiert etwas.

sql

-- Same governed Delta table, two very different consumers
-- BI analyst:
SELECT region, SUM(revenue) FROM sales.transactions
WHERE order_date >= '2024-01-01' GROUP BY region;

-- Data scientist, same table, reading a reproducible snapshot:
SELECT * FROM sales.transactions VERSION AS OF 142;

Bei dieser VERSION AS OF-Klausel lohnt es sich innezuhalten. In der Zwei-System-Welt konnte ein Data Scientist, der im März ein Modell trainiert hatte, sechs Monate später kaum die exakten Trainingsdaten rekonstruieren, wenn eine Aufsicht oder ein Model-Risk-Komitee danach fragte. Time Travel macht aus „zeigen Sie mir die Daten, die dieses Modell gesehen hat“ eine einzeilige Abfrage. Für jeden CDO in einer regulierten Branche rechtfertigt diese einzige Fähigkeit die Architektur oft schon für sich.

Die Trennung von Storage und Compute ist die eigentliche Verschiebung

Die tiefere Verschiebung ist nicht das Dateiformat, sondern dass Storage und Compute jetzt unabhängig skalierbar und unabhängig bepreist sind. Im klassischen Warehouse kaufte man eine gekoppelte Appliance: mehr Speicher bedeutete eine größere Box, ob man die Rechenleistung brauchte oder nicht. Im Lakehouse ist Storage handelsüblicher Object Storage für ein paar Cent pro Gigabyte, und Compute fährt man bei Bedarf hoch und wieder herunter.

Damit verändert sich das Kostengespräch des CDO von „wie groß ist unser Warehouse“ zu „welche Workloads betreiben wir wann“. Das ist das bessere Gespräch, aber es bringt ein neues Fehlermuster mit, auf das wir zurückkommen: ohne Disziplin ist entkoppeltes Compute eine Rechnung, die mit der Nachlässigkeit skaliert.

Die ehrliche Tradeoff-Tabelle

Das Narrativ der Anbieter lautet, das Lakehouse schlage die alte Trennung auf jeder Achse. Das tut es nicht. Hier ist die Beurteilung, die ein CDO tatsächlich treffen muss.

Wo das Lakehouse klar gewinnt:

Single Source of Truth. Eine Kopie, ein Governance-Modell, ein Lineage-Graph. Das Reconciliation-Team verschwindet. Das ist der größte strukturelle Gewinn und am schwersten zu quantifizieren, solange man den Schmerz der Doppelung nicht selbst erlebt hat.
ML und unstrukturierte Daten. Data Scientists arbeiten gegen produktionsreife, governte Tabellen statt gegen veraltete Extrakte, und derselbe Store hält Bilder, Text und Audio, die ein Warehouse nicht aufnehmen kann. Wenn Ihre Strategie wirklich AI-getrieben ist, ist das nicht optional.
Kosten bei Skalierung. Object Storage plus elastisches Compute ist für große, kalte oder selten abgefragte Daten drastisch günstiger als Warehouse-Storage.
Kein Vendor-Lock-in auf der Storage-Ebene. Ihre Daten sind Dateien in offenen Formaten, die Ihnen gehören. Sie können die Query-Engine wechseln, ohne ein Migrationsprojekt. Das ist echte Verhandlungsmacht gegenüber Anbietern, nutzen Sie sie.

Wo Warehouse plus Lake weiterhin gewinnt:

BI mit niedriger Latenz und hoher Concurrency. Ein ausgereiftes Warehouse (Snowflake, BigQuery, Teradata), das Tausende gleichzeitige Dashboard-Nutzer mit Antwortzeiten unter einer Sekunde bedient, ist in vielen Fällen noch schneller und vorhersehbarer als ein Lakehouse, das für dieselbe Aufgabe getuned ist. Der Abstand schrumpft schnell, aber er existiert.
Operative Reife. Warehouses haben 30 Jahre Tooling, DBA-Expertise und praxiserprobte Optimizer. Der Lakehouse-Stack verlangt seltenere Skills, Leute, die File Compaction, Small-File-Probleme und Partitionsdesign verstehen. Wenn Sie diese Talente nicht haben, wird die „günstigere“ Architektur teuer.
Einfachheit für reine BI-Häuser. Wenn Sie keine ernsthaften ML-Ambitionen und moderate Datenvolumina haben, ist ein Warehouse allein einfacher als das Lakehouse *oder* die Zwei-System-Trennung. Führen Sie kein Lakehouse ein, um ein Problem zu lösen, das Sie nicht haben.

Die Entscheidungsregel, die ich CDOs mitgebe: der Vorteil des Lakehouse wächst mit der Größe Ihrer Daten, der Ernsthaftigkeit Ihrer ML-Agenda und dem Schmerz Ihrer aktuellen Doppelung. Sind alle drei hoch, ist der Fall überwältigend. Ist Ihre Welt Small Data, nur BI und läuft rund, dann ist das Lakehouse eine Lösung auf der Suche nach einem Problem.

Data Warehouse vs Data Lake vs Data Lakehouse

Watch on YouTube

Die versteckten Kosten, die niemand vorführt

Zwei operative Realitäten tauchen in keinem Sales-Deck auf, und beide landen auf dem Schreibtisch des CDO.

Das Small-File-Problem. Streaming-Ingestion schreibt viele winzige Dateien. Unbeaufsichtigt bricht die Query-Performance deutlich ein, weil die Engine ihre Zeit damit verbringt, Tausende Dateien zu öffnen, statt Daten zu lesen. Das ist beherrschbar, Delta und Iceberg haben Compaction und Clustering, aber es ist eine *dauerhafte operative Verantwortung*, kein einmaliges Setup. Planen Sie das Platform Engineering ein, das dafür zuständig ist.

Wucherende Compute-Kosten. Weil Compute elastisch und leicht hochzufahren ist, produzieren ungoverntes Lakehouses schockierende Rechnungen. Ein einzelner Analyst, der eine unoptimierte Abfrage gegen eine Petabyte-Tabelle laufen lässt, kann in Minuten Tausende Dollar verbrennen. Die Zwei-System-Welt hatte in ihrer fixen Appliance eine natürliche Kostenobergrenze; das Lakehouse tauscht diese Obergrenze gegen Flexibilität, und Flexibilität ohne FinOps-Disziplin ist nur eine Kreditkarte ohne Limit. Workload-Tagging, Kostenzuordnung pro Team und Query-Governance sind nicht optional, sie sind der Eintrittspreis.

Migrationsurteil: wie Sie tatsächlich dort ankommen

Nehmen wir an, Sie haben entschieden, dass das Lakehouse richtig ist. Der Fehler, den ich am häufigsten sehe, ist, das als Lift-and-Shift-Infrastrukturprojekt zu behandeln. Das ist es nicht. Es ist ein Governance- und Workload-Migrationsprogramm, das zufällig Infrastruktur betrifft. So sequenzieren Sie es.

Beginnen Sie mit der Medallion-Architektur als Ordnungsdisziplin. Die Einteilung in Bronze/Silber/Gold haben Sie wahrscheinlich gehört; für einen CDO ist der Punkt, dass sie sauber auf Ownership und Vertrauen abbildet:

Bronze, rohe eingelesene Daten, im Besitz der Platform-/Ingestion-Teams. Niemand baut direkt darauf auf.
Silber, bereinigt, konformiert, dedupliziert. Im Besitz von Data Engineering. Hier lebt Ihre Single Source of Truth tatsächlich.
Gold, fachliche Aggregate und ML-Feature-Tabellen, im Besitz der Domain-Teams und Analysten.

Warum das strategisch zählt: es verhindert, dass das Lakehouse zum „Data Swamp“ verfällt, der die erste Generation von Data Lakes getötet hat. Die Medallion-Schichten sind Governance-Grenzen, nicht bloß Verarbeitungsstufen. Legen Sie das Ownership jeder Schicht schriftlich fest, bevor Sie irgendetwas migrieren.

Migrieren Sie nach Workload, nicht nach Datensatz. Versuchen Sie nicht, zuerst alle Daten zu verschieben. Wählen Sie einen abgegrenzten Workload mit hohem Schmerz, idealerweise einen, der aktuell das Kopieren von Daten zwischen Warehouse und Lake *erfordert*, und verlagern Sie ihn end-to-end. Die reconciliation-lastigen Analysen, unter denen die europäische Bank litt, sind der ideale erste Kandidat: die Migration belegt die Single-Source-of-Truth-These und liefert eine sichtbare Headcount-Einsparung.

Laufen Sie parallel und reconcilen Sie, bevor Sie umschalten. Lassen Sie bei den ersten migrierten Workloads alt und neu nebeneinander laufen und weisen Sie nach, dass die Zahlen übereinstimmen. Das ist mühsam und unglamourös, und es ist die wichtigste vertrauensbildende Aktivität im gesamten Programm. Beim ersten Mal, wenn ein migriertes Dashboard eine andere Zahl zeigt als das alte und Sie *nicht* erklären können, warum, verlieren Sie das Vertrauen des Business für ein Jahr.

Wissenscheck

1. Was ist die zentrale architektonische Veränderung, die das Lakehouse gegenüber dem klassischen Muster Warehouse plus Lake einführt?

2. Warum wird das offene Table-Format als die Schicht beschrieben, die man verstehen muss, um die gesamte Lakehouse-Architektur zu erfassen?

3. Welches zugrunde liegende Problem, das das Lakehouse lösen will, illustriert die Geschichte des „Reconciliation-Teams“?

MEHRFACHAUSWAHL

4. Wählen Sie ALLE Fähigkeiten, die ein offenes Table-Format über rohen Dateien im Object Storage ergänzt.

Wählen Sie alle richtigen Antworten aus.

MEHRFACHAUSWAHL

5. Wählen Sie ALLE Aussagen, die korrekt beschreiben, warum ein roher Data Lake allein keine ernsthafte BI tragen konnte.

Wählen Sie alle richtigen Antworten aus.

Entscheiden Sie Ihr Table-Format bewusst, es ist eine strategische, keine technische Wahl. Delta Lake ist eng mit Databricks integriert und hat das ausgereifteste Tooling; wenn Sie ein Databricks-Haus sind, ist es der Weg des geringsten Widerstands, bindet Sie aber stärker an dieses Ökosystem. Apache Iceberg ist zum neutralen Multi-Engine-Standard geworden, Snowflake, BigQuery, AWS und andere unterstützen es alle, was es zur stärkeren Wahl macht, wenn Engine-Unabhängigkeit und Verhandlungsmacht Ihr explizites Ziel sind. Treffen Sie diese Entscheidung auf CDO-Ebene *gemeinsam mit* Ihren Architekten, denn sie bestimmt, wie viel Lock-in-Hebel Sie für das nächste Jahrzehnt behalten. Lassen Sie sie nicht implizit von demjenigen treffen, der den ersten Proof of Concept fährt.

Lösen Sie Ihr Warehouse nicht reflexhaft auf. Die versiertesten Unternehmen fahren hybrid: das Lakehouse als governte Single Source of Truth, mit einem Teil der Gold-Layer-Daten, der weiterhin über ein spezialisiertes Warehouse oder eine Serving-Schicht für BI mit höchster Concurrency ausgeliefert wird. Das offene Table-Format macht das machbar, eine Iceberg-Tabelle kann sowohl von Ihren Spark-Jobs als auch von Snowflake abgefragt werden. Reinheit ist nicht das Ziel; die Beseitigung doppelter *Wahrheit* ist es. Sie können eine governte Kopie haben und sie dennoch in eine schnelle Serving-Engine schieben, denn das ist eine Performance-Projektion, keine zweite Quelle der Wahrheit.

Die organisatorische Veränderung, die über den Erfolg entscheidet

Die Architektur vereinheitlicht den Storage. Sie vereinheitlicht nicht automatisch Ihre *Leute*, und genau daran scheitern Lakehouse-Programme leise. In der Zwei-System-Welt hatten BI-Team und ML-Team getrennte Plattformen, getrennte Governance und getrennte Rituale. Setzen Sie sie auf einen Store, und Sie haben eine gemeinsame Abhängigkeit zwischen zwei Gruppen geschaffen, die möglicherweise nie zusammengearbeitet haben.

Die Aufgabe des CDO ist hier, aus der gemeinsamen Plattform eine gemeinsame *Verantwortung* zu machen. Jemand muss jede Medallion-Schicht besitzen. Jemand muss Compaction und Kosten-Governance besitzen. Die Definition einer „zertifizierten“ Gold-Tabelle muss zwischen BI und ML abgestimmt sein, denn beide trinken jetzt aus demselben Brunnen. Wenn Sie die Technologie migrieren, die Organisation aber in ihren alten Silos lassen, bauen Sie die Zwei-System-Trennung innerhalb einer einzigen Plattform wieder auf, dieselbe Doppelung, nur jetzt versteckt.

Kernaussagen

1. Das Table-Format ist das ganze Spiel. Delta, Iceberg oder Hudi ist das, was aus einem dummen Lake einen governten Store macht, der BI und ML bedient. Bewerten Sie Lakehouse-Vorschläge an ihrer Table-Format-Strategie und wählen Sie Iceberg, wenn Engine-Unabhängigkeit und Verhandlungsmacht Priorität haben.

2. Bewerten Sie die Entscheidung auf drei Achsen: Datenvolumen, Ernsthaftigkeit von ML und Schmerz der Doppelung. Hohe Werte auf allen drei machen das Lakehouse überwältigend; niedrige Werte auf allen drei bedeuten, dass ein einfaches Warehouse sowohl das Lakehouse als auch die alte Trennung schlägt. Führen Sie die Architektur nicht aus Prestige ein.

3. Planen Sie die operative Steuer ein, die die Demo verbirgt. Das Small-File-Problem und das Wuchern elastischer Compute-Kosten sind dauerhafte Verantwortungen. Etablieren Sie FinOps-Disziplin, Workload-Tagging, Kostenzuordnung, Query-Governance, *vor* dem Go-live, nicht nach der ersten schockierenden Rechnung.

4. Migrieren Sie nach Workloads mit hohem Schmerz, laufen Sie parallel und reconcilen Sie obsessiv. Die erste unerklärte Zahlendiskrepanz kostet Sie ein Jahr Vertrauen im Business. Belegen Sie die Single-Source-of-Truth-These an einem reconciliation-lastigen Workload, bevor Sie skalieren.

5. Vereinheitlichen Sie die Organisation, nicht nur den Storage. Weisen Sie jeder Medallion-Schicht ein explizites Ownership zu und vereinbaren Sie eine gemeinsame Definition einer zertifizierten Tabelle über BI und ML hinweg, sonst bauen Sie Ihre Silos innerhalb einer Plattform wieder auf.

Was Sie aus dieser Lektion umsetzen

Diese Maßnahmen sind im Playbook der Rolle zusammengefasst.

Architektur anhand von Workload, Team-Skills, Volumen und Lock-in-Toleranz wählen
Pipelines auf das Medallion-Muster mit Bronze-, Silver- und Gold-Layer standardisieren

Vollständiges Action Playbook ansehen →