Data Engineering ist ein sich ständig weiterentwickelndes Feld, in dem ständig neue Konzepte und Ideen auftauchen. Obwohl die Begriffe Data Lake, Data Warehouse und Data Lakehouse eng miteinander verwandt sind, bezeichnen sie unterschiedliche Architekturansätze. Da Unternehmen mehr denn je auf Daten angewiesen sind, ist es wichtig, die Unterschiede zwischen diesen Architekturansätzen zu verstehen. In diesem Beitrag gehen wir auf die wichtigsten architektonischen Unterschiede zwischen diesen Konzepten ein. Lassen Sie uns eintauchen!

Data Warehouse

Das Konzept des Data Warehouse wurde vor mehr als 50 Jahren entwickelt. Die Hauptidee besteht darin, Zugang zu hochwertigen, vertrauenswürdigen Daten zu bieten, die die Entscheidungsfindung auf Unternehmensebene erleichtern. Zu den Funktionen eines Data Warehouse gehören also:

• Datenkonsolidierung: Die Daten werden aus verschiedenen Datenquellen, operativen Datenbanken, Dateien und verschiedenen externen Quellsystemen gesammelt.
• Datenspeicherung: Ein Data Warehouse verwendet eine relationale Datenbank, um die Daten in einem für effiziente Abfragen geeigneten Format zu speichern.
• Datenverbrauch: Erstellen Sie direkt Berichte oder verwenden Sie Business Intelligence-Tools für flexible Berichte und Analysen.

Die High-Level-Architektur:

Ein typisches modernes Data Warehouse kann aus den folgenden Komponenten bestehen:

• Ein Tool zur Datenextraktion (Fivetran, Ayrbyte, Matillion, Stitch und viele mehr).
• Eine relationale Datenbank für die zentrale Speicherschicht (BigQuery, Snowflake, Redshift und viele mehr).
• Ein Tool für die Datenumwandlung und -übermittlung an die Verbraucher (Dataform, dbt, Talend und viele mehr).
• Ein Tool für die Workflow-Orchestrierung (Airflow, Dagster, Digdag und viele mehr).
• Ein BI- und Berichtstool (Looker, Power BI und viele mehr).

Zu den Hauptnutzern des Data Warehouse gehören Top-Manager, Marketing- und Vertriebsspezialisten und andere Entscheidungsträger, die die Richtung der Unternehmensgeschäfte bestimmen.

Datensee

In den 2010er Jahren sind neue Ansätze für die Datenanalyse aufgetaucht und haben zusammen mit den neuen Rollen an Popularität gewonnen: Data Scientist und Data Analyst. Die neuen Analysen erforderten keine teure Datenaufbereitung und konnten mit rohen, unstrukturierten oder halbstrukturierten Daten ohne strenges Format durchgeführt werden. Etwa zur gleichen Zeit wurden skalierbare Datenverarbeitungslösungen wie Hadoop, Spark, Kafka und skalierbare analytische Datenbankmanagementsysteme entwickelt und verbreitet, die den Zugang zur Verarbeitung wesentlich größerer Datenmengen eröffneten, als dies mit den klassischen Data Warehouses möglich war.

Data Lakes ermöglichen die Speicherung von Daten in beliebigen Formaten, CSV, JSON oder effizienteren Formaten wie Avro und Parquet. Sie haben keine strengen Anforderungen an die Datenqualität und Datenkonsistenzgarantien. Um die Nachfrage aller Datenkonsumenten zu befriedigen, wurde Data Lake daher oft zusammen mit dem klassischen Data Warehouse eingeführt:

In einer solchen Architektur werden zusätzlich zu den klassischen Datenquellen große Mengen an Daten von Geräten oder benutzerorientierten Diensten in den Data Lake geladen.

Die Pflege sowohl einer relationalen Datenbank als auch eines unstrukturierten Speichers, der viele doppelte Daten enthalten kann, ist teuer, während die Anwendungsfälle für die Daten immer noch unterschiedlich sind. Es wäre besser, diese Architektur irgendwie zu optimieren.

Data Lakehouse

Bei der weiteren Entwicklung von Data Lakes traten Probleme mit der Datenkonsistenz und der Datenqualität zutage: Ein Data Lake könnte zu einem „Datensumpf“ werden. Im Gegensatz zu einem Data Warehouse, das auf einer relationalen Datenbank aufbaut, bietet ein Data Lake keine vollständigen ACID-Garantien (Atomarität, Konsistenz, Isolation, Dauerhaftigkeit). Bei einem schlechten Design der Datenpipeline kann es beispielsweise vorkommen, dass bei einem Problem beim Laden oder Umwandeln der Daten die alten Daten nicht mehr verfügbar sind, während die neuen Daten noch nicht erfolgreich geliefert wurden. Oder wenn die neuen Daten erfolgreich geliefert werden, kann der Analyst oder ein anderer Datenkonsument feststellen, dass sich das Datenschema geändert hat und nun eine Inkonsistenz in der Dateistruktur besteht. Da keine Metadaten vorhanden sind, kann die Datenstruktur unklar werden.

Um diese Probleme zu lösen, wurden neue Abstraktionen, sogenannte Tabellenformate, eingeführt. Apache Iceberg, Delta Table von Databrick und Apache Hudi sind drei beliebte Tabellenformate. Diese Tabellenformate basieren auf den beliebtesten Datenformaten für Data Lakes (Parquet, ORC, Avro) und bieten ACID-Garantien, transparente Datenschemaentwicklung, Metadatenverwaltung, Sicherheit und viele andere Funktionen. All diese Funktionen bringen Data Lakes viel näher an Data Warehouses heran.

Gleichzeitig unterstützen viele relationale Datenbankmanagementsysteme, darunter auch beliebte analytische Datenbanken, die zum Aufbau von Data Warehouses verwendet werden, jetzt unstrukturierte Daten und maschinelles Lernen und ermöglichen die Entkopplung von Speicherung und Verarbeitung (d.h. die Abfrage der erwähnten offenen, extern gespeicherten Tabellenformate).

Es ist offensichtlich, dass die Grenze zwischen dem Data Warehouse-Konzept und dem Data Lake immer mehr verschwimmt. Da wir nun die Abfrage-Engines vom Speicher entkoppeln können und eine hochwertige Datenverwaltung im Data Lake haben, können wir eine neue Architektur des Data Lake House einführen:

Mit der Data Lakehouse-Architektur gibt es keine Datenduplizierung mehr, und wir behalten nur die Komponenten, die wir für unsere Datenanalyseanforderungen benötigen.

Auf diese Weise bietet Data Lakehouse genügend Flexibilität, um verschiedene Anforderungen effizient zu erfüllen. Ein Beispiel für ein Data Lakehouse kann auf Plattformen wie Databricks, Google Cloud Platform oder mit Open-Source-Komponenten erstellt werden. Ein Beispiel:

• Datenspeicherung: Objektspeicher in der Cloud mit Apache Iceberg.
• Datenpipelines: Python/SQL-Notebooks oder Skripte, die von Apache Airflow orchestriert werden.
• Abfrage-Engines: Trino, BigQuery, Spark.
• Die BI- und Datenbereitstellungstools sind die gleichen wie die, die in einem Data Warehouse verwendet werden.

Fazit

Data Warehouse, Data Lake und Data Lakehouse sind ähnliche und voneinander abhängige Architekturen, die im Zuge der Entwicklung von Datenplattformen entstanden sind. Die wichtigsten Unterschiede ergeben sich aus der Art der Datenspeicherung, der Zielgruppe der Daten, dem Volumen, der Vielfalt und der Geschwindigkeit der Daten sowie dem Ansatz für die Datenverwaltung.

Die Entwicklung von Datenplattformen geht weiter. Der Bereich der Datenanalyse ist hart umkämpft und voller unterschiedlicher Lösungen und Tools, was die Orientierung erschwert. Dieser Überblick über Datenarchitekturen auf hoher Ebene gibt Aufschluss über die Richtung und die Landschaft moderner Datenplattformen.