Datenmanagement im Laufe der Zeit: Von der Warehouse- zur Lakehouse-Architektur – Teil 2

Im ersten Teil haben wir uns mit den beiden Grundpfeilern der Datenwelt - dem Data Warehouse und dem Data Lake - beschäftigt und sind zu dem Schluss gekommen, dass ein hybrider Ansatz viele Vorteile mit sich bringen kann. Damit sind wir beim nächsten Schritt in der Entwicklung von Datenmanagementsystemen angelangt.

Modernes Data Warehouse oder zweischichtige Architektur

Wie im ersten Teil erläutert, haben Data Lakes relationale Data Warehouses nicht vollständig ersetzt, boten aber eigene Vorteile bei der Bereitstellung und Aufbereitung von Daten.

Seit Mitte der 2010er Jahre dominiert in der Branche die 2-Schicht-Architektur. Diese beinhaltet die Nutzung von Cloud-Speicherdiensten wie S3 oder ADLS als Data Lake und das Down-Streaming der Daten in das Data Warehouse, beispielsweise Redshift oder Snowflake. Kurz gesagt verkörpert es die Philosophie des „Best of Both Worlds“: Der Data Lake dient als Staging-Bereich für die Datenaufbereitung und unterstützt Data Scientists bei der Erstellung von Machine-Learning-Modellen. Das Data Warehouse hingegen dient der Datenbereitstellung, der Gewährleistung von Sicherheit und Compliance sowie der Erleichterung von Abfrage- und Berichtstätigkeiten der Fachanwenderinnen und -anwender.

Diese Architektur ermöglicht zwar BI und ML auf Grundlage der Daten in diesen beiden Systemen, führt aber auch zu doppelten Daten, zusätzlichen Infrastrukturkosten, Sicherheitsproblemen und erheblichen Betriebskosten. In einer 2-Schicht-Datenarchitektur werden die Daten per ETL von operativen Datenbanken in einen Data Lake übertragen. In diesem Data Lake werden Daten aus dem gesamten Unternehmen in einem kostengünstigen Objektspeicher gespeichert – und das in einem Format, das zwar mit gängigen Tools für maschinelles Lernen kompatibel ist, aber oft nicht gut organisiert und gepflegt ist. Als Nächstes wird ein kleiner Teil der kritischen Geschäftsdaten wieder per ETL in das Data Warehouse geladen, um dort Business-Intelligence- und Datenanalysevorgänge durchzuführen. Aufgrund der zahlreichen ETL-Schritte erfordert diese 2-Schicht-Architektur eine regelmäßige Wartung und führt häufig zu Datenverlusten.

Trotz aller Vorteile von Data Lakes und Data Warehouses stellt diese Architektur Data Analysts immer noch vor eine fast unmögliche Wahl: Sollen sie aktuelle, aber unzuverlässige Daten aus dem Data Lake oder veraltete, aber hochwertige Daten aus dem Data Warehouse verwenden? Aufgrund der geschlossenen Formate gängiger Data-Warehousing-Lösungen ist es auch sehr schwierig, die vorherrschenden Open-Source-Datenanalyse-Frameworks für hochwertige Datenquellen zu verwenden, ohne einen weiteren ETL-Vorgang einzuführen und die Datenqualität so weiter zu verschlechtern. Mit dem Konzept des Data Lakehouse sollen diese Probleme gelöst werden.

Data Lakehouse

Diese Architektur ermöglicht zwar BI und ML auf Basis der Daten in diesen beiden Systemen, führt aber auch zu doppelten Daten, zusätzlichen Infrastrukturkosten, Sicherheitsproblemen und erheblichen Betriebskosten. In einer zweischichtigen Datenarchitektur werden Daten mittels ETL aus operativen Datenbanken in einen Data Lake übertragen. In diesem Data Lake werden Daten aus dem gesamten Unternehmen in einem kostengünstigen Objektspeicher abgelegt - in einem Format, das zwar mit gängigen Machine-Learning-Tools kompatibel ist, aber oft nicht gut organisiert und gepflegt wird. Anschließend wird ein kleiner Teil der kritischen Geschäftsdaten mittels ETL wieder in das Data Warehouse geladen, um dort Business Intelligence- und Datenanalyse-Operationen durchzuführen. Aufgrund der zahlreichen ETL-Schritte erfordert diese zweischichtige Architektur eine regelmäßige Wartung und führt häufig zu Datenverlusten.

Trotz aller Vorteile von Data Lakes und Data Warehouses stellt diese Architektur den Datenanalysten immer noch vor eine fast unmögliche Wahl: Sollen aktuelle, aber unzuverlässige Daten aus dem Data Lake oder veraltete, aber qualitativ hochwertige Daten aus dem Data Warehouse verwendet werden? Aufgrund der geschlossenen Formate gängiger Data Warehousing Lösungen ist es zudem sehr schwierig, die vorherrschenden Open Source Datenanalyseframeworks für hochwertige Datenquellen zu nutzen, ohne einen weiteren ETL-Prozess einzuführen und damit die Datenqualität weiter zu verschlechtern. Das Konzept des Data Lakehouse soll diese Probleme lösen.

Data Lakehouse

Ende 2020 stellte Databricks das Konzept des Data Lakehouse vor. Das Unternehmen definiert Lakehouses als Datenmanagementsysteme, die auf einem kostengünstigen In-Memory-Speicher basieren, der auch herkömmliche analytische DBMS-Verwaltungs- und Leistungsfunktionen wie ACID-Transaktionen, Datenversionierung, Auditing, Indizierung, Caching und Abfrageoptimierung bietet. Lakehouses vereinen somit die Hauptvorteile von Data Lakes und Data Warehouses: kostengünstige Speicherung in einem offenen Format, auf das von einer Vielzahl von Systemen zugegriffen werden kann, und die leistungsstarken Management- und Optimierungsfunktionen eines Data Warehouse.

Data Lakes eignen sich besonders für Cloud-Umgebungen, in denen Rechen- und Speicherressourcen klar voneinander getrennt sind. Durch diese Trennung können verschiedene Rechenanwendungen unabhängig voneinander auf dedizierten Rechenknoten ( beispielsweise einem GPU-Cluster für maschinelles Lernen) ausgeführt werden und gleichzeitig direkt auf dieselben gespeicherten Daten zugreifen. Es ist aber auch möglich, eine Lakehouse-Infrastruktur mit lokalen Speichersystemen wie dem Hadoop Distributed File System (HDFS) aufzubauen.

Gründe für eine neue Lösung

• 1. Datenqualität und Zuverlässigkeit: Die Implementierung korrekter Datenpipelines ist an sich schon schwierig, und zweistufige Architekturen mit getrennten Data Lakes und Data Warehouses erhöhen die Komplexität zusätzlich. Beispielsweise können Data Lake- und Warehouse-Systeme unterschiedliche Semantiken in Bezug auf die unterstützten Datentypen, unterschiedliche SQL-Dialekte usw. aufweisen. Daten können auch mit unterschiedlichen Schemata im Data Lake und im Warehouse gespeichert werden (zum Beispiel denormalisiert in einem). Darüber hinaus erhöht die zunehmende Anzahl von ETL/ELT-Jobs, die sich über mehrere Systeme erstrecken, die Wahrscheinlichkeit von Ausfällen und Fehlern.
• 2. Aktualität der Daten: Immer mehr Geschäftsanwendungen benötigen aktuelle Daten. 2-Schicht-Architekturen führen jedoch häufig zu großen Mengen veralteter Daten, da sie einen separaten Staging-Bereich für eingehende Daten vor dem Warehouse haben und regelmäßige ETL/ELT-Jobs zum Laden dieser Daten verwenden. Theoretisch könnten Unternehmen mehr Streaming-Pipelines implementieren, um das Data Warehouse schneller zu aktualisieren, aber diese sind noch komplizierter als Batch-Jobs. Anwendungen wie Customer Support Systeme und Recommendation Engines sind mit veralteten Daten schlichtweg ineffizient, und selbst Datenanalysten, die Daten aus Data Warehouses abfragen, sehen veraltete Daten als großes Problem an.
• 3. Unstrukturierte Daten: In vielen Branchen ist ein Großteil der Daten heutzutage unstrukturiert, da Unternehmen eine Vielzahl von Datentypen wie Bilder, Sensordaten, Dokumente usw. sammeln. Unternehmen benötigen benutzerfreundliche Systeme zur Verwaltung dieser Daten, aber SQL Data Warehouses und ihre APIs unterstützen dies nicht ohne weiteres.
• 4. Maschinelles Lernen und Datenwissenschaft: Die meisten Unternehmen setzen heute ML- und Data Science-Anwendungen ein, die jedoch von Data Warehouses und Data Lakes nicht ausreichend unterstützt werden. Diese Anwendungen müssen große Datenmengen mit Nicht-SQL-Code verarbeiten und können daher nicht effizient über ODBC/JDBC laufen. Da sich fortgeschrittene Analysesysteme ständig weiterentwickeln, ist der direkte Zugriff auf Daten in einem offenen Format der effektivste Weg, diese Systeme zu unterstützen.
• 5. Datenmanagement: Darüber hinaus haben ML- und Data Science-Anwendungen die gleichen Datenmanagementprobleme wie herkömmliche Anwendungen, beispielsweise in Bezug auf Datenqualität, -konsistenz und -isolierung. Daher ist es von unschätzbarem Wert, DBMS-Funktionen auf die Daten anwenden zu können.

Die Idee eines Data Lakehouses besteht darin, einen einzigen Data Lake zur Speicherung aller Daten zu verwenden, anstatt diese in einem komplexen System mit einem Data Warehouse zu kombinieren. In der Vergangenheit konnte der Data Lake die Funktionalität des Data Warehouse nicht ersetzen. Hier kommen neue Datenformate wie Delta Lake und Apache Iceberg ins Spiel.

Diese Formate bieten eine Transaktionsschicht, die auf einem bestehenden Data Lake aufbaut und ähnliche Funktionen wie ein relationales Data Warehouse (RDW) bietet, wodurch Zuverlässigkeit, Sicherheit und Leistung verbessert werden. Im Wesentlichen handelt es sich um eine Parquet-Datei mit zusätzlichen Metadaten im JSON-Format in einem benachbarten Ordner. Schematisch entspricht ein Data Lake einem Data Lake mit einer zusätzlichen Metadaten- und Governance-Schicht.

An dieser Stelle könnte man meinen, dass der einzige Unterschied zwischen einem Data Lake und einem Data Lakehouse in der Verwendung von Delta Lake oder Apache Iceberg besteht. Die Idee eines Data Lakehouse geht jedoch über spezifische Technologien hinaus. Es basiert vielmehr auf Prinzipien, die in der Planungsphase sorgfältig berücksichtigt werden sollten. Das Lakehouse-Konzept basiert auf sieben Grundprinzipien, die im Folgenden näher erläutert werden.

• 1. Offenheit: Das Lakehouse bevorzugt Open-Source-Standards gegenüber Closed-Source-Technologien, um die Langlebigkeit der Daten zu gewährleisten und die Zusammenarbeit über nicht-proprietäre Technologien und Methoden, wie entkoppelte Speicher- und Recheneinheiten, zu erleichtern.
• 2. Datenvielfalt: In einem Lakehouse sind alle Daten gleichermaßen zugänglich, einschließlich semi-strukturierter Daten, wobei sowohl strukturierte als auch semi-strukturierte Daten gleichwertig behandelt werden. Dies wird durch die Anwendung von Schemata unterstützt.
• 3. Vielfältige Workflows: User können mit den Daten in einem Lakehouse auf verschiedene Weise interagieren, beispielsweise mit Notebooks, benutzerdefinierten Anwendungen und BI-Tools, wodurch eine Vielzahl von Arbeitsabläufen ohne Einschränkungen unterstützt wird.
• 4. Vielfältige Datenverarbeitung: Das Lakehouse unterstützt sowohl Streaming- als auch Batch-Verarbeitung. Darüber hinaus ermöglicht die Delta-Architektur die Integration von Streaming- und Batch-Technologien in einer einzigen Schicht für eine umfassende Datenverarbeitung.
• 5. Sprachunabhängigkeit: Das Lakehouse zielt darauf ab, alle Zugriffsmethoden und Programmiersprachen zu unterstützen. In der Praxis wird daher, wie zum Beispiel bei Apache Spark, eine Vielzahl von Methoden und Sprachen unterstützt.
• 6. Entkopplung von Datenhaltung und Datenverarbeitung: Im Gegensatz zu herkömmlichen Data Warehouses trennt das Lakehouse die Speicher- und Rechenschicht. Dadurch bietet es die Flexibilität, Technologien zu mischen und anzupassen, eine deutliche Kostenreduktion durch Cloud-Objektspeicher sowie eine überschaubare Skalierbarkeit.

7. ACID-Transaktionen: Lakehouses nutzen ACID-Transaktionen, die eine wesentliche Einschränkung von Data Lakes überwinden und für mehr Zuverlässigkeit und Effizienz sorgen. Zu diesem Zweck verwalten sie die transaktionale Datenverarbeitung und stellen die Integrität der Datenoperationen sicher.

Obwohl Data Warehouses auf eine lange Geschichte zurückblicken und sich weiterentwickelt haben, mangelt es ihnen an Anpassungsfähigkeit, um den heutigen Anforderungen an die Datenverarbeitung gerecht zu werden. Data Lakes wiederum bewältigen viele der Herausforderungen, verlieren aber einige der Vorteile von Data Warehouses. Das Data Lakehouse versucht, diese Unterschiede auszugleichen, indem es die Stärken beider Ansätze kombiniert. Auf diese Weise wird eine Lösung geschaffen, die die besten Eigenschaften beider Architekturlösungen vereint. Die Data-Lakehouse-Architektur befindet sich noch in einem frühen Entwicklungsstadium und benötigt Zeit, um zu reifen und bewährte Verfahren zu etablieren, die nach und nach angewendet werden. In der Zwischenzeit werden Data Warehouses und Data Lakes weiterhin für spezifische Anwendungsfälle eingesetzt. In vielen Fällen können diese beiden Ansätze nebeneinander bestehen und sich gegenseitig ergänzen, um unmittelbare Herausforderungen zu bewältigen.

Fazit

Data Warehouses und Data Lakes waren zu ihrer Entstehungszeit bahnbrechende Lösungen für analytische Herausforderungen, die entwickelt wurden, um gängige Probleme in der damaligen Technologielandschaft zu lösen. Das Lakehouse-Konzept ist ein Produkt der heutigen Zeit und zeigt, dass maschinelles Lernen nicht nur von den Großen der Branche, sondern auch von kleineren Unternehmen eingesetzt wird. Die in diesem Beitrag diskutierten Konzepte bieten Anhaltspunkte für geeignete Problemlösungsansätze. Leider gibt es keine Patentlösung. Auch wenn es den Anschein hat, dass herkömmliche Data Warehouses in der heutigen Datenumgebung überflüssig geworden sind, ist dies nicht ganz richtig. Viele Unternehmen haben noch nicht die nötige Datenreife erreicht, um komplexe Systeme wie ein Data Warehouse zu implementieren. Möglicherweise benötigen sie nur ein einfaches Data Warehouse. Andererseits wollen Dateningenieure oft die neuesten Technologien nutzen und die neuesten Architekturen implementieren. Für Entwicklerinnen und Entwickler ist es daher von entscheidender Bedeutung, die Ursache des Problems zu verstehen und dann nach einer geeigneten Lösung zu suchen, anstatt das am meisten gehypte Konzept anzuwenden.