Large Scale Multilayer Perceptron

LARGE SCALE MULTILAYER PERCEPTRON

Abschlussarbeitzur Erlangung des akademischen Grades

Master of Science (M.Sc.)an der

Hochschule für Technik und Wirtschaft BerlinFachbereich Wirtschaftswissenschaften IIStudiengang Angewandte Informatik

1. Prüfer: Prof. Dr. Christian Herta2. Prüfer: Prof. Dr. Hermann Hessling

Eingereicht vonSascha Jonas (B.Sc.)10. Februar 2014

© Copyright 2013 Sascha Jonas (B.Sc.). Alle Rechte vorbehalten.

iii

Kurzbeschreibung:

In dieser Arbeit wurde ein Software-Framework entwickelt, auf der Basis von ApacheHama, einer Implementierung des bulk-synchronous parallel model (BSP). Das Frameworkbietet die Möglichkeit, ein künstliches neuronales Netz in einem Rechner-Cluster verteiltzu trainieren. Es bietet weiterhin die Möglichkeit, sowohl auf Mini- als auch auf Big-Batchbasierende Trainingsalgorithmen zu benutzen. Skalierbarkeit und Performance wurden unteranderem anhand des Trainings eines Denoising Autoencoders mit 1.000 Eingabe- und Ausga-beneuronen ermittelt.

Abstract:

In this study the ability of bulk-synchronous parallel model (BSP) for scaling out thetraining of an artificial neural networks is analyzed. Comparable distributed training al-gorithms based on mini-batch and big-batch scheme were developed. For this purposethe framework Apache Hama was used. The scalability of the different approaches has be-en determined by the training of an denoising autoencoder with 1,000 input and output neurons.

Keywords: autoencoder, bulk-synchronous parallel computing (BSP), deeplearning, Multilayer Perceptron, Apache Hama

Inhaltsverzeichnis

Inhaltsverzeichnis v

1 Einleitung 11.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Grundlagen 52.1 Künstliche neuronale Netze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Initialisierung der Verbindungsgewichte . . . . . . . . . . . . . . . . . . . 82.1.2 Gradientenbasierte Lernverfahren . . . . . . . . . . . . . . . . . . . . . . . 92.1.3 Backpropagation of Error . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.1.4 Momentum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.5 ADAGRAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.6 Resilient Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.7 Autoencoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2 Bulk-Synchronous Parallel Model . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.1 Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.2.2 Apache Hama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Anforderungsanalyse 213.1 Verwandte Studien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.1 Studie 1: Using the BSP Cost Model to Optimize Parallel Neural NetworkTraining . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.1.2 Studie 2: Large Scale Distributed Deep Networks . . . . . . . . . . . . . . 223.2 Analyse des MLP Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.2.1 Speicherung der Verbindungsgewichte . . . . . . . . . . . . . . . . . . . . 243.2.2 Lernverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.3 Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.3 Zielstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.3.1 Funktionale Anforderungen . . . . . . . . . . . . . . . . . . . . . . . . . . 25

INHALTSVERZEICHNIS vi

3.3.2 Nicht-Funktionale-Anforderungen . . . . . . . . . . . . . . . . . . . . . . . 273.3.3 Abgrenzungskriterium . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Entwurf 294.1 Systembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.1 Datenvorverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304.1.2 verteiltes Training mit BSP . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1.3 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2 Sparse Autoencoder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 Implementierung 395.1 Datenverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1.1 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.1.2 Trainingsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.2 MLP-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.2.1 Initialisierung der Verbindungsgewichte . . . . . . . . . . . . . . . . . . . 415.2.2 Matrizen-Bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425.2.3 Trainingsalgorithmen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

5.3 verteiltes Training mit BSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 445.3.1 Initialisierung & Cleanup . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.3.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.4 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.5 Apache Hama . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.5.1 Stabilitätsprobleme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.5.2 Job-Verteilung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5.6 Software-Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 475.6.1 Datenverarbeitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.6.2 Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

6 Auswertung 496.1 Testumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 496.2 Validitätstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

6.2.1 Experiment: XOR-Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . 506.2.2 Experiment: MONK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

6.3 Skalierungstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.3.1 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.3.2 Vertikale Skalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.3.3 horizontale Skalierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

6.4 Laufzeittests einzelner Komponenten . . . . . . . . . . . . . . . . . . . . . . . . . 606.4.1 Einfluss des Caches auf die Ladezeit . . . . . . . . . . . . . . . . . . . . . 606.4.2 Vergleich von sequentieller und Binary Tree Kommunikation . . . . . . . 60

INHALTSVERZEICHNIS vii

6.4.3 Vergleich von Apache Mahout und jblas . . . . . . . . . . . . . . . . . . . 616.5 Untersuchung des Arbeitsspeicherverbrauchs . . . . . . . . . . . . . . . . . . . . . 636.6 Performancetests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

6.6.1 Messung: Iterationsanzahl bis zur Erreichung eines Zielfehlerwerts . . . . 656.6.2 Messung: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . 66

6.7 Xing-Profildaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.7.1 Problembeschreibung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.7.2 Datenaufbereitung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.7.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 706.7.4 Auswertung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

7 Fazit 757.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 757.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

A Klassendiagramme 79

B Einzelergebnisse der Performancetests 83B.1 MONK: Anzahl Iterationen bis zum Fehlerwert 0,1 . . . . . . . . . . . . . . . . . 83B.2 MONK: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . . . . . 85B.3 Xing20: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . . . . . . 87

C Fehlerrechnung 89

D Metriken 91D.1 Precision/Recall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91D.2 F-measure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92D.3 Speedup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

E Normalisierung von Trainingsdaten 93

F Verteiltes Training mit BSP in Pseudocode 95

G Abkürzungsverzeichnis 97

H Abbildungsverzeichnis 99

I Sourcecodeverzeichnis 101

J Tabellenverzeichnis 103

K Literaturverzeichnis 105

L Eigenständigkeitserklärung 111

Kapitel 1

Einleitung

1.1 Motivation

Das Multilayer Perceptron (MLP) ist ein künstliches neuronales Netz und wird bereits seitden 80er Jahren erfolgreich zur Lösung verschiedener Probleme, wie z.B. Klassifizierung undRegression, genutzt (siehe Abschnitt 2.1[Seite 7]).

Ausgelöst unter anderem durch die Arbeit Geoffrey E. Hintons im Jahr 2006, der einen Auto-encoder (siehe Unterabschnitt 2.1.7[Seite 15]) benutzte, um ein künstliches neuronales Netzwerkmit mehreren versteckten Schichten zu trainieren (deep learning), ist das MLP auch heute nochim Fokus aktueller Forschung (siehe [HS06a], [Hin07]).

Eine Gruppe von Forschern bei Google verfolgte 2012 einen Ansatz mit horizontaler Ska-lierung (scale out). Ihnen gelang es ein lokal verbundenes neuronales Netz mit einer MilliardeNeuronenverbindungen auf einem Cluster mit 1.000 Rechnern und 16.000 CPUs zu trainie-ren (siehe [LRM+12]). Die selbe Gruppe untersuchte 2013 den Ansatz der vertikalen Skalierung(scale up), anhand eines Clusters mit 16 Rechnern und 64 GPUs (siehe [CHW+13]). Mit diesemCluster gelang es ihnen, ein lokal verbundenes Netz mit 10 Milliarden Neuronenverbindungenin der gleichen Zeit zu trainieren.

Die obigen Beispiele zeigen, dass es unter Benutzung des Autoencoder-Ansatzes möglichist, neuronale Netze mit sehr vielen Parametern in kurzer Zeit zu trainieren. Beide Ansätzescheinen eine gute Skalierbarkeit aufzuweisen, sind jedoch nicht als Open Source frei verfügbar.

Im Big Data Bereich gibt es eine Reihe von Open Source Frameworks, die nur Standard-Hardware benötigen und eine gute Skalierbarkeit versprechen. Das Training eines neuronalenNetzwerks ist ein iteratives Verfahren, d.h. dass auch entsprechende Anforderungen an einFramework gestellt werden. Im Rahmen dieser Arbeit wird das Framework Apache Hama (sieheAbschnitt 2.2, Seite 16)verwendet, das eine Implementierung des bulk-synchronous parallelmodel (BSP) ist. Es unterstützt explizit Iterationen, außerdem bietet es, im Gegensatz zur Map

KAPITEL 1. EINLEITUNG 2

Reduce1 Implementierung von Apache Hadoop (siehe [Whi11], Seiten 129ff), die Möglichkeitan Daten über mehrere Iterationen hinweg im Arbeitsspeicher zu halten.

1.2 Zielstellung

Im Rahmen dieser Arbeit soll eine prototypische Anwendung zum verteilten Trainieren eineskünstlichen neuronalen Netzes erstellt werden. Diese Anwendung soll auf der Implementierungeines MLP, das von der Hochschule zur Verfügung gestellt wurde, basieren. Um eine korrek-te Funktion der daraus resultierenden Anwendung zu gewährleisten, wird als erstes Ziel dieUntersuchung und Validitätsprüfung des MLP-Frameworks festgelegt.

Den Trainingsvorgang zu beschleunigen ist ein weiteres Ziel dieser Arbeit. Zum Erreichendieses Ziels sollen folgende Ansätze verfolgt werden: Zum einen die Verwendung performanterTrainingsalgorithmen, zum anderen die Verteilung der Berechnungen in einem Rechner-Cluster.

Teil der Untersuchung des MLP-Frameworks sind deshalb die verwendeten Trainingsalgor-tithmen, die um zusätzliche Verfahren erweitert werden sollen. Das bereits vorhandene MLP-Framework arbeitet sequentiell. Als erstes stellt sich deshalb die Frage, welcher Teil der Berech-nungen parallelisiert erfolgen kann. Weiterhin muss ermittelt werden, wie die Parallelisierungmit Apache Hama und BSP erfolgen sollte, um eine gute Skalierbarkeit zu gewährleisten. Insbe-sondere muss untersucht werden, wie die Kommunikation über Rechnergrenzen hinweg ablaufensollte.

Zum Abschluss müssen die erfolgte Implementierung, die Eignung von Apache Hama unddie verwendeten Trainingsalgorithmen bewertet werden. Aus diesem Grund sollen Performanzund Skalierbarkeit untersucht werden, dabei sind unter anderem Speedup und Overhead durchNetzwerkkommunikation Gegenstand der Untersuchung. Als praktischer Anwendungsfall solldas Trainieren einer „collocate tag cloud“ anhand von Xing-Profildaten untersucht werden.

Bei Xing (siehe [Xin]) handelt es sich um ein soziales Netzwerk, für hauptsächlich berufli-che Zwecke. Die Benutzer dieser Webseite, können hier ihr Profil z.B. Ausbildung, beruflicherWerdegang und eine Liste ihrer fachlichen und sozialen Kompetenzen veröffentlichen. Letztereswurde von Prof. Dr. Herta im Rahmen eines Forschungsprojekts für eine Reihe von Profilengecrawlt, anonymisiert und dem Autor zur Verfügung gestellt.

1.3 Aufbau der Arbeit

Kapitel 2 (siehe Seite 5ff) beinhaltet die Grundlagen dieser Arbeit: eine Einführung in künstlicheneuronale Netze, verwendete Trainings- und Optimierungsverfahren, sowie eine Beschreibungdes Frameworks Apache Hama (siehe Abschnitt 2.2, Seite 16).

1Map/Reduce sind zustandslose Funktionen und weisen Ähnlichkeiten zur funktionalen Programmierung auf.

KAPITEL 1. EINLEITUNG 3

In Kapitel 3 (siehe Seite 21ff) werden zwei Studien analysiert, die ebenfalls das verteilteTraining eines MLP in einem Cluster zum Inhalt haben. Weiterhin wird das bereits vorhandeneMLP-Framework analysiert. Diese beiden Analysen bilden die Grundlage, für die am Ende desdritten Kapitels formulierte Zielstellung.

Kapitel 4 ist eine Zusammenfassung der Entwurfsphase (siehe Seite 29ff). Es beinhaltet eineSystembeschreibung, geht auf die einzelnen Systemkomponenten ein und erläutert die grund-sätzliche Vorgehensweise zur Implementierung eines Sparse Autoencoder (siehe Abschnitt 4.2,Seite 37), auch wenn diese aus Zeitgründen entfallen musste.

In Kapitel 5 wird näher auf die eigentliche Implementierung eingegangen (siehe Seite 39ff).Hier finden sich konkrete Details zur Implementierung ausgewählter Systemkomponenten, dieanhand von Codeausschnitten und Klassendiagrammen erläutert wird.

Die Auswertung der Validitäts-, Performance- und Skalierungstests ist Inhalt von Kapitel 6(siehe Seite 49ff). Die Feststellung der Validität eines trainierten neuronalen Netzes, erfolgteanhand des MONK-Problems, aus dem UCI-Repository für maschinelles Lernen (siehe [BL13],„MONK’s Problems Data Set“), und anhand der XOR-Funktion. Die Performanz der Trainings-verfahren, wurde sowohl anhand der Xing-Daten als auch anhand der MONK-Daten geprüft.Die Xing-Daten wurden zusätzlich zum Testen der vertikalen und horizontalen Skalierbarkeitverwendet. Der letzte Teil dieses Kapitels beschreibt Vorgehen und Ergebnisse der Extraktionvon syntagmatischer und paradigmatischer Relation mit Hilfe eines Denoising Autoencoder.

Das Kapitel 7 (siehe 75ff) bildet den Abschluss dieser Arbeit. Es enthält eine Zusammen-fassung der Ergebnisse und den Ausblick.

Kapitel 2

Grundlagen

Im ersten Teil dieses Kapitels, werden künstliche neuronale Netze im Allgemeinen und meh-rere im Rahmen dieser Arbeit verwendete Optimierungsverfahren erläutert. Dazu gehören dasBackpropagation Verfahren, Momentum, Denoising Autoencoder und Sparse Autoencoder, dieim vorliegenden Framework bereits implementiert wurden. Dieses Framework wurde im Rah-men dieser Arbeit um Improved Resilient Propagation (iRprop+), ADAGRAD und verschiedeneVerfahren zur Initialisierung der Verbindungsgewichte erweitert, die zusätzlich kurz beschriebenwerden. Außerdem wird der Autoencoder Algorithmus vorgestellt, der die Grundlage für denin Abschnitt 6.7 auf Seite 69 beschriebenen Anwendungsfall ist.

Im zweiten Teil dieses Kapitels werden das BSP Modell und das Framework Apache Hamabeschrieben.

2.1 Künstliche neuronale Netze

Ein künstliches neuronales Netz wird durch Simon Haykin (siehe [Sim05, Seite 24]) folgender-maßen definiert:

„A neural network is a massively parallel distributed processor made up of simple processingunits, which has a natural propensity for storing experiential knowledge and making it availablefor use. It resembles the brain in two respects:“

• Knowledge is acquired by the network from its environment through a learning process.

• Interneuron connection strengths, known as synaptic weights, are used to store the acquiredknowledge.

Es besteht also aus mehreren einfachen Prozessoren (Neuronen), die miteinander verbundensind. Es erlangt Wissen im Rahmen eines Lernprozesses und speichert Wissen, durch die Verbin-dungen (Synapsen) zwischen den Neuronen, denen unterschiedliche Gewichtungen zugeordnetwerden. Diese Verbindungsgewichte werden im Rahmen des Lernprozesses angepasst.

KAPITEL 2. GRUNDLAGEN 6

Man unterscheidet hier zwischen überwachtem („supervised“), unüberwachtem („unsuper-vised“) und bestärkendem („reinforcement“) Lernen. Ziel des Lernvorganges ist, das neuronaleNetz so zu trainieren, dass es sowohl für bekannte als auch unbekannte Eingaben sinnvolleAusgaben liefert, z.B. indem es Handschriften erkennt, mit denen es nicht trainiert wurde.

Im Rahmen dieser Arbeit wird das MLP beschrieben und verwendet, welches zur Klasseder künstlichen neuronalen Netze gehört. Das MLP ist ein Verfahren, das ausschließlich fürüberwachtes Lernen benutzt werden kann. Beim überwachtem Lernen wird Wissen durch Gebenvon gelabelten Datensätzen gewonnen, dabei besteht ein Datensatz aus einem oder mehrerenEingabewerten und dem erwarteten Ergebnis.

Weiterhin wird im Rahmen dieser Arbeit ein Autoencoder verwendet, der auf dem MLP

aufsetzt. Der Autoencoder ist ein Beispiel für unüberwachtes Lernen. Hier werden ungelabelteDaten zum Trainieren verwendet, dabei bedient sich der Autoencoder eines „Tricks“, indemdie Identität trainiert wird. Die Eingabe ist also gleich der Ausgabe, sodass das MLP auch mitungelabelten Daten benutzt werden kann (siehe Unterabschnitt 2.1.7, Seite 15).

Neuronenmodell

Abbildung 2.1: Neuronenmodell1

Ein künstliches neuronales Netz besteht aus mindestens einem Neuron, welches in Abbil-dung 2.1 für ein Neuron schematisch dargestellt wird. Xi stellt den Eingabevektor mit m-Dimensionen dar und Wij das Verbindungsgewicht zur jeweiligen Eingabe. X0 und W10 stelleneine besondere Eingabe, nämlich den Bias bzw. dessen Gewichtung dar (In der Abbildung alsb1 dargestellt).

Der Bias ist immer gleich plus eins. Man kann den Bias, in Verbindung mit dem jeweiligemVerbindungsgewicht, als einen Schwellwert betrachten. Erst wenn dieser Schwellwert überschrit-ten wird, erzeugt das Neuron einen Output.

1Quelle: Original von [Sim05][Seite 33] wurde angepasst.


Die gewichteten Eingaben werden summiert (z1 =m∑j=1

xjW1j + b1). und bilden die Eingabe

für die Aktivierungsfunktion f. Der daraus resultierende Funktionswert a1 stellt schließlich dieAusgabe des Neurons dar. Ein Beispiel für eine Aktivierungsfunktion ist die sigmoide-Funktionf(x) = 1

1+e−x , deren Funktionswerte im Bereich [0,1] liegen.

Multilayer Perceptron

Das Multilayer Perceptron ist ein Netz von mehreren miteinander verbundenen Neuronen. Esbesteht aus einer Eingabeschicht („input layer“), einer oder mehreren versteckten Schichten(„hidden layer“) und einer Ausgabeschicht („output layer“).

In der Abbildung 2.2 wird ein MLP exemplarisch dargestellt. Auf der linken Seite des neu-ronalen Netzes befindet sich die Eingabeschicht, auch „feature“ Vektor genannt, mit drei Ein-gaben. In der Mitte des Netzes befindet sich eine versteckte Schicht, mit drei Neuronen. Aufder rechten Seite befindet sich schließlich die Ausgabeschicht mit einem Neuron. Der Bias wirdnicht mitgezählt, er ist in der Abbildung als „+1“ dargestellt.

Im Rahmen dieser Arbeit werden ausschließlich voll verbundene neuronale Netze betrach-tet, d.h. jede Komponente des Eingabevektors ist mit jedem Neuron der benachbarten Schichtverbunden. Die Neuronen in den versteckten Schichten, sind Schicht für Schicht mit allen Neu-ronen in der jeweils benachbarten versteckten Schicht bzw. der Ausgabeschicht verbunden. DieVerbindungen sind gerichtete Graphen, daher wird das MLP auch als „feedforward-Netz“ be-zeichnet.

Abbildung 2.2: Multilayer Perceptron mit einem hidden layer2

Den Notationen von Ng folgend (siehe [And][Seite 4ff]), hat das oben gezeigte MLP dieParameter (W, b) = (W (1), b(1),W (2), b(2)), dabei stellt W (l)

ij das Gewicht dar, welches der Ver-bindung zwischen dem j-ten Neuron in der Schicht l und dem i-ten Neuron in der Schicht l+1zugeordnet wird. Weiterhin ist b(l)

i der Bias, der dem i-ten Neuron in der Schicht l+1 zugeord-

2Quelle: siehe [And][Seite 3]


net wird. Die Ausgabe eines Neurons wird durch a(l)i dargestellt. Die Ausgabe des dargestellten

MLP wird folgendermaßen berechnet:

a(2)1 = f(W (1)

11 x1 +W(1)12 x2 +W

(1)13 x3 + b

(1)1 ) (2.1)

a(2)2 = f(W (1)

21 x1 +W(1)22 x2 +W

(1)23 x3 + b

(1)2 ) (2.2)

a(2)3 = f(W (1)

31 x1 +W(1)32 x2 +W

(1)33 x3 + b

(1)3 ) (2.3)

hW,b(x) = a(3)1 = f(W (2)

11 a21 +W

(2)12 a

22 +W

(2)13 a

23 + b

(2)1 ) (2.4)

Um dieses neuronale Netz zu trainieren, werden die Trainingsdaten (x(i), y(i)), mit x(i) ∈ R3

und y(i) ∈ R1, benötigt. Die Variable x steht für den Eingabevektor und enthält die Eingabe-daten. Die Variable y steht für den Zielvektor und enthält die für dieses Beispiel erwartetenAusgabedaten.

Trainingsalgorithmen, werden unterschieden in Online-, Mini-Batch- und Batch-Lernverfahren (siehe Seiten 9 und 10).

Ein weiteres Unterscheidungsmerkmal ist, welche Ableitung der Fehlerfunktion (siehe Ka-pitel 2.1.2) benutzt wird. Man unterscheidet hier zwischen Verfahren erster und zweiter Ord-nung. Bei Verfahren erster Ordnung wird ausschließlich die erste Ableitung der Fehlerfunktionbenötigt (Gradient). Im Rahmen dieser Arbeit wird sich auf diese Verfahren beschränkt. BeiVerfahren zweiter Ableitung wird zusätzlich die zweite Ableitung benötigt (siehe z.B. Hesse-Matrix [Chr96][Seiten 150-160])).

Nachfolgend werden die Initialisierung der Verbindungsgewichte, mehrere Verfahren ersterOrdnung, zur Ermittlung der Gewichtsänderungen, und das Backpropagation Verfahren, zurErmittlung der ersten Ableitung, beschrieben.

2.1.1 Initialisierung der Verbindungsgewichte

Bevor ein neuronales Netz trainiert werden kann, müssen die Verbindungsgewichte initialisiertwerden. Hier gilt es zu beachten, dass sie mit unterschiedlichen Werten initialisiert werdenmüssen. Würde man jedes Verbindungsgewicht mit dem gleichen Wert initialisieren, dann wür-den alle Neuronen einer Schicht die selbe Funktion lernen und die gleiche Ausgabe erzeugen(siehe [And][Seite 7] und Unterabschnitt 2.1.3).

Laut LeCun et al. hat die Initialisierung einen großen Einfluss auf den Lernprozess (sie-he [LBOM98][Kapitel 4.6]). Eine schlechte Initialisierung z.B. auf einem Plateau kann denLernvorgang stark verlangsamen (siehe Beispiel d in Abbildung 2.4, Unterabschnitt 2.1.4). Le-Cun et al. schlagen folgende Normalverteilung für die zufällige Initialisierung der Gewichte vor:N (0, 1√

fanin

). Die Variable fanin steht für die Anzahl der jeweils eingehenden Verbindungen.Im Rahmen dieser Arbeit werden nur voll verbundene Netze betrachtet. Sie steht deshalb im-mer für die Anzahl der Neuronen in der vorhergehenden Schicht. Diese Form der Initialisierungwird in dem vorliegenden Framework bereits benutzt.


Nguyen & Widrow sowie Glorot & Bengio berechnen die Gewichtswerte unter Berücksich-tigung der Neuronenanzahl in zwei Schichten (siehe [NW90][Seite 25] und [GB10][Seite 253]).

Glorot & Bengio schlagen eine Uniformverteilung der Gewichtswerte vor, die sie als nor-malisierte Initialisierung bezeichnen. Die Initialisierung hängt laut Glorot & Bengio von derAktivierungsfunktion ab. Mit fanout gleich der Anzahl Neuronen in der betrachteten Schicht,gilt für die Aktivierungsfunktion tanh:

W v U

[−

√6√

fanin + fanout,

√6√

fanin + fanout

](2.5)

Die Initialisierung der Gewichte erfolgt mit dem Verfahren von Nguyen & Widrow in meh-reren Schritten. Im ersten Schritt werden die Gewichte zufällig initialisiert. Es gilt folgendeUniformverteilung:

W v U [−1, 1] (2.6)

Sei W li der Gewichtsvektor des i-ten Neurons in der Schicht l, dann wird im zweiten Schritt die

Norm von W li geändert, so dass gilt:

|W li | = 0.7 · (fanout)fan

−1in (2.7)

2.1.2 Gradientenbasierte Lernverfahren

Das Training eines neuronalen Netzes gehört zu der Klasse der Minimierungsprobleme, da es giltden Fehler, also den Abstand zwischen der tatsächlichen und der erwarteten Ausgabe des Netzes,zu verringern. Für diesen Zweck sei als erstes eine Fehlerfunktion auf Basis des quadratischenFehlers aufgestellt, welche die Parameter W, b, x und y berücksichtigt.

Für ein Trainingsbeispiel wird folgende Fehlerfunktion (siehe [And][Seite 6ff]) definiert:

J(W, b;x, y) = 12 ||hW,b(x)− y||2 (2.8)

Batch Gradient Descent

Benutzt man Batch Gradient Descent (BGD), so gilt folgende Fehlerfunktion über alle m-Trainingsdaten:

J(W, b) = [ 1m

m∑i=1

(12 ||hW,b(x

(i))− y(i)||2)] + λ

2

nl−1∑l=1

sl∑i=1

sl+1∑j=1

(W (l)ij )2 (2.9)

In obiger Fehlerfunktion stellt der erste Term, den Durchschnitt über den quadratischen Fehlerdar. Der zweite Term ist der sogenannte Regularisierungs-Term, der Overfitting, also das Aus-wendiglernen der Trainingsdaten, verringern soll. Hier stellt λ den weight decay parameter dar,der die Gewichtung des Regularisations-Term bestimmt. Der Parameter nl steht für die Anzahlan Schichten im MLP und sl für die Anzahl an Neuronen in der jeweiligen Schicht, ohne Bias.


Abbildung 2.3: Gradientenabstieg auf zweidimensionaler Fehlerfunktion3

Bei gradientenbasierten Verfahren wird das Optimum (meist jedoch nur ein lokales Minima)der Fehlerfunktion in einer Reihe von Iterationen ermittelt (siehe obige Abbildung). Die jeweili-ge Schrittweite (4W ) ist proportional zum Gradienten der Fehlerfunktion und zeigt in Richtungdes steilsten Abstiegs (siehe [GGKK07], Seite 64). Sie wird unter der Annahme ermittelt, dassder Anstieg der Fehlerfunktion größer ist, je weiter das Optimum entfernt ist (siehe Unter-abschnitt 2.1.4[Seite 12]). Je geringer der Anstieg, umso kleiner ist die gewählte Schrittweite.Während jeder Iteration werden die Parameter W und b folgendermaßen angepasst:

W(l)ij := W

(l)ij − α

∂

∂W(l)ij

J(W, b;x, y) (2.10)

b(l)i := b

(l)i − α

∂

∂b(l)i

J(W, b;x, y) (2.11)

In den Gleichungen 2.10 und 2.11 stellt α die Lernrate dar, welche in der vorliegenden Im-plementierung eines MLP immer fest gewählt wird, d.h. die für die Problemstellung optimaleLernrate müsste im Rahmen mehrere Versuche ermittelt werden. Einen Ansatz zur automati-schen Anpassung der Lernrate, stellt zum Beispiel ADAGRAD (siehe Unterabschnitt 2.1.5[Seite13]) dar.

Mini Batch Gradient Descent

Wie in den Gleichungen 2.9 und 2.10 zum BGD-Verfahren ersichtlich, wird im ersten Schrittder Gradient über alle Trainingsbeispiele gebildet und summiert. Daraus wird dann im zweitenSchritt der Durchschnitt gebildet und das Modell, genauer die Gewichtsmatrizen des neuronalenNetzes, verändert. Daraus folgt, je größer das Trainingsset um so länger dauert die Berechnungeines Iterationsschrittes.

Beim Mini Batch Gradient Descent (MBGD) Lernverfahren gilt auch die Gleichung 2.9, nursteht hier die Variable m für die Batchgröße und nicht für die Gesamtzahl an Trainingsbei-spielen. Ist die Batchgröße z.B. gleich 200, dann wird der durchschnittliche Gradient nur über

3Quelle: siehe [GGKK07][Seite 64]


200 Trainingsbeispiele gebildet und das Modell verändert. Das wird so lange wiederholt, bis dasModell mit allen Trainingsbeispielen trainiert wurde, dann beginnt das Training wieder mit denersten m-Trainingsdaten.

Ein weiteres auf Gradienten basierendes Verfahren ist Stochastic Gradient Descent (SGD).SGD ist ein Online-Lernverfahren, d.h. das Modell wird nach jedem Trainingsbeispiel ange-passt (siehe [Bot98][Seite 5ff]). Ein weiterer Unterschied ist, dass vor Beginn des Trainings dieTrainingsdaten nach dem Zufallsprinzip neu geordnet werden.

2.1.3 Backpropagation of Error

Wie in Gleichung 2.10 ersichtlich, muss zur Berechnung der Gewichtsänderung zuerst dieAbleitung der Fehlerfunktion an der Stelle [x, y] berechnet werden. Dies erfolgt mit demBackpropagation-Verfahren (siehe [And][Seiten 7-9]), das nachfolgend erläutert wird.

Im ersten Schritt wird die Ausgabe/Aktivierung a(l)i für alle Neuronen, in den versteckten

Schichten Ll und der Ausgabeschicht Lnl, berechnet (forward pass). Im zweiten Schritt wirdder Fehlerwert δli für alle Neuronen ermittelt. Für die Neuronen der Ausgabeschicht, stellt δnlijeweils die Differenz zwischen yi und der Netzausgabe dar. Daraus ergibt sich folgende Gleichungfür die Neuronen der Ausgabeschicht:

δ(nl)i = ∂

∂z(nl)i

12 ||y − hW,b(x)||2 = −(yi − a(nl)

i )f ′(z(nl)i ) (2.12)

In obiger Gleichung stellt zi die Summe der gewichteten Eingaben dar. Die Variable zi entsprichtvk aus Abbildung 2.1. Die Variable f steht für die Aktivierungsfunktion des jeweiligen Neurons.Für die Berechnung des Fehlerwerts δli, der Neuronen in den versteckten Schichten, wird dergewichtete Durchschnitt über alle Fehlerwerte berechnet, die ai als Eingabe benutzen. Darausergibt sich folgende Gleichung:

δ(l)i =

sl+1∑j=1

(W (l)ji δ

l+1j )f ′(z(l)

i ) (2.13)

Der Fehlerwert wird also beginnend bei der Ausgabeschicht berechnet und zu den davor lie-genden Schichten propagiert. Mit den Fehlerwerten kann schließlich die Ableitung berechnetwerden:

∂

∂W(l)ij

J(W, b;x, y) = a(l)j δ

(l+1)i (2.14)

∂

∂b(l)i

J(W, b;x, y) = δ(l+1)i (2.15)

Die Komplexität des Backpropagation Algorithmus, verhält sich linear zur Anzahl der Gewich-te im neuronalen Netz (O(W )). Damit ist das Backpropagation Verfahren sehr effizient. DieBestimmung der Ableitung z.B. mit finiten Differenzen wäre deutlich langsamer, da dessenKomplexität bei O(W 2) liegt (siehe [Chr96][Seiten 146-148]).


2.1.4 Momentum

Abbildung 2.4: Mögliche Probleme beim Gradientenabstieg4

Die in Abschnitt 2.1.2 erwähnte Ermittlung von 4W kann zu Problemen führen, da sieauf einer Annahme basiert, die nicht immer korrekt ist. So ist es z.B. möglich, dass Minimain der Nähe starker Anstiege übersprungen werden (Beispiel d in obiger Abbildung), oder dassdas Verfahren an Plateaus hängenbleibt (Beispiel b in obiger Abbildung), die einen geringenAnstieg haben aber kein Minima der Fehlerfunktion darstellen.

In der vorliegenden Implementierung des MLP wurde deshalb Gleichung 2.10 erweitert undder Momentum Term µ eingeführt5 (siehe [RHW88]). Für die Berechnung der Gewichtsverän-derung, gilt:

W(l)ij := W

(l)ij − (4W (l)

ij (t) + µ4W (l)ij (t− 1)) (2.16)

In der obigen Formel steht t für die aktuelle und t-1 für die letzte Gewichtsänderung. Zur Ge-wichtsänderung wird also die letzte Gewichtsänderung hinzu addiert, die mit dem Momentum-Term multipliziert wird. Der Momentum Term verstärkt die Gewichtsänderung, wenn4W (l)

ij (t)und 4W (l)

ij (t− 1) das gleiche Vorzeichen haben. Dadurch wird die Gewichtsänderungsrate aufPlateaus erhöht und bei wechselndem Vorzeichen verringert (siehe Beispiel c in obiger Abbil-dung). Allerdings ist es auch hier möglich, dass ein lokales Minima wieder verlassen wird, danicht zwischen einem Plateau und einem Minima unterschieden werden kann.

4Quelle: siehe [GGKK07][Seite 66]

5Die Variable µ ist in dem MLP-Framework standardmäßig auf 0.8 festgelegt und wird im Rahmen dieserArbeit nicht verändert.


2.1.5 ADAGRAD

Wie im Abschnitt 2.1.2 erwähnt, ist die Lernrate in der vorliegenden Implementierung eineKonstante. Mit ADAGRAD existiert ein Algorithmus, der die Lernrate für jedes Verbindungs-gewicht wi,j individuell anpasst. ADAGRAD steht für „adaptive gradient“ (siehe [DHS11]).

Dieser Algorithmus setzt voraus, dass die vorherigen und die aktuelle partielle Ableitungfür jede Gewichtsverbindung in einem Vektor ~

w(l)ij gespeichert sind. Dann ergibt sich folgende

Lernrate α für das Verbindungsgewicht W :

α(t) = η

| ~w(l)ij |

= η√t∑

τ=1( ∂∂W J(τ))2

(2.17)

In obiger Gleichung stellt η eine globale konstante Lernrate dar, die durch die l2-Norm,über alle vorherigen und die aktuelle partielle Ableitung, dividiert wird. Daraus folgt, dass dieSchrittweite bei großen Gradienten kleiner ist, als bei kleinen Gradienten.6 Eine weitere Folgeist, dass die Lernrate in jeder Iteration reduziert wird, bis die Gewichtsänderungen nahe Nullsind.

Das ADAGRAD-Verfahren wurde von Dean et al. mit Downpour SGD benutzt und erzieltedort sehr gute Ergebnisse (siehe [DCM+12][Seite 5]). Inwieweit sich ADAGRAD für MBGD oderBGD eignet, wird in Abschnitt 6.6 untersucht.

An dieser Stelle sei, auch wenn es im Rahmen dieser Arbeit nicht verwendet wird, nochauf das ADADELTA-Verfahren (siehe [Zei12]) verwiesen. Es erweitert ADAGRAD, so dass dieglobale Lernrate η entfällt, basiert jedoch zum Teil auf Verfahren zweiter Ordnung (Hesse-Matrix).

2.1.6 Resilient Propagation

Resilient Propagation (Rprop) ist ein von Riedmiller et al. entwickeltes Batch Lernverfahren(siehe [RB92]). Eine Besonderheit von Rprop ist, dass das Gewichtsupdate nicht von der Größedes Gradienten, sondern nur von dem Vorzeichen des Gradienten beeinflusst wird. Es ähneltMomentum und ADAGRAD dahingehend, dass Gradienten aus vorhergehenden Iterationen mitin die Berechnung einbezogen werden.

Rprop wurde unter anderem von Igel et al. weiterentwickelt (siehe [IH00]). Nachfolgend wirddeshalb deren verbesserte Variante: iRprop+ vorgestellt.

6Diese Vorgehensweise entspricht einem Vorschlag von Haykin (siehe [Sim05][Seite 206, 4.6.8]), zur Bestim-mung der Lernrate in den unterschiedlichen Schichten des künstlichen neuronalen Netzes.


Die Schrittweite4ij(t) mitWij(t+1) = Wij(t)+4ij(t) wird für Rprop und davon abgeleiteteVerfahren folgendermaßen festgelegt:

4ij(t) :=

η+ · 4ij(t− 1) , für ∂J(W,b)

∂Wij(t− 1) · ∂J(W,b)

∂Wij(t) > 0

η− · 4ij(t− 1) , für ∂J(W,b)∂Wij

(t− 1) · ∂J(W,b)∂Wij

(t) < 0

4ij(t− 1) , sonst

(2.18)

Allgemein gilt: 0 < η− < 1 < η+. Das heißt, dass die Schrittweite verringert wird, wenn sichdas Vorzeichen im Vergleich zur letzten Iteration geändert hat und gleich bleibt, wenn sich dasVorzeichen nicht ändert. Dieses Vorgehen hilft, die bereits in Unterabschnitt 2.1.4 geschildertenProbleme zu mildern.

1 for each Wij do

2 if ∂J(W,b)∂Wij

(t− 1) · ∂J(W,b)∂Wij

(t) > 0 then

3 4ij(t) := min(4ij(t− 1) · η+,4max)

4 4Wij(t) := −sign(∂J(W,b)∂Wij

(t))· 4ij(t)

5 Wij(t+ 1) := Wij(t) +4Wij(t)6 elseif ∂J(W,b)

∂Wij(t− 1) · ∂J(W,b)

∂Wij(t) < 0 then

7 4ij(t) := max(4ij(t− 1) · η−,4min)8 if(J(W, b)t > J(W, b)t−1) then

9 Wij(t+ 1) := Wij(t)−4Wij(t− 1)10 else

11∂J(W,b)∂Wij

(t) := 012 elseif ∂J(W,b)

∂Wij(t− 1) · ∂J(W,b)

∂Wij(t) = 0 then

13 4Wij(t) := −sign(∂J(W,b)∂Wij

(t))· 4ij(t)

14 Wij(t+ 1) := Wij(t) +4Wij(t)15 fi

16 od

Listing 2.1: iRprop+ in Pseudocode

Die Zeilen 3 und 7 in obigem Listing zeigen, dass die Schrittweite nach oben (4max) undunten (4min) begrenzt ist. Die Zeilen 8 bis 11 zeigen, wie „weight backtracking“ mit iRprop+

durchgeführt wird. Im Gegensatz zu Rprop wird hier nach einem Vorzeichenwechsel überprüft,ob die Änderung des Vorzeichens auch zu einem größeren Fehlerwert führt. Ist dies der Fall,dann wird die letzte Gewichtsänderung rückgängig gemacht.

Riedmiller et al. untersuchten in ihrer Arbeit, welche Werte für η+, η−,4min und4max opti-mal sind. Im Rahmen dieser Arbeit sind, wie von Riedmiller et al. empfohlen (siehe [RB92][Seite3]), diese Werte folgendermaßen festgelegt: η+ = 1.2, η− = 0.5,4min = 1e−6,4max = 50.


2.1.7 Autoencoder

Der Autoencoder Algorithmus wurde von Hinton et al. zum Trainieren von neuronalen Netzenmit mehreren versteckten Schichten („deep learning“) entwickelt (siehe [HS06b]). Diese Formvon neuronalen Netzen lässt sich sonst laut Hinton et al. nur sehr langsam trainieren, da derGradient kleiner ist, je weiter eine versteckte Schicht von der Ausgabeschicht entfernt ist. DiesesProblem ist als „vanishing gradient“ bekannt und wurde von Hochreiter im Zusammenhang mitrekurrenten neuronalen Netzen beschrieben (siehe [Hoc98]), gilt aber auch für „feed-forward“Netze.

Aus diesem Grund wird der Autoencoder im „deep learning“ benutzt, um die verstecktenSchichten des neuronalen Netzes in mehreren Schritten nacheinander zu initialisieren („pre-training“). Es zeigte sich, das mit einem Autoencoder trainierte neuronale Netze eine deutlichbessere Performance erzielen können, als vergleichbare Ansätze (siehe z.B. [LRM+12]). Dies seiaber nur zur Motivation, der Verwendung eines Autoencoder im „deep learning“, erwähnt, dadie im Rahmen dieser Arbeit benutzten neuronalen Netze lediglich über eine versteckte Schichtverfügen.

Ein weiterer Anwendungsfall für Autoencoder ist die Dimensionsreduktion bzw. Hauptkom-ponentenanalyse (PCA, siehe z.B. [GKWZ07]). Dafür eignet sich z.B. der nachfolgend erläuterteSparse Autoencoder.

Sparse Autoencoder

Wie zu Beginn dieses Kapitels erwähnt, gilt bei Benutzung eines Autoencoder, dass die Eingabegleich der Ausgabe ist, also y(i) = x(i). Die Lösung hierfür scheint trivial, da ein Netzwerk, beidem Eingabe-, versteckte und Ausgabeschicht die gleiche Größe haben, die Eingabe einfachweiterleiten müsste, z.B. mit Wij = 1 wenn i = j und Wij = 0 wenn i <> j.

Ist jedoch die Anzahl der Neuronen in der versteckten Schicht geringer, als die Größedes Eingabevektors, dann muss die Eingabe vom neuronalen Netz rekonstruiert werden (sie-he [And][Seiten 12-16]), z.B. durch das Finden von Korrelationen zwischen Eingabedaten.

p̂ = 1m

m∑i=1

[a

(2)j (x(i))

](2.19)

Um dies auch für Netze mit versteckten Schichten beliebiger Größe zu ermöglichen wird der„sparsity parameter“ p und der Begriff des Sparse Autoencoder eingeführt. In einem SparseAutoencoder wird erzwungen, dass die durchschnittliche Ausgabe p̂ eines Neurons (siehe Glei-chung 2.19) in einer versteckten Schicht über alle m-Trainingsdaten gleich p ist, mit kleinem p

z.B. p = 0.0001.

Um das zu erreichen, wird die Berechnung des Fehlerwerts (vgl. Gleichung 2.13), in ei-nem neuronalen Netz mit einer versteckten Schicht, folgendermaßen um einen „penalty“ Term


erweitert:

δ(2)i =

(( s2∑j=1

W(2)ji δ

3j

)+ β

(− p

p̂i+ 1− p

1− p̂i

))f ′(z(2)

i ). (2.20)

Bevor das Backpropagation Verfahren angewendet werden kann, muss also p̂i für alle i-Neuronender versteckten Schicht berechnet werden.

Denoising Autoencoder

Mit dem Denoising Autoencoder, wurde eine weitere Variante des Autoencoder von Vincent etal. entwickelt (siehe [VLBM08]). Wie im Standardverfahren gilt hier y(i) = x(i). Allerdings wirdbeim Training der Eingabevektor „beschädigt“, so dass statt x(i) der Vektor x̃(i) als Eingabedient. Als Ausgabe wird weiterhin x(i) erwartet.

Der Eingabevektor x̃(i) wird erzeugt, indem nach dem Zufallsprinzip eine oder mehrere Ein-gaben auf null gesetzt werden. Dadurch wird das neuronale Netz gezwungen den Vektor x(i)

aus der „beschädigten“ Eingabe zu rekonstruieren. Das bedeutet weiterhin, dass das neuronaleNetz in jeder Iteration mit leicht veränderten Eingabedaten aber gleichen Ausgabedaten/Er-wartungswerten trainiert wird.

Laut Vincent et al. konnte hiermit, im Vergleich mit den besten Verfahren, eine mindes-tens ähnliche bis deutliche bessere Performance erreicht werden. Im Vergleich mit einem Au-toencoder, wies der Denoising Autencoder in allen Tests eine bessere Performance auf (sie-he [VLBM08][Seite 7]).

2.2 Bulk-Synchronous Parallel Model

In den folgenden Unterkapiteln wird das BSP Modell beschrieben. Es wird im Rahmen dieserArbeit zum Verteilen aller Berechnungen in einen Cluster mit mehreren Rechnern benutzt.Weiterhin wird das Java-Framework Apache Hama vorgestellt, welches eine Implementierungdes BSP Modells ist.

2.2.1 Algorithmus

Das BSP Modell ist ein Verfahren, zum parallelen Ausführen von Berechnungen. Dieses Verfah-ren kann sowohl auf Hard- als auch auf Softwareebene implementiert werden und wurde vonLeslie G. Valiant entwickelt (siehe [RS98]).

Valiant beschreibt BSP als eine Kombination der folgenden drei Attribute (vgl. mit Abbil-dung 2.5):

1. Eine beliebige Anzahl von Komponenten, die Berechnungs- und/oder Speicherfunktiona-litäten bieten.

7Quelle: siehe http://en.wikipedia.org/wiki/Bulk_synchronous_parallel

http://en.wikipedia.org/wiki/Bulk_synchronous_parallel


Barrier Synchronisation

Local Computation

Communication

Processors

Abbildung 2.5: bulk-synchronous parallel modell7

2. Ein Router, der Nachrichten über Punkt-zu-Punkt-Verbindungen zwischen den einzelnenKomponenten ausliefert.

3. Es gibt die Möglichkeit alle oder einen Teil der Komponenten zu synchronisieren. Diessoll in einem festen Zeitintervall L geschehen. Eine Berechnung ist eine Abfolge aus einemoder mehreren Supersteps. In jedem Superstep erhält jede Komponente eine Aufgabe,die eine Kombination aus lokalen Berechnungen und dem Empfangen bzw. Senden vonNachrichten sein kann. Im fixen Zeitabstand L wird überprüft, ob der Superstep vonallen Komponenten abgeschlossen wurde. Erst wenn dieser der Fall ist, wird der nächsteSuperstep gestartet.

Ein vergleichbarer Ansatz für das Verteilen von Berechnungen in einen Cluster ist z.B.Message Passing Interface (MPI) (siehe [GLS94]). Auch hier erfolgt die Kommunikation mitHilfe von Nachrichten. Allerdings mit dem Unterschied, dass MPI nicht nur Punkt-zu-PunktVerbindungen, sondern auch Punkt-zu-Mehrpunkt Verbindungen (Broadcast, Multicast) expli-zit unterstützt. Außerdem werden hier mehrere Abstufungen zur Synchronisation von mehrerenRechnern unterstützt, was in dem BSP-Framework Apache Hama sehr strikt geregelt ist.


2.2.2 Apache Hama

Architektur

Abbildung 2.6: Architektur von Apache Hama8

In Abbildung 2.6 wird die in mehrere Schichten unterteilte Architektur (siehe[SYK+10][Seiten 1-2]) von Apache Hama dargestellt. Es besteht aus den drei KomponentenHama Core, Hama Shell und der Hama API und unterstützt die Verfahren MapReduce (sie-he [DG08]), BSP und Dryad.

Das Framework: Zookeeper (siehe [Whi11][Seiten 441-476]) wird zur Manipulation verteilterMetadaten und zur Transaktionskontrolle verwendet. Zur Ablage und zum Einlesen von Datenkann unter anderem das verteilte Dateisystem Hadoop Distributed Filesystem (HDFS) (siehe[Whi11][Seiten 41-128]) verwendet werden, dass u.a. den Vorteil der Datenlokalität bietet.

Ein BSP-Job wird von einem oder mehreren BSP-Peers (Threads) ausgeführt und bestehtaus mindestens einem Superstep. In der Job-Konfiguration kann unter anderem festgelegt wer-den, wie viele BSP-Peers insgesamt benutzt werden sollen.

In der Konfigurationsdatei eines Rechners wird festgelegt, wie viele BSP-Peers auf diesemRechner gestartet werden können. Das Framework verteilt die BSP-Peers nicht gleichmäßig imCluster, sondern auf möglichst wenige Rechner, um die Kommunikationskosten so gering wiemöglich zu halten.

Lesen/Schreiben von Daten

Bevor man einen BSP-Job starten kann, muss im ersten Schritt die Klasseorg.apache.hama.bsp.BSP erweitert und mindestens die bsp()-Methode überschriebenwerden. Dessen Signatur sieht wie folgt aus:

8Quelle: siehe [SYK+10][Seite 1]


1 public abstract void bsp(BSPPeer<K1, V1, K2, V2, Mextends Writable> peer) throws . . . ;

Listing 2.2: Methodensignatur von BSP.bsp()

In der obigen Methodensignatur werden Eingabe, Ausgabe und Kommunikation für den gesam-ten BSP-Job festgelegt. K1 und V1 stehen für die Eingabe, die aus dem Schlüssel (K1) und demdazugehörigen Wert (V1) bestehen. K2 und V2 bilden das Äquivalent für die Ausgabe. M stehtfür das zur Kommunikation benutzte Nachrichtenformat. Das Hama Framework kennt bereitseinige Standardformate z.B. Text, LongWritable und NullWritable.

Eine Besonderheit dieser Methode ist, dass sie während der gesamten Laufzeit des Pro-gramms, auf jedem BSP-Peer nur einmal aufgerufen wird. Wird diese Methode wieder verlassen,dann endet der BSP-Job, der wiederum aus einem oder mehreren Supersteps bestehen kann.Diese Besonderheit ermöglicht es Daten über mehrere Supersteps hinweg im Arbeitsspeicherzu halten. Im MapReduce-Verfahren ist das z.B. nicht möglich, da Map- bzw. Reduce-Methodestatuslos sind und mehrmals aufgerufen werden.

Die Dateneingabe kann aus einer oder mehreren Text- oder Sequenzdateien (siehe[Whi11][Seiten 116-123]) bestehen. Das Framework übernimmt standardmäßig das Aufsplit-ten der Daten in möglichst gleich große Teile, um auch die Rechenlast möglichst gleichmäßigzu verteilen. Es kann auch eine eigene Splitfunktion angegeben werden.

Innerhalb der bsp()-Methode erfolgt die Datenein- und -ausgabe mit Hilfe der BSPPeer-Klasse. Jeder BSP-Peer kann nur auf seinen Teil der Daten zugreifen, die jeweils lokal vorliegenund sich während eines BSP-Jobs nicht ändern.

Jeder BSP-Peer kann den Dateizeiger wieder auf den Anfang setzen, so dass in einer Iterationwieder von vorne begonnen werden kann. Es wird jedoch vom Framework nicht die Möglichkeitgegeben, z.B. zu einem bestimmten Datensatz zurück springen. Dazu müsste der Dateizeigerauf den Anfang und dann nicht benötigte Datensätze übersprungen werden, bis der gewünschteDatensatz erreicht ist. Auch ein Zwischenspeichern von Datensätzen im Arbeitsspeicher ist vonApache Hama zur Zeit nicht vorgesehen.

Kommunikation und Synchronisation

Jeder BSP-Peer wird durch einen eindeutigen Namen adressiert, der sich aus dem Rechnernamenund einen IP-Port zusammensetzt. Die Adressierung von BSP-Peers erfolgt mit Hilfe dieseseindeutigen Namens. Jeder BSP-Peer auf einem Rechner kommuniziert über seinen eigenenIP-Port.

Die BSPPeer-Klasse hat Methoden um den eigenen Peer-Namen und um alle Peer-Namenabzufragen, der Peers die mit diesem Job beschäftigt sind. Außerdem bietet sie die Möglichkeiteinzelne Nachrichten und die Gesamtanzahl an Nachrichten abzurufen.

Die BSPPeer-Klasse bietet mit der peer.send(String peerName, BSPMessage msg)-Methodedie einzige Möglichkeit zur Kommunikation zwischen BSP-Peers.


Im Listing 2.3 wird die Kommunikation zwischen BSP-Peers an einem kleinem Beispielgezeigt. Der BSP-Job führt in diesem Beispiel 100 Supersteps aus (siehe Zeile 4), in denen jederBSP-Peer jedem BSP-Peer eine Nachricht sendet.

Die Synchronisation der einzelnen BSP-Peers erfolgt in Zeile 8. Die Nachrichten werden inder Synchronisationsphase (Barriere) verteilt und sind erst nachdem alle BSP-Peers die Barriereverlassen haben verfügbar. Diese Methode muss von allen BSP-Peers aufgerufen werden, dasonst eine SyncException geworfen und der Job beendet wird. Es gibt also nicht die Möglichkeitz.B. nur ausgewählte BSP-Peers miteinander zu synchronisieren.

1 @Override

2 public void bsp (BSPPeer<NullWritable, NullWritable, Text, DoubleWritable, Text> peer)

3 throws . . . {

4 for (int i=0; i<100; i++) {

5 for (String peerName : peer.getAllPeerNames()) {

6 peer.send(peerName, new Text("Hello from " + peer.getPeerName()));

7 }

8 peer.sync();

9 }

10 }

Listing 2.3: Beispiel der Kommunikation zwischen BSP-Peers

Kapitel 3

Anforderungsanalyse

In diesem Kapitel werden zu Beginn zwei Studien vorgestellt, welche unterschiedliche Ansätzezur Verteilung eines künstlichen Neuronalen Netz in einem Cluster untersuchen. Im zweitenUnterkapitel wird das MLP-Framework analysiert. Sowohl die Erkenntnisse aus den Studien alsauch die Analyse des Frameworks sind die Grundlage, für die am Ende des Kapitels formulierteZielstellung.

3.1 Verwandte Studien

3.1.1 Studie 1: Using the BSP Cost Model to Optimize ParallelNeural Network Training

In ihrer Arbeit untersuchen Rogers et al. verschiedene Methoden zur Verteilung eines MLP mitdem BSP Modell und BGD (siehe [RS98]). Sie unterscheiden zwischen Exemplar Parallelism(EP), Block Paralellism (BP) und Neuron Parallelism (NP).

Bei EP erhält jeder BSP-Peer das Modell, so dass alle Rechner den gleichen Stand haben.Die BSP-Peers berechnen den Gradienten für ihren Teil der Daten, berechnen den Gradienten-Durchschnitt und das Gewichtsupdate. Zum Ende einer Iteration hat jeder BSP-Peer ein Modell,das mit allen Trainingsdaten trainiert wurde. Bei BP wird das Modell in Blöcke von benachbar-ten Neuronen aufgeteilt, dabei ist ein BSP-Peer für die Berechnungen eines Blocks zuständig.Wenn jeder Block alle Neuronen einer Schicht enthält, wird das Layer Parallelism genannt.Bei NP wird jedem BSP-Peers die gleiche Anzahl von Neuronen zugewiesen, dabei werden dieNeuronen zufällig zugeteilt. Die Lokalität wird bei NP also nicht berücksichtigt.

Rogers et al. beweisen in Ihrer Arbeit, dass sich EP am besten zur Parallelisierung einesMLP eignet. Dies liegt darin begründet, dass hier die Anzahl an Supersteps und Synchronisati-onsphasen am geringsten ist. Die Kommunikationskosten sind bei EP demzufolge ebenfalls amkleinsten.

KAPITEL 3. ANFORDERUNGSANALYSE 22

3.1.2 Studie 2: Large Scale Distributed Deep Networks

Dean et al. beschreiben in ihrer Arbeit (siehe [DCM+12]) die Verteilung der Berechnung einesneuronalen Netzes in einen Cluster, mit ihrem Framework: „DistBelief“. Zur Verteilung be-

Abbildung 3.1: Verteilung eines neuronalen Netzwerks, am Beispiel lokal verbundener Neuro-nen.2

nutzen sie Block Parallelism. Das Modell wurde, wie in Abbildung 3.1 dargestellt, in mehrerePartitionen gesplittet und dann auf mehrere Rechner verteilt.

Diese Form der Modellverteilung wurde u.a. auf ihre horizontale Skalierbarkeit untersucht.Dabei stellte sich hier heraus, dass neuronale Netze mit lokal verbundenen Neuronen eine bes-sere Skalierbarkeit aufweisen, als Netze mit voll verbundenen Neuronen. Das liegt laut Deanet al. darin begründet, dass neuronale Netze mit lokal verbundenen Neuronen geringere An-forderungen an die Kommunikation stellen. In Abbildung 3.1 wird der Kommunikationsflusszwischen den Rechnern durch die dickeren Linien dargestellt.

Abbildung 3.2: Links: Downpour SGD. Rechts: Sandblaster L-BFGS3

2Quelle: siehe [DCM+12]

3Quelle: siehe [DCM+12]


Dean et al. beschreiben unterschiedliche Vorgehensweisen für SGD- und BGD-Verfahren, diein Abbildung 3.2 schematisch dargestellt werden. Beiden Ansätzen ist gemein, dass nicht alleRechner eines Clusters auf einen oder mehrere langsamere Rechner warten müssen.

Bei SGD wird das Modell auf voneinander unabhängige Rechnergruppen verteilt. Jede Rech-nergruppe komuniziert asynchron mit einem Parameterserver. Die einzelnen Rechnergruppenberechnen Gewichtsupdates für ihren Teil der Daten, senden das Gewichtsupdate an den Pa-rameter Server und erhalten im Gegenzug das neueste Modell. Dies hat zur Folge, dass jedeGruppe mit einem leicht unterschiedlichen Modell arbeitet.

Eine Besonderheit des hier vorgestellten BGD-Ansatzes ist, dass für N-Rechnergruppen, dieBatchgröße durch einen Wert kleiner N geteilt wird. Die Kommunikation außerhalb der Rech-nergruppen erfolgt auch hier asynchron und wird zusätzlich durch einen Coordinator-Servergesteuert.

Die hier benutzten Verfahren stellen eine Mischung aus Exemplar und Block Parallelismdar. Die einzelnen Rechnergruppen benutzen Block Parallelism. Die Arbeit wird aber wie beiExemplar Parallelism, durch Aufteilen der Datensätze auf die einzelnen Rechnergruppen para-llelisiert. Zusammenfassend lässt sich hier feststellen, dass durch die asynchrone Kommunikationeine hohe Flexibilität erreichbar ist, die mit BSP nicht realisierbar ist.

Zusammenfassung

Wie gut sich ein künstliches neuronales Netz in einem Cluster verteilt trainieren lässt, dass hängtu.a. davon ab wie die Berechnungen verteilt werden bzw. wie das neuronale Netzes aufgebautist. In den untersuchten Studien wurden zwei unterschiedliche Ansätze untersucht. Rogers etal. verfolgten einen synchronen Ansatz mit BSP und betrachteten voll verbundene künstlicheneuronale Netze. Dean et al. verfolgten einen asynchronen Ansatz und untersuchten sowohl vollals auch lokal verbundene Netze.

Sowohl Rogers et al. als auch Dean et al. kamen zu dem Schluss, dass sich voll verbundeneNetze mit Block Parallelism nur stark begrenzt verteilen lassen. Dean et al. stellten weiter-hin fest, dass lokal verbundene Netze mit Block Parallelism besser als voll verbundene Netzeskalieren, da hier die Kommunikationskosten geringer sind. Lokal verbundene Netze skalierenlaut Dean et al. mit BP, in Abhängigkeit von der Modellgröße, je größer um so besser ist dieSkalierbarkeit.

Rogers et al. empfehlen die Benutzung von Exemplar Parallelism. Dean et al. kombinierenExemplar und Block Parallelism miteinander, was so aber nicht mit BSP sinnvoll realisierbarist.

Im Rahmen dieser Arbeit sind lokal verbundene Netze nicht Gegenstand der Untersuchung.Aus den oben genannten Gründen wird deshalb Exemplar Parallelism verwendet.


3.2 Analyse des MLP Frameworks

An dieser Stelle soll das verwendete MLP Framework näher betrachtet werden, um darausfolgend die Zielstellungen zu definieren.

3.2.1 Speicherung der Verbindungsgewichte

In dem Framework werden Verbindungsgewichte, wie in Abschnitt 2.1 beschrieben, in Form vonMatrizen gespeichert. Als Eingabe werden Vektoren erwartet. In Folge daraus werden auch alleRechenoperationen entweder auf Matrizen- oder Vektoren angewandt.

Die dafür benutzten Klassen entstammen der Mathe-Bibliothek des Apache Mahout Pro-jekts (siehe [Apa]). Bei genauerer Untersuchung der Mathe-Bibliothek wurde im Rahmen dieserArbeit festgestellt, dass die Multiplikation zweier Matrizen recht einfach mit der Standard-Matrizenmultiplikation gelöst wurde. Hier existieren u.a. der Strassen oder der Winograd Al-gorithmus, die effizienter als das Standardverfahren sind (siehe [CH13]).

Laut mehreren Benchmarks (siehe [Abe]) gibt es eine Reihe von leistungsfähigen Frameworksfür die lineare Algebra. Ein performantes Framework scheint laut diesen Benchmarks z.B. jblas(siehe [Bra]) zu sein, dass ein Java-Wrapper für BLAS/LAPACK (siehe [TCCDL]) und ATLAS(siehe [det]) ist.

Daraus folgt, dass die im MLP-Framework verwendete Matrizenbibliothek austauschbar seinund dessen Performanz mit anderen Bibliotheken verglichen werden sollte.

3.2.2 Lernverfahren

In dem MLP Framework wurde ein auf Verfahren erster Ordnung basierender SGD implemen-tiert, dass heißt, dass jedes Trainingsbeispiel auch ein Gewichtsupdate zur Folge hat. Dies kannmit BSP und EP nicht unverändert verwendet werden. Hier gilt es also die Berechnung der Gra-dienten von den Gewichtsupdates zu trennen. Auch der implementierte Sparse Autoencoder istein Online-Lerner und muss angepasst werden.

Zur Berechnung der Gradienten wird das Backpropagation Verfahren verwendet. Als Opti-mierungsverfahren wurde Momentum implementiert.

3.2.3 Tests

Es wurden eine Reihe von Softwaretests implementiert. Hervorzuheben ist der Test des Backpro-pagation Verfahrens. Hier wird der vom Framework berechnete Gradient mit einem numerischenAnnäherungsverfahren überprüft (siehe [And][Seiten 10-12]).

Laut diesen Tests, ist das MLP korrekt implementiert worden. Ein Test des Sparse Auto-encoder fehlt. Allerdings wird der Sparse Autoencoder im Rahmen dieser Arbeit auch nichtverwendet.


3.3 Zielstellung

In dem folgenden Kapitel wird die Zielstellung detailliert formuliert. Die darin formuliertenfunktionalen Anforderungen, bezüglich der Initialisierung des MLP und der Trainingsalgorith-men, ergeben sich aus den bereits in den Grundlagen beschriebenen Verfahren. Die restlichenfunktionalen Anforderungen entstammen der Entwurfsphase, siehe Kapitel 4.

3.3.1 Funktionale Anforderungen

Cache

• Cache:Beschreibung: Es soll die Möglichkeit geben, die Eingabedaten im Arbeitsspeicher zuhalten.

Datenformat

• Datenformat:Beschreibung: Es soll für diese Anwendung ein allgemeingültiges Datenformat entwickeltwerden.

Datenaufbereitung

• Dictionary:Beschreibung: Es soll die Möglichkeit geben, die Eingabe- und Ausgabeneuronen miteinem Wörterbuch zu verknüpfen, um die Ergebnisse im Falle der von Xing extrahiertenProfildaten evaluieren zu können.

• Normalisierung:Beschreibung: Je nach Anwendungsfall sollen Eingabedaten beim Parsen normalisiert wer-den können.

• Parser:Beschreibung: Es sollen Quell-Daten geparst und in das eigens entwickelte Datenformatüberführt werden.

Datenspeicherung

• Datenspeicherung:Beschreibung: Es soll die Möglichkeit geben, das trainierte neuronale Netz abzuspeichern,um es später weiter trainieren oder auswerten zu können.


Evaluierung der Ergebnisse

• Datenformat:Beschreibung: Es soll die Möglichkeit geben, ein trainiertes neuronales Netz zu evaluieren.Die Metriken Precision, Recall und F-measure sollen zur Auswahl stehen.

Fehlerwert

• Fehlerwert:Beschreibung: Es soll die Möglichkeit geben, den durchschnittlichen Fehlerwert über alleTrainingsdaten zu berechnen.

Kommunikation

• Kommunikation:Beschreibung: Es sollen verschiedene Kommunikationsstrategien implementiert werden.

Initialisierung der Gewichte

• Glorot-Bengio:Beschreibung: Es soll möglich sein, das Verfahren von Glorot-Bengio zur Initialisierungdes neuronalen Netzes zu benutzen.

• Ngyen-Widrow:Beschreibung: Es soll möglich sein, das Verfahren von Ngyen-Widrow zur Initialisierungdes neuronalen Netzes zu benutzen.

• Yann Lecun:Beschreibung: Es soll möglich sein, das Verfahren von Yann Lecun zur Initialisierung desneuronalen Netzes zu benutzen.

Matrizenbibliothek

• Matrizenbibliothek:Beschreibung: Es soll die Möglichkeit geben, die Matrizenbibliothek auszutauschen.

Trainingsalgorithmen

• Adagrad:Vorbedingung: Es wird nicht Resilient Propagation benutzt.Beschreibung: Es soll die Möglichkeit geben, Adagrad zum Trainieren des neuronalenNetzes zu benutzen.

• Batch Gradient Descent:Beschreibung: Es soll die Möglichkeit geben, Big-Batch Lernverfahren zum Trainieren desneuronalen Netzes zu benutzen.


• Mini-Batch Gradient Descent:Beschreibung: Es soll die Möglichkeit geben, Mini-Batch Lernverfahren zum Trainierendes neuronalen Netzes zu benutzen.

• MLP-Framework:Beschreibung: Es soll das bereits bestehende MLP-Framework in die Anwendung integriertwerden.

• Momentum:Beschreibung: Es soll die Möglichkeit geben, bei Bedarf Momentum zu benutzen.

• Resilient Propagation:Vorbedingung: Big-Batch Lernverfahren. Der Fehlerwert wurde für die letzten beidenIterationen berechnet.Beschreibung: Es soll die Möglichkeit geben, Resilient Propagation zum Trainieren desneuronalen Netzes zu benutzen.

• Denoising Autoencoder:Beschreibung: Es soll die Möglichkeit geben, die Eingabedaten in Verbindung mit einemAutoencoder zu verrauschen.

3.3.2 Nicht-Funktionale-Anforderungen

Skalierung

• Skalierung:Beschreibung: Das System sollte eine gute horizontale und vertikale Skalierbarkeit auf-weisen.

3.3.3 Abgrenzungskriterium

Im Rahmen dieser Arbeit werden nur MLP mit einer versteckten Schicht betrachtet. Weiterhinwird davon ausgegangen, dass das zu trainierende Modell in den Arbeitsspeicher passt. DieBerechnungen werden nach Exemplar Parallelism verteilt. Der Sparse Autoencoder wird nichtimplementiert.

Kapitel 4

Entwurf

In diesem Kapitel wird die Anwendung entworfen. Es werden das System und einzelne System-komponenten beschrieben und verschiedene Ansätze zur Realisierung diskutiert. Der SparseAutoencoder wurde zwar nicht implementiert, dennoch wird für zukünftige Arbeiten das hierzunötige Vorgehen am Ende des Kapitels beschrieben.

4.1 Systembeschreibung

Datenvorverarbeitung

Daten bereinigen (op.onal)

Daten normalisieren (op.onal)

Trainings-‐/ Evalua.onsdaten

erzeugen

Training des künstlichen neuronalen Netzes (MLP)

Modell verteilen

MLP ini.alisieren/ verteilen

Trainingsdaten lesen / GradientendurchschniA

berechnen

Quelldaten einlesen

Einstellungen laden

Gewichtsupdate berechnen / Modell updaten

Modell speichern (op.onal)

Evaluation

Modell laden

Metriken berechnen

Ergebnisse ausgeben

Evalua.onsdaten einlesen

Daten cachen (op.onal)

X-Iterationen

Abbildung 4.1: Systemübersicht

KAPITEL 4. ENTWURF 30

Im Rahmen dieser Arbeit soll eine Anwendung zum verteilten Trainieren eines MLP erstelltwerden. Diese Anwendung muss eine Reihe von Aufgaben erfüllen, die sich in Datenvorverar-beitung, Training und Evaluation des trainierten MLP gliedern lassen (siehe Abbildung 4.1).

Innerhalb der Datenvorverarbeitung findet das Parsen der Quelldaten statt. Je nach Anwen-dungsfall findet an dieser Stelle auch eine Bereinigung und Normalisierung der Daten statt. DerTrainingsvorgang ist ein iteratives Verfahren mit mehreren Einzelschritten. Bevor das Trai-ning beginnt werden Einstellungen geladen, das MLP auf allen BSP-Peers mit den gleichenWerten initialisiert und falls gewünscht die Trainingsdaten gecacht. Die Evaluation erlaubt dieBewertung des trainierten Netzwerks.

Diese Schritte werden in den nachfolgenden Unterkapiteln genauer beschrieben.

4.1.1 Datenvorverarbeitung

Die Datenvorverarbeitung erfolgt in einer Pipeline von mehreren aufeinander aufbauendenSchritten. Nachdem sie eingelesen wurden, müssen die Quelldaten eventuell bereinigt werden.Im Falle der Textverarbeitung sind hier eine Reihe von Schritten denkbar. So könnten Stoppwör-ter entfernt werden. Das sind z.B. bestimmte/unbestimmte Artikel oder Konjugationen, die mitHilfe einer „part of speech“ (POS) Erkennung ermittelt werden. Sie kommen meist sehr oft vor,sind aber für die eigentliche Analyse nicht von Bedeutung. Ein Beispiel für die POS Erkennung,ist der Log-linear Part-Of-Speech Tagger der Stanford NLP-Gruppe (siehe [TKMS03]).

Außerdem könnten z.B. Texte einer nicht unterstützten Sprache entfernt werden, wenn nurdeutsche Texte verarbeitet werden sollen. Im nächsten Schritt müssen je nach Anwendungs-fall die Quelldaten normalisiert werden. Im Falle von Textdaten könnten einzelne Wörter aufihren Wortstamm zurückgeführt werden (stemming, Lemmatisierung, siehe [MS99] Seiten 131-134). Andernfalls kann es vorkommen, dass Wörter mit dem gleichen Wortstamm mehrmals imEingabevektor vorkommen.

Die Wörter im Eingabevektor, könnten weiterhin mit der Term Frequenz und der Dokumen-tenhäufigkeit gewichtet werden (Term weighting, siehe [MS99] Seiten 541f). Mit dieser Formder Gewichtung, werden Wörter die sehr oft vorkommen, aber evtl. geringen Informationsge-halt haben, geringer gewichtet, als Wörter die sehr selten vorkommen, aber evtl. einen großenInformationsgehalt haben. In einem binären Wortvektor erfolgt keine solche Gewichtung, dahier nur enthalten ist, ob ein Wort in einem Satz vorkam oder nicht, was eventuell negativeAuswirkungen auf die Ergebnisse des Trainings hat.

Sollen Zahlenwerte als Eingabe benutzt werden, die in unterschiedlichen Wertebereichenvorkommen, dann sollten diese laut Cabreira et al. (siehe [CTM09]) in einen gemeinsamenWertebereich überführt werden (siehe Anhang E, Seite 93). Die Skalierung kann laut Cabreiraet al. zu besseren Resultaten führen. Im Falle der MONK-Daten erfolgte deshalb eine Skalierungaller Eingabedaten auf den Wertebereich: [0, 1].

Zum Schluss müssen die Daten schließlich geparst und gespeichert werden. Die Daten werdenim verteilten Dateisystem HDFS gespeichert. Hier wurde sich für ein Textformat entschieden,


um die Trainingsdaten leicht mit anderen Frameworks austauschen zu können. Das zugrunde-liegende Datenformat wird in dem folgenden Unterkapitel beschrieben.

Datenformat

< data >:=< labels > | < features > (4.1)

< labels >:=< indexL1 >:< valueL1 > < indexL2 >:< valueL2 > ... (4.2)

< features >:=< indexF1 >:< valueF1 > < indexF2 >:< valueF2 > ... (4.3)

Im Rahmen dieser Arbeit wird zum Beschreiben von Trainingsdaten, dass in Gleichung 4.1,Gleichung 4.2 und Gleichung 4.3 dargestellte Datenformat genutzt. Es entspricht einer Erwei-terung des u.a. in LIBSVM (siehe [CL11]) verwendeten Datenformats.

Die Ein- (Features) und Ausgabedaten (Labels) werden durch „|“ voneinander getrennt. ImGegensatz zu LIBSVM werden mehrere Label unterstützt, die genau wie die Features durch einLeerzeichen voneinander getrennt sind.

Jedes Wertepaar besteht aus einem Index und einem Wert. Die Indizes müssen vom TypInteger sein. Sie entsprechen dem Index im Ein- bzw. im Ausgabevektor, beginnend bei null. Diedazugehörigen Werte müssen vom Typ Double sein. Es müssen nur Werte angegeben werden,die ungleich null sind. Die Werte fehlender Indizes werden als gleich null betrachtet und belegenunter Verwendung eines „sparse Vector“ keinen Arbeitsspeicher.

Um Trainingsdaten zu erzeugen, die dem oben beschriebenen Datenformat entsprechen,muss für jeden Anwendungsfall ein Parser geschrieben werden. Der Parser überführt dann dieQuelldaten in das Trainingsdatenformat.

4.1.2 verteiltes Training mit BSP

Wie in Abbildung 4.1) auf der Seite 29 dargestellt, ist der Trainingsvorgang ein iteratives Ver-fahren, das eine Reihe von Einzelkomponenten voraussetzt. Dieses Kapitel gibt einen Überblicküber das Trainingsverfahren und beschreibt das Cachen von Daten im Arbeitsspeicher, die Feh-lerwertberechung und mehrere Ansätze der Kommunikation. Der Trainings-Algorithmus wirdnoch einmal detaillierter in Form von Pseudo-Code in Anhang F auf der Seite 95 dargestellt.

In Abbildung 4.2 (Seite 32) wird das verteilte Training eines neuronalen Netzes für eineIteration dargestellt. Die Parallelisierung des Trainings ergibt sich aus Gleichung 2.9 auf Seite 9,indem die Berechnung des Gradienten parallelisiert wird. Die Trainingsdaten werden in mehrerePartitionen gesplittet. Die Anzahl an Partitionen entspricht der Anzahl an BSP-Peers. DasTraining erfolgt in zwei Phasen.

In der ersten Phase berechnet jeder BSP-Peer den Gradienten, für seinen Anteil an dengesamten Trainingsdaten. Die Gradienten werden aufsummiert und zum Ende dieser Phasedurch die Batchgröße geteilt. Wenn alle BSP-Peers damit fertig sind, senden sie ihre partielleSumme an einen Master-Peer.


Par$$on I Par$$on III Par$$on II

Par$al Gradient Sum Par$al Gradient Sum Par$al Gradient Sum

Gradient Sum

Synchroniza$on Barrier

Synchroniza$on Barrier

Compute Model Update & Distribute Model

Abbildung 4.2: Schematische Darstellung des Vorgehens innerhalb einer Iteration.

In der zweiten Phase berechnet der Master-Peer aus den partiellen Summen den Gradien-ten1. Der Gradient wird dann zur Berechnung des Gewichtsupdates benutzt, das dann auf dasModell angewendet wird. Das neue Modell wird schließlich an alle BSP-Peers verteilt und dienächste Iteration beginnt. Das Vorgehen entspricht Exemplar Parallelism.

Das hier beschriebene Vorgehen, ließe sich auch mit dem MapReduce Ansatz realisieren. Dieerste Phase ließe sich mit der Map-Phase und die zweite Phase mit der Reduce-Phase abbilden.Zumindest die MapReduce Implementierung von Apache Hadoop (siehe [Whi11][Seiten 167ff])hat jedoch den Nachteil, dass sie keine Iterationen unterstützt. Das heißt hier müsste für jedeIteration ein neuer Job gestartet werden, wodurch auch für jede Iteration das Modell neu geladenund gespeichert werden müsste.

Caching

Um ein MLP mit den hier vorgestellten Verfahren zu trainieren, bedarf es eine große Anzahl vonIterationen. In jeder Iteration müssen die gleichen Trainingsdaten geladen und geparst werden.Hier bietet es sich an, Trainingsdaten im Arbeitsspeicher zu halten. Dies wird aber von ApacheHama nicht direkt unterstützt.

Hier sind mehrere Vorgehensweisen denkbar. Zum einen könnte man die geparsten Daten imArbeitsspeicher halten. Zum anderen könnte man die Daten serialisieren, komprimieren, kom-primiert im Speicher halten und nur bei Bedarf dekomprimieren und de-serialisieren. LetztereVariante würde sich anbieten, wenn der Arbeitsspeicher der Rechner nicht ausreichend groß ist.

1Die Gradientensumme wird bei der Binary Tree Kommunikation bereits in der Kommunikationsphase ge-bildet (siehe Abschnitt 4.1.2, 35).


Für diese Arbeit wird die erste Variante implementiert. Von jedem BSP-Peer wird der jeweilszugewiesene Anteil an den Trainingsdaten komplett im Speicher gehalten. Weitere Strategienzur Realisierung eines Caches sollten in zukünftigen Arbeiten untersucht werden.

Apache Hama bietet wie bereits erläutert keine Methoden zum Cachen von Daten. DerCache könnte aber mit einem Wrapper, um die von Apache Hama gebotene Funktionalität zumLaden von Daten, realisiert werden. Hier bietet sich z.B. die Aspektorientierte Programmierungmit aspectj (siehe [Fou]) an, da es sich bei dieser Anforderung um einen „cross-cutting concern“handelt. Aus Zeitgründen musste jedoch auf aspectj verzichtet werden.

Fehlerwertberechnung

Die Berechnung des Fehlerwerts ist für das Trainieren eines Netzwerks essentiell. Er ist ein Maßdafür, wie gut sich ein künstliches neuronales Netz an die Trainingsdaten angepasst hat.

Für die Fehlerwertberechnung wird festgelegt, dass der Fehlerwert sowohl bei BGD als auchbei MBGD über alle Trainingsdaten berechnet wird. Der Fehlerwert wird bei beiden Verfahrenaußerdem nur dann berechnet, wenn das MLP mit allen Trainingsdaten trainiert wurde. Zumeinen schwanken dadurch die Fehlerwerte nicht so stark, als wenn sie nur für einen Teil der Datenberechnet würden, zum anderen lassen sich mit BGD oder MBGD ermittelte Fehlerwerte besservergleichen.

Der Zeitpunkt zur Berechnung des Fehlerwerts bei MBGD bzw. bei BGD kann unterschied-lich gewählt werden. Zur Berechnung des Gradienten,für ein Trainingsbeispiel, wird der Outputdes neuronalen Netzes benötigt (siehe Gleichung 2.12 auf Seite 11). Dieser Output wird auchzur Berechnung des Fehlerwertes für dieses Trainingsbeispiel verwendet (vgl. mit Gleichung 2.8auf Seite 9). Um den Output nicht zweimal zu berechnen, sollte der Fehlerwert bei BGD zu-sammen mit dem Gradienten berechnet werden. Dabei gilt es zu beachten, dass der Fehlerwertfür das in der vorherigen Iteration berechnete Modell gilt.

Bei MBGD kann dieser Vorteil nicht genutzt werden, da sich mit jedem Mini-Batch auchdas Modell ändert, was den Fehlerwert verfälschen würde. Der Fehlerwert kann bei MBGD alsonur dann berechnet werden, wenn über alle Trainingsdaten iteriert wurde.

Kommunikation

Bei der Betrachtung der Kommunikation, gilt es einige Dinge zu berücksichtigen. So musszwischen der Kommunikation von Prozessen auf dem selben Rechner und der Kommunikationüber Rechnergrenzen hinweg unterschieden werden.

Bei letzterem erstellt man üblicherweise eine Kostenmatrix und einen Verbindungsgraphen,in dem dargestellt wird welcher Rechner mit welchem Rechner verbunden ist. In den Ver-bindungsgraphen fließen die Verbindungskosten ein. Dazu gehört nicht die rein physikalischeEntfernung zwischen zwei Rechnern, sondern die verfügbare Bandbreite und die Latenz. Derkürzeste Weg zwischen zwei Rechnern würde z.B. mit dem Dijkstra-Algorithmus berechnet wer-den. Dadurch könnte u.a. die Kommunikation zwischen Rechnern in unterschiedlichen Rechen-


zentren optimiert werden. Darauf muss allerdings im Rahmen dieser Arbeit aus Zeitgründenverzichtet werden.

Im Rahmen dieser Arbeit wird angenommen, dass die Kommunikationskosten für alle Rech-ner gleich groß sind, unabhängig davon mit welchem Rechner sie kommunizieren. Es wird weiterangenommen, dass alle Rechner sich in dem selben physikalischen Netzwerk befinden und übereinen Switch miteinander verbunden sind. Die Rechner kommunizieren über Punkt-zu-PunktVerbindungen und teilen sich nicht die verfügbare Bandbreite, wie es in einem über Hub ver-bundenen Netzwerk der Fall wäre.

Das in Listing F.1 auf der Seite 95 beschriebene Verfahren stellt unterschiedliche Anfor-derungen an die Kommunikation. Die Synchronisation der Rechner wird durch Apache Hamageregelt und hier nicht weiter betrachtet.

In den Zeilen 12-13 bzw. 20-21 wird ein Durchschnitt berechnet. Das heißt, hier müssenDaten von mehreren BSP-Peers eingesammelt und daraus dieser Wert berechnet werden. In derFachliteratur ist diese Kommunikationsform als „all-to-one reduction“ bekannt (siehe [Kri94],Seite 147ff).

Im Gegensatz dazu, muss in Zeile 13 bzw. in Zeile 25 ein Wert von einem BSP-Peer analle anderen BSP-Peers verteilt werden. In der Fachliteratur ist diese Kommunikationsform als„one-to-all broadcast“ bekannt (siehe [Kri94], Seite 147ff).

Wie bereits beschrieben unterstützt Apache Hama nur Punkt-zu-Punkt Verbindungen, wes-halb im Rahmen dieser Arbeit verschiedene Kommunikationsstrategien entwickelt wurden. Inden folgenden Unterkapiteln werden diese Ansätze näher betrachtet.

Sequentielle Kommunikation. Sequentiell bedeutet, dass Aufgaben nacheinander undnicht parallel verarbeitet werden. Das trifft streng genommen, nur für den ersten, der nach-folgend beschriebenen Abläufe zu.

Im „one-to-all broadcast“ werden Daten von einem BSP-Peer an alle BSP-Peers gesendet.Das erfolgt in diesem Ansatz sequentiell. Der BSP-Peer sendet also nacheinander die Datenan die anderen BSP-Peers, dabei wird nicht zwischen lokalen BSP-Peers und BSP-Peers aufentfernten Rechnern unterschieden. Die Gesamtdauer der Kommunikation verhält sich linearzur Anzahl an BSP-Peers. Die verfügbare Bandbreite, zwischen zwei BSP-Peers, kann durch diePunkt-zu-Punkt Verbindung voll ausgenutzt werden. Ein Nachteil dieses Ansatzes ist jedoch,dass immer nur zwei BSP-Peers miteinander kommunizieren, während die restlichen BSP-Peerswarten müssen.

Die Berechnung des Durchschnitts erfolgt auf jedem BSP-Peer2. Die daraus resultierendenDaten werden dann von allen BSP-Peers zur gleichen Zeit an den Master-Peer gesendet. DerMaster-Peer bildet nur noch die Summe der Einzelergebnisse. Auch bei dieser Kommunikati-

2Die von jedem BSP-Peer berechneten Einzelergebnisse werden lokal aufsummiert und durch die gesamteAnzahl an Trainingsdaten bzw. bei MBGD durch die Mini-Batch-Größe mulipliziert mit der Anzahl an BSP-Peers geteilt.


onsstrategie wird nicht zwischen lokalem und entfernten BSP-Peer unterschieden. Die Kom-munikation erfolgt parallel, es wird allerdings auch die verfügbare Bandbreite zwischen allenBSP-Peers aufgeteilt.

Die sequentielle Kommunikation ist bei beiden Strategien innerhalb eines Supersteps abge-schlossen. Sie ist sehr einfach zu implementieren und ausreichend schnell, wenn ausschließlichlokale Prozesse miteinander kommunizieren, da zwischen lokalen Prozessen die Kommunikati-onskosten vernachlässigbar gering sind.

Abbildung 4.3: Binary Tree Kommunikation in drei Phasen am Beispiel von acht Rechnern3

Binary Tree Kommunikation. In diesem Verfahren, werden Daten in mehreren Superstepsverteilt. Das Vorgehen ist beispielhaft in Abbildung 4.3 für acht Rechner dargestellt. JedemRechner wurde eine eindeutige Zahl als Name zugewiesen, beginnend mit der Zahl: eins.

Sei m die gesamte Anzahl an Rechnern, x die Nummer des Rechners der Daten sendet, ydie Nummer des Rechners an den Daten gesendet werden, n die Schrittnummer und nmax diemaximale Zahl von Schritten. Dann kommunizieren in jedem Schritt 2n Rechner miteinander.Die Schrittnummer beginnt mit der Zahl: eins und wird für jede Iteration um eins hochgezählt.

Welcher Rechner jeweils mit welchem Rechner kommuniziert, ergibt sich dann aus der For-mel: y = x + 2n−1. Ein Rechner kommuniziert nur dann, wenn gilt: y <= 2n. Daraus folgtschließlich: nmax = log2 m. Ist Es muss log2 m, wenn es keine ganze Zahl ist, auf die nächsteganze Zahl aufgerundet werden.

Bei der „all-to-one“ Kommunikation, wird dieses Verfahren einfach umgedreht. Diesmal wirddie Schrittnummer n runtergezählt und zu Beginn gilt: n = nmax = log2 m. Weiterhin gilt:y = x − 2n−1. Ein Rechner kommuniziert nur, wenn gilt: 0 < y <= 2n−1. Das Aufsummieren,der durch die Batch-Größe geteilten Daten, erfolgt hier, im Gegensatz zum sequentiellen Ansatz,bereits während der Kommunikation. Jeder Empfänger einer Nachricht bildet die Teilsumme,über die in der Nachricht enthaltenen und den lokal vorliegenden Daten

Für die Binary Tree Kommunikation wird zwischen lokalen und entfernten BSP-Peers diffe-renziert. Ansonsten würden sich die miteinander kommunizierenden BSP-Peers die Netzwerk-Bandbreite teilen, was wieder zu Lasten der Performance gehen würde. Bevor also über dasNetzwerk kommuniziert wird, senden alle lokalen BSP-Peers ihre Daten an einen lokalen BSP-Peer. Die gesamte Kommunikation ist in nmax + 1 Supersteps abgeschlossen.


Binary Tree ist optimal, wenn die Rechneranzahl eine Potenz von zwei ist. Der worst caseist gegeben, wenn die Rechneranzahl um eins größer als eine Potenz von zwei ist, da hier in derletzten Kommunikationsphase bis auf zwei Rechner alle Rechner warten müssen.

Zusammenfassung Die Kommunikationskosten werden maßgeblich von zwei Faktoren be-stimmt, der zu übertragenden Datenmenge und der Kommunikationsform. Die Datenmengewird dominiert von der Anzahl an Neuronenverbindungen. Sie verhält sich linear zur Anzahlan Neuronenverbindungen, außerdem besteht ein quadratischer Zusammenhang zur Anzahl anNeuronen. Verdoppelt man die Zahl der Neuronen, dann vervierfacht sich die Anzahl an Neu-ronenverbindungen, in einem voll verbundenen Netz mit einer versteckten Schicht.

Bezüglich der Kommunikationsform ist zu erwarten, dass die sequentielle Kommunikationlangsamer als die Binary Tree Kommunikation ist, sobald über Rechnergrenzen hinweg kommu-niziert wird. Die Kommunikationskosten werden hier vermutlich deutlich schneller steigen, sodass ab einer bestimmten Rechneranzahl keine nennenswerte horizontale Skalierung mehr ge-geben ist. Es wurden dennoch beide Ansätze implementiert, da für lokale Tests die sequentielleKommunikation ausreicht.

Das Problem der „one-to-all broadcast“ Kommunikation, gleicht dem Problem von verteiltenDateisystemen und Peer-2-Peer Netzen. Ein interessanter Ansatz könnte z.B. „Chunk basedparallel tree“ sein (siehe [BRF04][Seite 10]), der aber aus Zeitgründen nicht weiter untersuchtwerden konnte. Hier gilt es in zukünftigen Arbeiten eine optimale Vorgehensweise zu finden.

4.1.3 Evaluation

Die Evaluation dient der Qualitätsmessung und wird nach dem Training des künstlichen neu-ronalen Netzes ausgeführt. Üblicherweise wird die Evaluation mit einem Satz von Daten („goldstandard“4) durchgeführt, die nicht Teil der zum Trainieren verwendeten Daten sind, um einAuswendiglernen zu erkennen bzw. zu vermeiden.

Für die Evaluation spielen in dieser Arbeit, sowohl die Neuronen in der versteckten Schicht,als auch die Neuronen in der Ausgabeschicht eine Rolle. Welche Form der Evaluation angewen-det wird hängt vom Anwendungsfall ab.

Im Falle der Klassifizierung und der Regression sind nur die Neuronen in der Ausgabeschichtvon Bedeutung. Es werden nacheinander alle Daten des Testsets als Eingabe angelegt, dabeiwird jeweils die Ausgabe ausgewertet. Im Falle der MONK-Daten liegen die Ausgabewerte imBereich: [0, 1]. Ein Wert größer 0.5 gilt als zu Klasse I gehörig. Ein Wert kleiner 0.5, gilt alsnicht zu Klasse I gehörig. Mit Hilfe aller Messwerte und der Metriken: Precision, Recall undF-measure (siehe Anhang D, 91), wird dann die Qualität bestimmt. Außerdem wird für jedeKlasse der Durchschnittswert und die Standardabweichung aller Ergebnisse berechnet (siehe

4Manning et al. beschreiben hier (siehe [MRS08], Kapitel 8.1) zwar die Evaluation von „information retrieval“Systemen mit einem „gold standard“ das Prinzip ist jedoch das gleiche.


Anhang C, Seite 89), um die Verteilung der Ergebnisse zu bestimmen. Je näher die Ergebnissedes Testsets bei null bzw. bei eins liegen, um so besser ist das Netzwerk zumindest im Falle derMONK-Daten trainiert worden.

Im Falle der Xing-Daten werden zusätzlich die Neuronen in der versteckten Schicht be-trachtet. Jedes versteckte Neuron lernt ein bestimmtes Feature. Welches Features das ist, wirdermittelt durch das Finden des Inputs, der den höchsten Ausgabewert bei dem verstecktenNeuron verursacht, dabei wird die Norm des Vektors begrenzt (siehe [And], Seiten 16-18). Mitz gleich der Anzahl an Neuronen der Eingabeschicht, x gleich dem Eingabevektor und unterder Bedingung: ||x2|| =

∑zi=1 x

2i ≤ 1 gilt,

xj =W

(1)ij√∑z

j=1(W (1)ij )2

(4.4)

Die obige Formel wird auf alle Neuronen der versteckten Schicht angewendet. Für jedes ver-steckte Neuron erhält man einen Vektor, der zumindest im Falle der Xing-Daten nach der Größesortiert wird 5. Der Inhalt des Vektors kann dann weiter ausgewertet werden.

4.2 Sparse Autoencoder

1 filePointer <- SaveFilePointer();

2 for(batchProcessed<= batchSize) {

3 activationSum <- activationSum +CalculateHiddenNeuronActivation();

4 }

5 SetFilePointer(filePointer);

6 CalculateAverageNeuronActivation();

7 DistributeAverageNeuronActivation();

Listing 4.1: Sparse Autoencoder mit BSP in Pseudocode

Wie in Gleichung 2.20 auf Seite 16 ersichtlich, muss das Backpropagation Verfahren bei Ver-wendung des Sparse Autoencoder angepasst werden. Hier muss zusätzlich die Berechnung derdurchschnittlichen Neuronenaktivierung der Neuronen in der versteckten Schicht erfolgen (sieheListing 4.1, Zeilen 2-4). Dabei gilt es zu beachten, dass die durchschnittliche Neuronenaktivie-rung nur für die im (Mini-) Batch zu verwendenden Trainingsdaten berechnet werden muss.

Bedingt durch den Datenzugriff von Apache Hama, muss hierfür der Dateizeiger gespeichertwerden (siehe Listing 4.1, Zeile 1), z.B. durch das Zählen von bereits verarbeiteten Datensätzen.Zum Abschluss dieses Zwischenschritts, muss der Dateizeiger wieder zurück gesetzt werden(siehe Listing 4.1, Zeile 5), damit der Gradient für die gleichen Datensätze berechnet wird.

5Zum Beispiel bei Bilddaten, mit einzelnen Pixeln als Eingabe, muss man die Reihenfolge beibehalten.


Jeder BSP-Peer berechnet die Teilsumme der durchschnittlichen Aktivierung aller Neuronenund sendet sie an den Master-Peer (siehe Listing 4.1, Zeile 6). Die durchschnittliche Neuro-nenaktivierung wird je nach Kommunikationsstrategie auf dem Master-Peer oder als Teil derKommunikation ausgerechnet. Der Master-Peer verteilt die durchschnittliche Neuronenaktivie-rung dann auf alle BSP-Peers (siehe Listing 4.1, Zeile 7), damit diese den Gradienten berechnenkönnen.

Die Neuronenaktivierung für jedes Trainingsbeispiel, wird auch für das danach folgendeBackpropagation Verfahren zur Berechnung des Gradienten benötigt (siehe Gleichung 2.12 undGleichung 2.13 auf Seite 11). Um diesen Schritt nicht zweimal auszuführen, könnte die Neuro-nenaktivierung im Arbeitsspeicher gehalten und dort wiederverwendet werden.

Mit der sequentiellen Kommunikation werden zwei Supersteps benötigt. Mit der Binary TreeKommunikation werden 2 ∗ log2 m Supersteps benötigt.

Kapitel 5

Implementierung

Dieses Kapitel beschreibt im Detail, die Implementierung der im Entwurf vorgestellten System-komponenten: Datenverarbeitung, Training und Evaluation. Außerdem enthält es am MLP-Framework vorgenommene Änderungen, Details die bei der Verwendung von Apache Hamabeachtet werden mussten und eine Beschreibung der Softwaretests.

5.1 Datenverarbeitung

5.1.1 Cache

Der Cache wurde implementiert, indem die I/O-Methoden von Apache Hama in einer Methodegekapselt wurden. Jeder BSP-Peer speichert nur seinen Teil der Daten in seinem Cache. In derersten Iteration, werden die I/O-Methoden von Apache Hama genutzt und der Cache gefüllt. Abder zweiten Iteration werden die Daten nur noch aus dem Cache geladen. Der Cache wurde inForm einer Liste realisiert, dabei wurde davon ausgegangen, dass der verfügbare Arbeitsspeicherimmer für die Trainingsdaten ausreicht.

Die Eingabedaten werden in dem in Abschnitt 4.1.1 beschriebenen Format erwartet undliegen in Form von Textdateien vor. Das MLP erwartet aber Vektoren, die mit Double-Wertengefüllt sind. Beim Füllen des Caches, werden die Textdaten deshalb geparst und in Form vonVektoren gespeichert.

Durch die Benutzung des Caches muss zum einen das Parsen der Trainingsdaten nur einmaldurchgeführt werden, zum anderen werden die Daten aus dem Arbeitsspeicher schneller als vonder Festplatte geladen.

5.1.2 Trainingsdaten

Die Trainingsdaten werden in dem in Abschnitt 4.1.1 beschriebenen Datenformat erwartet.Quelldaten müssen also vorher in dieses Format überführt werden.

KAPITEL 5. IMPLEMENTIERUNG 40

IParser <<interface>>

+parse(String input): List<MLDataEntry>

XingParser MonkParser

Abbildung 5.1: Parser-Klassen

Für die beiden Anwendungsfälle MONK (siehe Unterabschnitt 6.2.2, Seite 51) und Xing-Daten (siehe Abschnitt 6.7, Seite 69) wurden Parser zum Überführen der Quelldaten in Trai-ningsdaten implementiert (siehe Abbildung 5.1). Beide Parser implementieren das InterfaceIParser, erwarten einen Textzeile als Eingabe und geben eine Liste mit dem geparsten Inhalt,in Form eines MLDataEntry (siehe Abbildung 5.2), zurück. Ein Trainingsbeispiel besteht auseinem Feature- und einem Zielvektor, dessen Größe von der Anzahl an Eingaben bzw. derNeuronenanzahl in der Ausgabeschicht abhängt. Der jeweilige Vektor ist ein RandomAccess-SparseVector, d.h. es werden nur Daten im Speicher gehalten, die ungleich null (0) sind.

MLDataEntry

+targetVector:,RandomAccessSparseVector+featureVector:,RandomAccessSparseVector

+MLDataEntry(nbInputUnits:int,nbOutputUnits:int)

Abbildung 5.2: Trainingsdaten-Klasse

Bezüglich der MONK-Daten musste beachtet werden, dass die Features/Eingabedaten inunterschiedlichen Wertebereichen liegen. Hierfür musste also vorher eine Normalisierung (sieheAnhang E, Seite 93) durchgeführt werden.

Die für den zweiten Anwendungsfall benötigten Xing-Daten wurden von Prof. Dr. Hertazur Verfügung gestellt. Sie wurden von der Xing-Webseite gecrawlt und mussten in mehrerenSchritten vor-verarbeitet werden. Hier wurden zum einen die Rohdaten vor-verarbeitet und zumanderen eine Wörterliste erstellt, da „bag of words“ als Features verwendet werden. Genaueresdazu in Abschnitt 6.7.

Für die Erstellung der Trainingsdaten zur XOR-Funktion wurde kein extra Parser geschrie-ben, da diese Funktion nur vier verschiedene Zustände kennt und somit ein Parser nicht not-wendig gewesen ist.


5.2 MLP-Framework

Das MLP-Framework enthält eine Reihe von Klassen, wie z.B. Kostenfunktion, die Matrizenbi-bliothek sowie Java-Factories zum Erzeugen von Matrizen und Vektoren. Für diese Arbeit amwichtigsten war die Java-Klasse de.mlp_distributed.mlp.core.MultiLayerPerceptron, da sie dieAlgrorithmen zum Trainieren eines MLP enthält. Sie ist in Abbildung A.3 auf der Seite 80 inForm eines UML-Diagramms dargestellt. Die Abbildung beschränkt sich aus Platzgründen aufdie wichtigsten Methoden.

Die ursprüngliche Implementierung war ein reiner Online-Lerner, d.h. das mit jedem Trai-ningsbeispiel auch das Modell angepasst wurde. Aus diesem Grund wurden Berechnung desGradienten und Berechnung des Gewichtsupdates voneinander getrennt. Die KlasseMultiLayer-Perceptron wurde außerdem dahingehend abgeändert, dass sich der Momentum-Term abschal-ten lässt, indem man den Momentum-Wert auf null setzt. Ansonsten würde Speicher für dieletzte Gewichtsänderung reserviert werden, auch wenn Momentum nicht verwendet wird.

Diese Klasse wurde außerdem um die Initialisierungsmethoden von Glorot & Bengio undNguyen &Widrow, sowie um die adaptive Lernrate ADAGRAD und das Lernverfahren iRprop+erweitert.

5.2.1 Initialisierung der Verbindungsgewichte

Bevor das MLP trainiert werden kann müssen die Verbindungsgewichte mit einem zufällig ge-wählten Wert initialisiert werden (siehe Unterabschnitt 2.1.1, Seite 8). Das MLP-Framework in-itialisiert die Verbindungsgewichte standardmäßig nach dem Verfahren von LeCun. Im Rahmendieser Arbeit erfolgte die Implementierung von zwei weiteren Algorithmen zur Initialisierungder Verbindungsgewichte, die nachfolgend genauer anhand von Codeausschnitten vorgestelltwerden.

1 final double distValue =Math.sqrt(6) / Math.sqrt(fanOut+ fanIn);

2 for (int i = 0; i < fanOut; i++) {

3 for (int j = 0; j < fanIn; j++) {

4 double weight = (2 * distValue * randomNumberGenerator.nextDouble()) - distValue;

5 this.weights[ l ].setQuick(i , j , weight);

6 }

7 }

Listing 5.1: Initialisierung der Verbindungsgewichte mit dem Verfahren von Glorot-Bengio

Im obigem Codeausschnitt ist die Initialisierung der Verbindungsgewichte nach dem Algorith-mus von Glorot & Bengio ausschnittsweise in Form von Java-Code dargestellt. Der Wertebereichin dem die Verbindungsgewichte liegen wird in Zeile eins festgelegt und wird unter Einbeziehungder Anzahl an eingehenden bzw. ausgehenden Verbindungen einer Schicht bestimmt. In Zeile


vier wird für jedes Gewicht eine Zufallszahl ermittelt und in den vorher bestimmten Wertbereichüberführt.

Das Verfahren von Nguyen & Widrow ist ausschnittsweise in Listing 5.2 dargestellt. Auchhier erfolgt die Berechnung des Verbindungsgewichts in Abhängigkeit zur Anzahl an Verbin-dungsgewichten in zwei Schichten (siehe Zeile eins).

Im ersten Schritt erfolgte eine zufällige Initialisierung der Verbindungsgewichte, die dannim Wertebereich [−1, 1] liegen (Zeile 2). Im zweiten Schritt wird für jedes Neuron die Vektor-norm über die eingehenden Verbindungsgewichte berechnet (Zeilen 4-9). Damit die Vektornorm|W l

i | = 0.7 · (fanout)fan−1in entspricht, werden die Verbindungsgewichte (Zeilen 11-15) entspre-

chend angepasst.

1 final double beta = 0.7 * Math.pow(this.nbUnits[1] + 1, 1.0 / (this.nbUnits[0] + 1));

2 initializeWeightsRandomly(-1,1);

3 // Berechne die Norm.

4 double norm= 0.0;

5 for (int j = 0; j < weightMatrix.columnSize(); j++) {

6 final double weight =weightMatrix.getQuick(i , j);

7 norm+=weight * weight;

8 }

9 norm=Math.sqrt(n);

10 // Passe das Gewicht an.

11 for (int j = 0; j < weightMatrix.columnSize(); j++) {

12 double weight =weightMatrix.getQuick(i , j);

13 weight = (beta * weight) / norm;

14 weightMatrix.setQuick(i , j , weight);

15 }

Listing 5.2: Initialisierung der Verbindungsgewichte mit dem Verfahren von Nguyen-Widrow

5.2.2 Matrizen-Bibliotheken

Wie im Entwurf beschrieben, sollte die Matrizenbibliothek austauschbar sein. Das ist nur mög-lich, durch die Definition einer gemeinsamen Schnittstelle. An dieser Stelle werden die bereitsin Apache Mahout enthaltenen Schnittstellen „org.apache.mahout.math.Vector“ (siehe Abbil-dung A.4, Seite 81) und „org.apache.mahout.math.Matrix“1 als gemeinsame Schnittstelle be-nutzt. Diese Schnittstellen werden bereits vom MLP-Framework verwendet, so dass an demMLP-Framework keine Änderungen vorgenommen werden mussten.

1Die Klassenhierarchie der Matrizen-Klassen ähnelt der Darstellung in Abbildung A.4, deshalb wurde aufeine Darstellung verzichtet.


Die Klassen de.mlp_distributed.mlp.math.jblas.JDenseVector und de.mlp_distributed.mlp.math.jblas.JDenseMatrix kapseln die jblas-Bibliothek, indem sie intern die Klasse DoubleMa-trix aus dieser Bibliothek benutzen. Es wurden jeweils nur die Methoden der Schnittstelleimplementiert, die vom MLP-Framework auch tatsächlich verwendet werden.

Das MLP-Framework wurde dahingehend geändert, dass Matrizen und Vektoren nicht mehrdirekt, sondern mittels Factory Klassen erzeugt werden. Diese Factories werden wiederum voneiner Factory-Klasse zur Verfügung gestellt, die ausschnittsweise unten dargestellt wird. DieFactory Klassen werden mittels Dependency Injection geladen (siehe Listing 5.3, Zeilen 1-4).Hierzu wurde das Framework guice von Google verwendet (siehe [Goo]). Das Binding erfolgtüber von der Klasse com.google.inject.AbstractModule abgeleitete Klassen (Zeilen 11-17). Indiesem Beispiel wird standardmäßig die Mahout-Bibliothek verwendet. Es existiert allerdingsauch eine Methode mit der das Binding verändert werden kann.

1 @Inject

2 MatrixFactory matrixFactory;

3 @Inject

4 VectorFactory vectorFactory;

5 public static Factory getInstance() {

6 if (Factory.instance== null) {

7 return Factory.getInstance(new FactoryModule());

8 }

9 return Factory.instance;

10 }

11 private static class FactoryModule extends AbstractModule {

12 @Override

13 protected void configure() {

14 this.bind(VectorFactory.class).to(MahoutVectorFactory.class);

15 this.bind(MatrixFactory.class).to(MahoutMatrixFactory.class);

16 }

17 }

Listing 5.3: Factory-Klasse zur Erzeugung von Matrix von Matrix- und Vektor-Factories

Durch diese Schritte, kann die Matrizenbibliothek jederzeit ausgetauscht werden, ohne dasÄnderungen am MLP-Framework nötig sind. Ein Vergleich der Performance zwischen MahoutsMatrizenbibliothek und jblas erfolgt in Unterabschnitt 6.4.3 auf Seite 61.

5.2.3 Trainingsalgorithmen

Die adaptive Lernrate ADAGRAD wurde wie in Gleichung 2.17 dargestellt implementiert. Umzu große Lernraten zu verhindern, musste jedoch der Divisior angepasst werden. Der Divi-


sor wird nun auf eins festgelegt, wenn er kleiner als 10−8 ist. Ansonsten kam es bei kleinenMini-Batch Größen und daraus folgend vielen Gewichtsupdates bereits sehr früh vor, dass dieGewichtsverbindungen gegen plus oder minus unendlich gingen. Für ADAGRAD wird für jedesGewicht die letzte Quadratsumme über die Gradienten in einer Matrix gespeichert, allerdingsnur auf dem Master-Peer, da nur die Lernrate zur Berechnung des Gewichtsupdates benötigtwird.

Das Batch-Lernverfahren iRprop+ wurde wie in Listing 2.1 dargestellt implementiert. Hiermusste die letzte Gewichtsänderung in einer Matrix gespeichert werden. Außerdem wird immerder aktuelle und der letzte Fehlerwert benötigt. Für iRprop+ muss demzufolge zwingend derFehlerwert in jeder Iteration berechnet werden. Sowohl Fehlerwert als auch die Matrix mit derletzten Gewichtsänderung werden nur auf dem Master-Peer gespeichert.

Der Denoising Autoencoder verrauscht den Feature Vektor. Dazu musste die Methode zumLaden eines Trainingsbeispiels angepasst werden. Der Denoising Autoencoder wurde so imple-mentiert, dass nur Trainingsdaten verrauscht werden, deren Feature Vektor größer zwei ist.Mit 20-prozentiger Wahrscheinlichkeit, werden bis auf eine Ausnahme alle Werte des Feature-Vektors auf null gesetzt. Ansonsten werden zufällig 50-Prozent des Feature Vektors auf nullgesetzt. Diese Werte entstammen dem MLP-Framework und wurden übernommen.

5.3 verteiltes Training mit BSP

Die Anwendung zum verteilten Training des MLP wird mit Hilfe von Apache Maven gebaut,dabei wird eine JAR-Datei erzeugt. Das Training wird mit Hilfe dieser JAR-Datei und der Klas-se de.distMLP.Train_MultilayerPerceptron gestartet, die den Pfad zu einer Property-Datei alsEingabe erwartet (siehe nächstes Unterkapitel). Diese Klasse führt wenn notwendig das Auf-splitten der Trainingsdaten in mehrere Dateien durch und startet den BSP-Job. Der BSP-Jobkann lokal oder auf einem BSP-Cluster ausgeführt werden. Wird ein BSP-Job lokal ausgeführt,dann wird ein BSP-Cluster emuliert.

Die Klassenhierarchie der zum Training verwendeten BSP-Klassen wird in Abbildung A.5auf der Seite 82 in Form eines UML-Diagramms dargestellt.

Die Klasse Base_MLP_Trainer ist eine abstrakte Klasse und erweitert die BSP-Klasse. Hierfinden sich mehrere Methoden, die beim Starten und beim Beenden des BSP-Jobs aufgerufenwerden. Außerdem findet hier die Kapselung der I/O-Methoden von Apache Hama für denCache statt. Die Eingabedaten können hier für den Denoising Autoencoder verrauscht werden,was bei jeder Iteration erneut durchgeführt wird. Sie regelt weiterhin das regelmäßige Speicherndes MLP-Modells und das Updaten des Modells auf dem Master-Peer.

Die Klasse MLP_MiniBatchGD ist von dieser Klasse abgeleitet. Sie überschreibt die bsp()-Methode, in der das eigentliche Training des MLP geregelt wird (siehe Listing F.1, Seite 95).Diese Klasse unterstützt BGD und MBGD in Verbindung mit den Lernverfahren Momentumund ADAGRAD. Das Lernverfahren iRprop+ kann mit Hilfe der von dieser Klasse abgeleite-


ten Klasse MLP_RPROP verwendet werden, welche die Methode zum Updaten des Modellsüberschreibt.

5.3.1 Initialisierung & Cleanup

Bevor ein BSP-Job startet müssen Einstellungen geladen und das MLP initialisert werden.Alle Einstellungen sind in einer Properties-Datei gespeichert, die beim Starten des BSP-Jobsinterpretiert wird. Um eine Evaluierung des MLP vornehmen zu können oder ein abgebrochenesTraining fortzusetzen, kann an dieser Stelle auch ein bereits trainiertes MLP geladen werden.

Die Properties-Datei erlaubt das Verändern von ca. 40 Standardwerten. Dazu gehören un-ter anderem der Aufbau des neuronalen Netzes, der Speicherort der Trainingsdaten, dass zuverwendende Trainingsverfahren und dessen Parameter, der Speicherintervall und der Zielfeh-lerwert. Zur Initialisierung des MLP wurde die setup()-Methode der BSP-Klasse überschrieben(siehe Abschnitt 2.2.2, Seite 18). Hier musste beachtet werden, dass alle BSP-Peers den gleichenSeed-Wert zur zufälligen Initialisierung des MLP verwenden, damit auch alle BSP-Peers mitdem gleichen Modell starten.

Ist ein BSP-Job zu Ende, dann wird die cleanup()-Methode der BSP-Klasse aufgerufen, dieebenfalls überschrieben wurde. An dieser Stelle wird, falls gewünscht, dass Modell in eine Dateigespeichert.

5.3.2 Kommunikation

Serialisierung

Die Kommunikation zwischen BSP-Peers basiert auf Nachrichten. Diese Nachrichten müssenals einzige Bedingung die Writable Klasse erweitern.

Bei den zu versendenden Daten handelt es sich um Java Objekte, die vor dem Versen-den serialisiert werden müssen. Im Rahmen dieser Arbeit wurden Java-Serialisierung und dasFramework kryo (siehe [eso]) in Betracht gezogen. Da kryo laut deren Webseite sowohl beimSerialisieren als auch Deserialisieren vier bis fünfmal schneller als die von Hama benutzte Java-Serialisierung ist, wurde schließlich kryo verwendet. Die Nachrichten werden vor dem Versendenmit kryo serialisiert und in einem Byte-Array zwischengespeichert. Wird die selbe Nachricht voneinem BSP-Peer mehrmals verschickt, dann wird die Serialisierung nur einmal durchgeführt.

Kommunikation

Es wurden jeweils Klassen für die unterschiedlichen Kommunikationsstrategien implementiert(siehe Abbildung A.1, Seite 80). Weiterhin wurden Nachrichten implementiert, zum Versendenvon Double Werten und zum Versenden der Gradienten bzw. des Modells (WeightMatrixMes-sage, siehe Abbildung A.2 auf der Seite 80).

Die WeightMatrixMessage wird zusätzlich im Falle von BGD benutzt, um die Fehlerwerte zuübermitteln. Weiterhin wird sie zum Benachrichtigen aller Peers verwendet, falls ein Abbruch-


kriterium erreicht wurde. Dies ist z.B. notwendig, wenn die Trainingsdaten ungleich verteiltsind und ein BSP-Peer bereits über alle Trainingsdaten iteriert hat. Ein weiteres Beispiel istder Fehlerwert, der nur auf dem Master-Peer gespeichert und ausgewertet wird. Ist ein be-stimmter Fehlerwert erreicht, dann muss der Master-Peer alle BSP-Peers benachrichtigen.

5.4 Evaluation

Die Evaluation eines trainierten MLP kann, wie in Unterabschnitt 4.1.3 beschrieben, anhandder Ausgabe des MLP bzw. anhand der Neuronen in der versteckten Schicht erfolgen. Die Eva-luation wurde in Form eines BSP-Jobs in der Java-Klasse de.distMLP.evaluation.MLPEvaluatorrealisiert, der durch die Java-Klasse de.distMLP.Evaluate_MultilayerPerceptron gestartet wird.Um einen BSP-Job zu starten wird eine Konfigurationsdatei erwartet, die die Pfade zu denEvaluierungsdaten, dem trainierten MLP und im Falle der Xing-Daten den Pfad zur Wortlisteenthält.

Bei der Evaluation wird unterschieden wie viele Neuronen die Ausgabeschicht des MLPenthält. Enthält sie ein Neuron, dann werden Precision/Recall und F-measure über alle Eva-luationsdaten berechnet und auf der Konsole ausgegeben. Zusätzlich wird für die Werte „truenegative“ (TN), „false negative“ (FN), „true positive“ (TP) und „false positive“ (FP) die Stan-dardabweichung berechnet und ausgegeben (siehe Anhang D, Seite 91).

Enthält die Ausgabeschicht mehr als ein Neuron, dann wird davon ausgegangen, dasses sich bei dem zu evaluierenden Problem um die Xing-Daten handelt. Es wird dann ei-ne Datei erwartet, die eine Zuweisung der Zeilennummer des Eingabevektors zu einem Ele-ment der Wörterliste enthält. Das erwartete Format für eine Zeile in dieser Datei ist <

Zeilennummer des Eingabevektors >:< Wort >, beginnend mit der Zeilennummer null (0).Für die Evaluation der Xing-Daten spielt nur die Zeilennummer des Eingabevektors eine

Rolle, d.h. um das erste Element des Eingabevektors zu evaluieren müsste die Eingabedateifolgende Zeile enthalten 0 : 1|0 : 1. Für jede Eingabe wird die Ausgabe des MLP ermittelt. DieWerte des Ausgabevektors werden dann nach der Größe absteigend sortiert. Die 15 höchstenWerte werden ausgegeben, vorher erfolgte eine Zuordnung der Zeilennummer des Ausgabevek-tors zum dazugehörigen Element der Wortliste. Außerdem erfolgt immer eine Evaluation allerNeuronen der versteckten Schicht.

5.5 Apache Hama

Apache Hama befindet sich zur Zeit in der Beta Phase und wurde in der Version 0.6.3 verwendet.Bei der Benutzung fielen zwei Dinge auf. Zum einen kam es sehr oft vor, dass BSP-Jobs bereitsbei der Initialisierung abbrachen. Zum anderen wurde der BSP-Job nicht wie gewünscht aufalle verfügbaren BSP-Peers verteilt, sondern immer nur auf die Hälfte der möglichen Anzahl anBSP-Peers.


5.5.1 Stabilitätsprobleme

Das Problem der Instabilität ließ sich auf die zu optimistischen Einstellungen der Standard-konfiguration zurückführen. Das Framework überprüft regelmäßig, ob alle Rechner im Clusterverfügbar sind. Wird die Zeitspanne überschritten, innerhalb der ein Rechner antworten muss,dann wird dieser als fehlerhaft oder nicht verfügbar markiert. Durch die hohe Last auf denRechnern, kam es regelmäßig zu Timeouts. Mit dem Hochsetzen dieser Zeitintervalle lief Apa-che Hama sehr stabil und die Stabilitätsprobleme konnten damit abschließend gelöst werden.

5.5.2 Job-Verteilung

Die für einen Job benötigte Anzahl an BSP-Peers, wird vom Framework über die Anzahl anEingabedateien bzw. bei großen Dateien anhand der Anzahl von Datei-Blöcken ermittelt2. DieEingabedateien können vom Framework gesplittet werden, dann erhält jeder BSP-Peer einenSplit. Hier stellte sich heraus, dass die Anzahl der Splits immer gleich der Hälfte anstatt dergewünschten Anzahl ist.

Um dieses Problem zu lösen, werden die Trainingsdaten nun vor dem Starten eines BSP-Jobs mit Hilfe eines eigens entwickelten Verfahrens gesplittet. Dabei wurde darauf geachtet, dassjeder BSP-Peer, unter Berücksichtigung der Mini-Batch-Größe, die gleiche Anzahl an Trainings-daten erhält. Es wird also unter Umständen ein Rest, der sich nicht gleichmäßig verteilen lässt,verworfen. Das betrifft im Rahmen dieser Arbeit nur die Xing-Daten, da nur diese zum verteil-ten Training benutzt wurden. Die Anzahl an Xing-Daten war jedoch sehr hoch, so dass hierauf einige wenige Trainingsdaten zu Gunsten der Skalierbarkeit verzichtet werden konnte. Jenach Anwendungsfall sollte das Splitverfahren denoch in zukünftigen Arbeiten weiter angepasstwerden.

5.6 Software-Tests

Die kritischen Komponenten, des im Rahmen dieser Arbeit erstellten Frameworks, sind Daten-verarbeitung, Kommunikation und Training des künstlichen neuronalen Netzes. Für die bereitsim MLP Framework implementierten Trainingsalgorithmen existieren bereits Tests. Die hinzugekommenen Verfahren iRprop+ und ADAGRAD, wurden mit Validitätstests überprüft (sieheAbschnitt 6.2).

Datenverarbeitung und Kommunikation sind mit Hilfe von JUnit-Tests überprüfbar. AlleTests werden automatisch beim Einchecken von Code ausgeführt. Zum Ausführen der Testsdient ein Hudson Server (siehe [Ora]), da er dem Autor bereits bekannt war.

2In der MapReduce Implementierung von Apache Hadoop, wird die Anzahl von Mappern und Reducern mitder gleichen Vorgehensweise ermittelt. Die Blockgröße entspricht der Blockgröße von HDFS. Die Standardblock-größe beträgt 128 Megabyte.


5.6.1 Datenverarbeitung

Die Datenverarbeitung wurde anhand von Beispieldaten getestet. Testkriterien waren die kor-rekte Überführung der Quelldaten in das Trainingsdatenformat und die korrekte Erstellung derWörterliste.

Bei der Normalisierung wurde überprüft, ob die korrekten Maxima und Minima gefundenund die Daten korrekt normalisiert und de-normalisiert werden.

5.6.2 Kommunikation

Die Kommunikation wurde in Form von Komponenten- und Integrationstests überprüft. Da-bei mussten die unterschiedlichen Anwendungsfälle Broadcast und „all-to-one“ berücksichtigtwerden.

Bei der Broadcast Kommunikation muss erstens jeder BSP-Peer eine Nachricht enthaltenund zweitens muss diese Nachricht die korrekten Werte beinhalten. Bei der „all-to-one“ Kommu-nikation werden Daten von allen BSP-Peers eingesammelt, aufsummiert und an einen BSP-Peergesendet. Hier galt es zu prüfen, ob jeder BSP-Peer eine Nachricht sendet. Zum anderen musstegeprüft werden, ob das Ziel die korrekte Summe erhält.

Die Kommunikationsstrategien liegen in Form von eigenen Klassen vor. Für diese Klassenwerden Komponententests in einem Pseudo-Cluster ausgeführt. Beide Kommunikationsstrategi-en werden mit unterschiedlicher Anzahl von BSP-Peers getestet, genauer mit einem BSP-Peer,sowie mit gerader und ungerader Anzahl an BSP-Peers.

Zum Ausführen von Integrationstests wurde für das MLP ein sogenanntes Mock Objekt,also eine von der Klasse MultiLayerPerceptron abgeleitete Klasse mit eingeschränkter Funk-tionalität, erstellt. Das Mock Objekt wird mit einsen statt mit zufälligen Werten initialisiert.Die Gradientenberechung wurde dahingehend geändert, dass alle Felder der Gradientenmatrixeine eins enthalten. Außerdem wurde das Gewichtsupdate dahingehend geändert, dass wederLernrate noch Regularisation Term einfließen. Auch die Berechnung der Fehlerrate ergibt fürjedes Trainingsbeispiel den Wert: eins.

Unter diesen Voraussetzungen, wird erwartet, dass die Nachrichten mit den durchschnitt-lichen Gradienten, eine Matrix enthalten, die mit Werten kleiner eins gefüllt ist. Weiterhinwird erwartet, dass das Gewichtsupdate eine Matrix gefüllt mit einsen ist. Das lässt sich leichtüberprüfen, da nach jeder Iteration, das Modell mit einem Wert gefüllt sein muss, der der Itera-tionsnummer plus eins entspricht. Außerdem muss der für jede Iteration berechnete Fehlerwertgleich eins sein.

Die Intergrationstests wurden in einem lokalen Pseudo-Cluster und in einem Cluster ausge-führt, dabei wurde die Anzahl der BSP-Peers variiert. Hier kann abschließend gesagt werden,dass die Kommunikation korrekt ausgeführt wird. Es konnten nur die üblichen auftretendenAbweichungen ermittelt werden, die sich aus der Berechnung mit Double Werten ergeben.

Kapitel 6

Auswertung

Dieses Kapitel beinhaltet verschiedene Tests zur Validität des verwendeten MLP, der Skalier-barkeit der Anwendung, sowie der Performanz in Abhängigkeit zum gewählten Lernverfahren.Außerdem werden Einfluss von Cache, Matrizenbibliothek und Kommunikationsform auf dieLaufzeit des Programms untersucht. Zum Abschluss dieses Kapitels wird der Arbeitsspeicher-verbrauch in Abhängigkeit von verwendetem Lernverfahren und Rolle des BSP-Peers ermittelt,sowie die These untersucht, ob sich syntagmatische und paradigmatische Beziehungen mit einemMLP ermitteln lassen.

6.1 Testumgebung

Für die Ausführung von Skalierungs- und Performancetests, konnte ein Labor der HTW Berlinzeitweise genutzt werden. Das Labor enthielt 21 Rechner, die über einen Switch miteinanderverbunden waren. Die Rechner waren folgendermaßen ausgestattet:

Prozessor: Intel Core i7-3770 3,40 GHzRAM: 8 GB DDR3 1600 MHz

Host-Betriebssystem: Ubuntu 13.04 LTS 64-BitNetzwerk: 2x Gigabit Ethernet

Virtualisierung: Oracle VirtualBox 4.2.16

Tabelle 6.1: Hardware-/Softwareausstattung der Hostrechner

Die Tests wurden innerhalb einer virtuellen Maschine ausgeführt, mit vier Prozessoren und6 GB RAM. Die virtuelle Maschine lief mit der in Tabelle 6.1 aufgelisteten Software.

6.2 Validitätstests

Die nachfolgenden Validitätstests dienen der Feststellung, ob das verwendete MLP richtig trai-niert. Das ist der Fall, wenn der Fehlerwert über mehrere Iterationen sinkt und die Werte der

KAPITEL 6. AUSWERTUNG 50

Gast-Betriebssystem: Ubuntu 13.04 LTS 64-BitApache Hama Version: 0.6.3Apache Hadoop Version: hadoop-0.20.2-cdh3u6

Tabelle 6.2: Softwareausstattung der virtuellen Maschine

Metriken sich verbessern.Die Bewertung der Qualität des Trainings erfolgte anhand der Metriken Precision/Recall

(siehe Abschnitt D.1) und F-measure (siehe Abschnitt D.2). Normalerweise werden diese Werteanhand eines Testsets ermittelt, dass sind Daten die nicht zum Training des Netzes verwendetwurden1. Validitätstests mit einem Testset waren im Rahmen dieser Arbeit jedoch nur mitden MONK-Daten möglich, da das XOR-Problem nur die vier zum Trainieren verwendetenZustände kennt.

Für alle Validitätstests gilt, dass der Output des MLP immer einer reelle Zahl zwischen nullund eins ist. Aus diesem Grund wird festgelegt, dass ein Wert kleiner gleich 0,5 als zur KlasseI gehörig bzw. als null bewertet wird. Ist ein Wert größer 0,5, dann wird er als zur Klasse IIgehörig bzw. als eins bewertet.

6.2.1 Experiment: XOR-Funktion

Problembeschreibung

Bei der XOR-Funktion handelt es sich um eine Boolesche Funktion (siehe [Wikb]) mit zweiEingängen, die unter anderem zur Addition von binären Zahlen eingesetzt werden kann. Siegibt eine eins aus, wenn die Eingänge unterschiedlich sind. Ansonsten gibt sie eine null (0) aus.Es gibt insgesamt vier unterschiedliche Eingaben, die in der unten stehenden Tabelle aufgelistetsind. Bei dieser Problemstellung handelt es sich demzufolge um ein Regressions-Problem.

x1 x2 y0 0 00 1 11 0 11 1 0

Tabelle 6.3: XOR-Funktion

Vorgehensweise

Das zum Trainieren verwendete Netz hat zwei Eingaben, eine versteckte Schicht mit drei Neuro-nen und eine Ausgabeschicht mit einem Neuron. Das Training erfolgte in mehreren Durchläufen,

1Ein künstliches neuronales Netz muss generalisieren können, d.h. es muss auch gute Werte liefern für Datenmit denen es nicht trainiert wurde. Da die Gefahr des Auswendiglernens besteht, wird deshalb mit Daten getestet,die nicht zum Trainieren verwendet wurden.


jeweils bis zu einem gewissen Fehlerwert. Mit den Trainingsdaten erfolgte dann die Ermittlungvon Precision/Recall und F-measure anhand der „true negative“ (TN), „false negative“ (FN),„true positive“ (TP) und „false positive“ (FP) Werte.

Das Training wurde mit verschiedenen Fehlerwerten als Zielwert und allen Trainingsalgo-rithmen in unterschiedlichen Kombinationen durchgeführt. Die nachfolgende Auswertung er-folgt anhand des Trainings mit dem iRprop+ Algorithmus. Die anderen Trainingsalgorithmenerreichten ähnliche Werte.

Auswertung

Die Tabelle 6.4 enthält die Ergebnisse für unterschiedliche Fehlerwerte, dabei gibt der Wertinnerhalb der Klammer an, wie viele Datensätze jeweils zugeordnet wurden. Die Werte für TP,FN, FP und TN entsprechen dem Mittelwert unter Angabe der Unsicherheit. Anhand dieserTabelle lässt sich erkennen, was der eher abstrakte Fehlerwert darstellt. Je kleiner der Fehlerwertist, um so mehr nähern sich die Ergebnisse dem Zielwert null bzw. eins an und um so geringerist auch die Varianz. Diese Daten erlauben den Schluss, dass das MLP für die Trainingsdatenkorrekt funktioniert.

Fehlerw. TP FN FP TN Prec. Recall F1-meas.0,1 0,91 ±0, 1 (0) (0) 0,07 ±0, 14 100% 100% 100%

(2) (2)0,2 0,83 ±0, 3 (0) (0) 0,16 ±0, 3 100% 100% 100%

(2) (2)0,3 0,97 0.44 (0) 0,13 ±0, 24 100% 50% 66%

(1) (1) (2)0,4 0,71 ±0, 3 (0) 0,54 0,02 66% 100% 80%

(2) (1) (1)0,5 0,71 ±0, 1 (0) 0,68 0,06 66% 100% 80%

(2) (1) (1)0,7 0,68 0,48 0,51 0,35 50% 50% 50%

Tabelle 6.4: XOR: Confusion Matrix und Metriken in Abhängigkeit zum Fehlerwert

6.2.2 Experiment: MONK

Problembeschreibung

Die Daten des MONK Problems entstammen dem UCI-Repository für maschinelles Lernen(siehe „MONK’s Problems Data Set“, [BL13]). Sie wurden ursprünglich zum Vergleichen vonverschiedenen Algorithmen des maschinellen Lernens erstellt (siehe [TBB+91]), was auch derGrund für ihre Verwendung im Rahmen dieser Arbeit ist.

Die Problemdomäne dieser Daten ist die Klassifizierung von Robotern. Ein Roboter wirdanhand von sechs Attributen beschrieben, z.B. Kopf- oder Körperform (siehe Tabelle 6.5). Es


gibt insgesamt 432 mögliche Kombinationsmöglichkeiten der einzelnen Attributausprägungen,mit dazugehöriger Klassifizierung. Davon wurden 30% zufällig ausgewählt und zum Trainierenverwendet. Die restlichen Daten bilden das Testset. Es handelt sich um ein binäres Klassifika-tionsproblem (2-Klassen-Problem), ein Roboter gehört zu einer spezifischen Klasse oder nicht.

Es gibt insgesamt drei MONK-Probleme, wovon aber nur das erste hier Verwendung fand.Für das erste MONK-Problem gilt, dass ein Roboter zur Klasse gehört, wenn seine Kopf- gleichseiner Rumpfform oder die Jackenfarbe rot ist.

x1 : head_shape ∈ round (1), square (2), octagon (3)

x2 : body_shape ∈ round (1), square (2), octagon (3)

x3 : is_smiling ∈ yes (1), no (2)

x4 : holding ∈ sword (1), balloon (2), f lag (3)

x5 : jacket_color ∈ red (1), yellow (2), green (3), blue (4)

x6 : has_tie ∈ yes (1), no (2)

Tabelle 6.5: MONK: Auflistung aller Attribute und ihrer Ausprägungen. Der Wert in den Klam-mern gibt an, welche Zahl dieses Attribut im Eingabevektor repräsentiert.

Datenaufbereitung

Die Rohdaten liegen in Textform vor und enthalten Klasse, Attributausprägungen und eineneindeutigen Namen. Der fünfte Datensatz sah zum Beispiel so aus:

1 1 1 1 1 3 1 data_5

Die Werte der Attribute befinden sich in unterschiedlichen Wertebereichen, z.B. Wx1 = [1, 3]und Wx3 = [1, 2]. Im ersten Schritt erfolgte deshalb eine Normalisierung der Daten (sieheAnhang E). Im zweiten Schritt wurden die Daten in das bereits beschriebene Datenformatüberführt.

Vorgehensweise

Das zum Trainieren verwendete Netz hat sechs Eingaben, eine versteckte Schicht mit siebenNeuronen und eine Ausgabeschicht mit einem Neuron. Die Validitätstests mit MONK-Datenerfolgten auf die gleiche Art und Weise wie die Tests mit der XOR-Funktion. Auch hier wurdedas MLP so lange trainiert, bis eine bestimmte Fehlerrate erreicht wurde. Dabei stellte sich her-aus, dass das Training mit einer Lernrate von 0,1 im Durchschnitt mehr als 200.000 Iterationenbenötigte. Das traf auf alle Verfahren bis auf iRprop+ zu. Aus diesem Grund wurde für dieMONK-Daten, eine Lernrate von 0,01 festgelegt, da hier deutlich weniger Iterationen benötigtwurden.


Auswertung

Die Tabelle 6.6 enthält die Ergebnisse für unterschiedliche Fehlerwerte. Auch hier ließ sichein im Laufe mehrerer Iterationen abnehmender Fehlerwert und zunehmend bessere Werte dereinzelnen Metriken feststellen.

Fehler- TP FN FP TN Pre- Re- F1-wert cision call measure0,03 0,96 ±0, 006 (0) 0,54 ±0, 02 0,06 ±0, 01 99% 100% 99%

(156) (2) (152)0,1 0,87 ±0, 02 0,47 0,67 ±0, 06 0,12 ±0, 02 91% 99% 95%

(155) (1) (15) (139)0,2 0,81 ±0, 02 0,47±0, 01 0,74 ±0, 04 0,18 ±0, 02 88% 95% 91%

(148) (8) (20) (134)0,3 0,83 ±0, 02 0,35±0, 03 0,68 ±0, 04 0,22 ±0, 02 74% 79% 77%

(124) (32) (43) (111)0,4 0,77 ±0, 02 0,32±0, 03 0,69 ±0, 03 0,27 ±0, 02 68% 70% 69%

(124) (32) (43) (111)

Tabelle 6.6: Monk: Confusion Matrix und Metriken in Abhängigkeit zum Fehlerwert

6.3 Skalierungstests

Für ein verteiltes System muss festgestellt werden, unter welchen Bedingungen es von zusätzli-chen Prozessoren bzw. zusätzlichen Rechnern profitiert. Ein Maß hierfür ist der Speedup (sieheD.3), der angibt wie gut ein Algorithmus parallelisierbar ist. Die vertikale bzw. horizontaleSkalierbarkeit wurde im Rahmen mehrerer Tests überprüft und anhand des Speedups bewertet.Die Ergebnisse wurden mit einer linearen Skalierung verglichen, die das Optimum darstellt.

Die Feststellung der vertikalen Skalierbarkeit erfolgte in einer verteilten (distributed-memory) und in einer nicht verteilten Umgebung, während die horizontale Skalierung aus-schließlich in einer verteilten Umgebung untersucht wurde. Die jeweiligen Testergebnisse unddie Diskussion dieser Ergebnisse, bilden den Inhalt dieses Unterkapitels.

6.3.1 Vorgehensweise

Allen Skalierungstests ist gemein, dass weder Momentum noch ADAGRAD oder iRprop+ ver-wendet wurden. Darauf wurde an dieser Stelle verzichtet, da diese Algorithmen nur auf einemRechner und von einem Task ausgeführt werden, und damit nicht parallelisierbar sind.

Alle Tests wurden unter Verwendung eines Caches und mit der Binary-Tree-Kommunikationausgeführt. Die Berechnung des Speedups erfolgte anhand der Iterationsdauer, genauer derenMittelwert, der über die Einzelergebnisse aus 40 Iterationen gebildet wurde. In allen Test gibtdie Iterationsdauer an, für BGD und MBGD, wie lange ein Durchlauf über alle Trainingsdatenim Durchschnitt dauerte. Wie lange es dauert, bis ein Gewichtsupdate ausgeführt wird, ist nicht


Teil der Untersuchungen. Für alle Tests gilt weiterhin, dass die Anzahl der Eingaben, gleich derAnzahl an Neuronen in der versteckten und in der Ausgabeschicht ist.

Das Training eines neuronalen Netzwerks besteht aus mehreren Einzelschritten. In den Ska-lierungstests werden die Zeiten zur Berechnung eines Gewichtsupdates bzw. für das Ausführendes Gewichtsupdates nicht weiter betrachtet, da sie nicht parallelisierbar sind. Die Zeiten hierfürliegen im ein- bis niedrigen zweistelligen Millisekundenbereich und sind gemessen an der Ge-samtdauer vernachlässigbar gering. Die Berechnung des durchschnittlichen Gradienten ist Teilder Kommunikation und wird auch nicht getrennt betrachtet. Die Berechnung des Fehlerwertserfolgt zwar parallel, ist aber, außer bei iRprop+, zum Trainieren des MLP nicht zwingend erfor-derlich und ist daher nicht Teil der Untersuchungen. Der Vergleich von BGD und MBGD erfolgtausschließlich anhand der Kommunikationszeiten und der benötigten Zeit zum Berechnen derGradienten für alle Trainingsbeispiele.

6.3.2 Vertikale Skalierung

Interprozesskommunikation zwischen Prozessen auf demselben Rechner

Dieser Test gilt der Untersuchung der vertikalen Skalierbarkeit, unter Beschränkung der Kom-munikation auf einen Rechner. Der hierfür verwendete Rechner, verfügte über vier Prozessorenund zusätzlich durch Hyper-Threading über vier virtuelle Prozessoren. Das untersuchte Trai-ning, erfolgte anhand eines neuronalen Netzes mit 20 Neuronen, 84.000 Trainingsdaten, einembis acht Tasks und dem BGD Lernverfahren. In den obigen Abbildungen sind Speedup und

1

1,5

2

2,5

3

3,5

4

1 Task 2 Tasks 3 Tasks 4 Tasks

Op.mum BGD 500

(a) Speedup

0

200000

400000

600000

800000

1000000

1200000

1400000

1 Task 2 Tasks 3 Tasks 4 Tasks

Itera&o

nsda

uer in ms

BGD 500

(b) Iterationsdauer für BGD und ein bis vier Tasks

Abbildung 6.1: Gegenüberstellung von Speedup und Iterationsdauer

Iterationsdauer für eine unterschiedliche Anzahl an Tasks dargestellt. Die Laufzeiten der Testsmit fünf bis acht Tasks glichen ungefähr der Laufzeit mit vier Tasks und sind deshalb nichtdargestellt. Der Speedup bricht bei vier Tasks ein, was auch der Anzahl an physikalischen Pro-zessoren entspricht. Vermutlich muss sich der vierte Task den Prozessor mit dem (Host- undGast-) Betriebssystem und anderen Prozessen teilen, so dass hier keine so deutliche Geschwin-digkeitssteigerung mehr erreicht werden konnte.


Auf eine Darstellung der Kommunikationszeiten wurde an dieser Stelle verzichtet. Dieselag bei allen Tests zwischen 2 ms und 6 ms, sie ist im Vergleich zur gesamten Dauer alsovernachlässigbar gering.

Distributed-Memory mit konstanter Anzahl an Trainingsbeispielen pro Task

In diesem Test wurde die vertikale Skalierbarkeit in einer verteilten Umgebung untersucht. DieTestdurchführung erfolgte immer mit 11 Rechnern, 180.000 Trainingsbeispielen und einem bisdrei Tasks pro Rechner. Auf einen Test mit vier Tasks wurde an dieser Stelle verzichtet, daein Einbruch des Speedups bereits im Test mit lokaler Interprozesskommunikation festgestelltwurde. Die zum Trainieren verwendeten Lernverfahren sind BGD und MBGD mit 100 bzw.200 Trainingsbeispielen pro Task. Die Mini Batch Größe war in diesem Test nicht konstant,sondern hing von der Anzahl an Tasks ab, da jeder Task immer 100 bzw. 200 Trainingsbeispieleverarbeitete.

1 1,2 1,4 1,6 1,8 2

2,2 2,4 2,6 2,8 3

11 Tasks 22 Tasks 33 Tasks

Speedu

p

Op/mum BGD MBGD 100 MBGD 200

(a) Speedup

0 100000 200000 300000 400000 500000 600000 700000 800000 900000 1000000


Itera&o

nsda

uer in ms

BGD MBGD 100 MBGD 200

(b) Iterationsdauer für BGD und MBGD 100/200 mit500 Neuronen


Die Ergebnisse dieser Tests, finden sich in Abbildung 6.2(b). Bei allen untersuchten Ver-fahren, ließ sich eine Verkürzung der Iterationsdauer, mit Erhöhung der Tasks pro Rechner,ermitteln. Das lässt sich damit begründen, dass die Kommunikationskosten der Interprozess-kommunikation zwischen Prozessen auf dem selben Rechner vernachlässigbar klein sind, so dassdas Verfahren in hohem Maße von zusätzlichen lokalen Prozessoren profitiert.

Am schnellsten war BGD, da hier die Kommunikationskosten am geringsten waren, danachfolgt MBGD mit 200 Trainingsbeispielen pro Task. Am langsamsten war MBGD mit 100 Trai-ningsbeispielen pro Task. Auch das lässt sich anhand der Kommunikationskosten erklären. EineIteration über alle Trainingsdaten, besteht bei MBGD wiederum aus mehreren Iterationen. Jegeringer die Mini Batch Größe, um so mehr Iterationen werden benötigt, um über alle Trai-ningsdaten zu iterieren. Je geringer die Mini Batch Größe, um so größer sind demzufolge auchdie Kommunikationskosten.

In Abbildung 6.2(a) sind die Speedup Werte, der einzelnen Verfahren dargestellt. Die MBGDVerfahren sind zwar am langsamsten, profitieren aber am stärksten von der Erhöhung der An-


0%

20%

40%

60%

80%

100%

BGD 11 Tasks

BGD 22 Tasks

BGD 33 Tasks

MBGD (11 T.) 100

MBGD (22 T.) 100

MBGD (33 T.) 100

MBGD (11 T.) 200

MBGD (22 T.) 200

MBGD (33 T.) 200

Anteil an

Gesam

tdau

er

in Prozent

Gradientenberechnung KommunikaCon

Abbildung 6.3: Prozentualer Anteil von Kommunikation und Gradientenberechnung an dergesamten Iterationsdauer.

zahl lokaler Prozessoren und Erreichen die höchsten Speedup Werte. Das liegt darin begründet,dass mit steigender Taskanzahl auch die Mini Batch Größe erhöht wurde, wodurch auch mehrDaten pro Iteration verarbeitet werden. Eine Iteration über alle Daten besteht bei steigenderTaskanzahl demzufolge aus weniger Iterationen.

Das lässt sich gut in Abbildung 6.3 ablesen. Am geringsten ist der Anteil der Kommunika-tionskosten bei BGD. Die Größe der Kommunikationskosten bleibt bei steigender Taskanzahlungefähr gleich, macht aber bei BGD einen steigenden Anteil an der Iterationsdauer aus. DasVerhältnis zwischen Kommunikation und Gradientenberechnung ist bei MBGD in allen Testsungefähr konstant.

Distributed-Memory mit konstanter Batchgröße

Ziel dieses Tests ist es, herauszufinden, wie gut das System skaliert, wenn das Training mitgeringer Anzahl an Trainingsdaten und konstanter Mini Batch Größe (384 Datensätze proIteration) erfolgt. Konstant bedeutet in diesem Fall, dass mit zunehmender Anzahl an Tasks,die Anzahl an Trainingsdaten pro Task abnimmt, die insgesamt verarbeitete Menge an Datenaber gleich bleibt.

Die Testdurchführung erfolgte mit 3840 Trainingsdaten und 500 bzw. 1000 Neuronen. ZumUntersuchen der vertikalen Skalierbarkeit, wurden Tests mit 16 Rechnern und einem bis dreiTasks pro Rechner ausgeführt. Das Mini Batch Verfahren benötigt in diesem Test aufgrund derkonstanten Batchgröße, immer zehn Iterationen, um mit allen Trainingsdaten zu trainieren.

In Abbildung 6.4(b) sind die Laufzeiten für alle untersuchten Verfahren und Taskgrößendargestellt. An dieser Abbildung lässt sich erkennen, dass sich die Iterationsdauer, mit Zunah-me der Anzahl an Tasks pro Rechner, nur in sehr geringem Maße verringert. Der Grund dafürsind die, im Verhältnis zur Berechnung des Gradienten, hohen Komunikationskosten. Wie inAbbildung 6.5 ersichtlich, nimmt zwar die Dauer der Gradientenberechnung mit zunehmenderTaskanzahl ab. Die Kommunikationskosten überwiegen jedoch insbesondere bei den Mini Batch


1

1,5

2

2,5

3

16 32 48

Speedu

p Op,mum BGD 500 BGD 1000

MBGD 500 MBGD 1000

(a) Speedup

1

10

100

1000

10000

100000

1000000

BGD-‐500 BGD-‐1000 MBGD 500 MBGD 1000

Itera&o

nsda

uer in ms


(b) Iterationsdauer für BGD und MBGD 384 mit 500bzw. 1000 Neuronen.


Verfahren deutlich, sie machen dort mehr als 90 Prozent aus, so dass der Geschwindigkeitsge-winn durch mehrere Tasks pro Rechner nur sehr gering ist.

0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

BGD 500 (16)

BGD 500 (32)

BGD 500 (48)

BGD 1000 (16)

BGD 1000 (32)

BGD 1000 (48)

MBGD 500 (16)

MBGD 500 (32)

MBGD 500 (48)

MBGD 1000 (16)

MBGD 1000 (32)

MBGD 1000 (48)

Gradientenberechnung KommunikaCon


In Abbildung 6.5 lässt sich auch ablesen, dass das Verhältnis von Kommunikation zu Berech-nungen günstiger ist, wenn die Anzahl an Neuronen größer ist. Im Ergebnis sind die SpeedupWerte der neuronalen Netze mit 1000 Neuronen größer, als mit 500 Neuronen (siehe Abbildung6.4(a)). Bei den Mini Batch Verfahren lässt sich nur ein Speedup nahe eins feststellen, das heißtdieses Verfahren skaliert zumindest in diesem Test nicht vertikal. Die im Vergleich mit 6.2(a)deutlich geringeren Speedup-Werte, lassen sich mit der geringen Anzahl an Trainingsdaten be-gründen.

Zusammenfassend lässt sich hier sagen, dass die Skalierbarkeit, von der Problemgröße, derAnzahl an Trainingsdaten und dem verwendeten Trainingsverfahren abhängt. Je größer dasProblem, also die Anzahl an Neuronenverbindungen, und je mehr Trainingsdaten pro Taskvorliegen um so besser skaliert das System.


6.3.3 horizontale Skalierung

In diesem Test wurde die horizontale Skalierung mit 500/1000 Neuronen, BGD/MBGD undvier Tasks pro Rechner untersucht. Die Mini Batch Größe betrug für alle Tests konstante 384Datensätze pro Iteration. Die Tests erfolgten jeweils mit unterschiedlicher Anzahl von Rechnern,dabei entsprach die Rechneranzahl immer einer Potenz von zwei. Diese Rechneranzahl wurdegewählt, da sie für die verwendete Binary Tree Kommunikation optimal ist.

0 15000 30000 45000 60000 75000 90000

105000 120000 135000 150000

1 Rechner 2 Rechner 4 Rechner 8 Rechner 16 Rechner Itera&o

nsda

uer in ms

BGD 500 Neuronen BGD 1000 Neuronen MBGD 500 Neuronen MBGD 1000 Neuronen

Abbildung 6.6: horizontale Skalierung mit 3.840 Trainingsdaten

In den Abbildungen Abbildung 6.6 und Abbildung 6.7 sind Iterationsdauer bzw. Speedupder einzelnen Testergebnisse dargestellt für 3.840 Trainingsdaten. Auf einem Rechner benötigenBGD und MBGD noch ungefähr die selbe Zeit für eine Iteration, der Overhead ist hier noch sehrgering. Für BGD wurde für alle Tests mit steigender Rechneranzahl eine kürzere Iterationsdauerund damit ein steigender Speedup festgestellt. Allerdings bricht der Speedup für BGD mit 500Neuronen bei 16 Rechnern ein, so dass hier keine größere Steigerung mit weiteren Rechnern zuerwarten ist. Für MBGD lässt sich, wie beim Test der vertikalen Skalierbarkeit, ein geringer bisnegativer Speedup feststellen, d.h. MBGD profitierte ab zwei Rechnern nicht mehr von weiterenRechnern, da die Kommunikationskosten überwogen.

0

1

2

3

4

5

6

1 Rechner 2 Rechner 4 Rechner 8 Rechner 16 Rechner

BGD 500 Neuronen BGD 1000 Neuronen

MBGD 500 Neuronen MBGD 1000 Neuronen

Abbildung 6.7: Speedup für 3.840 Trainingsdaten


0

200000

400000

600000

800000

1000000


Itera&o

nsda

uer in ms

BGD 500 BGD 1000 Neuronen

Abbildung 6.8: horizontale Skalierung mit 38.400 Trainingsdaten

Der selbe Test wurde mit 38.400 Trainingsdaten ausgeführt. Allerdings wurde diesmal aufMBGD verzichtet, da hier ähnliche Resultate zu erwarten waren. Mit zunehmender Rechneran-zahl sinkt in diesem Test auch die Anzahl an Trainingsdaten pro BSP-Peer. Sowohl bei einemRechner als auch bei 16 Rechnern würden 100 Iteration mit MBGD benötigt, um das MLP mitallen Trainingsdaten zu trainieren. Das würde wiederum sehr hohe Kommunikationskosten unddaraus folgend auch in diesem Test einen negativen Speedup bedeuten.

Die Ergebnisse der Tests sind in Abbildung 6.8 und Abbildung 6.9 dargestellt. Mit ei-ner Verzehnfachung der Anzahl an Trainingsdaten verzehnfachte sich näherungsweise auch dieIterationsdauer. Der erreichte Speedup war teils doppelt so hoch, wie der Speedup für 3.840Trainingsdaten. Bis zu einer Rechneranzahl von acht Rechnern ist er näherungsweise linear,dabei ist der Speedup für ein Netzwerk mit 1.000 Neuronen in allen Schichten größer als mit500 Neuronen.

Auch in diesem Test, ließ sich feststellen, dass die Skalierbarkeit von Modellgröße, Anzahlan Trainingsdaten und von der Batchgröße abhängt. Je größer diese Werte sind, um so besserist auch die horizontale Skalierbarkeit.

1

3

5

7

9

11

13

15


Op3mum BGD 500 Neuronen BGD 1000 Neuronen

Abbildung 6.9: Speedup für 38.400 Trainingsdaten


6.4 Laufzeittests einzelner Komponenten

Die Skalierungstests wurden mit aktiviertem Cache und der Binary Tree Kommunikation durch-geführt, ohne das auf diese Komponenten genauer eingegangen wurde. In den folgenden Un-terkapitel findet sich deshalb eine genauere Untersuchung dieser Komponenten, bezüglich ihresEinflusses auf die Laufzeit des Programms. Den Abschluss dieses Unterkapitels bildet der Ver-gleich der Matrizen Bibliotheken Apache Mahout und jblas.

Für alle Tests gilt, dass sie 100 mal bzw. im Falle der Kommunikation 40 mal wiederholtwurden. Die jeweils dargestellten Ergebnisse sind die Mittelwerte dieser Testergebnisse.

6.4.1 Einfluss des Caches auf die Ladezeit

0 1 2 3 4 5 6 7 8 9 10

256 2560 25600 256000

Speedup

(a) Speedup in Abhängigkeit zur Datenmenge.

1

10

100

1000

10000

256 2560 25600 256000

Zeit in m

s

mit Cache ohne Cache

(b) Ladezeit in Abhängigkeit der Datenmenge.

Abbildung 6.10: Cache: Gegenüberstellung von Speedup und Ladezeit

In diesem Unterkapitel wird der Einfluss des Caches auf die Gesamtladezeit anhand ver-schiedener Datenmengen näher beleuchtet. In den Abbildungen 6.10(a) und 6.10(b) sind dieErgebnisse der Tests, in Form eines Speedup-Diagramms bzw. die Ladezeiten für unterschied-liche Datenmengen, dargestellt. Die Ladezeit steigen mit und ohne Cache ungefähr linear zurDatenmenge an, dabei verkürzt sich die Ladezeit um den Faktor vier, wenn die Daten im Ar-beitsspeicher gehalten werden.

Die angegebenen Datenmengen gelten pro BSP-Peer, d.h. um eine signifikante Verkürzungder Trainingsdauer zu erreichen, müsste die Datenmenge pro BSP-Peer mindestens 250.000Datensätze betragen. Für die im Rahmen dieser Arbeit verwendeten Datenmengen, ließ sichaus diesem Grund auch keine signifikante Verkürzung der Iterationsdauer unter Verwendungeines Caches ermitteln.

6.4.2 Vergleich von sequentieller und Binary Tree Kommunikation

Im Rahmen dieser Arbeit wurden mit der sequentiellen und der Binary Tree Kommunikationzwei unterschiedlicher Verfahren zu Kommunikation implementiert, die nachfolgend miteinan-


der verglichen werden. Das hierfür verwendete MLP hatte einen Eingabevektor mit 1.000 Zeilenund 1.000 Neuronen in der versteckten bzw. in der Ausgabeschicht. Das Training erfolgte mitdem Lernverfahren BGD und 3.840 Trainingsdaten. Die Testdurchführung erfolgte in einerverteilten Umgebung mit vier BSP-Peers pro Rechner und einem, zwei, vier, acht und sech-zehn Rechnern. Der Testdurchlauf mit sequentieller Kommunikation und unter Verwendungvon sechzehn Rechnern, wurde allerdings nach zehn Minuten abgebrochen, da kein Fortschrittfeststellbar war.

0

1

2

3

4

5

6

7

8

9

1 Rechner 2 Rechner 4 Rechner 8 Rechner

Op4mum Seq. Komm. Binary Tree Komm.

(a) Speedup in Abhängigkeit zur Rechneranzahl

0

20000

40000

60000

80000

100000

120000

1 Rechner 2 Rechner 4 Rechner 8 Rechner Ite

ra&o

nsda

uer in ms

Sequen1elle Komm. Binary Tree Komm.

(b) Iterationsdauer in ms in Abhängigkeit zur Rech-neranzahl.

Abbildung 6.11: Kommunikation: Gegenüberstellung von Speedup und Iterationsdauer

In den obigen Abbildungen sind die Testergebnisse dargestellt. Die Iterationsdauer für biszu zwei Rechner ist bei beiden Verfahren annähernd gleich. Wenn jedoch mehr als zwei Rechnerverwendet wurden, zeigte sich, dass die sequentielle Kommunikation deutlich langsamer ist. DerGrund dafür lässt sich in Abbildung 6.12 ablesen. Der Anteil der Kommunikationsdauer an dergesamten Iterationsdauer wächst bei der sequentiellen Kommunikation deutlich schneller als beider Binary Tree Kommunikation, wenn mehr Rechner verwendet werden. Aus diesem Grundwurde die Binary Tree Kommunikation standardmäßig in allen Tests genutzt.

6.4.3 Vergleich von Apache Mahout und jblas

Wie bereits in Unterabschnitt 5.2.2 beschrieben, ist die vom MLP Framework verwendeteMatrix-Bibliothek jederzeit austauschbar. Es stehen die Matrizen Bibliotheken von ApacheMahout und jblas zur Auswahl. Welchen Einfluss eine Verwendung dieser Bibliotheken auf dieLaufzeit hat wird nachfolgend untersucht.

Framework / Anzahl Neuronen Mahout jblas-Wrapper500 Neuronen 20 ±2 41 ±21000 Neuronen 90 ±4 200 ±8

Tabelle 6.7: Zeitmessung der Gradientenberechnung für ein Trainingsbeispiel in ms

In der obigen Tabelle finden sich die Zeiten zur Gradientenberechnung, in Abhängigkeitzur Neuronenanzahl und des verwendeten Frameworks. Aus den obigen Daten lässt sich ab-


0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%

Seq. Komm. (1)

Seq. Komm. (2)

Seq. Komm. (4)

Seq. Komm. (8)

Binary Tree (1)

Binary Tree (2)

Binary Tree (4)

Binary Tree (8)

Gradientenberechnung KommunikaFon


lesen, dass die Berechnungen unter Verwendung der Mathe-Bibliotheken von Apache Mahoutam schnellsten erfolgten. Das gilt auch für die Berechnung des Gewichtsupdates, auf dessenDarstellung verzichtet wurde.

Um genauer herauszufinden wie die Laufzeiten der einzelnen Methoden sind, wurde dieaspektorientierte Programmierung mit Aspectj (siehe [Fou]) benutzt. Aspectj bot den Vorteil,dass hiermit deutlich weniger Code benötigt wird. Andernfalls hätte für jeden Methodenaufrufdie Implementierung einer Zeitmessung erfolgen müssen.

In Listing 6.1 findet sich der zum Profiling des MLP verwendete Code. In Zeile zwei ist derpointcut dargestellt, der bestimmt an welcher Stelle die sparse-Methode (Zeilen 4-10) in denursprünglichen Programmablauf eingebunden werden soll. Sie dient der Zeitmessung und wirdvor jedem Methodenaufruf aufgerufen, außer es handelt sich bei der aufzurufenden Methodeum eine main-Methode oder um Methoden der Klasse „MLP_Profiler“.

1 private final Map<String, Long> methodTimes=newHashMap<String, Long>();

2 pointcut sparse() : execution(* *(..)) && !execution(* main(..)) && !within(MLP_Profiler);

3

4 Object around(): sparse() {

5 final long start =System.nanoTime(), end;

6 Object result = proceed();

7 end=System.nanoTime();

8 this.methodTimes.put(getJoinPointName(thisJoinPoint), end - start);

9 return result;

10 }

Listing 6.1: Ermittlung der benutzten Methoden und deren Laufzeit mit Aspectj


Das Profiling des MLP erfolgte für die Gradientenberechnung und die Berechnung des Ge-wichtsupdates, wodurch die Methoden mit der längsten Laufzeit und dem größten Optimie-rungspotential ermittelt wurden. Für diese Methoden erfolgte dann ein Vergleich der Laufzei-ten, für die beiden zur Verfügung stehenden Bibliotheken. Die Ergebnisse sind in Tabelle 6.8dargestellt.

Framework / Rechenmethode DenseMatrix (Mahout) JDenseMatrix (jblas-Wrapper)Multiplikation 111,27 ±6, 8 11,56 ±2, 6

Addition 46,07 ±3, 4 49,98 ±7, 8DoubleDouble Funktion 22,17 ±2, 6 171,42 ±3

VektorDenseVector (Mahout) JDenseVector (jblas-Wrapper)

Cross 113,02 ±5, 12 280,54 ±7, 86

Tabelle 6.8: Linux: Zeitmessung verschiedener Rechenoperationen in ms für eine 1000x1000Matrix und einen Vektor mit 1000 Zeilen.

Wie in der obigen Tabelle ersichtlich, erfolgt die Multiplikation zweier Matrizen mit jblasdeutlich schneller als mit der Mathe-Bibliothek von Apache Mahout. In den anderen dargestell-ten Rechenoperationen ist es jedoch teils deutlich langsamer. Das ist auch der Grund dafür,dass das Training unter Verwendung von jblas langsamer ist. Warum dies im Detail der Fallist, wurde aus Zeitgründen nicht weiter untersucht. Für zukünftige Arbeiten scheint es jedochsinnvoll, die Matrizenmultiplikation von jblas zu benutzen und Apache Mahout für alle anderenRechenoperationen zu verwenden oder weitere Bibliotheken in Betracht zu ziehen.

6.5 Untersuchung des Arbeitsspeicherverbrauchs

Im Rahmen dieses Unterkapitels wird untersucht, wie viel Arbeitsspeicher von dem FrameworkApache Hama bzw. von dem verteilten MLP benötigt werden. Der erste Teil dieses Unterkapitelsberuht auf empirischen Untersuchungen mit dem Linux-Tool top, während der zweite Teil einetheoretische Betrachtung dieses Problems ist.

Wie bereits beschrieben, wurde im Rahmen dieser Arbeit das verteilte Dateisystem HDFSvon Apache Hadoop verwendet. Dementsprechend liefen auf allen Rechnern nicht nur Dienstevon Apache Hama sondern auch Dienste von HDFS. Das heißt, dass auf allen Rechnern einDatanode von Apache Hadoop sowie ein Groom-Server von Apache Hama liefen. Auf fünfRechnern lief zusätzlich der Dienst Zookeeper aus dem Framework Apache Zookeeper (siehe[Whi11], Seite 441-474), zur Synchronisation der einzelnen Rechner. Weiterhin liefen zusätzlichauf einem Rechner die Dienste Namenode, Secondary Namenode von Apache Hama und derDienst BspMaster von Apache Hama, nachfolgend Master-Rechner genannt.

Die Dienste Datanode, Zookeeper und Groom-Server reservieren ungefähr 100 MB Ar-beitsspeicher, während die restlichen Dienste noch einmal zusätzlich ca. 180 MB reservieren.


Startet man einen BSP-Job, dann reserviert zusätzlich jeder BSP-Peer zwischen 300 und 500MB an Arbeitsspeicher.

Betrachtet man den theoretischen Arbeitsspeicherbedarf des MLP, dann hält jeder BSP-Peer eine Reihe von Einstellungen, das Modell und mit eingeschaltetem Cache einen Teil derTrainingsdaten im Arbeitsspeicher. Zusätzlich dazu muss ein Master-Peer noch weitere Datenim Arbeitsspeicher halten, die von dem verwendeten Lernverfahren abhängen2.

Die Trainingsdaten werden jeweils in einem Sparse Vector und standardmäßig mit Dou-ble Werten als Inhalt gespeichert. In einem Sparse Vector wird Arbeitsspeicher nur für Zeilenbenötigt deren Wert ungleich null ist. In einem 64-Bit System sind das 8 Byte. Je nach An-wendungsfall und benötigter Genauigkeit könnten hier auch Werte vom Type Float mit 4 Bytebzw. Short mit 1 Byte Speicherbedarf verwendet werden.

Für die im Rahmen dieser Arbeit verwendete Menge an Trainingsdaten ist der Bedarf anArbeitsspeicher vernachlässigbar gering, so dass der Typ der Eingabe bei der Standardein-stellung belassen wurde. Der Arbeitsspeicherbedarf der Einstellungen, wie z.B. die Anzahl anIterationen, ist ebenfalls vernachlässigbar gering und beträgt schätzungsweise weniger als 1 KB.

Den größten Teil des Arbeitsspeicherbedarfs macht das auf jedem BSP-Peer gespeicherteModell in Form der Neuronenverbindungen aus. Sie werden in einem Matrix-Array gespeichert,der Objekt-Typ ist dabei aus Gründen der Genauigkeit vom Typ Double. Die Matrix ist nichtSparse, da die Gewichte zum größten Teil einen Wert ungleich null aufweisen. Das bedeutet,dass z.B. für ein MLP mit 1.000 Neuronen in allen drei Schichten und damit 2.000.000 Neu-ronenverbindungen ca. 15 MB benötigt werden. Der selbe Wert wird für das Versenden vonNachrichten (Gradient und Gewichtsupdate) benötigt, da vor dem Versenden eine Serialisie-rung der Nachricht in ein Byte Array stattfindet, was den gleichen Speicherbedarf aufweist.

Der Speicherbedarf des Master-Peer steigt, wenn Momentum, ADAGRAD oder iRprop+verwendet werden. Zur Berechnung des Momentum wird die letzte Gewichtsänderung benö-tigt. Dessen Speicherbedarf entspricht demzufolge dem Speicherbedarf der Neuronengewichte.Das selbe gilt für ADAGRAD, nur das hier die Summe der partiellen Ableitungen für jedesNeuronengewicht gespeichert wird. Der Speicherbedarf von iRprop+ entspricht der dreifachenModellgröße, da die letzte Schrittweite, der letzte Gradient und das letzte Gewichtsupdate fürdie Berechnung des nächsten Gewichtsupdates benötigt werden.

Diese Werte müssen vor dem Start des Trainings berücksichtigt werden, d.h. das die maxi-male Netzgröße vom kleinsten verfügbaren Arbeitsspeicher abhängt. Eine geeignete Maßnahmebetrifft bei geringen verfügbaren Arbeitsspeicher betrifft den Master-Peer, der den höchstenSpeicherbedarf hat und von der Anwendung gewählt wird. Ist ansonsten nicht genügend Ar-beitsspeicher vorhanden, könnte z.B. die Anzahl von BSP-Peers auf einem Rechner auf einsbeschränkt und dieser Rechner zum Master-Peer bestimmt werden.

2Das betrifft nur einen BSP-Peer, da die Berechnung des Gewichtsupdates nur durch einen BSP-Peer erfolgt.


6.6 Performancetests

Im Rahmen dieser Arbeit wurde eine Reihe an Performancetests, zum Vergleichen der verwen-deten Trainingsalgorithmen und Initialisierungsarten, durchgeführt. Die Aufnahme der Mess-werte erfolgte für jedes Verfahren in über 100 Durchläufen. Die MONK-Daten bzw. Xing-Profilewurden zum Trainieren verwendet, dabei entsprach der für die MONK-Daten verwendete Netz-aufbau dem in Unterabschnitt 6.2.2 beschriebenen Netzaufbau. Für die Xing-Profile wurde einNetzwerk mit 20 Neuronen in allen drei Schichten verwendet. Damit alle Verfahren unter dengleichen Bedingungen getestet werden, erfolgt die Wahl des Seed-Werts zum Initialisieren derVerbindungsgewichte nicht zufällig. Für jeden Testdurchlauf eines Verfahrens wird der Seed-Wert um eins hochgezählt, beginnend mit dem Seed-Wert: 1.

Als Vergleichskriterium dient der Fehlerwert, je geringer der Fehlerwert und die zum Errei-chen dieses Fehlerwerts benötige Anzahl an Iterationen sind, um so besser ist der Algorithmus.Für die Bewertung der Algorithmen spielt es zumindest in diesem Kapitel keine Rolle, wiegroß die Kommunikationskosten sind. In den Grafiken dieses Unterkapitels werden nur die je-weils im Vergleich mit BGD schnellsten Algorithmen dargestellt. Die Einzelergebnisse für alleAlgorithmen finden sich in Anhang B.

6.6.1 Messung: Iterationsanzahl bis zur Erreichung eines Zielfehler-werts

Ziel dieses Tests war es, herauszufinden wie viele Iterationen ein Trainingsalgorithmus im Durch-schnitt benötigt, um den Fehlerwert 0, 1 zu erreichen. Die Testdurchführung erfolgte unter an-derem mit SGD und anhand der MONK-Daten, da dieses Problem ausreichend klein und dieAnzahl an Trainingsdaten gering sind. Auf eine zufällige Verteilung der Trainingsdaten vor demTraining wurde in Abweichung zum Standardvorgehen mit SGD verzichtet, da sie bereits zufäl-lig ausgewählt wurden und im Gegensatz zu z.B. Timeseries-Daten keine Ordnung aufweisen.

BGD BGD-‐Momentum iRprop+ SGD-‐ADAGRAD max 4690 920 123 107

min 3562 652 38 38

avg 4119,85 805 63,47 62,64

1

10

100

1000

10000

Anzahl Itera,

onen

Abbildung 6.13: MONK: Vergleich der Trainingsverfahren und Initialisierungsarten, anhand derAnzahl an Iterationen bis zum Fehlerwert 0,1, mit logarithmischer Skalierung.


In der obigen Tabelle sind die schnellsten Optimierungsverfahren für Batch- und Online-Lernverfahren zum Vergleich dargestellt. Unter den Batch-Lernverfahren wurde die Zielfehler-rate mit Momentum am schnellsten erreicht, wenn die Initialisierung durch LeCuns Algorithmuserfolgte. Vergleicht man die Ergebnisse aller Batch-Lernverfahren, dann war allerdings die In-itialisierung mit Ngyen/Widrow am erfolgreichsten. Mit ADAGRAD musste die Anzahl derIterationen auf 50.000 begrenzt werden, da der Zielfehlerwert oftmals auch nach über 200.000Iterationen noch nicht erreicht wurde. Vermutlich war die mit ADAGRAD ermittelte adaptiveLernrate zu hoch.

Insgesamt gesehen waren die Verfahren iRprop+ und SGD am schnellsten. Bei iRprop+ ließsich in diesem Test keine Abhängigkeit von der Initialisierungsform feststellen. Alle getestetenVerfahren erreichten hier ähnliche Werte. Das gilt mit Einschränkungen auch für SGD. WennADAGRAD in Verbindung mit dem Initialisierungsalgorithmus von Glorot/Bengio verwendetwurde, dann war das Training im Mittel zwischen 30% (Momentum & ADAGRAD) und 100%langsamer als mit LeCun oder mit Ngyen/Widrow.

6.6.2 Messung: Fehlerwert nach 50 Iterationen

In diesem Test wurde untersucht, welcher Fehlerwert nach 50 Iterationen in Abhängigkeit vomLernverfahren erreichbar ist. Das Training erfolgte unter anderem mit einer Mini-Batch Größevon 100 und anhand eines MLPs mit 20 Neuronen in allen drei Schichten und 54.000 Xing-Profilen (siehe Abbildung 6.14). Außerdem erfolgte ein Training mit den MONK-Daten (sieheAbbildung 6.15).

BGD BGD-‐ADAGRAD-‐

Momentum (Glorot/Bengio)

iRProp+ (Glorot/Bengio) MBGD-‐100 -‐ADAGRAD-‐Momentum (Glorot/

Bengio) max 6,227 0,46 0,1732 0,132

min 5,503 0,29 0,1359 0,116

avg 5,762 0,37 0,154 0,122

0,1

1

10

Fehlerwert

Abbildung 6.14: Xing (20): Vergleich der Trainingsverfahren und Initialisierungsarten, anhanddes Fehlerwerts nach 50 Iterationen, mit logarithmischer Skalierung.

Für alle Tests mit den Xing-Profilen galt, dass der mit der Initialisierung von Glorot/Bengioermittelte Fehlerwert im Mittel am geringsten war. Das gilt zum größten Teil auch für dieMONK-Daten. Wenn man jeweils Maxima- und Minima des erreichten Fehlerwerts betrachtet,


dann scheint die Abhängigkeit von der Initialisierung bei den Xing-Daten geringer als beimMONK-Problem zu sein. Das lässt sich daran erkennen, dass sie bei den Xing-Daten für alleuntersuchten Verfahren deutlich näher am Mittelwert sind als beim MONK-Problem.

Auch in diesem Test erreichten iRprop+ und MBGD bzw. SGD die besten Ergebnisse. BeimTraining mit den Xing-Daten schnitt ADAGRAD in Kombination mit Momentum sowohl mitBGD als auch mit MBGD am besten ab. Diese Kombination schnitt beim MONK-Problem imGegensatz dazu am schlechtesten ab. Der Fehlerwert war hier sogar höher als BGD ohne weitereOptimierungen.

BGD BGD-‐Momentum (Glorot/Bengio) iRprop+ SGD-‐Momentum

(Glorot/Bengio) max 65,986 50,353 39,389 29,703

min 53,663 3,515 0,046 0,045

avg 61,419 24,654 5,181 4,615

0,010

0,100

1,000

10,000

100,000

Fehlerwert

Abbildung 6.15: MONK: Vergleich der Trainingsverfahren und Initialisierungsarten, anhand desFehlerwerts nach 50 Iterationen.

In Abbildung 6.16 sind beispielhaft die Fehlerkurven für die drei besten Verfahren im Ver-gleich mit BGD dargestellt. Die Fehlerkurve wird jeweils für die ersten 50 Iterationen und denSeed-Wert eins dargestellt.

Anhand der Abbildung lässt sich ablesen, wie die einzelnen Verfahren agieren. Sie startenalle mit dem gleichen Fehlerwert. Die Änderungsrate des Fehlerwerts ist bei allen Verfahren zuBeginn am größten und flacht dann immer weiter ab. Sowohl iRprop+ als auch MBGD erreicheneinen sehr geringen Fehlerwert, der wenn überhaupt von den anderen Verfahren erst nach sehrvielen Iterationen erreicht werden kann.

MBGD scheint hier bereits nach der ersten Iteration einen sehr geringen Fehlerwert erreichtzu haben. Die Iterationszahl steht jedoch für das Training über alle Trainingsdaten, es fandenhier also bereits 5.400 Gewichtsupdates statt, was wiederum den geringeren Fehlerwert erklärt


0,1

1

10

1 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 Fehlerwert

BGD BGD-‐ADA.-‐Mom. MBGD-‐ADA.-‐Mom. iRprop+

Abbildung 6.16: Xing (20): Fehlerkurve über 50 Iterationen in Abhängigkeit zum Lernverfahren,exemplarisch für den Seed-Wert eins.


6.7 Xing-Profildaten

6.7.1 Problembeschreibung

Ein Ziel dieser Arbeit war es, herauszufinden, ob die syntagmatische und paradigmatische Rela-tion mit Hilfe eines MLP extrahiert werden kann. Zuerst soll deshalb geklärt werden, was dieseBegriffe im Allgemeinen und bezogen auf den Anwendungsfall der Xing-Profildaten bedeuten.

Manning und Schütze definieren diese Begriffe folgendermaßen (siehe [MS99], Seite 94):

„All elements that can be replaced for each other in a certain syntactic position ... aremembers of one paradigm. In costrast, two words bear a syntagmatic relationship if they forma phrase (or syntagma) like skewed clothes or sewed a dress. An important class ofsyntagmatically related words are collocations.“

Das wird in dem folgenden allgemeinen Beispiel (aus [MS99], Seite 94) noch einmal verdeut-licht. Alle dort vertikal innerhalb einer Klammer angeordneten Elemente sind untereinanderaustauschbar und somit ein Beispiel für eine paradigmatische Relation. Alle horizontal ange-ordneten Elemente haben eine syntagmatische Beziehung zueinander.

She

the woman

the tall woman

the very tall woman

the tall woman with sad eyes

...

saw

him

the man

the short man

the very short man

the short man with red hair

...

.

Bezogen auf die Xing-Daten könnte das z.B. wie unten dargestellt aussehen. Innerhalb einerKlammer finden sich jeweils außer-fachliche oder berufstypische Qualifikationen, die untereinan-der austauschbar sind. Jede Spalte würde dann eine Klasse von Qualifikationen repräsentieren.In diesem Beispiel würde die zweite Spalte die Klasse der Programmiersprachen darstellen.Eine Zeile mit einem oder mehreren Elementen aus jeder Spalte könnte z.B. das Profil einesSoftware-Entwicklers darstellen.

Ein Anwendungsfall wäre z.B. die Verbesserung eines Suchalgorithmus. So könnte die Suchenach einem Software-Entwickler unter dem Suchbegriff Eclipse auch Profile als Ergebnis lieferndie den Begriff Netbeans enthalten.

Eclipse

Netbeans

IntelliJ

JDeveloper

V isual Studio

...

Java

C

PHP

C#Scala

...

Webdesign

Webentwicklung

Softwareentwicklung

QualitätsmanagementProjektleitung

...

ZuverlässigkeitFührungserfahrungF lexibel

KommunikationsfähigkeitEigeninitiative

...


6.7.2 Datenaufbereitung

Die Rohdaten wurden wie bereits beschrieben von Prof. Dr. Herta in Form einer Textdateimit über 1.100.000 Benutzerprofilen zur Verfügung gestellt. Jede Zeile dieser Datei beinhaltetedie Profilangaben eines Benutzers. Alle Qualifikationen eines Benutzers waren durch ein Se-mikolon voneinander getrennt und wurden vom Benutzer in Form eines Freitextes angegeben.Das heißt, dass eine Profilbeschreibung auch in Satzform erfolgte. Für die weitere Verarbei-tung wurde jedoch eine gewisse Form benötigt, die ausschließlich fachliche und außer-fachlicheQualifikationen beinhaltet.

Die Datenaufbereitung erfolgte in mehreren Schritten. Zuerst wurden Sonderzeichen undStoppwörter entfernt. Im nächsten Schritt wurden alle Leerzeichen entfernt, alle Großbuchsta-ben in Kleinbuchstaben umgewandelt und dann alle Zeichenfolgen entfernt die länger als 20Zeichen sind, um möglichst alle Sätze zu entfernen bzw. eine einheitliche Schreibweise zu er-reichen. Im nächsten Schritt wurde eine nach der Anzahl an Vorkommen sortierte Wörterlisteerstellt, die alle vorkommenden Wörter und deren Gesamtanzahl an Vorkommen enthält.

Für den Anwendungsfall mit z.B. 500 Eingaben wurden die 500 häufigsten Wörter ausge-wählt, alle Profile auf diese Wörter hin untersucht und in das in Abschnitt 4.1.1 beschriebeneFormat überführt. Enthielt ein Profil weniger als drei Wörter aus dieser Liste, dann wurde esverworfen.

Diese Vorgehensweise ist nicht unbedingt optimal, jedoch war eine andere Vorgehensweiseaus Zeitgründen nicht möglich. Dies hat zur Folge dass eine Reihe von Qualifikationen verworfenwurden, wenn sie in einem längeren Satz vorkamen. Außerdem kam es zu Dopplungen innerhalbder Wörterliste, da Wörter nicht auf Ihren Wortstamm zurückgeführt wurden, wie z.B. flexibelund Flexibilität. In zukünftigen Arbeiten sollte untersucht werden, inwieweit z.B. eine „part-of-speech“ Ermittlung zum Erkennen der Qualifikationen möglich und sinnvoll ist.

6.7.3 Vorgehensweise

Das Training des MLP erfolgte nach dem Denoising Autoencoder-Ansatz, bei dem die Eingabeverrauscht wird. Mit einer 50 prozentigen Wahrscheinlichkeit wurden bis auf einen zufälligausgewählten Wert alle Eingaben auf null gesetzt. Ansonsten wurden 20 Prozent der Eingabenauf den Wert null gesetzt. Die erwartete Ausgabe entsprach in allen Fällen der ursprünglichennicht verrauschten Eingabe. Auf die Nutzung eines Sparse Autoencoders musste verzichtenwerden, da eine Implementierung aus Zeitgründen nicht mehr erfolgen konnte. Stattdessenwurde eine Netzform gewählt, die deutlich weniger Neuronen in der versteckten Schicht hat alsEingaben bzw. Ausgabeneuronen.

Als Eingabe diente ein sogenannter „bag-of-words“ Vektor, der nicht normalisiert wurde.Eine eins repräsentiert demzufolge das Vorhandensein eines Wortes in einem Profil, während einenull das Gegenteil darstellt. Wie ein Eingabevektor bzw. der erwartete Ausgabevektor und dieNetzform aussehen könnte, ist beispielhaft für ein MLP mit sechs Eingaben in Abbildung 6.17


dargestellt. In diesem Beispiel würde das Benutzerprofil die Worte Eclipse, Network und OSGienthalten.

Abbildung 6.17: Training des MLP mit der Identität ohne verrauschten Eingabevektor.

Die Evaluation des trainierten MLP erfolgte wie bereits in Unterabschnitt 4.1.3 beschrieben,anhand der Ausgabe des MLP, sowie anhand der Neuronen in der versteckten Schicht.

Um die syntagmatische Relation zu ermitteln, wurde nacheinander immer ein Wert der Ein-gabe auf eins gesetzt und die dazugehörige Ausgabe des MLP untersucht. Das ist beispielhaft inAbbildung 6.18(a) dargestellt. Allerdings liegen in Abweichung zur Abbildung die Ausgabewertein dem Wertebereich [0, 1] und mussten nach dem höchsten Wert sortiert werden.

(a) Syntagmatische Relation (b) Paradigmatische Relation

Abbildung 6.18: Analyse von Ausgabe- bzw. versteckter Schicht in Abhängigkeit der gesuchtenBeziehung

Die Untersuchung bezüglich der paradigmatischen Relation wird in Abbildung 6.18(b) bei-spielhaft dargestellt. Hier wurde für jedes Neuron in der versteckten Schicht überprüft, welcheEingabe zu einer maximalen Aktivierung dieses Neurons führt. Der Eingabevektor wurde dann


nach der Größe sortiert, unter der Annahme, dass die jeweils repräsentierten Wörter eine pa-radigmatische Beziehung zueinander aufweisen.

Das eigentliche Training erfolgt mit iRprop+ und wurde nach 2.000 Iterationen abgebro-chen, da der Cluster nur für einen begrenzten Zeitraum zur Verfügung stand. Zum Vergleichwurde ein MLP mit 500 Eingaben und ca. 260.000 Profilen, sowie ein MLP mit 1.000 Eingabenbzw. Ausgabeneuronen und ca. 400.000 Profilen trainiert. Beide neuronalen Netze hatten eineversteckte Schicht mit 25 Neuronen.

6.7.4 Auswertung

Wie bereits erläutert, lag für diese Daten weder ein „gold standard“ (siehe Unterabschnitt 4.1.3,Seite 36) vor noch konnte dieser aus Zeitgründen erstellt werden. Zur Auswertung der Ergebnissewurde deshalb untersucht, ob für ausgewählte Daten die Ergebnisse den Erwartungen des Autorsentsprechen, die bereits zu Beginn dieses Kapitels vorgestellt wurden.

Als erstes soll eine Aussage über die allgemeine Güte des Trainings getroffen werden. Dieneuronalen Netze wurden mit der Identität trainiert, d.h. das im Optimalfall die Ausgabe einesNetzes der Eingabe entspricht. Wenn zum Beispiel der Eingabevektor nur in der ersten Zeile eineeins enthält, dann sollte der Ausgabevektor in der ersten Zeile einen Wert nahe eins enthalten.Um das zu überprüfen, wurde die Ausgabe nacheinander für alle Zeilen des Eingabevektorsermittelt, wobei immer nur eine Zeile des Eingabevektors einen Wert ungleich null enthielt. DerWert der gleichen Zeile des Ausgabevektors wurde gespeichert. Daraus wurde der Mittelwert füralle Zeilen berechnet. Dieser Wert lag bei dem Netz mit 500 Eingaben bei ca. 0,12 und bei demNetz mit 1.000 Eingaben bei ca. 0,04. Beide Netze weisen demnach auch einen entsprechendhohen Fehlerwert auf und sollten wahrscheinlich noch weiter trainiert werden.

Wie bereits beschrieben, sollte die Vermutung überprüft werden, dass sich mit Hilfe derAusgabe eines MLP Wörter ermitteln lassen, die eine syntagmatische Beziehung zur Eingabeaufweisen. Die Begriffe Webdesign und PHP wurden als Beispiel gewählt und die dazugehörigeAusgabe für die Netze mit 500 bzw. mit 1.000 Neuronen ermittelt. Nachfolgend finden sichdie ersten 15 Ergebnisse, nach der Größe des Ausgabewerts sortiert. Sowohl PHP als auchWebdesign wiesen den höchsten Ausgabewert auf.

Webdesign (1000): grafikdesign, marketing, fotografie, beratung, php, illustration, pro-grammierung, kreativität, cms, seo, internet, teamfähigkeit, printdesign, screendesign

Webdesign (500): grafikdesign, php, corporate design, cms, fotografie, programmierung,beratung, css, flash, html, internet, seo, projektmanagement, kreativität

PHP (1000): mysql, java, html, css, javascript, webdesign, sql, c++, c#, typo3, xml, linux,perl, teamfähigkeit


PHP (500): mysql, html, css, java, javascript, sql, webdesign, xml, linux, ajax, c++, cms,typo3, c#

Im Ergebnis lässt sich sagen, dass beide Netze trotz unterschiedlicher Fehlerwerte für dieseBegriffe sehr ähnliche Ergebnisse liefern. Tatsächlich scheinen diese Wörter auch eine syntagma-tische Beziehung aufzuweisen. Sie könnten zusammengenommen das Profil eines Webdesignersoder PHP-Entwicklers darstellen, was darauf hindeutet, dass sich das MLP für diese Aufgabeeignen könnte.

Eine weitere These war, dass die versteckten Neuronen Features lernen, die der paradigmati-schen Relation entsprechen. Nachfolgend die Daten am Beispiel des ersten versteckten Neurons:

Neuron 1 (1000): kommunikation, pr, rechnungswesen, it, teamfähig, php, vertrieb, web2.0, ausdauer, vbnet, c#, solaris, moderation, css, kreativität

Neuron 1 (500): xml, erfahrungsaustausch, c++, projektleitung, offenheit, vertriebserfah-rung, schnelle auffassungsgabe, html, c, personalentwicklung, führungserfahrung, bildbearbei-tung, eigeninitiative, training, humor

Sowohl die obigen Daten als auch die Ergebnisse der restlichen Neuronen sprechen nichtfür diese These, die aber auch nicht widerlegt werden kann. Möglicherweise lassen sich bessereErgebnisse mit mehr Neuronen in der versteckten Schicht oder mit dem Sparse Autoencodererzielen. Hierzu sollten noch umfangreichere Tests durchgeführt werden, die im Rahmen dieserArbeit aus Zeitgründen entfallen mussten.

Kapitel 7

Fazit

Diese Arbeit beschreibt die Entwicklung einer Anwendung zum verteilten Training eines MLPmit Apache Hama und einem von der Universität HTW-Berlin zur Verfügung gestellten MLP-Framework. Ein Ziel dieser Arbeit war es, die korrekte Funktionsweise des verwendeten MLP-Frameworks zu überprüfen, was anhand von MONK-Daten und der XOR-Funktion erfolgte.

Weitere Ziele dieser Arbeit waren die Feststellung der Eignung von Apache Hama für dieseAnwendung und die Beschleunigung des Trainingsvorganges (siehe Abschnitt 3.3, Seite 25).Letzteres sollte durch die Verteilung des Trainings in einen Rechnercluster und durch die Im-plementierung verschiedener Algorithmen erreicht werden, was anhand von Performanz- undSkalierungstests überprüft wurde.

Weiterhin wurde die These untersucht, ob sich sowohl syntagmatische als auch paradigma-tische Beziehungen mit einem MLP extrahieren lassen, das mit einem Denoising Autoencodertrainiert wurde.

7.1 Ergebnisse

Validität des Frameworks. Sowohl das MLP-Framework als auch die gesamte Anwendungwurden auf ihre korrekte Funktionsweise überprüft. Wie erwartet verringert sich der Fehlerwertim Laufe des Trainings, während die Werte für Precision/Recall und F-measure steigen. Für dieMONK-Daten als auch für die XOR-Funktion lässt sich demzufolge eine korrekte Funktionsweisefeststellen. Diese Tests und die JUnit-Tests weisen darauf hin, dass das MLP-Framework korrektarbeitet.

Die Funktionalität der gesamten Anwendung wurde mit Hilfe von JUnit-Tests evaluiert, dieebenfalls auf eine korrekte Funktionsweise schließen lassen.

Performanz und Skalierbarkeit. Die gesamte Anwendung wurde auf ihre horizontale undvertikale Skalierbarkeit in Abhängigkeit von Batchgröße, Modellgröße und Anzahl an Trainings-daten untersucht. Als Maß diente der Speedup. Zusammenfassend lässt sich sagen, dass je größer

KAPITEL 7. FAZIT 76

Modell, Batchgröße und Anzahl an Trainingsdaten sind, um so größer ist auch der Speedup.Das liegt darin begründet, dass je größer diese Werte sind umso geringer ist der Anteil derKommunikationskosten an der Gesamtlaufzeit und umso mehr profitiert die Anwendung vonweiteren Rechnern/Threads.

Teilweise konnte eine nahezu lineare Skalierbarkeit erreicht werden, allerdings nur unterVerwendung der Binary-Tree-Kommunikation. Die Anwendung skalierte mit der sequentiellenKommunikation nur bis zu zwei Rechnern. Mit mehr als zwei Rechnern verlangsamte sich mitihr die Anwendung, da die Kommunikationskosten überwogen.

Das Training des MLP beruht auf verschiedenen Rechenoperationen mit Matrizen bzw. mitVektoren. Aus diesem Grund wurde untersucht, inwieweit ein Austauschen der Matrizenbiblio-thek zu einem Geschwindigkeitsgewinn führt. Die untersuchte Matrizenbibliothek jblas war inder Multiplikation zweier Matrizen um den Faktor 10 schneller als die Bibliothek von ApacheMahout, jedoch war insgesamt das Training unter Verwendung von jblas am langsamsten. Dadiese Berechnungen zu einem großen Teil die Gesamtlaufzeit des Programms ausmachen, sollteder Grund hierfür in zukünftigen Arbeiten Gegenstand der Untersuchung sein, evtl. könnte aucheine Kombination der Algorithmen von jblas und Apache Mahout in Betracht gezogen werden.

Bezogen auf den Fehlerwert schnitten MBGD bzw. SGD in den Performanztests am bestenab. Das zweitbeste Verfahren war iRprop+, das ein Big-Batch-Lernverfahren ist. Bezieht mandie Erkenntnisse der Skalierbarkeit mit ein, dann ist iRprop+ das optimale Verfahren. Es er-reicht nicht nur einen geringen Fehlerwert innerhalb weniger Iterationen, sondern weist auchdie geringsten Kommunikationskosten auf und ist damit für die betrachteten Problemstellungenam besten geeignet.

Der Einfluss der Initialisierung des MLP auf den Fehlerwert wurde ebenfalls untersucht.Hier schnitt die Initialisierung mit dem Verfahren von Glorot und Bengio insgesamt gesehenam besten ab.

Analyse der Xing-Daten. Es wurden zwei Netze mit 500 bzw. 1000 Eingaben und mitdem Denoising Autoencoder Ansatz trainiert. Die Ergebnisse lieferten den Hinweis, dass esmöglich sein sollte die syntagmatische Relation zu extrahieren. Bezüglich der paradigmatischenBeziehung kann keine endgültige Aussage getroffen werden. In beiden Fällen sollten weitereUntersuchungen mit einem Goldstandard und evtl. mit einem Sparse Autoencoder durchgeführtwerden.

7.2 Ausblick

Zusammenfassend erlauben die Ergebnisse den Schluss, das sich Apache Hama zum verteiltenTrainieren eines MLP eignet, zumindest für die hier betrachteten Netzgrößen. Sowohl die expli-zite Unterstützung von Iterationen als auch die Möglichkeit das Modell über mehrere Iterationenhinweg im Arbeitsspeicher zu halten sind Grund für die gute Eignung dieses Frameworks.

KAPITEL 7. FAZIT 77

Ein Nachteil von Apache Hama ist die Begrenzung der Kommunikation zwischen Prozessenauf eine synchrone Kommunikation. So kam es vor, dass einzelne BSP-Peers aufgrund der syn-chronen Verarbeitungsweise mehrere Sekunden warten mussten, bis die Berechnungen von allenBSP-Peers abgeschlossen wurden. Die bereits in der Anforderungsanalyse erwähnte Forschungs-arbeit (siehe Unterabschnitt 3.1.2) zeigt, dass insbesondere bei großen neuronalen Netzen eineKombination aus asynchroner und synchroner Kommunikation von Vorteil sein kann, die mitApache Hama nicht umsetzbar ist.

Apache Hama unterstützt ausschließlich die Kommunikation in Form von Punkt-zu-PunktVerbindungen. Die Implementierung der Binary Tree Kommunikation zeigte, dass sich damitdie Kommunikation zwischen verteilten Prozessen effizient gestalten lässt. In zukünftigen Ar-beiten sollten noch weitere Algorithmen zur Inter-Prozess-Kommunikation untersucht werden.Interessant könnte z.B. „Chunk based parallel tree“ sein (siehe [BRF04][Seite 10]).

Zum Trainieren des künstlichen neuronalen Netzes wurden im Rahmen dieser Arbeit aus-schließlich Verfahren erster Ordnung verwendet und auf ein Netz mit nur einer verstecktenSchicht angewendet. In zukünftigen Arbeiten sollten Verfahren zweiter Ordnung in Betrachtgezogen werden. Sowohl die adaptive Lernrate ADAGRAD als auch die Initialisierung der Neu-ronengewichte mit dem Verfahren von Nguyen und Widrow wurden für künstliche neuronaleNetze mit mehreren versteckten Schichten entwickelt. Sie sollten dementsprechend noch anhandvon Netzen mit mehreren versteckten Schichten untersucht werden.

Anhang A

Klassendiagramme

de.distMLP.communication.MessageDistributor <<abstract>>

-peer:ABSPPeer<?,A?,A?,AHamaMessage>-peerMap:AMap<Integer,AString>-peerToIntMap:AMap<String,AInteger>-loaclPeerMap:AMap<Integer,AString>-localPeerToIntMap:AMap<String,AInteger>

+distributeMessageToAllPeers(senderName:String,msg:HamaMessage,peerNames:String[]):AHamaMessage+distributeAndAggregateMessageToMasterPeer(msg:HamaMessage,masterPeer:String):AHamaMessage

de.distMLP.communication.SimpleMessageDistributor

de.distMLP.communication.BTreeMessageDistributor

Abbildung A.1: Klassen zur Verteilung von Nachrichten

ANHANG A. KLASSENDIAGRAMME 80

org.apache.hadoop.io.Writable <<interface>>

+write(output:java.io.DataOutput)+readFields(input:java.io.DataInput)

de.distmlp.messages.HamaMessage

de.distmlp.messages.DoubleMessage

-doubleValue:[double

de.distmlp.messages.WeightMatrixMessage

-matrix:[Matrix[]-stopTraining:[boolean-cost:[double

Abbildung A.2: Klassen zur Realisierung der Nachrichten

<<interface>>org.apache.hadoop.io.Writable

<<nterface>>de.mlp_distributed.mlp.learning.OnlineLearner

<<abstract>>de.mlp_distributed.mlp.classfier.AbstractVectorClassifier

AclassifyFullginstance:VectorR

de.mlp_distributed.mlp.core.MultiLayerPerceptron

AMultiLayerPerceptrongnbInputUnits:intDnbOutputUnits:intDnbHiddenUnits:int[]DmutuallyExclusiveClasses:booleanDmomentum:doubleRAassignRegularizationAndLearningrateggradients:Matrix[]RAgetDerivativeOfTheCostWithoutRegularizationginput:VectorDtarget:VectorRAtrainOnlineginput:VectorDtarget:VectorR

Abbildung A.3: Darstellung der wichtigsten Methoden und Klassen des verwendeten MLP-Frameworks.


<<interface>>de.mlp_distributed.mlp.math.mahout.Vector

+assign(value:double):MVector+assign(f:DoubleDoubleFunction,y:double):MVector+plus(x:Vector):MVector+cross(other:Vector):MMatrix

de.mlp_distributed.mlp.math.jblas.JDenseVector

mjdm:MDoubleMatrix

de.mlp_distributed.mlp.math.mahout.AbstractVector

+size:Mint

de.mlp_distributed.mlp.math.mahout.RandomAccessSparseVector

Abbildung A.4: Darstellung der verwendeten Vektorklassen inkl. deren wichtigsten Methoden.


<<abstract>>org.apache.hama.bsp.BSP<K1,LV1,LK2,LV2,LMLextendsLWritable>

fbspdpeer:BSPPeer<K1hLV1hLK2hLV2hLM>E:LVectorfsetupdpeer:BSPPeer<K1hLV1hLK2hLV2hLM>Efcleanupdpeer:BSPPeer<K1hLV1hLK2hLV2hLM>E

<<abstract>>de.distMLP.train.Base_MLP_Trainer

Wmlp:LMultiLayerPerceptron

fsetupdpeer:BSPPeer<LongWritablehLTexthLNullWritablehTexthLHamaMessage>Efcleanupdpeer:BSPPeer<LongWritablehLTexthNullWritablehLTexthLHamaMessage>EfreadNextTrainingExampledpeer:BSPPeer<LongWritablehTexthLNullWritablehTexthLHamaMessage>hex:TrainingExampleE:LbooleanfreopenInputdpeer:finalLBSPPeer<LongWritablehTexthLNullWritablehLTexthLHamaMessage>EWupdateWeightMatrixdgradients:Matrix[]EfsaveMLPdpeer:BSPPeer<LongWritablehLTexthNullWritablehLTexthLHamaMessage>hiterationNumber:intE

de.distMLP.train.MLP_MiniBatchGD

fbspdpeer:BSPPeer<LongWritablehLTexthLNullWritablehTexthLHamaMessage>E

de.distMLP.train.MLP_RPROP

WupdateWeightMatrixdgradients:Matrix[]E

Abbildung A.5: Darstellung der BSP-Jobklassen.

Anhang B

Einzelergebnisse derPerformancetests

B.1 MONK: Anzahl Iterationen bis zum Fehlerwert 0,1

Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/WidrowBGD

Maximum: 4690 4697 4630Minimum: 3562 3140 3551

Konfidenzintervall: 4119,85 ± 47,24 4160,71 ± 47,14 4095,93 ± 51,44ADAGRAD η = 1

Maximum: 50000 35848 43024Minimum: 2629 3047 2800

Konfidenzintervall: 6007 ± 1570,56 5739 ± 921,16 5006 ± 792,38MomentumMaximum: 920 992 2072Minimum: 652 655 565

Konfidenzintervall: 805 ± 10,9 821 ± 12,66 802,72 ± 28,82ADAGRAD & Momentum

Maximum: 50000 50000 18585Minimum: 699 1009 696

Konfidenzintervall: 5930,67 ± 1186,14 4358 ± 1066,18 3521,2 ± 654,82

Tabelle B.1: BGD: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1

ANHANG B. EINZELERGEBNISSE DER PERFORMANCETESTS 84

Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/WidrowMaximum: 228 123 146Minimum: 37 38 37

Konfidenzintervall: 62,97 ± 4,38 63,47 ± 3,4 65,61 ± 3,42

Tabelle B.2: iRprop+: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1

Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/WidrowSGD

Maximum: 105 156 108Minimum: 33 39 39

Konfidenzintervall: 63,45 ± 2,9 63,33 ± 17,03 66,49 ± 3,04ADAGRAD (η = 1)

Maximum: 107 8867 152Minimum: 38 39 37

Konfidenzintervall: 62,64 ± 2,82 151,14 ± 176,1 66,74 ± 3,42MomentumMaximum: 132 108 142Minimum: 35 32 41

Konfidenzintervall: 64,45 ± 3,24 62,19 ± 3,08 64,78 ± 3,38Momentum & ADAGRAD

Maximum: 166 1674 125Minimum: 38 38 36


Tabelle B.3: SGD: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1


B.2 MONK: Fehlerwert nach 50 Iterationen


Maximum: 65,98 69,2 65,91Minimum: 53,66 48,68 55,99

Konfidenzintervall: 61,42 ± 0,553 58,69 ± 0,782 61,83 ± 0,489ADAGRAD η = 1

Maximum: 62,22 60,93 59,32Minimum: 19,27 18,70 27,601

Konfidenzintervall: 45,69 ± 1,662 45,46 ± 1,594 46,67 ± 1,487MomentumMaximum: 51,65 50,35 57,65Minimum: 4,73 3,52 4,80

Konfidenzintervall: 26,48 ± 2,3 24,65 ± 2,658 26,02 ± 2,375ADAGRAD & Momentum

Maximum: 40,92 37,05 26,79Minimum: 83,03 86,03 86,01


Tabelle B.4: BGD: Fehlerwert nach 50 Iterationen

Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/WidrowMaximum: 39,389 36,552 33,505Minimum: 0,046 0,051 0,058


Tabelle B.5: iRprop+: Fehlerwert nach 50 Iterationen


Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/WidrowSGD

Maximum: 33,394 28,071 31,95Minimum: 0,052 0,045 0,064

Konfidenzintervall: 5,998 ± 1,602 4,687 ± 1,316 7,272 ± 1,698ADAGRAD (η = 1)

Maximum: 29,43 38,42 47,64Minimum: 0,036 0,058 0,061


Konfidenzintervall: 6,65 ± 2,07 4,61 ± 1,34 6,87 ± 1,85Momentum & ADAGRAD

Maximum: 33,57 36,44 48,37Minimum: 0,047 0,051 0,052


Tabelle B.6: SGD: Fehlerwert nach 50 Iterationen


B.3 Xing20: Fehlerwert nach 50 Iterationen


Maximum: 6,227 5,68 6,45Minimum: 5,503 4,85 5,82

Konfidenzintervall: 5,762 ± 0,026 5,16 ± 0,03 6,06 ± 0,002Adagrad (η = 0.1)

Maximum: 1,91 1,86 1,87Minimum: 1,43 1,19 1,5


Konfidenzintervall: 2,58 ± 0,019 2,16 ± 0,018 2,82 ± 0,018Adagrad & Momentum (η = 0.1)

Maximum: 0,57 0,46 0,66Minimum: 0,35 0,29 0,35


Tabelle B.7: Batch Lernverfahren: Fehlerwert nach 50 Iterationen.

Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/WidrowMaximum: 0,1835 0,1732 0,1909Minimum: 0,1383 0,1359 0,1333


Tabelle B.8: iRprop+: Fehlerwert nach 50 Iterationen.


Messwerte/Initialisierungen LeCun Lorot/Bengio Ngyen/WidrowMBGD 100Maximum: 0,17 0,17 0,168Minimum: 0,132 0,133 0,1336


Konfidenzintervall: 0,134 ± 0,0014 0,132 ± 0,0014 0,133 ± 0,0014ADAGRADMaximum: 0,177 0,164 0,18Minimum: 0,131 0,129 0,133

Konfidenzintervall: 0,152 ± 0,002 0,144 ± 0,0018 0,156 ± 0,002ADAGRAD & Momentum

Maximum: 0,134 0,132 0,132Minimum: 0,117 0,116 0,116


Tabelle B.9: Mini Batch (100) Lernverfahren: Fehlerwert nach 50 Iterationen.

Anhang C

Fehlerrechnung

Bei der Aufnahme von mehreren Messwerten für den gleichen Vorgang, lassen sich oftmalsAbweichungen aufgrund zufälliger Fehler feststellen. Bei der Performancemessung von Java-Programmen können Abweichungen z.B. durch den Just-in-Time Compiler oder den GarbageCollector ausgelöst werden. Damit nun einzelne Ausreißer nicht die Messwerte verfälschen,muss eine Fehlerrechnung durchgeführt werden. Als Quelle für die folgenden Ausführungendiente [Wikc].

Für N Messwerte erlaubt das arithmetische Mittel eine bessere Aussage als Einzelwerte (vj).Es gilt folgende Gleichung für das arithmetische Mittel v̄:

v̄ = 1N

N∑j=1

vj . (C.1)

Die empirische Standardabweichung s ist, in Kombination mit der Unsicherheit u, ein Maß fürdie Streuung der Messwerte. Die empirische Standardabweichung wird folgendermaßen berech-net:

s =

√√√√ 1N − 1

N∑j=1

(vj − v̄

)2. (C.2)

Für die der Berechnung der Unsicherheit, gilt:

u = 1√N· s. (C.3)

Für alle im Rahmen dieser Arbeit vorgenommenen Messungen, gilt N >= 40, ein Konfi-denzniveau von 95% und damit der Konfidenzintervall: v̄ − 2 · u · · · v̄ + 2 · u.

Anhang D

Metriken

Die Metriken Precision/Recall und f-measure werden oft in der statistischen Sprachverarbeitungverwendet (NLP) und dienen im Rahmen dieser Arbeit als Qualitätsmaß für Klassifikatoren.Als Quelle wurde hier [MS99] benutzt (Seiten 267-271).

Der Speedup wird zur Bewertung der Skalierbarkeit eines verteilten Systems benutzt (Quel-len: [Wikd], [Wika]).

D.1 Precision/Recall

Zur Berechnung von Precision und Recall müssen als erstes die Anteile von „true negative“(TN), „false negative“ (FN), „true positive“ (TP) und „false positive“ (FP) an der Gesamtmengegemessen werden.

Im Rahmen der Klassifizierung eines Zwei-Klassen-Problems gilt folgende Matrix:

Deklariere als Klasse I Deklariere als Klasse IIIst Klasse I TP FNIst Klasse II FP TN

Tabelle D.1: Confusion Matrix

Die Precision wird folgendermaßen ermittelt:

Precision = tp

tp+ fp. (D.1)

Die Precision wird also berechnet, indem die Anzahl der korrekt gelabelten Daten durch dieGesamtzahl, der als zu dieser Klasse gehörigen Daten, geteilt wird. Ein Wert von 1.0 gibtan, dass alle als zu dieser Klassen gehörig gelabelten Daten auch tatsächlich zu dieser Klassegehören. Er sagt aber nichts darüber aus, wie viele Daten, die auch zu dieser Klasse gehören,nicht korrekt gelabelt wurden.

ANHANG D. METRIKEN 92

Der Recall wird folgendermaßen ermittelt:

Recall = tp

tp+ fn(D.2)

Der Recall wird also berechnet, indem die Anzahl der korrekt als Klasse I gelabelten Datendurch die Gesamtzahl an Daten, die insgesamt zur Klasse I gehören, geteilt wird. Ein Wert von1.0 bedeutet hier, dass alle zur Klasse I gehörigen Daten auch als zu Klasse I gehörig gelabeltwurden. Dieser Wert kann allerdings auch bedeuten, dass alle Werte als zu Klasse I gelabeltwurden

D.2 F-measure

Der F-measure kombiniert Precision und Recall zu einem Maß, wodurch besser die Gesamt-performance ermittelt werden kann. Es werden im Rahmen dieser Arbeit Precision und Recallgleich gewichtet (auch F1 score genannt), so dass sich folgende Gleichung ergibt:

F1 = 2 · precision · recallprecision+ recall

(D.3)

D.3 Speedup

Der Speedup ist folgendermaßen definiert:

Sp = T1

Tp(D.4)

Dabei gilt, dass p gleich der Anzahl an Prozessoren ist, T1 die Ausführungszeit des sequentiel-len Algorithmus und Tp die Ausführungszeit des parallelen Algorithmus mit p Prozessoren ist.Der Speedup ist ein Maß dafür, wie stark ein Algorithmus durch die Parallelisierung beschleu-nigt wurde. Wenn die Ausführungszeit halbiert wird, durch die Verdoppelung der Anzahl anProzessoren, dann spricht man von einem linearen Speedup.

Ein weiteres Maß ist die Effizienz, die folgendermaßen definiert ist:

Ep = Spp

(D.5)

Die Effizienz gibt an, wie viel Aufwand mit Kommunikation und Synchronisation verschwendetwird. Es gilt Ep = 1, wenn ein linearer Speedup erreicht wurde.

Laut dem Amdahlschen Gesetz ist die Parallelisierbarkeit eines Algorithmus durch seinensequentiellen Anteil begrenzt. Nach dem Amdahlschen Gesetz gilt, mit B ∈ [0, 1] gleich demsequentiellen Anteil, folgende Gleichung:

Tp = T1

(B + 1

p

(1−B

))(D.6)

Anhang E

Normalisierung vonTrainingsdaten

Je nach Anwendungsfall müssen die Daten aufbereitet werden, indem sie normalisiert werden.Die Daten werden dabei in einen neuen Wertebereich überführt, der vom Wertebereich derAktivierungsfunktion abhängt. Im Rahmen dieser Arbeit traf dies auf das MONK Problem zu,da die Features in unterschiedlichen Wertebereichen lagen. Auf eine Denormalisierung konnteverzichtet werden, da es sich um ein Klassifizierungsproblem handelt, die Ausgabe also entwedereins oder null ist.

Die Werte des neuen Wertebereichs liegen beim MONK Problem zwischen -1 und 1. ZurNormalisierung werden zuerst Maxima und Minima über alle Eingabedaten berechnet und ge-speichert. Die Berechnung erfolgt für jedes Feature getrennt. Die Normalisierung erfolgt mittelsfolgender Gleichung:

EingabeNorm = (Eingabe−Minima)(1−(−1)Maxima−Minima − 1

Um die Bestimmung von Minima und Maxima zu beschleunigen, werden mehrere Threadsbenutzt. Die Anzahl der Threads entspricht dabei der Anzahl der verfügbaren Prozessoren. DieImplementierung erfolgte mit Hilfe von Thread-Pools und dem ExecutorCompletionService.

Die Eingabe besteht jeweils aus einem Array, das die zu untersuchenden Daten enthält.Dieses Array wird in gleich große Bereiche unterteilt und jeweils von einem Thread bearbeitet.Falls das Array nicht in gleich große Bereiche aufgeteilt werden kann, dann übernimmt einThread zusätzlich den Rest. Zum Schluss werden die Ergebnisse der einzelnen Threads zusam-mengeführt und das endgültige Ergebnis berechnet. Durch die Verwendung mehrerer Threadskonnte dieser Vorgang zumindest messbar beschleunigt werden, auch wenn zugegebenermaßendieser Teil gemessen an der teils sehr langen Trainingszeit nur sehr gering ausfällt.

Anhang F

Verteiltes Training mit BSP inPseudocode

Im ersten Schritt werden das MLP initialisiert, das Modell sowie global gültige Einstellungenauf alle BSP-Peers kopiert und ein Master-Peer gewählt (Zeile 1). Die nächsten Schritte werdenso lange ausgeführt, bis entweder die Fehlerfunktion konvergiert1, eine bestimmte Anzahl anIterationen oder ein bestimmter Fehlerwert erreicht wurde (Zeilen 2 - 30).

1 global: model, parameter, masterPeer, iterationCounter <- 0;

2 while(true) {

3 ResetFilePointer();

4 iterationCounter <- iterationCounter +1;

5 while(processedData<= dataSize) {

6 for(batchProcessed<= batchSize) {

7 gradientSum <- gradientSum+ CalculateGradient();

8 }

9 CalculatePartialAverageGradient();

10 SendAverageGradientToMaster();

11 SynchronizePeers();

12 if(masterPeer) {

13 UpdateModel();

14 SendModelToAllPeers();

15 }

16 SynchronizePeers();

17 UpdateModel();

1Ein lokales Minnimum wurde erreicht, erkennbar daran, dass die Änderungsrate des Fehlerwerts, über alleTrainingsdaten, unter einem gewissen Schwellwert liegt.

ANHANG F. VERTEILTES TRAINING MIT BSP IN PSEUDOCODE 96

18 }

19 CalculateError();

20 if(StopTraining()) { break; }

21 }

Listing F.1: Allgemeine Vorgehensweise in Pseudocode

Zu Beginn einer Iteration wird der Dateizeiger wieder auf den Anfang gesetzt (Zeile 3). Dannwird der Iterationszähler hochgezählt (Zeile 4), da er ein Abbruchkriterium ist.

Die nächsten Schritte für BGD einmal und für MBGD mehrmals ausgeführt (Zeilen 5-20).Als erstes werden die Gradienten für die lokal vorliegenden Daten berechnet und aufsummiert(Zeilen 9-11). Dann wird die Teilsumme durch die Batchgröße geteilt (Zeile 12) und an einenMaster-Peer gesendet (Zeile 13).

Der Master-Peer berechnet den durchschnittlichen Gradienten und das Gewichtsupdate (Zei-le 16). Das neue Modell wird dann an alle BSP-Peers gesendet. Wurde ein Abbruchkriteriumerfüllt, dann wird das Training beendet ansonsten beginnt die nächste Iteration. Das Abbruch-kriterium wird in Zeile 20 geprüft, dabei gilt es zu beachten, dass je nach Abbruchkriteriumdie Prüfung nur durch den Master-Peer erfolgen kann. In dem Fall muss der Master-Peer eineNachricht an alle BSP-Peers schicken, um das Training anzuhalten.

Das Gewichtsupdate erfolgt wie beschrieben nur auf dem Master-Peer. Für Momentum,iRprop+ und ADAGRAD, bedeutet dies, dass die jeweils benötigten Daten auch nur auf demMaster-Peer im Arbeitsspeicher gehalten werden. Das ist z.B. im Falle von Momentum, eineMatrix mit der letzten Gewichtsänderung. Auf allen BSP-Peers muss das Modell, also die Ge-wichtsverbindungen der Neuronen, im Arbeitsspeicher gehalten werden. Die Anforderungen anden Arbeitsspeicher sind also, bis auf den Master-Peer, bei allen BSP-Peers gleich groß undhängen von der Anzahl an Gewichtsverbindungen ab.

Anhang G

Abkürzungsverzeichnis

BGD Batch Gradient Descent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

BSP bulk-synchronous parallel model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

EP Exemplar Parallelism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

HDFS Hadoop Distributed Filesystem. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18

iRprop+ Improved Resilient Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

MBGD Mini Batch Gradient Descent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

MLP Multilayer Perceptron . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

MPI Message Passing Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Rprop Resilient Propagation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

SGD Stochastic Gradient Descent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

Anhang H

Abbildungsverzeichnis

2.1 Neuronenmodell1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Multilayer Perceptron mit einem hidden layer2 . . . . . . . . . . . . . . . . . . . 72.3 Gradientenabstieg auf zweidimensionaler Fehlerfunktion3 . . . . . . . . . . . . . . 102.4 Mögliche Probleme beim Gradientenabstieg4 . . . . . . . . . . . . . . . . . . . . 122.5 bulk-synchronous parallel modell5 . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.6 Architektur von Apache Hama6 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Verteilung eines neuronalen Netzwerks, am Beispiel lokal verbundener Neuronen.7 223.2 Links: Downpour SGD. Rechts: Sandblaster L-BFGS8 . . . . . . . . . . . . . . . 22

4.1 Systemübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Schematische Darstellung des Vorgehens innerhalb einer Iteration. . . . . . . . . 324.3 Binary Tree Kommunikation in drei Phasen am Beispiel von acht Rechnern9 . . . 35

5.1 Parser-Klassen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.2 Trainingsdaten-Klasse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1 Gegenüberstellung von Speedup und Iterationsdauer . . . . . . . . . . . . . . . . 546.2 Gegenüberstellung von Speedup und Iterationsdauer . . . . . . . . . . . . . . . . 556.3 Prozentualer Anteil von Kommunikation und Gradientenberechnung an der ge-

samten Iterationsdauer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 566.4 Gegenüberstellung von Speedup und Iterationsdauer . . . . . . . . . . . . . . . . 576.5 Prozentualer Anteil von Kommunikation und Gradientenberechnung an der ge-

samten Iterationsdauer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 576.6 horizontale Skalierung mit 3.840 Trainingsdaten . . . . . . . . . . . . . . . . . . . 586.7 Speedup für 3.840 Trainingsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . . 586.8 horizontale Skalierung mit 38.400 Trainingsdaten . . . . . . . . . . . . . . . . . . 596.9 Speedup für 38.400 Trainingsdaten . . . . . . . . . . . . . . . . . . . . . . . . . . 59

ABBILDUNGSVERZEICHNIS 100

6.10 Cache: Gegenüberstellung von Speedup und Ladezeit . . . . . . . . . . . . . . . . 606.11 Kommunikation: Gegenüberstellung von Speedup und Iterationsdauer . . . . . . 616.12 Prozentualer Anteil von Kommunikation und Gradientenberechnung an der ge-

samten Iterationsdauer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.13 MONK: Vergleich der Trainingsverfahren und Initialisierungsarten, anhand der

Anzahl an Iterationen bis zum Fehlerwert 0,1, mit logarithmischer Skalierung. . . 656.14 Xing (20): Vergleich der Trainingsverfahren und Initialisierungsarten, anhand des

Fehlerwerts nach 50 Iterationen, mit logarithmischer Skalierung. . . . . . . . . . 666.15 MONK: Vergleich der Trainingsverfahren und Initialisierungsarten, anhand des

Fehlerwerts nach 50 Iterationen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 676.16 Xing (20): Fehlerkurve über 50 Iterationen in Abhängigkeit zum Lernverfahren,

exemplarisch für den Seed-Wert eins. . . . . . . . . . . . . . . . . . . . . . . . . . 686.17 Training des MLP mit der Identität ohne verrauschten Eingabevektor. . . . . . . 716.18 Analyse von Ausgabe- bzw. versteckter Schicht in Abhängigkeit der gesuchten

Beziehung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

A.1 Klassen zur Verteilung von Nachrichten . . . . . . . . . . . . . . . . . . . . . . . 79A.2 Klassen zur Realisierung der Nachrichten . . . . . . . . . . . . . . . . . . . . . . 80A.3 Darstellung der wichtigsten Methoden und Klassen des verwendeten MLP-

Frameworks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80A.4 Darstellung der verwendeten Vektorklassen inkl. deren wichtigsten Methoden. . . 81A.5 Darstellung der BSP-Jobklassen. . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Anhang I

Sourcecodeverzeichnis

2.1 iRprop+ in Pseudocode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2 Methodensignatur von BSP.bsp() . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3 Beispiel der Kommunikation zwischen BSP-Peers . . . . . . . . . . . . . . . . . . 204.1 Sparse Autoencoder mit BSP in Pseudocode . . . . . . . . . . . . . . . . . . . . . 375.1 Initialisierung der Verbindungsgewichte mit dem Verfahren von Glorot-Bengio . . 415.2 Initialisierung der Verbindungsgewichte mit dem Verfahren von Nguyen-Widrow 425.3 Factory-Klasse zur Erzeugung von Matrix von Matrix- und Vektor-Factories . . . 436.1 Ermittlung der benutzten Methoden und deren Laufzeit mit Aspectj . . . . . . . 62F.1 Allgemeine Vorgehensweise in Pseudocode . . . . . . . . . . . . . . . . . . . . . . 95

Anhang J

Tabellenverzeichnis

6.1 Hardware-/Softwareausstattung der Hostrechner . . . . . . . . . . . . . . . . . . 496.2 Softwareausstattung der virtuellen Maschine . . . . . . . . . . . . . . . . . . . . . 506.3 XOR-Funktion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506.4 XOR: Confusion Matrix und Metriken in Abhängigkeit zum Fehlerwert . . . . . 516.5 MONK: Auflistung aller Attribute und ihrer Ausprägungen. Der Wert in den

Klammern gibt an, welche Zahl dieses Attribut im Eingabevektor repräsentiert. . 526.6 Monk: Confusion Matrix und Metriken in Abhängigkeit zum Fehlerwert . . . . . 536.7 Zeitmessung der Gradientenberechnung für ein Trainingsbeispiel in ms . . . . . . 616.8 Linux: Zeitmessung verschiedener Rechenoperationen in ms für eine 1000x1000

Matrix und einen Vektor mit 1000 Zeilen. . . . . . . . . . . . . . . . . . . . . . . 63

B.1 BGD: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1 . . . . . . . . . 83B.2 iRprop+: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1 . . . . . . . 84B.3 SGD: Anzahl Iterationen bis zur Erreichung des Fehlerwerts 0, 1 . . . . . . . . . 84B.4 BGD: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . . . . . . . 85B.5 iRprop+: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . . . . . 85B.6 SGD: Fehlerwert nach 50 Iterationen . . . . . . . . . . . . . . . . . . . . . . . . . 86B.7 Batch Lernverfahren: Fehlerwert nach 50 Iterationen. . . . . . . . . . . . . . . . . 87B.8 iRprop+: Fehlerwert nach 50 Iterationen. . . . . . . . . . . . . . . . . . . . . . . 87B.9 Mini Batch (100) Lernverfahren: Fehlerwert nach 50 Iterationen. . . . . . . . . . 88

D.1 Confusion Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

Anhang K

Literaturverzeichnis

[Abe] Abeles, Peter: Java Matrix Benchmark. http://code.google.com/p/

java-matrix-benchmark/, Abruf: 2014.02.09

[And] Andrew Ng: Sparse autoencoder. http://www.stanford.edu/class/cs294a/

sparseAutoencoder_2011new.pdf, Abruf: 2014.02.09

[Apa] Apache Software Foundation: Apache Mahout. http://mahout.apache.org/,Abruf: 2014.02.09

[BL13] Bache, K. ; Lichman, M.: UCI Machine Learning Repository. http://archive.ics.

uci.edu/ml. Version: 2013

[Bot98] Bottou, Léon: Online Algorithms and Stochastic Approximations. Version: 1998.http://leon.bottou.org/papers/bottou-98x. In: Saad, David (Hrsg.): OnlineLearning and Neural Networks. Cambridge, UK : Cambridge University Press,1998. – revised, oct 2012

[Bra] Braun, Mikio: jblas: linear algebra for java. http://mikiobraun.github.io/jblas/,Abruf: 2014.02.09

[BRF04] Biersack, Ernst W ; Rodriguez, Pablo ; Felber, Pascal A: Performance ana-lysis of peer-to-peer networks for file distribution. In: QOFIS 2004, 5th Interna-tional Workshop on Quality of Future Internet Services, September 29-October 1,2004, Barcelona, Spain / Also published in "LNCS", Volume 3266/2004. Barcelona,SPAIN, 09 2004

[CH13] Cenk, Murat ; Hasan, M. A.: On the Arithmetic Complexity of Strassen-LikeMatrix Multiplications. Cryptology ePrint Archive, Report 2013/107, 2013. – http:

//eprint.iacr.org/

[Chr96] Christopher M. Bishop: Neural Networks - for Pattern Recognition. ClarendonPress, Oxford, 1996

http://code.google.com/p/java-matrix-benchmark/

http://code.google.com/p/java-matrix-benchmark/

http://www.stanford.edu/class/cs294a/sparseAutoencoder_2011new.pdf

http://www.stanford.edu/class/cs294a/sparseAutoencoder_2011new.pdf

http://mahout.apache.org/

http://archive.ics.uci.edu/ml

http://archive.ics.uci.edu/ml

http://leon.bottou.org/papers/bottou-98x

http://mikiobraun.github.io/jblas/

http://eprint.iacr.org/

http://eprint.iacr.org/

ANHANG K. LITERATURVERZEICHNIS 106

[CHW+13] Coates, Adam ; Huval, Brody ; Wang, Tao ; Wu, David J. ; Catanzaro, Bry-an C. ; Ng, Andrew Y.: Deep learning with COTS HPC systems. In: ICML (3)Bd. 28, JMLR.org, 2013 (JMLR Proceedings), 1337-1345

[CL11] Chang, Chih-Chung ; Lin, Chih-Jen: LIBSVM: A library for support vector ma-chines. In: ACM Transactions on Intelligent Systems and Technology 2 (2011), S.27:1–27:27. – Software available at http://www.csie.ntu.edu.tw/~cjlin/libsvm

[CTM09] Cabreira, A. G. ; Tripode, M. ; Madirolas, A.: Artificial neural networks forfish-species identification. In: Ices Journal of Marine Science 66 (2009), S. 1119–1129. http://dx.doi.org/10.1093/icesjms/fsp009. – DOI 10.1093/icesjms/fsp009

[DCM+12] Dean, Jeffrey ; Corrado, Greg S. ; Monga, Rajat ; Chen, Kai ; Devin, Matthieu; Le, Quoc V. ; Mao, Mark Z. ; Ranzato, Marc’Aurelio ; Senior, Andrew ; Tu-cker, Paul ; Yang, Ke ; Ng, Andrew Y.: Large Scale Distributed Deep Networks.In: NIPS, 2012

[det] details, See homepage f.: ATLAS homepage. http://math-atlas.sourceforge.net/,Abruf: 2014.02.09

[DG08] Dean, Jeffrey ; Ghemawat, Sanjay: MapReduce: Simplified Data Processing onLarge Clusters. In: Commun. ACM 51 (2008), Januar, Nr. 1, 107–113. http:

//dx.doi.org/10.1145/1327452.1327492. – DOI 10.1145/1327452.1327492. – ISSN0001–0782

[DHS11] Duchi, John ; Hazan, Elad ; Singer, Yoram: Adaptive Subgradient Methods forOnline Learning and Stochastic Optimization. In: J. Mach. Learn. Res. 12 (2011),Juli, 2121–2159. http://dl.acm.org/citation.cfm?id=1953048.2021068. – ISSN1532–4435

[eso] esoteric software: Kryo. https://github.com/EsotericSoftware/kryo, Abruf:2014.02.09

[Fou] Foundation, Eclipse: aspectj. http://eclipse.org/aspectj/, Abruf: 2014.02.09

[GB10] Glorot, Xavier ; Bengio, Yoshua: Understanding the difficulty of training deepfeedforward neural networks. In: In Proceedings of the International Conferenceon Artificial Intelligence and Statistics (AISTATS’10). Society for Artificial Intel-ligence and Statistics, 2010

[GGKK07] Grama, A. ; Gupta, A. ; Karypis, G. ; Kumar, V.: Introduction to ParallelComputing, Second Edition. 2007. – erhältlich auf http://www.dkriesel.com

[GKWZ07] Gorban, Alexander N. ; Kgl, Balzs ; Wunsch, Donald C. ; Zinovyev, Andrei:Principal Manifolds for Data Visualization and Dimension Reduction. 1st. SpringerPublishing Company, Incorporated, 2007. – ISBN 3540737499, 9783540737490

http://www.csie.ntu.edu.tw/~cjlin/libsvm

http://dx.doi.org/10.1093/icesjms/fsp009

http://math-atlas.sourceforge.net/

http://dx.doi.org/10.1145/1327452.1327492

http://dx.doi.org/10.1145/1327452.1327492

http://dl.acm.org/citation.cfm?id=1953048.2021068

https://github.com/EsotericSoftware/kryo

http://eclipse.org/aspectj/


[GLS94] Gropp, William ; Lusk, Ewing ; Skjellum, Anthony: Using MPI: Portable Par-allel Programming with the Message-Passing Interface. MIT Press, 1994

[Goo] Google: Guice. http://code.google.com/p/google-guice/, Abruf: 2014.02.09

[Hin07] Hinton, Geoffrey E.: Learning multiple layers of representation. In: Trends inCognitive Sciences 11 (2007), S. 428–434

[Hoc98] Hochreiter, Sepp: The Vanishing Gradient Problem During Learning Re-current Neural Nets and Problem Solutions. In: Int. J. Uncertain. FuzzinessKnowl.-Based Syst. 6 (1998), April, Nr. 2, 107–116. http://dx.doi.org/10.1142/

S0218488598000094. – DOI 10.1142/S0218488598000094. – ISSN 0218–4885

[HS06a] Hinton, G E. ; Salakhutdinov, R R.: Reducing the dimensionality of data withneural networks. In: Science 313 (2006), Juli, Nr. 5786, 504-507. http://dx.doi.

org/10.1126/science.1127647. – DOI 10.1126/science.1127647

[HS06b] Hinton, G E. ; Salakhutdinov, R R.: Reducing the dimensionality of data withneural networks. In: Science 313 (2006), Juli, Nr. 5786, 504-507. http://dx.doi.

org/10.1126/science.1127647. – DOI 10.1126/science.1127647

[IH00] Igel, Christian ; Hüsken, Michael: Improving the Rprop Learning Algorithm. In:Proceedings of the Second International ICSC Symposium on Neural Computation(NC 2000), ICSC Academic Press, 2000, S. 115–121

[Kri94] Kriesel, David: Ein kleiner Überblick über Neuronale Netze. 1994

[LBOM98] LeCun, Yann ; Bottou, Leon ; Orr, Genevieve ; Müller, Klaus: Efficient Back-Prop. Version: 1998. http://dx.doi.org/10.1007/3-540-49430-8_2. In: NeuralNetworks: Tricks of the Trade. Springer Berlin / Heidelberg, 1998 (Lecture Notes inComputer Science). – DOI 10.1007/3–540–49430–8_2. – ISBN 978–3–540–65311–0,Kapitel 2, 546

[LRM+12] Le, Quoc ; Ranzato, Marc’Aurelio ; Monga, Rajat ; Devin, Matthieu ; Chen,Kai ; Corrado, Greg ; Dean, Jeff ; Ng, Andrew: Building high-level featuresusing large scale unsupervised learning. In: International Conference in MachineLearning, 2012

[MRS08] Manning, Christopher D. ; Raghavan, Prabhakar ; Schütze, Hinrich: Introduc-tion to Information Retrieval. New York, NY, USA : Cambridge University Press,2008. – ISBN 0521865719, 9780521865715

[MS99] Manning, C. ; Schütze, H.: Foundations of statistical natural language processing.1999

http://code.google.com/p/google-guice/

http://dx.doi.org/10.1142/S0218488598000094

http://dx.doi.org/10.1142/S0218488598000094

http://dx.doi.org/10.1126/science.1127647




http://dx.doi.org/10.1007/3-540-49430-8_2


[NW90] Nguyen, D. ; Widrow, B.: Improving the learning speed of 2-layer neural networksby choosing initial values of the adaptive weights. (1990), Juni, 21–26 vol.3. http:

//dx.doi.org/10.1109/IJCNN.1990.137819. – DOI 10.1109/IJCNN.1990.137819

[Ora] Oracle: Hudson. http://hudson-ci.org/, Abruf: 2014.02.09

[RB92] Riedmiller, Martin ; Braun, Heinrich: RPROP - A Fast Adaptive LearningAlgorithm / Proc. of ISCIS VII), Universitat. 1992. – Forschungsbericht

[RHW88] Rumelhart, D. E. ; Hinton, G. E. ; Williams, R. J.: Neurocomputing: foundati-ons of research. Version: 1988. http://dl.acm.org/citation.cfm?id=65669.104449.Cambridge, MA, USA : MIT Press, 1988. – ISBN 0–262–01097–6, Kapitel Learninginternal representations by error propagation, 673–695

[RS98] Rogers, R. O. ; Skillicorn, D. B.: Using the BSP cost model to optimise parallelneural network training. In: Future Generation Comp. Syst. 14 (1998), Nr. 5-6, 409-424. http://dblp.uni-trier.de/db/journals/fgcs/fgcs14.html#RogersS98

[Sim05] Simon Haykin: Neural Networks - A Comprehensive Foundation. Pearson, Pren-tice Hall, 2005

[SYK+10] Seo, Sangwon ; Yoon, Edward J. ; Kim, Jaehong ; Jin, Seongwook ; Kim, Jin-Soo ; Maeng, Seungryoul: HAMA: An Efficient Matrix Computation with theMapReduce Framework. In: Proceedings of the 2010 IEEE Second InternationalConference on Cloud Computing Technology and Science. Washington, DC, USA: IEEE Computer Society, 2010 (CLOUDCOM ’10). – ISBN 978–0–7695–4302–4,721–726

[TBB+91] Thrun, Sebastian ; Bala, J. ; Bloedorn, E. ; Bratko, I. ; Cestnik, B. ; Cheng,J. ; Jong, K. D. ; Dzeroski, S. ; Hamann, R. ; Kaufman, K. ; Keller, S. ; Ko-nonenko, I. ; Kreuziger, J. ; Michalski, R.S. ; Mitchell, Tom ; Pachowicz,P. ; Roger, B. ; Vafaie, H. ; Velde, W. V. ; Wenzel, W. ; Wnek, J. ; Zhang,J.: The MONK’s Problems: A Performance Comparison of Different Learning Algo-rithms / Computer Science Department. Pittsburgh, PA, 1991 (CMU-CS-91-197).– Forschungsbericht

[TCCDL] Tennessee, Univ. of ; California, Berkeley Univ. o. ; Colorado Denver, Univ.of ; Ltd., NAG: LAPACK/BLAS homepage. http://www.netlib.org/lapack/,Abruf: 2014.02.09

[TKMS03] Toutanova, Kristina ; Klein, Dan ; Manning, Christopher D. ; Singer, Yoram:Feature-Rich Part-of-Speech Tagging with a Cyclic Dependency Network. In: INPROCEEDINGS OF HLT-NAACL, 2003, S. 252–259

http://dx.doi.org/10.1109/IJCNN.1990.137819

http://dx.doi.org/10.1109/IJCNN.1990.137819

http://hudson-ci.org/

http://dl.acm.org/citation.cfm?id=65669.104449

http://dblp.uni-trier.de/db/journals/fgcs/fgcs14.html#RogersS98

http://www.netlib.org/lapack/


[VLBM08] Vincent, Pascal ; Larochelle, Hugo ; Bengio, Yoshua ; Manzagol, Pierre-Antoine: Extracting and Composing Robust Features with Denoising Autoencoders.In: Proceedings of the 25th International Conference on Machine Learning. NewYork, NY, USA : ACM, 2008 (ICML ’08). – ISBN 978–1–60558–205–4, 1096–1103

[Whi11] White, Tom: Hadoop: The Definitive Guide (2nd Edition). O’Reilly, 2011

[Wika] Wikipedia: Amdahl’s law. http://en.wikipedia.org/wiki/Amdahl%27s_law, Ab-ruf: 2014.02.09

[Wikb] Wikipedia: Boolesche Funktion. http://de.wikipedia.org/wiki/Boolesche_

Funktion, Abruf: 2014.02.09

[Wikc] Wikipedia: Fehlerrechnung. http://de.wikipedia.org/wiki/Fehlerrechnung, Ab-ruf: 2014.02.09

[Wikd] Wikipedia: Speedup. http://en.wikipedia.org/wiki/Speedup, Abruf: 2014.02.09

[Xin] Xing AG: Xing. http://www.xing.com/, Abruf: 2014.02.09

[Zei12] Zeiler, Matthew D.: ADADELTA: An Adaptive Learning Rate Method. In: CoRRabs/1212.5701 (2012)

http://en.wikipedia.org/wiki/Amdahl%27s_law

http://de.wikipedia.org/wiki/Boolesche_Funktion

http://de.wikipedia.org/wiki/Boolesche_Funktion

http://de.wikipedia.org/wiki/Fehlerrechnung

http://en.wikipedia.org/wiki/Speedup

http://www.xing.com/

Anhang L

Eigenständigkeitserklärung

Hiermit versichere ich, dass ich die vorliegende Masterarbeit

Large Scale Multilayer Perceptron

selbstständig und nur unter Verwendung der angegebenen Quellen und Hilfsmittel verfassthabe. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungsbehördevorgelegt.

Berlin, 10. Februar 2014

Large Scale Multilayer Perceptron

Documents

Transcript of Large Scale Multilayer Perceptron