Aus der Big-Data-Welt nicht mehr wegzudenken

Hadoop 3.0: Weit jenseits der Batch-Verarbeitung

Melanie Feldmann

© Shutterstock / Katja Gerasimova

 

Fünf Jahre hat Hadoop von der Version 2.0 auf die 3.0 gebraucht. Andrew Wang, Release Manager von Apache Hadoop 3, spricht vom größten Release aller Zeiten des Open-Source-Projekts. Dementsprechend lang ist die Liste der Änderungen und neuen Features. Wie immer geht es um mehr Effizienz, Skalierbarkeit und Zuverlässigkeit.

Unterstützung für Erasure Coding in HDFS

Das Erasure Coding ist ein Verfahren, mit dem sich Daten dauerhaft speichern lassen, das im Vergleich zur Replikation platzsparender ist. Standardkodierungen wie Reed-Solomon (10,4) haben lediglich einen Overhead vom 1,4-fachen der Speichermenge, im Vergleich zum Overhead bei der Standard-HDFS-Replikation, der das dreifache an Platz braucht. Da Erasure Coding bei der Rekonstruktion zusätzlichen Overhead verursacht und meist Remote Reads durchführt, wird es eher für das Speichern selten abgerufener Daten verwendet. Benutzer sollten die Netzwerk- und CPU-Overheads der Erasure Codierung berücksichtigen, wenn sie dieses Feature einsetzen.

Neues zu YARN

Das YARN-Ressourcenmodell wurde verallgemeinert, um benutzerdefinierte, zählbare Ressourcentypen jenseits von CPU und Speicher zu unterstützen. So kann der Cluster-Administrator beispielsweise Ressourcen wie GPUs, Softwarelizenzen oder lokal angebundenen Speicher definieren. YARN-Tasks können dann entsprechend der Verfügbarkeit dieser Ressourcen eingeplant werden.

Mit bei Hadoop 3.0 dabei ist die Preview (Alpha 2) einer größeren Revision des YARN Timeline Service. YARN Timeline Service 2 soll die Skalierbarkeit und Zuverlässigkeit des Timeline Service verbessern. Die Einführung von Flows und Aggregation soll außerdem die Benutzerfreundlichkeit erhöhen. Entwickler sollen YARN Timeline Service 2 Alpha 2 testen und Feedback geben, um es zu einem vollwertigen Ersatz für Timeline Service 1.x zu machen. Es sollte aber noch nicht in Produktion zum Einsatz kommen. Weitere Informationen sind in der Dokumentation zu finden.

Neues Shell-Skript

Die Hadoop-Shell-Skripte wurden umgeschrieben, um Fehler zu beheben und einige neue Funktionen einzubauen. Obwohl auf Kompatibilität geachtet wurde, warnen die Entwickler davor, dass einige Änderungen bestehende Installationen beeinträchtigen könnten. Inkompatible Änderungen sind in den Release Notes dokumentiert. Weitere Details findet man in der Dokumentation des Unix Shell Guide. Power-User werden sich auch über die Unix-Shell-API-Dokumentation freuen, die einen Großteil der neuen Funktionalität beschreibt, insbesondere in Bezug auf die Erweiterbarkeit.

Abhängigkeiten in ein JAR

Das hadoop-client-Maven-Artefakt Versionen 2.x bringt die transitiven Abhängigkeiten von Hadoop auf den Klassenpfad einer Hadoop-Anwendung. Dies kann problematisch sein, wenn die Versionen dieser transitiven Abhängigkeiten mit den in der Anwendung verwendeten Versionen kollidieren. Deswegen gibt es nun neue hadoop-client-api– und hadoop-client-runtime-Artefakte, die die Abhängigkeiten von Hadoop in ein einziges JAR holen. Dadurch wird verhindert, dass die Abhängigkeiten von Hadoop auf den Klassenpfad der Anwendung übertragen werden.

Opportunistic Containers und Distributed Scheduling

Eine Abwandlung des Execution Type wurde eingeführt. Damit können Anwendungen nun Container mit dem Execution Type Opportunistic anfordern. Container diesen Typs können zur Ausführung auf einem NodeManager eingeplant werden, auch wenn zum Zeitpunkt der Terminierung keine Ressourcen zur Verfügung stehen. In einem solchen Fall kommen diese Container am NM in eine Queue und warten darauf, dass Ressourcen für den Start zur Verfügung stehen. Opportunistic Container haben eine geringere Priorität als die Guaranteed Container und werden daher bei Bedarf zurückgehalten, um Platz für diese zu schaffen. Dies sollte die Auslastung des Clusters verbessern. Opportunistic Container werden standardmäßig vom zentralen Release Manager (RM) allokiert, aber nun ist es auch möglich, Opportunistic Container von einem verteilten Scheduler allokieren zu lassen, der als AMRMProtokoll Interceptor implementiert ist.

Unterstützung für mehr als zwei NameNodes

Die anfängliche Implementierung der Hochverfügbarkeit von HDFS NameNode sah einen einzigen aktiven NameNode und einen einzigen Standby NameNode vor. Durch die Replikation von Edits auf ein Quorum von drei JournalNodes ist diese Architektur in der Lage, den Ausfall eines beliebigen Knotens im System zu tolerieren. Einige Deployments erfordern jedoch einen höheren Grad an Fehlertoleranz. Dies wird durch eine neue Funktion ermöglicht, die es Benutzern erlaubt, mehrere Standby-NameNodes zu betreiben. Zum Beispiel: Bei drei NameNodes und fünf JournalNodes ist der Cluster in der Lage, den Ausfall von zwei Knoten zu tolerieren.

Eine Übersicht über die wichtigsten Änderungen finden sich hier. Die vollständigen Release Notes hier.

Verwandte Themen:

Geschrieben von
Melanie Feldmann
Melanie Feldmann
Melanie Feldmann ist seit 2015 Redakteurin beim Java Magazin und JAXenter. Sie hat Technikjournalismus an der Hochschule Bonn-Rhein-Sieg studiert. Ihre Themenschwerpunkte sind IoT und Industrie 4.0.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: