Datenarchitekturen – verständlich eingeordnet aus der Praxis

Data Lake, Data Warehouse oder Lakehouse – technische Grundlagen, Architekturentscheidungen und Praxis aus über 50 Datenprojekten.

1.  Warum Datenarchitektur über KI-Erfolg entscheidet

Diese Aussage klingt simpel. In der Praxis ist sie einer der am häufigsten unterschätzten Grundsätze des Datenmanagements.

Wir erleben es regelmäßig: Ein Unternehmen hat eine klare KI-Vision, ein Budget und einen Zeitplan. Was fehlt, ist die Antwort auf die Frage, woher die Daten kommen, wie verlässlich sie sind und in welchem Format sie vorliegen. In solchen Projekten verlieren Teams Wochen oder Monate damit, Datenprobleme zu lösen, die in der Architektur hätten verhindert werden sollen.

Die Entscheidung für eine Datenarchitektur bestimmt, welche Analyseverfahren überhaupt möglich sind, wie schnell neue Datenquellen angebunden werden können, welche Governance-Strukturen aufgebaut werden müssen und wie teuer der Betrieb langfristig wird. Sie ist weit mehr als eine technische Detailfrage.

Eine Datenarchitektur ist nicht statisch. Wer heute mit einfachem Reporting startet, kann morgen Predictive Analytics benötigen und übermorgen KI-Agenten betreiben wollen. Die Architektur muss diese Entwicklung ermöglichen, nicht verhindern.

2.  Die drei zentralen Architekturansätze – technisch erklärt

Data Warehouse, Data Lake und Data Lakehouse sind keine Synonyme, keine aufeinander aufbauenden Generationen und keine konkurrierenden Produkte. Sie sind unterschiedliche Lösungsansätze mit klar definierten Stärken und Grenzen.

2.1  Das Data Warehouse: Schema-on-Write und ACID-Garantien

Ein Data Warehouse aggregiert Daten aus verteilten Quellsystemen – ERP, CRM, Datenbanken, externe Feeds – in einem zentralen, strukturierten Repository. Der entscheidende technische Mechanismus: das Schema-on-Write-Prinzip. Jedes Datenelement wird beim Schreiben in das Warehouse in ein vordefiniertes Schema transformiert und validiert.

Das hat einen direkten Vorteil: Daten sind sofort konsistent und abfragebereit. Business-Intelligence-Tools können direkt mit standardisierten SQL-Abfragen arbeiten. Datenqualität ist keine nachgelagerte Aufgabe, sondern eine strukturelle Eigenschaft des Systems.

Technisch ist ein Data Warehouse typischerweise dreischichtig aufgebaut:

• Integrationsschicht: ETL-Prozesse (Extract, Transform, Load) lesen Daten aus Quellsystemen, transformieren und laden sie ins Warehouse.
• Analyseschicht: Eine OLAP-Engine oder SQL-Abfragemaschine ermöglicht komplexe analytische Abfragen direkt auf dem gespeicherten Datenbestand.
• Präsentationsschicht: BI-Tools, Dashboards und Reporting-Interfaces greifen auf die Analyseschicht zu.

Moderne Cloud-Data-Warehouses wie Snowflake, Google BigQuery oder Microsoft Azure Synapse haben Computing und Storage voneinander getrennt – ein wesentlicher Fortschritt, der Skalierung deutlich günstiger macht.

Wo das Data Warehouse an Grenzen stößt: Unstrukturierte Daten – Freitext, Bilder, Sensorstreams – lassen sich nicht sinnvoll in ein relationales Schema zwingen. Für KI- und ML-Workloads ist das Data Warehouse ungeeignet. Der initiale Modellierungsaufwand ist zudem erheblich: Ein gut definiertes Datenbankschema erfordert tiefes Verständnis der Geschäftsprozesse und bindet signifikante Engineering-Kapazitäten.

2.2  Der Data Lake: Schema-on-Read und maximale Flexibilität

Der Data Lake entstand als Antwort auf das Web 2.0 und den Big-Data-Boom der späten 2000er Jahre. Unternehmen mussten Datenmengen verarbeiten, die das Hundertfache klassischer Transaktionsdaten umfassten – in Formaten, die sich nicht ohne Weiteres strukturieren ließen: Clickstreams, Logdateien, Social-Media-Posts, Sensordaten.

Die Lösung: Daten werden in ihrem nativen Rohformat gespeichert, ohne vorherige Transformation. Das Schema wird nicht beim Schreiben, sondern beim Lesen auferlegt – Schema-on-Read. Frühe Data Lakes basierten auf Apache Hadoop mit HDFS. Moderne Data Lakes nutzen Cloud-Objektspeicher wie Amazon S3, Azure Blob Storage oder Google Cloud Storage – deutlich günstiger, nahezu unbegrenzt skalierbar.

Das zentrale Problem: Ohne konsequente Governance wird ein Data Lake zum Datensumpf. Weil kein Schema erzwungen wird, landen Daten in unterschiedlichsten Formaten und Qualitätsstufen im Lake – oft ohne ausreichende Metadaten. Hinzu kommt: Data Lakes unterstützen keine ACID-Transaktionen (Atomicity, Consistency, Isolation, Durability). Das macht konsistente Datenupdates schwierig und erhöht das Risiko inkonsistenter Datenstände.

Für ML- und KI-Workloads bleibt der Data Lake unverzichtbar: Hier liegen die Rohdaten für Modelltraining und explorative Analysen. Der Schlüssel ist nicht, den Lake zu vermeiden, sondern ihn konsequent zu gouvernieren.

2.3  Das Data Lakehouse: Metadatenschicht als Schlüsselinnovation

Das Data Lakehouse verbindet die Stärken beider Ansätze – durch eine entscheidende Architekturinnovation: eine Metadatenschicht, die über dem rohen Objektspeicher liegt.

Diese Metadatenschicht ermöglicht das, was Data Lakes nicht können:

• Schemata definieren und durchsetzen, ohne Daten zu duplizieren
• ACID-Transaktionen auf Rohdaten ausführen – durch Formate wie Delta Lake, Apache Iceberg oder Apache Hudi
• Daten für schnellere Abfragen indizieren und versionieren
• Governance- und Qualitätskontrollen direkt in der Speicherschicht verankern

Die typische Lakehouse-Architektur besteht aus fünf Schichten: Aufnahme (Batch und Echtzeit-Streaming via ETL oder ELT), Speicherung (Cloud Object Storage), Metadaten (zentraler Katalog aller Objekte), API-Schicht (für externe Analysetools) und Nutzungsschicht (BI, ML, Data Science). Plattformen wie Databricks, Snowflake oder IBMs watsonx.data implementieren diese Architektur als Komplettlösung.

Was das für die Praxis bedeutet: Ein Data-Lakehouse-Team muss sowohl Data-Engineering-Kompetenz für den Lakebetrieb als auch analytisches Know-how für BI-Anwendungen mitbringen. Die Einstiegshürde ist höher als beim Data Warehouse. Dafür entfällt die Notwendigkeit, zwei separate Systeme zu betreiben – was bei wachsenden Anforderungen Zeit, Geld und Komplexität spart.

3  Direktvergleich: 11 Entscheidungskriterien

Keine Architektur ist universell die beste. Die richtige Wahl hängt von Anforderungen, Team-Zusammensetzung und Datenstrategie ab.

4  Drei Praxisbeispiele aus TIQ-Projekten

Architekturentscheidungen lassen sich nicht am Reißbrett treffen. Die Beispiele zeigen die Abwägungen, die dahinterstecken.

Beispiel 1: Data Warehouse – Produktionsunternehmen (300 MA)

Ausgangssituation: Produktions-, Qualitäts- und ERP-Daten in fünf voneinander isolierten Systemen. Die Geschäftsführung erhielt monatlich drei verschiedene Versionen der Umsatzzahlen aus drei verschiedenen Abteilungen.

Warum Data Warehouse: Die Daten waren überwiegend strukturiert, die Anwendungsfälle klar (Produktionskennzahlen, Qualitätsreporting), das Team hatte keine Data-Engineering-Kapazitäten für einen komplexeren Ansatz. Speed-to-Value war entscheidend.

Architektur: Azure Synapse Analytics, ETL-Pipelines mit Azure Data Factory, Power BI für Self-Service-Reporting. Bewusste Entscheidung gegen einen Data Lake – keine ML-Use-Cases in den nächsten 18 Monaten geplant.

Beispiel 2: Data Lake – Handelsunternehmen (800 MA)

Ausgangssituation: Über 2 TB tägliche Transaktionsdaten, Clickstream-Daten und externe Marktdaten in heterogenen Formaten. Ziel: ML-basierte Bedarfsprognosen und dynamische Preisoptimierung. Das bestehende Data Warehouse war strukturell ungeeignet.

Warum Data Lake: Datenmenge und -vielfalt machten Schema-on-Write impraktikabel. ML-Modelle benötigen Rohdaten in flexiblen Formaten. Das Data-Engineering-Team war erfahren genug für aktives Governance-Management.

Architektur: AWS S3 als Speicherschicht, Apache Spark für Transformationen, eigener Metadaten-Katalog, Snowflake für operatives BI. Bewusste Zwei-Plattform-Entscheidung, da die Anforderungen zu unterschiedlich waren.

Beispiel 3: Data Lakehouse – Digitaldienstleister (150 MA)

Ausgangssituation: Schnell wachsendes Unternehmen, heterogene Systemlandschaft. Gleichzeitiger Bedarf an BI-Reporting und KI-Piloten. Team zu klein für zwei getrennte Plattformen.

Warum Lakehouse: BI- und ML-Anforderungen auf einer Plattform – wirtschaftlich die sinnvollste Entscheidung. Databricks mit Delta Lake ermöglichte strukturierte SQL-Abfragen und die Verarbeitung von Rohdaten für KI-Modelle in einem System.

Architektur: Databricks mit Delta Lake für ACID-Transaktionen, Unity Catalog für Data Governance, Power BI via DirectQuery. ELT statt ETL – Transformation erst bei Bedarf.

5  Wie der Einstieg gelingt – pragmatisch und risikobewusst

Die größte Gefahr bei Datenarchitektur-Projekten ist nicht die falsche Technologiewahl – sondern der Anspruch, von Anfang an alles richtig machen zu wollen. Wir empfehlen einen iterativen Ansatz, der schnell erste Ergebnisse liefert.

1  Bestandsaufnahme: Welche Daten gibt es, wo liegen sie, in welchem Format, wer ist verantwortlich? Diese Inventur ist oft unangenehm – weil sie zeigt, wie fragmentiert die Datenwelt wirklich ist. Unverzichtbar.

2  Use-Case-Priorisierung: Nicht alle Daten sind gleich wichtig. Welche Anwendungsfälle versprechen in 12 Monaten den größten Mehrwert? Diese Entscheidung steuert die Architekturwahl.

3  Architekturentscheidung: Erst jetzt: Welcher Ansatz passt zu den priorisierten Use Cases, zum Team und zur IT-Landschaft? Dokumentiert und begründet.

4  Pilotprojekt mit engem Scope: Klar definierter Pilot: ein Use Case, ein Datensatz, ein messbares Ziel. Proof of Value – kein Proof of Concept. Der Pilot liefert echten Nutzen, nicht nur technische Machbarkeit.

5  Skalierung auf Basis von Lernerfahrungen: Was hat der Pilot gelehrt? Was muss angepasst werden? Skalierung ohne Reflexion ist teuer.

Fazit

Data Warehouse, Data Lake und Data Lakehouse sind keine konkurrierenden Alternativen – sie sind unterschiedliche Werkzeuge für unterschiedliche Aufgaben. Die Frage ist nicht, welches System das „beste“ ist, sondern welches für Ihre Anforderungen, Ihr Team und Ihre Datenstrategie die richtige Antwort liefert.

Was wir in jedem Projekt als entscheidend erleben: Die Architektur ist das Fundament. Sie bestimmt, was später möglich ist – und was nicht. Wer hier zu schnell, zu breit oder ohne klare Anforderungsbasis vorgeht, zahlt es später in Form von technischen Schulden, Qualitätsproblemen und gescheiterten KI-Projekten.

Gleichzeitig gilt: Eine pragmatische, gut dokumentierte Architektur, die heute produktiv ist und morgen erweitert werden kann, ist besser als eine theoretisch optimale Architektur, die nie fertig wird.

Autor: Andreas Richter, Claudia Caruso