Data Lake vs Data Warehouse?

Viele Denken, ein Data Lake und Data Warehouse seien dasselbe - ein Datenspeicher. Aber ein Unterschied ist: Während ein Data Warehouse üblicherweise auf einem Server läuft, ist ein Data Lake ein Verbund an unterschiedlichen Computer, um ein skalierbarer Massenspeicher und Verarbeitungsprozessor zu sein. Doch es gibt noch mehr Unterschiede, die Vor- und Nachteile der beiden Technologien zeigen.

#TL;DR

• Unterschiedliche Zwecke. Data Warehouses werden von Analysten, Managern und anderen Business Usern verwendet. Data Lakes hauptsächlich von Data Engineers und Data Scientists. In Data Lakes liegen hauptsächlich unstrukturierte und unverarbeitete Daten gespeichert, z.B. Protokolle des Benutzerverhaltens oder Telemetriedaten, Bilder, sowie andere Daten in den unterschiedlichen Formaten. Diese sind nicht für die Analyse in BI-Systemen geeignet, können aber von Data Scientists genutzt werden, um neue Geschäftshypothesen mithilfe statistischer Machine Learning oder Deep Learning Algorithmen.
• Verschiedene Verarbeitungsmethoden. ETL (Extract, Transform, Load) ist ein beliebtes Datenverarbeitungsparadigma in vielen gängigen Data-Warehousing-Systemen. Im Prinzip extrahiert man Daten aus einer oder mehreren Quellen, bereinigt, konvertiert sie in die benötigte strukturierten Datenform und lädt sie hoch. Bei Data Lakes verwenden man ein anderes Paradigma: ELT (Extract, Load, Transform), da die Umwandlung erst in späteren Phasen und nur bei Bedarf und nicht im Voraus erfolgt.
• Unterschiedliche Verständnisses der Daten. In Data Lakes werden Daten niemals verworfen, da sie in einem unverarbeiteten Format gespeichert werden. Dies ist besonders in einer Umgebung mit großen Datenmengen nützlich, wenn man nicht im Voraus weiß, welche Informationen aus der Datenanalyse gewonnen werden sollen. Gleichzeitig bildet als zentrale Datenbank die Grundlage der Data Warehouse-Umgebung. In der Regel basieren diese auf Relationelle Datenbank, so dass eine Planung des Datenmodells erforderlich ist.
• Verschiedene Design-Ansätze. Das Data Warehouse-Design basiert auf der relationalen Datenverarbeitungslogik - der dritten Normalform, Star- oder Snowflake-Schema. Bei der Konzeption des Data Lake muss man die Vielfalt der Informationsquellen und -verbraucher berücksichtigen. Die Frage der Speicherung ist ganz einfach gelöst - man braucht nur ein skalierbares, fehlertolerantes und relativ günstiges Dateisystem wie HDFS oder einen Blob-Speicher wie AWS S3.
• Unterschiedliche Preise. In der Regel wird der Data Lake auf der Grundlage kostengünstiger Server mit Apache Hadoop und dem HDFS Dateisystem aufgebaut, ohne teure Lizenzen und leistungsstarke Hardware. Im Gegensatz zu den hohen Kosten für die Entwicklung, Wartung und den Kauf spezialisierter Plattformen für das Data Warehouse, wie SAP, Oracle, usw.
• Skalierbarkeit. Die Entkopplung von Speicherung und Berechnung bringt enorme Verbesserungen in Bezug auf Skalierbarkeit, Flexibilität, Agilität und Betriebseffizienz und bietet gleichzeitig Kostenvorteile. Ein Data Warehouse lässt sich in der Regel nur vertikal skalieren während Data Lakes horizontal skalieren. Data Warehouse besteht aus teuren, mehrfach parallel verarbeitenden Datenbanken mit teurer Hardware. Vertikale Skalierbarkeit bedeutet, man muss den Server aufrüsten. Mehr RAM, mehr CPU-Kernen. Bei einem Data Lake hingegen nutzt man Standard-Hardware und schließt einfach weitere günstigere Computer an den Data Lake an.

Bevor wir auf den Vergleich zwischen Data Warehouse und Data Lake eingehen. Kurz ein berühmtes Zitat von James Dixon, dem CTO von Pentaho eingeschoben.

If you think of a data warehouse as a store of bottled water – cleansed and packaged and structured for easy consumption. The data lake is a large body of water in a more natural state. The contents of the data lake stream in from a source to fill the lake, and various users of the lake can come to examine, dive in, or take samples.

Diese bekannte Analogie besagt, dass ein Data Warehouse mit einem Wasserhersteller vergleichbar ist, bei dem man eine Flasche Wasser in einer bestimmten Größe und Form bekommt. Im Gegensatz dazu ist ein Data Lake wie ein See, der mit vielen Quellen gespeist wird und sich jeder das Wasser holen kann, das er braucht.

Mit dieser Analogie können wir nun anfangen die Konzepte eines Data Lake und Data Warehouse versuchen zu verstehen.

#Data Warehouse

Das Data Warehouse (DWH) verfügt über einen einzigen Speicherort (einen Server), der mithilfe verschiedener ETL-Prozesse aus unterschiedlichen Quellen gespeist wird. Die angeschlossenen Datenquellen (Buchhaltungs-, Rechnungs- und sonstige Systeme) können sehr unterschiedlich sein, was zu abweichenden Informationen führen kann. Die große Vielfalt an Schemata und Strukturen in den Datenquellen macht es schwierig, konsolidierte Informationen zu erhalten, wenn eine vollständige Momentaufnahme der Daten aus allen Teilsystemen des Unternehmens benötigt wird. Dies ist im allgemeinen Hauptgrund für Data-Warehouse-Lösungen, um hier eine Single Source of Truth zu erstellen.

Data Warehouse hat eine komplexe mehrstufige Architektur, die LSA - Layered Scalable Architecture - genannt wird. LSA implementiert eine logische Aufteilung von Strukturen mit Daten in mehrere funktionale Ebenen. Die Daten werden von Ebene zu Ebene kopiert und transformiert, um schließlich als konsistente, für die Analyse geeignete Informationen zur Verfügung zu stehen.

#Staging Area

Hier werden die Informationen aus den Quellsystemen in ihrer ursprünglichen Qualität geladen. Auf dieser Schicht werden in der Regel ETL-Pipelines verwendet, um Daten aus den Quellsystemen in das Data Warehouse zu übertragen.

#Core Layer

Diese Schicht ist eine operative Komponente, die die Aggregation, Normalisierung, Deduplizierung und Bereinigung von Daten durchführt, um am Ende eine gemeinsame Struktur zu erhalten. Hier findet die Hauptarbeit in Bezug auf Datenqualität und -transformationen statt, um logischen Anordnung der Datenquellen zu abstrahieren. Alle Transformationen und Aktualisierungen des Systemzustands werden vom Datenmodell abgeleitet.

Das Datenmodell ist eine Spezifikation aller Entitäten und Objekte im Data Warehouse. Das Modell definiert die Entitäten/ Eigenschaften und die Beziehungen zwischen den Geschäftsbereich und die gesamte Datenbankstruktur.

Es gibt verschiedene Ansätze für die Architektur in dieser Schicht, die zwei bekanntesten sind Kimball und Inmon. Dies ist wichtig und hat einen großen Einfluss auf die Struktur des Data Warehouse.

#Reporting Layer

In dieser Schicht werden die verarbeiteten, bereinigten und aggregierten Daten in eine Struktur umgewandelt - sogenannten Data Marts - die sich leicht analysieren und in BI-Dashboards oder anderen Verbrauchersystemen verwenden lassen. Hier kann auch eine Denormalisierung der Daten stattfinden.

#Service Layer

Diese Schicht steuert alle oben beschriebenen Schichten. Sie enthält keine Daten, verwaltet aber Metadaten und andere Datenqualitätsstrukturen und ermöglicht eine durchgängige Datenprüfung, MDM, Data Governance, Sicherheit, Monitoring.

Ein DWH enthält Fakten als auch analytische Ergebnisse. Die Business-User können diese Informationen jederzeit abrufen, wenn sie für persönliche und geschäftliche Zwecke benötigt werden. Dies kann nicht nur für strategische Entscheidungen nützlich sein, sondern auch für die Finanzverwaltung, strategische Entscheidungen und den Vertrieb.

Trotz seiner Vorteile ist die Speicherung und Verwaltung von Daten im Data Warehouse kostspielig und zeitaufwendig. Das Data Warehouse ist ideal für operative Nutzer, da es gut strukturiert und einfach zu bedienen ist.

Data Warehouse ist eine ausgereift und bewährt Technologie. Die Datenmodellierung ist auch heute noch relevant. Aber im letzten Jahrzehnt hat eine Reihe an Faktoren die Idee eines Data Warehouse vorangetrieben, und zwar die des Data Lakes.

#Data Lake

Faktoren, die ein Veränderung hervorriefen:

• Skalierbarkeit. Entkoppelung von Speicherung und Datenverarbeitung bringt ein hohes Maß an Flexibilität, Skalierbarkeit, betrieblicher Effizienz.
• Die Fülle an unstrukturierten Daten. Nicht alles ist tabellarisch, es gibt Formate wie Text, xml, json, Sensordaten, Bilder usw., um nur einige zu nennen.
• Riesige Datenmengen. Daten aus sozialen Netzwerken, Sensordaten und maschinengenerierte Daten, z.B. von Smartwatches oder ähnlichen Geräten.
• Neue Arten der Analysen. Die zuvor nicht möglich waren, wie die auf Grundlage von Deep Learning funktionieren, wie Recommendation Systems, Object Detection System (Yolo),...
• Neue Rollen in der Organisation. Da Daten zu einem Vermögenswert von höchstem Wert wurden (Daten sind das neue Öl), entstanden neue Rollen wie Data Scientist und Data Engieners, die den Wert der Daten bestimmen und daraus Insights generieren.

Die Entkopplung von Speicherung und Verarbeitung bringt enorme Verbesserungen in Bezug auf Skalierbarkeit, Flexibilität, Agilität und Betriebseffizienz und bietet gleichzeitig Kostenvorteile. Für alle Layer können handelsübliche kostengünstigen Hardware genutzt werden, diese werden im Verbund zu einem Cluster zusammengefügt und lässt sich viel besser skalieren, während gleichzeitig Ausfallzeiten reduziert werden. Wenn noch ein Cloud-Anbieter genutzt wird, profitieren man von Skaleneffekten.

Data Warehouses können zwar unstrukturierte Daten verarbeiten, aber nicht effizient. Bei großen Datenmengen kann die Speicherung in einer Datenbank oder einem Data Warehouse teuer werden. Ferner müssen die Daten, die in Data Warehouses eingehen, verarbeitet werden, bevor sie in einem Schema oder einer Struktur gespeichert werden können. Mit anderen Worten: Ein Datenmodell muss existieren, was nicht immer möglich ist.

Data Lakes speichern Rohdaten und können ohne vorherige Festlegung der Struktur betrieben werden. Im Falle des Data Lake sollte der Endbenutzer die Informationen selbst strukturieren, dies nennt sich Schema-on-Read. Das Tolle daran ist, dass die im Data Lake gespeicherten Daten bei einem Abruf oder einer Analyse nicht verändert werden – sie bleiben in genau demselben Format, in dem sie gekommen sind. Dadurch erhält man Flexibilität, die ein Data Warehouse nicht hat.

Damit unterscheidet sich der Data Lake deutlich vom Data Warehouse. Der architektonische Ansatz von LSA kann jedoch auch für den Aufbau eines Data Lake verwendet werden.

• Auf der Raw Data Layer werden Rohdaten in verschiedenen Formaten in ihrer ursprünglichen Form gespeichert (tsv, csv, parquet, json, etc)
• Auf der operativen Ebene (Processed Data Store) werden die Rohdaten in jede gewünschte Form umgewandelt. Hier wählen wir das Format aus, das sich am besten für die weitere Verarbeitung eignet. Die Struktur ist die gleiche wie in der vorhergehenden Ebene, kann aber bei Bedarf auf eine niedrigere Körnung aufgeteilt werden.
• Data Mart. Die Daten werden in konsumierbare Datensätze umgewandelt und können in Dateien oder Tabellen gespeichert werden. Der Zweck der Daten sowie Struktur sind in diesem Stadium bereits bekannt. Bereinigungen und Transformationen sollten vor dieser Schicht durchgeführt werden.

Man kann sich darüber streiten, wie die Data Mart-Komponente mit dem Data Lake zusammenhängt. Es stimmt - die Daten können hier nicht nur aus dem Data Lake, sondern auch aus dem Data Warehouse übernommen werden. Diese Schicht kann auch weggelassen werden, was auch Sinn ergibt, wenn es ein separates Data Warehouse existiert, das Daten aus dem Data Lake bezieht. Wichtig ist, dass Daten und Data Mart Layer überschaubar sein müssen und mit dem Data Lake und seinen Prozessen gekoppelt werden sollten.

Häufig werden Data Lakes verwendet, um Informationen zu speichern, die man aktuell nicht nutzen kann, aber in Zukunft für das Unternehmen von Nutzen sein könnten. Wenn Data Lakes jedoch schlecht verwaltet werden, sammeln sie schnell riesige Mengen an unkontrollierten Daten an, die meist nutzlos sind. Es ist nicht mehr klar, woher sie stammen und wann sie entstanden sind, wie relevant sie sind und ob sie für Analysen verwendet werden können oder nicht. So entstehen Datensümpfe – nutzlos und die Ressourcen des Unternehmens verschlingend. Um dies zu verhindern, muss das Unternehmen einen Datenmanagementprozess, der sich Data Governance nennt, einführen. Der Hauptteil dieses Prozesses besteht darin, die Korrektheit und Qualität der Daten zu bestimmen, noch bevor sie in den Data Lake geladen werden. Daher muss bei der Konzeption eines Data Lake zunächst der Zweck festgelegt werden.

#Lakehouse – Data Lake Evolution

Data Lakes eignen sich zwar für die Speicherung von Daten, doch fehlen ihnen einige wichtige Funktionen, die man aus üblichen Datenbanken kennt: Keine Transaktionen, keine Datenqualitätsmanagements, komplexe Datenlösungskonzepte, Batch- und Streaming-Aufträge zu kombinieren. Daher haben sich viele der Versprechungen von Data Lakes nicht erfüllt, was dazu führt, dass viele der Vorteile von Data Warehouses verloren gehen.

Um diese Grenzen von Data Lake und Data Warehouse zu überwinden, gibt es Lakehouse. Die wichtigsten Lösungen sind Delta Lake von Databricks, Apache Hudi von Uber und Apache Iceberg von Netflix. Hier wird noch mal eine Abstraktionsschicht über den Storage-Layer eingeführt.

#Fazit

Da das Datenvolumen weiter zunimmt und wenn die bestehende Infrastruktur des Unternehmens nicht skalierbar ist. Dann kann der Aufbau eines Data Lake für das Unternehmen die Lösung der aktuellen Architektur sein. Gerade mit den neuen Features, die Hudi und Iceberg mit sich bringen,

#Kurze tabellarische Übersicht

Nach dem unstrukturierten Text, jetzt eine tabellarische Darstellung

	Data Warehouse	Data Lake
Datenform	strukturierte tabellarische Daten	alle Formen (strukturiert und unstrukturiert)
Datenwert	nur mit hohen Wert	mittel bis hochwertige und noch-zu-entdecken Wert
Datenqualität	Hoch mit Bemühungen um Konsistenz und klare Regeln	Gemischt, einige Daten im Rohformat, einige Daten werden in eine höhere Qualität umgewandelt
Datenmodell	Star, Snowflake und Data Marts	Star, Snowflake und andere ad-hoc Repräsentationen
Datenerfassung	ETL	ELT
Schema	Starre Struktur (Schema-on-write)	On-the-fly zum Zeitpunkt der Analyse (schema-on-read)
Technologie	Teure, mehrfach parallel verarbeitende Datenbank mit teuren Festplatten und Konnektivität	Handelsübliche Hardware mit Parallelität als erstes Prinzip
Benuzer	Geschäftliche Nutzer (BI-Analysten, Manager,..)	Data scientists, Business analysts, ML engineers