Daten sind das neue Gold. Das ist mittlerweile Allgemeinwissen. Doch ebenso wie Goldgräber können Unternehmen nichts mit einem Haufen Erde und vereinzelten Goldklumpen anfangen. Das Gold muss herausgefiltert und aufbereitet werden, um seinen wahren Wert zu erlangen. Genau so müssen Daten strukturiert abgelegt, bereinigt und erweitert werden, um in analytischen Dashboards oder für das Training von Machine Learning und Künstlicher Intelligenz genutzt werden zu können.
Der Autor: Dimitri Dumonet ist Mitgründer und Chefentwickler von Emax DigitalAbhängig von der Menge der Daten, der Aufnahmefrequenz und der geforderten Verfügbarkeit sind hier aktuell unterschiedliche Ansätze möglich.
Zu Beginn eines neuen Big-Data-Projekts ist es oft die einfachste Lösung, die gesammelten Daten direkt in einem Data Warehouse zu speichern. Dieses ist für schnelle Lesezugriffe optimiert, wird aber während der Schreibzugriffe für laufende Lese- und Transformationsoperationen zu langsam. Die daraus resultierenden Ladezeiten können bei Kunden mit dynamischen Dashboards zu Frustrationen führen. Um das kontinuierliche Schreiben kleiner Datenmengen zu verhindern, wird ein Puffer benötigt. Dieser sammelt die Daten und überträgt sie in größeren Mengen in das Data Warehouse.
Ein Data Lake ist ein beliebtes Speichersystem, das als Puffer verwendet werden kann (siehe Abb. 2). Während die Daten in einem Data Warehouse strukturiert abgelegt werden, können sie im Data Lake auf eine unstrukturierte Weise und in verschiedenen Formaten gespeichert werden. Aber Achtung, auch hier gilt: Je einheitlicher und strukturierter, desto schneller und effizienter ist der Zugriff auf die Inhalte. Wird der Data Lake zu unstrukturiert, spricht man von einem Data Swamp.
Durch das Implementieren eines Data Lakes ergeben sich noch weitere Vorteile. Bei dem direkten Einfügen der Daten in ein Data Warehouse entfällt oft die Möglichkeit, die Daten vor dem Laden zu transformieren. Es müssen also weiterhin ETL-Pipelines (Extrahieren, Transformieren, Laden) genutzt werden. Die Transformation muss bei jedem Laden vom Data Warehouse berechnet werden. Dies führt erneut zu längeren Wartezeiten auf Seiten des Kunden und zu höheren Kosten für das Data Warehouse. Natürlich können diese Transformationen auch direkt auf der Datenbank vorberechnet werden, um so Ressourcen zu sparen, jedoch wird das Problem damit nur verschoben, da zu den Zeiten der Berechnung das Data Warehouse immer noch belastet wird.
Durch das günstige Angebot von skalierenden Speicherlösungen (z. B. Services wie Amazon S3) und die Verfügbarkeit von „günstiger“ On-demand-Rechenleistung eignet sich der Data Lake perfekt für die Implementierung einer ELT-Pipeline. Die Daten werden hier unbearbeitet in das Data Lake geladen. Eine angereicherte oder aggregierte Kopie der Daten wird erstellt und dann in das Data Warehouse geladen.
Der Speicher im Data Warehouse ist oft teuer, deshalb kann es sich lohnen nur aktuelle und häufig genutzte Daten dort abzulegen. Mit einem Data Lake ist dies kein Problem. Die Daten können einfach nach einer gewissen Zeit aus dem Data Warehouse gelöscht werden, sind aber immer noch über den Data Lake verfügbar und können bei Bedarf mit höherer Latenz geladen werden.
Es gibt zahlreiche Wege auf die Daten in einem Data Lake zuzugreifen. Besonders mittels Python und R sowie durch Technologien wie Spark. Diese Programmiersprachen zählen auch zu den gängigsten im Bereich Data Science und werden in Machine Learning Bibliotheken wie TensorFlow, PyTorch und XGBoost genutzt. Diese sind wiederum wie geschaffen für den Zugriff auf Data Lakes, da für das Trainieren von Machine-Learning-Modellen immer große Mengen von Daten auf einmal geladen und transformiert werden müssen, ohne dass der Endkunde während dieser Prozesse mit Verzögerungen in seinen Dashboards leben muss.
Data Warehouses sind dagegen vor allem auf das Laden von Ergebnissen einer Analyse oder kleinere Datenmengen ausgelegt. Jedoch gibt es Bestrebungen, Machine Learning direkt über ein Data Warehouse zu ermöglichen. Beispiele hierfür sind Technologien wie Redshift ML oder der direkte Zugriff von Amazons Machine-Learning-Plattform: Sagemaker auf Redshift. Auch der Anbieter Snowflake bietet Möglichkeiten als Data Warehouse direkt Machine Learning Models zu trainieren.
Ein Nachteil, einen Data Lake und ein Data Warehouse zeitgleich zu betreiben ist, die Daten immer an zwei oder mehreren Orten speichern zu müssen. Das erhöht die Anzahl der zu nutzenden Technologien, die verstanden, gewartet und überwacht werden müssen. Das wiederum erhöht die Komplexität und kann zu einer höherer Fehleranfälligkeit und Kosten führen. Zudem besteht das Problem, dass die Daten nicht aktuell sind, da sie erst in verschiedenen Schritten bearbeitet werden (ETL) bis sie schließlich im Data Warehouse verfügbar sind.
Sowohl das Data Warehouse als auch der Data Lake bringen also Vorteile mit sich und können sich an bestimmten Stellen ergänzen. Mit neuen Technologien wie Delta Lake, Apache Iceberg oder Apache Hudi nähern sich die beiden Technologien jedoch immer mehr aneinander an. Das wirft die Frage auf, ob in einigen Jahren überhaupt noch beide Systeme einzeln relevant sind oder ob sie zu einem Hybrid verschmelzen.
Ein Nachteil des traditionellen Data Warehouses ist, dass der Speicher und die Rechenleistung nicht unabhängig voneinander skaliert werden können. Das führt bei immer größer werdenden Datenmengen zu untragbaren Kosten. Moderne Data Warehouses wie Redshift und Snowflake gestatten es zumindest teilweise, ähnlich wie bei einem Data Lake, die Speicherkapazität und Rechenleistung unabhängig voneinander zu skalieren.
Die wohl wichtigsten Features eines Data Warehouses gegenüber einem Data Lake sind DBMS Management Features wie z. B. Zugriffsberechtigungen von Usern auf bestimmte Daten, ACID-Transaktionen, Versionierung, Auditing, Indexing, Caching und Query-Optimierungen.
Es gibt bereits Open-Source-Technologien, die einiger dieser Features in einem Data Lake ermöglichen. Delta Lake, Apache Iceberg oder Apache Hudi erstellen einen Metadaten-Layer zwischen dem Data Lake und der darauf nutzenden Applikation (siehe Abb. 3). Dieser Layer beinhaltet u. a. Informationen darüber, welche Objekte zu welcher Tabellenversion gehören. Dadurch werden ACID-Transaktionen ermöglicht und auch der Zugriff von Nutzern auf bestimmte Daten kann beschränkt werden. Weiterhin wird eine Versionierung der Daten im Data Lake dadurch vereinfacht. Außerdem können bestimmte Schemata für Daten erzwungen werden, indem man diese in dem Metadaten-Layer hinterlegt und beim Hochladen verifiziert.
Auch für die Verbesserung der Performance können diese Metadaten genutzt werden. Einen Teil der zu analysierenden Daten kann in einer schnelleren SSD (Solid-State Drive) oder im RAM (Random-Access Memory) gehalten werden. Dabei kann mit den Metadaten durch die Nutzung von Transaktionen festgestellt werden, welche der vorgehaltenen Daten noch aktuell sind. Zudem können Minima, Maxima oder Summen von Reihen hinterlegt werden, was die Suche von Datenpunkten beschleunigt.
Die offene Architektur des Lakehouse-Ansatzes zur Speicherung, Transformation und Auswertung von Daten stellt sich zunehmen attraktiver dar. So können für das Einfügen und Transformieren von Daten gezielt separate On-demand-Ressourcen gebucht werden, um so die Latenz von Kundenabfragen nicht zu beeinträchtigen. Außerdem werden Daten in einem Data Warehouse meist in einem proprietären Datenformat gespeichert. Aufgrund immer strengerer Regularien zu Daten und der Wunsch von Firmen nicht von einem Anbieter abhängig zu sein, geht der langfristige Trend der Softwareindustrie in Richtung offener Datenformate.
In Data Lakes wird hier meist das Open-Source-Datenformat Parquet genutzt. Der Lakehouse-Ansatz versucht die besten Seiten eines Data Lakes mit denen eines Data Warehouses zu vereinigen, um so zwei Systeme durch eines zu ersetzten. Vor allem die kürzeren ETL-Pipelines, die Kostenersparnisse sowie die verminderte Komplexität durch das Wegfallen multipler Technologien erhöhen den Anreiz der Implementation eines Lakehouses.