Kolumne: Die flinke Feder

Daten sind Schweine

Bernd Fondermann

„Normalisiert“. Dieses kleine Wörtchen hat es in sich. Es beschreibt die Annäherung an eine Utopie. Nämlich, dass man keinerlei Redundanzen in seinen Daten hat. Mehrfaches Ablegen derselben Information kostet Speicher; ein Argument, was vor einigen Jahren noch schwerer wog als heute. Außerdem erleichtert Normalisierung das maschinelle Verarbeiten von gleichen Informationen. Natürlich ist uns Menschen klar, dass „E-Mail“, „E-Mail-Adresse“ und „Mailadresse“ alles dasselbe bedeutet, zumindest höchstwahrscheinlich. Kollege Computer ist davon wesentlich schwerer zu überzeugen. Deswegen wird man aus diesen Varianten eine einzige zur Norm bestimmen und nur diese verwenden. Hoffentlich.

Bernd Fondermann auf der BigDataCon

Bernd Fondermann können Sie auf der JAX / BigDataCon live erleben:

Apache Hadoop: Past, Present, Future

17.04.2012 | 10:00 – 11:15


Aus dem exotischen Open-Source-Projekt ist ein Ökosystem an Projekten, Produkten und Distributionen geworden. Dabei die Übersicht zu behalten, fällt schwer. Der Vortrag gibt einen Überblick über aktuelle Entwicklungen rund um Hadoop und Big Data. Verschiedene Tools und Libraries werden kurz vorgestellt und bewertet. Ein Ausblick auf neue Features und Trends rund um den Big-Data-Platzhirsch wird gegeben.

Blaue oder rote Pille: SQL oder MapReduce?

17.04.2012 | 15:15 – 16:15


Big Data und NoSQL sorgen derzeit für frischen Wind. Das MapReduce Pattern spielt dabei eine große Rolle. Dieser Vortrag will Entscheidungshilfen liefern und MapReduce in ein praxisnahes Licht rücken. Anhand konkreter Beispiele und Demos wird gezeigt, welche Vor- und Nachteile die verteilte, parallele MapReduce-Datenverarbeitung hat und welche neuen Perspektiven sie gegenüber SQL bietet.

Infos: www.bigdatacon.de

Es ist ein kleiner Schritt für die Computer von „normalisiert“ nach „normal“, aber ein großer Schritt für die Menschheit. Sind Ihre Daten einwandfrei normalisiert? Testfrage: Wie lange würde eine Datenmigration in ein anderes System mit einem anderen Domänenmodell bei Ihnen dauern? Und wenn Sie sich die in den letzten Jahren gewachsenen Daten und Schemata noch einmal genau anschauen, wie lange würde es jetzt wirklich dauern?

Ich bin kein Physiker, aber bin mir sicher, dass sich aus der Thermodynamik oder der Relativitätstheorie folgender Satz ableiten ließe: Daten streben die höchstmögliche Divergenz von ihrem Schema an. Mit anderen Worten: Datenschemata sind super, funktionieren aber selten hundertprozentig. Was ist ein Schema wert, das nicht eingehalten wird? Besser als gar kein Schema, sagen Sie? Ich gebe Ihnen recht. Trotzdem der Versuch einer anderen Perspektive. Schauen wir uns Apache Pig [1] an. Das Motto, das laut Webseite zur Wahl des Namens führte, ist: „Pig eats everything“. Und Apache Pig frisst Daten. Sie müssen nicht normalisiert sein. Datenkonsistenz ist aber von großem Vorteil. Es sei nicht verschwiegen, dass ein Blick in den Quellcode von Pig den Namen noch zusätzlich motiviert. Sauberer Code ist etwas anderes. CSV Files, reine Textdateien oder Inhalte von Datenbanken sind die typischen Grundnahrungsmittel von Pig. Sie dürfen dabei auch sehr, sehr groß sein. Mit Pig lassen sich ad hoc Schemata auf solchen Daten deklarieren, das Chaos erhält also – wie gehabt – zuerst einmal Struktur. Nun kann man die Daten nach Belieben filtern, zählen, aufbrechen, aggregieren, umformen, joinen und parsen.

Hier kommt Pig Latin ins Spiel, die eingebaute deklarative Datenfluss-Sprache. Konstrukte wie Schleifen und Verzweigungen sucht man vergebens. Stattdessen werden mit jedem Befehl Daten umgeformt. In reinem SQL werden Selektionen, Joins, Aggregationen und Operationen auf Daten in einem großen Statement zusammengeschachtelt. In Pig findet das schrittweise, eher prozedural statt. Jedes Kommando beschreibt einen Teilschritt von Anfang zum Ziel. Mit dem abschließenden Befehl zum Berechnen eines Ergebnisses werden alle Teilschritte zusammengenommen und als eine Einheit ausgeführt. Dabei läuft mindestens ein MapReduce-Job ab, oft sind es aber auch mehrere hintereinander.

Daten in Pig sind typisiert. Pig Latin bietet neben den einfachen Typen wie int, float, long, double, chararray (String) und bytearray auch verschiedene Containertypen an, die sehr praktisch bei der Handhabung der Daten sind. Dabei handelt es sich um Map (Schlüssel/Wert), Tupel (ähnlich einem Array, nur dass jede Stelle einen eigenen Typ haben kann) und Bag (unsortierte Menge von Tupeln). Ein einfaches Beispiel ist das Laden eines Files, das pro Zeile einen User enthält und jeden User in einem Tupel (id, name, group) hält:


users = load ‚user.csv‘ as (id:long, name:chararray, logincount: long, groupid:chararray) using PigStorage(‚,‘);

Nehmen wir an, wir haben des Weiteren eine Datenstruktur groups:(gid:long, gname:chararray). Nun können wir users und groups über die Gruppen-ID joinen:


usergroups = join users by groupid, groups by gid;

Um die Anzahl der Log-ins für jede Gruppe zu zählen, gruppieren wir zuerst nach Gruppen-ID:


usergroups_grp = group usergroups by groupid;

usergroups_grp ist nun ein Bag, der für jede groupid passende Einträge aus usergroups enthält. Nun können wir die Log-ins zusammenzählen, indem wir eine neue Datenstruktur erzeugen, die Gruppennamen und Summen enthält:


login_counts = foreach usergroups_grp generate groupid, COUNT(usergroups.logincount);

So, unser Programm steht, aber bisher ist noch kein Code generiert und ausgeführt worden. Mit Befehlen wie describe users oder explain login_counts können wir aber die erzeugten Schemata ausgeben lassen oder einen Vorgeschmack auf Ablaufpläne holen. Die Befehle dump login_counts und store login_counts führen wirklich eine Berechnung aus, illustrate tut das für Testzwecke nur auf einem Bruchteil der Daten. Das Ungewöhnliche an der Sprache Pig Latin ist sein Kompilat, also die Ausgabe des Pig-Compilers: Es ist eine Serie von MapReduce-Jobs. MapReduce-Jobs sind hochgradig parallelisierbar. Man kann sie auf eine große Menge Daten (Zig-Gigabytes bis Terabytes) loslassen und trotzdem in endlicher Zeit ein Ergebnis erhalten, entsprechende Rechenleistung, z. B. in einem Hadoop-Cluster, vorausgesetzt.

Wer schon mal einen MapReduce-Job selber von Hand geschrieben hat, der wird Pig zu schätzen wissen. Der Code für einen einzelnen MapReduce-Job ist vergleichsweise übersichtlich. Aber die Hintereinanderschaltung von mehreren Jobs kann zum Kunststück werden. Pig erledigt dies ohne weiteres, ähnlich wie eine relationale Datenbank einen Query-Plan aufbaut. Dabei liefert Pig für viele Teilaufgaben schon fertiges Rüstzeug mit. Der obige Code kratzt nur an der Oberfläche. Beispiel Parser: Das Einlesen von CSV oder Apache Server Logs muss man nicht selbst implementieren. Eigene Formate lassen sich über JARs aus dem Classpath nachladen. Für sehr spezielle Anwendungen kommt man um eigene Java-Map- und Reduce-Klassen nicht herum. Aber vor allem für Brot-und-Butter-Jobs ist Pig ideal. Nicht zu vergessen natürlich jene Kollegen aus der Datenanalyse, die das JDK nicht als Bettlektüre verschlingen und alle „-X“-javac-Schalter aus dem Effeff beherrschen. Also jene, die die Schweinerei ausbaden müssen, wenn die Datenkonsistenz doch nicht so gut war.

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

Schreibe einen Kommentar

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