Data Lake vs. Cloud Data Warehouse: Ein praktischer Leitfaden für Data Scientists

Ein Data Lake ist ein zentrales Repository, das Rohdaten in ihrem nativen Format – strukturiert, semistrukturiert und unstrukturiert – auf kostengünstigem Cloud-Objektspeicher speichert. Im Gegensatz zu einem Cloud Data Warehouse, das ein vordefiniertes Schema vorschreibt, bevor Daten geladen werden können, wendet ein Data Lake die Struktur erst beim Lesen an (Schema-on-Read). Dies bietet Data Scientists und Data Engineers maximale Flexibilität bei der Arbeit mit unterschiedlichen Datentypen ohne vorherige Transformation. Beide Architekturen basieren auf einer Cloud-Infrastruktur, beantworten jedoch grundlegend andere Fragen dazu, wie Daten im großen Stil erfasst, verarbeitet und abgerufen werden.

Dieser Leitfaden richtet sich an Data Scientists, Data Engineers und Analytics-Verantwortliche, die ein praktisches Entscheidungs-Framework benötigen – und keine Verkaufspräsentation. Am Ende werden Sie die wesentlichen Unterschiede zwischen einem Data Lake und einem Cloud Data Warehouse verstehen, wissen, wann ein Data Lakehouse diese Lücke schließt, und wie Sie die richtige Datenspeicherarchitektur für Ihre spezifischen Workloads auswählen.

Schnelle Empfehlung im Überblick

Bevor wir uns mit den technischen Details befassen, finden Sie hier die praktischen Ratschläge, die die meisten Teams direkt zu Beginn benötigen.

Wählen Sie einen Data Lake, wenn Ihr Hauptbedarf darin besteht, Rohdaten in verschiedenen Formaten im Petabyte-Bereich für Machine Learning, Data Science oder zukünftige, noch nicht definierte Analytics-Anwendungsfälle zu speichern. Data Lakes bieten Skalierbarkeit zu geringeren Kosten pro Gigabyte als Cloud Data Warehouses und unterstützen alle Datentypen, ohne dass vor der Erfassung ein Schema erforderlich ist.

Wählen Sie ein cloudbasiertes Data Warehouse, wenn Ihr Workload auf schnellen, gleichzeitigen SQL-Abfragen auf strukturierten Geschäftsdaten basiert – Dashboards, Finanzberichte, Kontoauszüge und operative Analysen, bei denen eine geringe Abfragelatenz und hohe Gleichzeitigkeit wichtiger sind als die Flexibilität bei der Speicherung.

Wählen Sie ein Data Lakehouse, wenn Ihr Unternehmen sowohl Machine Learning- als auch Business Intelligence-Workloads ausführt und eine einheitliche Plattform benötigt, die Datenredundanz zwischen einem Lake und einem Warehouse vermeidet. Lakehouses bieten ACID-Transaktionsunterstützung direkt auf dem Lake-Speicher, was sie zum praktischen Standard für die meisten modernen Datenplattformen macht.

Was ist ein Data Lake?

Ein Data Lake ist ein zentrales Repository, das darauf ausgelegt ist, all Ihre Daten – strukturiert, semistrukturiert und unstrukturiert – in ihrem ursprünglichen Rohformat zu speichern, bis sie für Analysen benötigt werden. Data Lakes entstanden speziell, um den explosionsartig ansteigenden Bedarf an unstrukturiertem Speicherplatz zu decken, den herkömmliche relationale Datenbanken und Data Warehouses nicht wirtschaftlich bewältigen konnten.

Das entscheidende Merkmal eines Data Lake ist, dass er Daten sofort mithilfe der Extract, Load, Transform (ELT)-Methode aufnimmt und dabei Schema-on-Read statt Schema-on-Write anwendet. Das bedeutet, dass Data Engineers Logdateien, JSON-Ereignisse, Bilder, Videos, Sensor-Streams und Datenbanktabellen in dasselbe System einspeisen können, ohne vorher festlegen zu müssen, wie diese Daten abgefragt werden. Data Scientists erhalten direkten Zugriff auf rohe, unverarbeitete Daten in dem Format, in dem sie eingegangen sind, was für das Feature Engineering und die Entwicklung von Machine Learning-Modellen unerlässlich ist.

Cloud Data Lakes laufen in der Regel auf Objektspeicherdiensten – Amazon S3, Azure Data Lake Storage (ADLS) und Google Cloud Storage –, die eine praktisch unbegrenzte Kapazität bieten. Data Lakes können Petabytes an Informationen ohne feste Einschränkungen speichern, und die Kosten pro Gigabyte sind erheblich niedriger als bei dem proprietären Speicher, der von Legacy-Data-Warehouses verwendet wird. Diese Skalierbarkeit zu geringeren Kosten pro Gigabyte macht Data Lakes zur praktischen Wahl für die Speicherung von Big Data, bei der das Volumen im Vordergrund steht.

Data Lakes unterstützen alle Datentypen – strukturierte Datenbankexporte, semistrukturierte Formate wie JSON und Parquet sowie vollständig unstrukturierte Inhalte wie Textkorpora, Audio und Bilddaten. Diese Vielseitigkeit macht sie zur idealen Landing Zone für jedes Unternehmen, das Rohdaten für zukünftige Analysen aufbewahren muss, einschließlich Anwendungsfällen, die zum Zeitpunkt der Erfassung noch gar nicht definiert sind.

Cloud Data Warehouses und der Kontext relationaler Datenbanken

Ein Cloud Data Warehouse ist eine verwaltete Analyse-Datenbank, die für hochgradig gleichzeitige SQL-Abfragen auf strukturierten, geschäftsbereiten Daten optimiert ist. Im Gegensatz zu einer relationalen Datenbank, die für transaktionale Workloads ausgelegt ist – also das Einfügen und Aktualisieren einzelner Zeilen in Echtzeit –, ist ein Cloud Data Warehouse für analytische Workloads konzipiert, die große Mengen historischer Daten scannen, um Aggregate, Berichte und Dashboards zu erstellen.

Cloud Data Warehouses erzwingen ein Schema-on-Write-Modell: Daten müssen bereinigt, typisiert und an ein vordefiniertes Schema angepasst werden, bevor sie geladen werden können. Diese Einschränkung ist sowohl die größte Stärke als auch die wesentlichste Einschränkung des Warehouse. Da jede Zeile in jeder Tabelle einer bekannten Struktur entspricht, können spaltenbasierte Speicherung und Techniken zur Abfragebeschleunigung (Predicate Pushdown, Zone Maps, Result Caching) intensiv genutzt werden – was die Abfrageleistung im Subsekundenbereich liefert, die Business-Anwender und Datenanalysten von Dashboards erwarten.

Führende Anbieter von Cloud Data Warehouses – darunter Amazon Redshift, Google BigQuery, Snowflake und das Databricks Lakehouse – haben Rechenleistung und Speicher voneinander entkoppelt. Das bedeutet, dass die Abfragekapazität unabhängig von den gespeicherten Daten skaliert werden kann. Diese Architektur unterstützt Workloads mit hoher Gleichzeitigkeit, bei denen Hunderte von Benutzern gleichzeitig Abfragen ohne Ressourcenkonflikte ausführen. Für Business-Intelligence-Anwendungsfälle – Umsatzberichte, Kontoauszüge, Bestandsanalysen – bleibt das Cloud Data Warehouse die dominierende Wahl, da Abfrageleistung und Datenkonsistenz nicht verhandelbar sind.

Schwierigkeiten haben Cloud Data Warehouses mit Datentypen, die nicht in ein relationales Modell passen: unstrukturierter Text, rohe Sensor-Streams, Image Embeddings und semistrukturierte Ereignisprotokolle. Das Laden dieser Daten in ein Warehouse erfordert erheblichen Transformationsaufwand und führt oft dazu, dass Daten verworfen oder näherungsweise angepasst werden müssen, um in ein Schema zu passen. Dies beeinträchtigt die Vollständigkeit, die für Machine Learning-Workloads erforderlich ist.

Data-Lake-Architektur und Speicherlösungen

Die Data-Lake-Architektur ist in der Regel in drei Zonen unterteilt, von denen jede eine progressiv höhere Datenqualität und Geschäftsreife darstellt.

Raw-Zone (Bronze-Layer)

Die Raw-Zone ist der erste Landebereich für Daten, die aus externen Quellsystemen erfasst werden. Die Daten kommen in ihrem nativen Format an – Datenbankexporte, API-Antworten, Streaming-Ereignisse, Flat Files – und werden mit minimaler Transformation in den Objektspeicher geschrieben. Das Ziel ist Datentreue: Die Erhaltung des Originaldatensatzes, sodass die gesamte Pipeline von Anfang an neu abgespielt werden kann, falls sich die nachgelagerte Logik ändert. Metadaten, Zeitstempel des Ladevorgangs und Quellkennungen werden hinzugefügt, aber die Daten selbst bleiben unverändert.

Cleansed-Zone (Silver-Layer)

In der Cleansed-Zone werden Rohdaten abgeglichen, zusammengeführt und in eine einheitliche Unternehmenssicht gebracht. Es werden Datenqualitätsprüfungen durchgeführt, Duplikate bereinigt und Daten aus mehreren Quellen zu kohärenten Entitäten zusammengeführt – Kunden, Transaktionen, Produkte. Diese Schicht unterstützt explorative Analysen, Ad-hoc-Berichte und Data-Science-Experimente, ohne dass nachgelagerte Verbraucher den rohen, unverarbeiteten Daten ausgesetzt werden.

Curated-Zone (Gold-Layer)

Die Curated-Zone enthält produktionsreife Aggregate auf Geschäftsebene, die für die Nutzung durch Dashboards, operative Analysen und Machine Learning-Modelle bereitstehen. Die Daten in dieser Schicht haben alle Qualitätsprüfungen bestanden und sind in konsumbereiten Strukturen organisiert – Sternschemata, breite Tabellen, voraggregierte Metriken –, die hochperformante Abfragen unterstützen. Die Medallion-Architektur, die Bronze, Silver und Gold als unterschiedliche Pipeline-Stufen formalisiert, ist das am weitesten verbreitete Muster zur Organisation der Data-Lake-Architektur.

Der Objektspeicher ist das Fundament aller drei Zonen. Formate wie Apache Parquet und Apache ORC bieten eine spaltenbasierte Codierung, die den Speicherbedarf reduziert und analytische Scans beschleunigt. Offene Formate entkoppeln Daten von der Verarbeitungs-Engine eines einzelnen Anbieters, sodass dieselben Dateien von mehreren Tools ohne Kopieren abgefragt werden können.

Kosten für Datenspeicherung und Skalierbarkeit

Kostenvergleiche zwischen Data Lakes und Cloud Data Warehouses müssen Speicher- und Rechenleistung separat berücksichtigen, da moderne Architekturen beide voneinander entkoppeln.

Die Speicherung in Data Lakes auf Cloud-Objektspeicher-Tiers ist erheblich kostengünstiger als proprietärer Warehouse-Speicher – oft um eine Größenordnung beim reinen Preis pro Gigabyte. Für Unternehmen, die große Mengen an Roh- oder historischen Daten speichern, die selten abgefragt werden, senken Cold-Storage-Tiers (Amazon S3 Glacier, Azure Archive) die Kosten weiter, wenn auch mit einer höheren Abruflatenz. Data Lakes sind genau deshalb kostengünstiger als Data Warehouses, weil der Objektspeicher auf Langlebigkeit und Skalierbarkeit ausgelegt wurde, nicht auf Abfrageleistung.

Cloud Data Warehouses nutzen eine Abrechnung pro Abfrage oder pro Recheneinheit. Dies macht sie für regelmäßige, hochwertige Workloads kosteneffizient, aber teuer für Ad-hoc- oder explorative Abfragen auf großen Datensätzen. Pay-as-you-go-Preismodelle bei modernen Cloud Data Warehouses helfen zwar – Sie zahlen für ausgeführte Abfragen statt für eine feste Clustergröße –, aber die Kosten pro verarbeitetem Terabyte an Daten bleiben wesentlich höher als beim Lake-Speicher.

In der Praxis bedeutet dies, dass Entscheidungen über die Datenspeicherarchitektur selten reine Entweder-oder-Entscheidungen sind. Viele Unternehmen speichern aus Kostengründen alle Daten in einem Data Lake und verschieben dann selektiv kuratierte Datensätze in ein Data Warehouse für BI mit hoher Parallelität. Die Duplikationskosten für die Pflege von zwei Kopien – eine im Lake, eine im Warehouse – sind der Haupttreiber für die Einführung von Lakehouses.

Machine Learning und Advanced Analytics für Data Scientists

Data Lakes wurden für Machine Learning entwickelt. Die Möglichkeit, Rohdaten in ihrem nativen Format zu speichern, bedeutet, dass Data Scientists auf die vollständige Detailtreue historischer Daten zugreifen können – und nicht nur auf eine voraggregierte oder durch Schemata eingeschränkte Teilmenge. Dies ist für das Training hochwertiger Modelle unerlässlich.

Feature Engineering für Machine Learning erfordert iterative, explorative Transformationen über verschiedene Datentypen hinweg. Ein Data Scientist, der ein Modell zur Betrugserkennung trainiert, benötigt Transaktionsprotokolle im Rohformat, Geräte-Fingerprint-Daten, Verhaltenssequenzen und den Kontoverlauf – wovon das meiste nicht sauber in ein relationales Schema passt. Data Lakes bieten eine grundlegende Datenkonsistenz über verschiedene Anwendungen hinweg und bewahren gleichzeitig das Rohdatenformat, das ML-Pipelines benötigen.

Data Lakes lassen sich nativ in Data-Science- und Advanced-Analytics-Tools integrieren. Apache Spark, der De-facto-Standard für verteiltes ML in großem Maßstab, liest mithilfe offener Formate direkt aus dem Objektspeicher. Python-Bibliotheken, die für das Modelltraining verwendet werden – PyTorch, TensorFlow, scikit-learn –, greifen über dieselben S3-kompatiblen APIs auf den Lake-Speicher zu. Data Engineers können Streaming-Datenpipelines ausführen, die Echtzeit-Features in Modelle einspeisen, ohne Daten in ein separates System verschieben zu müssen.

Cloud Data Warehouses tragen zu ML-Workflows primär in der Inferenz- und Scoring-Phase bei. Sobald ein Modell trainiert ist, profitiert das operative Scoring auf strukturierten Warehouse-Tabellen – wie das Ausführen einer Churn-Vorhersage auf einer Kundentabelle oder das Scoring von Leads in einem CRM-Export – von der Indexierung und Abfrageoptimierung des Warehouses. Eine ausgereifte ML-Architektur platziert den Feature Store an der Schnittstelle: Die Berechnung der Roh-Features findet im Lake statt, während bereitzustellende Feature-Tabellen in einem Format materialisiert werden, auf das sowohl das Warehouse als auch die Model-Serving-Ebene zugreifen können.

Datenanalysen und BI-Workloads

Business-Intelligence-Workloads – Dashboards, geplante Berichte, Ad-hoc-Abfragen von Business Analysts – haben Anforderungen, die sich grundlegend von Machine Learning unterscheiden. BI-Benutzer benötigen Antworten mit geringer Latenz (unter einer Sekunde beim Laden von Dashboards), konsistente Ergebnisse bei gleichzeitigen Benutzern und Daten, die vereinbarte Geschäftsdefinitionen widerspiegeln, keine rohen Quellwerte.

Cloud Data Warehouses sind speziell für diese Anforderungen konzipiert. Spaltenbasierte Speicherung, Ergebnis-Caching und materialisierte Sichten (Materialized Views) sorgen dafür, dass gängige Dashboard-Abfragen selbst bei wachsendem Datenvolumen in Millisekunden zurückgegeben werden. Eine feingranulare Zugriffskontrolle ermöglicht es Datenanalysten, die Daten ihrer Abteilung abzufragen, ohne sensible Datensätze aus anderen Geschäftsbereichen offenzulegen. Geschäftsanwender können SQL direkt auf strukturierten Tabellen ausführen, ohne die zugrunde liegenden Datenspeicheroptionen oder Dateiformate verstehen zu müssen.

Data Lakes können BI-Workloads über SQL-Abfrage-Engines wie Apache Hive, Presto, Trino oder Spark SQL bedienen, boten jedoch traditionell eine geringere Abfrageleistung im Vergleich zu speziell entwickelten Warehouses. Die Flexibilität von Schema-on-Read bringt einen Aufwand für die Abfrageplanung mit sich, der sich bei hoher Parallelität bemerkbar macht. Für Echtzeit-Dashboards und Business Intelligence mit hoher Parallelität ist ein Cloud Data Warehouse oder ein Lakehouse mit einer leistungsstarken SQL-Ebene die richtige Wahl.

Streaming-Daten für Echtzeit-Dashboards werden immer häufiger genutzt: Sensormesswerte, Website-Clickstreams, Zahlungsereignisse. Sowohl Data Lakes als auch Cloud Data Warehouses unterstützen die Streaming-Ingestion über Konnektoren zu Kafka, Kinesis und ähnlichen Systemen. Die Unterstützung des Lakes für Streaming-Datenpipelines ohne Schema-Einschränkungen macht ihn jedoch zur natürlicheren Landing Zone für hochfrequente Ereignisströme mit variablen Schemata.

Hauptunterschiede: Lake vs. Cloud Data Warehouses

Der folgende Vergleich deckt die Dimensionen ab, die bei Architekturentscheidungen am wichtigsten sind.

Schema-Modell

Data Lakes nutzen Schema-on-Read: Die Struktur wird beim Abfragen der Daten angewendet, nicht beim Schreiben. Jeder Datentyp kann sofort ohne vorherigen Entwurf erfasst werden. Cloud Data Warehouses erfordern Schema-on-Write: Daten müssen vor dem Laden einer vordefinierten Struktur entsprechen. Dies sichert zwar die Datenqualität, verlangsamt jedoch die Erfassung und schränkt die Flexibilität ein. Dieser Unterschied ist der Hauptgrund für die meisten anderen unten aufgeführten Differenzen.

Abfrageleistung

Cloud Data Warehouses bieten eine überragende Abfrageleistung für strukturierte, SQL-basierte Workloads – insbesondere bei hoher Parallelität. Speziell entwickelte spaltenbasierte Engines, intelligentes Caching und Optimierungen bei der Abfragekompilierung ermöglichen Antwortzeiten im Subsekundenbereich für gängige BI-Muster. Traditionelle Data-Lake-Abfrage-Engines sind bei parallelem SQL langsamer, haben sich jedoch mit modernen vektorisierten Engines erheblich verbessert. Data Lakes sind weiterhin schneller bei der groß angelegten Batch-Verarbeitung und bei ML-Trainings-Workloads, bei denen Warehouse-Compute unerschwinglich teuer wäre.

Reifegrad von Data Governance und Kuratierung

Cloud Data Warehouses verfügen über eine ausgereiftere integrierte Governance: Zugriffskontrollen auf Tabellen- und Spaltenebene, Audit-Protokollierung, Data-Lineage-Verfolgung und erzwungene Datentypen gehören zum Standard. Traditionelle Data Lakes erfordern zusätzliche Tools – Datenkataloge, Metadaten-Management-Ebenen, externe Zugriffskontrollsysteme –, um einen vergleichbaren Governance-Reifegrad zu erreichen. Die Lücke hat sich mit Katalogdiensten wie Unity Catalog erheblich verkleinert, aber Warehouses haben für Organisationen mit strengen Compliance-Anforderungen immer noch einen Vorsprung.

Kosten pro Terabyte

Data Lakes speichern Daten zu wesentlich geringeren Kosten pro Terabyte als Cloud Data Warehouses – je nach Speicherklasse und Abfragehäufigkeit oft 10- bis 100-mal günstiger. Bei großen Datenmengen, historischen Daten und der Erfassung von Rohdaten ist der Kostenvorteil des Lakes entscheidend. Für kuratierte, häufig abgefragte Geschäftsdaten rechtfertigt die Leistung des Warehouses die höheren Kosten.

Unterstützte Datentypen und -formate

Data Lakes unterstützen alle Datentypen: strukturierte relationale Exporte, semistrukturierte JSON- und XML-Dateien, unstrukturierten Text, Bilder, Audio- und Binärdateien. Warehouses sind für strukturierte Daten in Datenbanktabellen optimiert und bieten nur eingeschränkte oder gar keine native Unterstützung für unstrukturierte und semistrukturierte Daten. Das Speichern unterschiedlicher Daten – Protokolldateien neben Finanztransaktionen und Bildmetadaten – ist ein klassischer Anwendungsfall für einen Lake.

Primäre Benutzer-Personas

Data Engineers und Data Scientists sind die Hauptnutzer von Data-Lake-Umgebungen: Sie benötigen direkten Zugriff auf alle Rohdaten in ihrem nativen Format für die Pipeline-Entwicklung und das Modelltraining. Datenanalysten und Geschäftsanwender sind die Hauptnutzer von Cloud Data Warehouses: Sie benötigen saubere, zuverlässige und schnell reagierende Daten für SQL-Abfragen und Berichte. Data Lakehouses bedienen beide Personas über eine einzige Plattform, was der Hauptgrund für ihre schnelle Verbreitung ist.

Data Lakehouses: Die Brücke zwischen Lakes und Warehouses

Ein Data Lakehouse ist eine Datenplattform-Architektur, die den kostengünstigen, flexiblen Speicher eines Data Lakes mit den Datenverwaltungsfunktionen und der Abfrageleistung eines Data Warehouses kombiniert – auf einem einzigen, einheitlichen System. Das Lakehouse eliminiert die teuersten Betriebskosten der Zwei-System-Architektur: die Pflege einer separaten Kopie kuratierter Daten im Warehouse.

Die transaktionale Speicherebene ist die entscheidende Innovation. Offene Tabellenformate – Delta Lake, Apache Iceberg und Apache Hudi – bringen ACID-Transaktionsunterstützung direkt in den Objektspeicher. ACID-Transaktionen stellen sicher, dass jeder Schreibvorgang entweder vollständig erfolgreich ist oder vollständig rückgängig gemacht wird, was eine Datenbeschädigung durch gleichzeitige Schreibvorgänge verhindert. Diese Garantie, die Data Warehouses seit Jahrzehnten bieten, war in Data Lakes historisch nicht verfügbar. Lakehouses bieten ACID-Transaktionsunterstützung für Datenzuverlässigkeit, während das offene Format und die Kostenstruktur des Lakes beibehalten werden.

Delta Lake ist das am weitesten verbreitete Lakehouse-Tabellenformat. Es speichert Daten in Parquet-Dateien im Cloud-Objektspeicher und führt ein Transaktionsprotokoll, das jede Schemaänderung, jeden Insert, jedes Update und jeden Delete aufzeichnet. Die Time-Travel-Funktion – abfragbar über SQL – ermöglicht es Data Scientists und Auditoren, jeden historischen Snapshot einer Tabelle zu lesen. Automatische Dateikomprimierung und Data-Skipping-Indizes beschleunigen die Abfrageleistung ohne manuelles Tuning. Delta Lake ist eine gängige Technologie in Lakehouse-Architekturen, da sie Open Source und Cloud-agnostisch ist und sich nativ in Apache Spark und SQL-Engines integrieren lässt.

Apache Iceberg und Apache Hudi bieten ähnliche Funktionen mit unterschiedlichen Design-Kompromissen. Iceberg bietet eine stärkere Schema-Evolution und versteckte Partitionierung (Hidden Partitioning) für komplexe analytische Workloads. Hudi ist auf Upserts auf Datensatzebene und Streaming-Ingestion-Muster spezialisiert. Alle drei Formate werden durch offene Standards wie Apache XTable zunehmend interoperabel.

Bis 2025 werden Lakehouses mehr als die Hälfte der Analytics-Workloads in Unternehmen ausmachen – angetrieben durch die betriebliche Einfachheit, eine einzige Plattform zu verwalten, anstatt einen Lake und ein Warehouse zu synchronisieren. Für Unternehmen, die eine neue Datenplattform aufbauen, ist das Lakehouse der praktische Standard.

Integrationsmuster mit relationalen Datenbanken und Data Marts

Zu verstehen, wo der Data Lake und das Cloud Data Warehouse im Vergleich zu anderen Systemen positioniert sind, verdeutlicht, wann welches System am besten eingesetzt wird.

Relationale OLTP-Datenbanken (Online Transaction Processing) – MySQL, PostgreSQL, Oracle – sind nach wie vor das maßgebliche System (System of Record) für operative Anwendungen. Sie sind für schreibintensive transaktionale Workloads optimiert: Bestellungsverwaltung, Bestandsverfolgung, Benutzerauthentifizierung. Analytische Workloads sollten nicht direkt auf OLTP-Datenbanken ausgeführt werden, da die Abfragelast mit den Anwendungstransaktionen konkurriert. Das Standardverfahren besteht darin, OLTP-Daten über Change Data Capture (CDC) in den Lake oder das Warehouse zu replizieren – eine Methode, die Änderungen auf Zeilenebene aus der Quelldatenbank als Events streamt, ohne die operative Leistung zu beeinträchtigen.

Data Marts sind themenspezifische Teilmengen eines größeren Data Warehouse oder Lake, die für eine bestimmte Geschäftsfunktion organisiert sind – Finanzen, Marketing, Lieferkette. Sie stellen kuratierte, vorab zusammengeführte Datensätze bereit, die Business-Analysten abfragen können, ohne das gesamte Datenmodell des Unternehmens verstehen zu müssen. Data Marts sind weiterhin in Organisationen relevant, in denen verschiedene Abteilungen unterschiedliche Governance-Anforderungen haben oder in denen eine Abfrageisolierung für die Performance erforderlich ist. In einer Lakehouse-Architektur erfüllen Tabellen der Gold-Schicht effektiv die Funktion eines Data Marts, ohne dass ein separates physisches System erforderlich ist.

ETL (Extract, Transform, Load) ist das geeignete Muster für das Laden in Schema-on-Write-Systeme: Transformationen werden angewendet, bevor die Daten in das Warehouse gelangen, was die Konformität mit dem Zielschema sicherstellt. ELT (Extract, Load, Transform) ist das geeignete Muster für Schema-on-Read-Systeme: Rohdaten landen zuerst im Lake, und Transformationen werden dann zum Abfragezeitpunkt oder in Pipeline-Stufen angewendet. Die meisten modernen Datenplattformen nutzen ELT für die Lake-Ingestion und wenden anschließend eine Kuratierung im ETL-Stil an, um Tabellen der Gold-Schicht zu erstellen.

Sicherheit, Governance und Compliance

Data Governance in einem Cloud Data Lake erfordert gezielte Investitionen, die Warehouse-Systeme standardmäßig bieten.

Die Zugriffskontrolle auf Dateiebene – das Verhindern, dass unbefugte Benutzer Rohdaten im Objektspeicher lesen – ist die grundlegende Anforderung. Cloud-Anbieter bieten Zugriffsrichtlinien auf Bucket- und Präfixebene, aber feingranulare Kontrollen auf Spalten- und Zeilenebene erfordern eine zusätzliche Governance-Schicht. Unity Catalog, die einheitliche Governance-Plattform von Databricks, bietet Sicherheitsrichtlinien auf Tabellen-, Spalten- und Zeilenebene für Lake- und Warehouse-Tabellen über eine einzige Benutzeroberfläche und nutzt dabei die standardmäßige SQL-DCL-Syntax, die Datenbankadministratoren bereits kennen.

Datenkatalog und Metadatenverwaltung bilden die zweite Governance-Schicht. Ein Katalog erfasst, welche Tabellen existieren, wie ihre Schemata aussehen, wer ihr Eigentümer ist und wie sie erstellt wurden – die Data Lineage von der Quelle bis zur Nutzung. Ohne einen Katalog werden Data Lakes zu Datensümpfen (Data Swamps): Repositories, in denen sich Daten ohne Dokumentation ansammeln und Engineers mehr Zeit mit der Suche nach Daten als mit deren Analyse verbringen. Die automatisierte Lineage – die Verfolgung des Transformationspfads von der Bronze-Ingestion über Silver-Joins bis hin zu Gold-Aggregaten – ist unerlässlich für das Debugging von Pipelines, die Validierung der Compliance und das Verständnis der Auswirkungen von Schemaänderungen.

Eine Verschlüsselung ist für alle ruhenden Daten (Data at Rest) und Daten in Übertragung (Data in Transit) erforderlich. Cloud-Objektspeicher verschlüsseln ruhende Daten standardmäßig mittels serverseitiger Verschlüsselung, und die Übertragung ist immer über TLS verschlüsselt. Organisationen mit strengeren Anforderungen verwalten ihre eigenen Verschlüsselungsschlüssel mithilfe von Customer-Managed Keys (CMK) über Cloud-Schlüsselverwaltungsdienste. So wird sichergestellt, dass selbst der Cloud-Anbieter Daten nicht ohne ausdrückliche Autorisierung entschlüsseln kann.

Entscheidungsrahmen für Migration und Architektur

Die Wahl zwischen einem Data Lake, einem Cloud Data Warehouse und einem Data Lakehouse erfordert die Abstimmung der architektonischen Funktionen auf die Workload-Anforderungen.

Beginnen Sie mit einer Bewertung der Workload-Eignung. Katalogisieren Sie Ihre Analyse-Workloads nach Hauptnutzern (Data Scientists, Analysten, Business-Anwender), erforderlichen Datentypen (strukturiert, semistrukturiert, unstrukturiert), Abfragemustern (Batch, interaktiv, Streaming) und Latenzanforderungen (Sekunden, Minuten, Stunden). Workloads, die von strukturiertem SQL-Reporting dominiert werden, lassen sich am besten auf Warehouses abbilden. Workloads, die verschiedene Datentypen, ML-Modelltraining oder zukünftige Flexibilität erfordern, passen am besten zu Lakes. Gemischte Workloads lassen sich auf Lakehouses abbilden.

Evaluieren Sie die Kosten parallel zur Performance. Ein bestehendes Data Warehouse erbringt für aktuelle Workloads möglicherweise eine akzeptable Leistung. Berechnen Sie jedoch die Gesamtkosten einschließlich des Speichers für andernorts liegende Rohdaten, der Kosten für Datenduplizierung und des Entwicklungsaufwands für die Wartung von Synchronisations-Pipelines. Für die meisten Organisationen, die mehr als ein paar Terabyte an Rohdaten speichern, summiert sich der Kostenvorteil des Lake-Speichers im Laufe der Zeit erheblich.

Bewerten Sie die Fähigkeiten Ihres Teams ehrlich. Cloud Data Warehouses bieten leichter zugängliche Tools für SQL-fokussierte Analyse-Teams. Data Lakes erfordern größere Investitionen im Engineering-Bereich für die Pipeline-Entwicklung, das Katalogmanagement und Governance-Tools. Lakehouses verringern diese Lücke, erfordern jedoch für umfangreiche Workloads weiterhin Kenntnisse in Spark oder einer gleichwertigen verteilten Verarbeitung.

Für Organisationen, die von einem traditionellen Data Warehouse migrieren, ist ein phasenweises Vorgehen am effektivsten. Identifizieren Sie in der Pilotphase einen einzelnen, besonders wertvollen Workload – einen spezifischen ML-Anwendungsfall oder einen Datentyp, den das bestehende Warehouse nur unzureichend verarbeiten kann – und übertragen Sie ihn in den Lake oder das Lakehouse. Messen Sie die tatsächlichen Kosten-, Performance- und Governance-Ergebnisse im Vergleich zum bestehenden System, bevor Sie expandieren. Dies verhindert das häufige Scheitern einer Big-Bang-Migration, die die produktive Analytik stört, bevor die neue Architektur validiert ist.

Die Wahl zwischen Data Lake, Warehouse und Lakehouse

Der Entscheidungsrahmen vereinfacht sich je nach primärem Workload-Typ auf drei Pfade.

Wenn Ihr Workload von Machine Learning, Data-Science-Experimenten oder der Speicherung großer Mengen an Rohdaten oder unstrukturierten Daten dominiert wird, beginnen Sie mit einem Data Lake. Die Kosteneffizienz und die Formatflexibilität sind entscheidende Vorteile, und Sie können später eine SQL-Abfrageschicht hinzufügen, wenn die Reporting-Anforderungen steigen.

Wenn Ihr Workload von strukturierter SQL-Analytik, Dashboards mit hoher Parallelität und Business-Reporting mit strengen Latenzanforderungen dominiert wird und Ihre Daten an der Quelle bereits strukturiert sind, bietet ein Cloud Data Warehouse das beste Preis-Leistungs-Verhältnis für diesen spezifischen Anwendungsfall.

Wenn Ihr Unternehmen beide Arten von Workloads ausführt – oder plant, beide innerhalb der nächsten 12 bis 18 Monate einzuführen –, sollten Sie von Anfang an auf eine Lakehouse-Architektur setzen. Die Kosten für die spätere Migration einer ausgereiften Zwei-System-Architektur auf ein einheitliches Lakehouse sind erheblich höher als der anfängliche Aufbau auf einer einheitlichen Basis.

In jedem Fall sollten Sie Ihre Annahmen mit einem Pilotprojekt validieren, bevor Sie sich für eine vollständige Migration entscheiden. Definieren Sie vor Beginn des Pilotprojekts messbare Erfolgsmetriken: Abfragelatenz bei P95, Kosten pro Terabyte und Monat, Zeit von der Rohdaten-Ingestion bis zu analysebereiten Daten sowie das Verhältnis von Pipeline-Wartung zur Entwicklung neuer Features. Diese Metriken bieten eine objektive Grundlage für Architektur-Entscheidungen, die andernfalls zu internen Diskussionen führen würden.

FAQs und verbreitete Missverständnisse

Ersetzt ein Data Lake in jedem Fall ein Cloud Data Warehouse?

Ein Data Lake ersetzt ein Cloud Data Warehouse nicht in allen Fällen. Data Lakes eignen sich hervorragend für die kostengünstige Speicherung von Rohdaten in verschiedenen Formaten und zur Unterstützung von Machine-Learning-Workloads. Herkömmliche Data Lakes bieten jedoch bei SQL-Workloads mit hoher Parallelität eine langsamere Abfrageleistung als speziell dafür entwickelte Warehouses. Organisationen mit ausgereiften Business-Intelligence-Anforderungen profitieren von einem Cloud Data Warehouse oder einem Lakehouse – einer einheitlichen Architektur, die eine Abfrageleistung auf Warehouse-Niveau direkt auf dem Lake-Speicher bietet.

Wie unterscheidet sich ein Data Lake von einer herkömmlichen relationalen Datenbank?

Ein Data Lake speichert Rohdaten in ihrem nativen Format im Objektspeicher ohne vordefiniertes Schema, während eine relationale Datenbank ein festes Schema erzwingt, strukturierte Daten in Datenbanktabellen speichert und für transaktionale Workloads optimiert ist – also das Einfügen und Aktualisieren einzelner Datensätze. Data Lakes sind für analytische und Machine-Learning-Workloads im Petabyte-Bereich konzipiert; relationale Datenbanken sind für operative Anwendungen ausgelegt, die ACID-Transaktionen mit geringer Latenz auf einzelnen Zeilen erfordern.

Was ist der Unterschied zwischen einem Data Lake und einem Data Lakehouse?

Ein Data Lake speichert Rohdaten im Objektspeicher ohne transaktionale Garantien, was gleichzeitige Schreibvorgänge und die Schema-Evolution komplex macht. Ein Data Lakehouse fügt eine offene Tabellenformatschicht hinzu – wie Delta Lake, Apache Iceberg oder Apache Hudi –, die ACID-Transaktionsunterstützung, Schemaerzwingung und Datenqualitätsüberwachung direkt auf dem Lake-Speicher bietet. Lakehouses bieten sowohl die Flexibilität und Kosteneffizienz eines Lake als auch die Zuverlässigkeit und Abfrageleistung eines Warehouse, ohne dass eine Datenduplizierung erforderlich ist.

Wann sollte ich einen Data Mart anstelle eines Data Lake oder Warehouse verwenden?

Verwenden Sie einen Data Mart, wenn eine bestimmte Geschäftsfunktion – Finanzen, Marketing, Vertrieb – einen kuratierten, vorab zusammengeführten Datensatz erfordert, der für die Abfragemuster dieser Funktion optimiert ist, und wenn die Isolierung dieses Datensatzes von der umfassenderen Unternehmensdatenplattform aus Governance- oder Performance-Gründen erforderlich ist. In einer Lakehouse-Architektur erfüllen Tabellen der Gold-Schicht effektiv die Data-Mart-Funktion, wodurch der Bedarf an separaten physischen Data Marts und der damit verbundenen Synchronisationskomplexität verringert wird.

Was macht einen Data Lake zu einem "Data Swamp" und wie kann ich das verhindern?

Ein Data Lake wird zu einem Data Swamp, wenn sich Daten ohne angemessenes Metadatenmanagement, Datenqualitätskontrollen oder Access Governance ansammeln – was es für Benutzer schwierig macht, die benötigten Daten zu finden, ihnen zu vertrauen oder auf sie zuzugreifen. Die Prävention erfordert drei Kontrollen: einen Datenkatalog, der Tabellenschemata, Eigentümerschaft und Lineage dokumentiert; Datenqualitätsprüfungen, die in jeder Pipeline-Stufe (Bronze, Silver, Gold) angewendet werden; und Zugriffskontrollen, die verhindern, dass unbefugte Schreibvorgänge kuratierte Datensätze verunreinigen. Die Medallion-Architektur erzwingt eine Qualitätssteigerung, die Rohdaten von produktionsreifen Tabellen isoliert hält.

Anhang: Technische Muster und Tools

Beispielarchitekturen für Batch und Streaming. Ein standardmäßiges Batch-Ingestion-Muster lädt täglich Exporte aus Quellsystemen in den Bronze-Lake-Speicher, wendet Bereinigungstransformationen für Silver an und materialisiert Gold-Aggregate für die BI-Nutzung. Ein Streaming-Muster verwendet Apache Kafka oder Cloud-Event-Streaming-Dienste, um Ereignisse in Fast-Echtzeit an Bronze zu liefern, wobei inkrementelle Silver- und Gold-Updates durch Streaming-Tabellen-Frameworks gesteuert werden. Beide Muster laufen auf demselben Lake-Speicher, wobei Delta Lake die Transaktionsisolation zwischen den beiden Ingestion-Modi übernimmt.

Beliebte Tools nach Layer. Für Ingestion: Lakeflow, Apache Kafka, Cloud-native CDC-Dienste. Für Transformation: Apache Spark (PySpark, Spark SQL), dbt (für SQL-zentrierte Teams). Für Orchestrierung: Apache Airflow, Cloud-native Workflow-Dienste. Für SQL-Analytics: Databricks Lakehouse, BigQuery, Snowflake, Amazon Redshift. Für Governance: Unity Catalog, Apache Atlas, Cloud-native Katalogdienste. Für ML: MLflow, Apache Spark MLlib, Cloud-native Modelltraining-Dienste.

Vorlagen für das Schemadesign. Für BI-Tabellen im Gold-Layer bleiben Sternschemata im Kimball-Stil – eine zentrale Faktentabelle, die von Dimensionstabellen umgeben ist – der Standard für die Dashboard-Performance. Faktentabellen enthalten Ereignisse (Transaktionen, Sitzungen, Konvertierungen); Dimensionstabellen enthalten Entitätsattribute (Kunde, Produkt, Filiale). Für ML-Feature-Tabellen minimieren breite, denormalisierte Tabellen mit einer Zeile pro Entität und allen Features als Spalten die Join-Komplexität während des Trainings. Für Streaming-Analytics ermöglichen Append-only-Ereignistabellen mit Partitionierung nach Ereignis-Zeitstempel effiziente Zeitbereichs-Scans für Echtzeit-Dashboards.

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag