Das tiefe Ende des Data Lake

Storage steht im Zeitalter von Big Data und Analytik vor einem Umbruch. Sven Breuner, Field CTO International bei VAST Data, sieht in einem Gastbeitrag zunehmenden Bedarf an agileren Systemen.

Schneller, höher, weiter. Datenanalytik und die Speichersysteme, die Datenanalytik-Workloads ermöglichen, haben sich im letzten Jahrzehnt stark weiterentwickelt. Zu Beginn der 2010er Jahre wurden Big-Data-Frameworks wie Hadoop mit den wachsenden Datenmengen immer beliebter. Hadoop wurde ursprünglich als Batch Processing-, also Stapelverarbeitungs-Framework für semi-strukturierte Daten konzipiert und implementiert. Die Benutzer konzentrierten sich zunächst auf die Nachbearbeitung von Daten, wobei die Aufträge Stunden oder Tage dauern konnten.

Mittlerweile sieht die Lage nach Meinung von VAST Data jedoch anders aus: Die heutigen Arbeitslasten erfordern jedoch eine Plattform, die nicht nur die stapelorientierten Workloads, sondern auch Ad-hoc-/interaktive Abfragen und sogar Echtzeit-Analysen bewältigen kann. Hadoop und insbesondere HDFS (das Hadoop Distributed File System, das Dateien lokal auf den Knoten des Clusters speichert und gleichzeitig die Konsistenz verwaltet) wurde nicht für diese Anwendungsfälle konzipiert. VAST Data beobachtet daher, dass nun eine Umstellung auf agilere und leistungsorientiertere Systeme im Gange ist.

Das Hadoop-Erbe

Im Laufe der Zeit hat Hadoop an Popularität eingebüßt, aber die zugrundeliegenden Konzepte, die es eingeführt hat, wurden zum Kern moderner Datenanalytiksysteme wie Databricks und haben ein reiches Ökosystem von Analyseprojekten wie Hive, Kafka und Impala hervorgebracht. Zu den Hadoop zugrundeliegenden Konzepten zählen MapReduce als Computing-Paradigma, die enge Kopplung von Storage und Compute, um den Netzwerkverkehr zu reduzieren, und die Verwendung von handelsüblicher „Commodity“-Hardware zum Aufbau strukturierter und halbstrukturierter Analyseplattformen.

Hadoop wurde in den frühen 2000er Jahren bei Yahoo entwickelt. Die ursprüngliche Idee stammt aus zwei Google-Arbeiten („The Google File System“ und „MapReduce: Simplified Data Processing on Large Clusters“) und ermöglichte es Yahoo, die Verarbeitungsleistung zu erhöhen und gleichzeitig kostengünstige, handelsübliche Hardware zu verwenden. Hadoop war und ist ein Open-Source-Projekt von Apache, das es jedem Unternehmen oder Benutzer ermöglicht, die Software herunterzuladen und frei zu nutzen. Hadoop versprach, den Markt für Data Warehouse und Analytik, der lange Zeit eine Hochburg von Unternehmen wie Oracle, Teradata und IBM war, aufzumischen. Während MapReduce, ein Framework zur Datenparallelisierung, in der Technologiegeschichte verschwunden ist, ist HDFS als Dateisystem zur Unterstützung von Big-Data-Anwendungen wie Spark und Kafka nach wie vor weit verbreitet.

Als HDFS ins Leben gerufen wurde, waren Festplatten schneller als Netzwerkadapter, so dass es als gemeinsam genutzter Cluster aus handelsüblichen Servern mit Direct-Attached Storage (DAS)-Geräten eingesetzt wurde. Dadurch konnte die Rechenleistung näher an die Medien gebracht werden. Zu dieser Zeit waren Solid-State-Laufwerke (SSDs) teuer und in ihrer Kapazität begrenzt, weshalb Festplatten (HDDs) zum Einsatz kamen. Außerdem waren die meisten Netzwerke noch auf Gigabit (1 Gbit/s) ausgelegt, was bedeutete, dass die einzige Möglichkeit zur Vermeidung von Netzwerkengpässen darin bestand, Speicher- und Rechenressourcen eng miteinander zu verbinden. Dieses Konzept, das als „Shared-Nothing“-Speicherarchitektur bekannt ist, wurde 2003 im White Paper zum Google File System vorgestellt. So können beispielsweise zwölf Festplatten etwa 1 GByte/Sek. liefern. Bei Verwendung eines Gigabit-Netzwerks ist der Durchsatz jedoch auf ca. 100 MByte/Sek. begrenzt, was das Netzwerk zu einem Engpass macht.

Als sich Big-Data-Systeme über MapReduce hinaus zu Echtzeitlösungen wie Spark und Kafka weiterentwickelten, musste der Speicher schneller werden und Datenanalysetechniken unterstützen. Außerdem musste er auf Tausende von Knoten skalierbar sein und eine nahezu unbegrenzte Kapazität bieten.

Verständnis der Lambda-Architektur und Big Data-Verarbeitung

Der Kern der meisten Big-Data-Workflows ist ein Muster, das Lambda-Architektur genannt wird. Diese Arbeitslast hängt von Ereignissen ab, die in großem Umfang eintreffen. In der Regel stammen diese Daten aus Quellen wie Protokolldateien oder IoT-Sensoren und fließen dann in eine Streaming-Plattform wie Kafka. Kafka ist eine Open-Source-Plattform für verteiltes Ereignis-Streaming, die diese Datenströme verarbeiten kann.

Ein Stream-Prozessor ist so etwas wie eine einzige Abfrage, die für alle durchströmenden Werte ausgeführt wird. Diese Abfrage fungiert als bedingte Aufteilung. So werden beispielsweise Sensordaten erfasst, damit eine bestimmte Aktion durchgeführt werden kann. Dies könnte in Form der Ausführung einer Funktion im Falle eines Computersystems oder der physischen Untersuchung eines Geräts durch einen Bediener geschehen. Der Rest der Werte wird in einer „kalten“ Schicht gestreamt, die eine umfassendere Analyse aller Werte für Trendanalysen und maschinelle Lerndienste ermöglicht.

Diese kalte Schicht ist in der Regel ein Data Warehouse oder eine Kombination aus HDFS und Spark. Eines der Hindernisse für Hadoop in einer physischen Infrastruktur mit lokalem Speicher ist, dass man für die Erweiterung der Speicherkapazität auch Rechenkapazitäten hinzufügen musste – wiederum aufgrund der engen Kopplung von CPU und Kapazität in Shared-Nothing-Architekturen, was in Bezug auf die tatsächlichen Kosten und die Verwaltung kostspielig war. Diese Architektur ähnelt vom Konzept her der hyperkonvergenten Infrastruktur, bei der man für mehr Rechen- oder Speicherkapazität sowohl Festplatten als auch Server kaufen muss.

Aus den Herausforderungen von Hadoop ergaben sich zwei wichtige Ergebnisse. Zum einen wendeten sich Unternehmen der Objektspeicherung als kostengünstiger Speicher für Big Data zu. Die S3-API wurde schnell zum Industriestandard, der es Unternehmen ermöglicht, Daten in fast jedem Objektspeicher zu speichern, abzurufen, aufzulisten, zu löschen und zu verschieben. Zum anderen kam ein technologischer Durchbruch in jüngerer Zeit in Form der DASE-Architektur (Disaggregated Shared Everything). Diese ermöglicht es, Cluster-Speicher unabhängig von der Rechenleistung zu skalieren, um die Kapazitäts- und Leistungsanforderungen von Anwendungen besser zu erfüllen.

Das tiefe Ende des Data Lake

Eine weitere Erfindung, die die moderne Speicherung vorangetrieben hat, ist das Konzept des Data Lake, bei dem die zur Analyse anstehenden Daten in ihrem Rohformat gespeichert werden – in der Regel auf einem verteilten Dateisystem.

Der schwierigste Teil jedes Business Intelligence- oder Datenanalysesystems besteht darin, die Daten aus ihrem Rohformat in ein Format zu bringen, in dem sie leicht abgefragt werden können. Traditionell wurde dies durch einen Prozess namens Extract, Load, and Transform (ETL) bewerkstelligt. Dieser Prozess wurde zum aktuellen Ansatz von ETL geändert, bei dem die Transformation auf der Abfrageebene stattfindet. Dadurch können verschiedene Anwendungen auf die Rohdaten zugreifen und nur die für sie erforderlichen Transformationen durchführen.

Spark wurde für die Arbeit mit Data Lakes entwickelt und ist schnell und flexibel; es lässt sich in eine Vielzahl von Data Lakes integrieren und unterstützt eine große Anzahl von Sprachen. Unternehmen können Scala, SQL oder Java sowie Jupyter Notebooks verwenden, die es auch weniger fortgeschrittenen Benutzern ermöglichen, fortgeschrittene Aufgaben auszuführen. Spark verwendet Speicher, um Daten zu verknüpfen, und kann wie ein Scale-Out-Data-Warehouse agieren, wobei die Kosten wesentlich geringer sind. Die schnelle Akzeptanz und die weit verbreitete User-Community haben dazu beigetragen, dass Spark zu einem der beliebtesten Datenanalysetools der heutigen Zeit avanciert ist.

Neben den Frameworks für die Datenanalyse in großem Maßstab haben sich jedoch auch die zugrundeliegenden Speichermedien erheblich verändert, die die Skalierung, Geschwindigkeit und das Volumen der Datenanalyse ermöglichen. Als Hadoop entwickelt wurde, war es auf sehr dichte, sehr günstige mechanische Festplatten mit 7.200 U/min ausgelegt. Solid-State-Speicher haben sich durch Protokolle wie NVMe, die extrem niedrige Latenzzeiten bieten, und sehr dichte SSDs zu viel günstigeren, dichteren und schnelleren Speichern entwickelt. Diese Geschwindigkeit, kombiniert mit Kostensenkungen bei SSDs, bedeutet, dass Unternehmen hoch skalierbaren und erschwinglichen All-Flash-Speicher zur Unterstützung ihres Data Lake haben.

Die Dinge werden nie mehr so sein wie bisher

VAST Data fasst abschließen zusammen: Der Speicher hat sich im Laufe der Jahre stark weiterentwickelt. Er ist schneller geworden, lässt sich viel besser skalieren und wurde von der zugrundeliegenden Hardware entkoppelt. Die nächste große Herausforderung ist die Frage, wie man die Daten, die sich in diesem Speicher befinden, schützt, verwaltet und aussagekräftige Erkenntnisse daraus zieht. Die DASE-Architektur von VAST Universal Storage ermöglicht es Unternehmen, von der Echtzeit-Speicherleistung für alle Anwendungsfälle der Datenanalyse zu profitieren, von Data-Warehouse-Analysen und Ad-hoc-Abfragen bis hin zu komplexen Data-Science-Aufgaben.

Themenseiten: Hadoop, Vast Data

Fanden Sie diesen Artikel nützlich?
Content Loading ...
Whitepaper

Artikel empfehlen:

Neueste Kommentare 

Noch keine Kommentare zu Das tiefe Ende des Data Lake

Kommentar hinzufügen

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *