Die flinke Feder

Apache Hadoop: Elefantitis

Bernd Fondermann

Der Elefant ist das Maskottchen von Apache Hadoop. Und da lassen sich die meisten Projekte neben, vor und um Hadoop herum nicht lumpen und haben in ihrem Logo irgendwas mit Elefant…oder Schwein. Einige wenige sind aber noch so jung, dass sie eines Logos noch entbehren.

Die Situation rund um das Hadoop-File-System und MapReduce ist vielleicht ein wenig mit der Hochzeit von J2EE zu vergleichen: Eine Vielzahl von Spezifikationen brachte eine Reihe von Produkten hervor. Zusätzlich tummelten sich weitere Tools, Ergänzungen und Servererweiterungen in diesem Bereich. Damals neu und aufregend, heute etabliert (Hibernate) oder unbedeutend (JCA).

Obwohl es sich um eine ganz eigene Technologie handelt, müssen auch Hadoop-Server installiert, konfiguriert, gewartet und überwacht werden. Code muss getestet und deployt werden. Ereignisse wollen geloggt, isoliert und analysiert sein. Daten werden importiert, exportiert, dupliziert und repliziert. Und für alles gibt es speziell für Hadoop erstellte Werkzeuge. Klassische Persistenztools und SQL sind für Hadoop nicht geeignet. Es gibt die verschiedensten Stellen, um solche Hilfsmittel zu finden: vollwertige Apache-Projekte (wie hbase.apache.org), den Apache Inkubator, Github Repositories. Einige Tools wurden von den Haupt-Hadoop-Kontributoren Yahoo! (neuerdings mit seinem Spin-off Hortonworks), Cloudera oder Facebook intern entwickelt und dann erst in Open Source überführt. Es ist derzeit fast unmöglich, eine vollständige Übersicht zu geben, da allein im Inkubator innerhalb weniger Wochen mehrere Hadoop-Tools eingebracht worden sind. Im Folgenden versuche ich, die zentralen Projekte herauszuarbeiten. Mit einigen habe ich mich im Rahmen dieser Kolumne schon beschäftigt [1].

Lass mich rein, lass mich raus

Was ist ein Dateisystem ohne Daten? Nichts. Was ist schwieriger als Datenmigration? Nichts. Nun, Hadoop bietet eine einfache Shell [2], mit der man à la Unix-Prompt Dateien nach und von HDFS transferieren kann. Sie bietet auch ein distcp [3], die Dateien nicht nur linear, sondern auch blockweise parallel kopieren kann. Sqoop bietet weitergehende Unterstützung, auch für relationale Datenquellen. Dabei wurde Sqoop ursprünglich als Add-on unter dem Hadoop-Projektmantel entwickelt, dann zu Github abgeschoben und ist jetzt vorerst im Inkubator gelandet [4].

Zwei Wege geradeaus

Es gibt zwei Wege, um zum MapReduce-Job zu kommen: selber programmieren oder ein Tool wie Apache Pig [5] oder Apache Hive [6] nutzen. Sie bieten jeweils eigene spezifische Sprachen an, deren Anweisungen in MapReduce-Jobs kompilieren. Pig ist sehr imperativ und offen für Erweiterungen. Hive ist so weit wie möglich an SQL angelehnt und spricht Umsteiger mit Erfahrungen in relationalen Datenbanken an. Auch Cascading [7] bietet eine Data-Processing-Abstraktionsschicht um MapReduce herum an. Es ist auch eines der wenigen Tools, das nicht Apache-, sondern GPL-lizensiert ist. Selbst in Java programmierte MR-Jobs lassen sich mit MRUnit [8] auch ohne Verteilung im Cluster effektiv testen.

Schreib- und Lesestärke

Gerade BigData will effizient gespeichert werden. Der Nachteil gegenüber der relationalen Datenbank ist, dass das vorherrschende Datenformat der Byte Array ist. Für die Serialisierung und Schematisierung von Datenstrukturen muss man also selber sorgen. Im Fall von Textfiles ist das kein Problem. Die Ablage von Objekten und Bäumen von Objekten will aber gut geplant sein. Dafür steht das Serialisierungsframework Apache Avro [9] bereit. Es kann Daten plattform- und sprachunabhängig serialisieren. Dabei ist es sehr effizient und auf das lineare Lesen ausgerichtet. Eine Alternative zu Avro ist Apache Thrift [10].

Alles unter Kontrolle

Der heimliche Strippenzieher im Hintergrund ist Apache Zookeeper [11]. Es dient dazu, dass ein Cluster als Ganzes eine Entscheidung treffen kann, ohne dass ein Single Point of Failure (SPOF) existiert. Folgende Entscheidungen, auch Quorum genannt, sind zu treffen: Gemeinsam eine zentrale Instanz bestimmen und auch einen Ersatz finden, für den Fall, dass diese ausfällt (Failover). Oder den Abschluss einer Transaktion bestätigen. Oder den Wert einer globalen Variablen feststellen. Zwischen den Teilnehmern am Zookeeper-Cluster wird ständig über solche Ereignisse abgestimmt. Die Ergebnisse werden in einer schlanken Baumstruktur abgelegt, die einem Dateisystem ähnlich ist. Es ist allerdings nur so klein, dass es von sämtlichen Zookeeper Nodes ständig in Gänze im RAM gehalten werden kann. Noch wird Zookeeper von Hadoop selber nicht verwendet, aber Apache Cassandra, Apache HBase und auch Apache Solr tun das schon. Angesichts der Tatsache, dass Namenode und Jobtracker noch SPOFs sind, ändert sich das hoffentlich schon bald.

Für Datenfortgeschrittene

Spezielle Anwendungen für Hadoop stellen Hama [12] (Apache Incubator) und Apache Mahout [13] dar. Große Matrizen, die viele Nullen enthalten, also schwach besetzt sind, spielen bei vielen mathematischen Problemen eine Rolle, zum Beispiel bei Optimierungsproblem. Hama möchte beim Rechnen mit solchen Matrizen helfen und baut dabei auf Hadoop. Mahout bearbeitet das besonders interessante Feld des Machine Learnings, das gerade auf vielen Anwendungsfeldern im Vormarsch ist, sei es für Empfehlungs-Engines oder für das Aufspüren von „ähnlichen“ Daten, beispielsweise bei der Bilderkennung.

Sammelwut

Viele Anwender nutzen Hadoop für das Speichern von Daten, die rund um den IT-Betrieb anfallen, also als Datensenke oder gar Ersatz für Ganglia und Co. Dazu stehen Chukwa [14] und Flume [15] bereit, beide brüten noch im Apache Inkubator. Und beide versenken ihre Daten in HBase. Zusätzliche Komponenten, so genannte Agents, werden auf allen Rechnern gestartet, die als Datenquelle fungieren und die eingefangenen Werte an Datenkollektoren weiterleiten, die schließlich die Speicherung vornehmen. In diesem Zusammenhang sei auch OpenTSDB [16] genannt, das speziell auf Zeitreihen optimiert ist. Alle drei Tools bieten grafische Oberflächen für die Abfrage an.

BigData-Verkleinerung

Auch bei BigData möchte man, dass gespeicherte Daten möglichst wenig Platz belegen. Komprimierung und Dekomprimierung brauchen CPU und damit Zeit. Da Hadoop Files in Blöcke gesplittet auf verschiedene Rechner verteilt werden, ist eine blockweise Komprimierung wünschenswert, um MapReduce optimal damit füttern zu können. Zu vermeiden ist auf jeden Fall Netzwerktransfer nur zum Zwecke des Auspackens und zu viel CPU-Last. Den besten Kompromiss zwischen den Faktoren Verdichtung und Rechenzeit scheinen die Algorithmen aus der Lempel-Ziv-Familie [17] in verschiedenen Varianten zu bieten. Hier gibt es Bibliotheken, die Hadoop hinzugefügt werden können. Auf Github liegt dafür beispielsweise hadoop-lzo [18] und lzf4hadoop [19] bereit.

Wie die Jungfrau zum Cluster

Amazon bietet mit Elastic MapReduce den Cluster für zwischendurch. Man will ihn schnell hochziehen und auch wieder loswerden, sonst wird’s teuer. Apache Whirr [20 (derzeit)], [21 (zukünftig)] bietet dafür eine Lösung an; ein Projekt, das dem Inkubator erst frisch entschlüpft ist. Ebenfalls im Incubator befindet sich auch Ambari, ein Ei, das es noch zu legen gilt. Es gibt noch keinen Code dazu und auch keine Website. Laut Projekt-Proposal soll es so etwas wie das zentrale Managementsystem über den Hadoop Stack werden, inklusive Upgrades. Das klingt wirklich vielversprechend, sodass ich mich als Mitentwickler eingeklinkt habe und hoffentlich bald Näheres über das Projekt sagen kann.

Fazit

Ähnlich wie ein Betriebssystemkernel mit Dateisystem bietet Hadoop nur die Grundlagen für eigene Anwendungen. Alles darüber hinaus, vom Management, über eine Datenbank bis zur speziellen Anwendung, muss man sich erst zusammensuchen oder gar selber programmieren. Dazu kommt, dass die meisten Tools sich noch in Entwicklung befinden. Beinahe wöchentlich landen im Apache Incubator Vorschläge für neue Projekte; mehr als man evaluieren kann. Daran wird klar, wie jung das Feld BigData ist. Voraussichtlich wird sich in den nächsten Jahren auch die Toollandschaft konsolidieren, und so können Beobachter der Szene leichter Empfehlungen geben.

Bernd Fondermann (bernd[at]zillion-one.com) ist freiberuflicher Softwarearchitekt und Consultant in Frankfurt am Main und Member der Apache Software Foundation. Er beschäftigt sich mit innovativen Open-Source-Technologien wie Apache Hadoop oder Lucene und bietet unter zillion-one.com einen BigData Hosting Service an.
Geschrieben von
Bernd Fondermann
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.