Boxhandschuhe als Symbol für Entscheidung zwischen Data Lake und Data Warehouse

Data Lake vs. Data Warehouse

Welche Lösung ist die richtige?

Datum

15.02.2022

Dieser Beitrag wurde verfasst von:

Marc Bastien

Geht es um die Speicherung großer Datenmengen, kommt man um die Begriffe Data Lake und Data Warehouse kaum herum. Vielen Unternehmen stellt sich früher oder später die Frage, welche der beiden Lösungen für welchen Anwendungsfall geeignet ist. In diesem Beitrag widme ich mich mit Erkenntnissen aus aktuellen Projekten in Kombination mit Erfahrungen und Versprechungen der Vergangenheit dem Thema Data Lake vs. Data Warehouse.

Dabei führt eigentlich schon der Titel in die Irre: „vs“ – wieso eigentlich „versus“, also entweder – oder? Das Thema „Data Warehouse“ ist und bleibt aktuell. Tatsächlich nehme ich bei unseren Kund*innen oft genau diese Vorstellung „entweder – oder“ wahr. In weiteren Gesprächen stellen wir zusammen fest, ob (und wie) ein integrierter Ansatz nicht viel sinnvoller ist, bzw. wie die beiden Ansätze sich ergänzen.

Zuerst kommt das Fachliche, dann die Technologie!

Ich wehre mich an dieser frühen Stelle ausdrücklich, beide Ansätze jetzt schon mit Technologien zu verbinden. Denn: die Entscheidung für das eine oder das andere sollte stets fachlich und nicht technisch getroffen werden! Stattdessen werde ich mich im Folgenden etwas detaillierter mit Data Lake und Data Warehouse auseinandersetzen, um später auch das eine oder andere zu möglichen Umsetzungen zu schreiben.

Gemeinsamkeit: Nutzung von Informationen

Gemeinsam haben Data Lake und Data Warehouse, dass in ihnen die technische, aber auch fachliche Basis für nachvollziehbare, (qualitäts-)gesicherte Informationen gelegt wird. Auf dieser lässt sich in unterschiedlicher Intensität und Qualität analysieren.

Das Verständnis um den Mehrwert von Informationen macht den Unterschied

Unternehmen weisen ein unterschiedliches Verständnis davon auf, welche Mehrwerte Informationen potenziell bieten. In Abhängigkeit dessen variieren die Anforderungen an analytische Fähigkeiten und damit entsteht auch die Notwendigkeit in der Bereitstellung unterschiedlicher Technologien.

Unternehmen, die wenig Mehrwerte in der Nutzung von Informationen sehen, werden ihre Aktivitäten in diesem Bereich auf die reine Bereitstellung der Daten zur historischen Betrachtung beschränken. Andere Unternehmen, die vielleicht sogar Informationen als Teil ihres Geschäftsmodells sehen, werden Daten sammeln, deren Wert derzeit möglicherweise noch fraglich ist und später mithilfe AI-gestützter Algorithmen Methoden finden, um den Inhalt zu verstehen und Mehrwerte zu generieren. Die höchste Stufe erreichen Unternehmen, die Informationen als zentralen Baustein all ihrer Aktivitäten verstehen und diese damit ergänzen: Sei es in der Produktion durch Ausschussreduktion, im Controlling durch vorausschauendes Cashflow Management, im Vertrieb durch gezielte Kundenansprache, oder oder oder…

Aus diesen Überlegungen ergeben sich die Anforderungen an die analytische Plattform: Data Warehouse, Data Lake? Womöglich beides oder besser noch eine Planungsapplikation mit OLAP? Die Möglichkeiten sind groß und der Bedarf nach der passenden Architektur ebenfalls. 

Data Lake & Data Warehousing
zur Speicherung von Big Data

Was genau ist ein Data Lake? Was ein Data Warehouse? Auf unseren Kompetenzseiten geben wir einen Überblick über grundlegende Begriffe.    

Data Warehouse & Data Lake im Vergleich

Das Data Warehouse – klassisch, aber nicht veraltet!

Die verschiedenen Schichten eines Data Warehouse'.

Der klassische Ansatz eines Data Warehouse besteht in der Bereitstellung eines „Single Point of Truth“. Sowohl technische als auch fachliche Gründe führten zur Entstehung von Methoden, die alle ihre Berechtigung und jede für sich Vor- oder Nachteile haben: ob Inmon oder Kimball, ob Star- oder Snowflake-Schema oder gar Data Vault.

Allen Methoden ist gemein, dass Daten aus unterschiedlichen Vorsystemen zum Zwecke der Analyse über mehrere Schichten hinweg in ein finales gemeinsames Schema gepresst werden. Der Anspruch: aus diesem Schema langfristig immer korrekte und nachvollziehbare Daten erhalten. Anbei eine schematische Darstellung inklusive aller in der Data Warehouse-Architektur üblichen Schichten / Stages. In echten Kundenprojekten werden sich Architekturen finden, die auf die eine oder andere Schicht verzichten. Dieses Schema wird fachlich vorgegeben und erfüllt hervorragend den Zweck eines einheitlichen Datenpools, um Nachvollziehbarkeit sicherzustellen.

Es ist kaum vorstellbar, dass Unternehmen ohne diesen Datenpool auskommen, und doch finden sich in unseren Projekten viele Kunden, die bisher darauf verzichteten. Stattdessen werden bei Bedarf Extrakte aus den operativen Systemen gezogen und irgendwie mit den erwartbaren Problemen in Excel gemergt: inkonsistent, aufwendig, nicht nachvollziehbar oder schlicht: unbrauchbar und falsch.

Data Lake, Big Data und die 3 (5, 7, 9, ..) „V“s – die Entwicklung des Data Lake

Das Thema Data Lake wurde in den 2010er aktuell und wurde damals vor allem in Kombination mit den 3 (bei einigen Herstellern auch gerne mehr) „V“ von Big Data zusammengebracht.

Die „V"s von Big Data
  • V – Velocity (Geschwindigkeit)
  • V – Volume (Umfang / Datenmenge)
  • V – Variety (Vielfalt)
  • Weitere V für Variability, Veracity, Value, and Visibility (einige Hersteller waren sehr kreativ)

Außerdem wurde, gemäß der Sicht auf damals vorhandene Technologien, davon ausgegangen, dass ein Data Lake nicht mit klassischer Data Warehouse-Technologie umgesetzt werden könne. Anstatt relationaler Datenbanken kam also meist Hadoop oder wenn, differenzierter, sogenannte NoSQL (Not Only SQL)-Technologie zum Einsatz.

Heute ist das Verständnis noch differenzierter und man geht auch hier von den fachlichen Anforderungen aus: Unter einem Data Lake wird die Möglichkeit verstanden, Daten, deren Nutzen und Nutzung (noch) nicht bestimmt ist, im Rohformat vorzuhalten. Typischerweise erfolgt die Analyse aufgrund der Rohform der Daten dann durch Spezialisten, den Data Scientists.

Die Mächtigkeit eines Data Lake zeigt sich gerade durch die Kombination aus großen Datenmengen und modernen, AI-gestützten Analysemethoden, mit denen aus vielen Datenpunkten (teil-) automatisiert relevante Information extrahiert und Zusammenhänge erkannt werden.

„Data Warehouse vs. Data Lake” vs. „Data Warehouse UND Data Lake”

Die verschiedenen Aspekte von Data Governance.

Wenn davon ausgegangen wird, dass der Nutzen eines Data Lake vor allem darin besteht, Rohdaten zur späteren Analyse vorzuhalten, sollte die Schichten-Architektur eines Data Warehouse genauer betrachtet werden. Schon seit Jahren wurden Daten in einer der Schichten, je nach Ansatz im „ODS –Operational Data Store“ oder „Stage“, für analytische Sonderfälle vorgehalten. Also genau das, was mit einem Data Lake auch erreicht werden will! Der Unterschied liegt darin, dass in der Schicht zwar Rohdaten, aber nur die, die im Data Warehouse von Nöten sind, gehalten werden und dass sich auf Daten beschränkt wird, die in die Struktur eines Relational Database Management Systems (RDBMS) passen.

Warum also nicht beide Ansätze kombinieren, wenn der Bedarf besteht: Ausbau um zusätzliche Daten (Menge & Format!) einerseits und analytische Fähigkeiten andererseits.

Data Governance im Data Lake

An dieser Stelle sei darauf hingewiesen, dass es nach meiner Einschätzung mindestens einer weiteren Aktivität bedarf, damit der Data Lake langfristig erfolgreich wird: Data Governance.

Während im Data Warehouse, bedingt durch die Architektur, oftmals der Datenbewirtschaftungsprozess und das Datenmodell klar definiert sind – wir erinnern uns: alles beginnt mit dem Datenmodell – werden im Data Lake möglicherweise sämtliche Daten des Unternehmens bevorratet. Es ist unabdingbar, diese Daten zu katalogisieren, einen Dateneigentümer („Data Steward“) zu benennen und ebenfalls ein Qualitäts- und Schutzkonzept für diese Daten zu implementieren.

Damit soll ausdrücklich nicht gesagt werden, dass darauf in einem Data Warehouse verzichten werden sollte! Die Erfahrung hat allerdings gezeigt, dass in Data Warehouse-Projekten aus den o. g. Gründen oft darauf verzichtet wird, solange dies nicht regulatorisch vorgeschrieben ist.

Fazit: Kombination beider Ansätze als mögliche Lösung

Data Warehouse und Data Lake ergänzen sich perfekt. Die Schichtenmodelle sind so unterschiedlich nicht!

Je nach absehbaren Anforderungen sollte bei der Auswahl der Technologie hinsichtlich Menge und Vielfalt eine gewisse Skalierbarkeit berücksichtigt werden, um einerseits für den Moment „nicht mit Kanonen auf Spatzen zu schießen“, andererseits nicht in Projekte zu investieren, die die notwendige Skalierung nicht zulassen. Der Ansatz eines „Data Lake Workshops“ hat sich dabei bewährt: umfangreiche Analyse der Ist-Situation, Integration aller Stakeholder und sorgfältige Planung einer Architektur und dann die Ableitung eines Vorgehens und einer Technologie.

Ergänzend sei an dieser Stelle erwähnt, dass im aktuell top-aktuellen Thema „Data Fabric“ viele Aspekte des Data Warehouse- / Data Lake-Konzeptes aufgenommen und ergänzt wurden. Insbesondere die Notwendigkeit eines Datenkataloges, der Möglichkeit der kombinierten Datenanalyse auf Daten unterschiedlicher Quellen on-the-fly und in Echtzeit, werden konsequent weitergedacht. Mehr zu diesem Thema in einem separaten Blogbeitrag.

Über den Autor: Marc Bastien

Marc Bastien ist als Analytics Architect bei der TIMETOACT sowohl mit architekturellen Fragestellungen als auch mit deren Umsetzung beschäftigt. In mehr als 25 Jahren beruflicher Tätigkeit ist er stets dem Thema Analytics treu geblieben, zuerst beim Anwender, dann bei Anbietern und schließlich als Berater. Fachliche analytische Kundensituationen und die resultierenden Lösungen reizen ihn besonders. Sein Motto: „Steht doch alles in den Daten, muss man doch nur nutzen!“.

Marc Bastien
Software ArchitectTIMETOACT Software & Consulting GmbHKontakt

Unsere Kompetenzen im Bereich Business Intelligence: