[1. „Lakehouse: A New Generation of Open Platforms that Unify Data Warehousing and Advanced Analytics“ Michael Armbrust, Ali Ghodsi, Reynold Xin, Matei Zaharia, Databricks, UC Berkeley, Stanford University – 2021]
Das Data Lakehouse ist eine Informationsarchitektur, die in den letzten Jahren immer mehr an Popularität gewonnen hat. Der Kerngedanke dieser Architektur ist der Versuch, die Ansätze des Data Warehouse und des Data Lake in einer Architektur zu vereinen. In diesem Artikel wird das Grundkonzept eines Data Lakehouse, die Beweggründe sowie die Hürden, die es dabei zu überwinden gilt, erläutert. Es ist wichtig zu beachten, dass es hier keine allgemein akzeptierte Definition eines Data Lakehouse gibt. Dieser Artikel bezieht sich daher vorwiegend auf die im White Paper [1] dargelegte Untersuchung und Interpretation. Zuerst werden die Vorgänger erörtert.
Data Warehouse
Das Data Warehouse („Datenlager“) stellt eine in Unternehmen weit verbreitete, strukturierte Datenarchitektur dar, die zur Datenaufbereitung, Berichtserstellung und Visualisierung für die Unternehmensdaten verwendet wird. Die Daten werden hier in relationalen Datenbanken gelagert und mittels ETL in die vorgegebene normalisierte Struktur transformiert, beispielsweise das Sternschema. Diese Struktur unterstützt die Performanz, die von den relationalen Datenbanken für große Datenmengen bereitgestellt wird.
Data Warehouse-Plattformen stellen MPP-Architekturen (Massively Parallel Processing) dar. In den 1980er Jahren fand diese Architektur erstmals Einzug in den Unternehmen. Die angesammelte Erfahrung spiegelt sich unter anderem in den heutigen relationalen Datenbanken wieder. Der Bedarf der Unternehmen an der Verarbeitung hat im Verlauf mehr und mehr zugenommen. Durch die Einführung des Machine Learnings ist der Bedarf nun erneut angestiegen. Viele Unternehmen entscheiden sich daher immer häufiger auch für einen Data Lake.
Data Lake
Der Data Lake („Datensee“) ist ein Repository für Unternehmen zur Speicherung einer großen Menge beliebiger, unstrukturierter Daten unterschiedlicher Datenherkunft. In einem solchen Repository werden Daten „as-is“ gespeichert, was in diesem Sinne bedeutet, dass im Data Lake auch semi-strukturierte Datentypen wie beispielsweise XML oder JSON hier verarbeitet werden können. Der Nutzen dieser Datenarchitektur liegt insbesondere im Bereich der fortgeschrittenen Datenanalyse, unter anderem mittels Machine Learning.
Ein Problem mit einem solchen damaligen Data Lake sind mitunter fehlende Transaktionsflüsse, Datenqualität und Datenkonsistenz.
Data Warehouse Vorteile:
- Daten liegen in Normalform für performante Datenverarbeitung in strukturierter Form vor – der Nutzer erhält alle zusammengeführten Daten in der Zieltabelle
- Datenqualität ist garantiert
- bereitgestellte State-of-the-Art Performanzoptimierung (Caching, Indexing)
- ACID-konform
Data Lake Vorteile:
- strukturierte, semi-strukturierte und unstrukturierte Daten können ohne weiteren Aufwand mittels Data Ingestion gesammelt werden.
- Nutzer haben direkten Zugriff auf die Rohdaten
- Daten können auf kosteneffizienten und skalierbaren Speichermedien gelagert werden.
- viele Open-Source-Dienste stehen zur Anbindung zur Verfügung.
Data Warehouse und Data Lake
Die oben erwähnten Informationsarchitekturen zeigen gegensätzliche Vorteile in ihrer Anwendungsform. Während das Data Warehouse mit Performanz bei großen Datenmengen glänzen kann, ist die Anwendungsmöglichkeit ausschließlich auf strukturierte Daten beschränkt und schließt somit moderne Möglichkeiten der fortgeschrittenen Datenanalyse aus. Der Data Lake kann hier überzeugen, was dieses Angebot angeht. Allerdings ist die Performanz der Datenlieferung auf Data Lake-Seite aufgrund der mangelnden Struktur stark eingeschränkt.
Durch eine Kombination beider Architekturen konnten Unternehmen bereits beide Vorteile genießen. Die Kosten der doppelten Speichernutzung sind dabei eine Trivialität, aber dennoch ein Kostenfaktor. Dies addiert sich leider weiter auf durch weiteren Planungsaufwand, Synchronisationsbedarf via ETL, Schnittstellen-Limitationen und einige weitere Punkte könnten hier aufgeführt werden. Auf Basis immer wachsender Daten und der rapiden Weiterentwicklung moderner Ansätze der Datenanalyse sowie der Machine Learning-Algorithmen wird die Komplexität weiter steigen und das Problem erschweren.
Das Konzept des Data Lakehouse ist im White Paper [1] vorgestellt und versucht, Vorteile beider Architekturen zu vereinen.
Konzept: Data Lakehouse
Eine Datenarchitektur ist ein Verbund verfügbarer Daten Services.
Sources -> Ingestion -> Storage -> Metadata -> Processing -> Serving
Das Data Lakehouse verknüpft daher die bereitgestellten Dienste mit dem Data Lake als Datenspeicher. Die Data Lakehouse-Architektur ist aus den folgenden 5 Ebenen zusammengesetzt.
- Data Source-Layer – Jegliche Form von Datenquellen (DB’s, IoT, Service Logs)
- Data Ingestion-Layer – Datenaufnahme und Einbettung in das System
- Data Storage-Layer – Skalierbare, resistente und leicht verfügbare Daten. Speicher für Data Lake und Data Warehouse – Bereiche ist im Data Lakehouse geteilt, um unnötige Datenduplikation zu vermeiden
- Metadata-Layer – Metadaten werden bereitgestellt für die Daten (strukturiert und unstrukturiert) für eine leichte Nutzerbereitstellung
- Datenverarbeitung – Transformation der Daten in zu verarbeitende Formate und weitere Datenaufbereitung (Datensäuberung, ‑validierung, ‑normalisierung)
- Datenbereitstellung – Bereitstellung der Daten auf Nutzerebene mittels Datenkatalog
Das Data Lakehouse führt die Möglichkeiten der zwei oben vorgestellten Architekturen in einer Plattform zusammen. Es kombiniert die Verarbeitung strukturierter Daten und die kosteneffiziente Verarbeitung unstrukturierter Daten. Die Kosten für die Datenspeicherung können durch Vermeidung von Datenduplikation und die effiziente Abspeicherung reduziert werden. Zudem werden ETL-Prozesse somit überflüssig. Diese Architektur bietet Entwicklern aus den unterschiedlichen Bereichen der Datenanalyse die Möglichkeit auf dieselbe Datenbasis Zugriff zu erhalten. Die Hoffnung ist, Ergebnisse mit überlappenden Zusammenhängen verschiedener Bereiche besser verstehen zu können.
Die Vorteile der Data Lakehouse-Architektur sind im Folgenden zusammengefasst.
Uniformes Toolkit: Data Warehouse & Data Lake greifen auf eine große Anzahl unterschiedlicher Dienste zur Bearbeitung der jeweiligen Datenstruktur zurück. Hier bietet das Data Lakehouse bereits eine starke Reduktion der verwendeten Dienste in eine uniforme Gestalt über die komplette Infrastruktur. Somit wird der Aufwand für Entwickler reduziert und der „Dienste-Zoo“ für Entwickler vermieden.
Reduktion des Speicherbedarfs: Redundante Daten können teilweise bei der Betreibung der beiden Plattformen Data Warehouse & Data Lake nicht vermieden werden. Eine solche Datenduplikation wird im Data Lakehouse vermieden.
Reduktion der Komplexität des Datenmanagements: Durch die Reduktion der Speicherorte und Vermeidung von Datenredundanz kann die Komplexität im Datenmanagementbereich gering gehalten werden.
ETL-Strecken: Es besteht ein großer Bedarf an Datenaustausch in den bisherigen Architekturen und erfordert abgestimmte ETL Prozesse. Dieser Bedarf entfällt komplett.
Hardware/Betriebssystem-Kosten: Es besteht ein hohes Potenzial, Kosten einzusparen durch Speicherreduktion, reduzierten Synchronisationsbedarf & reduzierten Verwaltungsaufwand.
Resümee
Trotz aller Vorteile gibt es hier auch Argumente gegen ein Data Lakehouse. Neben einer “jungen” und “naiven” Implementation eines solchen Konzepts können hier noch weitere Argumente gegen diese Architektur genannt werden.
Anpassung an bestehende Infrastrukturen: Die Einführung eines Data Lakehouses kann für Unternehmen, die bereits bestehende Data Warehouse- und Data Lake-Infrastrukturen haben, eine Herausforderung sein. Der Umstieg erfordert eine Anpassung der Systeme, was zeit- und ressourcenintensiv sein kann.
Mangelnde Standardisierung: Da das Data Lakehouse-Konzept noch relativ neu ist, gibt es bisher keine weit verbreitete Standardisierung. Dies kann zu Interoperabilitätsproblemen führen und die Zusammenarbeit zwischen verschiedenen Systemen und Tools erschweren.
Unreife der Technologie: Die Technologie hinter dem Data Lakehouse ist noch in der Entwicklung, und es gibt möglicherweise noch keine ausgereiften Lösungen für einige Anwendungsfälle. Unternehmen, die auf bewährte und etablierte Technologien setzen möchten, könnten zögern, sich für ein Data Lakehouse zu entscheiden.
Notwendige Expertise: Das Data Lakehouse-Konzept verbindet verschiedene Bereiche der Datenanalyse und ‑verarbeitung. Um ein solches System erfolgreich zu implementieren und betreiben, ist es notwendig, Experten mit umfassendem Wissen und Erfahrung in diesen Bereichen zu haben.
Sicherheitsbedenken: Die Konsolidierung von Daten in einem zentralen System kann Sicherheitsbedenken aufwerfen, da es potenziell einfacher für Angreifer ist, auf eine Vielzahl von Informationen zuzugreifen. Unternehmen müssen sicherstellen, dass sie angemessene Sicherheitsmaßnahmen ergreifen, um ihre Daten zu schützen.
Trotz dieser Herausforderungen bietet das Data Lakehouse-Konzept eine vielversprechende Möglichkeit, die Vorteile von Data Warehouses und Data Lakes zu kombinieren und Unternehmen dabei zu helfen, effektiver und effizienter mit ihren Daten umzugehen. Es ist wichtig, dass Unternehmen die potenziellen Vor- und Nachteile sorgfältig abwägen und die am besten geeignete Lösung für ihre spezifischen Bedürfnisse und Anforderungen wählen.
Die Lakehouse Architektur wird zurzeit von mehreren Technologien unterstützt und aktiv vorangetrieben. Beispiele hierfür sind die Anbieter AWS, Google, Azure aber auch Databricks mit ihrer auf hauptsächlich Open-Source-basierten Lösung und bietet mit der Databricks Data Lakehouse Platform ein Produkt dieser Architektur an. Damit ermöglicht es Entwicklern flexibel mit dem Datenhaushalt zu arbeiten.
saracus consulting hat mehrere Kunden bei ihren Migrationsvorhaben auf eine Lakehouse Architektur unterstützt und diese Vorhaben erfolgreich umgesetzt. Sollten Sie hier Unterstützungsbedarf haben oder an einem Austausch interessiert sein, kommen Sie gerne auf uns zu.
