Brauchen wir einen Datensee? Und was ist mit einem Datenspeicher?

Dieser Artikel ist eine Übersetzung meines Artikels auf Medium — Erste Schritte mit Data Lake, der sich als ziemlich populär herausgestellt hat, wahrscheinlich wegen seiner Einfachheit. Daher habe ich beschlossen, ihn auf Russisch zu schreiben und ein wenig zu ergänzen, damit es dem Durchschnittsmenschen, der kein Datenexperte ist, verständlich wird, was ein Data Warehouse (DW) ist, was ein Data Lake ist und wie sie miteinander koexistieren.

Warum wollte ich über Data Lake schreiben? Ich arbeite seit über 10 Jahren mit Daten und Analytik, und jetzt arbeite ich definitiv mit Big Data bei Amazon Alexa AI in Cambridge, das in Boston liegt, obwohl ich selbst in Victoria auf Vancouver Island lebe und oft sowohl in Boston, als auch in Seattle und Vancouver bin, und manchmal sogar in Moskau auf Konferenzen spreche. Von Zeit zu Zeit schreibe ich auch, hauptsächlich auf Englisch, und habe bereits mehrere Bücher, ich habe auch das Bedürfnis, Trends in der Analytik aus Nordamerika zu teilen, und manchmal schreibe ich in Telegram.

Ich habe immer mit Data Warehouses gearbeitet und seit 2015 intensiv mit Amazon Web Services zu tun, also habe ich insgesamt auf Cloud-Analytik (AWS, Azure, GCP) umgeschaltet. Ich habe die Evolution der Analytiklösungen seit 2007 beobachtet und habe sogar selbst bei dem Anbieter von Data Warehouses Teradata gearbeitet und dieses in der Sberbank implementiert, damals begann die Ära von Big Data mit Hadoop. Alle fingen an zu sagen, dass die Ära der Data Warehouses vorbei sei und jetzt alles auf Hadoop läuft, und später begann man schon über Data Lake zu sprechen, wiederum, dass es für Data Warehouses jetzt wirklich vorbei sei. Aber zum Glück (vielleicht für einige Unglück, die viel Geld mit der Einrichtung von Hadoop verdient haben), ist das Data Warehouse nicht verschwunden.

In diesem Artikel werden wir uns ansehen, was ein Data Lake ist. Der Artikel richtet sich an Menschen, die wenig oder gar keine Erfahrung mit Data Warehouses haben.

Auf dem Bild ist der Bleder See, eines meiner Lieblingsseen, obwohl ich erst einmal dort war, aber ich werde ihn mein Leben lang in Erinnerung behalten. Aber wir werden über einen anderen Typ See sprechen — den Data Lake. Möglicherweise haben viele von Ihnen diesen Begriff bereits mehrmals gehört, aber eine weitere Definition kann nie schaden.

Zunächst die beliebtesten Definitionen von Data Lake:

„Ein Dateispeicher für alle Arten roher Daten, die von jedem in der Organisation zur Analyse verfügbar sind“ — Martin Fowler.

„Wenn Sie denken, dass ein Datensee eine Flasche Wasser ist – gereinigt, verpackt und für den bequemen Verzehr abgefüllt, dann ist ein Datensee ein riesiger Behälter mit Wasser in seiner natürlichen Form. Benutzer können sich Wasser für sich holen, in die Tiefe tauchen und erkunden“ – James Dixon.

Jetzt wissen wir genau, dass ein Datensee um Analytik geht; er ermöglicht es uns, große Datenmengen in ihrer ursprünglichen Form zu speichern und wir haben den nötigen und bequemen Zugang zu den Daten.

Ich liebe es oft, Dinge zu vereinfachen. Wenn ich einen komplexen Begriff in einfachen Worten erklären kann, bedeutet das, dass ich für mich selbst verstanden habe, wie es funktioniert und wofür es nützlich ist. Neulich habe ich im iPhone in der Fotogalerie herumgestöbert, und es kam mir in den Sinn, das ist doch ein echter Datensee, ich habe sogar eine Folie für Konferenzen gemacht:

Es ist ganz einfach. Wir machen ein Foto mit dem Handy, das Foto wird auf dem Handy gespeichert und kann in iCloud (Cloud-Speicher) gesichert werden. Auch das Handy sammelt Metadaten des Fotos: was darauf zu sehen ist, Geotag, Zeit. Als Ergebnis können wir die benutzerfreundliche Oberfläche des iPhones nutzen, um unser Foto zu finden, und dabei sehen wir sogar Kennzahlen. Zum Beispiel finde ich, wenn ich nach Fotos des Begriffs Feuer (fire) suche, 3 Fotos von einem Lagerfeuer. Für mich ist das wie ein Business-Intelligence-Tool, das sehr schnell und präzise arbeitet.

Und natürlich dürfen wir die Sicherheit (Autorisierung und Authentifizierung) nicht vergessen, sonst könnten unsere Daten leicht öffentlich zugänglich werden. Es gibt viele Nachrichten über große Unternehmen und Startups, deren Daten aufgrund von Nachlässigkeit der Entwickler in den öffentlichen Zugriff geraten sind, weil einfache Regeln nicht beachtet wurden.

Bereits ein so einfaches Bild hilft uns, das Konzept eines Datensees, seine Unterschiede zu traditionellen Datenspeichern und seine grundlegenden Elemente zu verstehen:

1. Daten hochladen (Ingestion) – ein Schlüsselelement eines Datensees. Daten gelangen auf zwei Arten in den Datenspeicher – als Batch (Laden in Intervallen) und Streaming (Datenstrom).
2. Dateispeicher (Storage) – das Hauptbestandteil eines Datensees. Es ist wichtig, dass der Speicher leicht skalierbar, äußerst zuverlässig und kostengünstig ist. Zum Beispiel bei AWS ist das S3.
3. Katalog und Suche (Katalog und Suche) — um das Datenmoor zu vermeiden (das passiert, wenn wir alle Daten in einen Haufen werfen und dann nicht mehr damit arbeiten können), müssen wir eine Schicht aus Metadaten zur Klassifizierung der Daten erstellen, damit die Benutzer die Daten, die sie für ihre Analysen benötigen, leicht finden können. Darüber hinaus können zusätzliche Lösungen für die Suche verwendet werden, wie beispielsweise ElasticSearch. Die Suche hilft dem Benutzer, die benötigten Daten über eine benutzerfreundliche Oberfläche zu finden.
4. Verarbeitung (Prozess) — dieser Schritt ist für die Verarbeitung und Transformation von Daten verantwortlich. Wir können Daten transformieren, ihre Strukturen ändern, sie bereinigen und vieles mehr.
5. Sicherheit (Sicherheit) — es ist wichtig, Zeit für das Sicherheitsdesign der Lösung aufzuwenden. Zum Beispiel die Verschlüsselung von Daten während der Speicherung, Verarbeitung und Übertragung. Es ist wichtig, Authentifizierungs- und Autorisierungsmethoden zu verwenden. Abschließend wird ein Audit-Tool benötigt.

Aus praktischer Sicht können wir den Datensee durch drei Attribute charakterisieren:

1. Sammeln und speichern Sie alles — der Datensee enthält alle Daten, sowohl rohe unbewertete Daten über jeden Zeitraum als auch verarbeitete/bereinigte Daten.
2. Tiefgehende Analysen — der Datensee ermöglicht es Benutzern, Daten zu erkunden und zu analysieren.
3. Flexibler Zugriff — der Datensee gewährleistet flexiblen Zugriff auf unterschiedliche Daten und verschiedene Szenarien.

Jetzt können wir über den Unterschied zwischen einem Data Warehouse und einem Datensee sprechen. Oft fragen die Leute:

• Und wie steht es um das Data Warehouse?
• Ersetzen wir das Data Warehouse durch einen Datensee oder erweitern wir es?
• Kann man wirklich ohne einen Datensee auskommen?

Kurz gesagt, es gibt keine klare Antwort. Es hängt von der spezifischen Situation, den Fähigkeiten im Team und dem Budget ab. Zum Beispiel die Migration eines Data Warehouse von Oracle nach AWS und die Erstellung eines Datensees durch die Tochtergesellschaft von Amazon — Woot — Unsere Datensee-Geschichte: Wie Woot.com einen serverlosen Datensee auf AWS aufgebaut hat..

Andererseits behauptet der Anbieter Snowflake, dass Sie sich nicht mehr um einen Datensee kümmern müssen, da ihre Datenplattform (bis 2020 war dies ein Data Warehouse) es Ihnen ermöglicht, sowohl Datensee als auch Data Warehouse zu kombinieren. Ich habe ein wenig mit Snowflake gearbeitet, und es ist tatsächlich ein einzigartiges Produkt, das das leisten kann. Der Preis ist ein anderes Thema.

Zusammenfassend ist meine persönliche Meinung, dass wir weiterhin ein Data Warehouse als primäre Datenquelle für unsere Berichterstattung benötigen, während alles, was nicht passt, in einem Data Lake gespeichert wird. Die gesamte Rolle der Analytik besteht darin, dem Unternehmen einen einfachen Zugang zu ermöglichen, um Entscheidungen zu treffen. Letztendlich arbeiten Geschäftsanwender effizienter mit einem Data Warehouse als mit einem Data Lake; zum Beispiel gibt es bei Amazon Redshift (ein analytisches Data Warehouse) und Redshift Spectrum/Athena (SQL-Schnittstelle für den Data Lake in S3 auf Basis von Hive/Presto). Dasselbe gilt für andere moderne analytische Data Warehouses.

Schauen wir uns die typische Architektur eines Data Warehouses an:

Dies ist eine klassische Lösung. Wir haben Quelldatenquellen, und mit ETL/ELT kopieren wir die Daten in das analytische Data Warehouse und verbinden es mit einer Business Intelligence-Lösung (mein Favorit ist Tableau, und Ihrer?).

Solch eine Lösung hat folgende Nachteile:

• ETL/ELT-Vorgänge benötigen Zeit und Ressourcen.
• In der Regel ist der Speicherplatz für die Daten in einem analytischen Data Warehouse nicht billig (z.B. Redshift, BigQuery, Teradata), da wir einen ganzen Cluster kaufen müssen.
• Geschäftsanwender haben Zugriff auf bereinigte und häufig aggregierte Daten und haben nicht die Möglichkeit, Rohdaten zu erhalten.

Natürlich hängt alles von Ihrem Anwendungsfall ab. Wenn Sie keine Probleme mit Ihrem Data Warehouse haben, benötigen Sie überhaupt keinen Data Lake. Aber wenn Probleme mit Platzmangel, Leistung oder Preis eine entscheidende Rolle spielen, kann ein Data Lake in Betracht gezogen werden. Deshalb ist der Data Lake sehr beliebt. Hier ist ein Beispiel für die Architektur eines Data Lakes:

Durch die Nutzung des Data Lake-Ansatzes laden wir Rohdaten in unseren Data Lake (Batch oder Streaming) und verarbeiten die Daten nach Bedarf. Der Data Lake ermöglicht es Geschäftsanwendern, ihre eigenen Daten-Transformierungen (ETL/ELT) zu erstellen oder Daten in Business Intelligence-Lösungen zu analysieren (sofern der entsprechende Treiber vorhanden ist).

Ziel jeder analytischen Lösung ist es, den Geschäftsanwendern zu dienen. Daher sollten wir immer von den Anforderungen des Unternehmens ausgehen. (Bei Amazon ist dies eines der Prinzipien – working backwards).

Durch die gleichzeitige Arbeit mit einem Data Warehouse und einem Data Lake können wir beide Lösungen vergleichen:

Die wichtigste Erkenntnis, die man daraus ziehen kann, ist, dass ein Data Warehouse nicht in Konkurrenz zu einem Data Lake steht, sondern ihn vielmehr ergänzt. Aber es liegt an Ihnen zu entscheiden, was für Ihren Fall geeignet ist. Es ist immer interessant, es selbst auszuprobieren und die richtigen Schlussfolgerungen zu ziehen.

Ich möchte auch über einen der Fälle berichten, in denen ich anfing, den Data-Lake-Ansatz zu nutzen. Es ist alles ziemlich banal, ich versuchte, das ELT-Tool (wir hatten Matillion ETL) und Amazon Redshift zu verwenden, meine Lösung funktionierte, aber entsprach nicht den Anforderungen.

Ich musste Web-Logs sammeln, sie transformieren und aggregieren, um Daten für zwei Fälle bereitzustellen:

1. Das Marketing-Team wollte die Bot-Aktivität für SEO analysieren.
2. Die IT wollte die Metriken zur Leistung der Websites überwachen.

Sehr einfache, sehr banale Logs. Hier ein Beispiel:

https 2018-07-02T22:23:00.186641Z app/my-loadbalancer/50dc6c495c0c9188 
192.168.131.39:2817 10.0.0.1:80 0.086 0.048 0.037 200 200 0 57 
"GET https://www.example.com:443/ HTTP/1.1" "curl/7.46.0" ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 
arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/my-targets/73e2d6bc24d8a067
"Root=1-58337281-1d84f3d73c47ec4e58577259" "www.example.com" "arn:aws:acm:us-east-2:123456789012:certificate/12345678-1234-1234-1234-123456789012"
1 2018-07-02T22:22:48.364000Z "authenticate,forward" "-" "-"

Eine Datei hatte ein Gewicht von 1-4 Megabyte.

Aber es gab ein Problem. Wir hatten 7 Domains weltweit, und an einem Tag wurden 7000 Dateien erstellt. Das ist nicht sehr viel, insgesamt 50 Gigabyte. Aber die Größe unseres Redshift-Clusters war auch recht klein (4 Knoten). Das traditionelle Hochladen einer Datei dauerte etwa eine Minute. Das heißt, die Aufgabe ließ sich nicht direkt lösen. Und das war der Fall, als ich beschloss, den Data-Lake-Ansatz zu nutzen. Die Lösung sah ungefähr so aus:

Sie ist recht einfach (ich möchte anmerken, dass der Vorteil der Arbeit in der Cloud die Einfachheit ist). Ich verwendete:

• AWS Elastic Map Reduce (Hadoop) als Rechenleistung.
• AWS S3 als Dateispeicher mit der Möglichkeit zur Datenverschlüsselung und Zugriffsregulierung.
• Spark als In-Memory-Rechenleistung und PySpark für die Logik und Datenumwandlung.
• Parquet als Ergebnis der Spark-Verarbeitung.
• AWS Glue Crawler als Metadaten-Collector für neue Daten und Partitionen.
• Redshift Spectrum als SQL-Schnittstelle zum Data Lake für bestehende Redshift-Benutzer.

Der kleinste EMR+Spark-Cluster bearbeitete alle Paketdateien in 30 Minuten. Es gibt auch andere Anwendungsfälle für AWS, besonders viele sind mit Alexa verbunden, wo es eine große Menge an Daten gibt.

Vor Kurzem habe ich einen der Nachteile eines Data Lakes kennengelernt – die DSGVO. Das Problem ist, dass, wenn ein Kunde die Löschung seiner Daten verlangt und sich diese in einer der Dateien befinden, wir keine Data Manipulation Language und keinen DELETE-Befehl wie in einer Datenbank verwenden können.

Ich hoffe, der Artikel hat den Unterschied zwischen einem Data Warehouse und einem Data Lake erklärt. Wenn es interessant war, kann ich gerne weitere meiner Artikel oder Artikel von Fachleuten, die ich lese, übersetzen. Außerdem kann ich über die Lösungen berichten, mit denen ich arbeite, und deren Architektur.

Quelle: habr.com