w26M2

Big-Data-Technologien – Wissen für Entscheider
MapReduce-Programmierung als Anwendungs-
Hemmnis
Als problematischer Blocker für die Anwendung von
Hadoop hat sich bereits in den Kinderjahren dieser Technologie
die Notwendigkeit gezeigt, die Verarbeitungs-
Jobs in Java programmieren zu müssen. Dies setzt neben
guten Entwicklerkenntnissen ein tiefes Verständnis der
Hadoop-Arbeitsweise voraus.
Komponenten verfolgen den Ansatz, durch einfache,
schnell erlernbare Sprachen den Zugang zu Hadoop
zu erleichtern und problemorientiert – befreit von den
Details des MapReduce-Frameworks – arbeiten zu können.
Die Jobs müssen zwar weiterhin in einer Programmiersprache
formuliert werden, der Erfolg der Statistiksprache
R und der Office-Makrosprache VBA zeigen aber,
dass das kein Hinderungsgrund für eine weite Verbreitung
sein muss.
In der Praxis stellt sich immer wieder die Frage, ob ein
bestimmtes Problem in einem Hadoop-Cluster effektiv
gelöst werden kann. Ohne auf theoretische Aspekte der
Berechenbarkeit im MapReduce-Paradigma einzugehen,
lässt sich die allgemeine Antwort umgangssprachlich so
formulieren: »Prinzipiell lassen sich alle (berechenbaren)
Aufgaben in Hadoop lösen – man muss nur den passenden
Java-Programmcode dazu finden!«
Die Algorithmen müssen also in einem speziellen
MapReduce-Stil formuliert werden, was für bestimmte
Aufgabenstellungen eine durchaus anspruchsvolle Aufgabe
darstellt. Ein typisches Beispiel dafür ist die Implementierung
einer INNER JOIN-Operation, wie man sie aus
relationalen Datenbanksystemen kennt und wie sie in der
Hadoop-Batchverarbeitung sehr häufig vorkommt. Was
im deklarativen Datenbank-Standard SQL ohne nachzudenken
direkt ausgedrückt werden kann, muss in einem
MapReduce-Programm durch diverse Zeilen Java-Code
beschrieben werden – dies beinhaltet die Möglichkeit von
Fehlern oder eines ineffizienten Jobs. Der Entwickler ist
vollständig selbst für die Optimierung zuständig.
Sicherlich stellt allein schon die Verwendung einer
komplexen Hochsprache, wie Java oder C#, in einer
Programmierumgebung wie Eclipse oder Visual Studio
für Geschäftsanwender (wie z. B. Business Analysten)
eine zu hohe Hürde dar. Um die Schwelle für die Adaption
von Hadoop zu senken, war es also notwendig, die
Komplexität der Erstellung der MapReduce-Jobs deutlich
zu vermindern. Genau aus diesem Grund wurden die
Apache-Projekte Pig und Hive ins Leben gerufen. Beide
Pig als prozedurale Hadoop-Erweiterung
Pig wurde ursprünglich im Jahre 2006 bei Yahoo! entwickelt,
um auch Nicht-Programmierern die Arbeit mit
Hadoop zu ermöglichen. Daten-Analysten ist es mittels
der mit Pig verbundenen Sprache Pig Latin möglich,
eigene Skripte zu entwickeln, ohne die Low-Level-Java-
Programmierung zu verwenden. Pigs Anwendungsbereiche
sind die Datenintegration und Manipulation. Pig Latin
ist eine Datenfluss-Programmiersprache, mit der sich
Verarbeitungs-Pipelines beschreiben lassen, die dann vom
Pig Framework in MapReduce-Jobs überführt werden. Der
Begriff Pig ist übrigens kein Acronym, sondern eher eine
Metapher. Die folgenden Kernsätze aus der »Pig Philosophy«
machen klar, worum es geht:
• »Pigs eat anything« – mit Pig lassen sich beliebige
Daten verarbeiten;
• »Pigs live anywhere« – Pig kann innerhalb und außerhalb
von Hadoop Clustern verwendet werden;
• »Pigs are domestic Animals« – Pig ist einfach in der
Anwendung;
• »Pigs fly« – Pig kann Daten schnell verarbeiten.
Dass die Arbeit mit Pig Latin tatsächlich recht einfach
ist, soll das kurze Pig Latin-Skript in Abbildung 11
verdeutlichen 57 .
Vermutlich wird jemand, auch wenn er nie zuvor mit der
Pig Latin-Programmiersprache zu tun hatte, mehr oder
weniger auf Anhieb verstehen, worum es in diesem Beispiel
geht: Rohdaten werden aus einem HDFS-Verzeichnis
57
Vgl.: Wikipedia-Eintrag zu Pig: http://en.wikipedia.org/wiki/Pig_(programming_tool)
49