Mit dem Hadoop Distributed File System (HDFS) Big Data bewältigen

Das Hadoop Distributed File System wird immer mehr zum bevorzugten Tool, das Enterprise-Storage-Anwendern hilft, Big-Data-Probleme zu bewältigen.

Wenn es heute in Diskussionen um Storage geht, sind in der Regel die großen Datenmassen das vorherrschende Thema. Die meisten unterstellen dabei implizit, dass Unternehmen für ihre analytischen Anwendungen so viele Daten wie möglich erfassen und speichern wollen. Und in der Tat trifft das genau, wie es in der Praxis gerade zugeht: Weil es heute in vielen Unternehmen tatsächlich Standard ist, „alle Daten für immer aufzubewahren“, häufen viele Organisationen Petabyte an Daten an.

Diese Praxis ist allerdings nicht unproblematisch. Zwar werden die Storage-Kosten von Jahr zu Jahr billiger – doch die Kosten, all diese Daten zu speichern sind dennoch erheblich. Warum also sollten man alles an Daten speichern, was Tag für Tag anfällt? Weil Führungskräfte heute erkannt haben, dass Daten aufgrund der Fortschritte in der Datenanalyse einen hohen Eigenwert haben. Tatsächlich können Daten inzwischen relativ einfach monetarisiert werden. Die Führungskräfte sind inzwischen überzeugt, dass der Wert der Daten steigt – während gleichzeitig der Wert einer eigenen IT-Infrastruktur abnimmt.

Geht es um Big Data, geht es in der Regel auch um das Hadoop Distributed File System (HDFS). HDFS wird immer mehr zum bevorzugten Tool, das Enterprise-Storage-Anwendern hilft, Big-Data-Probleme zu bewältigen. Dieser Artikel wirft einen genaueren Blick darauf, wie und warum HDFS zur primären Option wurde.

Wohin mit all den Daten?

Traditionelle Enterprise-Storage-Plattformen – Silos für Disk-Arrays und Magnetbänder – sind nicht dafür geeignet, Daten in Massen zu speichern. Rechenzentrums-Arrays sind viel zu teuer für die großen Datenmengen. Während das Magnetband zwar zum Speichern von Datenmassen geeignet und auch preiswert ist, dauert der Datenzugriff viel zu lange. Der Datenspeicher, der heute von Unternehmen gesucht wird, wird oft als Big Data Lake bezeichnet, und die häufigste praktische Umsetzung dieser Art von Datenspeicher ist Hadoop.

Entstanden in den Internetdatenzentren von Google und Yahoo, wurde Hadoop entwickelt, um hohe analytische Performance zu liefern – verbunden mit hochskalierbarem Storage und bei sehr geringen Kosten. Zwischen den Data Centers der großen Internetdienstleister und den Enterprise-Rechenzentren gibt es allerdings eine Kluft – bedingt durch Unterschiede im Management-Stil, den Ausgabeprioritäten, der Compliance und dem Risikovermeidungsprofil. So wurde HDFS ursprünglich nicht für eine langfristige Bereithaltung der Daten designt. Die Annahme war, dass Daten für MapReduce Batch-Jobs in ein verteiltes Cluster geladen und anschließend wieder entfernt werden – ein Prozess, der für aufeinanderfolgende Aufträge immer wieder wiederholt werden müsste.

Heute wollen Unternehmen aber nicht nur aufeinanderfolgende MapReduce-Jobs ausführen können. Sie möchten auch mehrere Anwendungen erstellen, die zum Beispiel Analytics mit den Daten, die durch Online Transaction Processing (OLTP) erzeugt wurden, auf dem Hadoop Distributed File System zusammenführen. Zudem wird für mehrere Arten von Analytics-Nutzern auch ein gemeinsamer Speicher benötigt. Zu den beliebtesten Anwendungen gehören Apache HBase für OLTP und Apache Spark und Storm für Data Streaming sowie Echtzeit-Analysen. Um diese Anforderungen zu erfüllen, müssen die Daten dauerhaft bereitgehalten werden, geschützt sein und für mehrere Benutzergruppen und für längere Zeit gesichert werden.

Die Hadoop Speicherlücke schließen

Aktuelle Versionen des Hadoop Distributed File Systems enthalten Storage-Management-Funktionen und Features, die mit dauerhaft bereitgestellten Daten umgehen können. Die Apache Open Source Community arbeitet kontinuierlich daran, HDFS zu verbessern und es kompatibler zu den Anforderungen von Enterprise-Rechenzentren zu machen. Allerdings fehlen immer noch einige wichtige Funktionen.

Für Administratoren besteht die Herausforderung deshalb vor allem darin, herauszufinden, ob der HDFS Storage Layer tatsächlich als akzeptabler Datenspeicher für die Hadoop Analytics-Plattform und seine zunehmende Zahl von Anwendungen und Nutzern dienen kann oder nicht. Zwar gibt es mehrere Projekte der Apache-Community, die für Entwickler sehr interessant sind und für entsprechende Aufmerksamkeit sorgen. Aber Anwender, die auf eine praktisch einsetzbare Hadoop-Speicherfunktionalität warten, werden oft auf künftige Releases vertröstet. Die aktuelle Liste der Hadoop-Storage-Lücken, die geschlossen werden sollten, beinhaltet folgende Punkte:

Ineffizienter und unzureichender Datenschutz und DR-Funktionen: Das Hadoop Distributed File System stützt sich auf die sofortige Generierung von replizierten Datenkopien (in der Regel drei) um Daten nach Plattenfehlern, Datenverlustszenarien, dem Abbruch der Verbindung und damit verbundene Ausfällen wiederherzustellen. Während es dieser Prozess einem Cluster erlaubt, einen Festplatten-Crash ohne einen Ausfall zu tolerieren, deckt er immer noch nicht ganz Datenverlustszenarien wie die Beschädigung von Daten ab.

In einer aktuellen Studie fanden Forscher an der North Carolina State University heraus, dass Hadoop zwar Fehlertoleranz bietet, aber „sich Datenkorruptionen ernsthaft auf die Integrität, Leistung und Verfügbarkeit von Hadoop-Systemen auswirken.“ Dieser Prozess führt auch zu einer sehr ineffizienten Nutzung von Speichermedien – ein kritisches Problem, wenn Benutzer ihre Daten für bis zu sieben Jahren im Hadoop-Cluster behalten möchten, wie es für die Einhaltung gesetzlicher Vorschriften erforderlich ist. Die Apache Hadoop Entwickler-Community versucht gerade für eine neue Version von HDFS, die Ende 2016 erscheinen soll, Erasure Coding als zweite Schicht für Daten zu implementieren, auf die weniger häufig zugegriffen wird.

HDFS fehlt auch die Fähigkeit, Daten synchron zwischen mehreren Hadoop-Clustern zu replizieren. Das ist ein Problem, weil die synchrone Replikation eine entscheidende Voraussetzung für die Unterstützung von DR-Operationen auf Produktionsebene sein kann. Und während die asynchrone Replikation unterstützt wird, gilt dies nicht für Datei-Inkonsistenzen über lokale/Remote-Cluster-Repliken, die im Laufe der Zeit entstehen können.

Die Unfähigkeit, Storage von Rechenressourcen zu trennen: HDFS verbindet Rechenleistung und Speicher, um die Lücke zwischen der Verarbeitung und Speicherung der Daten aus Performance-Gründen möglichst gering zu halten. Das führt zu einigen ungewollten Folgen für HDFS, wenn es als eine langfristige und dauerhafte Speicherumgebung verwendet wird. Um Speicherkapazität in Form von Datenknoten hinzuzufügen, muss ein Administrator auch Rechenressourcen hinzufügen, egal ob er sie braucht oder nicht. Und denken Sie daran, dass ein TB nutzbare Speicherkapazität bis zu drei TB entsprechen, nachdem Kopien gemacht wurden.

Die Ein- und Ausgabe von Daten kann länger dauern als der eigentliche Abfrageprozess. Einer der wichtigsten Vorteile bei der Verwendung von Hadoop für Analyseanwendungen im Vergleich zu herkömmlichen Data Warehouses liegt in der Möglichkeit, Abfragen für sehr große Mengen unstrukturierter Daten auszuführen. Dazu werden oft Daten aus dem aktiven Datenspeicher in den Big Data Lake kopiert, ein Prozess, der zeitaufwendig ist und die Netzwerkressourcen intensiv beanspruchen kann – abhängig von der Menge der Daten.

Für den produktiven Hadoop-Einsatz noch kritischer ist, dass dies zu inkonsistenten Daten führen kann und Benutzer der Anwendung dazu bringt, sich die Frage zu stellen, ob sie tatsächlich nur eine einzige Quelle abfragen wollen.

Alternative Hadoop Add-ons und Speichersysteme

Die Apache-Community entwickelt häufig Add-on-Projekte, um die Mängel von Hadoop zu beheben. Administratoren können zum Beispiel das Raft Distributed Consensus Protokoll verwenden, um Cluster-Ausfälle ohne erneute Berechnung zu umgehen, und DistCp für die regelmäßige Synchronisation von Clustern über weitere WAN-Strecken. Apache Falcon, ein Feed-Processing- und Management-System, kümmert sich dabei um den Lebenszyklus von Daten und das Management. Das Ranger-Framework zentralisiert wiederum die Sicherheitsverwaltung. Diese Add-ons müssen als getrennte Einheiten installiert, geschult und verwaltet werden, und jede von ihnen hat ihren eigenen Lebenszyklus, und erfordert Tracking und Aktualisierungen.

Um diese Probleme anzugehen, beginnen immer mehr Administratoren damit, Speichersysteme von Rechenzentren mit Hadoop zu integrieren – und zwar so, dass sie den erforderlichen Datenschutz, die Integrität, Sicherheit und Governance-Funktionen gewährleisten. Die Liste der „Hadoop-ready“-Speichersysteme umfasst unter anderem EMC Isilon und EMC Elastic Cloud Storage (ECS), die Hyper Scale-Out-Plattform von Hitachi, IBM Spectrum Scale und die Open Solution for Hadoop von NetApp.

Lassen Sie uns zwei dieser externen Hadoop-Speichersysteme im Detail betrachten, um den potenziellen Wert der alternativen Möglichkeiten zu verstehen.

EMC Elastic Cloud Storage

Elastic Cloud Storage (ECS) steht als vorkonfigurierte Hardware-/Software-Appliance oder als Software zur Verfügung, die auf Scale-Out-Racks von Commodity-Servern betrieben werden kann. ECS unterstützt Objektspeicherdienste ebenso wie HDFS und NFS v3 File Services. Objektzugriff wird über Amazon Simple Storage Service (S3), Swift, OpenStack Keystone V3 und EMC Atmos Schnittstellen unterstützt.

ECS nutzt Hadoop als Protokoll und nicht als Dateisystem und erfordert die Installation von Code auf Hadoop-Cluster-Ebene. Der ECS-Datenservice bietet Hadoop-Cluster-Knoten den Zugriff auf die unstrukturierten Daten mit einem Hadoop-kompatiblen Dateisystem. Es unterstützt sowohl in ECS Knoten eingebettete SSD- und Hybridspeicher-Festplatten und skaliert in einem einzigen Rack – abhängig von der Benutzerkonfiguration – bis zu 3,8 PB.

Daten- und Speicher-Management-Funktionen umfassen Snapshots, Journaling und Versionierung. Zudem implementiert ECS für den Datenschutz Erasure Coding. Dabei teilt man die Daten in Fragmente auf, die wiederum mit redundanten Datenstücken erweitert und kodiert werden. Danach speichert man diese über verschiedene Standorte verteilt zum Beispiel auf Festplatten, Storage-Knoten oder auch geografisch verteilten Speicherorten. Alle ECS Daten sind Erasure Coded, mit Ausnahme des Index und der Metadaten, wobei ECS drei Kopien der Daten behält.

Weitere Merkmale von ECS, die beim produktiven Unternehmenseinsatz wichtig sind:

Konsistente Schreibleistung für kleine und große Dateigrößen: Das Schreiben kleiner Dateien wird zusammengefasst, geschrieben wird in einer Operation, während der Zugriff auf große Dateien parallel über mehrere Knoten erfolgt.

Multi-Site-Zugang und Three-Site-Support: ECS ermöglicht den sofortigen Datenzugriff von jeder ECS-Site aus auf einen Multi-Site Cluster, unterstützt durch eine starke Konsistenz (Anwendungen werden mit der neuesten Version von Daten versorgt, unabhängig von ihrem Standort und Indizes über alle Standorte hinweg synchronisiert). ECS unterstützt auch primäre, Fern- und sekundäre Sites in einem einzigen Cluster, sowie asynchrone Replikation.

Einhaltung gesetzlicher Vorschriften: ECS ermöglicht es Administratoren, zeitbasierte Datenaufbewahrungsrichtlinien zu implementieren. Es unterstützt Compliance-Standards wie SEC Rule 17a-4.

Suche: Die Suche kann über benutzerdefinierte und System-Level-Metadaten ausgeführt werden. Die indizierte Suche mit Schlüsselwertepaaren ist über eine vom Benutzer geschriebene Schnittstelle möglich.

Verschlüsselung: Inline Data-at-Rest-Verschlüsselung mit automatisiertem Schlüssel-Management, bei dem der Schlüssel von ECS generiert wird, werden innerhalb des Systems ausgeführt.

IBM Spectrum Scale

IBM Spectrum Scale ist ein (bis in den Multi-PB-Bereich) skalierbares High-Performance-Speichersystem, das nativ mit Hadoop (kein Cluster-Level-Code erforderlich) integriert werden kann. Das IBM-Produkt implementiert eine einheitliche Storage-Umgebung, das heißt, es unterstützt sowohl datei- als auch objektbasierte Datenspeicherung in einem einzigen globalen Namensraum.

Für den Datenschutz und die Sicherheit bietet Spectrum Scale Snapshots des Dateisystems oder macht ein Backup auf ein externes Speicherziel (Backup-Appliance und/oder Band). Speicher-basierte Sicherheitsfunktionen beinhalten Data-at-Rest-Verschlüsselung und sicheres Löschen sowie LDAP/AD für die Authentifizierung. Synchrone und asynchrone Datenreplikation über LAN-, MAN- und WAN-Strecken mit Transaktionskonsistenz sind ebenfalls verfügbar.

Mehr zum Thema Apache Hadoop:

SQL-on-Hadoop bietet für Analytics zahlreiche neue Möglichkeiten.

Big-Data-Management mit dem Hadoop-Framework in Amazon Elastic MapReduce (EMR).

Big-Data-Management mit der Hadoop-Distribution von Hortonworks.

Big-Data-Management mit der Hadoop-Distribution von MapR.

Big-Data-Management und Analytics mit IBM BigInsights und Apache Hadoop.

Spectrum Scale unterstützt automatisches Storage Tiering, indem es Flash für leistungskritische und Multi-Terabyte große mechanische Festplatte für kostengünstige Kapazitäten einsetzt. Dabei werden die Daten automatisch und richtliniengesteuert zwischen den Speicherebenen verschoben. Als zusätzlicher Archivspeicher stehen Tapes zur Verfügung.

Richtliniengesteuerte Datenkomprimierung kann für jeweils eine Datei implementiert werden, was die Speichereffizienz um etwa das Doppelte verbessert und die Verarbeitungslast auf Hadoop Cluster-Knoten reduziert. Auch Mainframe-Anwender können Spectrum Scale in IBM z-Systems integrieren, die oft die Rolle entfernter Dateninseln spielen, wenn Hadoop eingeführt wird.

Ein Funke am Horizont

Auf Apache Spark (deutsch: Funke) als Plattform für Big Data Analytics laufen MapReduce-Anwendungen schneller als auf Hadoop. Aber wie Hadoop ist auch Spark eine Multi-Applikations-Plattform, welche die Analyse von Streaming-Daten ermöglicht. Der effizientere Code von Spark und seine In-Memory-Verarbeitungsarchitektur beschleunigen seine Leistung, obwohl auch Spark auf Standard-Hardware läuft und auf Open-Source-Code basiert. Im Gegensatz zu Hadoop kommt Spark allerdings nicht mit einem eigenen, persistenten Data Storage Layer, weshalb Spark am häufigsten auf Hadoop-Clustern mit HDFS implementiert wird.

Die zunehmende Bedeutung von Spark resultiert aus dem wachsenden Interesse an der Verarbeitung von Streams und Echtzeit-Analysen. Allerdings war das Hadoop Distributed File System ursprünglich auch nicht konzipiert, um als persistenter Datenspeicher für Streaming-Analytics-Anwendungen zu fungieren. Spark wird jedenfalls das Storage Performance Tiering für Hadoop noch attraktiver machen – ein weiterer Grund, Hadoop mit Enterprise Storage zu vereinen.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+ und Facebook!

Artikel wurde zuletzt im Juni 2016 aktualisiert

Pro+

Premium-Inhalte

Weitere Pro+ Premium-Inhalte und andere Mitglieder-Angebote, finden Sie hier.

Diskussion starten

Schicken Sie mir eine Nachricht bei Kommentaren anderer Mitglieder.

Mit dem Absenden dieser Daten erklären Sie sich bereit, E-Mails von TechTarget und seinen Partnern zu erhalten. Wenn Ihr Wohnsitz außerhalb der Vereinigten Staaten ist, geben Sie uns hiermit Ihre Erlaubnis, Ihre persönlichen Daten zu übertragen und in den Vereinigten Staaten zu verarbeiten. Datenschutz

Bitte erstellen Sie einen Usernamen, um einen Kommentar abzugeben.

- GOOGLE-ANZEIGEN

SearchSecurity.de

SearchNetworking.de

SearchEnterpriseSoftware.de

SearchDataCenter.de

Close