Drahtlose Netzwerke sind überall: Zu Hause, im Café und in der Firma. Im Gegensatz zu Kabelnetzen verliert der Admin bei WLANs allerdings schnell die ... (mehr)

Big Data: eine Frage der Flexibilität

Zu den beinahe unverwüstlichen Mythen, die sich in der IT-Industrie halten, zählt die Überzeugung, dass Big Data nur für Großunternehmen anwendbar oder bezahlbar sei. Der Mittelstand ist fast schon selbstverständlich fest davon überzeugt, dass ohne Datenbestände im Petabyte-Bereich ohnehin nicht von Big Data die Rede sein kann. Nichts könnte weiter von der Wahrheit entfernt sein. Auch wenn es sich "nur" um Datenmengen von 10 oder 50 Terabyte handelt, bietet sich der Einsatz von Hadoop an. Bei Big Data handelt es sich nicht um eine bestimmte Datenmenge, sondern um das Fehlen einer Datenstruktur.

Eigentlich besteht die Frage gar nicht darin, ob sich ein Unternehmen "bereits" für Big Data qualifiziert. Viele Firmen haben allerdings zuvor noch eine ganz andere Herausforderung: ein Daten-Management-Problem. Ein unternehmenseigenes Data Warehouse stößt sehr schnell an die Kapazitätsgrenzen einer einzelnen Maschine. So sind zunächst isolierte Datensilos entstanden. Wer aus ihnen umsetzbare Erkenntnisse gewinnen möchte, braucht ein verteiltes Cluster-Dateisystem wie HDFS, das mit den Anforderungen mitwächst, und ein Framework wie Hadoop.

Für den Mittelstand gibt es keine sachlichen oder finanziellen Gründe, um auf Big Data zu verzichten. Zugegeben: zu den lautstärksten Benutzern von Hadoop gehören einige der größten Namen aus der IT-, Social-Media- und Unterhaltungsindustrie, darunter Amazon Web Services, AOL, Apple, eBay, Facebook, Netflix und HP. Doch vor allem für kleinere Firmen mit schmalen Budgets kommt Hadoop 2.2.x wie gerufen: einfach zu programmieren, kostenfrei, plattformunabhängig und offen.

Die größte Herausforderung beim Einsatz von Hadoop ist keinesfalls ein dickes Finanzpolster, sondern fehlendes Know-how. Im ersten Schritt gilt es, sich die günstige Datenverarbeitung und robuste Datensicherung mit Hadoop zunutze zu machen. Erst nachdem das Unternehmen damit begonnen hat, die Früchte dieser Kostensenkungen zu ernten, kann es die eigenen Aktivitäten rund um die Datenanalyse ausbauen. Erst in dieser Phase macht es Sinn, Datenwissenschaftler zu beschäftigen, damit sie mithilfe von Datenanalyselösungen auf der Basis von Hadoop anspruchsvolleren Fragen nachgehen.

MapReduce NextGen

Die Änderungen in Hadoop 2.2.0 sind tiefgreifend und durchdacht. Den Innovationen liegt die Modularisierung der Engine zugrunde. Dieser gewagte Schritt soll das Hadoop-Ökosystem um Plug-ins und andere Erweiterungen bereichern. Er verspricht nebenbei auch zusätzliche Flexibilität für den Hadoop-Administrator. So kann der Admin einige eingebaute Algorithmen bereits heute durch externe Module ersetzen, um in den Genuss erweiterter Funktionalität zu kommen. Das betrifft zum Beispiel Shuffle und Sort. Diese Module lassen sich sogar parallel und zusammern mit den eingebauten Algorithmen nutzen.

Zu den wichtigsten Neuerungen in der Version 2.2.0 zählt die Einführung von YARN (Yet Another Resource Negotiator) als optionalen Ersatz für MapReduce. MapReduce in Hadoop 1.x ( Abbildung 5 ) war nicht für alle Workloads optimal geeignet. Es läuft dort zur Höchstform auf, wo sich die Aufgaben klar aufteilen und parallelisieren lassen. Viele der Unzulänglichkeiten von MapReduce sind mit YARN passé.

Abbildung 5: Zum Vergleich: In Hadoop 1.x werden die vorhandenen Ressourcen des Clusters hart partitioniert, was eine suboptimale Nutzung der verfügbaren Kapazitäten zur Folge hatte. Jobs, die sich nicht per map und reduce aufteilen ließen, liefen entsprechend langsam ab.

Bei YARN handelt es sich um eine Weiterentwicklung von MapReduce, MapReduce Version 2 (kurz: MRv2). Der Name wurde im Übrigen nicht rein zufällig gewählt. Die Aussprache von "YARN" ähnelt dem englischen Wort "yearn"; dieses bedeutet so viel wie "etwas begehren".

YARN setzt direkt auf HDFS auf und übernimmt die Rolle eines verteilten Betriebssystems zur Ressourcen-Verwaltung für Big-Data-Applikationen ( Abbildung 4 ). Dank YARN können Sie mit Hadoop 2.2.x interaktive Workloads, Echtzeit-Workloads und automatisierte Workloads ineinander verweben. Das Beste daran: YARN ist rückwärtskompatibel zu MapReduce auf der API-Ebene (hadoop-0.20.205) und verbessert nebenbei die Kompatibilität von Hadoop mit anderen Projekten der Apache Software Foundation. Wer unbedingt darauf besteht, MapReduce in der alten Ausführung zu nutzen, kann es jetzt als ein Modul laden. Das sollte allerdings nicht nötig sein, denn MapReduce-Applikationen sind binärkompatibel zwischen beiden Generationen von Hadoop.

Big-Data-Applikationen mit Unterstützung für YARN

Aus der effizienten Ressourcen-Verwaltung durch YARN kann eine Vielzahl von Applikationen bereits heute einen Nutzen ziehen ( Abbildung 3 ). Die Liste YARN-optimierter Big-Data-Applikationen beinhaltet unter anderem Apache Giraph (Visualisierung), Apache Hama (BSP), Apache Hadoop MapReduce (Stapelverarbeitung von Daten), Apache Tex (Stapelverarbeitung und interaktive Jobs im Arbeitsspeicher), Apache S4/Samza/Storm (Echtzeitverarbeitung von Datenströmen), Apache Spark (iterative und interaktive Applikationen), Elastic Search, Cloudera Llama (eine YARN-Implementierung von Impala einer hybriden Ad-hoc-Abfrage-Engine mit Unterstützung für den SQL-Dialekt HiveQL), DataTorrent (Datenanalyse), HOYA (HBase auf YARN) und Red Point (Datenverwaltung).

Abbildung 3: Applikationen mit Unterstützung für YARN in Hadoop 2.x: MapReduce ist jetzt ein Modul im User-Space, binärkompatibel mit Altlasten-Applikationen aus Hadoop 1.x.
Abbildung 4: Die Architektur von Hadoop 2.x: Ressourcen-Verwaltung durch YARN basiert auf logischen Einheiten der sogenannten Ressourcen-Container; das Anfordern von Ressourcen ist nun von der Applikationslogik getrennt.

Die wichtigste Änderung in YARN gegenüber dem klassischen MapReduce ist die Zuteilung der zwei Funktionen des JobTrackers – der Ressourcen-Verwaltung und der Zeitverwaltung/Workload-Überwachung – zu zwei separaten Daemons: dem globalen ResourceManager (RM) und dem Job-spezifischen ApplicationMaster (AM).

Der ResourceManager besteht wiederum aus zwei Grundkomponenten: dem sogenannten Scheduler und dem ApplicationsManager. Der Scheduler verantwortet die Zuweisung von Ressourcen zu den verschiedenen laufenden Applikationen, fühlt sich aber für die Überwachung der Workloads nicht zuständig. Der Scheduler berücksichtigt sowohl den Ressourcen-Bedarf der einzelnen Applikationen als auch die Einschränkungen der Kapazitäten des Clusters.

In der aktuellen Version kann der Scheduler leider nur eine Ressource verwalten: den Arbeitsspeicher. In künftigen Versionen von YARN soll es möglich sein, CPU-Zyklen, den Massenspeicher und die Netzwerkbandbreite des Clusters einzelnen Applikationen zuzuteilen.

Die Zuteilung von Ressourcen erfolgt durch das Partitionieren des sogenannten Ressourcen-Containers, einer virtuellen Compute-Einheit in einem Knoten des Clusters. Ein Knoten kann im Übrigen über mehrere solche Container verfügen. Der ApplicationsManager (die zweite Grundkomponente des ResourceManagers neben dem Scheduler) nimmt Workload-Aufträge entgegen. Der ApplicationsManager initiiert hierzu die Einrichtung des ersten Ressourcen-Containers für den ApplicationMaster und startet diesen (beziehungsweise startet diesen nach einem Absturz neu). Der Applikations-gebundene ApplicationMaster fordert die benötigten Ressourcen-Container vom Scheduler an (der Scheduler ist Teil des ResourceManagers), und beginnt, sie zu überwachen.

HDFS kennt zwei Typen von Servern oder Clusterknoten: Namenknoten (NameNodes) und Datenknoten (DataNodes). NameNodes verwalten Metadaten; die eigentlichen Datenblöcke werden auf den DataNodes vorgehalten. Für jeden Knoten des Clusters (also eine einzelne Maschine) zeichnet sein eigener NodeManager verantwortlich. Dieser überwacht die Verwendung der Ressourcen der Container und berichtet an den ResourceManager/Scheduler, was auf dem jeweiligen Knoten gerade vor sich geht. Die neue Architektur ermöglicht erhebliche Kosteneinsparungen ( Abbildung 5 ). Yahoo schätzt die erzielten Verbesserungen der Node-Auslastung auf 60 bis 150 Prozent pro Tag. Yahoo testete YARN mit 365 PByte an Daten mit 400 000 Jobs auf 40 000 Cluster-Nodes mit einer Gesamtrechenzeit von 10 Millionen Stunden. Eine Hochverfügbarkeitsimplementierung des YARN-ResourceManagers ist für eine künftige Version geplant.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023