„Big Data“, „Data Lake“, „Data Swamp“, „Hybrid Architecture“, „NoSQL“, „Hadoop“ … Mit diesen Begriffen werden Sie heutzutage sehr häufig konfrontiert, wenn Sie mit Daten arbeiten. Vor diesem Hintergrund stellt sich die Frage, ob Sie angesichts einer enormen Datenvielfalt und eines stetig wachsenden Datenvolumens tatsächlich noch ein Data Warehouse benötigen. In diesem Beitrag erläutern wir, was ein Data Lake ist, ob beim Einsatz von NoSQL-Plattformen wie Hadoop weiterhin ein Data Warehouse erforderlich ist und wie sich dieses optimal mit Data Vault kombinieren lässt.
Was ist ein Data Lake?
Tamara Dull (SAS) liefert hierzu eine treffende Definition: „Ein Data Lake ist ein Repository, das eine riesige Menge an Rohdaten in ihrem nativen Format vorhält – einschließlich strukturierter,, halbstrukturierterund unstrukturierter Daten. Die Datenstruktur und die Anforderungen werden erst dann definiert, wenn die Daten tatsächlich benötigt werden.“ 1
Dass Datenstruktur und Anforderungen erst bei Bedarf festgelegt werden, bedeutet: Die Struktur wird erst dann abgebildet, wenn die Daten aus dem Repository (dem Data Lake) abgefragt werden – ein Prinzip, das als „Schema-on-Read“ bekannt ist. Der Unterschied zu traditionellen relationalen Datenbankmanagementsystemen (RDBMS mit „Schema-on-Write“) besteht darin, dass Sie die Struktur der Daten bzw. Dateien vor dem Laden in die NoSQL-Datenbank nicht vorab definieren müssen. Dies bedeutet keineswegs, dass Strukturen überflüssig wären – ganz im Gegenteil: Struktur ist essenziell, um einen Data Lake produktiv nutzen zu können. Sie wird jedoch nicht fest im Data Lake selbst definiert, sondern erst in dem Moment angewendet, in dem der Speicherort der Dateien einem Schema für den Lesevorgang zugeordnet wird. Fehlt eine solche Definition und dient eine NoSQL-Datenbank wie Hadoop – die im Kern lediglich ein Dateispeicher ist – rein als unstrukturierte Landing Zone, verwandelt sich der Data Lake rasch in einen Data Swamp. In der Folge müssen Data Scientists oder Power User einen unverhältnismäßig hohen Aufwand betreiben, um diese Datenhalde zu durchforsten und verwertbare Erkenntnisse zu gewinnen.
Mit Werkzeugen wie Hive können Sie ein solches Abfrageschema definieren – und zwar unter Nutzung von Massively Parallel Processing (MPP) auf einem HDFS.
Brauchen wir noch ein Data Warehouse?
Wenn Sie bereits über einen Data Lake mit sämtlichen Unternehmensdaten verfügen, drängt sich die Frage auf: Wird überhaupt noch ein Data Warehouse gebraucht oder fungiert der Data Lake nicht längst als solches?
Dazu lohnt sich ein direkter Vergleich der beiden Konzepte: Ein Data Warehouse speichert Daten themenorientiert, zeitvariant und über einheitliche Business Keys integriert. Ein Data Lake hingegen ist beim Datenladeprozess (Ingestion) weder themenorientiert noch integriert. Zudem kann er Mechanismen wie Change Data Capture (CDC) oder Delta-Verarbeitungen nicht nativ abbilden, da Dateiinhalte nicht direkt aktualisiert, sondern lediglich hinzugefügt oder überschrieben werden. Aus technischer und funktionaler Sicht bestehen gravierende Unterschiede zwischen dem Einsatz eines traditionellen RDBMS für Data Warehouses und NewSQL- bzw. NoSQL-Plattformen für Data Lakes.
Braucht man also noch ein Data Warehouse? Die kurze Antwort lautet: Es kommt auf den Einsatzzweck an. Wenn Sie bislang kein Data Warehouse nutzen und Ihre Aufgaben ausschließlich im Bereich Data Science oder in der explorativen Datenanalyse liegen, ist ein Data Warehouse vorerst meist nicht zwingend erforderlich. Benötigen Sie jedoch verlässliche Strukturen, fundierte Business Intelligence, über mehrere Quellsysteme hinweg harmonisierte Daten und eine Rückbindung der Kennzahlen an Ihre operativen Geschäftsprozesse, führt an einem Data Warehouse kein Weg vorbei. Kurz gesagt: Wenn Sie belastbare Mehrwerte aus den Rohdaten Ihres Data Lake generieren möchten, bleibt ein Data Warehouse das bewährteste Konzept.
Ist bereits ein Data Warehouse vorhanden, empfiehlt sich als Best Practice dessen gezielte Erweiterung: Integrieren Sie Ihr bestehendes RDBMS in den Data Lake oder setzen Sie auf eine hybride Architektur. Dabei wird die relationale Staging Area durch eine HDFS-basierte Staging Area ersetzt, die sowohl strukturierte als auch unstrukturierte Daten flexibel aufnehmen kann.
1 https://www.kdnuggets.com/2015/09/data-lake-vs-data-warehouse-key-differences.html
2 übernommen von https://www.smartdatacollective.com/big-data-cheat-sheet-what-executives-want-know/
