Dies ist der 2. Beitrag in der Serie zum Whitepaper von Mark Madsen: Wird der Data Lake das Data Warehouse ertränken? In der erster Beitragerläuterte Mark die Unterschiede zwischen dem Data Lake und dem traditionellen Data Warehouse und schloss damit: "Die Kernfähigkeit eines Data Lake und die Quelle eines Großteils seines Wertes ist die Fähigkeit, beliebige Daten zu verarbeiten."
In diesem Beitrag gibt Mark einen Überblick über das neue Umfeld und die neuen Anforderungen:
"Die Umgebungen aus der Zeit vor Hadoop, einschließlich der Integrationstools, die für die Verarbeitung strukturierter Zeilen und Spalten entwickelt wurden, schränken die Art der zu verarbeitenden Daten ein. Die Anforderungen im neuen Ökosystem, die den traditionellen Umgebungen am meisten zu schaffen machen, sind variable Datenstrukturen, Streaming-Daten und nicht-relationale Datensätze.
Daten-Strukturen: JSON ist das neue CSV
Das häufigste Austauschformat zwischen Anwendungen sind nicht Datenbankkonnektoren, sondern flache Dateien im CSV-Format (comma-separated value), die häufig über FTP ausgetauscht werden. Eine der großen Veränderungen im Anwendungsdesign in den letzten zehn Jahren war der Übergang zu REST-APIs mit Nutzdaten im JSON-Format, einem zunehmend verbreiteten Datenformat. In Kombination mit einer Streaming-Infrastruktur reduziert diese Entwicklung den Bedarf an einer Dateiintegration im alten Stil. JSON und APIs werden zu den neuen CSV- und FTP-Formaten.
Die meisten Tools zur Integration von Unternehmensdaten wurden unter der Annahme entwickelt, dass eine relationale Datenbank verwendet wird. Dies funktioniert gut für Daten, die aus transaktionalen Anwendungen stammen. Weniger gut funktioniert es bei Protokollen, Ereignisströmen und von Menschen erstellten Daten. Diese haben nicht die gleiche regelmäßige Struktur von Zeilen, Spalten und Tabellen, die Datenbanken und Integrationswerkzeuge erfordern. Diese Tools haben Schwierigkeiten, mit JSON zu arbeiten und müssen zusätzliche Arbeit leisten, um sie zu verarbeiten und zu speichern.
Das Gegenteil ist nicht der Fall. Neuere Datenintegrationstools können problemlos Tabellen in JSON darstellen, während verschachtelte Strukturen in JSON nur schwer in Tabellen dargestellt werden können. Die flexible Darstellung von Daten ermöglicht eine späte Bindung für Datenstrukturen und Datentypen.
Dies ist ein entscheidender Vorteil von JSON im Vergleich zu den frühen Bindungen und der statischen Typisierung, die von älteren Datenintegrationstools verwendet werden. Eine einfache Feldänderung im Vorfeld kann einen Datenfluss in den älteren Tools unterbrechen, während die flexiblere neue Umgebung in der Lage ist, ohne Unterbrechung weiterzumachen.
JSON ist jedoch nicht das beste Format für die Speicherung von Daten. Das bedeutet, dass Tools erforderlich sind, um Daten von JSON in effizientere Speicherformate in Hadoop und von diesen Formaten zurück in JSON für Anwendungen zu übersetzen. Ein Großteil der Web- und Nicht-Transaktionsdaten wird heute als JSON-Nachrichten gesendet. Die flexibleren Hadoop- und Streaming-Technologien sind für den Transport und die Verarbeitung dieser Daten besser geeignet als herkömmliche Datenintegrationstools.
Streams sind das neue Batch
Häufig stammen die ersten Datenquellen in einem Data Lake aus Ereignisströmen und können kontinuierlich und nicht im Stapel verarbeitet werden. In der Regel ist ein Data Warehouse ein schlechter Ort, um Daten zu verarbeiten, die in weniger als ein paar Minuten verfügbar sein müssen. Die Architektur wurde für periodische inkrementelle Lasten konzipiert, nicht für einen kontinuierlichen Datenstrom. Ein Data Lake sollte verschiedene Geschwindigkeiten unterstützen, von nahezu Echtzeit bis zu Batch mit hoher Latenz.
Die Stapelverarbeitung ist eigentlich eine Teilmenge der Stromverarbeitung. Es ist einfach, Daten für eine gewisse Zeit zu speichern und dann einen Auftrag auszuführen, um sie als Stapel zu verarbeiten. Es ist nicht so einfach, ein Stapelsystem so zu gestalten, dass es die Daten effizient nacheinander verarbeitet. Eine Batch-Engine kann mit den Anforderungen des Streaming nicht mithalten, aber Tools, die für die Verarbeitung von Streaming-Daten entwickelt wurden, können sich wie eine Batch-Engine verhalten.
Streaming-Daten bedeuten auch, dass das Datenvolumen schwanken kann, von einem kleinen Rinnsal in einer Stunde bis zu einer Flut in der nächsten. Die festen Servermodelle und die Kapazitätsplanung einer herkömmlichen Architektur lassen sich nicht gut auf die dynamische Skalierung der Server übertragen, wenn das Nachrichtenvolumen wächst und schrumpft. Dies erfordert ein Umdenken bei der Skalierung der Datenerfassung und -integration."
--
In dem Whitepaper Will the Data Lake Drown the Data Warehouse? heißt es weiter : "Verschiedene Datensätze treiben neue Maschinen an". Im nächsten Beitrag dieser Serie wird Mark die neue Data Lake-Architektur beschreiben und dabei auf einige der Konzepte eingehen, die er in dem dazugehörigen Data Lake-Whitepaper behandelt hat: How to Build an Enterprise Data Lake: Wichtige Überlegungen, bevor Sie loslegen. Sehen Sie sich auch die jüngste Webinar-Präsentation und -Aufzeichnung mit SnapLogic hier an und erfahren Sie mehr über SnapLogic für Big Data Integration hier.
