Die flinke Feder

Verteiltes Rechnen à la carte

Bernd Fondermann

Endlich sitzt man am Tisch im Restaurant, der Magen knurrt. Dann kommt die Speisenkarte, man schlägt sie auf – und wird erschlagen von der schieren Auswahl. Seite über Seite mit den verschiedensten bekannten und unbekannten Gerichten in unterschiedlichsten Varianten. Ähnliches widerfährt demjenigen, der eine NoSQL-Datenbank auswählen will. Jedes der Produkte hört sich in der Beschreibung so verführerisch an wie die blumig-umschreibenden Namen einer chinesischen Mahlzeit. Doch was steckt genau dahinter? Für welchen Magen welche Speise? MongoDB, CouchDB, Hypertable, memcached, Cassandra, Riak, Voldemort und wie sie alle heißen. Sie verheißen Leibesfülle durch Skalierbarkeit, können BigData verdauen und ihre APIs seien für den Entwickler problemlos zu schlucken. Trotzdem – die Geschmäcker sind ja wohlweißlich verschieden – schlägt dann die Wahl nachträglich manchem auf den Magen.

Bei den relationalen Datenbanken passiert einem das schon lange nicht mehr. Die meisten haben bereits ihre Leib-und-Magen-DB gefunden, müssen die Karte gar nicht mehr konsultieren, um dem Lizenzkellner die Nummer 11g oder 9i zuzurufen, ordern routiniert „MySQL mit extra innoDB“ oder bestellen gleich eine gut abgehangene Sybase oder DB/2. Doch SQL macht längst nicht mehr jeden satt.

Auf der ersten BigDataCon, die kurz nach Ostern parallel zur JAX 2012 stattfand, wurde deutlich, dass vielen Teilnehmern noch nicht klar ist, ob sie den NoSQL-Speicher, der auf dem Teller am Nebentisch so lecker dampfte, auch mal ausprobieren sollen. Und ob man ihn besser mit Messer und Gabel oder mit Stäbchen isst. Das kann man niemandem verdenken, denn alleine die Zutaten sind für viele noch recht exotisch: CAP-Theorem, Quorum und Eventual Consistency findet sich in der gutbürgerlich-relationalen Küche nicht im Gewürzschrank. Doch in den Gesprächen am Rande hat sich der eine oder andere NoSQL-Gourmet schon geoutet. Und es wurde klar: Mit dem Kochen hapert es noch, jede Zubereitung will erstmal geübt sein.

Zugegebenermaßen bin ich in der NoSQL-Küche nicht besonders experimentierfreudig. Cassandra ist mir beispielsweise geschmacklich zu komplex, mit seinen Columns, Column-Families, Super-Columns und Super-Column-Families. Andererseits empfinde ich viele Key-Value-Stores als zu wenig würzig und abwechslungsreich. Irgendwo dazwischen habe ich mich auf Apache Hadoop festgelegt.

Mittlerweile wuchert Hadoop selber wie ein Hefekuchen. Über die verschiedenen Zutaten wurde an dieser Stelle in den letzten Monaten immer mal wieder berichtet. Doch jetzt haben die Hadoop-Köche einen großen leeren Topf aufgesetzt und fangen ganz neu an. Hadoop Numero Zwo ist derzeit in Entwicklung, derzeit als branch-2 im Repository [1]. Hadoop 2 wird nicht nur eine verbesserte Architektur seines verteilten Filesystems bringen. Vor allem werden die Ablaufumgebungen für Jobs wesentlich weiterentwickelt. Aus dem bisherigen MapReduce-Framework wird ein universelles Anwendungsframework für verteiltes Rechnen. MapReduce ist auch immer noch als Topping erhältlich. Bisher waren Hadoop und MapReduce untrennbar miteinander verbunden. Damit musste jede Anwendung, die auf Hadoop ausgeführt werden sollte, als Mapper und Reducer implementiert werden. Um das zu ändern, wird die bisherige MapReduce-Umgebung aufgebohrt und verallgemeinert. Die neue Architektur heißt YARN [2] und befindet sich bereits seit Längerem in Entwicklung.

In nächster Zeit werden also neue Application-Flavors zu Hadoop hinzugefügt werden wie Joghurt-Sorten in der Kühltheke. Eines davon wird Apache Giraph sein. Mit Giraph ist es möglich, Graphen in Hadoop abzubilden und schrittweise zu verarbeiten. Graphen helfen beispielsweise beim Rechnen mit Links auf Webseiten und sozialen Netzen. Giraph läuft bereits jetzt auf Hadoop, indem es auf seine Algorithmen auf Mapper abbildet, wird für Hadoop-2 aber eine native Implementierung bekommen. Bereits heute werden MapReduce-Jobs für komplexere Berechnungen hintereinandergeschaltet. Dies wird mit YARN effizienter und schneller möglich sein, und somit profitiert MapReduce selbst auch von den kommenden Veränderungen. Insgesamt zielt man darauf ab, neben schwerfälliger Batch-Verarbeitung auf Hadoop auch agiles Data Processing zu ermöglichen, das viel näher an „Realtime“ als heute ist. Und dabei rede ich nicht nur vom doch recht klassisch-tabellenartigen Ansatz, den Apache HBase [3] ja heute schon bietet. Ein weiterer Anwendungsbereich von Hadoop werden vielmehr Message Passing Interfaces (MPI) nach Open MPI [4] sein [5]. Auch verteiltes Stream Processing nach dem Storm-Framework [6] würde man gerne auf Hadoop sehen.

Dieser Artikel kann nur einen Vorgeschmack auf die zukünftige Fusion-Küche namens Hadoop bieten. Die Auswahl der Data-Processing-Rezepte wird nicht einfacher werden, aber das Grundrezept wird immer häufiger Apache Hadoop sein.

Bernd Fondermann (bernd@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 Big-Data-Hosting-Service an.
Geschrieben von
Bernd Fondermann
Kommentare

Schreibe einen Kommentar

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