Vom Datensee zum flexiblen Data Lakehouse
Viele Unternehmen und Organisationen haben in den vergangenen Jahrzehnten hohe Summen in Data Warehousing (DWH) investiert. In den letzten Jahren sind DWHs allerdings etwas in den Ruf geraten, schwerfällige und komplexe Hindernisse auf dem Weg zu datengetriebenen Organisationen zu sein, anstatt die Reise dorthin zu beschleunigen. Mit Data Lakes hofft man schon seit längerem, DWHs zu entlasten und agiler zu werden. Hier und da wurde das Ende des Data Warehousing bereits ausgerufen, doch ein Data Lake allein ersetzt kein strukturiertes Data Warehouse. Erst seit dem Aufkommen von sogenannten «Lakehouses», die die Vorteile von DWHs und Data Lakes verbinden, gibt es eine wirkliche Alternative zum DWH. Ganz nach dem Prinzip «vom Datensee zum flexiblen Data Lakehouse», oder handelt es sich hierbei lediglich um ein DWH in neuem Gewand? Das wollen wir in diesem Beitrag herausfinden.
Klar ist: Die Anforderungen aus dem Business, die seinerzeit zum Aufbau der DWHs geführt hatten, sind immer noch aktuell und sogar noch dringender. Reporting sowie Datenanalysen sollen vermehrt in Echtzeit möglich sein und Daten müssen – vor allem für Advanced Analytics – verständlich, auffindbar und dokumentiert sein.
In diesem Beitrag wollen wir uns auf die Datenspeicherung fokussieren. Die Anforderungen aus dem Business übersetzen sich dabei in bestimmte technische Anforderungen, wie Daten zu sammeln und aufzubereiten sind.
Schauen wir uns also an, welche dieser technischen Anforderungen
- ein klassisches Data Warehouse, mit strukturierten relationalen Daten, versus
- ein klassischer Data Lake, also im Wesentlichen ein Dateispeicher
Während also klassische DWHs die Vorteile der heutigen Cloud-Möglichkeiten (Skalierbarkeit, Abrechnung nach Nutzung) nicht voll ausnutzen können und nur unzureichende Möglichkeiten für die Integration und Auswertung semi- und unstrukturierter Daten ermöglichen, bieten sie etablierte Verfahren zur Integration und Modellierung strukturierter Daten und vor allem elegante Historisierungsmöglichkeiten, so dass Zeitreisen möglich werden. Damit ist die Abfrage von Daten in der Form, wie sie zu einem bestimmten Zeitpunkt in der Vergangenheit vorlagen, gemeint. Dies ist in vielen Anwendungen eine zentrale Anforderung. Solche Historisierungstechniken eines DWH unterstützen zusätzlich die Fehlerverfolgung und Wiederherstellbarkeit von Daten, was im laufenden Betrieb oft von grossem Nutzen sein kann.
Um Zeitreisen via einem Data Lake zu ermöglichen, müssten alle historischen Daten redundant gespeichert werden, also beispielsweise eine vollständige Kopie der Daten je Tag bei tagesgenauer Historisierung vorliegen. Da Data Lakes lediglich Dateispeicher sind, lassen sich einmal abgelegte Daten nicht mehr (auf performante Weise) zielgenau ändern, sondern nur ergänzen. Die Datenbewirtschaftung wird daher ohne weitere Unterstützung zu einer grossen Herausforderung.
Ein DWH dagegen beruht in aller Regel auf einer relationalen Datenbank. Damit nutzt ein DWH einige Funktionalitäten, die dem reinen Data Lake fehlen:
Die Daten und auch die Datenstrukturen eines DWH können mit SQL gezielt abgefragt und verändert werden – die Dateien in einem Data Lake bisher nicht. Diese Möglichkeit der gezielten Abfrage und Veränderung ist zentral für robuste ETL- oder ELT-Prozesse zur Datenintegration und für die effiziente Historisierung, also für Kernaufgaben der Datensammlung.
Die ersten Data Lakes wurden oft zu «Sümpfen» (Data Swamps), weil man sie nur als Datenspeicher für Massendaten, die nicht mehr ins DWH passten, ansah. Doch neuerdings werden Data Lakes um Komponenten mit oben genannten Funktionalitäten ergänzt. So entstand das «Data Lakehouse». Die wesentlichen Komponenten eines Data Lakehouse sind:
- Als Datenspeicher wird ein cloud-basierter Object Store verwendet, der in der Regel S3-kompatibel ist. Darin werden strukturierte Daten in offenen (also nicht proprietären), für Abfragen optimierten Dateiformaten wie Parquet oder Apache Iceberg abgelegt.
- Um die Datenstrukturen, mit denen die Daten abgefragt werden können zu verwalten, hat sich «Hive» als de-facto-Standard für Metadaten durchgesetzt. Hive unterstützt die Versionierung der Datenstrukturen (Schema Evolution) und nutzt eine relationale Datenbank (idealerweise auch cloudbasiert) als Speicherort für die Metadaten.
- Die wichtigste Komponente im Lakehouse ist die Query Engine. Sie ermöglicht die Abfrage und gezielte Änderung der Daten mit SQL. Sie sollte Hive sowie die oben genannten quelloffenen Dateiformate unterstützen, um einen Vendor Lock-in zu vermeiden. Dremio und Presto sind Beispieltechnologien hierfür, während DeltaLake ein proprietäres Dateiformat nutzt.
Wie auch im DWH werden diese zentralen Komponenten durch eine Vielzahl weiterer Technologien ergänzt, sei es zur Datenbewirtschaftung (ELT-Prozesse), für Datenkataloge oder das Reporting.
Ist im klassischen DWH eine einzelne Technologie – die (meist proprietäre) relationale Datenbank – für mehrere Funktionalitäten zuständig, so wird dies im Lakehouse durch mehrere Einzeltechnologien ersetzt .Diese nutzen jedoch an ihren Schnittstellen kompatible Standards, so dass sie austauschbar sind und somit die Abhängigkeit von einem Hersteller entfällt. In der Kombination sorgen die optimierten Dateiformate und die Query Engines dafür, dass die Funktionen des DWH auch auf einem Data Lake zur Verfügung stehen.
Die Vorteile der neuen Architektur sind:
- Daten können dank der offenen Formate unabhängig von der Abfrage-Technologie (Query Engine) gespeichert werden. Ein Austausch der Query Engine ist also möglich, ohne die Datenstrukturen zu ändern. Auch Ergänzungstechnologien (Datenkataloge, ETL-Tools, etc.) können frei gewählt werden. Im Ergebnis verringert sich der Vendor Lock-in.
- Die Cloud-Fähigkeiten, insbesondere Skalierbarkeit und nutzungsgerechte Abrechnung, werden voll nutzbar. Der Umfang des Datenspeichers und die Leistungsfähigkeit der Abfragen können zudem getrennt skaliert werden – wer viele Daten hat, aber einfache Abfragen, zahlt weniger.
- Semi- und unstrukturierte Daten können am gleichen Ort gespeichert werden wie strukturierte Daten, was die zentrale Governance erleichtert.
- Dank des zentralen Datenspeichers mit seinen offenen Schnittstellen wird die Anbindung neuer Datenquellen vereinfacht. Analyst*innen erhalten so schneller Zugriff auf neue Rohdaten, während deren Veredelung für andere Zielgruppen später beziehungsweise nach Bedarf erfolgen kann.
Mit seinen offenen Schnittstellen grenzt sich das Data Lakehouse auch von Cloud Data Warehouses wie Snowflake ab, die stärker auf proprietäre Technologien setzen.
Ein Data Lakehouse kann ein DWH ersetzen. Wenn aber ein Data Lakehouse das Gleiche macht wie ein DWH, nur mit anderen Technologien, wird es dann genauso schwerfällig sein wie (angeblich) das DWH?
Betrachten wir die Best Practice im DWH, die Daten in mehreren Schichten abzulegen: Die erste Schicht beinhaltet die Rohdaten wie angeliefert: nach Quellsystemen getrennt, aber bereits historisiert. Die zweite Schicht enthält bereinigte und integrierte Daten, und eine dritte Schicht liefert fachlich aufbereitete, für die Visualisierung oder OLAP optimierte Daten. Die Schichten enthalten also redundante Daten und bei jeder Änderung von Daten (oder Datenstrukturen!) müssen alle Schichten aktualisiert werden. Berücksichtigt man dabei die notwendige Qualitätssicherung und Dokumentation wird deutlich, warum Änderungen im DWH in vielen Organisationen langwierig und vergleichsweise aufwändig sind.
Allerdings sind weder die Historisierung von Rohdaten, noch deren Bereinigung und Integration oder die Einbringung von Fachlogik im Data Lakehouse überflüssig. Es kommt weiterhin darauf an, diese Datenbewirtschaftungsprozesse möglichst umfangreich zu automatisieren. Die höheren Datenschichten sollten so angelegt werden, dass sie bei Fehlern oder bei Änderungsbedarf ohne allzu grossen Aufwand aus der untersten Schicht, die ja bereits historisiert sein sollte, rekonstruiert werden können. Diese Aufgaben sind heute schon lösbar, aber das Ökosystem der Lakehouses dürfte dank seiner offenen Grundstrukturen hier den Technologiewettbewerb weiter befeuern und in Zukunft noch etliche Standardaufgaben der Datenbewirtschaftung weiter erleichtern.
Ein Beispiel dafür ist der «Infrastructure as Code»-Ansatz, wie er im Eraneos Data Hub zum Tragen kommt. Das Grundgerüst für Datenmanagement in der Cloud ist mit dieser Plattform überaus schnell bereitgestellt – auch für ein Data Lakehouse. Damit können Datenprofis sich auf ihre Kernaufgaben konzentrieren und unmittelbar von den Vorteilen der Cloud profitieren, ohne zunächst aufwändige Installationsarbeiten abzuwarten.
Fazit
Neue Technologien, Cloud-Standards und offene Schnittstellen befeuern beim Data Lakehouse den Wettbewerb der Technologien. Schon heute gibt es vorgefertigte Lakehouse-Architekturen, die fast per Knopfdruck in der Cloud aufgebaut werden können, wie den Eraneos Data Hub.
Ein Data Lakehouse kann ein Data Warehouse ersetzen, aber die Historisierung von Daten, fachliche Veredelung und Visualisierung bleiben Aufgaben, mit denen Data Engineers sich auseinandersetzen müssen. Eine professionelle Datenbewirtschaftung bleibt niemandem erspart.
Data Hub | Daten zusammenführen und wertschöpfend nutzen
Die Verwaltung vieler unterschiedlicher Datensilos ist nicht nur ineffizient, sondern führt auch zu Redundanzen und hohen Kosten. Zudem ist die Integration dieser Silos äusserst schwierig.
Digitale Plattformen | Enabler einer agilen Unternehmensarchitektur
Die E-Paper Serie «Digitale Plattformen - Enabler einer agilen Unternehmensarchitektur» beleuchtet die Gestaltung von Fachanwendungen auf Basis digitaler Plattformen.
Data Analytics & AI | Daten vom Kostenfaktor zum Vermögenswert
Jedes Unternehmen verfügt über grosse Mengen von Daten, in denen wertvolles geschäftsrelevantes Wissen schlummert. Unsere Data Science Spezialisten helfen Ihnen, dieses Wissen zu extrahieren und nutzbar zu machen.
Berichte zu unseren Projekten, Wissenswertes aus den verschiedenen Kompetenz- und Kundenbereichen als auch Informationen über unser Unternehmen haben wir hier für Sie zusammengetragen.