Masterarbeit: Near Copy Detection in large text corpora (ODIN): Benchmark 2

Das neue Cluster ist fertig und funktioniert. Wir haben zu unseren bestehenden Cluster von 3XCore2 quad Maschinen und Imhoteps sechs Kernen, um 14 neue Sechskernmaschinen erweitert. Mit den neuen und den alten Maschinen kommen wir also auf 102 Kerne!

Wir haben uns für die neuen Maschinen für AMD FX 6100 Prozessoren entschieden. Dieser taktet seine 6 Kerne mit bis zu 3,3GHz und hat in einer Preis/Leistungsabwägung gut abgeschnitten. Der Prozessor sitzt auf einem Asus M5A88-Mainboard das mit 4X4GB Ram besückt ist.

Damit die Prozessoren auch immer gut mit Daten versorg werden können haben wir uns entschieden jedem Rechner vier Festplatten zu spendieren. Hier haben wir uns für Seagate Barracuda Green 2TB entschieden. Diese sorgen im Clusterverbund für eine gewaltige Bandbreite. So hat sie in einem Schreibtest eine Bandbreite von 830MB/sec (zweifach redundant, also jeder Datenblock wird drei mal geschrieben. Hieraus ergibt sich 2,4GB/sec) ergeben.

Das ganze wurde in T5 Gehäuse von Sharkoon eingebaut. Diese waren recht Preiswert und haben eine gute Kabelführung. Die Stromversorgung übernehmen 400Watt Netzteile von Sharkoon.

Die Rechner des alten Clusters und die neuen Rechner sind mit einen eigenen 1Gbit Switch verbunden.

Insgesamt kommen wir auf :

18 Workernodes
102 Cores (12xCore2 Quad 2,8GHz, 6xIntel Xeon 2,9GHz, 96x AMD FX 6100 3,3GHz)
260GB Ram (3x8GB, 1x12GB, 14x16GB)
115TB HDD (56x2TB, 1x500GB, 9x330GB)

Auf allen Workernodes läuft Ubuntu Server. Das Hadoop Framework wird mit Konfiguration vom Master kopiert und mit Java 1.6 ausgeführt (Ich habe mich hier für java 1.6 entschieden da sich Java 7 in Bezug auf Stringverarbeitung anders verhält).

Neben der Verwendung als Rechencluster, ist es auch sehr dekorativ und nützlich als Heizung an kalten Tagen. :-)

Hier einige Zeiten aus meiner Masterarbeit die ich mit einem Setup von 90 Kernen gemacht habe. Als Testdokumente habe ich 43.000 Paper aus der Computer Science genommen. Diese Paper haben ein Gesamtgröße von knapp 30GB. Auf diesem Datensatz habe ich fünf meiner MapReduce Job ausgeführt, diese haben die unten beschriebenen Funktionen.

PDFToText+Hyphenationremoval+Footer-Headerremoval: 1,35 Sekunden/Core/Dokument | 0,015 Sekunden/Dokument

Sentence+Tokensplitting+POS: 2,34 Sekunden/Core/Dokument | 0,026 Sekunden/Dokument

Lemmatizer: 23,4Sekunden/Core/Dokument | 0,260 Sekunden/Dokument (Der Lemmatizer ist gerade auf deutschen Texten sehr langsam)

Stemmen+Stopword+Numberremoval+Symbolremoval: 0,171 Sekunden/Core/Dokument | 0,0019 Sekunden/Dokument

Wordnet Synonymfindung: 43,2 Sekunden/Core/Dokument | 0,480 Sekunden/Dokument

Masterarbeit: Near Copy Detection in large text corpora (ODIN): Benchmark

In diesem Blog wollte ich ein paar Zwischenergebnisse des Hadoop Clusters auflisten. Das Cluster besteht momentan aus 4 Workernodes mit insgesamt 18 Cores (4,4,4,6 / Core2 2,8GHz) die alle ungefähr gleich schnell sind. Die Rechner sind mit insgesamt 7 Platten (3,3,3,1) ausgestattet und haben pro Core 2GB Ram. Der Testdatensatz umfasst ca. 43.000 PDFs mit einer gesamt Größe von ca. 27GB. Die aufgelisteten Werte drücken die Bearbeitungszeit eines Dokuments auf einen Core aus, dahinter die Bearbeitungszeit eines Dokuments auf den gesamten Cluster (geteilt durch die Anzahl der Cores).

PDFToText+Hyphenationremoval+Footer-Headerremoval: 0,074 Sekunden/Core/Dokument | 0,00411 Sekunden/Dokument

Sentence+Tokensplitting+POS: 1,828 Sekunden/Core/Dokument | 0,1015 Sekunden/Dokument

Lemmatizer: 11,554 Sekunden/Core/Dokument | 0,64189 Sekunden/Dokument

Stemmen+Stopword+Numberremoval+Symbolremoval: 0,111 Sekunden/Core/Dokument | 0,00617 Sekunden/Dokument

Daraus ergibt sich eine gesamt Zeit von 0,75367 Sekunden pro Dokument. Diese Zeit wird dominiert durch das Lemmatisieren was API-bedingt ist.

Fehlersuche in Hadoop

Manchmal gibt es leider auch in Clustern einige seltsame Fehler:

org.apache.hadoop.util.DiskChecker$DiskErrorException: Could not 
find any valid local directory for taskTracker/…

Der Fehler sagt eigentlich nur aus, dass der Node nicht mehr genug Speicherplatz frei hat. Lösung hierfür wäre die Vergrößerung der Festplatte, aktuell 150 GB.

Der nächste Fehler hat eine andere Ursache:

Task attempt_1 failed to report status for 600 seconds. Killing!

Die Lösung dafür ist die Erhöhung des Timeouts, indem auf allen Nodes mapred.task.timeout erhöht wird (in /conf/mapred-site.xml). Mal sehen, ob dies die Erlösung bringt…

Mein eigenes privates Cluster

Zugegeben, gegen das Facebook Cluster ist meins winzig, aber dafür habe ich volle Verfügungsgewalt darüber und es werden auch keine Daten zu Werbezwecken weitergegeben.

Und was mache ich damit? Nun zum einen dient es zum verteilten Berechnen von Ähnlichkeiten zwischen Dokumenten (bzw. Artefakten), zum Anderen wird es die Ähnlichkeitswerte zwischen allen Artefakten in einer Datenbank (Hive), die auf dem Cluster läuft, speichern.

Für die Wikipedia (en) benötigt man beispielsweise bei 4 Bit pro Ähnlichkeitswert einige TeraBytes an Speicherplatz. Was liegt also näher das gleiche System einzusetzen, mit dem Facebook 21 PetaByte an Daten verwaltet?

Mit den gespeicherten Ähnlichkeitswerten zwischen Artefakten wird nachfolgend in der Hadoop/Hive-Datenbank dann die Ähnlichkeit der zugehörigen Akteure berechnet. Unter Akteuren versteht man die „Besitzer“ der Dokumente (Artefakte), also beispielweise Personen, die ein Paper verfasst oder einen Tweet geschrieben haben.

Die Formel sieht kompliziert aus, ist sie aber nicht. Trotzdem versuche ich mal, mit einem nicht weiter erklärten Screenshot zu beeindrucken.

Nun gut, dass erst mal zu meiner Masterarbeit, Thema: „Ähnlichkeitsfindung in Artefakt-Actor-Networks“.