Data Lakehouse vs. Data Warehouse: Die neue Architektur-Entscheidung
(ACCA-Fokus: SBL – Technologie, Governance & Strategy)
Executive Summary: Warum Architektur heute Chefsache ist
Unternehmen im DACH-Raum stehen vor einer Herausforderung: Die „alten“ Silo-Strukturen der IT bremsen die strategische Steuerung aus. Früher galt: Für BI (Berichte) braucht man ein Data Warehouse (DWH), für AI und „Big Data“ einen Data Lake.
Heute verschmelzen diese Welten. Ein modernes Datenfundament muss beides können. Microsoft Fabric ist hier das technologische „Bindeglied“, das DWH und Lakehouse auf einer gemeinsamen Datenbasis vereint.
Für Sie als Führungskraft bedeutet das:
Weniger Datenkopien, mehr Wahrheit, niedrigere Kosten und die nötige Agilität für AI-Anwendungen.
1. Was ist was? – Architektur für Nicht-ITler und Experten
A) Data Warehouse (DWH) – Der kuratierte „BI-Anker“
Stellen Sie sich das DWH als ein hochgradig organisiertes Archiv vor. Daten kommen „schema-on-write“ hinein: Das bedeutet, bevor die Daten gespeichert werden, werden sie akribisch nach festen Regeln (z. B. IFRS-Buchungssätze) sortiert, gereinigt und in starre Tabellen (Star-Schemas) gepresst.
Der Nutzen: Einzigartige Performance bei Standard-Abfragen (z. B. „Was ist mein operativer Gewinn im Q3?“).
Die IT-Sicht: Eine T-SQL-basierte Engine, die auf Konsistenz und „Single Version of Truth“ getrimmt ist.
B) Data Lakehouse – Der moderne „Daten-Campus“
Das Lakehouse ist ein flexibler Campus. Es speichert nicht nur fertige Tabellen, sondern auch „Rohmaterial“ (JSON-Logs, Web-Daten, Excel-Files, Bilder). Es kombiniert die Flexibilität eines Data Lakes mit den Sicherheits- und SQL-Funktionen eines Warehouses.
Der Nutzen: Hier können sowohl Analysten (BI) als auch Data Scientists (AI/ML) auf derselben Datenbasis arbeiten.
Die IT-Sicht: Einsatz von offenen Speicherformaten (Delta Lake/Parquet), die ACID-Transaktionen (Sicherheit bei Schreibvorgängen) und Zeitreisen (Time-Travel – Zugriff auf Datenzustände der Vergangenheit) ermöglichen.
C) Microsoft Fabric – Die Brücke („Zero-Copy“)
Fabric ist die technologische Antwort auf das „Kopier-Chaos“. Anstatt Daten von A nach B zu schaufeln, liegen die Daten physisch in einer Ebene (OneLake). Verschiedene Engines (SQL, Spark, KQL) greifen direkt auf dieselben Delta-Dateien zu. Das bedeutet: „One Copy, Many Engines“.
2. Das Business-Problem: Warum Silos uns Geld kosten
Viele Finanzabteilungen leiden unter der „Kopier-Kette“:
Daten aus dem ERP werden exportiert (Kopie 1).
Daten in ein DWH geladen (Kopie 2).
Data Scientists kopieren diese in ein KI-Tool (Kopie 3).
Das Ergebnis: Bei jeder Kopie sinkt die Datenqualität, die Kosten steigen, und bei einer Abweichung im Reporting beginnt das „Finger-Pointing“: „Haben wir dieselbe Datenbasis?“
Die Zielarchitektur löst dies: Das Lakehouse dient als „Single Source of Truth“. Das Warehouse bildet darauf aufbauend die hochgradig kuratierte Sicht für das IFRS-Reporting.
3. Fünf Praxisfälle: Vom „Blindflug“ zum „Daten-Cockpit“
IFRS-Reporting: Statt manueller Abstimmungs-Excel-Listen greift Power BI via Direct Lake direkt auf das Warehouse-Modell zu. Der Abschluss wird beschleunigt.
Marketing-Attribution: Web-Clickstream (unstrukturiert) und CRM-Daten (strukturiert) verschmelzen. Data Science kann jetzt echte Korrelationen zwischen Web-Traffic und Umsatz berechnen.
Supply-Chain-Echtzeit: IoT-Sensoren liefern Daten kontinuierlich. Das ELT-Streaming (Bronze -> Silver -> Gold) alarmiert das Management bei Bestandsanomalien, noch bevor der Batch-Lauf am nächsten Tag startet.
Preissteuerung: Agile Szenarien-Planung mittels SQL (für BI) und Python (für Prognose-Modelle) auf derselben Datenbasis.
Gen-AI/LLM-Enrichment: Unternehmens-eigene Daten werden als „Wissensquelle“ für LLMs (Large Language Models) genutzt, die direkt auf dem Lakehouse-Fundament aufbauen.
4. ETL vs. ELT – Was passiert technisch?
ETL (Extract, Transform, Load): Der Klassiker. Erst transformieren, dann laden. Gut für starre Finanz-Kennzahlen.
ELT (Extract, Load, Transform): Modernes Vorgehen. Erst laden (in den OneLake), dann dort transformieren. Dies ist die Basis für das Medallion-Pattern (Bronze -> Rohdaten, Silver -> Bereinigt, Gold -> Business-Ready). Fabric ermöglicht beide Ansätze auf demselben Speicher.
5. Entscheidungsmatrix: Was brauchen Sie?
Anforderung | DWH | Lakehouse | Fabric-Hybrid |
IFRS/Reporting-Fokus | Sehr stark | Mittel | Exzellent |
KI/ML-Anforderungen | Schwach | Sehr stark | Exzellent |
Daten-Flexibilität | Begrenzt | Hoch | Maximal |
Tool-Landschaft | Monolith | Offen | Integriert |
6. ROI & Zukunftsfähigkeit
Kurzfristig: Zeitgewinn durch Ende der „Export-Import-Hölle“.
Mittelfristig: Einsatz neuer Technologien (Gen-AI, Predictive Analytics) ohne Migration von Altsystemen.
Langfristig: Aufbau eines Korpus aus historischen Daten und Echtzeit-Signalen als strategisches Asset.
7. Migrations-Roadmap (90-Tage-Plan)
Assessment: Wo liegen die Silos? Welcher Business-Case bringt den größten ROI?
Minimal Viable Lakehouse: Aufbau einer ersten Bronze-Silver-Pipeline. Ein Proof-of-Concept, das ein Power BI-Dashboard direkt aus einem Warehouse-Modell füttert.
Governance & Rollout: Einführung von Microsoft Purview für Lineage (Woher kommt der Wert?) und Zugriffskontrolle.
8. Rollen im modernen Betriebsmodell
Data Product Owner: Business-Verantwortung.
Data Engineer: Kümmert sich um die Pipelines (Veredelung von Bronze zu Gold).
Analytics Engineer: Sorgt für die semantische Schicht (KPI-Definitionen).
Data Scientist: Entwickelt ML-Modelle auf der „Silver“-Schicht.
Governance/Compliance: Überwacht Kataloge und Audit-Trails.
Relevanz für ACCA, CIMA & NextLevel‑Bildungsgänge
In den unseren modernen ACCA‑ (z. B. SBL, FR, AFM) und CIMA‑Lehrplänen (z. B. F1, E1) ist Datenarchitektur kein „IT‑Extra“ mehr, sondern Kernbestandteil strategischer Unternehmensführung: Technologie, Governance, Wertbeitrag und Risiko werden integriert bewertet.
ACCA SBL (Strategic Business Leader). Hier geht es nicht um SQL‑Befehle, sondern um Führungsentscheide: Warum ein Lakehouse (BI→AI/Streaming) heute den besseren Strategy‑&‑Governance‑Fit liefert; wie man bei der Ablösung von Legacy‑Silos Risikofaktoren mitigiert (Lineage, Rollen, Policies); und warum Architekturentscheidungen den Value for Money direkt beeinflussen (Zeit‑zu‑Bericht, Kopierkosten, Compliance).
CIMA (Financial Management & Enterprise). „Financial Architects“ müssen verstehen, wie aus Rohdaten via ELT‑Pipelines (Bronze→Silver→Gold) verlässliche IFRS‑Kennzahlen entstehen – und wie Warehouse (kuratierte T‑SQL‑Modelle) und Lakehouse (offene Formate, ACID/Time‑Travel) auf einer Datenbasis zusammenspielen. Das ist heute das operative Herz des Controllings. ]
NextLevel‑Ansatz. In unseren Bildungsgängen – vom Diplom Betriebswirtschafter HF (ACCA/CIMA) bis hin zum Diplom Wirtschaftsinformatiker HF bis zu spezialisierten Zertifizierungen – lehren wir genau diese Synthese:
Governance‑Layer: IFRS‑Bilanzierungslogik und Reporting‑Regeln werden als Richtlinien in der Datenplattform implementiert (Policy‑as‑Code, Lineage, Data‑Quality), statt nur „papierbasiert“ verwaltet.
Interdisziplinarität: Finanzlogik trifft Systemarchitektur. Ein NextLevel‑Absolvent zitiert nicht nur Standards – er weiß, wie diese in einer Zero‑Copy‑Architektur (Microsoft Fabric: OneLake + Delta + SQL/Spark/KQL auf derselben Tabelle) messbar und prüfbar werden.
Für Ihren Lernpfad. Betrachten Sie das Lakehouse nicht als „IT‑Projekt“, sondern als digitales Betriebssystem der Finanzführung: Es macht Vergleichbarkeit und Transparenz (z. B. standardisierte BI‑Sichten) und Governance (Katalog, Rollen, Lineage) in Echtzeit erfüllbar – und bereitet zugleich den Boden für AI/Realtime‑Use‑Cases. Wer die Architektur beherrscht, beherrscht die Sprache moderner Finanzführung.
NextLevel‑Statement: Architektur ist Haltung – und jetzt die härteste Währung in Finance & Strategy
Es gibt Momente, in denen Technologie nicht „IT“ ist, sondern Führungsarbeit. Die Entscheidung Lakehouse vs. Warehouse – oder beides, sauber vereint – ist genau so ein Moment. Wer heute noch Silos verteidigt, Kopierketten toleriert und damit Mehrdeutigkeiten im Reporting in Kauf nimmt, trifft keine neutrale Budgetentscheidung. Er trifft eine strategische: gegen Geschwindigkeit, gegen Transparenz – und letztlich gegen Vertrauen. Architektur ist Haltung. Und in einer Welt, in der Daten die Lieferkette von Entscheidungen sind, wird diese Haltung zur härtesten Währung im Wettbewerb.
Das „Weiter so“ kostet: Jede Kopie, jeder Export, jede Nebenrechnung schafft Reibung, Latenz und Misstrauen. Führungskräfte, die noch abwarten, zahlen doppelt: in Opportunitätskosten (verpasste AI‑/Realtime‑Use‑Cases) und in Risikokosten (fehlende Lineage, schwächere Governance, teure Tool‑Zoos). Moderne Plattformen zeigen, dass es anders geht: eine Datenbasis (OneLake), ein offenes Format (Delta), viele Engines (SQL, Spark, KQL) – ohne Kopien, mit einheitlicher Governance. Das ist keine Vision, das ist heute produktiv: „one copy, many engines“. Wer es nutzt, verkürzt den Weg von „Daten landen“ zu „Daten wirken“ – im Abschluss, im Vertrieb, in der Supply Chain.
Die unbequeme Wahrheit: Es sind nicht die Technologien, die Unternehmen ausbremsen, sondern Entscheidungen, Ressourcen nicht freizugeben. Man kann die Zukunft nicht „pilotieren“ und dann wieder abschalten. Man muss sie organisieren: mit einem operativen Modell, das Lakehouse‑Agilität (alle Datentypen, Streaming, AI/ML) und Warehouse‑Disziplin (IFRS‑Sicherheit, T‑SQL‑Modelle, geprüfte KPIs) vereint – und zwar auf demselben Datenfundament. Genau diese Konvergenz ist der Grund, warum Analysten das Lakehouse als Standardarchitektur für BI→AI verorten: weniger Silos, offen, transaktional, skalierbar. Das ist kein „nice to have“, es ist die Lizenz für Relevanz.
Governance ist kein Bremspedal – sie ist das Lenkrad. Ein gut designtes Lakehouse mit zentralem Katalog, Lineage, Rollen und Policies macht Compliance wahrscheinlicher und Innovation wiederholbar. Wer heute noch Datenqualität und Nachvollziehbarkeit auf Excellisten outsourct, verwechselt Handwerk mit Glück. Die Well‑Architected‑Leitplanken für Data & AI Governance existieren – man muss sie umsetzen und skaliert verkörpern. Führen heißt hier: Regeln in Code gießen, Lineage sichtbar machen, Audit standardisieren.
Und ja – Kosten zählen. Aber die Frage ist falsch, wenn sie nur lautet: „Was kostet Fabric, Lakehouse, Migration?“ Die richtige Frage schmeckt nach Rendite:„Was kostet es uns, weiter auf Kopien, Exporte und isolierte Tools zu setzen – an Durchlaufzeit, an Rework, an Glaubwürdigkeit?“
Die Antwort ist sichtbar in jedem verspäteten Bericht, jeder manuellen Abstimmung, jedem Feature, das nicht live geht. Cloud‑native Lakehouse‑Muster senken TCO, weil sie Kopien, Doppellizenzen und Integrationsfriktion reduzieren – und ein Speicher‑/Governance‑Gerüst für alle Workloads liefern. Das ist Kostenmanagement durch Architektur.
Unser Anspruch bei NextLevel ist kein „Tool‑Pitch“. Es ist eine Haltungsfrage:
Null Kopien als Ausgangspunkt (OneLake/Delta).
Ein Governance‑/Lineage‑System, das Prüfungen besteht und Innovation befähigt.
Mehrere Engines als Freiheitsgrade – ohne Wahrheitsbruch zwischen IFRS‑BI, Data Science und Realtime.
Schrittweise Skill‑Entwicklung (SQL und Python) am gleichen Datensatz statt in Parallelwelten.
So entsteht ein Unternehmen, das entscheidet, statt zu erklären, das steuert, statt nachzuarbeiten, und das lernt, statt zu rechtfertigen.
An alle, die zögern:
Man kann die Zukunft nicht im Sandkasten gewinnen. Wer jetzt keine Ressourcen öffnet – für ein Minimal Viable Lakehouse, für Direct‑Lake‑Reporting im Abschluss, für ELT‑Streaming in der Kette – wird morgen Ressourcen zur Schadensbegrenzung freigeben müssen: für noch ein Tool, noch eine Kopie, noch eine Korrektur. Das ist keine Sparsamkeit. Das ist Verschwendung.
An alle, die führen wollen:
Architektur ist kein IT‑Projekt. Architektur ist Strategie in Struktur. Entscheiden Sie sich für eine Datenbasis, ein Governance‑Modell, viele Nutzungspfade. Schaffen Sie Räume, in denen Teams schnell liefern und sicher auditieren können. Dann passiert das, worauf es im CFO‑/CEO‑Office wirklich ankommt: Tempo, Transparenz, Vertrauen. Und das ist – in Märkten, die sich täglich neu schreiben – der einzige Zins, der immer zahlt.
9. FAQ – Häufige Fragen zum Thema Data Lakehouse vs. Data Warehouse
1) Was ist der entscheidende Unterschied zwischen Data Lakehouse und Data Warehouse?
Snippet: Ein Warehouse ist der kuratierte, SQL‑optimierte BI‑Anker für strukturierte Daten; ein Lakehouse vereint Lake‑Flexibilität (alle Datentypen) mit Warehouse‑Disziplin (ACID/SQL/Governance) – so laufen BI→AI/ML→Streaming auf einem Datenfundament. Was es für Sie heißt (DACH): Weniger Datenkopien, schnellere Iteration, einheitliche Wahrheit über Bereiche hinweg—ohne den BI‑Vorteil des Warehouses zu verlieren. Quick‑Checklist: Haben Sie semi‑/unstrukturierte Daten (JSON, Logs, Bilder) und IFRS‑BI‑Bedarf? → Lakehouse plus Warehouse‑Sichten. [fm-magazine.com], [rsmuk.com] [fm-magazine.com] [cpdbox.com]
2) Warum ist Microsoft Fabric für CH/DE/AT ein „Game Changer“?
Snippet: Fabric konsolidiert Lakehouse, Warehouse, Real‑Time Analytics und Power BI auf OneLake—mehrere Engines (SQL, Spark, KQL) greifen ohne Kopien auf dieselben Delta‑Dateien zu („one copy, many engines”). Was es für Sie heißt: Zero‑Copy‑Analytics senkt Kosten & Komplexität und verkürzt den Weg von „Daten landen“ zu „Daten wirken“ in Finanz & Operations. KPI‑Ideen: Lade‑/Refresh‑Latenz, Zahl der notwendigen Datenkopien, Zeit bis zum Monatsabschluss (T‑1 vs. T‑3). [ey.com] [pinnvalor.com]
3) Direct Lake in Power BI: lohnt sich das wirklich?
Snippet: Direct Lake liest BI‑Modelle direkt aus Delta‑Tabellen in OneLake—ohne Import/Extrakte—und reduziert Latenz, Kopien und Inkonsistenzen. Was es für Sie heißt: Bessere Performance bei IFRS‑Dashboards & Self‑Service‑Analysen; Änderungen in Delta sind sofort in Berichten sichtbar. Quick‑Checklist: Wenn Sie aktuell viele Power‑BI‑Importe pflegen → Direct‑Lake‑Pilot ansetzen. [ey.com]
4) Ist das Warehouse mit Fabric noch nötig—oder reicht ein Lakehouse?
Snippet: Ja, Warehouse bleibt relevant: T‑SQL‑Modelle liefern kuratierte, prüfbare IFRS‑Sichten auf dieselben Delta‑Tabellen—wenn Lakehouse parallel AI/Streaming bedient. Was es für Sie heißt: Bewahren Sie den BI‑Anker und gewinnen Sie Flexibilität—ohne Silos. KPI‑Ideen: SLA‑Abfragezeiten, Stabilität der Kennzahlen (Rework/Monat), Audit‑Nachweise (Lineage). [fm-magazine.com] [ey.com]
5) ETL vs. ELT—welches Muster passt zu Realtime und AI/ML?
Snippet: ETL (transform→load) ist ideal für stabile BI; ELT (load→transform in OneLake) skaliert in der Cloud besser, unterstützt das Medallion‑Pattern (Bronze→Silver→Gold) und ist bei Streaming/AI meist überlegen. Was es für Sie heißt: In Fabric können ETL (Warehouse/T‑SQL) und ELT (Lakehouse/Spark/SQL) nebeneinander laufen—oft auf derselben Delta‑Tabelle. Quick‑Checklist: Hohe Änderungsfrequenz, viele Quellen, Events? → ELT‑First. [pinnvalor.com] [ey.com]
6) Was bringt die Medallion‑Architektur (Bronze/Silver/Gold) ganz praktisch?
Snippet: Bronze = Rohdaten, Silver = bereinigt/harmonisiert, Gold = business‑ready—alles ohne Systemkopien. Was es für Sie heißt: Klarer Datenfluss + inkrementelle Veredelung = schnellere Insights, weniger Brüche, robuste Governance. KPI‑Ideen: Time‑to‑First‑Insight, Fehlerrate in Gold‑Views, Anzahl manueller Korrekturen. [pinnvalor.com] [bdo.global]
7) Wie senkt das Lakehouse die TCO (Total Cost of Ownership) im DACH‑Kontext?
Snippet: Offene Formate (Delta/Parquet) + entkoppelter Speicher/Compute reduzieren Kopien & Tool‑Zersplitterung und nutzen günstigen Object‑Storage. Was es für Sie heißt: Weniger Lizenzen/Extraktstrecken, schnelleres Onboarding neuer Quellen und Use‑Cases—besonders in Multi‑Cloud/Hybrid‑Setups. KPI‑Ideen: Speicher‑/Compute‑Kosten pro TB, Kopien pro Datensatz, Anzahl Tools je Datenpfad. [cpdbox.com] [rsmuk.com]
8) Governance & Compliance: Ist ein Lakehouse audit‑fest genug?
Snippet: Der Well‑Architected‑Ansatz fordert zentralen Katalog/Lineage, einheitliche Berechtigungen, Audit & Data‑Quality—genau darauf zielen Purview/Fabric und Lakehouse‑Best‑Practices ab. Was es für Sie heißt: Eine Plattform—ein Rechte‑/Katalogmodell—weniger Streuverluste gegenüber „Tool‑Zoos“. Quick‑Checklist: Ist Lineage für IFRS‑Kennzahlen durchgängig? Gibt es einheitliche Rollen/Policies? [bdo.global] [bdo.global]
9) Wie funktioniert „one copy, many engines“ in Fabric technisch?
Snippet: Daten liegen einmal in OneLake; Warehouse‑SQL, Spark (Lakehouse) und KQL arbeiten direkt auf denselben Delta‑Dateien—keine Duplikate, keine Exporte. Was es für Sie heißt: BI, Data Science & Streaming teilen eine Wahrheit; Änderungen propagieren schnell und konsistent in alle Workloads. [ey.com] [pinnvalor.com]
10) Microservices & Datenstrategie: Warum harmoniert das Lakehouse besser?
Snippet: Lakehouses sind offen & modular (APIs, Streaming, Multi‑Engine), während ein reines Warehouse oft ein monolithischer SQL‑Knoten bleibt. Was es für Sie heißt: Domänenteams können eigenständig Datenprodukte (Gold‑Views, Features) liefern—ohne zentrale Engpässe. [cpdbox.com]
11) Welche Rollen braucht der Betrieb im Mittelstand (CH/DE/AT)?
Snippet: Data Product Owner (Business), Data Engineer (Pipelines/Delta), Analytics Engineer (Semantik/Power BI), Data Scientist (Modelle), Governance (Katalog/Audit). Was es für Sie heißt: Weniger Übergaben—mehr Verantwortung je Domäne—schnellere Roadmaps. [ey.com], [bdo.global] [ey.com]
12) Wie sieht ein 90‑Tage‑Einstieg aus—mit messbarem Nutzen?
Snippet: (1) Assessment & Entscheidungs‑Blueprint, (2) Minimal Viable Lakehouse (Bronze→Silver, 1 IFRS‑Modell, Direct‑Lake‑Dashboard), (3) Governance & Rollout (Katalog, Rollen, Quality). Was es für Sie heißt: Früher Nutzen im Reporting und vorbereitete Pipeline für AI/Streaming—ohne Big Bang. [pinnvalor.com], [ey.com] [pinnvalor.com]
13) Brauchen wir Spark‑/Python‑Profis—oder reicht SQL?
Snippet: Beides. DWH‑Teams arbeiten in T‑SQL (Warehouse), Data Science in Python/Spark (Lakehouse)—auf denselben Delta‑Tabellen (OneLake). Was es für Sie heißt: Skills wachsen inkrementell, ohne parallel gepflegte Datenwelten. [fm-magazine.com], [ey.com] [ey.com]
14) Wie kommen wir seriös zu Realtime‑Analysen (DACH‑Praxis)?
Snippet: ELT‑Streaming (Events in OneLake/Delta) + KQL/Real‑Time Analytics in Fabric → Alarme & Live‑Dashboards ohne Kopierketten; BI & Data Science nutzen ein Fundament. Was es für Sie heißt: Schnellere Reaktionen in Supply Chain/Operations; weniger Zwischenstufen bedeuten weniger Fehler. [ey.com] [pinnvalor.com]
15) Welche Vorstandslogik empfehlen wir in CH/DE/AT (ACCA SBL‑tauglich)?
Snippet: IFRS/Controlling‑SLA top → Warehouse (T‑SQL/kuratierte Modelle). AI/ML, Streaming & Datenvielfalt → Lakehouse. Beides—aber ohne Kopien/Silos → Fabric‑Hybrid auf OneLake. Was es für Sie heißt: Architektur als Strategie‑Hebel: Stabilität und Innovationsfähigkeit—statt Entweder‑Oder. [fm-magazine.com], [ey.com] [rsmuk.com]
Wissenschaftlicher Hinweis & Zitierfähigkeit
Dieser Beitrag wurde im Rahmen des NextLevel-Forschungsschwerpunkts „Financial Governance & Reporting Architecture“ erstellt. Er dient der wissenschaftlichen Aufbereitung von Datenarchitekturen unter Berücksichtigung von IFRS-Governance-Standards und führenden Cloud-Frameworks.
Zitierempfehlung:
NextLevel College (2026): Data Lakehouse vs. Data Warehouse – Architektur & Governance. In: NextLevel Finance-Bibliothek. Abgerufen am 14.03.2026.