Brauchen wir einen Data Lake? Was tun mit dem Data Warehouse?

Dieser Artikel ist eine Übersetzung meines Artikels auf Medium - Erste Schritte mit Data Lake, das sich wahrscheinlich aufgrund seiner Einfachheit als sehr beliebt herausstellte. Deshalb habe ich beschlossen, es auf Russisch zu schreiben und ein wenig hinzuzufügen, um einem normalen Menschen, der kein Datenspezialist ist, klar zu machen, was ein Data Warehouse (DW) ist, was ein Data Lake ist (Data Lake) und wie er funktioniert miteinander auskommen.

Warum wollte ich über den Data Lake schreiben? Ich arbeite seit über 10 Jahren mit Daten und Analysen, und jetzt arbeite ich definitiv mit Big Data bei Amazon Alexa AI in Cambridge, das in Boston liegt, obwohl ich in Victoria auf Vancouver Island lebe und oft Boston, Seattle, besuche , und in Vancouver und manchmal sogar in Moskau spreche ich auf Konferenzen. Von Zeit zu Zeit schreibe ich auch, aber ich schreibe hauptsächlich auf Englisch, und ich habe bereits geschrieben einige Bücher, ich habe auch das Bedürfnis, Analysetrends aus Nordamerika zu teilen, und manchmal schreibe ich ein Telegramme.

Ich habe immer mit Data Warehouses gearbeitet, seit 2015 arbeite ich eng mit Amazon Web Services zusammen und bin generell auf Cloud Analytics (AWS, Azure, GCP) umgestiegen. Ich habe die Entwicklung von Analyselösungen seit 2007 beobachtet und sogar für den Data-Warehouse-Anbieter Teradata gearbeitet und es bei der Sberbank implementiert, und da kam Big Data mit Hadoop auf den Markt. Alle begannen zu sagen, dass die Ära der Speicherung vorbei sei und jetzt alles auf Hadoop sei, und dann fingen sie wieder an, über Data Lake zu reden, dass nun definitiv das Ende des Data Warehouse gekommen sei. Aber zum Glück (vielleicht zum Unglück für einige, die mit der Einrichtung von Hadoop viel Geld verdient haben) ist das Data Warehouse nicht verschwunden.

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

Auf dem Bild ist der Bleder See zu sehen, das ist einer meiner Lieblingsseen, obwohl ich nur einmal dort war, erinnere ich mich für den Rest meines Lebens daran. Aber wir werden über eine andere Art von See sprechen – einen Datensee. Vielleicht haben viele von Ihnen schon mehr als einmal von diesem Begriff gehört, aber eine weitere Definition wird niemandem schaden.

Hier zunächst die gängigsten Definitionen eines Data Lake:

„Eine Dateispeicherung aller Arten von Rohdaten, die jedem in der Organisation zur Analyse zur Verfügung steht“ – Martin Fowler.

„Wenn Sie denken, dass ein Data Mart eine Flasche Wasser ist – gereinigt, verpackt und für den bequemen Verbrauch verpackt, dann ist ein Data Lake ein riesiges Wasserreservoir in seiner natürlichen Form.“ Benutzer, ich kann Wasser für mich selbst sammeln, tief tauchen, erkunden“ – James Dixon.

Jetzt wissen wir mit Sicherheit, dass es bei einem Data Lake um Analysen geht, er ermöglicht uns die Speicherung großer Datenmengen in ihrer ursprünglichen Form und wir haben den notwendigen und bequemen Zugriff auf die Daten.

Ich mag es oft, Dinge zu vereinfachen. Wenn ich einen komplexen Begriff mit einfachen Worten erklären kann, dann verstehe ich selbst, wie er funktioniert und wofür er benötigt wird. Eines Tages stöberte ich in der iPhone-Fotogalerie herum und mir wurde klar, dass dies ein echter Datensee ist. Ich habe sogar eine Folie für Konferenzen erstellt:

Alles ist sehr einfach. Wir machen ein Foto auf dem Telefon, das Foto wird auf dem Telefon gespeichert und kann in iCloud (Cloud-Dateispeicher) gespeichert werden. Das Telefon sammelt auch Foto-Metadaten: was angezeigt wird, Geo-Tag, Zeit. Dadurch können wir über die benutzerfreundliche Oberfläche des iPhones unser Foto finden und sehen sogar Hinweise, wenn ich beispielsweise nach Fotos mit dem Wort Feuer suche, finde ich 3 Fotos mit dem Bild eines Feuers. Für mich ist das so etwas 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önnen unsere Daten leicht in die Öffentlichkeit gelangen. Es gibt viele Neuigkeiten über große Unternehmen und Startups, deren Daten aufgrund der Nachlässigkeit der Entwickler und der Nichtbeachtung einfacher Regeln öffentlich zugänglich wurden.

Selbst ein so einfaches Bild hilft uns, uns vorzustellen, was ein Data Lake ist, welche Unterschiede es zu einem herkömmlichen Data Warehouse gibt und welche Hauptelemente es enthält:

1. Daten werden geladen (Ingestion) ist eine Schlüsselkomponente des Data Lake. Daten können auf zwei Arten in das Data Warehouse gelangen: Batch (Laden in Intervallen) und Streaming (Datenfluss).
2. Dateispeicher (Speicher) ist die Hauptkomponente des Data Lake. Der Speicher musste einfach skalierbar, äußerst zuverlässig und kostengünstig sein. In AWS ist es beispielsweise S3.
3. Katalog und Suche (Katalog und Suche) – Damit wir den Datensumpf vermeiden können (wenn wir alle Daten auf einen Stapel legen und es dann unmöglich ist, damit zu arbeiten), müssen wir eine Metadatenebene erstellen, um die Daten zu klassifizieren damit Benutzer die Daten, die sie für die Analyse benötigen, leicht finden können. Darüber hinaus können Sie weitere Suchlösungen wie ElasticSearch nutzen. 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 Struktur ändern, sie bereinigen und vieles mehr.
5. Sicherheit (Sicherheit) – Es ist wichtig, Zeit in das Sicherheitsdesign der Lösung zu investieren. Beispielsweise Datenverschlüsselung beim Speichern, Verarbeiten und Laden. Es ist wichtig, Authentifizierungs- und Autorisierungsmethoden zu verwenden. Schließlich wird ein Audit-Tool benötigt.

Aus praktischer Sicht können wir einen Data Lake durch drei Attribute charakterisieren:

1. Sammeln und lagern Sie alles – Der Datensee enthält alle Daten, sowohl unverarbeitete Rohdaten für einen beliebigen Zeitraum als auch verarbeitete/bereinigte Daten.
2. Tiefen-Scan – Ein Data Lake ermöglicht Benutzern das Erkunden und Analysieren von Daten.
3. Flexibler Zugang — Der Data Lake bietet flexiblen Zugriff für unterschiedliche Daten und unterschiedliche Szenarien.

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

• Was ist mit dem Data Warehouse?
• Ersetzen wir das Data Warehouse durch einen Data Lake oder erweitern wir ihn?
• Kann man auf einen Data Lake noch verzichten?

Kurz gesagt, es gibt keine klare Antwort. Es hängt alles von der konkreten Situation, den Fähigkeiten des Teams und dem Budget ab. Zum Beispiel die Migration eines Data Warehouse von Oracle zu AWS und die Erstellung eines Data Lake durch eine Amazon-Tochtergesellschaft – Woot – Unsere Data-Lake-Geschichte: Wie Woot.com einen serverlosen Data Lake auf AWS aufgebaut hat.

Auf der anderen Seite sagt der Anbieter Snowflake, dass man nicht mehr über einen Data Lake nachdenken muss, da seine Datenplattform (bis 2020 war es ein Data Warehouse) es ermöglicht, sowohl einen Data Lake als auch ein Data Warehouse zu kombinieren. Ich habe nicht viel mit Snowflake gearbeitet und es ist wirklich ein einzigartiges Produkt, das dies kann. Der Preis der Emission ist eine andere Sache.

Zusammenfassend ist meine persönliche Meinung, dass wir immer noch ein Data Warehouse als Hauptdatenquelle für unser Reporting benötigen und alles, was nicht passt, in einem Data Lake speichern. Die gesamte Aufgabe der Analyse besteht darin, Unternehmen einen einfachen Zugang zur Entscheidungsfindung zu ermöglichen. Was auch immer man sagen mag, Geschäftsanwender arbeiten effizienter mit einem Data Warehouse als mit einem Data Lake, zum Beispiel in Amazon – es gibt Redshift (analytisches Data Warehouse) und es gibt Redshift Spectrum/Athena (SQL-Schnittstelle für einen Data Lake in S3 basierend auf Hive/Presto). Das Gleiche gilt auch für andere moderne analytische Data Warehouses.

Schauen wir uns eine typische Data-Warehouse-Architektur an:

Dies ist eine klassische Lösung. Wir haben Quellsysteme, mit ETL/ELT kopieren wir Daten in ein analytisches Data Warehouse und verbinden sie mit einer Business Intelligence-Lösung (mein Favorit ist Tableau, was ist mit Ihrem?).

Diese Lösung hat folgende Nachteile:

• ETL/ELT-Vorgänge erfordern Zeit und Ressourcen.
• Speicher zum Speichern von Daten in einem analytischen Data Warehouse ist in der Regel 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 keinen Zugriff auf Rohdaten.

Natürlich hängt alles von Ihrem Fall ab. Wenn Sie keine Probleme mit Ihrem Data Warehouse haben, benötigen Sie überhaupt keinen Data Lake. Wenn jedoch Probleme aufgrund von Platz- oder Strommangel auftreten oder der Preis eine entscheidende Rolle spielt, können Sie die Option eines Data Lake in Betracht ziehen. Aus diesem Grund erfreut sich der Data Lake großer Beliebtheit. Hier ist ein Beispiel für eine Data-Lake-Architektur:

Beim Data-Lake-Ansatz laden wir Rohdaten in unseren Data Lake (Batch oder Streaming) und verarbeiten die Daten dann nach Bedarf. Der Data Lake ermöglicht es Geschäftsanwendern, eigene Datentransformationen (ETL/ELT) zu erstellen oder Daten in Business Intelligence-Lösungen zu analysieren (sofern der erforderliche Treiber verfügbar ist).

Das Ziel jeder Analyselösung besteht darin, Geschäftsanwendern zu dienen. Deshalb müssen wir immer nach den geschäftlichen Anforderungen arbeiten. (Bei Amazon ist dies eines der Prinzipien – rückwärts arbeiten).

Wenn wir sowohl mit einem Data Warehouse als auch mit einem Data Lake arbeiten, können wir beide Lösungen vergleichen:

Die wichtigste Schlussfolgerung, die daraus gezogen werden kann, ist, dass das Data Warehouse nicht mit dem Data Lake konkurriert, sondern ihn vielmehr ergänzt. Aber es liegt an Ihnen, zu entscheiden, was für Ihren Fall das Richtige ist. Es ist immer interessant, es selbst auszuprobieren und die richtigen Schlussfolgerungen zu ziehen.

Ich möchte Ihnen auch einen der Fälle erzählen, in denen ich angefangen habe, den Data-Lake-Ansatz zu verwenden. Alles ist ziemlich trivial, ich habe versucht, ein ELT-Tool (wir hatten Matillion ETL) und Amazon Redshift zu verwenden, meine Lösung hat funktioniert, entsprach aber nicht den Anforderungen.

Ich musste Webprotokolle aufnehmen, umwandeln und aggregieren, um Daten für zwei Fälle bereitzustellen:

1. Das Marketingteam wollte die Bot-Aktivität für SEO analysieren
2. Die IT-Abteilung wollte sich die Leistungsmetriken der Website ansehen

Sehr einfache, sehr einfache Protokolle. Hier ist 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 wog 1-4 Megabyte.

Aber es gab eine Schwierigkeit. Wir hatten 7 Domains auf der ganzen Welt und an einem Tag wurden 7000 Dateien erstellt. Das ist nicht viel mehr Volumen, nur 50 Gigabyte. Aber auch die Größe unseres Redshift-Clusters war klein (4 Knoten). Das Laden einer Datei auf herkömmliche Weise dauerte etwa eine Minute. Das heißt, das Problem wurde nicht direkt gelöst. Und das war der Fall, als ich mich für den Data-Lake-Ansatz entschied. Die Lösung sah in etwa so aus:

Es ist ganz einfach (ich möchte darauf hinweisen, dass der Vorteil der Arbeit in der Cloud in der Einfachheit liegt). Ich benutzte:

• AWS Elastic Map Reduce (Hadoop) für Rechenleistung
• AWS S3 als Dateispeicher mit der Möglichkeit, Daten zu verschlüsseln und den Zugriff einzuschränken
• Spark als InMemory-Rechenleistung und PySpark für Logik und Datentransformation
• Parkett als Ergebnis von Spark
• AWS Glue Crawler als Metadatensammler über neue Daten und Partitionen
• Redshift Spectrum als SQL-Schnittstelle zum Data Lake für bestehende Redshift-Benutzer

Der kleinste EMR+Spark-Cluster verarbeitete den gesamten Dateistapel in 30 Minuten. Es gibt andere Fälle für AWS, insbesondere viele im Zusammenhang mit Alexa, wo viele Daten vorhanden sind.

Erst kürzlich habe ich erfahren, dass einer der Nachteile eines Data Lake die DSGVO ist. Das Problem besteht darin, dass wir die Datenmanipulationssprache und den DELETE-Vorgang nicht wie in einer Datenbank verwenden können, wenn der Client zum Löschen auffordert und sich die Daten in einer der Dateien befinden.

Ich hoffe, dieser Artikel hat den Unterschied zwischen einem Data Warehouse und einem Data Lake verdeutlicht. Wenn Sie interessiert sind, kann ich weitere meiner Artikel oder Artikel von Fachleuten, die ich gelesen habe, übersetzen. Und erzählen Sie auch von den Lösungen, mit denen ich arbeite, und ihrer Architektur.

Source: habr.com