Ich dachte, der ganze Sinn der Verwendung eines Data Lake gegenüber einem Data Warehouse war, den ETL-Prozess (Extract, Transform, Load) in LET (Load, Extract, Transform) zu invertieren. Wenn wir diese Daten nicht extrahieren, transformieren und in eine Tabelle laden, kommen wir genau dahin zurück, wo wir angefangen haben?Was ist der Sinn einer Tabelle in einem Datensee?
IMHO der Punkt eines Datensees ist, alle Arten von Daten zu speichern: unstrukturiert, semi-strukturiert und strukturiert. Die Azure-Version von diesem ist Azure Data Lake Store (ADLS) und seine primäre Funktion ist skalierbarer Massenspeicher.
Separat gibt es ein Produkt Azure Data Lake Analytics (ADLA). Dieses Analyseprodukt kann mit ADLS interagieren, aber auch mit Blob Storage, SQL auf einer VM (IaaS) und den beiden PaaS-Datenbankangeboten SQL Database und SQL Data Warehouse sowie HDInsight. Es hat eine leistungsfähige Batch-Sprache namens U-SQL, eine Kombination aus SQL und .net zum Abfragen und Bearbeiten dieser Datenspeicher. Es verfügt auch über eine Datenbankoption, mit der Sie gegebenenfalls Daten, die Sie verarbeitet haben, im Tabellenformat speichern können.
Ein Beispiel könnte sein, dass Sie einige unstrukturierte Daten in Ihrem See haben, Sie Ihre Batch-Ausgabe ausführen und die strukturierte Zwischenausgabe speichern möchten. Hier können Sie die Ausgabe in einer ADLA-Datenbanktabelle speichern. Ich neige dazu, sie zu verwenden, wo ich beweisen kann, dass ich eine Leistungsverbesserung von ihnen bekommen kann und/oder die verschiedenen Indizierungsoptionen nutzen möchte.
Ich neige dazu, diese als Warehousetabellen zu betrachten, weil sie mit anderen Produkten noch nicht gut interagieren, dh sie haben noch keine Endpunkte/sind nicht sichtbar, zB Azure Data Factory kann sich nicht bewegen Tabellen von dort noch.
Schließlich denke ich, dass ADLS analog zu HDFS und U-SQL/ADLA analog zu Spark ist.
HTH
definitionsgemäß ein Daten See ist ein riesiges Repository Rohdaten Speicherung in seiner nativen Format, bis sie benötigt. Seen verwenden eine flache Architektur statt verschachtelt (http://searchaws.techtarget.com/definition/data-lake). Daten im See haben eine eindeutige ID und Metadaten-Tags, die in Abfragen verwendet werden.
So können Datenseen strukturierte, semistrukturierte und unstrukturierte Daten speichern. Strukturierte Daten würden Daten vom Typ SQL-Datenbank in Tabellen mit Zeilen und Spalten enthalten. Semi-strukturiert wären CSV-Dateien und dergleichen. Und unstrukturierte Daten sind alles und jedes - E-Mails, PDFs, Videos, Binärdateien. Mithilfe dieser ID und der Metadaten-Tags können Benutzer Daten im See finden.
Um einen Datensee überschaubar zu halten, rotieren, archivieren oder bereinigen erfolgreiche Implementierer regelmäßig Daten aus dem See. Sonst wird es zu dem, was manche als "Datensumpf" bezeichnet haben, im Grunde ein Datenfriedhof.
Der traditionelle ELT-Prozess eignet sich besser für Data Warehouses, da sie strukturierter sind und die Daten in einem Warehouse für einen Zweck da sind. Datenseen, die weniger strukturiert sind, eignen sich besser für andere Ansätze wie ELT (Extrahieren, Laden, Transformieren), da sie Rohdaten speichern, die nur durch jede Abfrage kategorisiert werden. (Siehe hierzu article von Panopoly für eine Besprechung von ELT vs ETL.) Sie möchten zum Beispiel Kundendaten von 2010 sehen. Wenn Sie einen Datensee danach abfragen, erhalten Sie alles aus Buchhaltungsdaten, CRM-Datensätzen und sogar E-Mails von 2010 Sie können diese Daten erst analysieren, wenn sie in brauchbare Formate umgewandelt wurden, in denen die gemeinsamen Nenner Kunden + 2010 sind.
Für mich ist die Antwort „Geld“ und „Ressourcen“
(und wahrscheinlich korreliert von Excel zu verwenden, um Daten zu verbrauchen :))
Ich war durch ein paar Migrationen von RDBMS zu Hadoop/Azure-Plattformen und es kommt auf die Kosten/Budget und Use-Cases:
1) Port-Legacy-Reporting-Systeme auf neue Architekturen
2) Skillset von Endnutzern, die die Daten verbrauchen Geschäftswert
fahren3) Die Art der Daten, die durch den Endbenutzer verarbeitet werden
4) Skillset von Support-Mitarbeiter, die die Endanwender
5) Ob der Zweck der Migration unterstützen ist Infrastruktur Support-Kosten zu reduzieren, oder aktivieren neue Fähigkeiten.
einige weitere Details für ein paar der oben:
Legacy-Berichterstattung oft Systeme basieren entweder auf einige Analytics-Software oder homegrown-System, das im Laufe der Zeit eine tief verwurzelte Erwartung für saubere hat, regiert, strukturiert, stark -typisierte Daten. Um das Backend-System zu wechseln, müssen oft die gleichen Strukturen veröffentlicht werden, um zu vermeiden, dass die gesamte Analyselösung und Codebasis ersetzt werden.
Skillsets sind auch ein Hauptanliegen, weil Sie oft von Hunderten bis Tausenden von Leuten reden, die gewohnt sind, Excel zu benutzen, mit etwas SQL. Wenige Endanwender, meiner Erfahrung nach, und wenige Analysten, mit denen ich gearbeitet habe, können programmieren. Statistiker und Dateningenieure neigen zu R/Python. Und Entwickler mit Java/C# -Erfahrung tendieren zu Scala/Python.
Datentypen sind ein entscheidender Faktor dafür, welches Werkzeug für den Job geeignet ist ... aber hier haben Sie einen großen Konflikt, weil es Leute gibt, die mit "Datenrechtecken" (zB Datenrahmen/Tabellendaten) umgehen können, und diejenigen, die wissen, wie man mit anderen Formaten arbeitet. Allerdings finde ich immer noch Leute, die semistrukturierte/binäre/unstrukturierte Daten konsequent in eine Tabelle umwandeln, sobald sie ein Ergebnis operationalisieren müssen ... weil Support für Spark schwierig zu finden ist.