Was ist ein Data Lake? Definition, Architektur und Use Cases

Der Data Lake ist ein neueres Konzept zur Erfassung, Speicherung und Verarbeitung von Daten. In diesem Artikel stellen wir eine Definition des Data Lakes zur Verfügung, diskutieren Vor- und Nachteile, gehen auf konkrete Anwendungsfälle ein und zeigen Möglichkeiten auf, wie die Infrastruktur bzw. Architektur eines Data Lakes aussehen kann. 

Inhaltsverzeichnis

Einfach erklärt: Was ist ein Data Lake?

Als Data Lake (Deutsch: “Datensee”) definiert man eine Kombination von verschiedenen Technologien um eine Bandbreite an Datentypen gemeinsam zu verwalten. Einfach gesagt geht es darum, dass einerseits die aufwendige Vorbereitung von klassischen Datenbanksystemen vermieden wird, andererseits auch einfach unstrukturierte und unverarbeitete Daten gespeichert werden können.

Am einfachsten kann man das Konzept eines Data Lakes so erklären, dass er sich wie eine Festplatte auf einem Computer verhält. Auf der Festplatte kann man alle Arten von Daten speichern und verwalten. Selbst Daten, die man bisher weder kennt noch verarbeiten kann, können dort gespeichert werden. Also kann man Bilder, Videos, aber auch unverarbeitete strukturierte Daten wie CSV einfach ablegen um sie später zu verwenden.

Klassische Datenbanken hingegen wären in dieser Analogie strukturierte Daten, zum Beispiel ein Excel-File. Die Struktur ist vorgegeben, der Inhalt strukturiert erfasst und es lassen sich einfach Analysen und Operationen auf den Daten durchführen, während im Data Lake gegebenenfalls noch weitere Schritte notwendig sind, bevor eine Verarbeitung möglich ist. Interessanterweise kann ein Data Lake durch seine Bandbreite an Technologien wiederum ganze Datenbanken und -systeme enthalten. Also wäre es ganz natürlich, dass auf unserer Festplatte auch aufbereitete Excel-Dateien auftauchen.

Den Ursprung haben Data Lakes als Konzept in einem Artikel von Forbes, bei dem der CTO des ETL-Tools Pentaho den Begriff notiert, um seine Ansicht zur Datenverwaltung zu klassischen Data Marts zu kontrastieren. Seitdem hat sich der Begriff zwar gehalten, aber die ursprüngliche Definition, einfach alle Daten in ein verteiltes Dateisystem wie Hadoop zu kippen, ist mehrfach verfeinert worden.

Um es als eine kurze Definition zusammenzufassen: Ein Data Lake hat zum Ziel, strukturierte und unstrukturierte Daten gleichermaßen in allen Verarbeitungsstufen zu erfassen.

Vorteile eines Data Lake

Dass die Idee eines Data Lakes einsichtig ist, lässt sich kaum bestreiten. Doch was sind konkret die Vorteile einer solchen Architektur, speziell auch im Vergleich zu älteren Datenbanksystemen wie einem Data Warehouse?

Erfassung von unstrukturierten Daten

Eine der Grundideen und nach wie vor einer der Vorteile ist die Erfassung von unstrukturierten Daten im Data Lake. Grundlage hierbei sind vor allem Big Data-typische Datenmengen und Arten, die vor allem auch mittels Data Science weiter analysiert werden sollen. 

Dass unstrukturierte Daten wie Bilder, Videos, Text und mehr in den Fokus von Unternehmen rückt ist einfach durch einerseits die Explosion an Datenmengen zu erklären, andererseits auch ganz klar dadurch, dass immer mehr Unternehmen Data Mining mittels künstlicher Intelligenz betreiben und versuchen einen Mehrwert aus ihren Daten zu generieren.

Erfassung der verschiedenen Verarbeitungsstufen (“Distillierung”)

Ein weiterer wichtiger Aspekt für die Vorteile von Data Lakes ist die Möglichkeit, verschiedene Schritte in der Datenaufbereitung und -verarbeitung als eigenständige Datensätze mit zu dokumentieren. Ob nun Rohdaten, die Konsolidierung verschiedener Datensätze, Aggregation oder wirklich aufbereitete Daten entweder für Dashboards oder Machine Learning: Alle Zwischenschritte können im Data Lake gespeichert und somit mitprotokolliert werden.

Dies hat mehrere Vorteile. Zum einen erlaubt es einfach und schnell nachzuvollziehen wie die verschiedenen Datensätze am Ende entstanden sind, zum anderen kann jeder Zwischenschritt wiederum von anderen Nutzern eingesetzt werden. Fügt zum Beispiel eine Einheit Produkt- und Transaktionsdaten zusammen, können diese auch direkt für andere Zwecke wiederverwendet werden.

Schnelle Speicherung, schneller Zugriff

Da Data Lakes generell dem ELT-Modell folgen, also beim Speichern der Daten kein Datenmodell benötigen, ist es wesentlich einfacher und schneller Daten zu erfassen. Monatelange Diskussionen welches Datenmodell geschickt wäre löst sich mit der Speicherung von Rohdaten schnell auf. 

Das Gleiche gilt im Umkehrschluss für den Zugriff. Sind Rohdaten erst einmal im Data Lake vorhanden, können diese auch schnell und einfach ausgeliefert werden und müssen nicht erst noch umständlich nachträglich aus den Quellsystemen extrahiert werden. 

Der Wert ist noch undefiniert – somit eine hohe Chance bei Wiederverwertung

Direkt anknüpfend an den Vorteil des ELT-Prozesses ist auch der Wert der Daten wesentlich höher, da die Granularität und der Informationsgehalt höher ist. Der Grund ist simpel: Bereitet man Daten auf, kann man Granularität nur verringern und Daten können maximal weggelassen werden. Somit sind Rohdaten generell immer von höherem Wert als aggregierte oder aufbereitete Daten.

Dieser Vorteil war auch seit jeher einer der Gründe für die Speicherung von Rohdaten in einem Data Lake. “Wer weiß, wofür ich diese Daten noch brauchen kann” – diesem Gedanken zu folgen ist erst möglich, seit auch Rohdaten gespeichert werden und nicht nur die transformierten Datensätze ins Business Warehouse übertragen werden.

Entlastung von Quellsystemen

Ein weiteres Hauptargument ist die Entlastung von den Datenquellsystemen. Indem man die Daten vollständig in den Data Lake repliziert, wird das System nur einmal bei der Extraktion belastet, nicht bei jeder Analyse. Dies ist vor allem bei Kernsystemen ein fundamentaler Vorteil: Denn Überlastung eines Kernsystems hat üblicherweise schwerwiegende Folgen.

Reich technisch gesehen sind Data Lakes zudem besser gewappnet für hohe Datenanfragen und können entsprechend skalieren als herkömmliche Software-Tools, die nicht für eine hohe Anzahl an Rohdatennutzern ausgelegt sind.

Abschaffung von Datensilos

Ein letzter Vorteil den wir hier aufführen möchten ist die schrittweise Abschaffung von Datensilos. Indem man die Rohdaten gemeinsam in einen zentralen Data Lake speichert, umgeht man Grenzen in der Verantwortung von Quellsystemen. Dies erlaubt eine Demokratisierung der verfügbaren Daten und schafft einen gemeinsamen Nenner, welche Daten vorhanden sind und wie sie zur Generation von Mehrwert eingesetzt werden können.

Gefahren eines Data Lake

Doch nebst dieser zahlreichen Vorteile gibt es selbstverständlich auch Gefahren beim Einsatz eines Data Lakes.

Der Data Lake wird zum Data Swamp

Die Nutzbarkeit eines Data Lake steht und fällt mit der entsprechenden Datenverwaltung, Data Governance genannt. Nur wenn sauber dokumentiert ist, welche Daten sich im Data Lake befinden, können sie gepflegt und genutzt werden. 

Folgt man dieser strikten Verwaltung nicht, hat man bald keinen Überblick mehr welche Daten in welcher Aktualität in welchen Analysen und Kanälen genutzt werden. Auch die Ownership oder im schlimmsten Fall die Inhalte bzgl. DSGVO-Kompatibilität kann unklar sein.

Übt man also keine saubere Data Governance, verkommt der See zu einem Sumpf von vielen Daten, den keiner mehr durchblickt – metaphorisch Data Swamp genannt. 

Anti-Demokratisierung von Datenanalyse

Eigentlich soll durch die Ablösung von Datensilos ja der Zugriff auf die Daten vereinfacht und somit die Verfügbarkeit verbreitert werden. Der negative Aspekt dabei ist jedoch, dass bei klassischen Business Warehouses and dergleichen meist der Weg zum Self-Service der Daten wesentlich kürzer ist als bei einem aus mehreren hochspezialisierten Technologien bestehenden Data Lake.

Folglich kann man argumentieren, dass durch die nicht-Aufbereitung der Daten in einem Data Lake die Daten auch schwieriger verfügbar sind, vor allem für Nicht-Spezialisten. Da der Weg zum “Citizien Data Scientist” auch noch wesentlich weiter ist als zum “Citizien Data Analyst”, muss genau beachtet werden, wie man die Data Lake Inhalte auch zur Verfügung stellen kann, so dass eine möglichst breite Masse darauf zugreifen kann.

Technologische Überverwaltung

Ein weiterer logischer Punkt gemäß des infrastrukturellen Aufbaus von Data Lakes ist die notwendige Verwaltung der verschiedenen Technologien. Vor allem die Kombination von verschiedenen Systemen und Tools in ein Framework, das es erlaubt, dass die Technologie Hand-in-Hand geht, ist eine große Herausforderung. 

So muss das Ziel sein, dass die Bandbreite an eingesetzten Tools möglichst gering ist, während gleichzeitig alle Anforderungen erfüllt werden wollen. Dies erfordert hoch spezialisierte Enterprise Architekten und Data Engineers, die den Data Lake entsprechend langfristig planen, Standards etablieren und ein Abrutschen in eine Tool- statt Datenzentrierung verhindern.

Hohe Kosten

Dieser Punkt folgt direkt aus dem vorhergehenden. Ein Data Lake hat üblicherweise mehrere Systemkomponenten, die auch von unterschiedlicher Komplexität sein können. Hat ein Data Lake zum Beispiel Tools für die Erfassung von unstrukturierten Daten und strukturierten Daten, muss entsprechend Personal zum Management von beiden Lösungen zur Verfügung stehen. Neben diesen Kosten kommen die üblichen Kosten für Lizenzen und Hardware hinzu. Und auch die Architekturkomponente – welche System wie miteinander interagieren – und die Governance-Komponente darf man als Kostenfaktor nicht unterschätzen.

Data Lake vs. Data Warehouse: Was ist der Unterschied?

Während wir die Unterschiede zwischen dem Data Lake Konzept und einem viel weiter verbreiteten Business Data Warehouse haben bereits mehrfach anskizziert haben, hier nochmal Details zur Unterscheidung zwischen den beiden Prinzipien:

  • Datentypen: Data Lakes verarbeiten alle Arten von Datentypen, egal ob strukturiert oder unstrukturiert, egal ob Bild, Ton oder Tabellen. Data Warehouses sind im Gegensatz auf strukturierte Daten beschränkt.
  • Data Pipelines: Data Warehouses setzen das ETL-Prinzip (Extract-Transform-Load) ein, welches Daten aus Quellsystemen auf ein vorgegebenes Datenmodell anpassen, bevor sie ins Warehouse eingespeist werden. Data Lakes hingegen nutzen das ELT (Extract-Load-Transform), laden also die Daten direkt in ihrer ursprünglichen Rohdatenversion in den Lake.
  • Informationsgehalt: Direkt folgend aus vorherigem Punkt muss in Data Warehouses der Informationsgehalt schrumpfen, da die Transformation immer mit Verlust von Daten einhergeht. Beim Lake hingegen werden alle Daten und somit auch der gesamte Informationsgehalt komplett erhalten. Dies ist besonders relevant beim Einsatz von Machine Learning oder Deep Learning durch Data Scientists, da hier möglichst viele Attribute eingesetzt werden sollen.
  • Self-Service: Der Self-Service der Datenanalyse ist im DWH wesentlich höher, da die Daten strukturiert und zur Verarbeitung transformiert bereit stehen. Im Data Lake hingegen ist der Self-Service auf die Rohdaten selbstverständlich höher, aber jeder Zugriff erfordert generell mehr Expertise.
  • Flexibilität: Egal ob Datenquellen, Attribute oder Anwendungen – ein Data Lake ist darauf getrimmt, hoch flexibel mit neuen Daten umzugehen. Ein Data Warehouse hingegen muss erst durch die verschiedenen Aufbereitungsstufen laufen, bevor neue Daten integriert werden können.
  • Pflegebedarf: Während der initiale Pflegebedarf beim Data Warehouse abschreckend wirkt, erlaubt es, in nachfolgenden Schritten kaum Aufwand bezüglich der Dokumentation und Datenqualität zu betreiben. Der Data Lake hingegen erfordert ein vielfaches an Data Governance und Data Management, um nicht zum Data Swamp zu verkommen.

Noch mehr Details zum Unterschied zwischen Data Lake und Data Warehouse findet ihr in unserem ausführlichen Artikel “Data Warehouse vs Data Lake: Der Unterschied einfach erklärt”.

Use Cases als Beispiele für den Einsatz eines Data Lakes

Nun haben wir relativ ausführlich dargestellt, wie das Konzept eines Data Lakes aussieht und welche Vor- und Nachteile er mit sich bringt. Das wichtigste ist jedoch die Frage: Warum soll eine Organisation überhaupt einen Data Lake etablieren? Hier stellen wir kurz mehrere Anwendungsfälle vor, die direkt in die Idee des Datensees einzahlen.

Analytics, Data Science, Machine Learning

Der Ursprung und vermutlich auch nach wie vor das Hauptanwendungsgebiet eines Data Lakes ist die Nutzung mittels Datenanalyse, Data Science und vor allem Machine Learning. Die Idee ist, dass man einen Zugriff auf möglichst viele Daten in möglichst roher Form besitzt, um diese dann optimal gewinnbringend einzusetzen.

Als Beispiel kann die Kombination von strukturierten und unstrukturierten Daten in einem Machine Learning Modell dienen. Bei klassischen Data Warehouses wären ein Teil der Daten nicht verfügbar, somit müsste auf andere Systeme ausgewichen werden. Diese Systeme würden gegebenenfalls wieder in einer ganz anderen Umgebung laufen, andere Zugänge benötigen und anderes Personal zur Pflege voraussetzen. Daher der klare Vorteil eines Data Lakes, der diese Aspekte mitbringt.

API-Management als Grundlage für Datenverfügbarkeit

Oft sind Unternehmen schon so sehr damit ausgelastet, Daten in einen Data Lake zu replizieren, dass sich wenig Gedanken über die Wiederzurverfügungstellung gemacht wird. Direkter Datenbankzugang oder Systemabhängige APIs sind meist die Lösung der Wahl. Denkt man hingegen einen Schritt weiter, macht es absolut Sinn, eine übergreifende API für die gespeicherten Daten zur Verfügung zu stellen. 

Dieser Anwendungsfall des Data Lakes sieht also die Datenanalyse als nur einen Anwendungsfall der Daten im Data Lake. Weitere Anwendungsfälle können erweiterte Data Pipelines in andere Systeme, die Extraktion von Daten aus einem Legacy System oder die Bereitstellung von Daten für Kanäle (z.B. Website) sein. Wenn dies durch eine API abgewickelt werden kann, lassen sich schnell und einfach Systeme und Datenbanksysteme auswechseln, ohne dass andere Entitäten innerhalb der Data Pipeline davon betroffen sind.

Internet der Dinge und Daten-Streaming

Ein weiteres Beispiel bei dem Data Lakes glänzen ist das Internet of Things (IoT), zu Deutsch Internet der Dinge. Durch Data Streaming muss es kontinuierlich die Möglichkeit geben, neue Daten zu speichern und ggf. auch direkt zu analysieren. In einem Batch-Processing basierten Data Warehouse ist dies kaum möglich, da die Data Pipelines dafür gar nicht angedacht sind. Im Data Lake hingegen muss man “nur” eine High Frequency Datenbank hinzufügen und schon kann man seinen Lake um die Fähigkeit zum Stream Processing erweitern – und ist gewappnet für das Internet der Dinge.

Unstrukturierte Daten rücken immer mehr ins Zentrum

Ein weiterer klassischer Anwendungsfall als direktes Merkmal von Big Data sind die unstrukturierten Daten. Wir sind in einem Zeitalter angekommen, in dem es nicht mehr nur um strukturiert erfasste Information geht, sondern vor allem in der Bandbreite an möglichen “Sensoren” zur Datenaufnahme liegt ungeheueres Potential.

Daher gibt es auch immer mehr Bewegungen, um unstrukturierte Daten zu erfassen, zu speichern und zur Verfügung zu stellen. Ob nun Bild oder Ton, ob Text oder Video – es gibt genug unstrukturierte Daten, dass sich ein umfassendes Beschäftigen mit einem Data Lake auch für diesen Zweck lohnt.

Weitere Beiträge zum Thema Data Driven Company direkt per E-Mail bekommen:

Beispiele für eine Data Lake Architektur

Wir wissen nun was ein Data Lake ist, wir haben ausgeführt wieso ein Data Lake sinnvoll ist – bleibt noch das Wie. Data Lake Infrastruktur ist ein sehr breites, allgemeines Feld, da es keine einzige Lösung gibt, sondern die Architektur eher den Gedanken dem Unternehmen gefügig macht. Dennoch möchten wir hier Beispiele für eine Data Lake Infrastruktur bzw. Architektur zeigen und im Falle von AWS und Azure auch konkret mit Services hinterlegen.

Template der Bestandteile eines Data Lakes

Ein Data Lake hat üblicherweise mehrere Schichten. Ganz Vorne, also am Ursprung, stehen die Quellsysteme. Ein Quellsystem kann ein ERP, ein CRM, eine einfache Textdatei, eine vorhandene Datenbank oder auch ein Stream sein. 

Um diese Quellsysteme in den Data Lake zu integrieren, gibt es den Data Ingestion Prozess. Hierbei werden die Daten mittels ELT, ggf. auch ETL in den Data Lake überführt. Einfach gesagt werden Data Pipelines – also Skripts oder Tools – genutzt, um die Daten von der Quelle in eine Datenbank oder ein Filesystem zu überführen.

Dies ist auch bereits die nächste Schicht, die Data Storage. Ganz offensichtlich ist die Speicherung von Daten das Herzstück des Data Lakes und somit auch der größten Varianz. Üblicherweise wird im Storage Layer mindestens zwischen strukturierten und unstrukturierten Daten unterschieden, oft kommen auch noch die Fragen nach Cloud oder On-Premise oder Streaming-Architekturen zur Sprache. Im Grunde besteht diese Schicht in Data Lakes aber immer aus einer Rohdatenerfassung (“Raw Zone” oder “Landing Zone”) und weiteren Distillierungsschritten (zum Beispiel Aggregierungen oder ein Data Warehouse).

Sind die Daten erfasst, gilt es, sie zu verarbeiten. Diese Schicht ist üblicherweise das Processing Layer, also die Applikation von Transformationen, Konsolidierungen oder auch Analysen wie dem Training von Machine Learning Modellen. All dies geschieht quasi auf dem Data Lake, aber da die Ergebnisse wieder direkt in den Lake zurückgeführt werden, sind sie auch als Teil dessen zu sehen. Eine nahtlose Integration ist hier unumgänglich.

Schlussendlich gilt es, die Ergebnisse oder auch einfach nur die erfassten Daten auszuliefern. Diese Delivery Layer-Schicht (auch: Serve Layer oder Deployment Layer) stellt Daten, Machine Learning Modelle oder ähnliches anderen Applikationen, Systemen oder Kanälen zur Verfügung, um den generierten Mehrwert auch zu nutzen.

Beispiel für einen Data Lake auf AWS

Die Cloudkomponenten der Amazon Web Services (AWS) starten mit AWS Glue, dem ETL-Service von Amazon. Damit kann man den Data Ingestion Prozess, aber auch weitere Aspekte im Data Governance Umfeld abdecken.

Für Data Storage hat AWS eine Bandbreite an Lösungen. Zum Beispiel AWS Redshift für SQL, DynamoDB für NoSQL oder der Allrounder AWS S3 für unstrukturierte Daten. 

Um die Daten zu verarbeiten, nutzt Amazon ihre Services AWS EC2 bzw. AWS Lambda, um der Microservices-Idee zu folgen und mittels Komponenten wie Amazon SageMaker Machine Learning oder ähnliches durchzuführen.

Ausgeliefert, also das Deployment Layer, wird bei Amazon über Services wie beispielsweise Amazon Quicksight für Visualisierung oder AWS API Gateway zum Anbieten von APIs. Im Zentrum für Containerisierung stehen Amazon Elastic Container Service (ECS) und Amazon Elastic Kubernetes Services (EKS).

Beispiel für einen Data Lake auf Azure

Auf Microsoft Azure sind die Komponenten mit denen man sich einen generellen Data Lake zusammenstellen kann relativ gut integriert. Am Anfang steht meist die Azure Data Factory um den Data Ingest abzuwickeln. Data Factory kann mittels Konnektoren an viele Schnittstellen andocken und somit kontinuierlich die Daten “einspeisen”. 

Als Storage Komponenten hat Azure viele Möglichkeiten. Ob nun eine klassische Azure SQL Datenbank, Azure Blob Storage für unstrukturierte Daten oder Azure Cosmos für High Frequency Daten wie zum Beispiel Streaming.

Im Processing-Bereich steht dann Azure Analysis Service oder Azure Machine Learning zur Verfügung. Aber auch Azure Databricks, das sowohl Data Engineering als auch Modellierung auf Hadoop übernimmt, ist als Auswahl zur Verfügung.

Spricht man dann über das Deployment, greift man zum Beispiel zur Visualisierung auf das Microsoft-geprägte Power BI zu, in der Containerization auf Azure K8s oder Azure Redshift Service und zur Erstellung und dem Management von APIs auf Azure API Management.

Wie man sieht, bietet Azure eine umfangreiche Bibliothek an Services, um einen Data Lake vollumfänglich zu repräsentieren und in andere Prozesse einzubinden.

Beispiel für einen On-Premise Data Lake

Während bei Cloud-basierten Data Lakes die Komponenten relativ klar sind, sind bei On-Premise Realisierungen selbstverständlich keinerlei Grenzen gesetzt. Als einfaches Beispiel kann zur Data Ingestion ein ETL-Service wie Talend oder ein Streaming-Dienst wie Kafka stehen.

Dem folgt eine Bandbreite an Datenbanken wie Oracle oder Microsoft SQL DBs, MongoDB für NoSQL oder klassischerweise die Hadoop Cluster für unstrukturierte Daten für die Abdeckung der Storagekomponente.

Die Processing-Schicht ist nahezu unendlich skalierbar. Ob nun einfache python-Scripte die mittels einer Virtual Machine Workbench integriert werden, Data Mining Tools wie KNIME oder eine Spark Infrastruktur für größere Datenmengen – alles nur Beispiele in einer sehr großen Landschaft.

Die Daten und Analysen dann zur Verfügung gestellt werden können beispielsweise mittels Visualisierungssoftware wie Tableau, Docker Containerization oder – und das wird dann spannend – selbst implementierter REST APIs.

Wie man merkt, müssen in On-Premise Data Lake Architekturen einige Dinge aufgrund der unglaublichen Freiheit wesentlich umfangreicher geplant werden als im Cloudumfeld, bei dem es fast immer fixe Komponenten für die verschiedenen Schichten gibt. Dies resultiert einerseits in sehr großer Bandbreite und individueller Konfiguration des In-House Data Lakes, andererseits natürlich an sehr hohe Anforderungen an IT und DevOps.

Die Rolle des Data Lake in einer Data Driven Company

Wir hoffen, dass diese einfache Erklärung und Definition der Idee, des Konzepts, der Vorteile und Architektur von Data Lakes verständlich war. Die Frage die bleibt ist: Welche Rolle spielt ein Data Lake in einer Data Driven Company?

Simpel gesagt ist – egal ob man die Infrastruktur nun Data Lake oder Data Hub oder Datenplattform nennt – die Zusammenführung und Bereitstellung von Daten absolut zentral in einer Data Driven Company. Wenn das Ziel ist, dass alle Prozesse und Vorgänge durch Daten unterstützt werden, müssen die Daten auch vorhanden, erfasst und verfügbar sein. Dies funktioniert nur, wenn man die Storage-Komponente als auch die Data Governance vollumfänglich unter Kontrolle hat.

Zusammengefasst ist ein Data Lake – oder eine Abwandlung dessen – eines der wichtigsten Werkzeuge um eine Data Driven Company aufzubauen. Nicht nur im Analytics und Machine Learning, sondern in allen Prozessen muss man auf Daten zugreifen können. Da eine solche Konsolidierung und Zentralisierung ein Mammutprojekt ist, ist unsere Empfehlung lieber früh und iterativ einen Data Lake aufzusetzen, ihn zu pflegen und zu managen, statt über endlos-Planung alles operative aus den Augen zu lassen.

Weiterführende Information

Video zum Konzept eines Data Lakes

Ein einfach verständliches Video von IBM zum Thema Data Lakes:

AWS Data Lake Landing Page

https://aws.amazon.com/de/big-data/datalakes-and-analytics/what-is-a-data-lake/

Azure Data Lake Landing Page

https://azure.microsoft.com/en-us/solutions/data-lake/

Weitere Beiträge zum Thema Data Driven Company direkt per E-Mail bekommen: