Das Lakehouse: Analytics & ML unter einem Dach

Der Kopiervorgang 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 BIBITechnologien und Prozesse, die Rohdaten über Reporting, Dashboards und Analysen in verwertbare Insights überführen, damit Teams auf Basis von Fakten statt Intuition entscheiden.Vollständige Definition ansehen →-Teams und ein Hadoop-Lake für die Data Scientists. Dazwischen lagen 40 nächtliche ETLETLETL (Extract, Transform, Load) ist ein Datenintegrationsprozess, der Daten aus Quellsystemen extrahiert, in ein konsistentes Format bringt und in ein Zielsystem schreibt.Vollständige Definition ansehen →-Jobs, deren einziger Zweck darin bestand, Daten von einem System in das andere zu kopieren, damit beide Seiten annähernd dieselben Zahlen sahen. **Das Reconciliation-Team existierte *ausschließlich*, um zu erklären, warum die „Kundenanzahl“ im Warehouse und die „Kundenanzahl“ im Lake um 3 % voneinander abwichen**.

Als die Bank schließlich die Kosten dieser Dopplung zusammenrechnete, Storage doppelt bezahlt, Pipelines doppelt gepflegt, zwei Governance-Regime und Personal, dessen Aufgabe Reconciliation war, lag die Zahl über die Lebensdauer der Plattform im neunstelligen Bereich. Nichts davon brachte einen einzigen Insight. Es war die Steuer, die man für zwei Kopien der Wahrheit zahlt.

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

Was das LakehouseLakehouseEine hybride Architektur, die die Flexibilität eines Data Lake mit den analytischen Fähigkeiten eines Data Warehouse auf einer einzigen Storage-Schicht verbindet.Vollständige Definition ansehen → tatsächlich verändert

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

Der Mechanismus, der das möglich macht, ist das offene Tabellenformat, Delta Lake, Apache Iceberg oder Apache Hudi. Wer diese Schicht versteht, versteht die gesamte Architektur; wer sie übersieht, hört bei jedem Anbieter denselben Pitch.

Ein roher Data LakeData LakeEin Data Lake ist ein zentraler Speicher, der große Datenmengen im Rohformat ablegt, von strukturierten Tabellen bis zu unstrukturierten Dateien, bis sie gebraucht werden.Vollständige Definition ansehen → war nur eine Sammlung von Dateien (Parquet, ORC) in Object Storage. Günstig, skalierbar und dumm: keine Transaktionen, kein Schema Enforcement, keine Möglichkeit, eine einzelne Zeile zu aktualisieren, ohne eine ganze Partition neu zu schreiben. Deshalb konnte man darauf keine ernsthafte BI betreiben. Das Tabellenformat legt eine Metadatenschicht *über* diese Dateien und liefert damit die Dinge, die ein Warehouse immer hatte:

• ACID-Transaktionen, gleichzeitige Schreibvorgänge beschädigen keine Leseoperationen.
• Schema Enforcement und Evolution, schlechte Daten werden beim Schreiben abgewiesen; Spalten lassen sich sicher ergänzen.
• Time Travel, die Tabelle in einem früheren Versionsstand abfragen, was Reproduzierbarkeit im ML und Audit verändert.
• Upserts und Deletes, entscheidend für das DSGVODSGVOEU-Verordnung zur Erhebung, Speicherung und Nutzung personenbezogener Daten, mit Bußgeldern, die am weltweiten Umsatz bemessen werden.Vollständige Definition ansehen →-„Recht auf Vergessenwerden“ und CDCCDCVerfahren, das nur die geänderten Daten eines Quellsystems erkennt und weiterleitet, um nachgelagerte Systeme aktuell zu halten, ohne alles neu zu laden.Vollständige Definition ansehen →-Ingestion.

Die strategische Konsequenz: **Ihre Daten liegen einmal, als Dateien in offenem Format in Ihrem eigenen Object Storage, und *mehrere Engines* greifen darauf zu**. Eine SQLSQLSales Qualified Lead: ein Prospect, den das Sales-Team als bereit für direkte Ansprache und ein Angebot validiert hat, weil er klare Qualifizierungskriterien erfüllt.Vollständige Definition ansehen →-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.

-- 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 Welt der zwei Systeme konnte ein Data Scientist, der im März ein Modell trainiert hatte, sechs Monate später kaum die exakten Trainingsdaten rekonstruieren, wenn eine Aufsichtsbehörde oder ein Model-Risk-Komitee danach fragte. Time Travel macht aus „zeig mir die Daten, die dieses Modell gesehen hat“ eine einzeilige Query. Für jeden CDO in einer regulierten Branche rechtfertigt diese eine Fähigkeit oft schon die gesamte Architektur.

Die Trennung von Storage und Compute ist die eigentliche Verschiebung

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

Damit verschiebt sich das Kostengespräch des CDO von „wie groß ist unser Warehouse“ zu „welche Workloads betreiben wir und wann“. Das ist das bessere Gespräch, aber es bringt einen neuen Fehlermodus mit sich, auf den wir zurückkommen: ohne Disziplin ist entkoppeltes Compute eine Rechnung, die mit 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 Abwägung, 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 der am schwersten zu quantifizierende, solange man den Schmerz der Dopplung 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-forward ist, ist das keine Option, sondern Pflicht.
• Kosten bei Skalierung. Object Storage plus elastisches Compute ist für große, kalte oder selten abgefragte Daten dramatisch günstiger als Warehouse-Storage.
• Kein Vendor-Lock-in auf der Storage-Ebene. Ihre Daten sind Dateien in offenem Format, die Ihnen gehören. Sie kkDie durchschnittliche Zahl neuer Nutzer, die jeder bestehende Nutzer über Empfehlungen generiert. Über 1,0 verstärkt sich das Wachstum selbst und wird exponentiell.Vollständige Definition ansehen →önnen die Query-Engine wechseln, ohne ein Migrationsprojekt. Das ist echter Hebel in Anbieterverhandlungen, nutzen Sie ihn.

Wo Warehouse plus Lake weiterhin gewinnt:

• BI mit geringer Latenz und hoher Concurrency. Ein ausgereiftes Warehouse (Snowflake, BigQuery, Teradata), das Tausende gleichzeitiger Dashboard-Nutzer im Sub-Sekunden-Bereich bedient, ist in vielen Fällen noch schneller und vorhersehbarer als ein Lakehouse, das für dieselbe Aufgabe getunt ist. Die Lücke schließt sich schnell, aber sie 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 Datenmengen haben, ist ein Warehouse allein einfacher als das Lakehouse *oder* die Trennung in zwei Systeme. 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 Dopplung. Sind alle drei hoch, ist der Fall eindeutig. Ist Ihre Welt Small Data, reine BI und läuft rund, dann ist das Lakehouse eine Lösung auf der Suche nach einem Problem.

Die versteckten Kosten, die niemand vorführt

Zwei operative Realitäten tauchen im Sales Deck nie auf, und beide landen auf dem Schreibtisch des CDO.

Das Small-File-Problem. Streaming-Ingestion schreibt viele winzige Dateien. Unbehandelt verschlechtert sich die Query-Performance massiv, weil die Engine ihre Zeit damit verbringt, Tausende Dateien zu öffnen, statt Daten zu lesen. Das ist handhabbar, Delta und Iceberg bieten Compaction und Clustering, aber es ist eine *dauerhafte operative Verantwortung*, kein einmaliges Setup. Planen Sie das Platform Engineering ein, das sie übernimmt.

Wucherende Compute-Kosten. Weil Compute elastisch und leicht hochzufahren ist, erzeugen ungovernte Lakehouses schockierende Rechnungen. Ein einzelner Analyst, der eine unoptimierte Query gegen eine Petabyte-Tabelle laufen lässt, kann in Minuten Tausende Dollar verbrennen. Die Welt der zwei Systeme hatte mit ihrer fixen Appliance eine natürliche Kostenobergrenze; das Lakehouse tauscht diese Grenze gegen Flexibilität, und Flexibilität ohne FinOps-Disziplin ist nur eine Kreditkarte ohne Limit. Workload-Tagging, Kostenzuordnung nach Team und Query-Governance sind keine Option, sie sind der Eintrittspreis.

Migrationsurteil: wie man tatsächlich dorthin kommt

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. Ist es nicht. Es ist ein Governance- und Workload-Migrationsprogramm, in dem zufällig Infrastruktur vorkommt. So sequenzieren Sie es.

Starten Sie mit der Medallion-Architektur als organisierender Disziplin. Von der Einteilung 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, verantwortet von den Platform-/Ingestion-Teams. Niemand baut direkt darauf auf.
• Silber, bereinigt, konformiert, dedupliziert. Verantwortet vom Data Engineering. Hier lebt Ihre Single Source of Truth tatsächlich.
• Gold, fachliche Aggregate und ML-Feature-Tabellen, verantwortet von Domain-Teams und Analysten.

Warum das strategisch zählt: Es verhindert, dass das Lakehouse zum „Data Swamp“ verfällt, der die erste Generation der Data Lakes umgebracht hat. Die Medallion-Schichten sind Governance-Grenzen, nicht bloß Verarbeitungsstufen. Legen Sie die 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 heute das Kopieren von Daten zwischen Warehouse und Lake *erfordert*, und verlagern Sie ihn end-to-end. Die reconciliation-lastige Analytics, unter der die europäische Bank litt, ist der ideale erste Kandidat: ihre Migration belegt die Single-Source-of-Truth-Thesis und liefert eine sichtbare Personalersparnis.

Parallel betreiben und abstimmen, bevor Sie umschalten. Betreiben Sie die ersten migrierten Workloads alt und neu nebeneinander und weisen Sie nach, dass die Zahlen übereinstimmen. Das ist mühsam und unglamourös, und es ist die wichtigste vertrauensbildende Aktivität im ganzen Programm. Sobald ein migriertes Dashboard erstmals 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.

Entscheiden Sie Ihr Tabellenformat 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 Verhandlungshebel Ihr ausdrückliches 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 dem treffen, der den ersten Proof of Concept fährt.

Lösen Sie Ihr Warehouse nicht reflexhaft auf. Die anspruchsvollsten 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 Tabellenformat 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 Source of Truth.

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

Die Architektur vereint den Storage. Sie vereint nicht automatisch Ihre *Menschen*, und genau dort scheitern Lakehouse-Programme leise. In der Welt der zwei Systeme hatten das BI-Team und das 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 vielleicht noch nie zusammengearbeitet haben.

Die Aufgabe des CDO ist hier, aus der gemeinsamen Plattform eine gemeinsame *Verantwortung* zu machen. Jemand muss jede Medallion-Schicht verantworten. Jemand muss Compaction und Kostensteuerung verantworten. Die Definition einer „zertifizierten“ Gold-Tabelle muss zwischen BI und ML abgestimmt sein, denn beide trinken künftig aus demselben Brunnen. Migrieren Sie die Technologie, lassen Sie aber die Organisation in ihren alten Silos, dann bauen Sie die Trennung in zwei Systeme innerhalb einer einzigen Plattform wieder auf, gleiche Dopplung, nur jetzt versteckt.

Key Takeaways

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

1. Bewerten Sie die Entscheidung auf drei Achsen: Datenvolumen, Ernsthaftigkeit des ML-Vorhabens und Schmerz der Dopplung. Hoch auf allen drei macht das Lakehouse eindeutig; niedrig auf allen drei heißt, ein einfaches Warehouse schlägt sowohl das Lakehouse als auch die alte Trennung. Führen Sie die Architektur nicht aus Prestige ein.

1. Budgetieren Sie die operative Steuer, die die Demo verbirgt. Das Small-File-Problem und wucherende Kosten für elastisches Compute sind dauerhafte Verantwortungen. Etablieren Sie FinOps-Disziplin, Workload-Tagging, Kostenzuordnung, Query-Governance, *vor* dem Go-live, nicht nach der ersten Schockrechnung.

1. Migrieren Sie nach Workloads mit hohem Schmerz, betreiben Sie parallel und stimmen Sie obsessiv ab. Die erste unerklärte Zahlenabweichung kostet Sie ein Jahr Vertrauen im Business. Belegen Sie die Single-Source-of-Truth-Thesis an einem reconciliation-lastigen Workload, bevor Sie skalieren.

1. Vereinen Sie die Organisation, nicht nur den Storage. Weisen Sie jeder Medallion-Schicht explizite Ownership zu und vereinbaren Sie eine gemeinsame Definition einer zertifizierten Tabelle zwischen BI und ML, sonst bauen Sie Ihre Silos innerhalb einer Plattform wieder auf.