Der Enterprise Big Data Lake

Kapitel 1. Einführung in Data Lakes

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: [e-mail]

Datengestützte Entscheidungsfindung verändert die Art und Weise, wie wir arbeiten und leben. Von Data Science, maschinellem Lernen und fortgeschrittener Analytik bis hin zu Echtzeit-Dashboards - Entscheidungsträger/innen verlangen nach Daten, um Entscheidungen zu treffen. Unternehmen wie Google, Amazon und Facebook sind datengesteuerte Moloche, die traditionelle Unternehmen durch die Nutzung von Daten übernehmen. Finanzdienstleister und Versicherungsunternehmen waren schon immer datengetrieben, wobei Quants und automatisierter Handel den Weg ebneten. Das Internet der Dinge (IoT) verändert die Produktion, den Transport, die Landwirtschaft und das Gesundheitswesen. Von Regierungen und Unternehmen in jeder Branche bis hin zu gemeinnützigen Organisationen und Bildungseinrichtungen werden Daten als Wegbereiter gesehen. Künstliche Intelligenz und maschinelles Lernen durchdringen alle Aspekte unseres Lebens. Die Welt stürzt sich auf Daten, weil sie so viel Potenzial bieten. Es gibt sogar einen Begriff für diese Datenflut: Big Data, den Doug Laney von Gartner mit den drei Vs (Volume, Variety und Velocity) definiert hat, zu denen er später ein viertes und meiner Meinung nach wichtigstes V hinzufügte : Veracity.

Bei so viel Vielfalt, Volumen und Geschwindigkeit sind die alten Systeme und Prozesse nicht mehr in der Lage, die Datenanforderungen des Unternehmens zu erfüllen. Die Wahrhaftigkeit ist ein noch größeres Problem bei fortgeschrittener Analytik und künstlicher Intelligenz, wo das Prinzip "GIGO" (garbage in = garbage out) noch kritischer ist, weil es praktisch unmöglich ist zu sagen, ob die Daten schlecht waren und zu schlechten Entscheidungen in statistischen und maschinellen Lernmodellen geführt haben oder ob das Modell schlecht war.

Um diese Bestrebungen zu unterstützen und diese Herausforderungen zu bewältigen, findet eine Revolution im Datenmanagement statt, bei der es darum geht, wie Daten gespeichert, verarbeitet, verwaltet und den Entscheidungsträgern zur Verfügung gestellt werden. Die Big-Data-Technologie ermöglicht eine Skalierbarkeit und Kosteneffizienz, die um Größenordnungen höher ist als bei der traditionellen Datenmanagement-Infrastruktur. Die Selbstbedienung löst die sorgfältig ausgearbeiteten und arbeitsintensiven Ansätze der Vergangenheit ab, bei denen Heerscharen von IT-Fachleuten gut verwaltete Data Warehouses und Data Marts erstellten, aber Monate brauchten, um Änderungen vorzunehmen.

Der Data Lake ist ein gewagter neuer Ansatz, der die Möglichkeiten der Big-Data-Technologie nutzt und sie mit der Agilität der Selbstbedienung verbindet. Die meisten großen Unternehmen haben heute entweder Data Lakes eingeführt oder sind dabei, sie einzuführen.

Dieses Buch basiert auf Gesprächen mit über hundert Organisationen, von den neuen datengetriebenen Unternehmen wie Google, LinkedIn und Facebook bis hin zu Regierungen und traditionellen Unternehmen, über ihre Data-Lake-Initiativen, Analyseprojekte, Erfahrungen und bewährten Methoden. Das Buch richtet sich an IT-Führungskräfte und Praktiker, die den Aufbau eines Data Lakes in Erwägung ziehen, gerade dabei sind, einen aufzubauen, oder bereits einen haben, aber Schwierigkeiten haben, ihn produktiv zu machen und auf breiter Basis einzusetzen.

Was ist ein Data Lake? Warum brauchen wir ihn? Wie unterscheidet er sich von dem, was wir bereits haben? Dieses Kapitel gibt einen kurzen Überblick, der in den folgenden Kapiteln noch weiter vertieft wird. Um die Zusammenfassung kurz und bündig zu halten, werde ich hier nicht jeden Begriff und jedes Konzept im Detail erklären und erläutern, sondern die ausführliche Diskussion für die folgenden Kapitel aufheben.

Datengestützte Entscheidungsfindung ist in aller Munde. Von Data Science, maschinellem Lernen und fortgeschrittener Analytik bis hin zu Echtzeit-Dashboards - Entscheidungsträger brauchen Daten, um Entscheidungen zu treffen. Diese Daten brauchen ein Zuhause, und der Data Lake ist die bevorzugte Lösung, um dieses Zuhause zu schaffen. Der Begriff wurde von James Dixon, CTO von Pentaho, erfunden und erstmals in seinem Blog beschrieben: "Wenn du dir einen Datamart als einen Vorrat an abgefülltem Wasser vorstellst - gereinigt, verpackt und strukturiert für den einfachen Konsum - dann ist der Data Lake ein großes Gewässer in einem natürlicheren Zustand. Der Inhalt des Datensees strömt aus einer Quelle und füllt den See, und verschiedene Nutzer des Sees können kommen, um ihn zu untersuchen, einzutauchen oder Proben zu nehmen." Ich habe die entscheidenden Punkte kursiv gedruckt, nämlich:

• Die Daten sind in ihrer ursprünglichen Form und ihrem ursprünglichen Format(natürliche oder Rohdaten).

• Die Daten werden von verschiedenen Nutzern verwendet (d.h. sie sind für eine große Nutzergemeinschaft zugänglich und zugänglich).

In diesem Buch geht es darum, wie man einen Data Lake aufbaut, der Rohdaten (und verarbeitete Daten) einer großen Nutzergemeinschaft von Unternehmensanalysten zur Verfügung stellt, anstatt sie nur für IT-gesteuerte Projekte zu verwenden. Der Grund für die Bereitstellung von Rohdaten für Analysten ist, dass sie Self-Service-Analysen durchführen können. Die Selbstbedienung ist ein wichtiger Megatrend zur Demokratisierung von Daten. Er begann am Ort der Nutzung mit Selbstbedienungs-Visualisierungstools wie Tableau und Qlik (manchmal auch Data Discovery Tools genannt), mit denen Analysten Daten analysieren können, ohne die Hilfe der IT-Abteilung in Anspruch nehmen zu müssen. Der Self-Service-Trend setzt sich mit Datenvorbereitungstools fort, die den Analysten helfen, die Daten für die Analyse aufzubereiten, sowie mit Katalogtools, die den Analysten helfen, die benötigten Daten zu finden, und mit Data-Science-Tools, die bei der Durchführung fortgeschrittener Analysen helfen. Für noch fortgeschrittenere Analysen, die allgemein als Data Science bezeichnet werden, nutzt eine neue Klasse von Nutzern, die Data Scientists, einen Data Lake als primäre Datenquelle.

Eine große Herausforderung bei der Selbstbedienung sind natürlich Governance und Datensicherheit. Alle sind sich einig, dass Daten sicher aufbewahrt werden müssen, aber in vielen regulierten Branchen gibt es vorgeschriebene Datensicherheitsrichtlinien, die umgesetzt werden müssen, und es ist illegal, Analysten Zugang zu allen Daten zu geben. Selbst in einigen nicht regulierten Branchen gilt das als schlechte Idee. Es stellt sich also die Frage, wie wir den Analysten Daten zur Verfügung stellen können, ohne gegen interne und externe Datenschutzbestimmungen zu verstoßen. Dies wird manchmal als Datendemokratisierung bezeichnet und in den folgenden Kapiteln ausführlich behandelt.

Data Lake Reifegrad

Da der Data Lake ein relativ neues Konzept ist, ist es sinnvoll, einige der zu beobachtenden Reifestufen zu definieren und die Unterschiede zwischen diesen Stufen klar zu formulieren:

• Ein Data Puddle ist im Grunde genommen ein Data Mart für einen einzigen Zweck oder ein einziges Projekt, das mit Big-Data-Technologie erstellt wurde. Er ist in der Regel der erste Schritt bei der Einführung von Big-Data-Technologien. Die Daten in einem Data Puddle werden für den Zweck eines einzelnen Projekts oder Teams geladen. Der Grund, warum die Big Data-Technologie anstelle des traditionellen Data Warehousing eingesetzt wird, ist, dass die Kosten gesenkt und die Leistung verbessert werden sollen.

• Ein Datenteich ist eine Ansammlung von Datenpfützen. Er kann wie ein schlecht konzipiertes Data Warehouse sein, das im Grunde eine Sammlung von verteilten Data Marts ist, oder er kann eine Auslagerung eines bestehenden Data Warehouses sein. Geringere Technologiekosten und bessere Skalierbarkeit sind zwar klare und attraktive Vorteile, aber diese Konstrukte erfordern immer noch ein hohes Maß an IT-Beteiligung. Außerdem beschränken sich Datenpools auf die Daten, die für das Projekt benötigt werden, und verwenden diese Daten nur für das Projekt, das sie benötigt. Angesichts der hohen IT-Kosten und der eingeschränkten Datenverfügbarkeit helfen Datenpools nicht wirklich dabei, die Datennutzung zu demokratisieren oder die Selbstbedienung und datengestützte Entscheidungsfindung für Geschäftsanwender zu fördern.

• Ein Data Lake unterscheidet sich in zwei wichtigen Punkten von einem Datenteich. Erstens unterstützt er die Selbstbedienung, d.h. die Fachanwender/innen können die Datensätze, die sie nutzen wollen, selbst finden und verwenden, ohne auf die Hilfe der IT-Abteilung angewiesen zu sein. Zweitens soll er Daten enthalten, die die Geschäftsnutzer/innen möglicherweise auch dann brauchen, wenn es kein Projekt gibt, das sie gerade benötigt.

• Ein Datenozean erweitert die Self-Service-Daten und die datengesteuerte Entscheidungsfindung auf alle Unternehmensdaten, wo auch immer sie sich befinden mögen, unabhängig davon, ob sie in den Data Lake geladen wurden oder nicht.

Abbildung 1-1 veranschaulicht die Unterschiede zwischen diesen Konzepten. Wenn der Reifegrad von einer Pfütze zu einem Teich, einem See oder einem Ozean wächst, nehmen auch die Datenmenge und die Zahl der Nutzer zu - manchmal sogar dramatisch. Das Nutzungsverhalten ändert sich von einer hohen IT-Beteiligung zu einer Selbstbedienung, und die Datenmenge geht über das hinaus, was für unmittelbare Projekte benötigt wird.

Abbildung 1-1. Die vier Stufen der Reife

Der Hauptunterschied zwischen einem Datenteich und einem Data Lake ist der Fokus. Datenteiche sind eine kostengünstige und skalierbare technologische Alternative zu bestehenden relationalen Data Warehouses und Data Marts. Während letztere darauf ausgerichtet sind, routinemäßige, produktionsreife Abfragen durchzuführen, ermöglichen es Data Lakes den Geschäftsanwendern, Daten für ihre eigenen Entscheidungen zu nutzen, indem sie Ad-hoc-Analysen durchführen und mit einer Vielzahl neuer Datentypen und Tools experimentieren, wie in Abbildung 1-2 dargestellt.

Bevor wir uns damit befassen, was es braucht, um einen erfolgreichen Data Lake zu schaffen, wollen wir uns die beiden Reifegrade, die dazu führen, genauer ansehen.

Abbildung 1-2. Nutzenversprechen des Data Lake

Datenpfützen

Datenpfützen werden in der Regel für ein kleines, spezialisiertes Team oder einen speziellen Anwendungsfall erstellt. Bei diesen "Pfützen" handelt es sich um mittelgroße Datensammlungen, die einem einzigen Team gehören und häufig von den Geschäftsbereichen mit Hilfe von Schatten-IT in der Cloud erstellt werden. Im Zeitalter des Data Warehousing war es üblich, dass jedes Team für jedes seiner Projekte einen relationalen Data Mart erstellte. Der Prozess der Erstellung eines Data Puddle ist sehr ähnlich, nur dass hier Big Data-Technologie zum Einsatz kommt. Normalerweise werden Data Puddle für Projekte erstellt, die die Leistungsfähigkeit und den Umfang von Big Data erfordern. Viele fortschrittliche Analyseprojekte, wie z. B. solche, die sich mit Kundenabwanderung oder vorausschauender Wartung befassen, fallen in diese Kategorie.

Manchmal werden Data Puddles gebaut, um die IT-Abteilung bei automatisierten rechen- und datenintensiven Prozessen zu unterstützen, wie z.B. beim Extrahieren, Transformieren, Laden (ETL), das in späteren Kapiteln ausführlich behandelt wird, wobei die gesamte Transformationsarbeit vom Data Warehouse oder teuren ETL-Tools auf eine Big Data-Plattform verlagert wird. Eine weitere häufige Anwendung von ist die Bereitstellung eines Arbeitsbereichs, einer sogenannten Sandbox, in der Data Scientists experimentieren können.

Datenpfützen haben in der Regel einen kleinen Umfang und eine begrenzte Vielfalt an Daten; sie werden von kleinen, dedizierten Datenströmen bevölkert, und ihre Erstellung und Pflege erfordert ein hochtechnisches Team oder eine starke Beteiligung der IT.

Daten Teiche

Ein Datenteich ist eine Sammlung von Datenpfützen. Genauso wie du dir Datenpfützen als Data Marts vorstellen kannst, die mit Big-Data-Technologie erstellt wurden, kannst du dir einen Datenteich als ein Data Warehouse vorstellen, das mit Big-Data-Technologie erstellt wurde. Er kann organisch entstehen, wenn weitere Puddles zur Big-Data-Plattform hinzugefügt werden. Ein anderer beliebter Ansatz zur Schaffung eines Data Ponds ist das Data Warehouse Offload. Anders als beim ETL-Offloading, bei dem Big Data-Technologie verwendet wird, um einen Teil der Verarbeitung durchzuführen, die für die Befüllung eines Data Warehouse erforderlich ist, geht es hier darum, alle Daten aus dem Data Warehouse in eine Big Data-Plattform zu laden. Die Vision ist oft, das Data Warehouse irgendwann abzuschaffen, um Kosten zu sparen und die Leistung zu verbessern, da Big-Data-Plattformen viel billiger und skalierbarer sind als relationale Datenbanken. Die Abschaffung des Data Warehouse allein gibt den Analysten jedoch keinen Zugang zu den Rohdaten. Da die strenge Architektur und die Governance des Data Warehouse beibehalten werden, kann das Unternehmen nicht alle Herausforderungen des Data Warehouse angehen, wie z. B. lange und teure Änderungszyklen, komplexe Transformationen und manuelle Kodierung als Grundlage für alle Berichte. Und schließlich gefällt es den Analysten oft nicht, von einem fein abgestimmten Data Warehouse mit blitzschnellen Abfragen auf eine viel weniger vorhersehbare Big-Data-Plattform umzusteigen, auf der große Batch-Abfragen vielleicht schneller laufen als in einem Data Warehouse, typische kleinere Abfragen aber Minuten dauern können. Abbildung 1-3 veranschaulicht einige der typischen Einschränkungen von Datenteichen: fehlende Vorhersagbarkeit, mangelnde Agilität und fehlender Zugriff auf die ursprünglichen unbehandelten Daten.

Abbildung 1-3. Die Nachteile des Data Warehouse Offloading

Einen erfolgreichen Data Lake schaffen

Was braucht es also, um einen erfolgreichen Data Lake zu haben? Wie bei jedem Projekt ist es unabdingbar, es an der Geschäftsstrategie des Unternehmens auszurichten und die Unterstützung der Geschäftsleitung sowie eine breite Zustimmung zu erhalten. Aus Gesprächen mit Dutzenden von Unternehmen, die Data Lakes mit unterschiedlichem Erfolg eingeführt haben, lassen sich drei wichtige Voraussetzungen ableiten:

• Die richtige Plattform

• Die richtigen Daten

• Die richtigen Schnittstellen

Die richtige Plattform

Big Data-Technologien wie Hadoop und Cloud-Lösungen wie Amazon Web Services (AWS), Microsoft Azure und Google Cloud Platform sind die beliebtesten Plattformen für einen Data Lake. Diese Technologien haben mehrere wichtige Vorteile:

Band

Diese Plattformen wurden so konzipiert, dass sie ohne nennenswerte Leistungseinbußen unbegrenzt skaliert werden können.

Kosten

Wir hatten schon immer die Möglichkeit, große Datenmengen auf relativ preiswerten Speichern wie Bändern, WORM-Disks und Festplatten zu speichern. Aber erst mit Big Data-Technologien konnten wir riesige Datenmengen so kostengünstig speichern und verarbeiten - in der Regel zu einem Zehntel bis Hundertstel der Kosten einer kommerziellen relationalen Datenbank.

Sorte

Diese Plattformen verwenden Dateisysteme oder Objektspeicher, die es ihnen ermöglichen, alle Arten von Dateien speichern: Hadoop HDFS, MapR FS, AWS's Simple Storage Service (S3), und so weiter. Im Gegensatz zu einer relationalen Datenbank, bei der die Datenstruktur vordefiniert sein muss(Schema on write), ist es einem Dateisystem oder einem Objektspeicher egal, was du schreibst. Um die Daten sinnvoll zu verarbeiten, musst du natürlich ihr Schema kennen, aber nur, wenn du die Daten verwendest. Dieser Ansatz wird " Schema on Read" genannt und ist einer der wichtigsten Vorteile von Big-Data-Plattformen, die eine "reibungslose Dateneingabe" ermöglichen. Anders als bei relationalen Datenbanken, bei denen die Daten erst dann geladen werden können, wenn sie in das von der Datenbank erwartete Schema und Format konvertiert worden sind, können die Daten ohne jegliche Bearbeitung geladen werden.

Zukunftssicher

Da sich unsere Anforderungen und die Welt, in der wir leben, ständig ändern, ist es wichtig, dass wir sicherstellen, dass die Daten, die wir haben, auch für unsere zukünftigen Bedürfnisse genutzt werden können. Wenn Daten heute in einer relationalen Datenbank gespeichert werden, kann nur diese Datenbank auf sie zugreifen. Hadoop und andere Big-Data-Plattformen sind dagegen sehr modular aufgebaut. Dieselbe Datei kann von verschiedenen Verarbeitungsmaschinen und Programmen genutzt werden - von Hive-Abfragen (Hive bietet eine SQL-Schnittstelle zu Hadoop-Dateien) über Pig-Skripte bis hin zu Spark und benutzerdefinierten MapReduce-Aufträgen können alle möglichen verschiedenen Tools und Systeme auf dieselben Dateien zugreifen und sie nutzen. Da sich die Big-Data-Technologie schnell weiterentwickelt, gibt dies den Menschen die Gewissheit, dass auch zukünftige Projekte auf die Daten im Data Lake zugreifen können.

Die richtigen Daten

Die meisten Daten, die Unternehmen heute sammeln, werden weggeworfen. Ein kleiner Prozentsatz wird zusammengefasst und für ein paar Jahre in einem Data Warehouse aufbewahrt, aber die meisten detaillierten Betriebsdaten, maschinell erzeugten Daten und alten historischen Daten werden entweder zusammengefasst oder ganz weggeworfen. Das macht es schwierig, Analysen durchzuführen. Wenn zum Beispiel ein Analyst den Wert einiger Daten erkennt, die bisher weggeworfen wurden, kann es Monate oder sogar Jahre dauern, bis er genug Daten gesammelt hat, um sinnvolle Analysen durchzuführen. Das Versprechen des Data Lake ist es daher, so viele Daten wie möglich für die zukünftige Nutzung zu speichern.

Der Data Lake ist also so etwas wie ein Sparschwein(Abbildung 1-4) - du weißt oft nicht, wofür du die Daten speicherst, aber du willst sie für den Fall, dass du sie eines Tages brauchst. Und weil du nicht weißt, wie du die Daten verwenden wirst, macht es keinen Sinn, sie vorzeitig umzuwandeln oder zu bearbeiten. Du kannst dir das so vorstellen, als würdest du mit deinem Sparschwein durch verschiedene Länder reisen, Geld in der Währung des Landes einzahlen, in dem du dich gerade aufhältst, und den Inhalt in der jeweiligen Landeswährung aufbewahren, bis du dich entscheidest, in welchem Land du das Geld ausgeben willst; dann kannst du alles in diese Währung umwandeln, anstatt dein Geld bei jedem Grenzübertritt unnötig umzuwandeln (und Umrechnungsgebühren zu zahlen). Zusammenfassend lässt sich sagen, dass das Ziel darin besteht, so viele Daten wie möglich in ihrem ursprünglichen Format zu speichern.

Abbildung 1-4. Ein Data Lake ist wie ein Sparschwein, das es dir ermöglicht, die Daten in ihrem ursprünglichen oder rohen Format zu behalten

Eine weitere Herausforderung bei der Beschaffung der richtigen Daten sind Datensilos. Verschiedene Abteilungen horten ihre Daten, weil es schwierig und teuer ist, sie bereitzustellen, und weil es oft eine politische und organisatorische Abneigung gibt, sie zu teilen. Wenn in einem typischen Unternehmen eine Gruppe Daten von einer anderen Gruppe benötigt, muss sie erklären, welche Daten sie braucht, und dann muss die Gruppe, der die Daten gehören, ETL-Aufträge implementieren, die die benötigten Daten extrahieren und verpacken. Das ist teuer, schwierig und zeitaufwändig, so dass die Teams Datenanfragen so weit wie möglich zurückbekommen und sich dann so viel Zeit lassen, wie sie brauchen, um die Daten bereitzustellen. Diese zusätzliche Arbeit wird oft als Ausrede benutzt, um Daten nicht zu teilen.

Mit einem Data Lake, der Rohdaten durch reibungsloses Einlesen (im Grunde werden sie ohne jegliche Verarbeitung eingelesen) nutzt, entfällt diese Herausforderung (und Ausrede). Ein gut verwalteter Data Lake ist außerdem zentralisiert und bietet den Mitarbeitern im gesamten Unternehmen einen transparenten Prozess, wie sie an die Daten gelangen können.

Die richtige Schnittstelle

Sobald wir die richtige Plattform gefunden und die Daten geladen haben, kommen wir zu den schwierigeren Aspekten des Data Lakes, bei denen die meisten Unternehmen fehlschlagen: die Wahl der richtigen Schnittstelle. Um eine breite Akzeptanz zu erreichen und die Vorteile zu nutzen, die sich daraus ergeben, dass Geschäftsanwender/innen datengestützte Entscheidungen treffen können, müssen die von den Unternehmen angebotenen Lösungen selbstbedienbar sein, damit die Anwender/innen die Daten finden, verstehen und nutzen können, ohne die Hilfe der IT-Abteilung in Anspruch zu nehmen. Die IT-Abteilung ist einfach nicht in der Lage, eine so große Nutzergemeinschaft und eine so große Vielfalt an Daten zu unterstützen.

Es gibt zwei Aspekte bei der Ermöglichung von Selbstbedienung: die Bereitstellung von Daten auf dem richtigen Kompetenzniveau für die Nutzer/innen und die Sicherstellung, dass die Nutzer/innen die richtigen Daten finden können.

Bereitstellung von Daten auf der richtigen Ebene des Fachwissens

Um eine breite Akzeptanz für den Data Lake zu erreichen, wollen wir, dass jeder, vom Datenwissenschaftler bis zum Business Analysten, ihn nutzt. Bei so unterschiedlichen Zielgruppen mit unterschiedlichen Bedürfnissen und Fähigkeiten müssen wir jedoch darauf achten, dass die richtigen Daten für die richtigen Nutzergruppen zur Verfügung stehen.

Zum Beispiel haben Analysten oft nicht die Fähigkeit, Rohdaten zu verwenden. Rohdaten sind in der Regel zu detailliert, zu feinkörnig und weisen häufig zu viele Qualitätsprobleme auf, um problemlos verwendet werden zu können. Wenn wir z. B. Verkaufsdaten aus verschiedenen Ländern sammeln, die unterschiedliche Anwendungen nutzen, liegen diese Daten in unterschiedlichen Formaten mit unterschiedlichen Feldern (z. B. kann ein Land eine Umsatzsteuer haben, ein anderes nicht) und unterschiedlichen Maßeinheiten (z. B. lb versus kg, $ versus €) vor.

Damit die Analysten diese Daten nutzen können, müssen sie harmonisiertwerden , d.h.in dasselbe Schema mit denselben Feldnamen und Maßeinheiten eingefügt werden, und häufig auch zu täglichen Umsätzen pro Produkt oder pro Kunde aggregiert werden. Mit anderen Worten: Die Analysten wollen "gekochte" Fertiggerichte, keine Rohdaten.

Datenwissenschaftler/innen hingegen sind das genaue Gegenteil. Für sie enthalten gekochte Daten oft nicht die goldenen Nuggets, nach denen sie suchen. Wenn sie zum Beispiel wissen wollen, wie oft zwei Produkte zusammen gekauft werden, aber die einzige Information, die sie bekommen können, sind die Tagessummen pro Produkt, sind Datenwissenschaftler/innen aufgeschmissen. Sie sind wie Köche, die Rohzutaten brauchen, um ihre kulinarischen oder analytischen Meisterwerke zu schaffen.

In diesem Buch werden wir sehen, wie man unterschiedliche Bedürfnisse befriedigen kann, indem man mehrere Zonen oder Bereiche einrichtet, die Daten enthalten, die bestimmte Anforderungen erfüllen. Die Rohdaten- oder Landing-Zone enthält zum Beispiel die ursprünglichen Daten, die in den Lake eingespeist werden, während die Produktions- oder Gold-Zone hochwertige, kontrollierte Daten enthält. Wir werfen einen kurzen Blick auf die Zonen im Abschnitt "Organisieren des Data Lake"; eine ausführlichere Diskussion findet sich in Kapitel 7.

Zu den Daten gelangen

Die meisten Unternehmen, mit denen ich gesprochen habe, setzen auf das Paradigma des "Daten-Shoppings", bei dem Analysten eine Schnittstelle im Stil von Amazon.com nutzen, um Daten zu finden, zu verstehen, zu bewerten, mit Anmerkungen zu versehen und zu konsumieren. Die Vorteile dieses Ansatzes sind vielfältig, unter anderem:

Eine vertraute Schnittstelle

Die meisten Menschen sind mit dem Online-Shopping vertraut und fühlen sich wohl bei der Suche nach Schlüsselwörtern und der Nutzung von Facetten, Bewertungen und Kommentaren, sodass sie keine oder nur eine minimale Schulung benötigen.

Facettierte Suche

Suchmaschinen sind für die Facettensuche optimiert. Die facettierte Suche ist sehr hilfreich, wenn die Zahl der möglichen Suchergebnisse groß ist und der Nutzer versucht, das richtige Ergebnis zu finden. Wenn du zum Beispiel bei Amazon nach Toastern suchst(Abbildung 1-5), werden in den Facetten die Hersteller aufgelistet, ob der Toaster Bagels verarbeiten kann, wie viele Scheiben getoastet werden müssen und so weiter. Auch bei der Suche nach den richtigen Datensätzen können Facetten dabei helfen, die gewünschten Attribute des Datensatzes, die Art und das Format des Datensatzes, das System, in dem er gespeichert ist, die Größe und die Aktualität des Datensatzes, die Abteilung, der er gehört, die Berechtigungen, die er hat, und viele andere nützliche Eigenschaften anzugeben.

Rangliste und Sortierung

Die Möglichkeit, Datenbestände darzustellen und zu sortieren, die von Suchmaschinen weitgehend unterstützt wird, ist wichtig, um den richtigen Bestand nach bestimmten Kriterien auszuwählen.

Kontextbezogene Suche

Je intelligenter Kataloge werden, desto wichtiger wird die Fähigkeit, Datenbestände mit Hilfe eines semantischen Verständnisses dessen zu finden, was Analysten suchen . Ein Vertriebsmitarbeiter, der nach Kunden sucht, ist vielleicht wirklich auf der Suche nach potenziellen Kunden, während ein Mitarbeiter des technischen Supports, der nach Kunden sucht, vielleicht wirklich nach bestehenden Kunden sucht.

Abbildung 1-5. Eine Schnittstelle zum Online-Shopping

Der Daten-Sumpf

Während Data Lakes immer mit guten Absichten beginnen, nehmen sie manchmal eine falsche Wendung und enden als Datensümpfe. Ein Datensumpf ist ein Datenteich, der auf die Größe eines Data Lakes angewachsen ist, aber einer breiten Analystengemeinschaft fehlgeschlagen ist, was in der Regel an mangelnden Selbstbedienungs- und Governance-Einrichtungen liegt. Im besten Fall wird der Datensumpf wie ein Datenteich genutzt, im schlimmsten Fall wird er überhaupt nicht genutzt. Oft nutzen verschiedene Teams zwar kleine Bereiche des Sees für ihre Projekte (der weiße Bereich des Datenteichs in Abbildung 1-6), aber der Großteil der Daten ist dunkel, undokumentiert und unbrauchbar.

Abbildung 1-6. Ein Daten-Sumpf

Als Data Lakes aufkamen, kauften viele Unternehmen überstürzt Hadoop-Cluster und füllten sie mit Rohdaten, ohne eine klare Vorstellung davon zu haben, wie diese genutzt werden sollten. Das führte zu riesigen Datensümpfen mit Millionen von Dateien, die Petabytes an Daten enthielten, ohne dass es eine Möglichkeit gab, diese Daten sinnvoll zu nutzen.

Nur die anspruchsvollsten Nutzer konnten sich in den Sümpfen bewegen, indem sie kleine Pfützen aushöhlten, die sie und ihre Teams nutzen konnten. Außerdem verhinderten Governance-Vorschriften, dass die Sümpfe für ein breites Publikum geöffnet werden konnten, ohne dass sensible Daten geschützt wurden. Da niemand wusste, wo sich die sensiblen Daten befanden, konnte den Nutzern kein Zugang gewährt werden und die Daten blieben weitgehend unbrauchbar und ungenutzt. Ein Datenwissenschaftler erzählte mir von seiner Erfahrung, wie sein Unternehmen einen Data Lake aufbaute, alle Daten in diesem See verschlüsselte, um sie zu schützen, und von den Datenwissenschaftlern verlangte, dass sie nachweisen, dass die gewünschten Daten nicht sensibel waren, bevor sie die Verschlüsselung aufheben und die Daten nutzen konnten. Das erwies sich als eine Zwickmühle: Da alles verschlüsselt war, konnte der Datenwissenschaftler, mit dem ich sprach, nichts finden, geschweige denn beweisen, dass es nicht sensibel war. Das Ergebnis war, dass niemand den Datensee (oder, wie er ihn nannte, den Sumpf) nutzte.

Roadmap zum erfolgreichen Data Lake

Da wir nun wissen, was für den Erfolg eines Data Lakes notwendig ist und welche Fallstricke es zu beachten gilt, stellt sich die Frage, wie wir einen Data Lake aufbauen? Normalerweise folgen Unternehmen diesem Prozess:

1. Richte die Infrastruktur ein (bringe den Hadoop-Cluster zum Laufen).

2. Organisiere den Data Lake (erstelle Zonen für die Nutzung durch verschiedene Nutzergruppen und nimm die Daten auf).

3. Richte den Data Lake für die Selbstbedienung ein (erstelle einen Katalog von Datenbeständen, richte Berechtigungen ein und stelle den Analysten Tools zur Verfügung).

4. Öffne den Datensee für die Nutzer.

Einrichten eines Data Lake

Als ich 2015 anfing, dieses Buch zu schreiben, bauten die meisten Unternehmen Data Lakes vor Ort auf, entweder mit Open Source oder kommerziellen Hadoop-Distributionen. Im Jahr 2018 baute mindestens die Hälfte der Unternehmen ihre Data Lakes entweder vollständig in der Cloud auf oder sie bauten hybride Data Lakes, die sowohl vor Ort als auch in der Cloud betrieben werden. Viele Unternehmen haben auch mehrere Data Lakes. Diese Vielfalt führt dazu, dass die Unternehmen neu definieren, was ein Data Lake ist. Wir sehen jetzt das Konzept eines logischen Data Lakes: eine virtuelle Data-Lake-Ebene über mehrere heterogene Systeme. Die zugrundeliegenden Systeme können Hadoop, relationale oder NoSQL-Datenbanken sein, vor Ort oder in der Cloud.

Abbildung 1-7 vergleicht die drei Ansätze. Alle drei Ansätze bieten einen Katalog, in dem die Nutzer die benötigten Datenbestände finden. Diese Datenbestände befinden sich entweder bereits im Hadoop Data Lake oder werden ihm zur Verfügung gestellt, damit die Analysten sie nutzen können.

Abbildung 1-7. Verschiedene Data-Lake-Architekturen

Organisieren des Data Lake

Die meisten Data Lakes, denen ich begegnet bin, sind in etwa gleich organisiert, nämlich in verschiedene Zonen:

• Eine Roh- oder Landezone, in der die Daten von aufgenommen werden und so nah wie möglich an ihrem ursprünglichen Zustand bleiben.

• Eine Gold- oder Produktionszone, in der saubere, verarbeitete Daten aufbewahrt werden.

• Eine Entwicklungs- oder Arbeitszone, in der die technischeren Nutzer wie Data Scientists und Data Engineers ihre Arbeit erledigen. Diese Zone kann nach Nutzern, Projekten, Themen oder auf verschiedene andere Arten organisiert werden. Sobald die in der Arbeitszone geleistete Analysearbeit produktiv wird, wird sie in die Goldzone verschoben.

• Eine sensible Zone, die sensible Daten enthält.

Abbildung 1-8 veranschaulicht diese Organisation.

Abbildung 1-8. Zonen eines typischen Data Lake

Viele Jahre lang war die vorherrschende Weisheit für Data-Governance-Teams, dass Daten unabhängig von ihrem Speicherort oder Zweck der gleichen Governance unterliegen sollten. In den letzten Jahren haben die Branchenanalysten von Gartner jedoch das Konzept der multimodalen ITgefördert , d.h.die Idee, dass die Governance die Datennutzung und die Anforderungen der Nutzergemeinschaft widerspiegeln sollte. Dieser Ansatz wurde von den Data-Lake-Teams weitgehend übernommen, wobei für die verschiedenen Zonen unterschiedliche Governance-Ebenen und Service-Level-Agreements (SLAs) gelten. Die Daten in der Gold-Zone beispielsweise werden in der Regel stark kontrolliert, sind gut kuratiert und dokumentiert und unterliegen Qualitäts- und Aktualitäts-SLAs, während die Daten im Arbeitsbereich nur eine minimale Kontrolle haben (hauptsächlich um sicherzustellen, dass es keine sensiblen Daten gibt) und SLAs, die von Projekt zu Projekt variieren können.

Unterschiedliche Nutzergruppen ziehen sich natürlich in unterschiedliche Zonen zurück. Business-Analysten nutzen Daten hauptsächlich in der Gold-Zone, Data Engineers arbeiten mit Daten in der Raw-Zone (und wandeln sie in Produktionsdaten um, die für die Gold-Zone bestimmt sind), und Data Scientists führen ihre Experimente in der Work-Zone durch. Während für jede Zone eine gewisse Governance erforderlich ist, um sicherzustellen, dass sensible Daten erkannt und gesichert werden, konzentrieren sich die Data Stewards vor allem auf die Daten in der sensiblen und der Gold-Zone, um sicherzustellen, dass sie mit den Unternehmens- und Regierungsvorschriften übereinstimmen. Abbildung 1-9 veranschaulicht die verschiedenen Ebenen der Governance und die unterschiedlichen Nutzergemeinschaften für die verschiedenen Zonen.

Abbildung 1-9. Erwartungen an die Governance, Zone für Zone

Einrichten des Data Lake für Self-Service

Analysten, seien es Business Analysten, Datenanalysten oder Data Scientists, durchlaufen in der Regel vier Schritte, um ihre Arbeit zu erledigen. Diese Schritte sind in Abbildung 1-10 dargestellt.

Abbildung 1-10. Die vier Phasen der Analyse

Der erste Schritt besteht darin, die Daten zu finden und zu verstehen. Sobald sie die richtigen Datensätze gefunden haben, müssen sie die Daten bereitstellen, d.h. Zugang zu ihnen erhalten. Sobald sie die Daten haben, müssen sie sie oft vorbereiten, d.h. sie bereinigen und in ein für die Analyse geeignetes Format umwandeln. Schließlich müssen sie die Daten nutzen, um Fragen zu beantworten oder Visualisierungen und Berichte zu erstellen.

Die ersten drei Schritte sind theoretisch optional: Wenn die Daten dem Analysten gut bekannt sind und er sie versteht, wenn er bereits Zugang zu ihnen hat und wenn sie bereits in der richtigen Form für die Analyse sind, kann der Analyst nur den letzten Schritt machen. In der Realität haben viele Studien gezeigt, dass die ersten drei Schritte bis zu 80 % der Zeit eines typischen Analysten in Anspruch nehmen, wobei der größte Aufwand (60 %) auf den ersten Schritt des Findens und Verstehens der Daten entfällt (siehe z. B. "Boost Your Business Insights by Converging Big Data and BI" von Boris Evelson, Forrester Research, 25. März 2015).

Damit du dir ein besseres Bild davon machen kannst, was in jeder der vier Phasen passiert, wollen wir sie aufschlüsseln.

Die Daten finden und verstehen

Warum ist es so schwierig, Daten im Unternehmen zu finden? Weil die Vielfalt und Komplexität der verfügbaren Daten die menschliche Fähigkeit, sich an sie zu erinnern, bei weitem übersteigt. Stell dir eine sehr kleine Datenbank mit nur hundert Tabellen vor (manche Datenbanken haben Tausende oder sogar Zehntausende von Tabellen, das ist also wirklich eine sehr kleine reale Datenbank). Nun stell dir vor, dass jede Tabelle hundert Felder hat - eine vernünftige Annahme für die meisten Datenbanken, vor allem für analytische Datenbanken, in denen die Daten oft denormalisiert sind. Dann haben wir 10.000 Felder. Wie realistisch ist es, dass sich jemand daran erinnert, was 10.000 Felder bedeuten und in welchen Tabellen sich diese Felder befinden, und dass er sie dann im Auge behält, wenn er die Daten für etwas Neues verwendet?

Stell dir nun ein Unternehmen vor, das mehrere tausend (oder mehrere hunderttausend) Datenbanken hat, die meisten eine Größenordnung größer als unsere hypothetische Datenbank mit 10.000 Feldern. Ich habe einmal mit einer kleinen Bank gearbeitet, die nur 5.000 Mitarbeiter hatte, aber 13.000 Datenbanken erstellen konnte. Ich kann mir nur vorstellen, wie viele eine große Bank mit Hunderttausenden von Mitarbeitern haben könnte. Ich sage "nur vorstellen", weil keines der Hunderte von großen Unternehmen, mit denen ich in meiner 30-jährigen Laufbahn gearbeitet habe, mir sagen konnte, wie viele Datenbanken sie hatten - geschweige denn, wie viele Tabellen oder Felder.

Wir hoffen, dass du eine Vorstellung davon bekommst, vor welchen Herausforderungen Analysten bei der Suche nach Daten stehen.

Ein typisches Projekt besteht darin, dass Analysten "herumfragen", um herauszufinden, ob jemand schon einmal eine bestimmte Art von Daten verwendet hat. Sie werden von Person zu Person verwiesen, bis sie über einen Datensatz stolpern, den jemand in einem ihrer Projekte verwendet hat. In der Regel haben sie keine Ahnung, ob es sich dabei um den besten Datensatz handelt, wie er erstellt wurde oder ob die Daten überhaupt vertrauenswürdig sind. Sie stehen dann vor der schrecklichen Wahl, diesen Datensatz zu verwenden oder sich weiter umzuhören und vielleicht nichts Besseres zu finden.

Sobald sie sich für einen Datensatz entschieden haben, verbringen sie viel Zeit damit, die Bedeutung der darin enthaltenen Daten zu entschlüsseln. Manche Daten sind ziemlich eindeutig (z. B. Kundennamen oder Kontonummern), andere hingegen sind kryptisch (z. B. was bedeutet ein Kundencode von 1126?). Also verbringen die Analysten noch mehr Zeit damit, nach Leuten zu suchen, die ihnen helfen können, die Daten zu verstehen. Wir nennen diese Informationen "Stammeswissen". Mit anderen Worten: Das Wissen ist in der Regel vorhanden, aber es ist über den ganzen Stamm verstreut und muss in einem mühsamen, langwierigen und fehleranfälligen Findungsprozess wieder zusammengesetzt werden.

Glücklicherweise gibt es neue Analysten-Crowdsourcing-Tools, die dieses Problem angehen, indem sie Stammeswissen durch einen Prozess sammeln, der es Analysten ermöglicht, Datensätze mit einfachen Beschreibungen aus Geschäftsbegriffen zu dokumentieren und einen Suchindex zu erstellen, der ihnen hilft, das zu finden, wonach sie suchen. Tools wie diese wurden von modernen datengetriebenen Unternehmen wie Google und LinkedIn entwickelt. Weil Daten in diesen Unternehmen so wichtig sind und "jeder ein Analyst ist", ist das Problembewusstsein und die Bereitschaft, zur Lösung beizutragen, viel höher als in traditionellen Unternehmen. Es ist auch viel einfacher, Datensätze zu dokumentieren, wenn sie zum ersten Mal erstellt werden, weil die Informationen noch frisch sind. Doch selbst bei Google sind zwar einige beliebte Datensätze gut dokumentiert, aber es gibt immer noch eine große Menge an dunklen oder undokumentierten Daten.

In traditionellen Unternehmen ist die Situation noch viel schlimmer. Es gibt Millionen bestehender Datensätze (Dateien und Tabellen), die nie von Analysten dokumentiert werden, wenn sie nicht genutzt werden - aber sie werden auch nie gefunden und genutzt, wenn sie nicht dokumentiert werden. Die einzige praktische Lösung besteht darin, Crowdsourcing mit Automatisierung zu kombinieren. Waterline Data ist ein Tool, das mein Team und ich entwickelt haben, um eine solche Lösung zu bieten. Es nimmt die Informationen von Analysten, die mit ihren Datensätzen arbeiten, und wendet sie auf alle anderen dunklen Datensätze an. Der Prozess nennt sich Fingerprinting: Das Tool durchforstet alle strukturierten Daten im Unternehmen und fügt jedem Feld eine eindeutige Kennung hinzu. Wenn Felder von Analysten mit Anmerkungen oder Tags versehen werden, sucht es nach ähnlichen Feldern und schlägt ihnen Tags vor. Wenn Analysten nach Datensätzen suchen, sehen sie sowohl Datensätze, die von Analysten getaggt wurden, als auch Datensätze, die vom Tool automatisch getaggt wurden, und haben die Möglichkeit, die vorgeschlagenen Tags entweder zu akzeptieren oder abzulehnen. Das Tool wendet dann maschinelles Lernen (ML) an, um die automatische Markierung auf der Grundlage des Nutzerfeedbacks zu verbessern.

Der Kerngedanke ist, dass die menschliche Kommentierung allein angesichts des Umfangs und der Komplexität der Daten nicht ausreicht, während eine rein automatisierte Kommentierung angesichts der einzigartigen und unvorhersehbaren Eigenschaften der Daten unzuverlässig ist - daher müssen beide zusammengebracht werden, um die besten Ergebnisse zu erzielen. Abbildung 1-11 veranschaulicht diesen positiven Kreislauf.

Abbildung 1-11. Nutzung von menschlichem Wissen und maschinellem Lernen

Zugriff auf und Bereitstellung von Daten

Sobald die richtigen Datensätze identifiziert sind, müssen die Analysten in der Lage sein, sie zu nutzen. Traditionell wird den Analysten der Zugang gewährt, wenn sie ein Projekt beginnen oder ihm beitreten. So haben alte Hasen Zugang zu praktisch allen Daten im Unternehmen, die auch nur im Entferntesten nützlich sein könnten, während Neulinge praktisch keinen Zugang haben und daher nichts finden oder nutzen können. Um das Problem des Datenzugriffs für den Data Lake zu lösen, entscheiden sich Unternehmen in der Regel für eines der beiden Extreme: Entweder sie gewähren allen Mitarbeitern vollen Zugriff auf alle Daten oder sie schränken den Zugriff ein, es sei denn, ein Analyst kann einen Bedarf nachweisen. Die Gewährung des vollen Zugriffs funktioniert in einigen Fällen, aber nicht in regulierten Branchen. Um es akzeptabler zu machen, de-identifizieren Unternehmen manchmal sensible Daten - aber das bedeutet, dass sie Daten einlesen müssen, die niemand braucht. Und wenn sich die Vorschriften ändern, müssen möglicherweise immer mehr Daten de-identifiziert werden (dieses Thema wird in späteren Kapiteln ausführlich behandelt).

Ein praktischerer Ansatz ist es, Informationen über alle Datensätze in einem Metadatenkatalog zu veröffentlichen, damit Analysten nützliche Datensätze finden und dann bei Bedarf Zugang beantragen können. Die Anfragen enthalten in der Regel eine Begründung für den Zugriff, das Projekt, für das die Daten benötigt werden, und die Dauer des Zugriffs. Diese Anfragen werden an die Datenverantwortlichen für die angeforderten Daten weitergeleitet. Wenn sie den Zugriff genehmigen, wird er für einen bestimmten Zeitraum gewährt. Dieser Zeitraum kann verlängert werden, ist aber nicht unbegrenzt, so dass das Problem des Legacy-Zugriffs beseitigt ist. Eine eingehende Anfrage kann auch die De-Identifizierung sensibler Daten auslösen, aber das geschieht jetzt nur noch bei Bedarf.

Die Bereitstellung oder der physische Zugriff auf die Daten kann auf verschiedene Weise erfolgen:

• Den Nutzern kann Lesezugriff auf den gesamten Datensatz gewährt werden.

• Wenn nur teilweiser Zugriff gewährt werden soll, kann eine Kopie der Datei erstellt (und auf dem neuesten Stand gehalten) werden, die nur die für den Benutzer relevanten Daten enthält, oder es kann eine Hive-Tabelle oder -Ansicht erstellt werden, die nur die Felder und Zeilen enthält, die der Analyst sehen soll.

• Bei Bedarf kann eine anonymisierte Version des Datensatzes erstellt werden, bei der sensible Informationen durch zufällig generierte gleichwertige Informationen ersetzt werden, sodass alle Anwendungen weiterhin funktionieren, aber keine sensiblen Daten nach außen dringen.

Aufbereitung der Daten

Gelegentlich kommen Daten vollkommen sauber und analysereif an. In den meisten Fällen müssen die Daten jedoch bearbeitet werden, damit sie für die Analysten geeignet sind. Die Datenaufbereitung umfasst in der Regel die folgenden Arbeitsschritte:

Gestalten

Auswählen einer Teilmenge von Feldern und Zeilen, die bearbeitet werden sollen, Kombinieren mehrerer Dateien und Tabellen zu einer einzigen (Zusammenführen), Umwandeln von und Aggregieren, Gruppieren (z. B. von diskreten Werten in Bereiche oder Gruppen - z. B. 0- bis 18-Jährige in die Gruppe "Jugendliche", 19- bis 25-Jährige in die Gruppe "junge Erwachsene" usw.), Umwandeln von Variablen in Merkmale (z. B. Umwandeln des Alters in ein Merkmal, das den Wert 0 hat, wenn eine Person über 65 Jahre alt ist, und 1, wenn dies nicht der Fall ist) und viele andere mögliche Schritte.

Reinigung

Ergänzen von fehlenden Werten (z. B. Erraten eines fehlenden Geschlechts anhand des Vornamens oder Nachschlagen der Adresse in einer Adressdatenbank), Korrigieren von falschen Werten, Auflösen von widersprüchlichen Daten, Normalisieren von Maßeinheiten und Codes auf gängige Einheiten und Ähnliches.

Blending

Harmonisierung verschiedener Datensätze mit demselben Schema, denselben Maßeinheiten, denselben Codes usw.

Wie du an diesen wenigen Beispielen sehen kannst, steckt in der Datenaufbereitung eine Menge ausgeklügelte Arbeit und Denkarbeit. Die Automatisierung ist entscheidend, um von den Erkenntnissen aus den Transformationen zu profitieren und zu vermeiden, dass dieselben mühsamen Schritte für Tausende von Tabellen und Datensätzen wiederholt werden.

Das gängigste Tool zur Datenaufbereitung ist Excel. Leider lässt sich Excel nicht auf die Größe des Data Lakes skalieren, aber eine Vielzahl neuer Tools bietet Excel-ähnliche Funktionen für große Datensätze. Einige, wie Trifacta, wenden ausgefeilte maschinelle Lernverfahren an, um Umwandlungen vorzuschlagen und Analysten bei der Datenvorbereitung zu unterstützen. Viele große Anbieter haben ebenfalls Tools für die Datenvorbereitung auf den Markt gebracht, und Anbieter von Analyseprogrammen wie Tableau und Qlik verbessern die Datenvorbereitungsfunktionen ihrer Tools ebenfalls.

Analyse und Visualisierung

Sobald die Daten aufbereitet sind, können sie analysiert werden. Die Analyse reicht von der Erstellung einfacher Berichte und Visualisierungen bis hin zu anspruchsvollen erweiterten Analysen und maschinellem Lernen. Dieser Bereich ist sehr ausgereift und es gibt Hunderte von Anbietern, die Lösungen für alle Arten von Analysen anbieten. Speziell für Hadoop Data Lakes bieten Arcadia Data, AtScale und andere Analyse- und Visualisierungstools an, die nativ laufen und die Rechenleistung von Hadoop nutzen.

Data Lake Architekturen

Ursprünglich dachten die meisten Unternehmen, mit denen ich gesprochen habe, dass sie einen riesigen, lokalen Data Lake haben würden, der alle ihre Daten enthält. Als sich ihr Verständnis und ihre bewährten Methoden weiterentwickelten, erkannten die meisten Unternehmen, dass ein einziger Anlaufpunkt nicht ideal ist. Aufgrund von Vorschriften zur Datenhoheit (z. B. dürfen Daten nicht aus Deutschland herausgenommen werden) und organisatorischen Zwängen erwiesen sich mehrere Data Lakes als die bessere Lösung. Als die Unternehmen die Komplexität der Unterstützung eines massiv parallelen Clusters erkannten und frustriert feststellten, dass sie keine erfahrenen Administratoren für Hadoop und andere Big-Data-Plattformen finden und einstellen konnten, entschieden sie sich für Cloud-basierte Data Lakes, bei denen die meisten Hardware- und Plattformkomponenten von den Experten verwaltet werden, die für Amazon, Microsoft, Google und andere arbeiten.

Data Lakes in der Public Cloud

Abgesehen von den Vorteilen des Zugangs zu Big-Data-Technologien und den kurzen Bereitstellungszeiten machen die niedrigen Kosten für die Speicherung und die Elastizität des Cloud Computing zu einer äußerst attraktiven Option für die Implementierung eines Data Lake. Da viele Daten für die zukünftige Nutzung gespeichert werden, ist es sinnvoll, sie so kostengünstig wie möglich zu speichern. Das passt gut zu den Möglichkeiten der Kostenoptimierung, die durch die verschiedenen Speicherebenen von Amazon und anderen Anbietern unterstützt werden: Der Zugriff reicht von Hochgeschwindigkeit bis zu eisiger Geschwindigkeit, wobei Medien mit langsamerem Zugriff deutlich günstiger sind.

Außerdem ermöglicht die Elastizität des Cloud Computing, dass ein sehr großer Cluster bei Bedarf hochgefahren werden kann. Zum Vergleich: Ein lokaler Cluster hat eine feste Größe und speichert seine Daten in einer angeschlossenen Speicherung (obwohl neue Architekturen mit netzwerkgebundener Speicherung erforscht werden). Das bedeutet, dass neue Knoten allein für die Speicherung hinzugefügt werden müssen, wenn sich die Knoten mit Daten füllen. Und wenn die Analysen sehr rechenintensiv sind und mehr Rechenleistung benötigen, musst du weitere Knoten hinzufügen, auch wenn du sie nur für kurze Zeit nutzt.

In der Cloud zahlst du nur für die Speicherung, die du brauchst (d.h. du musst keine zusätzlichen Rechenknoten kaufen, nur um mehr Speicherplatz zu bekommen) und kannst für kurze Zeiträume riesige Cluster aufsetzen. Wenn du zum Beispiel einen Cluster mit 100 Knoten vor Ort hast und ein Auftrag 50 Stunden dauert, ist es nicht sinnvoll, 1.000 Knoten zu kaufen und zu installieren, nur um diesen einen Auftrag schneller auszuführen. In der Cloud hingegen würdest du für die Rechenleistung von 100 Knoten für 50 Stunden ungefähr genauso viel bezahlen wie für 1.000 Knoten für 5 Stunden. Das ist der große Vorteil von Elastic Compute.

Logische Datenseen

Als Unternehmen erkannten, dass ein zentraler Data Lake keine gute Lösung ist, setzte sich die Idee des logischen Data Lake durch. Bei diesem Ansatz werden nicht alle Daten in den Data Lake geladen, nur für den Fall, dass jemand sie irgendwann braucht, sondern sie werden den Analysten über einen zentralen Katalog oder über Datenvirtualisierungssoftware zur Verfügung gestellt.

Logische Datenseen befassen sich mit den Problemen der Vollständigkeit und Redundanz, wie in Abbildung 1-12 dargestellt.

Abbildung 1-12. Fragen der Vollständigkeit und Redundanz

Diese Themen lassen sich wie folgt zusammenfassen:

Vollständigkeit

Wie finden die Analysten den besten Datensatz? Wenn die Analysten nur Daten finden können, die sich bereits im Data Lake befinden, werden andere Daten, die noch nicht in den Data Lake aufgenommen wurden, nicht gefunden oder verwendet (der halbmondförmige Bereich rechts in Abbildung 1-12).

Redundanz

Wenn wir alle Daten in den Data Lake einspeisen, gibt es Redundanz zwischen den Datenquellen und dem Data Lake (dargestellt durch den Überschneidungsbereich zwischen den beiden Kreisen in Abbildung 1-12). Bei mehreren Data Lakes müssten wir, um Vollständigkeit zu erreichen, dieselben Daten in jeden Data Lake einspeisen.

Erschwerend kommt hinzu, dass es im Unternehmen bereits eine Menge Redundanz gibt. Wenn ein neues Projekt gestartet wird, besteht die zweckmäßigste und politisch einfachste Vorgehensweise für das Projektteam traditionell darin, einen neuen Data Mart zu erstellen, Daten aus anderen Quellen oder dem Data Warehouse zu kopieren und eigene Daten hinzuzufügen. Das ist viel einfacher, als bestehende Data Marts zu untersuchen und mit den derzeitigen Eigentümern und Nutzern über die gemeinsame Nutzung zu verhandeln. Infolgedessen gibt es einen Wildwuchs an Data Marts, die größtenteils gleich sind. Wenn wir alle Daten aus diesen Data Marts blindlings in den Data Lake laden, haben wir ein extrem hohes Maß an Redundanz in unserem See.

Die beste Herangehensweise an die Herausforderungen der Vollständigkeit und Redundanz, die ich gesehen habe, beinhaltet ein paar einfache Regeln:

• Um das Problem der Vollständigkeit zu lösen, solltest du einen Katalog aller Datenbestände erstellen, damit die Analysten jeden Datensatz, der im Unternehmen verfügbar ist, finden und anfordern können.

• Um das Redundanzproblem zu lösen, befolge den in Abbildung 1-13 dargestellten Prozess:

  • Speichere Daten, die nirgendwo anders im Data Lake gespeichert sind.

  • Bringe Daten, die in anderen Systemen gespeichert sind, in den Data Lake, wenn sie gebraucht werden, und halte sie synchron, solange sie gebraucht werden.

  • Bringe jeden Datensatz nur einmal für alle Nutzer ein.

Abbildung 1-13. Verwaltung von Daten im logischen Datensee

Virtualisierung gegenüber einem katalogbasierten logischen Datensee

Virtualisierung (manchmal auch Föderation oder EII genannt, für Enterprise Information Integration) ist eine Technologie, die in den 1980er Jahren entwickelt und über mehrere Generationen bis in die 2010er Jahre verbessert wurde. Dabei wird eine virtuelle Ansicht oder Tabelle erstellt, die den Standort und die Implementierung der physischen Tabellen verbirgt. In Abbildung 1-14 wird eine Ansicht erstellt, indem zwei Tabellen aus verschiedenen Datenbanken verbunden werden. Die Abfrage würde dann diese Ansicht abfragen und es dem Datenvirtualisierungssystem überlassen, herauszufinden, wie es auf die Daten in den beiden Datenbanken zugreifen und sie verbinden kann.

Abbildung 1-14. Erstellen eines benutzerdefinierten Datensatzes über eine Ansicht

Obwohl diese Technologie für einige Anwendungsfälle gut funktioniert, müsste in einem logischen Data Lake jeder Datensatz als virtuelle Tabelle veröffentlicht und auf dem neuesten Stand gehalten werden, wenn sich die zugrundeliegenden Tabellenschemata ändern, um Vollständigkeit zu erreichen.

Selbst wenn das anfängliche Problem der Veröffentlichung aller Datenbestände gelöst wäre, stellen Ansichten immer noch ein großes Problem dar:

• Das Erstellen einer virtuellen Ansicht macht die Daten nicht einfacher zu finden.

• Das Zusammenführen von Daten aus mehreren heterogenen Systemen ist komplex und rechenintensiv und führt oft zu einer massiven Belastung der Systeme und langen Ausführungszyklen. Diese sogenannten verteilten Verknüpfungen von Tabellen, die nicht in den Speicher passen, sind notorisch ressourcenintensiv.

Im Gegensatz dazu werden beim kataloggesteuerten Ansatz nur die Metadaten über jeden Datensatz veröffentlicht, um ihn auffindbar zu machen. Die Datensätze werden dann demselben System (z. B. einem Hadoop-Cluster) zur Verfügung gestellt, um lokal verarbeitet zu werden, wie in Abbildung 1-15 dargestellt.

Abbildung 1-15. Bereitstellung von Metadaten über einen Katalog

Ein Unternehmenskatalog macht nicht nur alle Daten auffindbar und für Analysten zugänglich, sondern kann auch als zentraler Punkt für Zugriff, Governance, und Auditing dienen, wie in Abbildung 1-16 dargestellt. Oben: Ohne einen zentralen Katalog ist der Zugriff auf die Daten überall verstreut und schwer zu verwalten und zu verfolgen. Unten, mit dem zentralen Katalog, laufen alle Zugriffsanfragen über den Katalog. Der Zugriff wird bei Bedarf für einen bestimmten Zeitraum gewährt und vom System überprüft.

Abbildung 1-16. Datenbereitstellung und -verwaltung über den Katalog

Fazit

Zusammenfassend lässt sich sagen, dass die richtige Plattform , das Laden der richtigen Daten auf und die Organisation und Einrichtung der Selbstbedienung mit einer an die Fähigkeiten und Bedürfnisse angepassten Schnittstelle der Schlüssel zum erfolgreichen Aufbau eines Data Lake sind. Im weiteren Verlauf dieses Buches werden wir untersuchen, wie diese Aufgaben zu bewältigen sind.