Data Lakehouse
Erhalten Sie das Beste aus zwei Welten: Data Warehouse und Data Lake.
Unlock the next level of business decision-making.
Entstehung Data Warehouse
Seit mehreren Dekaden werden Datenanalyseplattformen (Data Warehouses, Data Lakes, Data Marts, …) dazu genutzt, Unternehmen bei wichtigen Entscheidungen zu unterstützen. Durch eine zentrale Sammlung von Unternehmensdaten aus verschiedenen Quellen lassen sich übergreifende Analysen durchführen. Dadurch können Sie beispielsweise tiefere Einblicke in Betriebsabläufe bekommen und somit ihre Business-Intelligence-Initiativen unterstützen. Außerdem lassen sich Einsparpotentiale und Probleme ausfindig machen, welche bei dezentralen Analysen nicht gefunden und daher nicht gelöst werden können.
Um noch tiefer in nicht direkt sichtbare Strukturen und Verbindungen der Daten einzudringen, können Machine-Learning-Prozesse eingebunden werden. Die dadurch gewonnen Kenntnisse stellen einen essenziellen Wettbewerbsvorteil dar.
In den 80er Jahren etablierte sich aus diesem Grund das Konzept des Data Warehouse. Hierbei werden die Daten über ETL-Prozesse aggregiert, verdichtet und in ein für die gewünschte Analyse optimiertes Schema gebracht. Bei diesem Prozess werden viele der in den Rohdaten enthaltenen Informationen entfernt. Analysen, die zu einem späteren Zeitpunkt von diesen Daten Gebrauch machen könnten, lassen sich damit im Nachgang nicht mehr realisieren.
Sehr hohe kosten durch cold data
Ein weiterer Nachteil eines klassischen DWHs ist, dass die benötigte Menge von RAM und CPU linear mit der Menge der gespeicherten Daten steigt. Dieser Skalierungsfaktor ist typisch für klassische Datenbanksysteme und führt in der Realität dazu, dass Daten, die selten angefragt werden (Cold Data) sehr hohe Kosten verursachen. In großen Datenplattformen können mehrere Hundert Terabyte dieser Daten entstehen, was dazu führt, dass sich viele Unternehmen dieser – in der Zukunft potenziell wichtigen Daten entledigen. Außerdem sind klassische Datenbanksysteme auf eine Datenstruktur spezialisiert. Anders strukturierte Daten müssen in zusätzlichen, externen Systemen persistiert werden.
Der nächste Evolutionsschritt: die Einführung klassischer Data Lakes
Die skizzierten Probleme führten in den späten 2000ern zur Entwicklung von Data Lakes. Das Konzept eines Data Lakes ist es, die grundlegenden Funktionalitäten einer Datenbank in mehrere, hochgradig skalierbare Systeme zu unterteilen. So besitzen Data Lakes skalierbaren File Storage (z.B. Amazon S3) um Daten zu persistieren, mindestens eine Datenbank zur Verwaltung von Metadaten und mindestens eine Query Engine und einige weitere Komponenten. Diese Trennung erlaubt das Speichern von strukturierten, semistrukturierten und unstrukturierten Daten in einer konsolidierten Plattform. Des Weiteren benötigt die Query Engine nur so viel Rechenleistung, wie für die Verarbeitung der angefragten Daten nötig ist. Ein Umstand, der zur Folge hat, dass Cold Data und Rohdaten preiswert in einem Data Lake persistiert werden können. Klassische Data Lakes besitzen allerdings nur beschränkte Datenmanagement Funktionalitäten und haben gegenüber den Query Engines von klassischen Datenbanken klar das Nachsehen. Aus diesem Grund werden Data Lakes als Speicher für Rohdaten genutzt, welche an klassische DWHs und Data Marts angeschlossen werden.
Nachteile eines herkömmlichen data lakes
Durch die Kombination aus Data Lake und den daran angeschlossenen Systemen ergeben sich aber auch einige Nachteile.
Bevor Daten für eine Analyse im DWH bereitstehen, muss der Data Analyst mit dem Data Engineer in Kontakt treten und ihm erläutern, welche Daten er in welchem Schema benötigt. Dadurch entsteht ein nicht zu unterschätzender Kommunikationsaufwand. Des Weiteren sind nicht alle Daten im Data Lake für den Data Analyst erreichbar, was dazu führen kann, dass interessante Use-Cases nicht entdeckt werden können.
Außerdem kann ein Data Lake bei fehlender Pflege schnell nicht mehr sinnvoll nutzbar sein, da relevante Daten nicht mehr effizient auffindbar sind (Data Swamp). Gründe hierfür sind eine nicht erforderliche Datenstruktur, gebrochene Beziehungen der Daten untereinander sowie eine steigende Datenmenge.
Zusätzlich ist die Datenqualität aufgrund fehlender ACID-Transaktionen häufig schlecht.
In diesem Zustand ist der Data Lake kein Gewinn mehr für Ihre Organisation.
Weitere Nachteile sind bspw. Wartungsarbeiten an mehreren Systemen, Analysen auf veralteten Daten durch langwierige ETL-Prozesse (82 % der Analysten nutzen veraltete Daten) oder aber eingeschränkte Unterstützung von Machine-Learning-Analysen, da diese nur auf den Rohdaten im Data Lake durchführbar sind.
Aufgrund dieser Probleme wurde Ende 2020 eine neue Architektur postuliert, welche die zuvor genannten Problem lösen soll – das Lakehouse.
The Lakehouse architecture
Die Lakehouse-Architektur
Das Lakehouse vereint die Ökonomie eines Data Lake mit der Performance und den Management-Features eines Data Warehouse.
Wie zuvor wird ein Data Lake als Speicher für die Rohdaten genutzt. Allerdings wird dieser um einen Datenmanagement- und Governance-Layer ergänzt – dem Delta Lake.
Hierbei handelt es sich um eine Spark-Library von Databricks, welche dem Data Lake DBMS-Management-Features hinzufügt, ähnlich zu denen in einem DWH. Verfügbare Features sind bspw. ACID-Transaktionen, Versionierung, Schema-Enforcement, Verwaltung von Metadaten und eine Rollback-Funktionalität.
Neben diesen Features ist es noch notwendig die Rohdaten für komplexe Analysen aufzubereiten, da diese sonst nur sehr schwer bzw. nicht durchführbar sind. Beim Delta Lake wird hier eine mehrstufige Lösung verfolgt, in welcher den Rohdaten mithilfe von Tabellen (Delta-Tabellen) in jedem Schritt durch Transformationen mehr Struktur erhalten:
Rohdaten und historische Daten
Die einkommenden Daten aus Stream- oder Batchverarbeitung werden zunächst in ihrem Rohformat erfasst (Bronze-Tabelle).
Gefilterte, gesäuberte und angereicherte Daten
Im nächsten Schritt wird die Bronze-Tabelle gefiltert, gesäubert und gereinigt. Die auf diese Weise normalisierten Rohdaten werden in der Silber-Tabelle gespeichert und lassen sich über diese auch abfragen.
Für die Analyse aufbereitete Daten
In einem letzten Schritt können Silber-Tabellen aggregiert werden. Diese Business-level Aggregationen werden in der Gold-Tabelle gespeichert. Sie ist die Grundlage für Analysen oder Reporting-Berichte und ermöglicht ein effizientes Abfragen der Daten.
Delta-Tabellen und MPP-Query-Engines
Die Delta-Tabellen (inkl. ihrer Metdadaten) werden auf dem Object Storage in mehreren unveränderbaren Parquet-Dateien gespeichert. Außerdem wird pro Delta-Tabelle ein Transaction-Log angelegt, in welchem die durchgeführten Transaktionen in unveränderbaren JSON-Dateien gespeichert werden. Zusätzlich zu der Art der Transaktion werden in diesen noch weitere Metadaten wie bspw. der Zeitpunkt oder verantwortliche Nutzer erfasst (wichtig für das Auditing).
Werden mithilfe von Transaktionen Daten verändert oder gelöscht, werden keine Parquet-Dateien gelöscht, sondern nur als gelöscht markiert. Dadurch kann man Änderungen leicht wieder rückgängig machen.
Die Aktualisierung dieser Delta-Tabellen wird ausgelöst, wenn neue Daten vorhanden sind (Echtzeitverarbeitung) oder aber nach einem festen Muster (z. B. einmal pro Tag).
Die verschiedenen Transformationen werden bei einer Änderung nochmal automatisch durchlaufen und man erhält somit stets aktuelle Daten und eine hohe Datenqualität in der Gold-Tabelle. Die Pipeline für die Aktualisierung der Tabellen kann dauerhaft online sein. Dies wäre in einem DWH nicht möglich.
Ein weiterer Bestandteil der Lakehouse-Architektur sind neuartige MPP-Query-Engines (Massively Parallel Processing) wie zum Beispiel Trino. Hierbei handelt es sich um externe und verteilte Query Engines, welche die Daten im Memory verarbeiten und somit extrem schnelle Anfragen ermöglichen. Existiert ein Metadaten-Speicher, sowie eine gute Datenstruktur, kann die Query-Performance eines DWHs erreicht werden.
Diese MPP-Query-Engines können direkt an den Delta Lake angebunden werden. Dadurch sind die Vorteile von Data Lakes und Data Warehouses im Lakehouse kombinierbar.
UNTERSTÜTZUNG FÜR BELIEBIGE DATENSTRUKTUR
Daten – strukturiert, semi-strukturiert oder unstrukturiert – werden im Rohformat in hochgradig skalierbaren File Storages (zb. Amazon S3) persistent gespeichert und sind dadurch auch zu einem späteren Zeitpunkt noch für Analysen verfügbar.
ENTKOPPLUNG VON COMPUTE- UND STORAGE-RESSOURCE
Neben einer kosteneffizienten Speicherung der Daten hat diese Trennung den Vorteil, dass nur so viele Compute-Ressourcen verwendet werden, wie für die Verarbeitung der Daten zu jedem Zeitpunkt wirklich notwendig sind (Ressourcen skalieren mit der Last).
VALIDE TRANSAKTIONEN
Beliebig viele Pipelines können gleichzeitig Daten lesen und schreiben ohne dass man sich um Konsistenzprobleme Gedanken machen muss (ACID-Konformität).
UNTERSTÜTZUNG DIVERSER WORKLOADS
Supports various workloads
Data Science, Machine-Learning, SQL-Abfragen und komplexe Analysen – alle diese Workloads können mit geeigneten Tools an das Lakehouse angebunden werden und stützen somit ihre Anwendungen alle auf derselben Datenbasis
ENDE-ZU-ENDE-STREAMING
Es werden keine zusätzlichen Systeme für Echtzeit-Anwendungen benötigt. Diese können direkt an das Lakehouse angebunden werden.
TRANSPARENZ/OFFENHEIT
Die Dateispeicherformate (z.B. Parquet) sind offen und standardisiert. Sie bieten eine Schnittstelle an wodurch eine Vielzahl an Anwendungen, darunter auch Machine-Learning-Anwendungen und Python/R-Bibliothkene, die Daten direkt nutzen können.
BI SUPPORT
BI-Anwendungen können ohne weitere Zwischenschritte direkt auf den Daten arbeiten. Dies wiederrum reduziert die Latenz und die Kosten, die für die Verwaltung von Kopien bei einer hybriden Architektur anfallen.
„*“ zeigt erforderliche Felder an