parallelisierung von data mining - algorithmen · sequentielle data mining-verfahren schon lange...
TRANSCRIPT
Fakultat fur Elektrotechnik und InformatikInstitut fur Praktische Informatik
Fachgebiet Datenbanken und Informationssysteme
Parallelisierung von Data Mining -Algorithmen
Masterarbeitim Studiengang Informatik
Oliver PabstMatrikelnummer: 2297090
Prufer: Prof. Dr. Udo LipeckZweitprufer: Dr. Hans Hermann Bruggemann
Betreuer: Prof. Dr. Udo Lipeck
13. Mai 2014
Zusammenfassung
In der heutigen Gesellschaft fallen in vielen Bereichen (Onlinehandel, Web-Mining furSuchmaschinen, soziale Netzwerke, etc.) immer großere Datenmengen an, in denen po-tentiell nutzliches Wissen enthalten sein kann. Diese bewegen sich in vielen Fallen bereitsim Bereich von Petabytes. Traditionelle sequentielle Algorithmen zur Assoziations- undClusteranalyse stoßen hier schon lange an ihre Grenzen, da eine effiziente Analyse deranfallenden Daten mit diesen Verfahren nicht moglich ist. Um diesem Problem beizukom-men ist eine Parallelisierung der Problemlosung unumganglich, wenn keine grundsatzlicheffizienten Algorithmen bekannt sind.
Im ersten Teil dieser Arbeit wird eine Auswahl paralleler Data Mining-Algorithmen vor-gestellt, die aus dem Bereich der Assoziations- und Clusteranalyse stammen. Grundlagefur diese Verfahren sind Parallelrechnerarchitekturen mit gemeinsam-globalem Speicheroder Kommunikation uber Nachrichten fur Informationsaustausch sowie das relativ neueMapReduce-Paradigma.
Der zweite Teil der Arbeit beginnt zunachst mit der Vorstellung der Implementierungvon vier parallelen Algorithmen, jeweils zwei aus dem Bereich der Assoziations- undClusteranalyse. Der Fokus der Implementierungen und der nachfolgenden Versuche liegthierbei auf dem MapReduce-Paradigma. In den Versuchen soll die Tauglichkeit fur großeDatenmengen, soweit es im Rahmen dieser Arbeit und der vorhandenen Moglichkeitenmachbar ist, untersucht werden sowie der Einfluss der Steuerparameter auf die Algorith-men betrachtet werden.
Inhaltsverzeichnis
1 Einleitung 7
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Uberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 Grundlagen 9
2.1 Knowledge Discovery in Databases . . . . . . . . . . . . . . . . . . . . . 9
2.2 Assoziationsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Der Apriori-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.2 Frequent Pattern Growth . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Clusteranalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1 Hierarchisches Clustering . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.2 Partitionierendes Clustering . . . . . . . . . . . . . . . . . . . . . 24
2.4 Die UNION-Find-Struktur . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.5 Parallelrechner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.6 MapReduce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6.1 Programmiermodell . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.6.2 Der Map-Reduce Prozess . . . . . . . . . . . . . . . . . . . . . . . 35
2.6.3 Hadoop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6.4 Ein- und Ausgabeformate . . . . . . . . . . . . . . . . . . . . . . 41
3 Parallele Algorithmen 43
3.1 Algorithmen zur Assoziationsanalyse . . . . . . . . . . . . . . . . . . . . 43
3.1.1 Partition-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.2 Laufzeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5
3.1.3 MapReduce-Partition . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.1.4 MapReduce Frequent-Pattern-Growth (PFP) . . . . . . . . . . . . 50
3.1.5 Weitere Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2 Algorithmen zur Clusteranalyse . . . . . . . . . . . . . . . . . . . . . . . 56
3.2.1 Parallel Partially Overlapping Partitioning (pPOP) . . . . . . . . 56
3.2.2 Parallel Disjoint-Set DBSCAN (PDSDBSCAN) . . . . . . . . . . 60
3.2.3 MapReduce-DBSCAN . . . . . . . . . . . . . . . . . . . . . . . . 65
3.2.4 Shared-memory SLINK (SHRINK) . . . . . . . . . . . . . . . . . 79
3.2.5 MapReduce k-Means Clustering . . . . . . . . . . . . . . . . . . . 85
3.2.6 Weitere Algorithmen . . . . . . . . . . . . . . . . . . . . . . . . . 88
4 Implementierung 90
4.1 MapReduce-Partition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2 MapReduce-DBSCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.2.1 MapReduce-kMeans und Parallel FP-Growth . . . . . . . . . . . . 97
5 Versuche 99
5.1 Assoziationsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5.1.1 Experimentelle Untersuchung der Korrektheit des Parallel FP-Growth-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . 101
5.1.2 Untersuchung der Performance des Partition-Algorithmus . . . . . 104
5.1.3 Untersuchung der Performance des Parallel FP-Growth-Algorithmus105
5.1.4 Performancevergleich zwischen MR-Partitition und PFP-Growth . 108
5.2 Clusteranalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
5.2.1 Auswirkungen der Blockgroße und Knotenanzahl auf die Laufzeitam Beispiel des MR-kMeans-Algorithmus . . . . . . . . . . . . . . 110
5.2.2 Einfluss der Parameterwahl und Knotenzahl auf den MR-DBSCAN-Algorithmus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.2.3 MapReduce-kMeans und MapReduce-DBSCAN im Vergleich . . . 117
6 Fazit 121
6
Kapitel 1
Einleitung
1.1 Motivation
Das Erfassen von Daten in den verschiedensten Lebensbereichen und Umfeldern fin-det in der heutigen Zeit in immer großer werdenden Ausmaß statt. Um aus diesen ge-sammelten Daten potentiell nutzliche Informationen zu extrahieren reichen traditionellesequentielle Data Mining-Verfahren schon lange nicht mehr aus, da beispielsweise inhoch-frequentierten Bereichen des Internets, etwa Suchmaschinen oder Onlinehandel,Datenmengen anfallen, die bereits den Petabyte-Bereich erreicht haben.
Um diese Datenmengen effizient analyisieren zu konnen wurden, im Wesentlichen imvergangenen Jahrzehnt, parallele Data Mining-Verfahren entwickelt. Diese basieren zumGroßteil auf Parallelrechner-Architekturen, die als Grundlage einen gemeinsamen globa-len Speicher oder Nachrichten fur den Informationsaustausch verwenden. In den letztenJahren ist im verstarkten Ausmaß das MapReduce-Paradigma als Grundlage neuer Ver-fahren hervorgetreten. Dieses bezeichnet sowohl ein Programmiermodell, nach dem An-wendungen entwickelt werden, als auch eine Software-Infrastruktur fur massiv-paralleleBerechnungen in großen verteilten Systemen.
In dieser Arbeit wird die Parallelisierung von Data Mining betrachtet. Zuerst wird ei-ne Auswahl verschiedener Algorithmen aus den Bereichen der Assoziations- und Clu-steranalyse vorgestellt, welche auf verschiedenen Parallelisierungs-Paradigmen basieren.Anhand dieser werden verschiedene Ansatze vorgestellt, mit denen eine Parallelisierung,zum Teil bekannter sequentieller Algorithmen, erreicht wird. Mit einer experimentellenUntersuchung wird fur eine Auswahl von Algorithmen analysiert, ob sich diese fur dieParallelisierung und somit Verarbeitung großer Datenmengen eignen. Der Fokus fur dieVersuche liegt hier auf dem MapReduce-Paradigma.
7
1.2 Uberblick
In Kapitel 2 werden zunachst die relevanten Grundlagen der Arbeit vorgestellt. Es sollein Uberblick geliefert werden, wie die Entdeckung von Wissen aus Daten funktioniert.Daran anschließend werden die fur diese Arbeit relevanten Teilbereiche, die Assoziations-und Clusteranalyse mit den bekanntesten Verfahren vorgestellt. Weiterhin werden diefur die nachfolgenden Kapitel relevanten Themen Parallelrechner sowie MapReduce pra-sentiert. Außerdem wird mit der Union-Find-Struktur eine Datenstruktur vorgestellt,die von einigen der vorgestellten parallelen Algorithmen verwendet wird.
Eine Auswahl paralleler Data Mining-Algorithmen wird in Kapitel 3 vorgestellt. Es wer-den Algorithmen aus den Bereichen Assoziations- und Clusteranalyse vorgestellt, diezum einen auf verschiedenen Parallelisierungsparadigmen, wie etwa MapReduce oderShared-Memory, basieren. Zum anderen basieren diese auf vielfaltigen Ansatzen, umzum Teil populare sequentielle Algorithmen zu parallelisieren.
Kapitel 4 prasentiert die Implementierungen der Algorithmen, die im Rahmen dieser Ar-beit fur Versuche auf Grundlage von Hadoop entwickelt worden sind. Bei diesen handeltes sich um den MapReduce-Partition- sowie den MapReduce-DBSCAN-Algorithmus,welche in Kapitel 3 vorgestellt werden. Außerdem werden oberflachlich die Implementie-rungen der beiden anderen untersuchten Algorithmen, MapReduce-kMeans und ParallelFP-Growth, analysiert, die ebenfalls fur die Versuche verwendet werden; diese stammenaus dem Mahout-Projekt der Apache Software Foundation, welches skalierbare Algorith-men fur maschinelles Lernen bereitstellt.
Die Tauglichkeit der MapReduce-Implementierungen wird in Kapitel 5 betrachtet. Hier-bei steht unter anderen die Skalierbarkeit der Verfahren im Vordergrund und ob diese mitverhaltnismaßig großen Datenmengen umgehen konnen. Weiterhin wird untersucht, wiesich die Laufzeit der Algorithmen bei Variation der Steuerparameter verhalt sowie jeweilsein Vergleich der Algorithmen aus dem jeweiligen Gebiet der Versuche vorgenommen.
In Kapitel 6 werden abschließend die wichtigsten Punkte der Arbeit zusammengefasst.Zusatzlich wird ein abschließendes Fazit gezogen.
8
Kapitel 2
Grundlagen
In diesem Kapitel werden die beiden Bestandteile des Prozesses der Knowledge Discove-ry in Datenbanken vorgestellt, die in dieser Arbeit betrachtet werden. Hierbei handeltes sich um die Data Mining-Techniken der Assoziationsanalyse sowie der Clusterana-lyse. Der Fokus liegt auf diesen beiden Verfahren, da diese es ermoglichen, Muster inunbekannten Daten zu erkennen. Diese sind die Grundlage um Regeln zu entwickeln,mit denen Verfahren wie die Klassifikation oder die Generalisierung angewendet wer-den. Fur diese beiden Analysearten werden grundlegende sequentielle Algorithmen pra-sentiert. Zusatzlich wird die weniger bekannte Union-Find-Struktur erlautert, die imspateren Verlauf in einigen Implementierungen paralleler Clusteringverfahren zum Ein-satz kommt, sowie das MapReduce-Paradigma, welches fur einige Implementierungenparalleler Algorithmen, die in dieser Arbeit vorgestellt werden, verwendet wird.
2.1 Knowledge Discovery in Databases
Ester und Sander definieren den Begriff der Knowledge Discovery in Databases (KDD)[ES00] als einen Prozess, der, automatisch oder semi-automatisch, Wissen aus Daten-banken gewinnt. Dieses muss jedoch im statistischen Sinne gultig sein, darf bisher nichtbekannt sein und soll nach Moglichkeit Nutzen bringen. Der iterative Prozess, der in Ab-bildung 2.1 dargestellt ist, besteht aus funf Schritten, die im Folgenden kurz vorgestelltwerden.
Fokussierung
Das Ziel der Fokussierung ist es, zunachst ein Verstandnis uber die Anwendung zu ge-winnen und in Erfahrung zu bringen, welches Anwendungswissen bereits vorhanden ist.
9
Gesamter Datenbestand
Relevanter Datenbestand
Vorverarbeitete Daten
Transformierte Daten
Erkannte MusterEntdecktes
Wissen
Fokussieren Vorverarbeitung
Transformation
Data Mining Evaluation
Abbildung 2.1: Der KDD-Prozess
Hieraus wird das zu erreichende Ziel des KDD-Prozesses abgeleitet, insbesondere un-ter dem Gesichtspunkt, dass das neu generierte Wissen der Anwendung Nutzen bringenmuss und nicht bereits bekannt sein darf. Weiterhin gilt es festzulegen, welche Quel-len herangezogen werden sollen fur die Suche und wie diese verfugbar gemacht werdenkonnen. Ein weiterer wichtiger Punkt ist, in welcher Form die zu verwendenden Datenvorgehalten werden sollen. In vielen Fallen geschieht dies mit Hilfe eines Datenbank-systems, da dies beispielsweise im nachsten Schritt, der Vorverarbeitung, eine einfacheSelektion der gewunschten Daten aus dem fur die Anwendung relevanten Datenbestanderlaubt.
Vorverarbeitung
Im zweiten Schritt, der Vorverarbeitung, geht es um die Integration der fur relevanterachteten Werte, welche gegebenenfalls in eine konsistente Form zu bringen und zuvervollstandigen sind. Fur Daten aus unterschiedlichen Quellen gilt, dass fur diese bei-spielsweise verschiedene Einheiten (z.B. angloamerikanisches Maßsystem ↔ metrischesMaßsystem) oder verschiedene Namen fur dasselbe Objektattribut verwendet wurden.Zusatzlich konnen Inkonsistenzen durch Schreibfehler auftreten oder fehlerhafte Mes-sungen zu Rauschen fuhren, also zu einem Zufallsmuster, das wiederum die tatsachlichvorhandenen Muster uberlagern kann.
Transformation
Die vorverarbeiteten Daten sind zunachst in eine Form zu bringen, die fur die zur Anwen-dung kommenden Data Mining-Verfahren geeignet sind. In den meisten Fallen bedeutetdies, dass nur ausgewahlte Attribute der vorverarbeiten Daten verwendet werden (Selek-tion), die fur die Aufgabe relevant sind, oder dass Attributwertbereiche reduziert werden
10
(Diskretisierung), etwa die Reduktion eines Attributs ”Alter” von einem numerischenWert auf einen kategorischen Wert (Kind|Erwachsener).
Data Mining
Der vierte Schritt ist die Anwendung von effizienten Algorithmen auf die vorverarbeite-ten Daten, um gultige Muster in dem Datenbestand zu finden. Hierfur ist es zunachstnotwendig, die Aufgaben zu identifizieren, die im Data Mining-Schritt zu bewaltigen ist.Die wichtigsten Aufgaben sind:
• Clusteranalyse: Die Aufgabe der Clusteranalyse ist die Gruppierung der Daten-bankobjekte in Gruppen (Cluster), so dass Objekte desselben Clusters in ihrenAttributen moglichst ahnlich, Objekte verschiedener Objekte jedoch moglichst un-ahnlich sind. Aufgrund der Bedeutung im Rahmen dieser Arbeit wird die Cluster-analyse in Abschnitt 2.3 auf Seite 22 ausfuhrlicher beschrieben.
• Klassifikation: Gegeben ist eine Menge von Trainingsobjekten mit Attributwerten,fur die eine Klassenzuordnung vorhanden ist. Ziel ist das Anlernen einer Funkti-on z.B. basierend auf Entscheidungsbaumen oder Regeln, die eine Klassifikationzukunftiger Objekte anhand ihrer Attributauspragungen durchfuhrt.
• Assoziationsanalyse: Aus einer gegebenen Datenbank mit Transaktionen (Item-sets) sollen Regeln der Form
”IF A AND B THEN C “gefunden werden, die
haufig auftretende und starke Zusammenhange unter den vorkommenden Itemsbeschreiben. Da diese Data Mining-Aufgabe, ebenso wie die Clusteranalyse, furdiese Arbeit von zentraler Bedeutung ist, erfolgt eine tiefergehende Beschreibungder Assoziationsanalyse in Abschnitt 2.2 auf Seite 12.
• Generalisierung : Das Ziel ist das Erreichen einer moglichst kompakten Beschrei-bung einer Datenmenge, indem Attributwerte generalisiert und die Anzahl vonDatensatzen reduziert wird.
Sobald die Aufgabe identifiziert ist kann basierend auf den Anwendungszielen und derBeschaffenheit der Daten ein angemessener Algorithmus ausgewahlt und ausgefuhrt wer-den.
Evaluation
Zum Abschluss des KDD-Prozesses werden vom ausfuhrenden System die Ergebnisse,in diesem Fall gefundene Muster, einem Experten der Anwendungsdomane in geeigneterWeise dargestellt. Dieser entscheidet daruber, ob die gesetzten Ziele erreicht worden sind,
11
oder ob eine zusatzliche Iteration des KDD-Prozesses durchzufuhren ist. Hierbei ist fest-zuhalten, dass in einem weiteren Iterationsschritt nicht der vollstandige Prozess abermalsauszufuhren ist; es kann auch beispielsweise nur das Data Mining mit einer verandertenParameterwahl ausgefuhrt werden, wenn die zugrunde liegenden vorverarbeiteten Datenvon ausreichender Qualitat sind. Damit auch zukunftige Prozesse neues Wissen generie-ren, ist es notwendig, gefundenes Wissen in das bestehende System einzupflegen, damiteine wiederholte Durchfuhrung des KDD-Prozesses auch weiterhin unbekanntes Wissenliefert.
2.2 Assoziationsanalyse
Assoziationsregeln, die aus Verfahren der Assoziationsanalyse gewonnen werden, werdenauch als Warenkorbanalyse bezeichnet. Warenkorbe sind hier analog zu Kundeneinkau-fen zu betrachten. Ein Warenkorb ist hierbei zusammengesetzt aus Objekten (Items),die zusammen gekauft werden, unabhangig davon ob es sich um materielle (Artikel imSupermarkt) oder immaterielle (Dienstleistungen, Informationen) Objekte handelt. Einanschauliches Beispiel fur eine Datenbank von Transaktionen ist die Datensammlung,die sich aus den Scanvorgangen an den Kassen eines Supermarkts ergibt. Eine Trans-aktion besteht in diesem Fall aus Informationen zu allen Artikeln (z.B. Barcodes), dieein Kunde zu einem Zeitpunkt gekauft hat. Die Grundlage fur eine tiefer gehende Ana-lyse von Transaktionsdatenbanken ist das Bestimmen von Objektmengen, so genanntenItemsets, die haufig in dieser Datenbank auftreten frequent Itemsets, wobei die Itemsetsauch als k-Itemsets bezeichnet werden; k bezeichnet hier die Anzahl der Elemente desItemsets.
Hierfur wird zunachst der Support s(X) fur ein Itemset X berechnet, welcher denAnteil von Transaktionen darstellt, die X enthalten. Von einem haufigen Itemset Xspricht man nun, wenn der Support s(X) großer gleich einem festgelegten SchwellenwertminimumSupport ist, also s(X) ≥ minimumSupport. Fur ein Itemset
{Chips,Brezeln,Bier}
ware der Support beispielsweise
s({Chips,Brezeln,Bier}) =|{Chips,Brezeln,Bier}||Transaktionsdatenbank|
,
also in wie vielen Transaktionen der Datenbank das Itemset vorhanden ist.
Auf Grundlage der haufigen Itemsets konnen Assoziationsregeln gesucht werden, welcheZusammenhange in den Transaktionen darstellen. Ein Beispiel hierfur ware die Regels({Chips,Brezeln⇒ Bier}), welche besagt, dass das Vorhandensein von Chips und Bre-zeln in einem Warenkorb auf das gleichzeitige Vorhandensein von Bier schließen lasst.
12
Es ist jedoch wichtig, auch die Qualitat der Regeln zu bewerten. Ein Kriterium dafurist die Konfidenz. Diese bezeichnet die relative Haufigkeit, in der die Regel korrekt ist,und bedeutet im Falle der Regel {Chips,Brezeln ⇒ Bier}, in wie vielen Regeln, die{Chips,Brezeln} enthalten, zusatzlich auch {Bier} enthalten ist (Gleichung 2.1).
confidence({Chips,Brezeln⇒ Bier}) =s{Chips,Brezeln,Bier}
s{Chips,Brezeln}(2.1)
Ein weiteres Kriterium ist der Lift, mit dessen Hilfe sich berechnen lasst, ob und wie weitdie Konfidenz fur eine Regel den Erwartungswert ubertrifft (Gleichung 2.2); der Lift istfolglich ein Indikator fur die generelle Bedeutung einer Regel.
lift({Chips,Brezeln⇒ Bier}) =s({Chips,Brezeln} ∪ {Bier})
s({Chips,Brezeln}) · s({Bier})(2.2)
Der Fokus ist hinsichtlich großer Datenmengen auf den Aufgabenbereich der Bestimmunghaufiger Itemsets (Frequent-Itemset-Mining) gerichtet, da fur diese Aufgabe zunachstalle moglichen Itemsets, die sich aus dem Datenbestand ergeben, zu bestimmen sind.Sei nun I die Menge aller Items, die in einer Transaktionsdatenbank mindestens einmalauftreten. Dann ist die Menge aller moglichen Itemsets die Potenzmenge von I ohne dieleere Menge und somit |I| = 2n − 1.
Deshalb betrachtet diese Arbeit nur das Frequent-Itemset-Mining, fur welches im Fol-genden die beiden bekannten Algorithmen Apriori und FP-Growth vorgestellt werden.
2.2.1 Der Apriori-Algorithmus
Der Apriori-Algorithmus [AS94] ist ein Verfahren der Assoziationsanalyse, um haufige,bzw. interessante Itemsets aus Transaktionsdatenbanken zu berechnen. Die Grundlagedieses Algorithmus ist das Apriori-Prinzip, welches besagt, dass wenn ein Itemset haufigist, so sind auch dessen Teilmengen haufig. Zusatzlich gilt fur haufige Itemsets eine Anti-Monotonie (Gleichung 2.3), aus welcher gefolgert werden kann, dass der Support einesItemsets nicht großer sein kann als der großte Support der Teilmengen.
∀X, Y : (X ⊆ Y ) =⇒ s(X) ≥ s(Y ) (2.3)
Der Apriori-Algorithmus 2.1 zahlt in der ersten Iteration zunachst alle haufigen 1-Itemsets durch einen Scan der Transaktionsdatenbank. Die nachfolgenden Iterationen(Zeile 2-8) bestehen jeweils aus zwei Phasen. In der ersten wird aus den im vorherigenDurchlauf berechneten haufigen (k−1)-Itemsets mit dem Apriori-Gen-Algorithmus 2.2
13
die Kandidatenmenge der haufigen k-Itemsets berechnet (Zeile 5). In der zweiten Pha-se (Zeile 5-8) wird der Support fur die Kandidaten in Ck gezahlt. Itemsets der Lange kmit einem Support großer gleich dem minimalen Support minSup werden zum Abschlussder Menge der haufigen k-Itemsets hinzugefugt (Zeile 9). Am Ende gibt der Algorithmusschließlich die Vereinigung aller haufigen Itemsets zuruck (Zeile 10).
Algorithmus 2.1 Apriori-Algorithmus ([AS94] angepasst)
input: T - list of transactionsinput: minSup - minimal support required for frequent itemsetsoutput: set of found frequent itemsets
1: procedure Apriori(T , minSup)2: L1 = {frequent 1-itemsets};3: for (k = 2;Lk−1 6= ∅; k + +) do4: Ck = Apriori-Gen(Lk−1);5: for all transactions t ∈ T do6: // calculate itemsets contained in transaction t7: Ct = Subset(Ck, t);8: for all candidates c ∈ Ct do9: c.count++;
10: Lk = {c ∈ Ck|c.count ≥ minSup}11: return
⋃k Lk
Der Algorithmus zur Erzeugung neuer, großerer Itemsets (Algorithmus 2.2) benutzt dieMenge Lk−1, die Menge aller haufigen (k−1)-Itemsets und konstruiert daraus eine Ober-menge von Itemsets der Lange k. In den Zeilen 2 bis 5 werden diese erzeugt, indemzunachst zwei haufige (k−1)-Itemsets p und q gewahlt werden, die auf den Position1, . . . , k−2 identisch sind und sich in der k−1-ten Position unterscheiden, das (k−1)-teElement von p jedoch kleiner als das von q ist. Die Positionen 1, . . . , k−2 werden nunmit den zwischen p und q gleichen Elementen besetzt, die (k−1)-te Position mit dem(k−1)-ten Element aus p und das k-te Element mit dem aus q.
Im Anschluss an die Erzeugung der Itemsets ist abschließend die Apriori-Eigenschaftzu prufen, also ob die Kandidaten haufige (k-1)-Itemsets enthalten. Dadurch lasst sichbereits die Menge der Itemsets, deren Support zu berechnen ist, reduzieren. Hierfurwerden alle Kandidaten durchlaufen (Zeile 7), von denen wiederum alle (k-1)-Teilmengendurchlaufen werden. Wenn nun eine dieser Teilmengen nicht haufig ist, also nicht in Lk−1enthalten ist, so folgt aus der Apriori-Eigenschaft, dass das k-Itemset nicht haufig seinkann.
14
Algorithmus 2.2 Apriori-Gen - Erzeugung neuer Itemsets ([AS94] angepasst)
input: Lk−1 - frequent itemsets of length k−1output: Ck - frequent itemsets of length k
1: procedure Apriori-Gen(Lk−1)2: // generating new itemsets3: insert into Ck4: select p.item1, p.item2, . . . , p.itemk−1, q.itemk−15: from Lk−1 p, Lk−1 q6: where p.item1 = q.item1, . . . , p.itemk−1 = q.itemk2 , p.itemk−1 < q.itemk−1;7: // prune candidates containing (k − 1)-subsets that are not in Lk−18: for all itemsets c ∈ Ck do9: for all (k−1)-subsets s of c do
10: if (s /∈ Lk−1) then11: delete c from Ck12: return Ck
Laufzeit
Fur den ersten Schritt, die Bestimmung der frequent 1-Itemsets, ist eine Laufzeit vonO(|T | ·w) erforderlich, wobei w die durchschnittliche Transaktionslange ist. Fur die Er-zeugung von Kandidaten werden Itemsets der Lange k−1 paarweise verglichen, wobeihierfur maximal k−2 Vergleiche pro Paar benotigt werden. Maximal mussen hier al-le gefundenen Itemsets der vorherigen Iteration betrachtet werden, so dass hier fur dieLaufzeit maximal O(
∑wk=2(k − 2) · |Lk−1|2) betragt. Fur das Pruning ist fur jeden gene-
rierten Kandidaten zu prufen, ob alle (k−1) Teilmengen ebenfalls haufig sind, so dasssich eine Laufzeit von O(
∑wk=2 k · (k−1) · |Ck|) ergibt. Bei der Zahlung des Supportes
ergeben sich fur jede Transaktion mit Lange |t|(|t|k
)Itemsets. Insgesamt ist die Lauf-
zeit fur die Supportzahlung O(|T | ·∑
k ·(wk
)αk), wobei αk die Kosten zur Aktualisierung
eines Itemset-Kandidaten sind. Fur einen sehr niedrigen Support ergibt sich insgesamtaufgrund der Anzahl potentieller Itemsets eine exponentielle Laufzeit.
Nachteile
Bei einem niedrig angesetzten minimalen Support-Schwellwert kann es beim Apriori-Algorithmus passieren, dass es eine Vielzahl haufiger und langer Itemsets geben kann.Dies fuhrt dazu, dass der Apriori-Algorithmus sehr teuer hinsichtlich des Speicherbedarfswird, da eine große Anzahl von Kandidaten-Itemsets zu handhaben ist.
Beispielsweise fuhrt eine Menge von 104 haufigen 1-Itemsets bereits zu mehr als 107 2-Itemset-Kandidaten (
(10000
2
)= 4, 9995 · 107). Zusatzlich ist fur diese Kandidatenmenge
auch der Support zu bestimmen. Ein weiterer Punkt ist, dass fur die Entdeckung ei-
15
nes haufigen Itemsets {a1, . . . , a100} der Lange 100 der Erzeugung von 2100 − 1 ≈ 1030
Kandidaten notwendig ist, was in Folge der Kandidatengenerierung nicht zu vermeidenist.
2.2.2 Frequent Pattern Growth
Der Frequent-Pattern-Growth(FP-Growth)-Algorithmus [HPY00] versucht die Nachteiledes Apriori-Algorithmus zu umgehen, in dem die Transaktionsdatenbank in Form einerBaum-Struktur dargestellt wird, aus welcher die haufigen Itemsets gewonnen werdenkonnen. Der Ansatz, eine Baum-Struktur zur Kodierung der Transaktionen zu verwen-den, ermoglicht, dass die Menge der haufigen Itemsets berechnet werden kann, ohnedass, wie im Apriori-Algorithmus, iterativ Kandidatenmengen berechnet und bewertetwerden mussen. Dieses wird durch drei verschiedene Ansatze erreicht.
Erstens wird eine erweiterte Prafix-Baum-Struktur und quantitative Informationen derItemsets in der Baum-Struktur gespeichert. Zusatzlich werden in einem FP-Baum nurKnoten gespeichert, die in der Menge der haufigen 1-Itemsets vorkommen. Schließlichwerden die Knoten des Baumes so angeordnet, dass haufig vorkommende Items einegroßere Chance haben, sich Knoten mit anderen Pfaden zu teilen.
Der zweite Ansatz ist eine Methode zur Erzeugung wachsender Itemsets aus einem FP-Baum, die mit haufigen 1-Itemsets beginnt (Ausgangs Suffix-Itemset) und im weiterenVerlauf nur eine bedingte Itemset-Basis betrachtet, d.h. die Teildatenbank der Menge vonhaufigen Itemsets, die zusammen mit dem Suffix-Pattern auftreten. Basierend auf demSuffix-Itemset und der daraus resultierenden bedingten Itemset-Basis wird ein bedingterFP-Baum erzeugt, auf welchem die Itemset-Erzeugung rekursiv aufgefuhrt wird. DasWachstum der Itemsets geschieht durch das Aneinanderhangen der Suffix-Patterns mitneuen Suffix-Patterns aus dem bedingten FP-Baum. Die Vollstandigkeit dieser Methodedes Pattern-Wachstums wird garantiert, da haufige Itemsets einer Transaktion immer ineinem zugehorigen Pfad des FP-Baums codiert ist.
Als drittes wird als Suchtechnik zur Generierung haufiger Itemsets ein Divide-and-Conquer-Ansatz verwendet. Dieser reduziert die Große der bedingten Itemset-Basis, dadas Problem des Findens langer, haufiger Itemsets in die Suche nach kurzen Itemsetsund das Aneinanderhangen von Suffixen umgewandelt wird.
Frequent-Pattern Baum
Ein Frequent-Pattern-Baum (Abbildung 2.2) ist eine Baumstruktur, die als Wurzel einenals
”null“ bezeichneten Knoten besitzt, der als Attribut die Anzahl der im Baum gespei-
cherten Transaktionen festhalt. An der Wurzel wird eine Menge von Prafix-Teilbaumen
16
der Elemente eingehangt. Die Struktur verfugt zusatzlich uber eine Header-Tabelle, inder die im Baum enthaltenen Items sowie Zeiger zum ersten Vorkommen des Items imBaum enthalten sind.
null:5
A:2 B:2
C:1 D:1
F:1 E:1
D:1
F:1
C:1
F:1
ItemABCDEF
Header
Abbildung 2.2: Beispiel eines Frequent-Pattern Baums
Jeder Knoten besitzt drei Attribute: das erste ist der Knotenname, der das Item angibt,welches der Knoten reprasentiert. Das zweite ist die Anzahl der Transaktionen, die durchden Teilpfad, in dem der Knoten liegt, bis zu diesem Knoten reprasentiert werden. Dasdritte Element schließlich ist ein Zeiger, der auf den nachsten Knoten im Baum mitdemselben Namen zeigt. Die Header-Tabelle schließlich besitzt zwei Spalten; in der erstenSpalte steht der Name des Items, die zweite enthalt einen Zeiger zum ersten Vorkommendes Elements im Baum. Dieses Konstrukt ermoglicht ausgehend von der Header-Tabelledas einfache Finden jedes Vorkommens eines Items in einem FP-Baum durch Verfolgenvon Zeigern.
Algorithmus 2.3 Aufbau eines FP-Baums (basierend auf [HPY00] erarbeitet)
input: tdb - database of transactions, ξ: minimum support thresholdoutput: T - a fp-tree
1: procedure ConstructFpTree(tdb, ξ)2: define list F[] . list of frequent 1-itemsets3: for each transaction t in tdb do4: for each item ai in t do5: F [ai] + +
6: sort F in descending order relating to item count7: create root of FP-Tree T , labeled as
”null“
8: for each transaction t ∈ tdb do9: order and filter frequent items in t according to F into f
10: InsertTree(f, T )
11: return T
Um den FP-Baum aufbauen zu konnen (Algorithmus 2.3), wird zunachst ein Scan der
17
Transaktionsdatenbank durchgefuhrt und eine Liste der haufigen Itemsets erstellt, welcheabsteigend nach der Vorkommenshaufigkeit sortiert wird. Anschließend wird die Trans-aktionsdatenbank nochmals vollstandig durchlaufen. Jede Transaktion wird nun hin-sichtlich der Liste der haufigen Itemsets sortiert und gefiltert, so dass die Transaktionnur noch haufige Items enthalt und diese nach der Haufigkeit des Vorkommens sortiertist; diese wird mit der Funktion InsertTree in den Baum eingefugt.
Das Einfugen eines Itemsets in den FP-Baum (InsertTree, Algorithmus 2.4) beginntan der Wurzel des Baumes T . Hier wird uberpruft, ob T einen Kindknoten n mit demNamen des ersten Items e aus t hat (Zeile 2). Wenn dies der Fall ist, wird im Kindknotenn der Zahler fur das Element um eins inkrementiert.
Algorithmus 2.4 Einfugen eines Itemsets in einen FP-Baum (basierend auf [HPY00]erarbeitet)
input: t - itemset, T - a fp-tree1: procedure InsertTree(t, T )2: let e be the first item of t3: if T.hasChild(n)and n.itemName == e.itemName then4: increase n’s item count by 15: else6: create new node n with name e and count 17: set n’s parent to T8: set n’s node link to nodes with same item name using the node link structure
9: remove item e from the itemset t10: if t is not empty then11: InsertTree(t, n)
Falls T jedoch kein Kindknoten mit dem Namen e besitzt, so wird ein neuer Knotenn mit einen Itemzahlwert von 1 und T als Vorganger erzeugt. Zusatzlich wird n in dienode link Struktur des Baumes eingebunden. Im Anschluss an beide Falle wird das Iteme aus t entfernt und erneut die Funktion InsertTree aufgerufen mit den verbliebenenRest von t sowie n als Wurzel, sofern t nicht leer ist.
Ein Beispiel fur den Aufbau eines FP-Baumes ist in Abbildung 2.3 zu sehen; eingefugtwird in diesen die Transaktionsmenge {T1 = {A,B}, T2 = {A,C}, T3 = {B,C}}.
Zu Beginn des Einfugevorgangs besteht der Baum nur aus der Wurzel”null:0“. Wenn nun
also T1 eingefugt wird, muss ein neuer Knoten”A“ mit einem Zahler von 1 als Kind von
der Wurzel erzeugt werden. Zusatzlich wird ein Zeiger in der Header-Tabelle angelegt,der auf
”A“ zeigt. Das Einfugen von
”B“ beginnt mit Knoten
”A“ als Startknoten. Da
auch hier kein entsprechendes Kind vorhanden ist, wird analog zum ersten Item ein neuerKnoten
”B“ mit einem Zahlerwert von 1 angelegt und ein Zeiger von der Header-Tabelle
auf den Knoten erzeugt. Das Einfugen von T2 beginnt analog zu T1, jedoch ist unterhalbder Wurzel von T bereits ein Kindknoten mit dem Namen
”A“ vorhanden, so dass von
18
null:1
A:1
B:1
null:3
C:1
B:1A:2
B:1 C:1
null:2
A:2
B:1 C:1
Items
B
C
A
Header
Items
B
C
A
Header
Items
B
A
Header
Abbildung 2.3: Konstruktion eines FP-Baumes
diesem lediglich der Zahlerwert um eins inkrementiert wird. Um das Item”C“ unterhalb
von A einzufugen, ist jedoch wieder ein neuer Knoten”C“ mit einem Zahlerwert von
eins anzulegen und zusatzlich wird ein Link von der Header-Tabelle auf”C“ angelegt.
Das Einfugen von T3 erfolgt weitestgehend analog, jedoch mussen zusatzliche Zeiger vonden bereits vorhandenen Pfadenden der Headertabelle auf die neuen Knoten angelegtwerden.
Die Komplexitat fur das Einfugen eines Itemsets in einen FP-Baum betragt, grob ab-geschatzt, O(|t|), wobei t die Lange des Itemsets ist. Sei A nun die Menge aller in derTransaktionsdatenbank vorkommen Items mit der Anzahl ihrer Vorkommen. Dann be-tragt die Komplexitat fur den Aufbau eines FP-Baumes grob O((|tdb| ∗ |t|) + O(A ∗log(A)) + O(|tdb| ∗ (|t| + |f |)) unter der Annahme, dass A in O(n ∗ log(n)) sortiertwerden kann.
19
Erzeugung von haufigen Itemsets aus einem FP-Baum
Das Erzeugen von haufigen Itemsets aus einem FP-Baum (FPGrowth, Algorithmus2.5) lasst sich in zwei Falle unterteilen. Im ersten Fall (Zeile 2-6), wenn der bedingte FP-Baum T nur noch einen einzigen Pfad p enthalt, so werden die verbleibenden Knotenβ des Pfades p in allen moglichen Kombinationen mit dem bisherigen Itemset-Fragmentα kombiniert und erhalten als Support das Minimum aus β. Ausgegeben werden dieso erzeugten Itemsets, wenn der Support von β den minimalen Support ξ erreicht oderuberschreitet. Im anderen Fall (Zeile 7-14) ist nicht nur ein einzelner Pfad in T ver-bleibend, sondern ein ganzer Baum. Zunachst wird jedes im Baum vorhandene Item aimit dem bis hierher entstandenen Itemset-Fragment α zu einen Itemset β verbunden,welches den Support von ai erhalt und ausgegeben, wenn der Support des neuen Item-sets den minimalen notwendigen Support ξ erreicht. Hierfur werden alle Pfade von derWurzel T ’s ausgehend betrachtet, die mit dem Item ai enden. Die Items, aus denen diePfade bestehen, bilden die bedingte Itemset-Basis (conditional pattern base). Auf dieserGrundlage wird dann der bedingte FP-Baum (conditional frequent pattern tree) von Tβfur das Itemset-Frament β aufgebaut (ConstructFPTree, Algorithmus 2.3), der aufβ endende Transaktionen enthalt.
Algorithmus 2.5 Frequent-Pattern Growth ([HPY00] angepasst)
input: T - a fp treeinput: α - itemset fragmentinput: ξ - minimum supportoutput: β - itemsets
1: procedure FPGrowth(T , α, ξ)2: if T contains a single path p then3: for each combination β of nodes in path p do4: generate pattern β ∪ α with suppport = min{s(β)}5: if β.support > ξ then6: Output β
7: else8: for each ai in header-table of T do9: generate pattern β = ai ∪ α with sup = ai.sup
10: if β.sup > ξ then11: Output β
12: construct ai’s cond. pattern base and then β’s cond. FP-Tree Tβ13: if Tβ 6= ∅ then14: call FPGrowth(Tβ, β, ξ)
Eine Abschatzung der Laufzeit des Algorithmus nach unten ist nicht moglich. Diesesliegt an der Tatsache, dass sich in keinem Rekursionsschritt vorhersagen lasst, wie großdie Anzahl und Große der resultierenden Teilprobleme ist. Eine Abschatzung nach obenist jedoch moglich. Angenommen wird hierfur der Worst-Case, in welchem jede Trans-
20
aktion aus Items besteht, die in keiner anderen Transaktion auftreten. In diese Fall istder FP-Baum mindestens so groß wie die Transaktionsdatenbank. Fur die Suche nachfrequent Itemsets muss nun im schlimmsten Fall jeder Zweig des Baumes abgearbeitetwerden, so dass die Laufzeit fur eine Transaktionsdatenbank T mit einer durchschnittli-chen Transaktionslange maximal O(|T | · w) betragt.
Beispiel Ein einfaches Beispiel fur die Erzeugung von Itemsets aus einem FP-Baumist in Abbildung 2.4 zu sehen. In (1) ist zunachst der initiale FP-Baum dargestellt, inwelchem Itemsets gesucht werden sollen, die auf c enden. Der Teilbaum in (2) ist derresultierende Teilbaum, der lediglich Transaktionen enthalt, die auf c enden.
null:3
C:1
B:1A:2
B:1 C:1
null:3
C:1
B:1A:2
C:1
(1)
(2)
(3)
null:3
B:1
null:3
A:2
Abbildung 2.4: Beispiel fur die Generierung von Itemsets aus einem FP-Baum
In (3) sind schließlich die bedingten Baume zu sehen, die aus (2) fur jedes haufige Itemsetin T gebildet werden. Die Abarbeitung wird rekursiv fortgesetzt, so dass schlussendlichdie beiden Itemsets {AC} und {BC} als Ergebnis geliefert werden.
21
Nachteile
Der FP-Growth Algorithmus ist hinsichtlich seiner Fahigkeit, große Datenmengen ver-arbeiten, ebenso eingeschrankt wie der Apriori-Algorithmus. Zwar entfallt der Aufwandfur Erzeugung und Verwaltung der Itemset-Kandidaten, trotzdem konnen bei großenTransaktionsdatenbanken mit vielen Kandidaten die FP-Baume eine Große erreichen,die nicht mehr im Hauptspeicher handhabbar ist. Zusatzlich spielt der minimale Sup-port eine entscheidende Rolle. Je großer der minimale Support ist, desto kleiner fallendie FP-Baume und die Menge der gefundenen Itemsets aus. Fur die Warenkorbanalysemag dies ein gangbarer Weg sein, bei Internet-Suchmaschinen etwa konnen jedoch auchItemsets mit geringem Support von Interesse sein.
2.3 Clusteranalyse
Die Clusteranalyse wird mit dem Ziel durchgefuhrt, Daten automatisch bzw. semi-automatisch in Kategorien, Gruppen(Cluster) oder Klassen einzuordnen. Das Ziel isthierbei, dass Objekte, die sich in demselben Cluster befinden, hinsichtlich der betrach-teten Attribute moglichst ahnlich zueinander sind, Objekte aus verschiedenen Clusternjedoch moglichst unahnlich zueinander sind. Allerdings ist es zuvor notwendig, den Be-griff der Ahnlichkeit, der Aufgabenstellung entsprechend, geeignet zu modellieren. ImFalle numerischer Attributwerte kann fur die Berechnung der Ahnlichkeit beispielsweisedie euklidische Distanz (Gleichung 2.4) verwendet werden, wenn fur die Attributwerte xider Datensatze x = (x1, . . . , xd) Kategorien verwendet werden, so ergibt sich die Distanzaus der Anzahl der verschiedenen Komponenten zwischen unterschiedlichen Datensatzen(Gleichung 2.5).
dist(x, y) =√
(x1 − y1)2 + . . .+ (xn − yn)2 (2.4)
dist(x, y) =d∑i=1
δ(xi, yi) mit δ(xi, yi) =
{0,wenn(xi = yi)
1,wenn(xi 6= yi)(2.5)
Im Folgenden werden drei bekannte sequentielle Algorithmen fur die hierarchische undpartitionierende Clusteranalyse vorgestellt und hinsichtlich ihrer Eignung unter Beruck-sichtung aktueller Anforderungen betrachtet.
22
2.3.1 Hierarchisches Clustering
Im agglomerativen hierarchischen Clustering wird zunachst jeder Datenpunkt als einCluster aufgefasst. Anschließend werden diese Cluster Schritt fur Schritt vereinigt, bis amEnde ein einzelner Cluster ubrig bleibt (Algorithmus 2.6). Ein hierarchisches Clusteringwird oftmals durch ein Dendrogram dargestellt (Abbildung 2.5).
12
3
4 5
52 431
Abbildung 2.5: Hierarchisches Clustering - Beispiel
Die Vereinigung der Cluster erfolgt uber die Betrachtung der Distanz zwischen denClustern; in jeder Iteration werden die Cluster vereinigt, die die geringste Distanz, bzw.die großte Ahnlichkeit, zueinander besitzen.
Algorithmus 2.6 Naiver Algorithmus fur agglomeratives hierarchisches Clustering([TSK05] angepasst)
input: set of points Doutput: dendrogram d representing the clustering
1: procedure AgglomerativeHierarchical-Clustering(D: Set of points)2: compute proximity matrix P from point-set D3: initialize dendrogram d4: let each data point ∈ D be a cluster5: repeat6: merge closest pair of clusters7: adjust d to represent this merging8: update P to reflect changed proximity between new and old clusters9: until only one cluster left
10: return dendrogram d
Fur die Berechnung der Distanz bzw. der Ahnlichkeit zwischen den Clustern gibt esverschiedene Ansatze, unter anderem:
23
• Min: Verwendung der Distanz zwischen den nachsten Punkten zweier verschiede-ner Cluster (single link)
• Max: Verwendung der Distanz zwischen den am weitesten voneinander entferntenPunkten zweier verschiedener Cluster (complete link)
• Group-Average: Distanz zweier verschiedener Cluster zueinander ist der Durch-schnitt der paarweisen Distanz zwischen den Punkten der Cluster c1 und c2:
dist(c1, c2) :
∑pi∈c1,pj∈c2
dist(pi,pj)
|c1|∗|c2|
Die Laufzeit des naiven Algorithmus aus 2.6 liegt bei Nutzung einer Distanzmatrix undn−1 Vereinigungen bei O(n3). Ein optimaler Algorithmus mit einer Laufzeit von O(n2)wird in Kapitel 3.2.4 vorgestellt.
2.3.2 Partitionierendes Clustering
Beim partitionierenden Clustering wird eine Aufteilung der Daten berechnet, so dassjeder Punkt genau einem oder keinem Cluster zugeordnet ist. Zwei der bekanntestenAnsatze werden im Folgenden vorgestellt.
k-Means
Durch den k-Means-Algorithmus (siehe Algorithmus 2.7) wird aus einer Menge vonPunkten eine Partitionierung in k disjunkte Gruppen berechnet. Hierfur werden zu-nachst k initiale Schwerpunkte, die nicht Teil der zu partitionierenden Punktemengesein brauchen, bestimmt und jeder Punkt dem ihm nachsten Schwerpunkt zugewiesen.
Algorithmus 2.7 k-Means Clustering ([TSK05] angepasst)
input: D - dataset to be clustered, K - initial centroidsoutput: K - final centroids
1: procedure KMeansClustering(D, K)2: assign each point to its nearest centroid k ∈ K3: repeat4: compute new centroids based on groups of points assigned to former centroids5: assign each point to its nearest centroid k ∈ K6: until centroids have not moved or centroid movement < δ7: return K
Mittels dieser Zuordnungen werden nun neue Schwerpunkte berechnet und die Punktewieder dem nachsten Schwerpunkt zugeordnet. Dieser Vorgang wird so lange iteriert,
24
bis sich die Schwerpunkte nicht mehr andern oder die Anderungen einen festzulegendenSchwellwert unterschreiten. Die Berechnung der Schwerpunkte ist im k-Means Algorith-mus die Summe der quadrierten Abweichungen (SSE) von den Clusterschwerpunkten;das Ziel des Algorithmus ist die Minimierung dieser Abweichung.
SSE =K∑i=1
∑x∈Ci
dist2(mi, x) (2.6)
Formal ist dies ist in der Gleichung 2.6 dargestellt. Fur jeden Datenpunkt ist der Fehlerdie Distanz zum nachstliegenden Schwerpunkt. x ist hierbei ein Datenpunkt des ClustersCi, mi ist der Schwerpunkt von Ci.
Die Berechnung der Schwerpunkte erfolgt, nachdem die Summe der quadrierten Abwei-chung berechnet wurde, nach Gleichung 2.7.
mi =1
|Ci|∑x inCi
x (2.7)
Die aufwandigste Berechnung in k-Means ist die Bestimmung der Distanzen der Daten-punkte zu den Clusterschwerpunkten. Hierbei ist zu beachten, dass diese unabhangigvoneinander sind, also parallel berechnet werden konnen. Jedoch werden nach jeder Ite-ration die Clusterschwerpunkte angepasst; die Iterationen mussen folglich sequentiellberechnet werden.
Abbildung 2.6: beispielhafte Darstellung des k-Means Algorithmus
Ein Beispiel ist in Abbildung 2.6 gezeigt; die Schwerpunkte sind hier als Kreise, die Da-tenpunkte als Quadrate dargestellt und die Farbe der Quadrate symbolisiert die Zuord-nung zu Schwerpunkten. Im ersten Bild sind farblich die initialen Schwerpunkte hervor-gehoben. Im zweiten Bild sind die Datenpunkte hinsichtlich der aktuellen Schwerpunkte(blass gefarbt) dargestellt, wahrend Schwerpunkte in kraftigem Grun und Rot die neu
25
berechneten abgebildet sind. Das dritte Bild stellt schließlich die zweite Iteration dar,in der erneut die Zuordnungen aktualisiert und auf Basis dieser die Schwerpunkte neuberechnet wurden.
Ausschlaggebend fur die Komplexitat des Algorithmus ist an erster Stelle die Anzahl derclusternden Punkte n. Aber auch die Anzahl der Cluster K, die Anzahl der Punktattri-bute d sowie die Anzahl der Iterationen I ist zu berucksichtigen, wobei die Anzahl derCluster ublicherweise kleiner als die Anzahl der Punkte ist und nur wenige Iterationenbenotigt werden. Daraus ergibt sich, dass die Zeitkomplexitat O(n ∗K ∗ I ∗ d) ist.
Nachteile Ein Problem des k-Means-Algorithmus ist, dass er ohne Eingreifen vonaußen keine optimale Losung berechnet; die Qualitat des Ergebnisses hangt stark vonAnzahl und Lage der gewahlten Schwerpunkte ab, die zudem vorgegeben werden mussen.Ein weiterer wichtiger Punkt ist, dass k-Means die Bildung kugelformiger Cluster an-strebt. Dies liegt an der Minimierung der Abstande zwischen Datenpunkten und Cluster-Schwerpunkten.
DBSCAN
Der DBSCAN-Algorithmus [EKSX96] ist ein dichtebasierter Algorithmus, der ein parti-tioniertes Clustering berechnet. Zu den wichtigsten Eigenschaften des Algorithmus zahlt,dass die Anzahl der Cluster nicht vorab festgelegt werden muss, da der AlgorithmusCluster selbststandig erkennen kann. Weiterhin kann der DBSCAN-Algorithmus Clustervon beliebiger Form erkennen und unterliegt somit auch hier keiner Limitierung wie derk-Means Algorithmus.
ε
p
Abbildung 2.7: ε-Nachbarschaft
Ein zentraler Aspekt des Algorithmus ist die ε-Nachbarschaft (Abbildung 2.7). Als Nach-barschaft eines Punktes p werden alle Punkte bezeichnet, die sich innerhalb des Umkrei-ses mit dem Radius ε befinden. Auf Grundlage der ε-Nachbarschaft lassen sich nun die
26
drei verschiedenen Klassen von Punkten definieren, die im DBSCAN-Algorithmus auf-treten:
• Kernpunkte, die sich dadurch auszeichnen, dass die Anzahl von Punkten in ihrerNachbarschaft einen bestimmten Schwellwert uberschreitet; diese werden als dichtbezeichnet.
• Randpunkte, die selber nicht dicht sind, sich jedoch innerhalb der Nachbarschafteines Kernpunkts befinden. Diese werden auch dichte-erreichbar genannt
• Rauschpunkte, die weder dicht noch dichte-erreichbar sind
Grundlage des Algorithmus ist das Prinzip der Dichte-Verbundenheit. Dieses besagt,dass zwei Punkte dichte-erreichbar sind, wenn sie durch eine Kette von Kernpunktenerreichbar sind. Die Punkte, die durch diese dichte-erreichbaren Punkte verbunden sind,bilden eine dichte-verbundene Menge, die auch als Cluster bezeichnet wird.
Der DBSCAN-Algorithmus (Algorithmus 2.8) startet mit einer Menge von zu clustern-den Datenpunkten, einem Wert fur ε, der die Große der Nachbarschaft eines Punktesfestlegt, sowie einem Wert minPts, der definiert, ab welcher Nachbarschaftsgroße einPunkt ein Kernpunkt ist. Zu Beginn sind zusatzlich alle Punkte als unklassifiziertmarkiert. Der Algorithmus durchlauft die Punktmenge vollstandig (Zeile 3-7), uberpruftjedoch nur fur noch nicht klassifizierte Punkte, ob von diesen ausgehend ein Cluster ge-bildet werden kann. Die Beschrankung auf unklassifizierte Punkte erfolgt, da durch dasPrinzip der Dichte-Verbundenheit Cluster wahrend ihrer Entdeckung bis zu ihrer maxi-malen Ausdehnung erweitert werden. Die Beschrankung verhindert folglich eine erneuteBetrachtung von bereits zugeordneten Punkten zum Zwecke der Suche und Erkennungvon Clustern.
Algorithmus 2.8 Der DBSCAN-Algorithmus ([EKSX96] angepasst)
input: points - dataset to be clusteredinput: ε - size of the neighborhoodinput: minPts - points required for a core point
1: procedure DBSCAN(points, ε, minPts)2: clusterId= 03: for i from 1 to points.size do4: point = points.get(i);5: if point.clusterId = UNCLASSIFIED then6: if ExpandCluster(points, point, clusterId, ε, minPts) then7: clusterId = clusterId + 1
Die Clustererweiterung (Algorithmus 2.9) startet mit der gesamten zu clusternden Punkt-menge, dem zur Suche und Erweiterung gewahlten Startpunkt, dem aktuellen Cluster-
27
Identifikator und den bereits aus Algorithmus 2.8 bekannten Großen ε und minPts alsEingabe.
Algorithmus 2.9 DBSCAN - Clustererweiterung ([EKSX96] angepasst)
input: points - dataset to be clusteredinput: point - starting point for cluster expansioninput: clusterId - identificator of the current clusterinput: ε - size of the neighborhoodinput: minPts - points required for a core pointoutput: boolean - indicates, whether cluster was found
1: procedure ExpandCluster(points, point, clusterId, ε, minPts)2: seeds = points.regionQuery(point, eps)3: if seeds.size < minPts then4: points.changeClusterId(point, NOISE )5: return FALSE6: else7: points.changeClusterIds(seeds, clusterId)8: seeds.delete(point)9: while seeds 6= ∅ do
10: currentPoint = seeds.first()11: result = points.regionQuery(currentPoint, ε)12: if result.size ≥ minPts then13: for i from 1 to result.size do14: resultPoint = result.get(i)15: if resultPoint.clusterId IN (UNCLASSIFIED, NOISE ) then16: if resultPoint.clusterId == UNCLASSIFIED then17: seeds.append(resultPoint)
18: points.changeClusterId(resultPoint, clusterId)
19: seeds.delete(currentPoint);
20: return TRUE;
Als erstes wird fur den Startpunkt die Nachbarschaft im Umkreis, der durch ε definiertist, abgefragt (Zeile 3-5) und in der Variable seeds gespeichert; diese wird spater zurErweiterung des Clusters verwendet. Wenn die Große der Nachbarschaft großer gleichminPts ist, so handelt es sich bei dem Punkt um einen Kernpunkt. Ist die Nachbarschaftjedoch kleiner als minPts, so wird der Punkt vorlaufig als Rauschen klassifiziert; dieseZuordnung ist jedoch noch nicht endgultig, da der Punkt noch von einem Kernpunktdichte-erreichbar sein kann. Falls es sich bei dem Punkt um einen Kernpunkt handelt,so werden zuerst alle Punkte der Nachbarschaft mit dem aktuellen Cluster-Identifikatorversehen und der aktuelle Punkt geloscht (Zeile 7-8). In den Zeilen 9 bis 19 findet nun dieeigentliche Erweiterung des Clusters statt. Aus der Menge seeds wird der erste Punktentnommen und die Nachbarschaft hinsichtlich ε abgefragt und in der Variable resultgespeichert. Wenn die Kardinalitat von result großer gleich minPts ist, so ist auch der
28
aktuelle Punkt ein Kernpunkt und wird zur Erweiterung des Clusters genutzt. Hierfurwird die vollstandige Nachbarschaft durchlaufen (Zeile 13 - 19) und diesen die aktuelleCluster-ID zugewiesen, wenn es sich um unklassifizierte oder Rausch-Punkte handelt(Zeile 18). Unklassifizierte Punkte werden zusatzlich der Menge seeds hinzugefugt undbei der Erweiterung des Clusters genutzt.
Der DBSCAN-Algorithmus (Algorithmus 2.8) durchlauft in seiner außeren Schleife jedenPunkt genau einmal. Die Suche nach Clustern mittels der Funktion ExpandClusterwird jedoch nur fur noch nicht-klassifizierte Punkte ausgefuhrt. Wenn eine Clustererwei-terung (Algorithmus 2.9) initiiert wird, wird zunachst die Nachbarschaft des Ausgangs-punktes mit einer raumlichen Suche bestimmt. Die Punkte im Ergebnis dieser Abfragewerden zusammen mit unklassifizierten Punkten aus weiteren Nachbarschaftsanfragenfur weitere Suchen verwendet. Geeignete Indexstrukturen wie etwa ein R-Baum ermog-lichen eine Nachbarschaftssuche in einer Laufzeit von O(log(n)), wahrend die Laufzeitohne Indexunterstutzung O(n2) betragt. Folglich ergibt sich bei der Nutzung einer raum-lichen Indexstruktur naherungsweise eine Laufzeit im Bereich von O(n ∗ log(n)) fur denDBSCAN-Algorithmus.
BeispielEine beispielhafte Szene zur Beschreibung des DBSCAN-Algorithmus ist in Abbildung2.8 abgebildet. Die Kreise stellen hier die Nachbarschaft der Punkte p und q dar, welcheeinen Radius von ε besitzen. Weiterhin sei eine Kardinalitat der Punktnachbarschaft von5 notwendiges Kriterium, damit ein Punkt ein Kernpunkt ist.
ε
p
q
r
s
Abbildung 2.8: DBSCAN - Beispiel
Der Punkt p ist, gemaß vorheriger Definition, ein Kernpunkt, da er uber eine genu-
29
gend große Nachbarschaft verfugt. Innerhalb dessen Nachbarschaft liegt der Punkt q,der somit dichte-erreichbar von p ist. Zusatzlich ist q ein Kernpunkt, da die Kardi-nalitat der Nachbarschaft von q ≥ 5 ist; q gehort folglich dem gleichen Cluster an wiep. Fur den Punkt r gilt, dass er von q dichte-erreichbar ist. Jedoch ist die Kardinalitatder Nachbarschaft von r < 5, somit ist r ein Randpunkt. Der Punkt s besitzt eineNachbarschafts-Kardinalitat von s < 5 und ist somit kein Kernpunkt. Zusatzlich ist sauch von keinem Kernpunkt erreichbar; s ist somit Rauschen bzw. ein Rauschpunkt.
NachteileDer gravierendste Nachteil des DBSCAN-Algorithmus tritt zu Tage, wenn der DatensatzGebiete mit sehr stark voneinander abweichenden Punktdichten enthalt. Der Algorith-mus ist bei derartigen Datensatzen nicht in der Lage, ein brauchbares Clustering zuerzeugen, da es keine Kombination der Parameter ε und minPts gibt, die fur alle vor-handenen Cluster passt.
2.4 Die UNION-Find-Struktur
Bestimmte Probleme, wie beispielsweise hierarchisches agglomeratives Clustering, habenzu Beginn eine Menge von Objekten, die jedes fur sich eine eigene Menge bilden. Im wei-teren Verlauf werden diese Mengen in einer bestimmten Reihenfolge zusammengefugt,um eine grobere Partitionierung zu bilden, die jedoch immer vollstandig und disjunktbleibt. Zusatzlich finden Abfragen statt, um die Menge in Erfahrung zu bringen, dieein bestimmtes Objekt enthalt. Diese Anforderungen lassen sich durch die OperationenUnion und Find auf Mengen realisieren. Die Union-Operation fuhrt hierbei die Verei-nigung zweier Mengen durch, wahrend die Find-Operation fur eine gegebenes Elementdie enthaltende Menge liefert.
ADT DisjointSet
Der abstrakte Datentyp DisjointSet (bzw. Union-Find-Struktur oder auch Merge-Find-Struktur) besteht aus einer Menge von Teilmengen, hier als Komponenten bezeichnet undden folgenden Operationen:
• Union(A,B) bestimmt die Vereinigung der Teilmengen [A] und [B] und definiertals Namen ein reprasentatives Element, dass in der neu entstandenen Menge ent-halten sein muss
• Find(x) liefert den Namen der Komponente zuruck, in der x enthalten ist
30
• Initial erzeugt eine Partitionierung, die aus disjunkten ein-elementigen Mengenbesteht.
Ein einfache Implementierung auf Array-Basis findet sich in Algorithmus 2.10 unter derBezeichnung Merge-Find-Set(MFSET), basierend auf [AHU83]. Die Operation Initialerzeugt ein neues MFSET, in der sich jedes Element in einer eigenen Partition bzw. Men-ge befindet. Die Menge, in der ein Element x enthalten ist, liefert die Find-Operation,indem einfach der Wert fur x im MFSET zuruckgegeben wird. Und auch die Vereini-gung einer Menge A mit einer Menge B ist in der array-basierten Implementierung desMFSETs durch die Operation Merge sehr einfach; das Array, welches die Komponen-ten der Struktur enthalt, wird von Anfang bis Ende durchlaufen und jedes Feld, das derMenge B zugewiesen ist wird der Menge A zugewiesen.
Algorithmus 2.10 ADT DisjointSet uber {1, . . . , n}, Array-Implementierung ([AHU83]angepasst)
output: returns new MFSET1: procedure Initial2: C := Array[1, . . . , n] of [1, . . . , n]3: for x := 1 to n do4: C[x] := x
5: return C
input: x - integer in the range {1, . . . , n}input: C - an existing MFSEToutput: integer of the class, that includes x
6: procedure Find(x,C)7: return C[x]
input: A,B - integers in the range {1, . . . , n}, that represent a classinput: C - an existing MFSEToutput: MFSET with merged classes A and B
8: procedure Merge(A,B; C)9: for x = 1 to C.length do
10: if C[x] = B then11: C[x] = A
12: return C
Die Laufzeitkomplexitat fur die Initialisierung eines MFSET betragt O(n), die Abfrageeines Wertes fur eine Komponente x betragt O(1). Die Implementierung zur Vereinigungzweier Klassen benotigt eine Laufzeit von O(n), da fur die Suche nach einer Klasse B dasvollstandige MFSET durchlaufen werden muss. Wenn nun Komponente fur Komponentedas MFSET mit der Vereinigungs-Operation zu einer einzigen Klasse vereinigt wird, so
31
werden maximal n−1 Operationen ausgefuhrt, so dass die Laufzeit insgesamt O(n2)betragt.
Eine deutliche Verbesserung der Laufzeit ist zu erreichen, wenn das MFSET als Baumund nicht als Array implementiert wird. Diese ermoglicht fur die Suche nach der Klassevon Komponenten eine Laufzeit von O(log(n)), fur die Vereinigung von zwei Klassensogar eine konstante Laufzeit von O(1).
2.5 Parallelrechner
Parallelrechner sind Computer, in denen Rechenoperationen nebenlaufig ausgefuhrt wer-den konnen. Die Parallelitat basiert auf der Grundlage, dass Probleme in kleinere Pro-bleme zerlegt und parallel zeitgleich ausgefuhrt werden konnen. Parallelrechner lassensich grundsatzlich in der Ebene, auf der die Parallelisierung stattfindet, unterteilen. Sokann ein einzelner Computer bereits mehrere Rechenelemente beeinhalten, wobei dieserals Multi-Cores im Falle mehrerer Kerne in einem Prozessor oder Multi-Prozessor imFalle mehrerer Prozessoren bezeichnet wird; jedoch arbeiten diese Rechenelemente nichtzwingend alle an der gleichen Aufgabe sondern werden teilweise beispielsweise durchAufgaben des Betriebssystems ausgelastet. Rechencluster und Rechengrids zeichnen sichdadurch aus, dass sie ein Verbund von Rechnern sind, die gemeinsam an der gleichenAufgabe arbeiten.
Zugleich ist die Entwicklung von Software fur Parallelrechner aufwandiger als fur se-quentielle Rechner, da Probleme durch gleichzeitigen Zugriff auf Datenstrukturen oderRace-Conditions auftreten konnen, die zu nicht vorhersehbarem Programmverhalten fuh-ren konnen. Dieses fuhrt dazu, dass Kommunikation und Synchronisierung zwischen denparallel laufenden Tasks stattfinden muss; dieses ist gleichzeitig einer der Faktoren, dermaßgeblich fur die Performance von paralleler Software verantwortlich ist, da nur oh-ne Kommunikation und Synchronisierung eine wirklich parallele Ausfuhrung von Taskserfolgt.
Dieser Sachverhalt lasst sich anschaulich durch das Amdahl’sche Gesetz verdeutlichen.Ein paralleles Programm besteht aus zwei wesentlichen Komponenten, einem sequen-tiellen Anteil (fs) und einem parallelen Anteil (fp). Diese sind normiert und bewegensich im Bereich 0 ≤ fs ≤ 1 und folglich fp = 1 − fs. Fur einen Parallelrechner mit nProzessoren ergibt sich nun eine Beschleunigung (Speed-Up) von:
sp(n) ≤ 1fpn
+ fs≤ 1
fs
Wenn die Anzahl der Prozessoren gegen unendlich geht, geht folglich die Ausfuhrungs-zeit des parallelen Anteils gegen null, so dass fur diesen Fall die Ausfuhrungszeit desparallelen Programms nach unten durch den sequentiellen Programmanteil beschrankt
32
ist. Folglich ist wahrend des Entwurfs und der Implementierung auf eine moglichst starkeEntkopplung der Teilaufgaben zu achten, um Synchronisation und Kommunikation, undsomit den sequentiellen Anteil, moglichst klein zu halten.
Ein weiteres wichtiges Unterscheidungsmerkmal fur Parallelrechner ist die Speicherarchi-tektur. Diese konnen einerseits einen gemeinsamen globalen Speicher besitzen (Shared-Memory-Architektur), der uber einen gemeinsamen Adressraum adressiert wird; dieKommunikation zwischen Prozessoren erfolgt in diesem Fall implizit uber Bereiche imgemeinsamen Speicher. Andererseits kann jeder Prozessor uber einen eigenen lokalenSpeicher mit eigenem Adressraum verfugen, auf den andere Prozessoren keinen Zugriffhaben; die Kommunikation zwischen Prozessoren erfolgt in diesem Fall explizit uberNachrichten, was als Message-Passing-Architektur bezeichnet wird.
2.6 MapReduce
MapReduce[DG04] bezeichnet sowohl ein Programmiermodell als auch eine Implementie-rung fur die Verarbeitung und Generierung großer Datenmengen. Kern des Programmier-modells sind zwei Phasen, die Map- und die Reduce-Phase, welche inspiriert sind durchdie gleichnamigen Funktionen aus der funktionalen Programmierung. Programme, dienach dem MapReduce-Programmiermodell entwickelt wurden, lassen sich automatischdurch MapReduce-Implementierungen, wie beispielsweise Hadoop, auf einem Cluster miteiner Vielzahl von Rechenknoten ausfuhren, ohne dass Erfahrung fur die Entwicklungparalleler Software oder verteilter Systeme notwendig ist. Ein weiterer wichtiger Fak-tor ist, dass die Ausfuhrung in eine Vielzahl von Tasks aufgeteilt wird, die unabhangigvoneinander ausgefuhrt werden. Der Vorteil dieser Losung ist, dass selbst der Ausfallvon Teilen des Rechenclusters nicht einen Neustart der Berechnung bedingt; Tasks, dienach Ablauf einer bestimmten Frist nicht erledigt worden sind, werden einfach abermalszur Bearbeitung freigegeben und von verbleibenden Teilen des Rechenverbunds durch-gefuhrt. Im Folgenden wird nun zunachst das hinter MapReduce stehende Programmier-modell erlautert, anschließend wird der hinter einem MapReduce-Programm steckendeProzess vorgestellt. Hadoop, eine MapReduce-Implementierung, wird in Abschnitt 2.6.3prasentiert.
2.6.1 Programmiermodell
In der Map-Phase (2.8) wird die Map-Funktion parallel auf jedes Schlussel-Wert-Paar(k1, v1) der Eingabe angewendet. Als Ergebnis liefert die Map-Funktion fur ein eingege-benes Paar eine Liste von Schlussel-Wert-Paaren. Im Anschluss werden vom MapReduce-Framework alle Schlussel-Wert-Paare mit gleichem Schlussel aus allen Listen eingesam-
33
melt und unter Beachtung des Schlussels gruppiert.
Map(〈k1, v1〉) = list(〈k2, v2〉) (2.8)
In der Reduce-Phase (2.9) wird die Reduce-Funktion parallel fur jeden Schlussel und diedazugehorige Liste von Werten ausgefuhrt und die Liste in reduzierter Form, beispiels-weise durch Aufsummierung der Werte, als Schlussel-Wert-Paar zuruckgegeben.
Reduce(〈k2, list(v2)〉) = 〈k2, v3〉 (2.9)
MapReduce - Beispiel
Das kurze Beispiel in Quelltext 2.1 stellt ein MapReduce-Programm dar, welches furein ubergebenes Dokument fur jedes Wort die Anzahl der Vorkommen innerhalb desDokumentes zahlt und ausgibt.
1 map(String key , String value):
2 # key: document name
3 # value: document contents
4 for each substring w in value:
5 Output <w,1>;
6
7 reduce(String key , Iterator values ):
8 # key: a word
9 # value: a list of numbers
10 int result = 0;
11 for each v in values:
12 result += v;
13 Output <key , result >;
Quelltext 2.1: MapReduce - Wortvorkommen in einem Dokument zahlen [DG04]
Die Aufgabe der Map-Funktion (Zeile 1) ist in diesem Beispiel sehr einfach. Sie durchlauftalle Worter des ubergebenen Dokuments (Zeile 4) und gibt fur jedes gefundene Wort einSchlussel-Wert-Paar der Form 〈Wort, 1〉 aus. Die Reduce-Funktion summiert die Anzahlder Vorkommen (Liste von ”values”) eines Wortes (”key”) auf und gibt diese zuruck.
Eine beispielhafte Ausfuhrung des Beispiels in Quelltext 2.1 ist in Abbildung 2.9 zusehen.
2.6.2 Der Map-Reduce Prozess
Zu Beginn des Prozesses wird zunachst eine Aufteilung der zu verarbeitenden Datenin sogenannte Shards vorgenommen. Anschließend wird der Prozess mit der Map-Phase
34
Die Sonne scheint und der Himmel ist blau. Es scheint ein schöner Tag zu werden, wenn die Sonne weiter scheint.
< die , 1>< sonne , 1>< scheint , 1>< und , 1>< der , 1>< himmel , 1>< ist , 1>< blau , 1>< es , 1>< scheint , 1>< ein , 1>< schöner , 1>< tag , 1>< zu , 1>< werden , 1>< wenn , 1>< die , 1>< sonne , 1>< weiter , 1>< scheint , 1>
< blau , 1>< der , 1>< die , 2>< ein , 1>< es , 1>< himmel , 1>< ist , 1>< scheint , 3>< schöner , 1>< sonne , 2>< tag , 1>< und , 1>< weiter , 1>< wenn , 1>< werden , 1>< zu , 1>
Map Reduce
Abbildung 2.9: MapReduce-Beispiel
gestartet, in dem fur jeden Shard ein Map-Task erstellt wird, die unabhangig voneinanderausgefuhrt werden.
Shard 1
Shard 2
Shard 3
Map
Map
Map
Reduce
Reduce
Ergebnis
Abbildung 2.10: Der MapReduce-Prozess
Wenn ein Map-Task gestartet wird, liest dieser den Teil der Eingabedaten, die ihmzugeordnet wurden. Aus diesem parst er die Schlussel-Wert-Paare und leitet diese an dieMap-Funktion weiter. Diese bearbeitet die Eingabe-Paare gemaß ihrer Definition undgibt sie wieder als Schlussel-Wert-Paare aus.
Die Ausgabedaten der Map-Tasks werden nun in der Reduce-Phase an Reduce-Tasksverteilt, was als ”Shuffling” bezeichnet wird. Die Verteilung erfolgt uber eine Partitio-nierungsfunktion, welche die Ergebnisse der Map-Tasks auf verschiedene disjunkte Par-titionen verteilt, wobei fur jede Partition ein Reduce-Task erzeugt wird. Die Partitio-
35
nierungsfunktion lasst sich beispielsweise einfach mittels einer Hash-Funktion umsetzen(z.B. hash(key) mod R mit R = Anzahl der Reducer).
Nun durchlauft der Reduce-Tasks die Schlussel-Wert-Paare der ihm zugewiesenen Par-tition und sortiert diese nach dem Schlussel, so dass die Werte nach diesen gruppiertsind. Die derart gruppierten Paare werden nun gruppenweise an die Reduce-Funktionubergeben, von dieser bearbeitet, und in Form eines einzelnen Schlussel-Wert-Paaresausgegeben.
Mit der Combine-Phase steht zusatzlich eine optionale Funktionalitat bereit, die gege-benenfalls Kommunikationskosten reduzieren kann. Funktional ist diese ahnlich wie dieReduce-Phase, wird jedoch lokal auf den Knoten nach Abschluss der Map-Phase aus-gefuhrt. Der Sinn dieser Phase ergibt sich aus der Betrachtung des Beispiels im Quell-text 2.1, dem Wortzahlen. Jeder Knoten berechnet aus dem zugewiesenen TextfragmentSchlussel-Wert-Paare der Form 〈′gefundenes Wort′,′ 1′〉. So gibt es beispielsweise eineHaufung von Wortern, etwa ’und’, ’der’ oder ’das’. Eine Reduktion der Kommunikati-onskosten lasst sich erreichen, indem diese Paare bereits lokal auf den Knoten zusam-mengefasst werden, so dass beispielsweise nicht 50 Paare 〈′das′,′ 1′〉 ausgegeben werden,sondern nur 〈′das′,′ 50′〉.
2.6.3 Hadoop
Hadoop ist eine MapReduce-Implementierung, die unter dem Dach der Apache Softwa-re Foundation entwickelt wird. In der Version 2.2.0, die in dieser Arbeit genutzt wird,besteht Hadoop aus drei wesentlichen Komponenten: Hadoop Distributed Filesystem,Hadoop YARN und Hadoop MapReduce, wobei Hadoop MapReduce das Programmier-modell darstellt, welches in allgemeiner Form bereits in Abschnitt 2.6.1 auf Seite 33 vor-gestellt wurde. Alle Komponenten wurden vor dem Hintergrund entworfen, dass Ausfallevon einzelnen Rechnern oder ganzen Racks in großen verteilten Systemen an der Tages-ordnung sind; die Erkennung und Behandlung von Ressourcen-Ausfallen ist aus diesemGrund direkt in Hadoop implementiert worden.
Hadoop Filesystem
Das Hadoop Filesystem (HDFS) ist ein Dateisystem, welches entwickelt wurde, um ver-schiedene Anforderungen zu erfullen. Zum einen soll das Datensystem in der Lage sein,sehr große Dateien mit einer Große von mehreren hundert Terabytes zu speichern. Zumanderen soll der Dateizugriff in Form von Streams moglich sein. Hintergrund hierfur ist,dass fur die Analyse Daten einmalig geschrieben, aber vielfach gelesen werden. In jederdurchgefuhrten Datenanalyse werden die gesamten zu analysierenden Daten oder großeTeile davon gelesen, so dass der ausschlaggebende Performance-Faktor fur eine Leseope-
36
ration die Gesamtzeit fur das Lesen der gesamten Daten ist, nicht der Zugriff auf einzelneTeile einer Datei. Außerdem soll das Dateisystem auf normaler Standard-Hardware ar-beiten, die im Gegensatz zu wesentlich teurerer hoch-zuverlassiger Hardware, bei einergroßen Anzahl von Knoten in einem verteilten System eine hohe Ausfallwahrscheinlich-keit fur einzelne Knoten hat. Im Falle eines Komponentenausfalls innerhalb des verteiltenSystems soll das Dateisystem ohne Unterbrechungen fur den Anwender weiter funktionie-ren; dies bedeutet, dass das Dateisystem trotz eines Ausfalls von Knoten weiter verfugbarbleibt und ein Ausfall zu keinem Datenverlust fuhrt.
HDFS benutzt als grundlegende Aufteilung des Speichers, wie andere Dateisysteme,Blocke von Speicher. Jedoch ist die Blockgroße mit 64 Megabyte oder mehr bedeu-tend großer, als dies bei Dateisystemem fur Standard-Massenspeicher, wie beispielsweiseNTFS oder EXT4, mit 4 Kilobyte. Dateien werden in Stucke entsprechend der Block-große aufgeteilt und unabhangig voneinander gespeichert. Im Unterschied zu normalenDateisystemen belegt ein Block, der nicht vollstandig gefullt ist, jedoch nicht den kom-pletten Speicher des Blockes im zugrunde liegenden Speichers sondern nur den tatsachlichvom Block verwendeten Speicher.
Die Abstraktion des Speichers in Blocke bringt einige Vorteile mit sich. Zum einen istes moglich, dass Dateien großer sein konnen als ein einzelner Massenspeicher der lokalenKnoten. Außerdem vereinfacht die Verwendung von Blocken die Replikation, um dieVerfugbarkeit und Fehlertoleranz zu verbessern. Um mit nicht verfugbaren Blocken inFolge von Hardware-Fehlern oder dem Ausfall von Knoten umzugehen, werden Blockeauf eine vom Administrator festzulegende Anzahl von Knoten repliziert, so dass diesegegebenenfalls von einem anderen Knoten gelesen werden kann.
Das verteilte Dateisystem wird aus zwei verschiedenen Typen von Knoten aufgebaut,einem Namenode (Master) und mehreren Datanodes (Worker). Der Namenode verwal-tet das Dateisystem in Form eines Dateisystem-Baumes und Metadaten fur alle Dateienund Verzeichnisse des Dateisystems. Diese werden lokal auf dem Namenode persistentgespeichert. Zusatzlich verfugt der Namenode hinsichtlich der Blocke, aus denen eineDatei besteht, uber die Information, auf welchen Datanodes diese physikalisch gespei-chert sind. Diese wird jedoch nicht persistent gespeichert sondern wahrend des Startsdes Dateisystems aus den ubermittelten Informationen der Datanodes rekonstruiert.
Der Zugriff auf das Dateisystem durch Nutzer erfolgt uber einen Client, der nach Aufrufdurch den Nutzer mit dem Namenode und den Datanodes kommuniziert. Die Schnitt-stelle fur den Dateizugriff auf das verteilte Dateisystem orientiert sich stark am PortableOperating System Interface(POSIX), so dass der Nutzer kein Wissen uber die Funkti-onsweise des Namenodes oder der Datanodes benotigt.
Wie zuvor bereits angedeutet sind die Datanodes fur den Großteil der Arbeit des ver-teilten Dateisystems verantwortlich. Auf Anweisung von Clients oder des Namenodesspeichern und Empfangen sie Datei-Blocke und liefern periodisch eine Liste der von
37
ihnen gespeicherten Blocke an den Namenode.
Aus dem Aufbau des Dateisystems ist ersichtlich, dass der Namenode eine zentrale Kom-ponente des verteilten Dateisystems und ein Single-Point-of-Failure ist. Tatsachlich kanndas Dateisystem ohne den Namenode nicht benutzt werden und als schwerwiegenderNachteil kommt zusatzlich hinzu, dass ein Ausfall des Namenodes zum Verlust allerDateien des Dateisystems fuhrt, da nur der Namenode uber die Informationen zur Re-konstruktion der Dateien aus den Blocken verfugt.
YARN
Das Yet-Another-Resource-Negotiator(YARN)-Framework ist die zentrale Komponen-te von Hadoop, welche zum einen die Ressourcen in Form von Rechenknoten verwal-tet und zum anderen fur das Scheduling der von Benutzern gestarteten MapReduce-Anwendungen verantwortlich ist.
YARN erfullt diese zwei wesentliche Aufgaben durch zwei verschiedene Dienste sind. Ei-nerseits werden die Berechnungs-Ressourcen des Clusters durch den Resource Managerverwaltet, andererseits steuert und uberwacht YARN den Lebenszyklus von Anwen-dungen (z.B. Verfolgung des Ausfuhrungsstatus von Tasks, fehlgeschlagenen Tasks neustarten), die auf dem Cluster ausgefuhrt werden, wobei jedes MapReduce-Programmeinen eigenen Application-Master besitzt.
Die Grundidee ist, dass der Application-Master mit dem Resource-Manager die Nutzungvon Resourcen des Clusters in Form von Containern mit festgelegten Speicherlimits aus-handelt und die Prozesse der MapReduce-Anwendung in diesen Containern ausfuhrt. DieUberwachung der Container erfolgt von den Node Managern, die auf jedem Clusterkno-ten laufen und dafur Sorge tragen, dass die Anwendungen sich an die durch die Containervorgegebenen Ressourcenbeschrankungen halten.
Fur die Ausfuhrung einer MapReduce-Anwendung mit dem YARN-Framework sind diefolgenden Komponenten notwendig:
• Ein Client, der die auszufuhrende MapReduce-Anwendung ubermittelt
• Der YARN-Resource-Manager, welcher die Ressourcenzuweisung des Clusters ko-ordiniert
• Die YARN-Node-Manager, die Container fur Tasks auf Clusterknoten starten unduberwachen
• Der Application-Master der MapReduce-Anwendung, der die Ausfuhrung von Tasksder Anwendung uberwacht. Der Application-Master und die Tasks werden in Con-
38
tainern ausgefuhrt, die vom Resource-Manager zugeteilt werden und durch dieNode-Manager verwaltet werden.
• Das verteilte HDFS-Dateisystem, welches genutzt wird, um Dateien der Taskszwischen den Komponenten auszutauschen.
client JVM
client node
MapReduceprogram
Job
resource manager node
Resource Manager
2: get new application
4: submit applications
node manager node
Node Manager
MRAppMaster
5a: start container
5b: launch
6: initializejob
SharedFileSystem(e.g. HDFS)
3: copy jobresources
8: allocate resources
7: retrieveinput splits
node manager node
Node Manager
task JVM
9a: startcontainer
9b: launch
YarnChild
MapTaskor
ReduceTask
11: run10: retrieve job resources
1: run job
Abbildung 2.11: Ablauf der Ausfuhrung einer MapReduce-Anwendung mit dem YARN-Framework [Whi12]
Der Ablauf einer MapReduce-Anwendung ist in Abbildung 2.11 dargestellt und beginnt,indem die Anwendung, auch Job genannt, auf einem Client gestartet wird (1).
Fur diesen Job wird vom Resource Manager ein Identifikator angefordert (2), um diesenund die zugehorigen Daten im System zuordnen zu konnen.
Der Client berechnet nun die Input-Splits, bzw. die Aufteilung der Eingabedaten, undkopiert diese Information zusammen mit der Anwendungskonfiguration und der Anwen-dung, welche in Form eines JAR-Archivs an Hadoop ubergeben wird, in das verteilteDateisystem (3).
39
Die Anwendung wird nun zur Ausfuhrung an den Resource Manager ubergeben (4).
Der Resource-Manager liefert die Anfrage zur Ausfuhrung einer Anwendung an einenJob-Scheduler weiter, der einen Container anfordert, in welchem der Resource-Managereine Instanz des Application Masters unter Verwaltung des Node Managers startet (5aund 5b).
Der Application Master startet die Ausfuhrung der Anwendung, in dem zunachst eineReihe von Variablen zur Verfolgung des Fortschritts der Anwendung initialisiert werden,da im Verlauf der Anwendung Fortschrittsmeldungen von Tasks und Meldungen uberabgeschlossene Tasks beim Application Master eingehen (6).
Im Anschluss wird die vom Client berechnete Aufteilung der Eingabedaten vom Appli-cation-Master geladen und ein Map-Task fur jeden Teil der Eingabe erstellt; zusatzlichwird eine festgelegte Anzahl von Reduce-Tasks erzeugt (7).
Nun fordert der Application Master vom Resource Manager Ressourcen in Form vonContainern fur die Ausfuhrung der Map- und Reduce-Tasks an (8). Die Anforderungenenthalten zusatzlich Information hinsichtlich der Lokalitat von zu Tasks gehorenden Da-ten, insbesondere Informationen, auf welchen Knoten und in welchen Racks der Teil derEingabe liegt. Diese Informationen konnen vom Scheduler fur die Entscheidung genutztwerden, um Tasks im Idealfall auf einem Knoten auszufuhren, auf dem die Daten bereitslokal vorhanden sind, mindestens jedoch auf einem Knoten im selben Rack. Mit denAnfragen sind zusatzlich Anforderungen von Speicher verbunden, so dass fur einzelneTasks gezielte Mengen von Speicher fur die Container angefordert wird.
Sobald einem Task durch den Resource Manager ein Container zugewiesen wurde, startetder Application Master den Container durch Benachrichtigung des Node Managers (9aund 9b).
Der Task wird durch eine Java-Anwendung in einer Java Virtual Machine (JVM) ausge-fuhrt. Jedoch mussen zuvor die Daten geladen werden, die fur die Ausfuhrung des Taskserforderlich sind, unter anderem die Konfiguration des Tasks und das JAR-Archiv, wel-ches die MapReduce-Anwendung enthalt (10).
Schließlich wird die der Map- oder Reduce-Task ausgefuhrt (11).
Fehlerbehandlung
Zusatzlich ist fur MapReduce-Programme, die unter Nutzung des YARN-Frameworksausgefuhrt werden, der Fehlerfall zu betrachten. Dies betrifft Tasks, den ApplicationMaster, Node Manager und den Resource Manager.
Falls ein laufender Tasks fehlschlagt, wird diese Information an den Application Master
40
ubermittelt und der Ausfuhrungsversuch des Tasks als fehlgeschlagen markiert. Eben-so werden Tasks als fehlgeschlagen markiert, die sich nicht innerhalb eines bestimmtenZeitintervalls beim Application Master melden. Die fehlgeschlagenen Tasks werden vomApplication Master erneut zur Ausfuhrung vergeben und ein erneuter Ausfuhrungsver-such unternommen, wobei die Anzahl der Versuche variabel ist.
Ebenso wie einzelne Tasks kann auch fur Ausfuhrung einer kompletten MapReduce-Anwendung mehrere Versuche unternommen werden. Ein Application Master sendetperiodisch Lebenszeichen (Heartbeats) an den Resource Manager, so dass der ResourceManager einen Fehler eines Application Masters an ausbleibenden Lebenszeichen er-kennen, und eine neue Instanz starten kann. Hierbei ist es moglich, den Status einesfehlgeschlagenen Application Masters wiederherzustellen; bereits erfolgreich ausgefuhrteTasks mussen so nicht nochmals ausgefuhrt werden.
Beim Ausfall eines Node Managers hort dieser auf, Lebenszeichen an den Resource Ma-nager zu senden. Dieser kann ihn daraufhin aus dem Pool verfugbarer Knoten entfernen.Tasks oder Anwendungen, die auf diesem Knoten laufen, konnen gemaß der Vorgehens-weisen von fehlgeschlagenen Tasks oder Fehlern des Applications Masters wiederherge-stellt werden.
Am schwerwiegendsten ist der Ausfall des Resource Managers, da ohne diesen wederAnwendungen noch Tasks gestartet werden konnen. Jedoch wurde dieser so entworfen,dass periodisch der Zustand persistent gespeichert wird und eine neue Instanz des Re-source Managers daraus wiederhergestellt werden kann. Der Zustand umfasst dabei dieNode Manager und laufende Anwendungen.
2.6.4 Ein- und Ausgabeformate
Ein weiterer Aspekt sind die Ein- und Ausgabeformate der Daten, die von Hadoopverarbeitet und generiert werden. Die Eingabeformate lassen sich grob in zwei Kategorienaufteilen: Dateieingaben und Datenbankeingaben. Die Dateieingaben wiederum lassensich unterteilen in einfache Textdateien und Binardateien.
Textdateien sind unstrukturierte Eingabedaten die auf verschiedene Arten verarbeitetwerden konnen. Zwei Beispiele hierfur sind das TextInputFormat und das KeyValueIn-putFormat. In ersterem entspricht jede Zeile einem Datensatz, wobei der Schlussel derByteoffset des Zeilenbeginns in der Eingabedatei ist und der Wert die gelesene Zeile.Zweiteres sind zum Beispiel CSV-Dateien mit zwei Spalten pro Zeile, so dass die ersteSpalte der Schlussel und die zweite der Wert ist.
Binardateien, sogennante SequenceFiles, sind Dateien, in denen Schlussel-Wert-Paarestrukturiert gespeichert werden. Strukturiert bedeutet in diesem Fall, dass zwischen je-dem Schlussel-Wert-Paar eine Marke existiert, so dass diese sauber voneinander getrennt
41
werden konnen. Diese haben den zusatzlichen Vorteil, dass sie komprimiert werden kon-nen und serialisierbare Datentypen nutzen konnen. Hadoop nutzt fur die Serialisierungein eigenes Format, sogenannte Writables. Diese sind von zentraler Bedeutung fur Ha-doop, da diese oft bei der Ein- und Ausgabe von Tasks als Datentypen fur die Schlussel-Wert-Paare verwendet werden und somit im verteilten Dateisystem gespeichert und ausdiesem gelesen werden. Die beiden wichtigsten Vorteile von diesen sind, dass sie ein kom-paktes Speichern und durch geringen Overhead schnelles Lesen und Schreiben erlauben.
Datenbankeingaben erlauben das Einlesen von Daten aus Datenbanken uber JDBC-Treiber. Dieses hat jedoch den Nachteil, dass es kein Sharding, also eine Aufteilung derEingabe, erlaubt, welches im verteilten Dateisystem durch die Speicherung in Blockenimplizit geschieht.
Die Ausgabeformate von Hadoop entsprechen den Eingabeformaten, so dass diese nichtnochmals aufgefuhrt werden.
42
Kapitel 3
Parallele Algorithmen
In den letzten Jahren fuhrt eine immer starkere Nutzung der Informationstechnik dazu,dass immer großere Mengen von Daten anfallen. Sequentielle Data Mining-Algorithmensind aus verschiedenen Grunden nicht mehr in der Lage, diese Datenmengen zu bewal-tigen. Zum Einen steigt die Berechnungszeit in inakzeptable Hohen, zum Anderen sinddie Datenmengen derart gewaltig, so dass diese von einzelnen Computern nicht mehr zuhandhaben sind. Aus diesem Grund wurden verschiedene Verfahren aus dem Bereich derAssoziations- und Clusteranalyse vorgeschlagen, um diese Herausforderungen zu bewal-tigen und eine effiziente Analyse der Daten zur ermoglichen. Von diesen wird in diesemKapitel eine Auswahl von Verfahren vorgestellt, die auf verschiedenen Parallelisierungs-ansatzen basieren.
Auf eine Betrachtung der Laufzeitkomplexitat der MapReduce-Algorithmen wird in die-ser Arbeit verzichtet, da sich noch kein Modell zur Beschreibung von dieser etablierthat.
3.1 Algorithmen zur Assoziationsanalyse
3.1.1 Partition-Algorithmus
Der Partition-Algorithmus [SON95](Algorithmus 3.1) benotigt fur das Berechnen vonfrequent Itemsets in Abhangigkeit eines minimalen Supports ξ in einer Menge von Trans-aktionen zwei vollstandige Suchlaufe auf diesem Datenbestand.
In der ersten Phase werden alle potentiellen frequent Itemsets durch eine Suche aufdem gesamten Datenbestand bestimmt. Hierfur werden die Daten in nicht uberlappendePartitionen aufgeteilt. Auf diesen Partitionen wird unabhangig voneinander die Menge
43
der lokalen frequent Itemsets berechnet. Die Mengen der generierten lokalen frequentItemsets werden anschließend zu einer Menge zusammengefuhrt, der Kandidatenmengefur potentielle globale frequent Itemsets.
Zu Beginn der zweiten Phase wird zunachst fur jedes Itemset der globalen Kandidaten-menge ein Zahler erzeugt. Nun wird der tatsachliche Support der Kandidaten auf dergesamten Datenbank berechnet, indem die Vorkommen der Kandidaten in jeder Parti-tion gezahlt und die Zahler entsprechend erhoht werden. Anschließend lasst sich durcheinen einfachen Vergleich mit dem minimalen Support die Menge der frequent Itemsetsberechnen.
Im Gegensatz zum Apriori-Algorithmus, der global auf der vollstandigen Transaktions-datenbank arbeitet, besitzt der Partition-Algorithmus durch die Partitionierung aucheine lokale Komponente. Es findet eine Unterscheidung zwischen lokalen und globalenfrequent Itemsets statt. Die verschiedenen auftretenden Itemset-Menge sind in Tabelle3.1 dargestellt. Zusatzlich sind einige Begriffe zu definieren, die fur den Partition-Algorithmus von Bedeutung sind. Im Kontext dieses Verfahrens ist eine Partition p ∈D ein Ausschnitt aus der gesamten Menge von Transaktionen, wobei diese als nicht-uberlappend definiert sind. Zwei Partitionen sind nicht uberlappend, wenn sie paar-weise disjunkt hinsichtlich der enthaltenen Transaktionen sind, formal: pi
⋂pj = ∅ |
∀i, j : i 6= j. Fur diese wird nun ebenfalls ein lokaler minimaler Support definiert: die-ser bezeichnet den Anteil der Transaktionen in der Partition, die ein Itemset benotigt,um als lokales frequent Itemset bezeichnet zu werden. Festgelegt ist der Wert des lokalenminimalen Supports auf ξ/|D|; ein Itemset ist also ein potentielles globales frequent Item-set, wenn dieses in mindestens einer Partition lokal haufig ist. Itemsets, die gegen denlokalen Support auf Haufigkeit getestet werden, werden als lokale Kandidaten-Itemsetsbezeichnet.
Cpk Menge der lokalen Kandidaten der k-Itemsets in Partition p
Lpk Menge der lokalen frequent k-Itemsets in Partition pLp Menge aller lokalen frequent Itemsets in Partition pCGk Menge aller Kandidaten der globalen k-Itemsets
CG Menge aller globalen Itemsets-KandidatenLGk Menge aller globalen frequent k-Itemsets
Tabelle 3.1: Ubersicht und Notation der verschiedenen Itemset-Mengen
Globaler Support, globale frequent Itemsets und globale Itemset-Kandidaten sind wie dievorher genannten lokalen Varianten definiert, sie beziehen sich jedoch nicht auf einePartition p ∈ D sondern auf die vollstandige Menge von Transaktionen D.
44
Algorithmus 3.1 Partition-Algorithmus ([SON95] angepasst)
input: D - database of transactionsinput: n - number of partitionsinput: ξ - minimum supportoutput: LG - list of global frequent itemsets
1: procedure Partition(D, n, ξ)2: P = Partition Database(D)3: τ = ξ/n . τ - lokaler minimaler Support4: for i = 1 to n in parallel do . Erzeugung der Kandidaten5: Read In Partition(pi ∈ P )6: Li = Gen Large Itemsets(pi, τ)
7: for (i = 2;Lji 6= ∅, i = 1, 2, . . . , n; i+ +) do . Merge der lokalen Kandidaten8: CG
i =⋃j=1,2,...,n L
ji
9: for i = 1 to n in parallel do . Berechnung des globalen Supports10: Read In Partition(pi ∈ P )11: Gen Count(CG, pi)
12: LG = {c ∈ CG|c.count ≥ ξ}13: return frequent itemsets LG
Ablauf
Zu Beginn des Algorithmus wird die Transaktionsdatenbank D in n logische Partitionenaufgeteilt. In der ersten Phase wird in n Iterationen parallel mit dem Algorithmus 3.2fur die jeweilige Partition pi als Eingabe die Menge Li der lokalen frequent Itemsets derLangen 1, . . . , l berechnet mit Li = Li1 ∪ Li2 ∪ . . . ∪ Lil.
Anschließend werden sequentiell die berechneten Kandidaten-Mengen lokaler frequentItemsets aller n Partition zu einer großen Menge vereinigt, der Kandidatenmenge furglobale frequent Itemsets.
In der zweiten Phase wird nun parallel in jeder Partition der Support jedes Kandida-ten mit der Funktion Gen Count gezahlt und anschließend aufsummiert. Kandidaten,deren Support uber dem globalen minimalen Support ξ liegen werden in die MengeLG, der Menge der globalen frequent Itemsets, eingefugt und am Ende des Algorithmuszuruckgegeben.
Erzeugung lokaler frequent Itemsets
Dier Erzeugung lokaler frequent Itemsets mit Algorithmus 3.2 beginnt mit einer Parti-tion der Transaktionsmenge und dem lokalen minimalen Support τ . Zunachst wird ausder Transaktionsmenge die Menge aller lokalen frequent 1-Itemsets berechnet und jedes
45
dieser Itemsets die Liste der Transaktionen angehangt, in denen das Itemset enthaltenist. Nun beginnt die Erzeugung der lokalen frequent Itemsets mit der Lange k aus Kan-didaten der Lange k−1 (Zeilen 3-11). Hierfur wird in einer inneren und außeren Schleifejeweils uber die Kandidaten mit der Lange k−1 iteriert. Wenn zwei Kandidaten l1 undl2 nun bis zur k−1-ten Stelle identisch sind und sich an dieser unterscheiden, so dassl1[k−1] < l2[k−1], so wird ein neues Itemset c generiert, welches bis zur k− 2-ten Stelleidentisch ist und dann l1[k−1] und anschließend l2[k−1] angehangt.
Algorithmus 3.2 Generierung großer Itemsets im Partition-Algorithmus ([SON95]angepasst)
input: p - database partitioninput: τ - local minimum supportoutput: Lp - list of local frequent itemsets in p
1: procedure Gen Large Itemsets(p, τ)2: Lp1 ={large 1-itemsets along with their tidlists}3: for (k = 2;Lpk 6= ∅; k + +) do4: for all itemsets l1 ∈ Lpk−1 do5: for all itemsets l2 ∈ Lpk−1 do6: if l1[1] = l2[1]∧l1[2] = l2[2]∧. . .∧l1[k−2] = l2[k−2]∧l1[k−1] < l2[k−1]
then7: c = l1[1] · l1[2] · · · l1[k − 1] · l2[k − 1]8: if Prune(c) == false then9: c.tidlist = l1.tidlist∩l2.tidlist
10: if |c.tidlist| / |p| ≥ τ then11: Lpk = Lpk ∪ {c}12: return Lp
Fur diesen Kandidaten ist erst zu testen, ob dieser auf Grund des Apriori-Prinzips (Ab-schnitt 2.2.1) verworfen werden kann. Dieses passiert mit Algorithmus 3.3, indem fur allek−1-Teilmengen getest wird, ob diese in Kandidaten-Menge lokaler frequent Itemsetsder Lange k−1, Lk−1 enthalten ist. Wenn dies der Fall ist, wird die Schnittmenge derTransaktionen der Itemsets l1 und l2, aus denen der Kandidat c enstanden ist, berechnetund an c angehangt.
Wenn nun die Anzahl der Transaktionen, in den c enthalten ist, durch die Transaktions-zahl der Partition p großer ist als der lokale minimale Support τ , so wird c zu der Mengeder lokalen frequent Itemsets der Lange k hinzugefugt. Dieser Vorgang wird solange fort-gesetzt, bis in einer Iteration keine neuen Itemsets mehr generiert werden. Anschließendwird die Liste Lp mit allen lokalen frequent Itemsets zuruckgegeben.
46
Algorithmus 3.3 Der Pruning-Schritt im Partition-Algorithmus ([SON95] angepasst)
input: c - k-itemsetoutput: boolean that indicates, whether c can be pruned
1: procedure Prune(c: k-itemset)2: for all (k − 1)-subsets s of c do3: if s /∈ Lk−1 then4: return true5: else6: return false
Erzeugung der globalen frequent Itemsets
Das Zahlen der Vorkommen aller Itemsets c aus CG in einer Partition p beginnt zunachst,in dem fur jedes Vorkommende 1-Itemset eine Liste erzeugt wird, in welchen Transak-tionen dieses vorkommt. Die Menge von Transaktion, die c enthalt, ergibt sich, indemSchritt fur Schritt aus den Items von c der Schnitt der Transaktionslisten berechnet wird.Dieses wird fur alle c ∈ CG durchgefuhrt und abschließend CG zuruckgegeben.
Algorithmus 3.4 Berechnung des Supports der Kandidaten in einer Partition ([SON95]uberarbeitet)
input: CG - list of all itemset candidatesinput: p - partitionoutput: count of all c ∈ CG in p
1: procedure Gen Count(c, p)2: for all 1-itemsets do3: generate the tidlist for partition p
4: for all c ∈ CG do5: c.count = c[1].tidlist
⋂c[2].tidlist
⋂. . .⋂c[k].tidlist
6: return CG
3.1.2 Laufzeit
Die Laufzeit des Partition-Algorithmus setzt sich im wesentlichen aus zwei Teilen zu-sammen, der Erzeugung von lokalen frequent-Itemset-Kandidatenmengen und der Be-stimmung des Supports der globalen Kandidatenmenge.
Als erstes ist fur die Bestimmung der frequent 1-Itemsets eine Laufzeit von O(|p| · w)notig, wobei w die durchschnittliche Transaktionslange bezeichnet. Die Erzeugung der lo-kalen Kandidatenmengen erfolgt ahnlich zum Apriori-Algorithmus aus Abschnitt 2.2.1.Fur die Erzeugung eines neuen Kandidaten sind maximal k−2 Vergleichsoperationen
47
auszufuhren. Diese ist fur alle Itemset-Paare der vorherigen Iteration durchzufuhren.Fur das Pruning der Kandidaten sind, wie im Apriori-Algorithmus, alle k−1 Teilmen-gen hinsichtlich der Haufigkeit des Vorkommens zu uberprufen; zusatzlich sind hierfurebenfalls k−1 Zugriffe auf eine Datenstruktur zur Speicherung der frequent ItemsetKandidaten notig, welche im Falle eines HashSets in O(1) erfolgen. Die Vereinigung derListen mit den Transaktions-Identifikatoren schließlich erfordert den einmaligen Durch-lauf beider Listen, sofern diese sortiert sind. Insgesamt erfolgt die Kandidatenerzeugungalso in O(|p| · w) + O(
∑wk=2 |L
pk−1|2 · ((k−2) + k · (k−1) + (|l1| + |l2|))). Wie fur den
Apriori-Algorithmus gilt auch hier, dass die Laufzeit fur einen sehr niedrigen Supportexponentiell sein; die Laufzeit-Komplexitat liegt also bei O(2
n
p)
Fur die Berechnung der Vorkommen der Kandidatenmenge ist zunachst die Bestimmungder Listen mit den Transaktions-Identifikatoren fur die 1-Itemsets erforderlich. Wie inder im Schritt zur Kandidatengenerierung benotigt dies eine Laufzeit von O(|p| · w).Fur die Zahlung des globalen Supports werden nun alle Kandidaten durchlaufen und dieSchnittmengen der Listen mit den Transaktions-Identifikatoren gebildet. Diese kann inO(|CG| · ((k−1) · (2 · l))) ausgefuhrt werden, wobei l die durchschnittliche Lange derListen ist.
Analog zum Apriori-Algorithmus ergibt sich fur einen sehr niedrigen notwendigen Sup-port eine exponentielle Laufzeit, so dass die Partition-Algorithmus im schlechtesten FallO(2
n
p) betragt.
3.1.3 MapReduce-Partition
Der Partition-Algorithmus aus dem vorherigen Abschnitt lasst sich auf relativ einfacheWeise auf das MapReduce-Paradigma ubertragen [RU11]. Hierfur werden zwei aufein-ander folgende MapReduce-Phasen verwendet. In der ersten Phase lesen die Mapper diezugewiesenen Eingabepartitionen ein und generieren auf diesen lokale frequent Itemsets,welche ausgegeben werden. Die Reducer der ersten Phase lesen diese ein und fassendiese zu der Kandidatenmenge fur potentielle globale frequent Itemsets zusammen. Inder zweiten Phase berechnen die Mapper fur die zugewiesene Partition, wie oft jedesKandidaten-Itemset in dieser vorkommt. Das Itemset wird zusammen mit dem Vor-kommen als Schlussel-Wert-Paar ausgegeben. Die Reducer summieren nun die fur jedesItemset die Vorkommen auf und geben das Itemset aus, wenn es den minimalen Sup-port uberschreitet. Der folgende Pseudocode zur Beschreibung der beiden Phasen desPartition-Algorithmus ist auf Grundlage der Ausfuhrungen von [RU11] und mit Refe-renzierung der bereits vorhanden Pseudocodes aus Abschnitt 3.1.1 erstellt worden.
48
Phase 1: Generierung der Kandidaten
Die Map-Funktion liest zunachst die ihr zugewiesene Partition, bzw. die darin enthalte-nen Transaktionen, und berechnet die lokalen frequent Itemsets dieser Teilmenge nachAlgorithmus 3.2.
Algorithmus 3.5 Kandidatengenerierung
input: key: null, value: list of transactionsoutput: key: local frequent itemset, value - null
1: procedure Mapper(key, value)2: L← Gen Large Itemsets(value)3: for each itemset in L do4: Output(〈 itemset, null 〉)
input: key - local frequent itemset, value - nulloutput: key - itemset, value - null
5: procedure Reducer(key,value)6: Output(〈key, null〉)
Die so berechneten Itemsets werden als Schlussel-Wert-Paare der Form 〈itemset, null〉ausgegeben. Die Funktionalitat der Reducer ist im ersten Durchlauf extrem einfach ge-halten; sie geben auftretende Itemsets unverandert als Schlussel-Wert-Paar der Form 〈Itemset, null 〉 aus. Die Menge von Itemsets, die nach dem Ende der Reduce-Phase vor-liegt, ist die Menge der Kandidaten-Itemsets, fur die getestet werden muss, ob sie auchglobal haufig sind.
Phase 2: Berechnung des globalen Supports
In der Map-Phase des zweiten Durchlaufes wird nun fur jede Partition die Anzahl derVorkommen fur jedes Kandidaten-Itemset berechnet. Die Berechnung erfolgt hierfur nachAlgorithmus 3.4. Fur jedes Itemset wird das Vorkommen als Paar 〈Itemset, Anzahl derVorkommen〉 ausgegeben.
In der Reduce-Phase werden nun von den Reducern fur jedes Kandidaten-Itemset dieVorkommen aufsummiert und der Support berechnet. Itemsets, deren Support den mi-nimal notwendigen Support erreichen oder uberschreiten sind globale frequent Itemsetsund werden als Schlussel-Wert-Paar 〈Itemset, count〉 ausgegeben.
49
Algorithmus 3.6 Berechnung des globalen Supports
input: key - null, value - list of transactionsinput: candidates : list of frequent itemset candidatesoutput: key - itemset, value - itemset count
1: procedure Mapper(key, value)2: Gen Count(candidates, value)3: for each c ∈ candidates do4: Output (〈c, c.count〉)
input: key - itemset i , value - list of itemset i’s countsoutput: key - itemset, value - itemset count
5: procedure Reducer(key, value)6: count← 07: for each v in value do8: count← count+ v
9: if count ≥ minSupp then10: Output(〈itemset, count〉)
3.1.4 MapReduce Frequent-Pattern-Growth (PFP)
Der MapReduce FP-Growth Algorithmus (PFP) [LWZ+08] ist eine parallelisierte Vari-ante des FP-Growth Algorithmus (Abschnitt 2.2.2) fur verteile Computercluster unterNutzung des MapReduce-Frameworks. Die Grundidee des Algorithmus ist eine Partitio-nierung der Transaktionsdatenbank in unabhangige Teile, so dass parallel ohne außereAbhangigkeiten mit dem FP-Growth Algorithmus haufige Itemsets gesucht werden kon-nen.
Der Ablauf des Algorithmus (Abbildung 3.1) gliedert sich in funf Phasen. In der erstenPhase wird die Datenbank in Teile zerlegt, die auf P verschiedenen Knoten in einemverteilten Dateisystem gespeichert werden. Diese Zerlegung und Verteilung der Datenwird als sharding bezeichnet, jedes einzelne Teil als Shard.
Die Supportwerte aller Items aus der Datenbank werden in der zweiten Phase berech-net. Hierfur wird ein MapReduce-Durchlauf ausgefuhrt (Algorithmus 3.7), in welchemjeder Mapper einen Shard als Eingabe erhalt und fur jedes gefundene Item ai in einerTransaktion Ti ein Schlussel-Wert-Paar der Form 〈Item, 1〉 ausgibt. Die Reducer fas-sen nun die Menge der Werte fur jedes Vorkommen von ai zusammen und geben einSchlussel-Wert-Paar der Form 〈null, ai + count〉 aus. In diesem Schritt wird außerdemdas Vokabular I der Datenbank bestimmt, welches fur große Datensatze oftmals nichtbekannt ist. Das Ergebnis, die haufigen 1-Itemsets und ihr Support, wird in einer Liste,der F-Liste (Frequent Itemset List) gespeichert.
In der dritten Phase werden die |I| Items aus der F-Liste gleichmaßig in Q Gruppen
50
Eingabedaten
Ergebnis
Zwischenergebnis
Liste häufiger 1-Itemsets
Gruppenliste
Neue integrierte Daten
CPU CPU CPU
CPU CPU CPU
CPU
CPU CPU CPU
CPU CPU CPU
CPU CPU CPU
Gruppe 1 Gruppe 2 Gruppe Q
CPU
Q R
CPU
Q R
CPU
Q R
Map
Map
Map
Reduce
Reduce
Reduce
1 & 2: Sharding und paralleles
Zählen
3: Items gruppieren
4: paralleles und selbst-
anpassendes FP-Growth
5. Aggregierung
Abbildung 3.1: Ablaufdiagramm des PFP-Algorithmus (nach [LWZ+08])
51
Algorithmus 3.7 Berechnung des Supports aller 1-Itemsets ([LWZ+08] angepasst)
input: key - null, value - transaction Tioutput: key - item ai, value - 1
1: procedure Mapper(key, value)2: for each item ai in Ti do3: Output (〈ai,′ 1′〉)
input: key - an item ai, value - set of values corresponding to key aioutput: key - null, value - item with corresponding occurence count
4: procedure Reducer(key, value)5: count← 0;6: for each ′1′ in value do7: count← count+ 1
8: Output(〈 null, ai + count〉)
verteilt, wobei die Liste der Gruppen als G-Liste (Group List) bezeichnet wird undjede Gruppe einen eindeutigen Identifikator erhalt. Aufgrund der geringen Große undZeitkomplexitat kann diese Phase auf einem einzelnen Knoten ausgefuhrt werden.
Das Kernstuck des Algorithmus, das Generieren von haufigen Itemsets, erfolgt in dervierten Phase mit Algorithmus 3.8. Diese benotigt einen MapReduce-Durchlauf, wobeiin der Map-Phase Transaktionen fur gruppen-abhangige Partitionen erzeugt werden undin der Reduce-Phase der FP-Growth Algorithmus auf den zuvor generierten gruppen-abhangigen Transaktions-Partitionen ausgefuhrt wird.
Beim Start eines Mappers wird zunachst die Gruppen-Liste geladen, welche in Form einerHash-Tabelle organisiert wird (Zeile 2-3). Hierdurch wird jedes Item ai auf eine Gruppegid abgebildet. Als Eingabe erhalten die Mapper einen Shard der Eingabedaten, wobeidas Eingabe-Paar fur die Map-Funktion von der Form 〈null, Ti〉 ist und somit nur eineeinzige Transaktion als Wert enthalt. Fur jede gelesene Transaktion wird jedes Item ajdurch die Gruppen-ID substituiert, welche sich aus der Anwendung des Items auf dieHash-Tabelle H ergibt (Zeile 6). Fur jede nun vorkommende Gruppen-ID gid wird dasam weitesten rechts stehende Vorkommen bestimmt, hier j und entsprechende Paare derForm 〈 gid, {Ti[1] . . . Ti[L]} 〉 ausgegeben. Jede Transaktion wird folglich Element furElement, von rechts beginnend, verkurzt und anhand der Gruppenzugehorigkeit des amweitesten rechts stehenden Element einer Gruppe zugeordnet. Wichtig hierbei ist jedoch,dass die ursprungliche Transaktion bzw. die aus der Verkurzung resultierenden Teilmen-gen jeder Gruppe hochstens einmal zugeordnet werden. Dieses wird gewahrleistet durchdas Entfernen der Paare 〈 HashNum, ai〉 aus der Hash-Tabelle H (Zeile 8). Wenn alleMap-Tasks fertiggestellt wurden, werden von der MapReduce-Infrastruktur die von denMappern ausgegebenen Paare gesammelt und die Werte nach dem Schlussel gruppiert.Die gruppen-abhangigen Transaktion werden an die Reducer ubergeben in Form vonPaaren 〈gid,DB gid〉, wobei DB gid eine Menge von gruppen-abhangigen Transaktionen
52
Algorithmus 3.8 Suche von frequent Itemsets mit dem FP-Growth-Algorithmus([LWZ+08] angepasst)
input: key - null, value - transaction Tioutput: key - hash-value, value - itemset
1: procedure Mapper(key, value)2: load G-List3: generate Hash Table H from G-List4: a[]← Split(Ti)5: for j = |Ti| − 1 to 0 do6: HashNum← getHashNum(H, a[j])7: if HashNum 6= Null then8: delete all pairs whose hash value is HashNum in H9: output (〈HashNum, a[0] + a[1] + . . .+ a[j]〉)
input: key - group-id, value - transaction-list corresponding to group-idoutput: key - null, value - itemset with support value
10: procedure Reducer(key, value)11: load G-List12: nowGroup← G− Listgid13: LocalFPtree← clear14: LocalFPtree = ConstructFpTree(DBgid, ξ)15: for each ai in nowGroup do16: create a max heap HP with size K17: TopKFPGrowth(LocalFPtree, ai,HP)18: for each vi in HP do19: call Output(〈null, vi + supp(vi)〉)
mit der selben Gruppen-ID gid sind. Diese Menge wird als gruppen-abhangiger Shard,bzw. Partition, bezeichnet.
In jedem Task erzeugt der Reducer einen FP-Baum (Zeile 14) und generiert mit einenleicht abgewandelten FP-Growth Algorithmus (siehe Algorithmus 2.5 auf Seite 20 fur dasOriginal) Itemsets (Zeile 15-19). Der Unterschied zum normalen FP-Growth Algorithmusliegt in der Tatsache, dass fur ein Itemset ai nur die K Itemsets mit dem großten Supportgeliefert werden welche vom Algorithmus direkt in einem Maximum-Heap der Große Kverwaltet werden. Diese werden anschließend als Schlussel-Wert-Paare 〈null, v+supp(v)〉,also ohne Schlussel und als Wert das Itemset mit dem zugehorigen Support, ausgegeben.
Eine Aggregierung der Ergebnisse aus Algorithmus 3.8 erfolgt nun in der funften Phasemit Algorithmus 3.9. Fur jedes Item ai werden die K Itemsets mit dem großten Supportausgegeben. Als Eingabe erhalten die Mapper in diesem Schritt Schlussel-Wert-Paare derForm 〈null, v + supp(v)〉, also einem Itemset mit dem zugehorigen Support; aus diesemwird fur jedes aj ∈ v ein Paar der Form 〈aj, v + supp(v)〉 ausgegeben.
53
Algorithmus 3.9 Aggregierung der Ergebnisse ([LWZ+08] angepasst)
input: key - null, value - itemset v with corresponing support countoutput: key - item, value - itemset v with corresponding support count
1: procedure Mapper(key, value)2: for all item ai in v do3: Call Output(〈ai, v + supp(v)〉)
input: key - item, value - set of itemsets v with corresponding support countsoutput: key - null, value - item ai and top-k supported itemsets and support counts
4: procedure Reducer(key, value)5: define and clear a size K max heap HP ;6: if |HP | < K then7: insert v + supp(v) into HP8: else9: if supp(HP [0].v) < supp(v) then
10: delete top element in HP11: insert v + supp(v) into HP
12: for each v ∈ HP do13: Call Output(〈 null, ai + v〉)
Die Reduce-Tasks verarbeiten als Eingabe nun Schlussel-Wert-Paare 〈aj, set(v+supp(v))〉als Eingabe, wobei set(v + supp(v)) eine Menge von Transaktionen mit dem zugehori-gen Support bezeichnet, welche das Item aj enthalten. Diese werden direkt in einenMaximum-Heap HP, der nach dem Support-Wert sortiert ist, eingefugt, solange dieserweniger als K Elemente enthalt. Wenn der Heap bereits K Elemente enthalt konnenzwei Falle auftreten. Wenn der Support des einzufugenden Itemsets v großer als der desItemsets mit dem kleinsten Support-Wert des Heaps ist, so wird dieses aus dem Heapentfernt und v eingefugt. Ansonsten wird v verworfen. Wenn der Reducer alle Wertegelesen hat werden zum Abschluss alle Itemsets v des Heaps als Schlussel-Wert-Paare〈null, ai + v〉 ausgegeben.
Abschließend ist festzuhalten, dass aus der Beschreibung des Algorithmus nicht hervor-geht, ob die Ergebnisse des Verfahrens exakt oder lediglich approximativ sind. Kernpunkthierfur ist die Aufteilung in gruppenabhangige Shards. Zunachst erfolgt eine Aufteilungder auftretenden Items in Q Gruppen, wobei eine Gruppe mehrere Items enthalten kann.Anschließend werden die Transaktionen sukzessive gekurzt und nach dem Hashwert desletzten Transaktions-Items einem Shard, der einer Gruppe zugeordnet ist, zugewiesen.Jedoch ist es nicht moglich, dass in einer Partition mehr als eine Teilmenge der Aus-gangstransaktion auftritt.
Durch das Auftreten von Teilmengen einer Transaktion in verschiedenen gruppenabhan-gigen Shards ist deshalb anzunehmen, dass der Algorithmus nur approximative Ergeb-
54
nisse liefert. In Kapitel 5 wird deshalb experimentell versucht, in einem Vergleich mitdem MapReduce-Partition-Algorithmus eine Antwort auf diese Frage zu finden.
3.1.5 Weitere Algorithmen
Der PARMA-Algorithmus (Parallel Randomized Algorithm for Approximate AssociationRule Mining in MapReduce)[RDFU12] ist ein paralleler Algorithmus auf Grundlage desMapReduce-Paradigmas, der durch ein stochastisches Verfahren eine Annaherung derMenge von frequent Itemsets berechnet. Hierfur nimmt jeder Rechenknoten eine Stich-probe der Transaktionsdatenbank. Die Knoten berechnen unabhangig voneinander diefrequent Itemsets der Stichprobe, die abschließend zu einem einzigen Ergebnis gefiltertund aggregiert werden. Die Qualitat der Naherung ist uber Parameter fur Genauigkeitund Fehlerwahrscheinlichkeit der Stichprobe kontrollierbar. Diese Parameter bestimmenletzlich auch den Umfang der Stichprobe.
Ein weiteres paralleles Verfahren fur Multi-Core-Rechner ist der P-Mine-Algorithmus(Parallel Itemset mining on large datasets) [BCCG13], welcher als grundlegende Daten-struktur einen HY-Baum[BCC10] verwendet. Bei diesem handelt es sich, analog zumFP-Baum des FP-Growth-Algorithmus um einen Prafix-Baum, der Transaktionen nachHaufigkeit sortiert reprasentiert. Ein zentraler Aspekt ist, dass fur einen Baumdurch-lauf die physischen Speicherorte der Knoten uber Zeiger festgehalten werden. Außerdemexistiert ein sogenannter Item-Index, der es zum einen ermoglicht, alle Pfade, die einbestimmtes Item enthalten zu ermitteln, zum anderen enthalt er alle Items des HY-Baumes zusammen mit ihrem Support sowie Zeiger auf den physikalischen Speicherort.Die Suche nach frequent Itemsets erfolgt, analog zum FP-Growth-Algorithmus, durchdie Generierung bedingter Teilbaume und der rekursiven Abarbeitung.
Der MLFPT-Algorithmus (Multiple local frequent pattern trees)[ZEHL01] ist paralle-les Verfahren zur Assoziationsanalyse, welches auf den Grundlagen des FP-Growth-Algorithmus basiert. Der Algorithmus benotigt zwei Suchlaufe auf der Transaktionsda-tenbank und besteht aus zwei Phasen. In der ersten Phase werden parallele FP-Baumeerzeugt. In dieser werden in einem Suchlauf parallel die frequent 1-Itemsets bestimmt,nach Haufigkeit sortiert und in einer Header-Tabelle gespeichert. In einem zweiten Durch-lauf werden parallel die lokalen FP-Baume aufgebaut. Jeder Prozessor baut aus der zu-gewiesenen Menge von Transaktionen einen eigenen FP-Baum auf, verwirft Items, dienicht in der Header-Tabelle vorhanden sind und sortiert die Transaktionen gemaß derHaufigkeit der Items. Jedoch ist die Header-Tabelle im MLFPT-Algorithmus global unddie Zeiger verbinden so die Items verschiedener FP-Baume. Fur die Suche nach frequentItemsets wird der Support aller Items durch die Anzahl der Prozessoren geteilt und soder durchschnittliche Support A gebildet. Die Items werden uber den Support-Wert aufdie Prozessoren verteilt, so dass der kumulierte Support jedes Prozessors etwa A betragt.Die Prozessoren bilden nun auf Basis ihrer zugewiesenen Items bedingte FP-Baume auf
55
Grundlage der lokalen FP-Baume, die zuvor berechnet worden sind. In diesen wird dannparallel nach frequent Itemsets gesucht.
3.2 Algorithmen zur Clusteranalyse
3.2.1 Parallel Partially Overlapping Partitioning (pPOP)
Partial Overlapping Partitioning (POP)
Der POP-Algorithmus[DL01] nutzt die 90-10-Regel aus, um die Speicheranforderun-gen und die Laufzeit zu reduzieren. Diese ergibt sich aus Beobachtungen des Verlaufshierarchischer Clusterings und besagt, dass in den ersten 90% der Iterationen des Al-gorithmus Cluster vereinigt werden, deren Entfernung weniger als 10% der maximalenVerschmelzungs-Distanz von allen Cluster-Vereinigungen betragt (Abbildung 3.2).
Min
imal
er A
bst
and
Anzahl der Schritte
Abbildung 3.2: Die 90-10-Regel im hierarchischen Clustering
Basierend auf dieser Annahme wird nun der zu clusternde Datensatz in p Zellen un-terteilt, die sich in den Randbereichen uberlappen. Dieser Uberlappungsbereich wird alsδ-Region bezeichnet, wobei δ die Breite dieses Bereiches bezeichnet (Abbildung 3.3), undgehort immer zu zwei Partitionen.
Hierarchische Clusteringverfahren, wie etwa der SLINK-Algorithmus [Sib73], haben imbesten Fall eine Komplexitat von O(n2). Weiterhin lasst sich aus der 90-10-Regel schlie-ßen, dass zu Beginn des Algorithmus Paare mit sehr kleinen Distanzen vereinigt werden,so dass diese lokal begrenzt sind. Im Umkehrschluss bedeutet dies, dass durch die, minde-stens quadratische, Komplexitat die Verschmelzungsoperationen auf den unteren Ebenendes Dendrograms sehr teuer sind. Eine Aufteilung der zu clusternden Daten in Parti-tionen ermoglicht somit eine signifikante Reduktion der Laufzeit, da die zugehorigen
56
Distanzmatrizen einen geringeren Umfang besitzen.
δ δ δ δ
δ
δ
δ δ δ δ
δ
δ
Abbildung 3.3: POP-Algorithmus - Uberlappende Partitionen
Die Grundidee des POP-Algorithmus (Algorithmus 3.10) ist die Unterteilung des Da-tensatzes in p Partitionen nach einem zu bestimmenden Attribut; jede der Zellen besitztmit den angrenzenden Nachbarn einen Uberlappungsbereich, der als δ-Region bezeichnetwird (Abbildung 3.3).
Wahrend jeder Iteration wird nun in jeder Zelle nach dem Cluster-Paar mit dem gering-sten Abstand gesucht, aus diesen wiederum das Paar mit insgesamt geringsten Distanzausgewahlt wird; wenn diese Distanz kleiner als δ ist, so werden die beiden Clusterverbunden und die Prioritatswarteschlangen der betroffenen Zelle aktualisiert. Wenn ei-ner der beiden Clusterschwerpunkte oder der Schwerpunkt des vereinigten Clusters inder δ-Region liegt, so wird zusatzlich die Warteschlange der anderen betroffenen Zelleaktualisiert. Diese erste Phase wird solange fortgesetzt, bis die Distanz zwischen Cluster-Paaren δ uberschreitet.
In der zweiten Phase wird abschließend ein klassischer Algorithmus fur hierarchischesClustering auf den verbleibenden Clustern angewendet, um das Dendrogram zu vervoll-standigen.
57
Algorithmus 3.10 Der POP-Algorithmus ([DL01] angepasst)
input: d - dataset to be clusteredinput: p - number of partitions, δ - width of cell overlapoutput: resulting dendrogram
1: procedure POP2: choose attribute to partition the data3: divide the dataset d into p partitions with margin δ4: init priority queues P for each cell5: while merging distance < δ do6: init priority queue clusterPairs7: for each cell c do8: find closest cluster pair p(C1, C2) ∈ c9: clusterPairs.insert(p)
10: closestPair = clusterPairs.deque()11: Cnew = merge(closestPair)12: update corresponding priority queue P containing p13: if C1 ∈ p ∨ C2 ∈ p ∨ Cnew in δ-region then14: update priority queue P of affected cell
15: if any of the pair merged cluster in δ-region, update P of affected cell
16: remove duplicates from the δ-regions17: cluster the remaining k’ clusters18: return dendrogram
Parallelisierung des POP-Algorithmus
Eine mogliche Parallelisierung ergibt sich direkt, wenn die Struktur des POP-Verfahrens(Abschnitt 3.2.1 Algorithmus 3.10) betrachtet wird. In diesem wird der Datenraum indisjunkte Partitionen unterteilt und in jedem Schritt werden sequentiell in diesen dienachsten Cluster-Paare gesucht. Zusatzlich ist bei einer Verschmelzung die Distanzma-trix der betroffenen Partition zu aktualisieren, wobei Distanzen zwischen Clusterpaarenbestimmt werden mussen. Der pPOP -Algorithmus [DPS07] setzt an diesen Punkten anund parallelisiert die Berechnung der nachsten Paare, sowohl bei der Suche nach Ver-schmelzungskandidaten als auch bei der Aktualisierung der Distanzmatrizen; die cha-rakteristischen zwei Phasen des POP-Algorithmus, der Aufbau lokaler Dendrogrammeund das anschließende Verschmelzen zu einem globalen Dendrogram, bleiben im pPOP-Algorithmus erhalten.
In der ersten Phase werden die Daten in uberlappende Zellen partitioniert, wobei derUberlappungsbereich die Breite δ besitzt. Nun wird parallel in jeder Partition das Clu-sterpaar mit der kleinsten Inter-Cluster-Distanz gesucht. Das Paar mit der insgesamtkleinsten Distanz dist < δ wird von einem festgelegten Prozessor gewahlt und anschlie-ßend vereinigt. Bei der Vereinigung sind nur Cluster und folglich Distanzen derselben
58
Zelle betroffen; es muss nur die Distanzmatrix einer Zelle aktualisiert werden. Wennsich das nachste Paar jedoch innerhalb einer δ-Uberlappungszone, dem Randbereich derZelle, befindet, mussen zusatzlich zur Zelle, die die vereinigten Cluster enthalt, auch dieDistanzen zwischen Clustern der an den δ-Breich angrenzenden Zellen aktualisiert wer-den. Die erste Phase wird beendet, sobald die Distanz zwischen den nachsten Paaren δuberschreitet.
In der zweiten Phase werden die verbliebenen Cluster durch Verwendung eines sequen-tiellen Algorithmus fur hierarchisches agglomeratives Clustering vereinigt.
Ablauf
Die hier vorgestellte Variante des pPOP-Algorithmus (Algorithmus 3.11) verwendet furdie Implementierung der Distanzmatrix Prioritatswarteschlangen. Diese werden zu Be-ginn parallel initialisiert. Die zu berechnenden Zellen werden den verfugbaren Prozesso-ren so zugeordnet, dass jeder Prozessor die Prioritatswarteschlangen fur durchschnittlichc/p Zellen berechnet. Jeder Prozessor erhalt so eine eigene Menge kleinster Inter-Cluster-Distanzen fur die Zellen, die von ihm berechnet werden. Aus dieser wahlt er die kleinsteaus und liefert die Zellennummer, in der dieses Paar zu finden ist. Folglich ergibt sichhieraus, dass es nach der parallel Bestimmung der kleinsten Distanz (Zeile 6-7) p klein-ste Distanzen von Clusterpaaren und zugehorige Zellennummern gibt. Ein Prozessor,der quasi als Master fungiert, wahlt hieraus nun das insgesamt kleinste Paar aus undverschmilzt dieses zu einem neuen Cluster (Zeile 8-10). Fur den neuen Cluster ist nuneine neue Prioritatswarteschlange anzulegen, in welcher die Distanzen zu allen anderenClustern der Zelle gespeichert sind. Auch diese Berechnung kann parallelisiert werden,indem jeder Prozessor einen Teil der Distanzen berechnet.
Nach der Vereinigung des Clusterpaares sind im Anschluss auch die Warteschlangen deranderen Cluster in der Zelle zu aktualisieren, was ebenfalls parallel erfolgen kann, indem jeder Prozessor einen Teil der Warteschlangen aktualisiert, also Cclus(C)
p(Zeile 11-
12). Fur den Fall, dass einer der vereinigten Cluster oder der neu gebildete Cluster imδ-Randbereich der Partition lagen, so sind in den hiervon betroffenen Zellen ebenfallsdie Warteschlagen zu aktualisieren (Zeile 13-17). Sobald die kleinste gefundene Distanzzwischen Clusterpaaren mindestens die Große δ erreicht hat endet der parallele Teil desAlgorithmus; die bis hierhin gebildeten lokalen Dendrogramme werden durch die Anwen-dung eines sequentiellen hierarchischen Clustering-Algorithmus durch die Vereinigungder verbliebenen Cluster zu einem globalen Dendrogram verschmolzen.
Die Laufzeitkomplexitat des pPOP-Algorithmus setzt sich aus vier Teilen zusammen. Furdie Initialisierung der Prioritatswarteschlagen ergibt sich eine Komplexitat von O(N
2
c∗p),wobei p die Anzahl der Prozessoren und N die Anzahl der Datenpunkte ist. Die anschlie-ßende WHILE-Schleife wird maximal N − 1-mal durchlaufen, hat also eine Laufzeit vonO(N). Die Komplexitat fur die Suche nach den beiden Punkten mit der geringsten
59
Algorithmus 3.11 pPOP-Algorithmus ([DPS07] angepasst)
Ccell(p) - number of cells assigned to processor pCclus(C) - chunk of clusters in cell Cinput: ds: dataset, c: number of cells, δ: width of cell overlapoutput: dendrogram of a clustered dataset ds
1: procedure P-POP(ds, c, δ)2: partition ds in c cells3: for each processor P in parallel do4: create priority queues for Ccell(P )
5: while overall min dist < δ do6: for each processor P in parallel do7: determine closest pair (CL1, CL2) for each cell C in Ccell(p) in parallel
8: on designated processor P9: find overall closest pair (CL1, CL2) and cell C that holds it
10: merge CL1 and CL2
11: for each processor P in parallel do12: update the priority queues of Cclus(C)
13: on designated processor P14: determine if neighbor cells are affected by the merged clusters15: for each processor P in parallel do16: for each affected cell C do17: update priority queues of Cclus(C)
18: merge resuming clusters with sequential hierarchical clustering algorithm19: return complete dendrogram
Distanz ist O(np). n bezeichnet hier die Anzahl von Clustern, die noch in den Prioritats-
warteschlangen vorhanden sind. Fur den vierten Schritt, das Aktualisieren der von der
Vereinigung betroffenen Prioritatswarteschlagen, betragt die Komplexitat O(n∗log(n
c)
p),
da eine einzelne Prioritatswarteschlange nc
Cluster enthalt. Insgesamt ergibt sich somit
eine Laufzeit von O(N2∗log(N
c)
p).
3.2.2 Parallel Disjoint-Set DBSCAN (PDSDBSCAN)
Um eine Erweiterung des ursprunglichen DBSCAN-Algorithmus [EKSX96] handelt essich bei dem PDSDBSCAN-Algorithmus[PPA+12], der eine Parallelisierung durch dieVerwendung der Union-Find-Datenstruktur erreicht. Zunachst wird die sequentielle Va-riante, der Disjoint-Set DBSCAN -Algorithmus vorstellt. Mit diesem als Grundlage wirdsodann eine parallele Implementierung vorgestellt.
60
Der Disjoint-Set-DBSCAN-Algorithmus
Im ersten Schritt des Algorithmus 3.12 wird die Punktmenge X derart aufgeteilt, dassjeder Punkt in einer eigenen Menge enthalten ist. Zusatzlich werden fur die jeweiligenMengen die Zeiger fur die Vorganger auf die eigene Menge gesetzt (Zeile 2-3). Anschlie-ßend wird die gesamte Punktemenge durchlaufen; fur jeden Punkt wird zunachst dessenNachbarschaft in Abhangigkeit vom Punkt x und der Nachbarschaftsgroße eps bestimmtund in der Menge N gespeichert. Wenn die Anzahl der Nachbarn großer als die minimaleNachbarschaftsgroße ist, wird x als Kernpunkt markiert. Dann erfolgt eine zusatzlicheBetrachtung der Punkte x′, die in der Nachbarschaft von x enthalten sind. Fur jedendieser Punkte wird gepruft, ob x′ ein Kernpunkt ist oder ob er noch keinem Clusterzugeordnet ist. Wenn der Punkt ein Kernpunkt ist werden die Mengen, die x und x′
enthalten, vereinigt. Falls x′ noch keinem Cluster zugeordnet ist, wird wie im vorherigenSchritt die Mengen, die x und x′ enthalten vereinigt. Analog zum DBSCAN-Algorithmusergibt sich durch Nutzung einer raumlichen Indexstruktur eine Laufzeitkomplexitat vonO(n ∗ log(n)) wenn eine DisjointSet-Implementierung verwendet wird, die eine Klassen-vereinigung in O(1) ermoglicht.
Algorithmus 3.12 DSDBSCAN-Algorithmus ([PPA+12] angepasst)
input: X - set of pointsinput: eps - neighborhood sizeinput: minpts - number of points required for classification as core point
1: procedure DSDBSCAN(X, eps,minpts)2: for each point x ∈ X do3: p(x)← x
4: for each point x ∈ X do5: N ← GetNeighbors(x, eps)6: if |N | ≥ minpts then7: mark x as core point8: for each point x′ ∈ N do9: if x′ is a core point then
10: Union(x, x′)11: else if x′ is not yet member of any cluster then12: mark x′ as member of a cluster13: Union(x, x′)
Ein Beispiel fur die einzelnen Phasen des DSDBSCAN-Algorithmus ist in Abbildung3.4 dargestellt. In diesem sind drei Punkte innerhalb der Punktnachbarschaft fur eineKlassifikation als Kernpunkt notwendig. Im ersten Teil der Abbildung ist die raumlicheVerteilung der Punkte des Beispiels abgebildet; die Große der ε-Nachbarschaft ist durchgestrichelte Kreise dargestellt. Das DisjointSet nach seiner Initialisierung mit den Bei-spielpunkten ist im zweiten Teil zu sehen. Eine Nachbarschaftssuche, ausgehend von den
61
Punkten 4, 5, 6 und 7 ist in dritten Teil zu sehen; das Ergebnis dieser spiegelt sich in dengebildeten Baumen wieder. Das finale Clustering schließlich ist im vierten Teil der Ab-bildung abgebildet. Cluster sind hier durch blaue Baume mit blauen Knoten, Rauschendurch Baume mit roten Knoten hervorgehoben.
1
2
3
4
5
6
7
8
9
91 2 3 4 5 6 7 8
1
2
3
4
5 6
9
7
8
1
2 3 4
5 6
9
7
8
1
2
3
4
Abbildung 3.4: Beispielhafte Abbildung der Phasen des DSDBSCAN-Algorithmus (nach[PPA+12])
Der Algorithmus (PDSDBSCAN)
Kernpunkt der parallelen Version des DSDBSCAN-Algorithmus ist die Union-Find-Datenstruktur (Abschnitt 2.4). Hierbei wird zuerst der Datenraum partitioniert, so-dass die Partitionen unabhangig von einander auf den lokalen Datenpunkten die lokalenCluster, respektive Baume, berechnen. Sobald die Baume fur die jeweiligen Partitionen
62
berechnet sind, werden diese verschmolzen, um aus den lokalen Clustern die globalen zuerzeugen.
Zugrunde liegt zunachst die Annahme, dass der Algorithmus auf einem Rechner mitgemeinsamen Speicher und p Threads ausgefuhrt wird. Der Datenraum der Punktmengesoll also in p Partitionen, {X1, X2, . . . , Xp}, wobei jedem Thread eine Partition zugewie-sen wird. Fur jeden Thread t bezeichne Yt eine Menge von Punkt-Paaren (x, x′), so dassx ∈ Xt und x′ /∈ Xt.
Algorithmus 3.13 PDSDBSCAN-Algorithmus ([PPA+12] angepasst)
input: X - set of pointsinput: eps - neighborhood sizeinput: minpts - number of points required for classification as core point
1: procedure PDSDBSCAN-S(X, eps,minpts)2: for t = 1 to p in parallel do3: for each point x ∈ Xt do4: p(x)← x
5: Yt ← ∅6: for each point x ∈ Xt do7: N ← GetNeighbors(x, eps)8: if |N | ≥ minpts then9: mark x as a core point
10: for each point x′ ∈ N do11: if x′ ∈ Xt then12: if x′ is a core point then13: Union(x, x′)14: else if x′ /∈ any cluster then15: mark x′ as member of a cluster16: Union(x, x′)
17: else18: Yt ← Yt ∪ {(x, x′)}19: for t = 1 to p in parallel do20: for each (x, x′) ∈ Yt do21: if x′ is a core point then22: UnionUsingLock(x, x′)23: else if x′ /∈ any cluster then24: mark x′ as member of a cluster25: UnionUsingLock(x, x′)
Der Algorithmus kann in zwei wesentliche Teile, einen lokalen (Zeile 2-18) und einenglobalen (Zeile 19-25), aufgeteilt werden. Die Berechnungen innerhalb des lokalen Teilssind identisch zu denen aus Algorithmus 3.12, jedoch werden nicht Datenpunkte aus derganzen Punktmenge X sondern nur aus der Partition Xt des Threads verwendet. Zu
63
beachten ist hierbei jedoch, dass in der Abfrage der Nachbarschaft eines Punktes x ∈ Xt
auch Punkte x′ /∈ Xt enthalten sein konnen. In diesem Fall wird das Verschmelzender Baume, die x und x′ enthalten, verzogert und in der Merge-Phase gelost. Hierfurwird das Paar (x, x′) zu der Menge Yt hinzugefugt. Die einzigen Falle, in denen dieThreads auf nicht-lokale Punktedaten, also Punkte außerhalb der eigenen Partition,zugreifen, sind die Lesezugriffe, wenn die Nachbarschaft eines Punktes abgefragt wird.Es ist hierbei festzuhalten, dass in diesem ersten lokalen Schritt keine Kommunikationzwischen den Threads notwendig ist, ja sogar nicht erwunscht ist, damit die lokale Phasevollstandig unabhangig voneinander ausgefuhrt werden kann, es also keine Verluste durchKommunikationsverzogerungen gibt. Folglich werden hier lokale Union-Find-Strukturenverwendet.
Algorithmus 3.14 Vereinigung von Union-Find-Strukturen mit Sperre ([PPA+12] an-gepasst)
input: points x and x′ to be merged1: procedure UnionUsingLock(x, x′)2: while p(x) 6= p(x′) do3: if p(x) < p(x′) then4: if x = p(x) then5: Lock(p(x))6: if x = p(x) then7: p(x)← p(x′)
8: Unlock(p(x))
9: x = p(x)10: else11: if x′ = p(x′) then12: Lock(p(x′))13: if x′ = p(x′) then14: p(x′)← p(x)
15: Unlock(p(x′))
16: x′ = p(x′)
Im zweiten Schritt, der Vereinigung der Baume (Algorithmus 3.14), werden die in Ytenthaltenen Punktpaare durchlaufen. Fur jedes Paar (x, x′) ∈ Yt wird uberpruft, ob x′
ein Kernpunkt ist oder noch nicht zu einem Cluster hinzugefugt wurde. Wenn dies derFall ist, werden die Baume, die x und x′ enthalten, mit der Union-Operation vereinigt.Implizit sorgt dieser Schritt dafur, dass x und x′ schließlich dem gleichen Cluster ange-horen. Wahrend des Vereinigungsvorgangs kann es passieren, dass die Vorganger-Zeigervon Punkten geandert werden, die einem anderen Berechnungsthread zugeordnet sind.Es ist also notwendig, Vorkehrungen fur den konkurrierenden Zugriff auf die Punkte zutreffen.
Der Grundgedanke bei den Sperren ist, dass jeder Punkt eine eigene Sperre besitzt,
64
was aufgrund des gemeinsamen Speichers notwendig ist. Nehmen wir an, dass wir zweiWurzeln r1 und r2 haben. Nehmen wir weiter an, dass wir den Vorgangerzeiger von r1auf r2 umsetzen wollen. Um nun eine Union-Operation zum Verschmelzen auszufuhrenist das erfolgreiche Anfordern einer Sperre auf r1 erforderlich. Nun kann es passieren,dass der Thread, der die Sperre anfordert, warten muss, da ein anderer Thread bereitsdie Sperre des Punkts gesetzt hat. Nun gibt es zwei Moglichkeiten:
1. Wenn r1 weiterhin eine Wurzel ist wird der Vorgangerzeiger von r1 auf r2 gesetzt
2. Falls ein anderer Thread den Vorgangerzeiger geandert hebt der Thread die Sperreauf und setzt die Ausfuhrung von der momentanen Position fort
Die Laufzeit fur den ersten Teil des Algorithmus liegt bei O(n∗log(n)p
), da die Berechnun-gen identisch mit dem DSDBSCAN-Algorithmus sind und vollig unabhangig voneinanderausgefuhrt werden konnen. Fur den zweiten Teil, die Vereinigung der lokalen Clusterings,hangt die Laufzeit maßgeblich von der Große der Menge Yt ab, wobei fur jedes Elementaus Yt eine Vereinigung mit Algorithmus 3.14 ausgefuhrt wird. Da die diese solange aus-gefuhrt wird, bis beide Baume auf die gleiche Wurzel zeigen, betragt die Laufzeit maximalO(log(n)). Patwary et al. verweisen in [PPA+12] darauf, dass in der Praxis nur in sehrwenigen Fallen Sperren andere ausfuhrende Threads blockieren, da sich die Punktpaarein Yt oft im gleichen Baum befinden, so dass die Laufzeitkomplexitat fur die VereinigungO(Yt∗log(n)
p). Folglich kann die Laufzeit des gesamten PDSDBSCAN-Algorithmus grob
mit O( (n+Yt)∗(log(n))p
) abgeschatzt werden.
3.2.3 MapReduce-DBSCAN
Massiv angestiegene Datenmengen haben zu verschiedenen Vorschlagen wie etwa PDB-SCAN [XJK99] oder PDSDBSCAN [PPA+12] gefuhrt, um den bekannten DBSCAN-Algorithmus (Abschnitt 2.3.2) zu parallelisieren. Diese haben jedoch als Nachteil, dassdie gesamte Parallelisierung des Verfahrens durch die Entwickler in Form von Nachrich-tenaustausch oder gemeinsam genutztem Speicher behandelt werden muss. Eine Alterna-tive zu klassischen Ansatzen ist das MapReduce-Framework (Abschnitt 2.5), welches dieDetails der Parallelisierung vor den Entwicklern verborgen halt. [HTL+14] prasentiereneine Variante des DBSCAN-Algorithmus, die das MapReduce-Paradigma zu Paralleli-sierungszwecken nutzt.
Der Ablauf des Algorithmus ist in Abbildung 3.5 abgebildet.
Im ersten Schritt, der Datenpartitionierung, wird ein zunachst ein Profil der zu clu-sternden Daten erstellt. Es wird zuerst die Anzahl der Punkte in den Rohdaten unddie raumliche Verteilung ermittelt. Basierend hierauf wird ein rechteck-basiertes Parti-tionierungsprofil des Datenraumes erstellt. Dieses ist die Grundlage fur den nachsten
65
Rohdaten
Daten mit globalen
Cluster IDs
1.1: Zellen-basierte statistische Analyse
globales Abbildungsprofil
2:lokales Clustering
3.2:Umbenennung der
Daten
Mengen der Mergekandidaten
Profil der Aufteilungsbereiche
Statistisches Profil Partionierungsprofil
1.2: Partitionierung 3.1: Erzeuge Merge-Abbildung
1. Datenpartitionierung 3. Globale Vereinigung
Metadaten
Punktdaten
Abbildung 3.5: Ablauf des MR-DBSCAN-Algorithmus [HTL+14]
Schritt, das lokale Clustering. In diesem wird der eigentliche Clustering-Algorithmusfur jeden Teilraum, der aus dem Partitionierungsprofil hervorgeht, ausgefuhrt. Hier-fur wird eine Abwandlung des DBSCAN-Algorithmus verwendet, der an einigen Stellenan die Einschrankungen einer MapReduce-Implementierung, die fehlende Kommunikati-onsmoglichkeit zwischen parallelen Berechnung, angepasst wurde. Im dritten und letztenSchritt, der globalen Vereinigung, werden dann die Teilergebnisse der lokalen Clusteringsmittels eines Profils der Aufteilungsbereiche zu einem globalen Clustering aggregiert.
Vorbereitung der Partitionierung
Eine wichtige Aufgabe fallt der Vorverarbeitung zu, da in dieser das Partitionierungs-schema fur den Datensatz festgelegt wird. Dieses hat aufgrund der ungleichmaßigenVerteilung von Objekten in Datensatzen zentralen Einfluss auf die Lastverteilung, danur durch eine gleichmaßige Partitionierung, die an die Datenverteilung angepasst ist,ein optimaler Durchsatz erreicht werden kann.
Um ein angepasstes Partitionierungsschema zu erstellen besteht eine mogliche Losungdarin, einen raumlichen Index, wie etwa einen R-Baum oder kD-Baum, aufzubauen.Jedoch gestaltet sich dieses wegen des großen Umfangs der Datensatze schwierig, dahierarchische Indexstrukturen bei umfangreichen Datenmengen selber einen erheblichenPlatzbedarf besitzen; somit kann also bereits die raumliche Indexierung nicht mehr effi-zient handhabbare Dimensionen erreichen.
[HTL+14] schlagen als Grundlage eine binare Partitionierung des Raumes (BSP: bina-ry space partitioning), um eine effiziente Aufteilung des Datenraumes in nicht uber-lappende Rechtecke zu erreichen und daraus Partitionen zu erzeugen. Auf Grundlagevordefinierter Regeln wird durch BSP rekursiv eine Aufteilung des Raumes in zwei klei-nere Teilraume vorgenommen. Eine weit verbreitete Regel ist die moglichst gleichformige
66
Aufteilung von Punkten (ESP: even split partitioning). Eine andere Regel zielt auf ei-ne Minimierung der Anzahl von Punkten innerhalb des Randbereiches von Partitionenab (RBP: reduced-boundary partitioning). Dies ist deshalb erstrebenswert, da die Par-titionen uberlappende Rander mit einer Breite von ε, dem Radius der Punktnachbar-schaft im zwei-dimensionalen Fall, haben, die auf mehrere Partitionen kopiert werdenund in der globalen Clustervereinigung beachtet werden mussen. Diese Regel kann alsodie Kommunikationskosten reduzieren, wenn eine geringe Anzahl von Punkten in mehre-ren Partitionen vorkommt und somit weniger Kandidaten wahrend der Berechnung derClustervereinigung betrachtet werden mussen.
Jedoch haben die Ansatze Nachteile. So fußt der ESP-Ansatz auf der Annahme, dassdie Laufzeit des DBSCAN-Algorithmus proportional zur Anzahl der Punkte ist; faktischhangt diese jedoch maßgeblich von der Datenverteilung ab. Der RBP-Ansatz hingegenbewertet die Kommunikationskosten des lokalen Clusterings und der globalen Cluster-vereinigung als am teuersten, was jedoch nur fur kleine Datenmengen und eine nichtparallel durchgefuhrte Clustervereinigung stimmt.
Um diesen Nachteilen Herr zu werden schlagen [HTL+14] eine kosten-abhangige Partitio-nierung (CBP: cost-based partitioning) vor (Algorithmus 3.15). Vor Beginn der Partitio-nierung wird SU , das minimal einschließende Rechteck, das alle Punkte des Datensatzesumschließt, in ein Raster mit n×n Zellen mit n = 1/2ε unterteilt. Fur jede der Zellen desRasters wird die Dichte, also die Anzahl der in der Zelle enthaltenen Punkte, berechnet.
Algorithmus 3.15 Kostenbasierte raumliche Aufteilung ([HTL+14] angepasst)
input: SU - mbr, that contains all pointsinput: nPointsOfCells - array containing number of points for each cellinput: maxCost - maximum cost allowed for a celloutput: set of non-overlapping rectangles satisfying SU =
⋃Si
1: procedure CostBasedPartitioning(SU , nPointsOfCells, maxCost)2: taskQueue.add(SU)3: partitions = ∅4: while taskQueue is not empty do5: S = taskQueue.remove()6: if EstimateCost(S, nPointOfCells) > maxCost then7: S1, S2 = CostBasedBinarySplit(S, nPointsOfCells)8: taskQueue.add(S1, S2)9: else
10: partitions.add(S)
11: return partitions
Der Algorithmus (3.15) startet, indem einer abzuarbeitenden Warteschlange taskQueuedas minimal-einschließende Rechteck des gesamten Datensatzes ubergeben wird. DieWarteschlange wird nun so lange abgearbeitet, bis keine Rechtecke mehr in ihr enthaltensind. Zu Beginn der Schleife (Zeile 5) wird ein Element der Warteschlange entnommen
67
und mit Hilfe der Funktion EstimateCost (Algorithmus 3.17) die Kosten der Zelleberechnet. Wenn diese uber einen festen Wert maxCost liegen, wird das Rechteck Smit der Funktion CostBasedBinarySplit (Algorithmus 3.16) in zwei Teil-RechteckeS1, S2 aufgeteilt und der Aufgabenwarteschlange hinzugefugt (Zeile 6-8). Sind die Kostenkleiner, so wird das Rechteck einer Liste von Partitionen hinzufugt (Zeile 9-10). DieseListe wird nach Abbruch der Schleife zuruckgegeben und stellt die Partitionierung desDatensatzes in Form von nicht uberlappenden Rechtecken dar, welche den Datenraumvollstandig abdeckt.
Die Zerteilung eines Rechtecks durch die Funktion CostBasedBinarySplit (Algorith-mus 3.16) erfolgt durch vertikale und horizontale Teilungslinien, die entlang der Zellen-grenzen verlaufen. In den Zeilen 5 bis 12 durchlauft der Algorithmus alle Teilungslinienund wahlt die beiden aus der Teilung resultierenden Rechtecke aus, die die geringsteKostendifferenz haben.
Algorithmus 3.16 Kostenbasierte binare Raumaufteilung ([HTL+14] angepasst)
1: input: S - rectangle to be split2: input: nPointsOfCells - array cotaining number of points for each cell3: output: S1, S2 - split result of input rectangle S4: function CostBasedBinarySplit(S, nPointsOfCells)5: splitLineCandidates = vertical and horizontal lines that split S in two sub-
rectangles6: minCostDiff = ∞7: (S1, S2) = (null, null)8: for each splitLine in splitLineCandidates do9: (S ′1, S
′2) = sub-rectangles corresponding to splitLine
10: S ′1.cost = EstimateCost(S ′1, nPointsOfCells)11: S ′2.cost = EstimateCost(S ′2, nPointsOfCells)12: costDiff = |S ′1.cost− S ′2.cost|13: if costDiff < minCostDiff then14: minCostDiff = costDiff15: (S1, S2) = (S ′1, S
′2)
16: return (S1, S2)
Ein Beispiel fur eine solche Unterteilung ist in Abbildung 3.6 abgebildet. Auf der linkenSeite ist die Punkt-, auf der rechten die Kostenverteilung uber die Zellen dargestellt. DieKandidaten fur vertikale und horizontale Teilungslinien, von denen es in diesem Beispielinsgesamt acht gibt, sind gepunktet gezeichnet und stellen gleichzeitig die Rander derzugrunde liegenden Zellen im Inneren des umschließenden Rechtecks dar. Die gewahlteTrennungslinie, die das Rechteck in zwei Teilrechtecke unterteilt, so dass die Kosten-differenz zwischen den Partitionen minimal ist, ist fett gezeichnet und verlauft entlangder Trennlinie zwischen der ersten und zweiten Spalte. Fur einen maxCost-Wert von104 ware die Unterteilung in Abbildung 3.6 bereits eine gultige finale Partitionierung;
68
fur eine maxCost-Wert von 100 ware eine weitere Unterteilung der rechten Partitiondurchzufuhren.
99
27.6 10.8
10.8 10.8
10.8
10.8
10.8
10.8
Abbildung 3.6: Beispiel fur kostenbasierte Partitionierung [HTL+14]
Die Kostenabschatzung erfolgt mit der Funktion EstimateCost (Algorithmus 3.17). Sieerhalt als Eingabe ein Rechteck sowie ein Array, welches Informationen zu der Punkt-dichte fur jede Zelle enthalt. Die Gesamtkosten fur ein Rechteck setzen sich zusammenaus den Kosten fur jede Zelle, die das Rechteck uberdeckt.
Algorithmus 3.17 Kostenabschatzung fur ein Rechteck ([HTL+14] angepasst)
1: input: S - rectangle, that represents a partition2: input: nPointsOfCells - array containing number of points in each cell3: output: cost - cost of given partition scheme4: function EstimateCost(S, nPointsOfCells)5: cost = 06: for each cell in S do7: nPoints = number of points in cell, gathered with help of numPointsOfCell8: costsOfCell = cost computation using nPoints by Eq. 3.19: cost = cost+ costsOfCell
10: return cost
Die formale Berechnung der Kosten fur ein Zelle erfolgt mit den Formeln in 3.1. Dieerste Formel W (S) besagt, dass sich die Kosten eines Rechtecks S zusammensetzenaus den Kosten fur alle Zellen ci, die von S uberdeckt werden. Die Kosten der einzel-nen Zellen wiederum setzen sich zusammen aus der Anzahl der in der Zelle enthaltenenPunkte Nci und einer Abschatzung der Speicherzugriffskosten DA(Nci), die durch Nach-barschaftsanfragen im DBSCAN-Algorithmus zu erwarten sind. Wenn die Zugriffskostender Einfachheit halber auf 1 gesetzt werden, so sind die Kosten einer Zelle die Anzahl der
69
darin enthaltenen Punkte. Eine detailliertere Beschreibung der Kosten ist in [HTL+14]ausgefuhrt.
W (S) =∑
W (ci) mit S =⋃
ci
W (ci) = Nci ∗DA(Nci)(3.1)
Die Laufzeit der Partitionierung setzt sich aus drei wesentlichen Teilen zusammen, deraufrufenden Funktion, der Funktion zur binaren Rechteck-Teilung und der Kostenschat-zung. Die Laufzeit fur die Kostenabschatzung, vorausgesetzt, dass einfach nur die Sum-me der in einem Raster enthaltenen Punkte gebildet wird, betragt im schlechtesten FallO(n)2, wenn ohne Optimierung das ganze Raster durchsucht werden muss. Jedoch istes moglich, aus den Koordinaten des Rechtecks die uberdeckten Zellen des Rasters zuberechnen, so dass in diesem Fall lediglich eine Laufzeit von O(n) benotigt wird. Furbinare Rechteckteilung mussen jeweils fur jede horizontale und vertikale Teilungsliniedie Kosten fur die resultierenden Rechtecke geschatzt werden, so dass eine Laufzeitvon O(4 · n2) fur die optimierte Fassung der Kostenschatzung benotigt wird. Wenn furdie binare Rechteckaufteilung eine Laufzeit von O(n2) angenommen wird, so lasst sichdie rekursive Funktion zur Erzeugung der kostenbasierten Partitionierung mit Hilfe desMaster-Theorems auf eine Laufzeit von Θ(n2) abschatzen.
Partitionierung der Daten
Ziel der Partitionierung ist eine Aufteilung des Datensatzes, damit die Clustering-Auf-gabe auf mehrere Berechnungen verteilt wird, die unabhangig voneinander durchgefuhrtwerden konnen, also keinen Zugriff auf Punkte außerhalb der Partition benotigen. Eineinfaches Beispiel fur eine Partitionierung ist in Abbildung 3.7 dargestellt. Das minimaleinschließende Rechteck des Datenraumes SU wurde hier bereits in zwei Rechtecke S1
und S2 unterteilt. Am Beispiel der Nachbarschaft des Punktes px wird deutlich, dass,wenn eine Partition P1 nur die Punkte aus S1 enthalt, nicht feststellbar ist, ob px einKernpunkt ist, da die Nachbarschaft von px eventuell Punkte aus S2 enthalt. Folglichist es notwendig, Punkte aus benachbarten Rechtecken zu einer Partition hinzuzufugen,um fur jeden Punkt einer Partition die Klasse bestimmen zu konnen.
Zu diesem Zweck wird ein Rechteck Si um ε nach außen erweitert, welches als außeresRechteck von Si (OR - outer rectangle) bezeichnet wird und einen außeren Rand (OM- outer margin) besitzt. Analog wird ein weiteres Rechteck um ε nach innen verkleinert,welches als inneres Rechteck von Si (IR - inner rectangle) mit einem inneren Rand(IM - inner margin) bezeichnet wird. Punkte, die innerhalb von IR liegen, zeichnensich dadurch aus, dass sie fur die Vereinigung der lokalen Cluster nicht mehr betrachtetwerden mussen, da diese außerhalb der Uberlappungsbereiche angrenzender Partitionenliegen.
70
ε ε
S1 S2
OR(S1)
IR(S1)IR(S2)
OR(S2)
px
Abbildung 3.7: Beispiel einer Partitionierung mit ε-Randbereichen [HTL+14]
Insgesamt bildet die Menge aller Rechtecke eine minimal vollstandige Partitionierungs-menge (MCPS: minimum complete partition set). Fur eine Punktmenge DB und eindiese einschließendes Rechteck SU gilt, dass P = {P1, P2, . . . , Pm} ein MCPS von DBist (Abbildung 3.8), wenn fur die Rechtecke S1, S2, . . . , Sm der Durchschnitt Si ∩ Sj =∅ fur i 6= j und ∪mi=1Si = SU ist, wobei Pi = OR(Si) ist.
Fur die Implementierung der Partitionierung ist zuerst ein MapReduce-Job auszufuh-ren, der die Statistiken der Datenverteilung erfasst. In der Map-Funktion wird das mi-nimal einschließende Rechteck des Datensatzes SU in kleine quadratische Zellen mit derKantenlange 2ε aufgeteilt. In der Shuffle-Phase des MapReduce-Frameworks werden diePunkte nun nach den Partitionen, in denen sie enthalten sind, sortiert. Die Reduce-Funktion generiert hieraus ein Profil, welches die Anzahl von Punkten in jeder Zelleenthalt.
Abschließend wird ein MCPS berechnet, welches mit den Algorithmen aus den geschatz-ten Berechnungskosten fur die Datenverteilung abgeleitet wird. Das Ergebnis wird alsDatei (file-partition-index) ausgegeben und enthalt die unteren linken und oberen rech-ten Ecken der Rechtecke des MCPS und bildet so einen Partitionierungsindex, welcherfur die Zuweisungen der Punkte zu Partitionen in Form von Identifikatoren im nachstenSchritt benotigt wird.
71
S0
S3
S5
S2
S1
S4
Abbildung 3.8: Beispiel einer minimal vollstandigen Partitionierungsmenge [HTL+14]
Lokales Clustering
Fur das Clustering der Partitionen wird eine leicht abgewandelte Version des DBSCAN-Algorithmus (Seite 27) verwendet, in der eine Modifikationen in der Suche und Erwei-terung von Clustern vorgenommen wird (Algorithmus 3.18). Es wird fur jeden Punktzusatzlich zum Cluster-Identifikator ein Flag eingefuhrt, welches explizit die Klassifika-tion in Kern-, Rand- und Rauschpunkte enthalt und eine spatere Unterscheidung derPunkte ermoglicht.
Die erste Anderung findet sich in Zeile 4, in welcher der Rauschpunkt keinen Cluster-identifikator zugewiesen bekommt, der ihn implizit als Rauschpunkt identifiziert, sondernexplizit ein Flag gesetzt wird, dass den Punkt explizit als Rauschpunkt ausweist. Eineweitere kleine Anderung findet sich in Zeile 8, in der fur einen Punkt mit einer aus-reichend großen Nachbarschaft das Flag ’CORE’ gesetzt wird, um ihn als Kernpunktzu markieren. Die großte Anderung findet sich jedoch in der Clusterweiterung in denZeilen 10 bis 22. So wird zum einen bei Punkten, die uber die Nachbarschaftabfrageerreicht wurden, explizit uberpruft, ob diese noch nicht besucht worden sind (’UNCLAS-SIFIED’) oder bereits als Rauschpunkte (’NOISE’) markiert wurden. Zum anderen wirdfur erreichte unklassifizierte Punkte, die nun ihrerseits eine Abfrage starten, ein Flag’CORE’ gesetzt (Zeile 16), wenn die Große der Nachbarschaft den Schwellenwert uber-schreitet, und ein Flag ’BORDER’ gesetzt, wenn dies nicht der Fall ist (Zeile 19). DieLaufzeitkomplexitat des modifizierten DBSCAN-Algorithmus liegt, wie beim normalenDBSCAN-Algorithmus bei O(n · log(n)).
72
Algorithmus 3.18 Modified DBSCAN - Clustererweiterung ([HTL+14] angepasst)
input: points - dataset to be clusteredinput: point - starting point for cluster expansioninput: clusterId - identificator of the current clusterinput: ε - size of the neighborhoodinput: minPts - points required for a core pointoutput: boolean - indicates, whether cluster was found
1: procedure ExpandCluster(points, point, clusterId, ε, minPts)2: seeds = points.regionQuery(point, eps)3: if seeds.size < minPts then4: point.setFlag(NOISE )5: return FALSE6: else7: points.changeClusterIds(seeds, clusterId)8: points.setFlag(CORE )9: seeds.delete(point)
10: while seeds 6= empty do11: currentPoint = seeds.first()12: if currentPoint.clusterId == UNCLASSIFIED then13: currentPoint.setClusterId(clusterId)14: result = points.regionQuery(currentPoint, ε)15: if result.size ≥ minPts then16: currentPoint.flag == CORE17: seeds.append(resultPoint)18: else19: currentPoint.flag == BORDER
20: else if currentPoint.flag == NOISE then21: currentPoint.setClusterId(clusterId)22: currentPoint.setFlag(BORDER)
23: seeds.delete(currentPoint)
24: return TRUE;
Das eigentliche Clustering findet in einem eigenen MapReduce-Auftrag statt. Zuerstwird mittels der Map-Funktion (Algorithmus 3.19) der Datenbestand auf verschiedenePartitionen verteilt.
Dieses geschieht, indem die eingegebenen Schlussel-Wert-Paare, die keinen Schlussel undals Wert den Punkt enthalten, mit dem Partitions-Identifikator versehen und ausgegebenwerden.
Der Partitionierungsindex partitionIndex wird zu Beginn der Ausfuhrung des Map-Tasksaus den Ausgabedaten des ersten Schrittes, der Datenpartitionierung, erzeugt. Fur jeden
73
Algorithmus 3.19 Lokales Clustering([HTL+14] angepasst)
input: - 〈key : null, value : point〉output: key - partition id, value - point object
1: procedure Map(key, value)2: partitionIndex = readFromFile(partition-index-file)3: partitionIDs = getPartitionIDsForPoint(partitionIndex, point)4: for each partitionId in partitionIDs do5: Output (〈 partitionId, point 〉)
input: key - partitionId, value - all points in partition P(partitionId)input: context - minPts: points required for core points, ε: neighborhood size
6: procedure Reduce(key, value)7: rTree = createRTree(value)8: S = rectangle of partitionId9: for each unvisited p inside of S do
10: cluster points with algorithm 3.18 using rTree
11: for each p in P do12: OutputToFile(〈p, (p.clusterId, p.f lag)〉, file-results-partitionID)
13: for each p in P do14: if p.flag == CORE and p inside IM(S) then15: OutputToFile (〈p, (p.clusterId, p.f lag)〉, file-AP-partitionID)16: else if p.flag != NOISE and p inside OM(S) then17: OutputToFile (〈p, (p.clusterId, p.f lag)〉, file-BP-partitionID)
Punkt point kann uber den Index partitionIndex mit der Funktion getPartititionIDsFor-Point aus den Koordinaten der Partitionierungsrechteckee bestimmt werden, in welchemRechteck und somit in welcher Partitionen dieser enthalten ist. Daraus wird fur jede ent-haltene Partition ein Schlussel-Wert-Paar 〈partitionId, point〉 erzeugt und ausgegeben.Nach Abschluss der Map-Phase werden die Schlussel-Wert-Paare dann vom MapReduce-Framework gemischt und nach den Partitions-Identifikatoren gruppiert. Punkte mit demgleichen Identifikator werden an die Reduce-Funktion ubergeben, in welcher das lokaleClustering durchgefuhrt wird.
Das Clustering erfolgt in der Reduce-Phase (Algorithmus 3.19) mit dem modifiziertenDBSCAN-Algorithmus (3.18). Fur eine effiziente Unterstutzung der Nachbarschaftsan-fragen verwendet der Algorithmus einen R-Baum als raumlichen Index, der alle Punkteder Partition enthalt.
Die Ergebnisse des Clustering einer Partition werden in drei verschiedene Ausgabeda-teien geschrieben. Das Gesamtergebnisse, alle Punkte innerhalb von S, werden eine Da-tei ’file-results-partitionID’ geschrieben. Kernpunkte, die innerhalb des inneren Randes(S − IR(S)) liegen, werden in eine Datei ’file-AP-partitionID’ geschrieben, Kern- und
74
Randpunkte im außeren Rand (OR(S) − S) in eine Datei ’file-BP-partitionID’. Ledig-lich diese Bereiche, die von anderen angrenzenden Partitionen uberdeckt werden oderandere angrenzende Partitionen uberdecken, sind zu betrachten, wenn die Vereinigungder lokalen Cluster durchgefuhrt wird. Außerdem werden die Partitions-Identifikatorenin die Cluster-Identifikatoren eingearbeitet, so dass alle lokalen Cluster global eindeutigeIdentifikatoren besitzen.
Globale Clustervereinigung
Um das Clustering zu vervollstandigen ist eine Vereingung der lokalen Clusterings in einglobales Clustering notwendig. Grob lasst sich dieser Schritt aufteilen in die Erzeugungeiner Vereinigungs-Abbildung und das Umbenennen der Daten. Fur die Vereinigungs-Abbildung ist es zunachst notwendig, alle Partitionspaare zu finden, die eine gemeinsameSchnittmenge besitzen. Ziel ist es, fur zwei Partitionen P1 und P2 alle Paare lokaler Clu-ster C1 ⊂ P1 und C2 ⊂ P2 zu finden, so dass C1 und C2 dem selben globalen Clusterangehoren. Anschließend werden die globalen Cluster berechnet und eine Abbildung be-stimmt, die die lokalen Cluster auf globale Cluster abbildet. Hierbei gilt es festzuhalten,dass ein Cluster C1 mit einem Cluster C2 vereinigt werden kann, wenn es einen Punktp ∈ C1 ∩ C2 gibt, wobei p ein Kernpunkt in C1 oder C2 ist. p wird in diesem Kontextauch als Vereinigungs-Punkt von C1 oder C2 bezeichnet. Auf dieser Grundlage ist eseinfach, alle Vereinigungspunkte der Partitionen P1 und P2 zu bestimmen, zumal zumAbschluss des lokalen Clusterings bereits alle Punkte innerhalb der Randbereiche geson-dert als Kandidaten fur die Vereinigung von Clustern ausgegeben werden. Es ist lediglichzu uberprufen, dass einer der Punkte ein Kernpunkt in P1 oder P2 ist. Diese Kandidatenlassen sich relativ einfach uber den Join (AP1 ∩BP2) ∪ (AP2 ∩BP1) bestimmen.
Weiterhin gilt, dass die Vereinigung lokaler Cluster zwischen zwei uberlappenden Par-titionen unabhangig von allen anderen Partitionen ist und somit parallel ausgefuhrtwerden kann. Sobald alle Paare zu vereinigender lokaler Cluster bekannt sind, ist eseinfach, mit einem graph-basierten Algorithmus die globalen Cluster zu berechnen.
Diese Abbildungen lassen sich durch einen MapReduce-Job berechnen der aus der Map-Funktion in Algorithmus 3.20 und der Reduce-Funktion in Algorithmus 3.20 besteht. Inder Map-Funktion (3.20) fur zwei Partitionen A und B werden zunachst die jeweiligenListen mit Kernpunkten im inneren Rand und Kern- und Randpunkten des außerenRandes geladen. Mit diesen wird uber den bereits zuvor beschrieben Join in Zeile 6 dieMenge der zu vereinigenden Cluster-Paare berechnet. Die ausgegebenen Schlussel-Wert-Paare enthalten keinen Schlussel, damit diese zum Aufbau der globalen Vereinigungs-Abbildung nur an einen Reducer ubergeben werden.
Eine beispielhafte Situation ist in Abbildung 3.9 dargestellt, anhand derer der Aufbaueines Vereinigungs-Mappings verdeutlicht werden soll. Nachdem fur jede Partition derinnere Rand (S − OR(S)) und der außere Rand (OR(S) − S) eingelesen wurde, gilt es
75
Algorithmus 3.20 Erzeugung einer Vereinigungs-Abbildung ([HTL+14] angepasst)
1: input: key - partition id, value - partition id2: output: key - null, value - pair of cluster ids3: procedure Map(key, value)4: AP1 = read file-AP-key5: BP1 = read file-BP-key6: AP2 = read file-AP-value7: BP2 = read file-BP-value8: for each p ∈ (AP1 ∩BP2) ∪ (AP2 ∩BP1) do9: A.clusterId = p.clusterId in partition A
10: B.clusterId = p.clusterId in partition B11: Output (〈null, (A.clusterId, B.clusterId)〉)
input: key - null, value - pair of cluster idsoutput: key - local cluster id, value - global cluster id
12: procedure Reduce(key, value)13: initialize empty graph G14: for each item in values do15: if vertex item.A.clusterId is not in G then16: G.addVertex(item.A.clusterId)
17: if vertex item.B.clusterId is not in G then18: G.addVertex(item.B.clusterId)
19: if edge (item.A.clusterId, item.B.clusterId) is not in G then20: G.addEdge((item.A.clusterId, item.B.clusterId))
21: for each connected component C in G do22: globalClusterId = next unique global cluster id23: for each vertex localClusterId in C do24: Output 〈key=localClusterId, value=globalClusterId〉25: for each localClusterId not in G do26: globalClusterId = next unique global cluster id27: Output (〈localClusterId, globalClusterId〉)
die Schnittmenge (AP1 ∩BP2) ∪ (AP2 ∩BP1) zu berechnen. Hierbei ist (AP1 ∩BP2) ={p1, p2, p3, p4} und (AP2 ∩BP1) = {p5, p6, p7}, so dass insgesamt (AP1 ∩BP2) ∪ (AP2 ∩BP1) = {p1, p2, p3, p4} ∪ {p5, p6, p7} ist. Fur jeden Punkt diese Menge wird nun einSchlussel-Wert-Paar ausgegeben, welches als Wert das Paar der Clusteridentifikatorenenthalt, dem der Punkt in der jeweiligen Partition angehort. Fur die Punkte p1 . . . p7ergeben sich so die folgenden Paare:
• 〈 null, (S1 1, S2 1) 〉
• 〈 null, (S1 1, S2 1) 〉
76
• 〈 null, (S1 2, S2 1) 〉
• 〈 null, (S1 2, S2 1) 〉
• 〈 null, (S2 1, S1 2) 〉
• 〈 null, (S2 1, S1 2) 〉
• 〈 null, (S2 1, S1 1) 〉
ε ε
S1 S2
OR(S1)
IR(S1)IR(S2)
OR(S2)
minPts=3p1
p2
p3
p4
p5
p6
p7
S1_1
S1_2
S2_1
ε
Abbildung 3.9: Beispiel eines Vereinigungs-Mappings
Der Reducer (3.20) baut aus diesen Abbildungen einen ungerichteten Graph auf. JederCluster-Identifikator in den Schlussel-Wert-Paaren wird durch einen Knoten im Graphreprasentiert (Zeile 4-7), jedes ubergebene Paar von Cluster-Identifikatoren wird durcheine Kante im Graph dargestellt (Zeile 8-9). Aus dem Graph lassen sich schließlich dieglobalen Cluster einfach ableiten, da jeder zusammenhangende Teilgraph einem globalenCluster entspricht. Fur jeden zusammenhangenden Teilgraphen werden Schlussel-Wert-Paare ausgegeben, die die Identifikatoren der lokalen Cluster auf einen globalen Identi-fikator abbilden (Zeile 10-13). Außerdem werden auch fur jeden alleinstehenden Clusterein Schlussel-Wert-Paar ausgegeben, welches den lokalen Cluster-Identifikator auf einenglobalen Identifikator abbildet (Zeile 14-16).
Aus den zuvor generierten Schlussel-Wert-Paaren wird nun nach Algorithmus 3.20 einungerichteter Graph aufgebaut, der in Abbildung 3.10 dargestellt ist. Folglich gehorenalle Punkte aus beiden Partitionen zum selben Cluster, da die jeweiligen lokalen Clustereine zusammenhangende Komponente im Graphen bilden.
77
S1_1
S1_2
S2_1
Abbildung 3.10: Graph-Reprasentation des Vereinigungs-Mappings
Algorithmus 3.21 Umbenennung der Daten ([HTL+14] angepasst)
input: key - point object, value - cluster id and classfication flaginput: mergeMapping - stored in a hash mapoutput: key - point object, value - cluster id and classification flag
1: procedure Map(key, value)2: globalClusterId = mergeMapping [p.clusterId]3: p.clusterId = globalClusterId4: Output (〈p, (p.clusterId, p.flag)〉)
input: key - point p, value: set of (clusterId, flag)-pairsoutput: key - point p, value: (clusterId, flag)-pair
5: procedure Reduce(key, value)6: clusterId = null7: flag = NOISE8: for each pair in value do9: if clusterId is null then
10: clusterId = pair.p.clusterId
11: if pair.p.flag == BORDER then12: flag = BORDER13: else if pair.p.flag == CORE then14: flag == CORE15: break16: Output (〈p, (clusterId, flag)〉)
Um das finale Ergebnis zu erhalten mussen die lokalen Cluster-Identifikatoren aller Punk-te substituiert werden und der Typ dieser bestimmt werden. Auch dies wird durch einenMapReduce-Job gelost. Die Eingabe fur den Job besteht aus den Dateien ’file-results-partitionId’, welche die vollstandigen Ergebnisse der jeweiligen lokalen Clusterings ent-halt. In der Map-Phase (Algorithmus 3.21) werden die lokalen Cluster-Identifikatoren mitHilfe der Vereinigungs-Abbildung ersetzt (Zeile 2-3) und der Punkt zusammen mit dem
78
finalen Cluster-Identifikator und dem Typ, der im lokalen Clustering bestimmt wurde,ausgegeben.
Fur Punkte in den Randbereichen gilt hierbei, dass diese an mehreren lokalen Clusteringsbeteiligt gewesen sein und somit verschiedene Typen besitzen konnen; das Ergebnis derMap-Phase kann also Paare mit gleichem Schlussel jedoch verschiedenen Werten liefern.Durch die Shuffle-Phase werden die Paare nach dem Schlussel gruppiert, so dass sichDuplikate leicht identifizieren lassen. Fur diese ist im Detail der Typ zu bestimmen. DieTypisierung folgt einer einfachen Regel: der Typ eines Punktes wird durch die signifi-kanteste gefundene Klassifikation definiert. Diese ist absteigend geordnet nach ’CORE’,’BORDER’ und ’NOISE’. Punkte ohne Duplikate werden direkt ausgegeben. Die so pro-duzierte Menge von Schlussel-Wert-Paaren reprasentiert nun das finale Ergebnis undsomit das globale Clustering.
3.2.4 Shared-memory SLINK (SHRINK)
Der SHRINK-Algorithmus [HPA+12] ist ein paralleler Algorithmus zur Berechnung eineshierarchischen Clusterings, der fur Systeme mit gemeinsamen Speicher entworfen wurde.Die Grundidee des Algorithmus besteht in einer Aufteilung des eigentlichen Problems,der Erzeugung eines globalen hierarchischen Clusterings, in uberlappende Teilproblemeannahernd gleicher Große, die schließlich zu einer Gesamtlosung vereinigt werden. Hierfurwird eine Partitionierung des Datenraumes vorgenommen und auf den Partitionen miteiner modifizierten Version des SLINK-Algorithmus [Sib73] das jeweilige hierarchischeClustering in Form eines Dendrogramms bestimmt. Die Gesamtlosung wird abschließendaus den uberlappenden Teillosungen kombiniert, indem die Dendrogramme der lokalenClusterings zu einem globalen Dendrogramm vereinigt werden.
Algorithmus 3.22 Ablauf des SHRINK-Algorithmus ([HPA+12] uberarbeitet)
input: D - dataset to be clustered, p - number of partitionsoutput: complete dendrogram of dataset D
1: procedure Shrink(D, p)2: partition D into p subsets S = {S1, S2, . . . , Sp}3: let M be an empty set4: for all (Si, Sj) ∈ S|i 6= j in parallel do5: dendrogram d = Mod-Slink(Si ∪ Sj)6: add dendrogram d to set M
7: repeat8: merge dendrograms in M pairwise as shown in 3.11 with the function Merge9: until M contains only one dendrogram in parallel
10: return remaining dendrogram in M
Zunachst werden in Algorithmus 3.22 die Teilmengen S des Datensatzes gebildet. Diese
79
entstehen durch die Aufteilung des Datenbestandes in p Teile. Jedes Paar (Si, Sj) ∈ Sfur i 6= j wird einem separaten Thread zugewiesen, der fur die Punktmenge ein hier-archisches Clustering berechnet (Zeile 5-7). Fur das Clustering wird eine modifizierteVariante des SLINK-Algorithmus verwendet. Diese unterscheidet sich von dem Originalin drei Punkten. Als erstes werden die fur Distanzberechnungen verwendeten Punktemitverfolgt und gespeichert. Dann werden bei gleichen Distanzen die Identifikatoren derDatenpunkte verglichen und der kleinere Identifikator gewahlt. Als Drittes und Letzteswerden die Dendrogramme reprasentiert durch eine Folge von Vereinigungen von nach-sten Clusterpaaren. In Zeile 8-10 werden die Dendrogramme der Partitionen-Paare daus der Liste M in ein einziges Dendrogramm zusammengefuhrt, das die Originallosungdarstellt. Die Kombination erfolgt, indem uber die Clustervereinigungen in aufsteigenderDistanz iteriert wird und die Vereinigungen ubernommen werden, die Datenpunkte inverschiedenen Clustern vereinigen; Vereinigungen hingegen, die Punkte zusammenfuh-ren, welche bereits demselben Cluster angehoren, werden verworfen. Die Reihenfolge, inder die Teilprobleme zusammengefuhrt werden, ist hierbei nicht von Bedeutung.
d1 d2 d3 d4 d5 d6
d1 d3 d5
d1
d1
Abbildung 3.11: Beispiel fur den Ablauf der Vereinigung sechs lokaler Dendrogrammezu einem globalen Dendrogramm (nach [HPA+12])
Die Berechnung der Dendrogramme erfolgt uber den Modified-SLINK-Algorithmus (Al-gorithmus 3.23). Zu Beginn werden drei Arrays erzeugt, welche das Endergebnis des Clu-sterings sowie Zwischenergebnisse speichern. Die Arrays result und M enthalten jeweils3-Tupel der Form (Punkt, Punkt,Distanz), wobei ein 3-Tupel eine Clustervereinigungreprasentiert; das Array result wird fur jeden Punkt mit Eintragen (−,−,∞), das ArrayM mit Eintragen (−,−,−) initialisiert. Das Array clusterId enthalt fur einen Punkt dieInformation, zu welchem welchem Cluster er gehort; reprasentiert wird ein Cluster durchden Punkt mit der kleinsten ID, so dass Punkte eines Clusters schlussendlich auf diesenzeigen. Initialisiert wird dieses so, dass jeder Punkt sich selber als Vereinigungspartnerbesitzt (Zeile 4-6). Der Algorithmus durchlauft nun die ganze Punktmenge (Zeile 7-20),wobei die Position des Punktes in der Punktliste gleichzeitig seine globale ID darstellt.
80
Fur jeden Punkt i ∈ D wird die Distanz zu jedem anderen Punkt j in der Liste M in derForm (D[i], D[j], d(D[i], D[j])) gespeichert (Zeile 8-9). d(D[j], D[i]) reprasentiert hierbeiimplizit uber die Distanz die Hohe, in der die Vereinigung im Dendrogramm passiert.Es erfolgen jetzt zwei Durchlaufe uber alle Punkte j ∈ D\{i} (Zeilen 10-17 und 18-20).Zuerst wird uberpruft, ob die Distanz der bisherigen Vereinigung der Punkte i und jin result[j] kleiner ist als die zuvor berechnete in M [j]. Wenn jedoch die Distanz derVereinigung von i und j großer ist als die berechnete Vereinigung des Vorgangers vonj, so wird dessen Zwischenergebnis M [j] auf das bisherige Ergebnis result[j] gesetzt(Zeile 12-13). Anschließend wird das Ergebnis fur j in result[j] auf M [j] gesetzt undder Vorganger von j auf i gesetzt (Zeile 14-15). Wenn weiterhin die Vereinigung von iund j in M [j] eine geringere Distanz als der Vorganger von j besitzt, so wird das Er-gebnis von M [clusterId [j]] auf M [j] gesetzt. In einer weiteren Schleife (Zeile 18-20) wirdnun getestet, ob die Distanz der Clustervereinigung von Punkt j großer ist als die desVorganger von j. Ist dieses der Fall, so wird der Vorganger von j auf i gesetzt. Zuletztwerden die Vereinigungen der Cluster, die in result gespeichert sind, nach aufsteigenderDistanz sortiert zuruckgegeben (Zeile 21-22).
Algorithmus 3.23 Modified SLINK ([HPA+12] uberarbeitet
1: input: D - dataset of points2: output: result: list of cluster merges sorted by increasing height3: procedure Mod-Slink(D)4: initialize array clusterId [i] with i for each i ∈ D5: initialize array result with (−,−,∞) for each i ∈ D6: initialize array M with (−,−,−) for each i ∈ D7: for i← 1 to |D| − 1 do8: for j ← 0 to i− 1 do9: M [j]← (D[j], D[i], d(D[j], D[i])), at distance d(D[j], D[i])
10: for j ← 0 to i− 1 do11: if result[j] has a higher distance/id than M [j] then12: if result[j] has a lower distance/id than M [clusterId [j]] then13: M [clusterId [j]]← result[j]
14: result[j]←M [j]15: clusterId[j]← i16: else if M [j] has a lower distance/id than M [clusterId[j]] then17: M [clusterId[j]]←M [j]
18: for j ← 0 to i− 1 do19: if result[j] has a higher distance/id than result[clusterId[j]] then20: clusterId[j]← i
21: Sort the merges of result by increasing distance22: return result
Der Algorithmus zur Vereinigung zweier Dendrogramme (Algorithmus 3.24) nutzt imKern eine Union-Find Struktur, um die Cluster-Zugehorigkeit fur jeden Datenpunkt zu
81
verwalten. Zu Beginn werden zwei Datenstrukturen initialisiert, eine Liste M3, in wel-cher die Folge der Clustervereinigungen gespeichert wird und eine Union-Find-Struktur,die die Clusterzuordnungen der Datenpunkte festhalt. Fur die Union-Find-Struktur wirdzudem angenommen, dass eine Vereinigung nur erfolgreich ist, wenn die beiden zu verei-nigenden Punkte in verschiedenen Clustern liegen. Das Verfahren beginnt, indem aus denVereinigungslisten der Cluster M1 und M2 die Vereinigungen mit der kleinsten Distanzzusammen mit den vereinigten Punkten ausgewahlt werden. Zuvor ist zu uberprufen, obDuplikate vorhanden sind, Vereinigungen also, die in beiden Vereinigungslisten enthal-ten sind. Wenn Duplikate vorhanden sind, ist eines der beiden Vorkommen zu entfernen.Wenn die Distanz h1 ∈ m1 nun kleiner als h2 ∈ m2 ist, so wird m1 zu M3 hinzugefugt,vorausgesetzt, dass die Cluster u1, v1 ∈ m1 in der Union-Find-Struktur verschiedenenClustern zugeordnet sind; m1 wird anschließend auf die Vereinigung mit der nachstkleinsten Distanz gesetzt. Das Vorgehen ist analog fur den Fall, dass h1 keine geringereHohe als h2 aufweist. Das Vorgehen wird solange fortgesetzt, wie M1 und M2 verbleiben-de Vereinigungen haben. Sobald nur noch eine Liste Vereinigungen enthalt werden diesezu M3 hinzugefugt, sofern diese in verschiedenen Clustern enthalten sind. Abschließendwird als Ergebnis die neue Liste der Vereinigungen M3 zuruckgegeben.
Algorithmus 3.24 Vereinigung zweier Dendrogramme ([HPA+12] angepasst)
1: input: M1,M2 - dendrograms2: output: M3 - merged dendrogram3: procedure Merge((M1,M2))4: Initialize M3 to be empty5: Initialize Union-Find data structure with each unique point from M1,M2
6: Let m1 = (u1, v1, h1) be the data points and distance of the lowest merge in M1
7: Let m2 = (u2, v2, h2) be the data points and distance of the lowest merge in M2
8: while M1 and M2 have merges remaining do9: if h1 < h2 then
10: if union(u1, v1) succeeds then11: Add m1 to M3
12: Let m1 = (u1, v1, h1) be the next lowest merge in M1
13: else14: if union(u2, v2) succeeds then15: Add m2 to M3
16: Let m2 = (u2, v2, h2) be the next lowest merge in M2
17: Add remaining merges (u, v, h) of M1 or M2 to M3 as long as union(u, v) succeeds18: return M3
Die Laufzeit des SHRINK-Algorithmus setzt sich aus drei wesentlichen Teilen zusammen,der Partitionierung, dem Clustering und der Vereinigung. Hendrix et al. schatzen dieLaufzeit fur die Partitonierung mit O( n√
p) ab, wobei p die Anzahl der Prozessoren, bzw.
Threads ist. Die Laufzeit fur das Clustering mit dem ModSLINK-Algorithmus betragtO(n2
0) mit n0 als Anzahl der Punkte pro Partition. In diesem wird eine außere Schleife
82
(Zeilen 7-20) n0-mal durchlaufen, die beiden inneren Schleifen (Zeilen 8-9 sowie 10-20)werden ebenso maximal n0-mal und benotigen jeweils nur konstante Zeit. Das Sortierender Vereinigungen nach der Distanz wird in O(n0 ∗ log(n0)) ausgefuhrt. Insgesamt kanndas Clustering somit in O(n
2
p) ausgefuhrt werden. Die Vereinigung zweier Dendrogramme
wird mit O(n ∗ α(n)) abgeschatzt, wobei α die inverse Ackermann-Funktion ist. Da dieVereinigung der Dendrogramme in den Zeile 7-9 jeweils paarweise in Form eines binarenBaumes erfolgt, benotigt diese eine Laufzeit von O(log(p)), so dass sich fur die gesamteDendrogrammvereinigung eine Laufzeit von O(n ∗ log(p)) ergibt. Insgesamt betragt dieLaufzeitkomplexitat somit nach [HPA+12] O(n
2
p+ n√
p+ n ∗ α(n) ∗ log(p). Diese lasst
sich sogar auf O(n ∗ α(n) ∗ log(p)) reduzieren, indem p ∼ nlog(n)
Prozessoren verwendetwerden.
Beispiel
Um die Funktionsweise des SHRINK-Algorithmus zu verdeutlichen ist in Abbildung 3.12ein Beispiel fur ein solches abgebildet. Erzeugt werden soll das hierarchische Clusteringeines Datensatzes, bestehend aus vier Punkten, der in drei Partitionen aufgeteilt ist.
Im oberen Teil ist zunachst der Datenraum mit den Datenpunkten und Partitionierungenauf der linken Seite abgebildet, auf der rechten Seite die Resultate der drei moglichenClusterings von paarweise disjunkten Partitionen in Form einer Liste. Wie bereits zuvorin der Beschreibung des Algorithmus erwahnt, ist die Reihenfolge, in der Teilergebnisseder paarweisen Clusterings zusammengefugt werden, irrelevant. In diesem Beispiel wirdzunachst das Ergebnis A mit B vereinigt, anschließend {A,B} mit C. Fur die ersteVereinigung werden die Vereinigungs-Listen aus A (M1) und B (M2) verwendet undzusatzlich eine Union-Find-Struktur fur die Datenpunkte, die in M1 und M2 enthaltensind, initialisiert. Algorithmus 3.24 folgend, werden m1 und m2 mit den Vereinigungeninitialisiert, die in den jeweiligen Teilergebnissen die kleinste Distanz besitzen. Da m1 <m2 wird die Vereinigung (2, 3, 0.5) gewahlt und zu M3 hinzugefugt. Folglich wird auchdie Union-Find-Struktur aktualisiert, um zu reprasentieren, dass die Punkte 2 und 3 demgleichen Cluster angehoren. m1 wird nun auf die Vereinigung mit der nachst großerenDistanz gesetzt. Auch im zweitem Schritt ist m1 < m2 und es wird m1 zu M3 hinzugefugtund die Union-Find-Struktur aktualisiert. Da M1 nun keine Vereinigungen mehr enthaltwerden nun die verbleibenden aus M2 zu M3 hinzugefugt, sofern sich die Punkte, dievereinigt werden, in verschiedenen Clustern befinden. In der zweiten Vereinigung werdennun die Vereinigungs-Listen aus dem vorherigen Schritt {A,B} sowie des Ergebnisses Caus dem Clustering der Partitionen D2∪D3 zusammengefuhrt, um das finale Clusteringzu erhalten. Auch hier werden m1 und m2 mit den Vereinigungen mit kleinster Distanzaus M1 und M2 initialisiert. Hier ist sofort zu sehen, dass die erste Vereinigung in M1
und M2 identisch ist; eine der beiden ist zu eliminieren. In diesem Beispiel wird dieVereinigung aus M2 entfernt. Die Vereinigungen werden nun nach dem bekannten Musterzu M3 hinzugefugt. Nachdem die Vereinigung (1, {2, 3}, 1.1) zu M3 hinzugefugt wurde,
83
1
23
4
A = MOD-SLINK(D1 ᴜ D2): [(2, 3, 0.5), (1, {2,3}, 1.1)]
B = MOD-SLINK(D1 ᴜ D3): [(1, 4, 2.1)]
C = MOD-SLINK(D2 ᴜ D3): [(2, 3, 0.5), ({2,3}, 4, 1)]
MERGE(A,B)
m1(u1, v1, h1) = (2, 3, 0.5)
m2(u2, v2, h2) = (1, 4, 2.1)M3 = [(2, 3, 0.5)]
m1(u1, v1, h1) = (1, {2,3}, 1.1)
m2(u2, v2, h2) = (1, 4, 2.1)M3 = [(2, 3, 0.5), (1, {2, 3}, 1.1)]
da A leer, Rest von B zu M hinzufügen
M3 = [(2, 3, 0.5), (1, {2, 3}, 1.1), (1, 4, 2.1)]
MERGE({A,B}, C) M2 = [(2, 3, 0.5), ({2, 3},4, 1)]M1 = [(2, 3, 0.5), (1, {2, 3}, 1.1), (1, 4, 2.1)]
m1(u1, v1, h1) = (2, 3, 0.5)
m2(u2, v2, h2) = ({2, 3}, 4, 1)M3 = [(2, 3, 0.5)]
m1(u1, v1, h1) = (1, {2, 3}, 1.1)
m2(u2, v2, h2) = ({2, 3}, 4, 1)M3 = [(2, 3, 0.5), ({2, 3}, 4, 1)]
M3 = [(2, 3, 0.5), ({2, 3}, 4, 1), (1, {2, 3}, 1.1)]
1234
1224
1234
1114
1234
1111
1234
1224
1234
1222
1234
1111
1 2 3 4
D1
D2
D3
M1 = [(2, 3, 0.5), (1, {2, 3}, 1.1)] M2 = [(1, 4, 2.1)]
m1(u1, v1, h1) = (1, {2, 3}, 1.1)
m2(u2, v2, h2) = (1, 4, 2.1)
Abbildung 3.12: SHRINK-Algorithmus - Beispiel
lasst aus der mitgefuhrten Union-Find-Struktur ablesen, dass alle Datenpunkte demselben Cluster angehoren. Die verbleibende Vereinigung, (1, 4, 2.1) wird abschließend
84
nicht mehr zu M3 hinzugefugt, da die Punkte 1 und 4 bereits dem gleichen Clusterangehoren.
M3 enthalt nun das finale Clustering des Datensatzes, dargestellt in Form einer Abfolgevon Vereinigungen, welches am unteren Rand von Abbildung 3.12 als Dendrogrammdargestellt ist.
3.2.5 MapReduce k-Means Clustering
Auch der sequentielle k-Means-Algorithmus (Abschnitt 2.3.2) ist nicht in der Lage, großeDatenmengen effizient zu clustern, da der Hauptspeicher zu klein ist und alleine dasEinlesen der Daten zu lange dauern wurde. [ZMH09] stellen eine Implementierung desk-Means-Algorithmus fur das MapReduce-Framework vor, der mit diesen Anforderungenumgehen kann. Das zugrundeliegende Prinzip des Algorithmus ist, dass die Zuweisungvon Punkten zum nachsten Clusterschwerpunkt unabhangig von der Berechnung einesneuen Schwerpunktes durchgefuhrt wird. Zusatzlich kann die Zuweisung zum nachstenClusterschwerpunkt parallel ausgefuhrt werden, da unter den Datenpunkten keine Ab-hangigkeiten vorhanden sind; jeder Punkt kann individuell dem nachsten Cluster zu-gewiesen werden. Eine Parallelisierung der Berechnung der neuen Schwerpunkte kannebenso erreicht werden, indem jeder Clusterschwerpunkt unabhangig von den anderenberechnet wird. Erreichen lasst sich dies, indem die Sortier-Fahigkeit des MapReduce-Frameworks ausgenutzt und Schlussel-Wert-Paare derart sortiert werden, dass diese nachihrem Schlussel gruppiert werden. Das iterative Vorgehen des k-Means-Algorithmus wirdin MapReduce durch mehrere Durchlaufe des Prozesses erreicht, eine wiederholte Aus-fuhrung der Map-, Combine- und Reduce-Phase, wobei als Eingabe immer die Schlussel-Wert-Paare und Cluster-Schwerpunkte der vorherigen Iteration genutzt werden.
Ablauf
Der Ablauf der MapReduce-Implementierung ist in Abbildung 3.13 dargestellt. Wennein Task fur einen Datensatz und eine Menge von vorgegebenen Centroiden gestartetwird erfolgt zuerst eine Unterteilung des Datensatzes in Teilstucke. Diese werden vonden Mappern zusammen mit den Centroiden als Eingabe verwendet, um darauf parallelfur jeden Punkt des Datensatzes zu berechnen, welchem Clusterschwerpunkt dieser amnachsten ist.
Diese Zuordnung wird als Schlussel-Wert-Paar ausgegeben und auf demselben Rechen-knoten durch die Combine-Funktion lokal zusammengefasst, quasi die lokalen Cluster-schwerpunkte jeder Datenpartition berechnet. Im Reduce-Schritt werden diese Zwi-schenergebnisse schließlich fur jeden Cluster mit der Reduce-Funktion zusammengefasst,um die globalen Clusterschwerpunkte zu erhalten. Analog zum klassichen k-Means-
85
Shard 1
Shard 2
Shard 3
Map
Map
Reduce
Reduce
Result
Combine
Combine
Combine
ClusterCentroids
Map
Abbildung 3.13: MapReduce k-Means - Datenfluss
Algorithmus konnen diese neuen Centroide fur einen erneuten MapReduce-Durchlaufverwendet werden.
Map-Funktion
Die Map-Funktion in Algorithmus 3.25 berechnet fur jeden Punkt, welches der nachsteCluster-Schwerpunkt ist und ordnet den Punkt diesem zu.
Algorithmus 3.25 MapReduce-k-Means: Map-Phase ([ZMH09] angepasst)
1: input: key - null, value - point object2: output: key - cluster id, value - point object3: procedure Map(〈key, value〉)4: minDistance = Double.MAX VALUE5: index = −16: for i = 0 to centroids.length do7: distance = computeDistance(value, centroids[i])8: if distance < minDistance then9: minDistance = distance
10: index = i11: Output 〈index, value〉
Fur ein eingegebenes Schlussel-Wert-Paar 〈null, point〉, bei dem der Schlussel nicht be-
86
trachtet wird und der Wert die Reprasentation eines Punktes ist, wird uber eine Schleifedie Distanz zu jedem Cluster-Schwerpunkt berechnet und der nachste in der Variableindex festgehalten (Zeile 4-8). Die so berechnete Cluster-Zuordnung wird nun ausgege-ben in Form eines Schlussel-Wert-Paares 〈clusterID, point〉 (Zeile 9-11).
Kombinations-Funktion
Die Combine-Funktion (Algorithmus 3.26) fuhrt bereits lokal eine Reduzierung der Schlu-ssel-Wert-Paare durch, aquivalent zur Reduce-Funktion. Die lokal-generierten Paare wer-den nach den Cluster-Identifikatoren gruppiert und zusammengefasst. Hierfur wird zumeinen ein Array mit so vielen Feldern verwendet wie die Dimensionalitat der Daten istund ein Zahler fur die Anzahl der Punkte.
Algorithmus 3.26 MapReduce-k-Means: Combine-Phase ([ZMH09] angepasst)
1: input: key - cluster id, value - set of points2: output: key - cluster id, value - number of cluster points and centroid coordinates3: procedure Combine(〈key, value〉)4: init values[dimCount]5: init pointCount = 06: while value.hasNext() do7: v = value.next()8: for i = 0 to v.dimCount do9: values[i]+ = v[i]
10: pointCount+ +
11: for j = 0 to values.length do12: values[i] = values[i]
pointCount
13: Output 〈key, pointCount+ values.toString()〉
Fur einen Cluster-Identifikator werden jetzt in den jeweiligen Dimensionen die Koordi-naten der Punkte aufsummiert (Zeile 6-7) und uber einen Zahler mitgefuhrt, wievielePunkte aufsummiert worden sind. Abschließend wird jede Dimensionssumme durch dieAnzahl der Punkte geteilt um den lokalen Clusterschwerpunkt zu erhalten (Zeile 9-10).Das Ergebnis wird als Paar 〈 clusterID, |Punkte| + localCentroid 〉 ausgegeben.
Reduce-Funktion
Am Ende des MapReduce-Durchlaufs werden dann durch die Reduce-Funktion (Algo-rithmus 3.27) die Zwischenergebnisse, die durch die Combine-Funktion bereits lokalreduziert wurden, global zusammengefasst. Als Eingabe erhalt die Funktion das Paar
87
〈clusterID, set(|points|+ localCentroid)〉, die, analog zur Combine-Funktion (Algorith-mus 3.26) reduziert werden.
Algorithmus 3.27 MapReduce-k-Means: Reduce-Phase ([ZMH09] angepasst)
1: input: key - cluster id, value - set of partial centroid calculations2: output: key - cluster id, value - centroid coordinates3: procedure Procedure(〈key, value〉)4: init values[dimCount]5: init pointCount = 06: while value.hasNext() do7: v = value.next()8: for i = 0 to v.dimCount do9: values[i]+ = v[i]
10: pointCount+ = v.pointCount
11: for j = 0 to values.length do12: values[i] = values[i]
pointCount
13: Output 〈key, values.toString()〉
Jedoch werden nicht Punkte, sondern lokale Cluster-Schwerpunkte koordinatenweise auf-summiert (Zeile 4-8) und anschließend durch die Gesamtzahl der Punkte geteilt (Zeile9-10). Die Ausgabe der Funktion ist nun das Schlussel-Wert-Paar 〈 clusterID, centroid-Coordinates 〉, also der neue Schwerpunkt des bearbeiteten Clusters, der fur die nachsteIteration verwendet wird.
3.2.6 Weitere Algorithmen
Ein weiteres Verfahren zur Berechnung eines approximativen hierarchischen Cluste-rings auf Grundlage des MapReduce-Paradigmas ist der PARABLE(PArallel RAndom-partition Based hierarchicaL clustEring)-Algorithmus [WD11], der in zwei Phasen ge-gliedert ist. In der ersten Phase wird eine zufallige Partitionierung mit homogener Par-titionsgroße des Datensatzes vorgenommen. Auf diesen Partitionen wird parallel miteinen sequentiellen Verfahren ein hierarchisches Clustering berechnet, wobei das Cluste-ring durch ein Dendrogramm reprasentiert wird. In der zweiten Phase wird sequentielleine Vereinigung der berechneten Dendrogramme zu einem Gesamtergebnis durchge-fuhrt. Diese werden zunachst sequentiell in einem rekursiven Verfahren an einem Vorlage-Dendrogramm ausgerichtet. Anschließend wird das Vorlage-Dendrogramm in Teilbaumezerlegt und in den anderen Dendrogrammen nach Teilbaumen gesucht, die an denen derVorlage ausgerichtet sind und mit dem Clusteridentifikator der Vorlage versehen.
Der PDBSCAN-Algorithmus[XJK99] ist eine weitere Variante des DBSCAN-Algorithmus,welches als Master-Slave-Architektur umgesetzt ist. Zentrale Komponente dieses Ver-
88
fahrens ist die Verwendung eines verteilten R-Baums als raumliche Indexstruktur. DasVerfahren ist in drei Phasen gegliedert. In der ersten Phase wird eine Aufteilung der Ein-gabedaten in mehrere Partitionen vorgenommen, welche an die verfugbaren Rechenkno-ten (Slaves) verteilt werden. In der zweiten Phase fuhren die Rechenknoten parallel dasClustering auf der zugewiesenen Partition mit einer modifizierten Variante des DBSCAN-Algorithmus durch. Dieser ist dahingehend verandert, dass er in Randbereichen, die uberdie Partition herausragen, uber den verteilten raumlichen Index im Punkte aus angren-zenden Partitionen abfragen kann und so Punkt-Paare ermittelt, die fur eine Vereinigungvon Clustern betrachtet werden mussen. Diese wird in der dritten Phase unter Nutzungder Punkte-Paare aus den lokalen Clusterings vom Master ausgefuhrt.
89
Kapitel 4
Implementierung
In diesem Kapitel werden die Implementierungen der MapReduce-Varianten des Par-tition-Algorithmus sowie des DBSCAN-Algorithmus vorgestellt. Diese sind in der Pro-grammiersprache Java geschrieben und nutzen als Grundlage das MapReduce-Frameworkder MapReduce-Implementierung Hadoop. In den Versuchen werden zusatzlich der Map-Reduce-kMeans- sowie Parallel-FP-Growth-Algorithmus untersucht. Fur diese werdendie Implementierungen des Apache-Projekts Mahout1 genutzt, welches unter anderenVerfahren aus dem Bereich Clustering und Klassifikation fur maschinelles Lernen bereit-stellt. Diese konnen unter anderen auf der Hadoop-Laufzeitumgebung ausgefuhrt werdenkonnen.
4.1 MapReduce-Partition
Die Implementierung des Algorithmus halt sich an die Beschreibung aus Abschnitt 3.1.3.Die Implementierung setzt sich aus drei MapReduce-Jobs zusammen, die sequentiell aus-gefuhrt werden (Abbildung 4.1). Es ist festzuhalten, dass die Anzahl von Transaktionen,in denen frequent Itemsets gesucht werden sollen, vorab nicht zwangslaufig bekannt ist,insbesondere vor dem Hintergrund, dass sehr große Datenmengen eventuell auf viele Da-teien verteilt sind. Aus diesem Grund wird zunachst ein MapReduce-Job ausgefuhrt, derdie gesamten Eingabedaten durchlauft und ausschließlich die Menge der Transaktionenzahlt.
Im Anschluss beginnt die Berechnung der lokalen frequent Itemsets. Diese wird in einemseperaten Job ausgefuhrt, wobei die Eingabedaten in disjunkte Teile aufgeteilt werdenund fur jeden Teil der Eingabe ein Mapper die lokalen frequent Itemsets der Partitionberechnet. Diese werden von einem Reducer in eine Menge zusammengefasst und als
1http://mahout.apache.org/
90
Zählung der Transaktionen
Generierung der Kandidaten
Berechnung des globalen Supports
Transaktionen (Eingabe)
Kandidaten für global-häufige
Itemsets
Daten
MapReduce-Jobs
Datenfluss
Prozessfluss
Globale frequent Itemsets
(Ausgabe)
Abbildung 4.1: Ablauf der MapReduce-Implementierung des Partition-Algorithmus
Datei im verteilten Dateisystem zwischengespeichert.
Anschließend werden in einem dritten Job die Kandidaten fur globale frequent Itemsetsgegen die gesamte Menge von Transaktionen getestet. Hierfur liest jeder Mapper dieKandidatenmenge ein und einen Teil der Menge von Transaktionen. In diesem Anteilvon Transaktionen wird nun fur jeden Kandidaten berechnet, wie oft dieser vorkommtund dieses als Schlussel-Wert-Paar ausgegeben. Der Reducer fasst in diesem Schritt dieVorkommen fur jeden Kandidaten zusammen und berechnet, ob der Anteil von notwen-digen Vorkommen fur jeden Kandidaten erreicht wurde. Kandidaten, die den minimalenSupport erreichen, werden ausgegeben und bilden so die Menge der frequent Itemsets.
Berechnung der Transaktions-Anzahl
Die Berechnung des Umfangs der Transaktionsdaten erfolgt, indem jeder Mapper dieAnzahl der gelesenen Zeilen mitzahlt und die Summe ausgibt. Ein Reducer sammelt dievon den Mappern gelieferten Werte ein, addiert diese, und bildet so die Gesamtsum-me der gelesenen Zeilen, respektive Transaktionen. Die Anzahl der Transaktionen wirdabschließend im verteilten Dateisystem gespeichert.
91
Berechnung der lokalen frequent Itemsets
Ein Mapper beginnt mit dem Einlesen des zugewiesenen Teils der Transaktionsmenge.Wahrend des Einlesens werden die Transaktionen direkt in Listen von Transaktions-Identifikatoren (TID-Liste) zerlegt, so dass fur jedes Element der Transaktionsmengefestgehalten wird, in welcher Transaktion es vorkommt. Die TID-Liste wird als HashMapgespeichert, welches als Schlussel das Element und als Wert die Liste enthalt. Die initia-le Menge von lokalen frequent 1-Itemsets lasst sich direkt aus der TID-Liste generieren,indem alle Elemente als 1-Itemsets ubernommen werden, deren Vorkommen in Relationzu der Anzahl der Transaktionen des Mappers den minimalen lokalen Support uber-schreiten. Mit diesen Transaktionen geschehen nun mehrere Dinge. Zum einen werdendiese direkt als Schlussel-Wert-Paare ausgegeben. Zum anderen bilden diese Itemsets dieGrundlage, auf der großere Itemsets gebildet werden. Sie werden also zusatzlich in einerArray-List gespeichert. Die Itemsets werden durch Objekt reprasnetiert, welches sowohldas Itemset als auch die TID-Liste in Form eines Arrays enthalt. Zur Vereinfachung desPrunings von Itemset-Kandidaten wird zusatzlich die String-Reprasentation des Arraysin einem Hash-Set gespeichert, so dass die Prufung der haufigen Itemset-Teilmengendurch eine indizierte Suche optimiert wird.
Die Kandidatengenerierung erfolgt analog zu Algorithmus 3.2. Zusatzlich werden im-mer nur die Itemsets der vorherigen Iteration vorgehalten, um den Speicherbedarf zureduzieren.
Das Pruning eines Itemset-Kandidaten gestaltet sich durch die Speicherung der String-Reprasentation aller bisher generierten lokal-haufigen Itemsets relativ einfach. Fur einenKandidaten werden alle Teilmengen berechnet und in dem HashSet gesucht. Sobaldeine Teilmenge nicht in dem HashSet enthalten ist, kann der Kandidat direkt verworfenwerden.
Die Implementierung des Reduce-Tasks ist sehr einfach gehalten, da dieser lediglich dievon den Mappern generierten Kandidaten als Eingabe erhalt und daraus die Menge derlokalen frequent Itemset-Kandidaten liefert. Diese werden anschließend zur Zwischen-speicherung in das verteilte Dateisystem geschrieben.
Berechnung der globalen frequent Itemsets
Das initiale Vorgehen der Mapper in der dritten Phase ist identisch zu dem der zweitenPhase. Zunachst wird aus den Transaktionen der zugewiesenen Eingabe eine TID-Listefur jedes Item erstellt, die in Form eines HashSets als Schlussel das Element und als Wertin Form einer Array-List die Vorkommen in Transaktionen enthalt. Zusatzlich wird dieMenge der lokalen frequent Itemsets eingelesen. Nun wird fur jedes Kandidaten-Itemsetder Support berechnet. Dies geschieht, indem das Itemset Item fur Item durchlaufen wird
92
und die Schnittmenge der TID-Listen fur alle Elemente des Itemsets sukzessive berechnetwird, so dass am Ende fur das Itemset die Menge der Transaktionen ubrig bleibt, die alleElemente des Itemsets enthalten. Die Ausgabe erfolgt nun als Schlussel-Wert-Paar, wobeials Schlussel das Itemset und als Wert die Anzahl der lokalen Vorkommen ausgegebenwerden.
Die Reducer fassen abschließend die Ergebnisse der Mapper gemaß Algorithmus 3.6zusammen. Ausgegeben werden schlussendlich die globalen frequent Itemsets zusammenmit der Anzahl ihrer Vorkommen.
4.2 MapReduce-DBSCAN
Die Implementierung des MR-DBSCAN-Algorithmus folgt der Verfahrensbeschreibungin Abschnitt 3.2.3 auf Seite 65. Als zusatzliche Phase ist hier jedoch die Bestimmung ei-nes minimal-einschließenden Rechtecks der zu clusternden Punktmenge eingefuhrt (Ab-bildung 4.2). Dieses ist notwendig, da die geometrischen Ausmaße der zu clusterndenPunktmenge nicht zwingend bekannt ist. Die Erzeugung einer adaptiven Partitionierungist jedoch auf die Bekanntheit der Datensatzausmaße angewiesen.
Bestimmung eines MERs
Die Bestimmung des minimal-einschließenden Rechtecks (MER) fur die Eingabedatenerfolgt auf triviale Weise, indem die Mapper den zugewiesenen Teil der Eingabe punkt-weise durchlaufen und die minimalen und maximalen x- und y-Koordinaten festhalten.Diese wird von jedem Mapper jeweils als Schlussel-Wert-Paar 〈 null, (x, y) 〉 ausgegebenwerden. Ein Reducer verarbeitet diese Zwischenergebnisse nun und bestimmt daraus dielinke untere und rechte obere Ecke des einschließenden Rechtecks.
Berechnung einer Partitionierung
Die Mapper berechnen in der Initialisierung zunachst unabhangig voneinander aus demMER ein Raster, indem nacheinander in positiver x- und y-Richtung mit Schrittweite ε2
vom Mittelpunkt des minimal einschließenden Rechtecks ausgehend gelaufen wird, bisdie erreichte Koordinate der jeweiligen Dimension echt großer als die maximal x-, bzw.y-Koordinate, sind. Die gleiche Zellenzahl kommt auch in negativer Richtung hinzu, sodass die Große des Rasters [2∗X][2∗Y ] betragt, wenn X und Y die Anzahl der gezahltenZellen in der jeweiligen Dimension sei. Im Anschluss berechnet jeder Mapper fur jeden
2Die Schrittweite betragt hier nicht, im Gegensatz zur Beschreibung in 3.2.3, um das Raster nichtzu groß werden zu lassen.
93
MER der Eingabedaten
berechnen
Daten-partitionierung
Lokales Clustering
Rohdaten (Eingabe)
Partitionierungs-profil
Daten
MapReduce-Jobs
Datenfluss
Prozessfluss
Koordinaten des MER
Ergebnisse der lokalen Clusterings
Erzeuge Merge-Abbildung
Umbenennung der Daten
Merge-Abbildung
Daten mit globalen Cluster IDs (Ausgabe)
Angrenzende Partitionenpaare
Menge der lokalen Cluster-
identifikatoren
Abbildung 4.2: Ablauf der Implementierung des MR-DBSCAN-Algorithmus
94
Punkt der zugewiesenen Eingabe, in welcher Rasterzelle ein Punkt enthalten ist, undinkrementiert einen Zahler fur diese Zelle. Nachdem die Eingabe vollstandig gelesen undbearbeitet ist, gibt der Mapper fur jede Rasterzelle die Anzahl der enthaltenen Punktein der Form 〈 ID Rasterzelle, Punktzahl 〉 aus.
Ein Reducer sammelt nun die Schlussel-Wert-Paare der Mapper ein und erzeugt ausdiesen analog zu den Mappern ein Raster fur den Datensatz, in welchem die Ergebnisseder Mapper zusammengefasst werden und so die Punktverteilung fur den ganzen Da-tensatz reprasentiert wird. Auf Grundlage des Rasters wird eine binare Unterteilung desminimal-einschließenden Rechtecks, welches das gesamte Raster einschließt, vorgenom-men. Hierfur wird eine Rechtecke enthaltende Queue so lange abgearbeitet, bis diese leerist. Initialisiert wird diese mit dem MER des Rasters. Aus der Queue wird nun das ersteRechteck entnommen und mit Hilfe des Rasters berechnet, wie viele Punkte es enthalt.Dieses geschieht, in dem uber die Koordinaten beider Objekte die vom Rechteck uber-deckten Zellen berechnet und die darin enthaltenen Punktsummen aufsummiert werden.Wenn diese Punktsumme nun die vorgegebenen Kosten uberschreitet, so ist das Recht-eck in zwei neue Rechtecke zu unterteilen. Hierfur werden parallel zu der x- und y-Achseverlaufende Unterteilungslinien aus den Rechteck-Koordinaten berechnet, die parallel imAbstand ε zueinander achsparallel verlaufen. Fur jede dieser Linien wird die Kostendiffe-renz wie zuvor durch die Bestimmung der uberdeckten Rasterzellen fur die zwei sich ausder Unterteilung ergebenden Rechtecke berechnet und die Linie gewahlt, die zu einerminimalen Kostendifferenz fuhrt; die resultierenden Rechtecke werden zuruckgeliefertund in die Queue fur eine eventuelle weitere Unterteilung eingefugt. Ein Rechteck, dassdie maximalen Kosten fur eine Partition nicht uberschreitet, stellt eine gultige Partiti-on dar und wird zwischengespeichert. Sobald die Queue keine Rechtecke mehr enthaltist die Partitionierung abgeschlossen und die Partitionsliste wird im verteilten Dateisy-stem gespeichert. Zusatzlich wird fur jede Partition der berechneten Partitionierung dieMenge der direkt angrenzenden Partitionen bestimmt und diese als Schlussel-Wert-Paarausgegeben.
Lokales Clustering
Die Mapper lesen zu Beginn zuerst die Partitionsliste ein. Fur jeden Punkt der Eingabewird gegen die Partitionsliste uber die Koordinaten der Partition und des Punktes diePartition bestimmt, in der der Punkt enthalten ist, und der Partitions-Identifikator mitdem Punkt als Schlussel-Wert-Paar ausgegeben.
Fur die Reduce-Phase werden nun so viele Reduce-Tasks erzeugt, wie es Partitionengibt; dieses soll gewahrleisten, dass das Clustering jeder Partition in einem eigenen Taskstattfindet. Ein Reducer liest zunachst die ihm zugeordneten Punkte ein und speichertdiese als Clusterobjekte, so dass einem Punkt zusatzlich ein Klassifikationsflag und einCluster-Identifikator zugeordnet ist. Sobald die Eingabe vollstandig gelesen ist wird ausder Punktmenge ein R-Baum aufgebaut, wofur die Implementierung Sort-Tile-Recursive
95
R-Tree(STRtree) aus der Java Topology Suite(JTS) verwendet wird. Auf diesem wirddas Clustering gemaß des modifizierten DBSCAN-Algorithmus (siehe 3.18 auf Seite 73)durchgefuhrt. Mit den Ergebnissen des Clusterings passieren nun drei Dinge. Zum einenwerden die geclusterten Punkte als Schlussel-Wert-Paare der Form 〈 Punkt, (lokaleCluster-ID, Punkt-Klassifikation) 〉 ausgegeben; der lokale Clusteridentifikator setzt sichzusammen aus einem Identifikator fur die Partition und dem numerischen Wert, der sichaus dem Clustering-Prozess ergibt. Zusatzlich schreibt jeder Reducer die Menge aller lo-kale vorkommenden Clusteridentifikatoren in das Dateisystem. Außerdem wird fur jedePartition die Menge der Punkte innerhalb der inneren und außeren Randbereiche (sieheAbbildung 3.7 auf Seite 71) bestimmt und in das verteilte Dateisystem geschrieben.
Berechnung einer Vereinigungsabbildung
Die Mapper erhalten als Eingabe einen Teil der Schlussel-Wert-Paare mit angrenzendenPartitionspaaren, die in der Partitionserzeugung generiert worden sind. Fur jedes Paarwird aus dem verteilten Dateisystem fur jede Partition die Liste der Kernpunkte iminneren Randbereich und die Liste der Rand- und Kernpunkte im außeren Randbereichder Partition gelesen. Die Berechnung des Durchschnitts von jeweils zwei Listen erfolgt,indem eine der beiden zu vergleichenden Clusterobjekt-Listen in eine HashMap umge-wandelt wird, die als Schlussel eine String-Reprasentation des Punktes und als Wertdas Clusterobjekt besitzt. Anschließend wird die Liste durchlaufen und fur jeden Punktgegen die HashMap getestet, ob die String-Reprasentation in der Map enthalten ist;ist dies der Fall werden beide Clusterobjekte zu einer Ergebnisliste von Clusterobjekt-Paaren hinzugefugt. Abschließend wird die Liste durchlaufen und Schlussel-Wert-Paarefur jedes Punktpaar ausgegeben.
Ein Reducer sammelt nun die Paare der Mapper ein und generiert aus diesen zu-nachst einen ungerichteten Graphen, fur den die Implementierung des Java Univer-sal Network/Graph(JUNG)-Frameworks verwendet wird. Hierfur wird fur jedes geleseneIdentifikatoren-Paar jeweils ein Knoten sowie eine die beiden Knoten verbindende Kan-te generiert und in den Graphen eingefugt; der Bezeichner der Knoten ist hierbei derlokale Clusteridentifikator. Sobald alle Identifikatoren-Paare gelesen und in den Grapheingefugt worden sind, werden die Zusammenhangskomponenten des Graphen berechnet;fur die Berechnung wird ein WeakComponentClusterer des JUNG-Frameworks genutzt,der eine Menge von berechneten Zusammenhangskomponenten zuruckliefert, wobei jedeZusammenhangskomponente wiederum aus einer Menge von Knoten der Komponen-te besteht. Es wird nun eine HashMap fur die Vereinigungsabbildung erstellt, die alsSchlussel den lokalen und als Wert den globale Clusteridentifikator enthalt. Zunachstwird ein Zahler fur die globalen Clusteridentifikatoren mit eins initialisiert. Nun wird je-de Zusammenhangskomponente durchlaufen und fur jeden Knoten ein Eintrag mit demlokalen und dem globalen Clusteridentifikator zu der Map hinzugefugt; nach jeder Kom-ponente wird der Zahler um eins inkrementiert. Anschließend wird nun ebenfalls aus
96
dem Dateisystem fur jede Partition die Liste lokaler Clusteridentifikatoren gelesen, ausdenen bereits im Graph vorhandene Identifikatoren entfernt werden. Auch hier wird furjeden lokalen Clusteridentifikator ein Eintrag mit dem lokalen und dem globalen Cluste-ridentifikator in die Map eingefugt und anschließend der Zahler inkrementiert; Punkte,die bereits lokal als Rauschen markiert worden sind (Partitions-Identifikator + ”0”), er-halten global den Identifikator ”0” als Rausch-Marker. Abschließend wird die Map mitder Abbildung serialisiert und im verteilten Dateisystem gespeichert.
Umbenennung der Ergebnisse des lokalen Clusterings
Die Mapper lesen in der Initialisierung die Vereinigungsabbildung, die im vorherigenSchritt erzeugt wurde. Diese wurde als HashMap angelegt, damit die Suche nach einemglobalen Cluster-Identifikator ausgehend von einem lokalen Cluster-Identifikator ubereinen Index beschleunigt werden kann. Anschließend erhalten sie einen Teil der Ausga-be, die im lokalen Clusterings erzeugt wurde. Mit Hilfe der HashMap wird der globaleIdentifikator des Clusterobjekts gesucht und im Clusterobjekt aktualisiert. Schließlichwird das modifizierte Schlussel-Wert-Paar ausgegeben.
Die Reducer fuhren nun die finale Bestimmung der Punktklassifikation fur Punkte ausden Uberlappungsbereichen der Partitionen durch. Die implementierte Vorgehensweiseorientiert sich direkt an 3.21 auf Seite 78 und wird deshalb nicht weiter ausgefuhrt.
4.2.1 MapReduce-kMeans und Parallel FP-Growth
In diesem Abschnitt sollen die Implementierungen der beiden Algorithmen, die aus demApache Mahout Projekt stammen, kurz analysiert werden. Es soll betrachtet werden,ob und, wenn ja, welche Unterschiede es zwischen den vorgestellten Beschreibungen in3.2.5 und 3.1.3 gibt.
MapReduce-kMeans
Die Implementierung des MapReduce-kMeans-Algorithmus vom Mahout-Projekt ent-spricht nicht der Beschreibung in [ZMH09], die in Abschnitt 3.2.5 vorgestellt wurde.Im Gegensatz zu der gelieferten Beschreibung besteht die Implementierung lediglich auseinem einzigen Map-Task pro Iteration. In diesem Map-Task werden die eingegebenPunkte mittels eines Cluster-Klassifikators dem nachstgelegenen Cluster-Zentroiden zu-geordnet. Die im Laufe der Berechnung aktualisierten Zentroide werden am Ende jederIteration ausgegeben und als Eingabe-Zentroide der nachsten Iteration genutzt.
97
Parallel FP-Growth
Die Implementierung des Parallel FP-Growth-Algorithmus folgt der Verfahrensbechrei-bung von [LWZ+08], die in Abschnitt 3.1.3 vorgestellt wurde. Die Implementierung istebenfalls in drei Phasen aufgeteilt fur die Zahlung der frequent 1-Itemsets, die Suche nachfrequent Itemsets in gruppenabhangigen Shards und die Aggregierung der Teilergebnis-se. Es wird ebenfalls die zentrale Datenstruktur zur Speicherung der frequent Itemsets,ein Maximum-Heap mit einer begrenzten Anzahl von Elementen, verwendet. Eine ober-flachliche Betrachtung des Quelltextes der Implementierung hat keine Auffalligkeiten zuTage gefordert.
98
Kapitel 5
Versuche
In diesem Kapitel werden vier verschiedene Verfahren auf MapReduce-Basis, jeweilszwei aus dem Bereich der Assoziations- und Clusteranalyse, untersucht, die in Kapitel3 vorgestellt wurden. Fur die Assoziationsanalyse werden hier die Algorithmen MR-Partition sowie Parallel FP-Growth, fur die Clusteranalyse die Algorithmen MR-kMeanssowie MR-DBSCAN untersucht.
Fur die Algorithmen zur Assoziationsanalyse wird hierbei zum einen experimentell dieKorrektheit des Parallel FP-Growth-Algorithmus untersucht, zum anderen wird fur beideAlgorithmen die Tauglichkeit am Beispiel von Transaktionsdatenbanken verschiedenerGroße untersucht.
Fur die Algorithmen der Clusteranalyse wird am Beispiel des MR-kMeans-Algorithmusdie Auswirkung der Blockgroße der Eingabedaten auf die Laufzeit des Algorithmus be-trachtet. Fur den MR-DBSCAN-Algorithmus wird experimentell die Auswirkung derParameterwahl auf die Laufzeit untersucht, insbesondere im Hinsicht auf die sequentiel-len Anteile des Algorithmus. Fur beide Verfahren wird zusatzlich der Speed-Up betrach-tet. Schließlich werden beide Verfahren in einem Versuch mit großen Testdaten direktgegenubergestellt und verglichen.
Fur die Versuche wurde ein Hadoop-Cluster auf drei Rechnern aus dem Rechnerpool desFachgebiets Datenbanken und Informationssysteme aufgesetzt. Hierbei handelt es sichum zwei Rechner mit Intel Core i3-540 2-Kern-Prozessoren mit 3,07 GHz, 4 virtuellenKernen und 4 GB Arbeitsspeicher (Typ-1) sowie einen Rechner mit einem Intel Corei7-2600 4-Kern Prozessor mit 8 virtuellen Kernen und 16 GB Arbeitsspeicher (Typ-2).Vom ersten Typ werden dem Hadoop-Cluster jeweils 2 virtuelle Prozessorkerne und 3GB Arbeitsspeicher, vom zweiten Typ 4 virtuelle Kerne sowie 6 GB Arbeitsspeicher zuVerfugung gestellt.
Durch diese Ressourcenzuweisung lasst sich durch sukzessives Hinzufugen von Knoten
99
vom Typ 1 und schließlich Typ 2 zum Cluster grob eine Verdopplung der Leistung mitjedem hinzugefugten Knoten darstellen:
• Konfiguration 1 (1 Knoten): Typ-1
• Konfiguration 2 (2 Knoten): Typ-1 + Typ-1
• Konfiguration 3 (3 Knoten): Typ-1 + Typ-1 + Typ-2
Zusatzlich ist der Hadoop-Cluster so konfiguriert, dass der Nodemanager jedes Knotensmaximal 3 GB Speicher zur Verfugung stellt. Das verteilte Dateisystem wird aus denlokalen Festplatten der Knoten aufgebaut und besitzt eine standardmaßige Blockgroßevon 128MB und einem Replikationsfaktor von 3, so dass im Betrieb mit 3 Knoten jederBlock auf jedem Knoten vorliegt.
Auf jedem Knoten des Clusters laufen folglich als Dienste ein Namenode fur die Be-reitstellung von Speicher fur das verteilte Dateisystem sowie ein Nodemanager, der dieRechenressourcen des Knotens verwaltet. Die zentralen Komponenten, der Resource-Manager fur die Verwaltung der Rechenressourcen des Clusters und der Namenode furdie Metadatenverwaltung des Clusters, laufen auf dem Typ-2 Knoten. Sofern nicht an-ders angegeben betragt die Blockgroße fur die Dateien im verteilten Dateisystem 64 MB.Zusatzlich betragt die Große fur einen Container 1 GB, wovon 768 MB von der JVM,die im Container ausgefuhrt wird, fur den Heap-Speicher verwendet werden konnen.
5.1 Assoziationsanalyse
In den Versuchen mit dem MapReduce-Partition und Parallel FP-Growth-Algorithmussollen verschiedene Aspekte untersucht werden. Zum Abschluss der Vorstellung des Par-allel FP-Growth-Algorithmus in Abschnitt 3.1.3 blieb die Frage offen, ob dieser eineexakte oder ungefahre Losung liefert. Dies soll in einem ersten Experiment untersuchtwerden. In zwei weiteren Versuchen soll unabhangig voneinander die Performance beiderAlgorithmen untersucht werden. Dies geschieht durch Tests der Implementierungen inunterschiedlichen Konfigurationen. Zum Abschluss sollen schließlich beide in einem Testeinem Vergleich hinsichtlich der Tauglichkeit antreten.
Fur die Versuche mit den Verfahren der Assoziationsanalyse werden die folgenden Test-datensatze von Frequent Itemset Mining Implementations(FIMI)1 verwendet, bei denenes sich sowohl maschinell erzeugte als erfasste Realwelt-Daten handelt:
• Synthetische Testdaten:
1http://fimi.ua.ac.be/
100
– T10I4D100K.dat (3,9 MB) - 100.000 Transaktion, 1000 verschiedene Items,durchschnittliche Transaktionslange: 10, durchschnittliche Lange der haufig-sten Itemsets: 4
– T40I10D100K.dat (15 MB) - 100.000 Transaktionen, 1000 verschiedene Items,durchschnittliche Transaktionslange: 40, durchschnittliche Lange der haufig-sten Itemsets: 10
• Realwelt-Testdaten:
– accidents.dat2 (34 MB) - Offizielle Unfallstatistiken des National Institute ofStatistics (NIS) der Region Flandern (Belgien), 340.183 Transaktionen, 572verschiedene Items, durchschnittlich Transaktionslange: 54 Items
– webdocs.dat3 (1,4 GB) - Sammlung von 1,7 Million HTML-Dokumenten ausdem Internet, 1.692.082 Transaktionen, 5.267.656 verschiedene Items, maxi-male Transaktionslange: 71.412 Items
Bei diesen handelt es sich um einfache Textdateien, in denen jede Zeile einer Transaktionentspricht.
5.1.1 Experimentelle Untersuchung der Korrektheit des Paral-lel FP-Growth-Algorithmus
Am Ende der Beschreibung des Parallel FP-Growth-Algorithmus (Abschnitt 3.1.3, Seite49) ist die Frage offen geblieben, ob dieser ein exaktes oder approximatives Ergebnisliefert. Dies soll anhand eines kleinen Beispiels untersucht werden. Verwendet wird hierfurdie Transaktionsdatenbank in Tabelle 5.1, welche aus dem Artikel uber den Apriori-Algorithmus4 aus der englischen Wikipedia stammt.
Itemsets{1, 2, 3, 4}{1, 2, 4}{1, 2}{2, 3, 4}{2, 3}{3, 4}{2, 4}
Tabelle 5.1: Beispiel-Transaktionsdatenbank
2http://fimi.ua.ac.be/data/accidents.pdf3http://fimi.ua.ac.be/data/webdocs.pdf4http://en.wikipedia.org/wiki/Apriori algorithm
101
Damit ein Itemset haufig ist wird verlangt, dass dieses in mindestens drei Transaktionenauftritt. Folglich ergeben sich als frequent 1-Itemsets die vier Itemsets aus Tabelle 5.2mit der entsprechenden Anzahl von Vorkommen.
Itemset Anzahl{1} 3{2} 6{3} 4{4} 5
Tabelle 5.2: Haufige 1-Itemsets
Es sind somit alle vier vorkommenden 1-Itemsets der Transaktionsdatenbank haufig.Die sich daraus ergebenden Kombinationen von 2-Itemsets sind mit ihrem Support inTabelle 5.3 dargestellt.
Itemset Support{1, 2} 3{1, 3} 1{1, 4} 2{2, 3} 3{2, 4} 4{3, 4} 3
Tabelle 5.3: Haufige 2-Itemsets
Von diesen sechs 2-Itemsets sind jedoch nur vier haufig. Das einzige sich daraus ergeben-de 3-Itemset, welches nicht aufgrund nicht-haufiger Teilmengen verworfen wird, ist inTabelle 5.4 abgebildet. Da es jedoch nur einen Support von zwei hat wird es verworfen.
Itemset Support{2, 3, 4} 2
Tabelle 5.4: 3-Itemset Kandidaten
Auf dieser Transaktionsdatenbank werden nun der MapReduce-Partition- sowie derParallel-FP-Growth-Algorithmus ausgefuhrt. Hierbei zeigt sich, dass der MR-Partition-Algorithmus die gleichen haufigen Itemsets der Lange eins und zwei liefert, die in Tabelle5.2 und 5.3 aufgefuhrt sind. Die Ausfuhrung des Parallel-FP-Growth liefert keine Aus-gabe; die Ursache hierfur ließ sich nicht klaren.
Aus diesem Grund wird eine theoretische Betrachtung des Algorithmus mit der Trans-aktionsdatenbank (Tabelle 5.1) als Eingabe vorgenommen. Es wird zunachst festgelegt,dass der Algorithmus vier Gruppen verwendet; alle Items werden folglich durch die Hash-Funktion verschiedenen Gruppen zugewiesen.
102
Zunachst wird die Menge aller haufigen 1-Itemsets bestimmt und diese nach ihrem Sup-port absteigend sortiert. Diese sind bereits in Tabelle 5.2 aufgelistet und ergeben, ab-steigend nach der Anzahl der Vorkommen sortiert die Liste {2, 4, 3, 1}.
Transaktion G-1 G-2 G-3 G-4{2, 4, 3, 1} {2, 4, 3, 1} {2} {2, 4, 3} {2, 4}{2, 4, 1} {2, 4, 1} {2} {2, 4}{2, 1} {2, 1} {2}{2, 4, 3} {2} {2, 4, 3} {2, 4}{2, 3} {2} {2, 3}{4, 3} {4, 3} {4}{2, 4} {2} {2, 4}
Tabelle 5.5: Gruppenabhangige Shards.
Mit dieser Liste wird nun die Transaktionsdatenbank nach Algorithmus 3.8 in vier grup-penabhangige Shards transformiert transformiert; diese ist in Tabelle 5.5 dargestellt. EinBerechnen der frequent Itemsets fur jeden gruppenabhangigen Shard von Hand liefertexakt das gleiche Ergebnis, welches beispielsweise eine Berechnung mit Hilfe des Apriori-oder FP-Growth-Algorithmus auf der vollstandigen Transaktionsdatenbank ergibt.
Dies zeigt, dass der Parallel-FP-Growth zumindestens fur dieses kleine Beispiel ein ex-aktes Ergebniss liefert. Es werden alle vorhandenen frequent Itemsets mit dem exaktenSupport-Wert gefunden.
Ein zweiter Versuch wird mit dem synthetischen Testdatensatz T10I4D100K.dat durch-gefuhrt. Hierfur wird ein relativer Support von 0.0001, was einem absoluten Support von10 Transaktionen bei 100.000 Transaktionen in der Transaktionsdatenbank entspricht,verwendet. Zusatzlich soll der PFP-Algorithmus die 100 haufigsten Itemsets fur jedesItem ausgegeben und die vom Parallel FP-Growth vorgegebene standardmaßige Anzahlvon 50 Gruppen verwenden.
Partition Parallel FP-Growth411.365 Itemsets 362 Itemsets
Tabelle 5.6: Anzahl gefundener Itemsets
Bei den Anzahl der gefundenen Itemsets fur diesen Versuch (Tabelle 5.6) ist zunachsterkennbar, dass sich die Anzahl der gefundenen Itemsets stark unterscheidet. Die Mengeder vom PFP-Algorithmus erhoht sich auch nicht, wenn man die Anzahl der auszu-gebenden frequent Itemsets fur ein Item massiv erhoht, beispielsweise auf 10.000. EineStichprobenartige Prufung zeigte, dass die gefundenen frequent Itemsets des Parallel FP-Growth-Algorithmus auch in den Ergebnissen des MapReduce-Partition-Algorithmusauftreten. Jedoch stimmten die berechneten Supportwerte beider Ergebnisse nicht uber-ein.
103
Hinsichtlich der Anzahl gefundener Itemsets ist die Vermutung naheliegend, dass aufdie Ausgabe der Teilmengen gefundener frequent Itemsets verzichtet wird. Eine tiefer-gehende Analyse des Quelltextes bestatigt diese Vermutung. Itemsets werden in derImplementierung des Maximum-Heaps, der vom Parallel FP-Growth-Algorithmus ver-wendet wird, nur in den Maximum-Heap eingefugt, wenn es keine Teilmenge eines bereitsvorhandenen Itemsets ist oder aber einen großeren Support als dieses besitzt. Außerdemwerden Itemsets, die Teilmenge eines einzufugenden Itemsets sind und einen geringerenoder gleichen Support als dieses besitzen, ersetzt.
Abschließend lasst sich als Fazit festhalten, dass der Parallel FP-Growth offensichtlichnicht immer eine exakte Losung hinsichtlich der Supportwerte liefert. Sofern sich diesim Rahmen dieses Versuchs sagen lasst, beinhaltet die Losung jedoch sehr wohl dietatsachlichen existierenden frequent Itemsets.
5.1.2 Untersuchung der Performance des Partition-Algorith-mus
In diesem Versuch soll fur die MapReduce-Implementierung des Partition-Algorithmusmit verschiedenen Datensatzen die Leistungsfahigkeit untersucht werden. Hierfur werdendie drei Datensatze T10I4D100K.dat, T40I10D100K.dat und accidents.dat verwendet.Aufgrund der geringen Datengroße werden diese jeweils in vier Teile aufgeteilt, damitder Algorithmus mehrere Eingabe-Teile erhalt und eine der Menge der Eingabedateienentsprechende Anzahl von Map-Tasks erzeugt, die parallel verarbeitet werden. Genutztwerden alle drei Knoten des Clusters. Getestet wird die Laufzeit des Algorithmus mitverschiedenen Eingabedaten sowie minimalen Support-Werten.
minimaler Support T10I4D100K T40I10D100K accidents0,01 (1000 Transaktionen) 01:16 Fehler Fehler0,001 (100 Transaktionen) 11:28 Fehler Fehler0,0001 (10 Transaktionen) Fehler Fehler Fehler
Tabelle 5.7: Testresultate fur den MR-Partition-Algorithmus
Die Ergebnisse der Test (Tabelle 5.7) sind sehr ernuchternd. Die Berechnung der fre-quent Itemsets gelingt nur bei dem kleinsten Testdatensatz, und selbst bei einem sehrkleinen minimalen Support scheitert die Berechnung. Die Ursache hierfur liegt in derTatsache begrundet, das der Algorithmus keine komprimierte Darstellung der Trans-aktionsdatenbank fur die Suche nach frequent Itemsets verwendet. In jeder Iterationist es erforderlich, dass die gefundenen Itemsets der vorherigen Iteration mit den zuge-horigen Transaktionslisten vorgehalten werden, um aus diesen durch die Kombinationzweier Itemsets ein neues zu generieren; es ist folglich in jedem Schritt notwendig, diegefundenen frequent Itemsets von zwei Iterationen zusammen mit den TID-Listen zu
104
speichern. Aus dem vorherigen Versuch ist bereits bekannt, dass eine Ausfuhrung desMapReduce-Partition-Algorithmus auf den Datensatz T10I4D100K.dat bei einem mini-malen Support von 0,0001 bereits etwa 400.000 frequent Itemsets findet (Tabelle 5.6.Verstarkend kommt in diesen Versuchen noch hinzu, dass durch Aufteilung der Einga-bedaten in vier Teile der minimale Support ebenfalls durch vier geteilt wird und somit0,000025 betragt, also noch weiter reduziert wird, und folglich zu noch mehr gefundenenItemsets fuhrt.
Somit lasst sich an dieser Stelle bereits festhalten, dass der MapReduce-Partition-Algo-rithmus fur eine Anwendung auf große Transaktionsdatenbanken vollig ungeeignet ist,da der aus der Kandidatengenerierung resultierende Speicherbedarf viel zu groß ist.
5.1.3 Untersuchung der Performance des Parallel FP-Growth-Algorithmus
Fur den Parallel FP-Growth-Algorithmus sollen in dieser Versuchsreihe zwei verschie-dene Aspekte betrachtet werden. Zum einen soll die Laufzeit des Algorithmus bei einerverschiedenen Anzahl von Rechenknoten ermittelt werden. Zum anderen soll erprobtwerden, wie sich die drei Steuerparameter des Algorithmus, die Gruppenzahl, der mi-nimale Support und die Anzahl zu auszugebender frequent Itemsets fur jedes Item, aufdie Laufzeit auswirken.
Knotenzahl
Fur diesen Versuch wurde der Testdatensatz webdocs.dat verwendet. Als Parameter furden Algorithmus wurde eine Gruppenzahl von 10, ein minimaler Support von 10 sowiedie Ausgabe der 500 haufigsten Itemsets gewahlt.
Die Ergebnisse fur die Gesamtlaufzeit (Abbildung 5.1) zeigen, dass der Algorithmus furden verwendeten Datensatz keinen linearen Speed-Up besitzt und dieser beim Ubergangvon zwei auf drei Knoten sogar noch starker abflacht.
Eine Betrachtung der Laufzeiten der einzelnen Phasen des Algorithmus zeigt, dass dasZahlen der haufigen 1-Itemsets die großte Zeit des Algorithmus in Anspruch nimmt. Be-reits in diesen ist kein linearer Speed-Up erkennbar. Das Mining von frequent Itemsetsaus den gruppenabhangigen Transaktionsdatenbanken zeigt hier jedoch einen naherungs-weisen linearen Speed-Up. Der letzte Schritt hingegen, die Aggregierung der Ergebnisse,ist von der Laufzeit her annahernd konstant und verandert sich bei einer verandertenKnotenzahl nicht signifikant.
105
Abbildung 5.1: Laufzeit PFP-Algorithmus (Gruppen: 10, Support: 10, K: 50)
Steuerparameter
Betrachtet werden soll in diesem Test, wie sich die verschiedenen Steuerparameter desAlgorithmus auf die Laufzeit auswirken. Die Tests werden mit allen drei Knoten desClusters ausgefuhrt und es kommt der Datensatz webdocs.dat zur Anwendung.
Zuerst wird die Laufzeit mit einer verschieden großen Zahl von gruppenabhangigenTransaktionsdatenbanken getestet. Wie in Tabelle 5.8 zu sehen ist, hat die Variationder Anzahl zu bildender Gruppen bei der verwendeten Knotenzahl und Datensatzgro-ße keinen keine gravierenden Veranderung der Laufzeit zur Folge. Zwar steigt bei einerAnzahl von 5000 Gruppen die Laufzeit fur die Zahlung der haufigen 1-Itemsets leichtan, da diese Phase des Algorithmus noch nicht von der Anzahl der Gruppen beeinflusstwird ist dieses aller Wahrscheinlichkeit eine Folge des Nichtdeterminismus der Program-mausfuhrung auf dem Cluster.
Gruppen Gesamtzeit Zahlen Suchen Aggregierung100 03:46 03:03 00:27 00:16500 03:29 02:46 00:25 00:18
2.500 03:24 02:45 00:24 00:155.000 03:53 03:15 00:25 00:13
Tabelle 5.8: Laufzeit bei variabler Gruppenzahl (minSup = 10, K = 500)
In einer weiteren Versuchsreihe, bei der mit unterschiedlichen Parameterauspragungendes minimalen Supports getestet wird, zeigt sich, dass der minimale Support keine
106
Abbildung 5.2: Laufzeiten der einzelnen Teile des PFP-Algorithmus
messbaren Einfluss auf die Performance des Verfahrens hat (Tabelle 5.9).
Support Laufzeit Zahlen Suche Aggregierung10 03:37 02:48 00:32 00:17100 03:38 02:59 00:24 00:15
1.000 03:58 03:17 00:24 00:1710.000 03:41 03:01 00:28 00:12
Tabelle 5.9: Laufzeit bei unterschiedlichem minimalen Support (100 Gruppen, K = 500)
Das gleiche trifft auf die Laufzeiten zu, wenn die Anzahl der haufigen Itemsets, die furein Item ausgegeben werden sollen, variieren. Wie in Tabelle 5.10 zu sehen ist, gibt esauch hier keinen deutlichen Unterschied zwischen Laufzeiten der einzelnen Versuche.
Insgesamt haben die Steuerparameter fur den gewahltem Datensatz keine signifikanteAuswirkung auf die Laufzeit des Algorithmus. Dieses mag jedoch der dem geringenUmfang des Testdatensatzes geschuldet sein.
107
K Laufzeit Zahlen Suchen Aggregierung50 03:41 02:54 00:29 00:18250 03:26 02:42 00:26 00:18500 03:46 03:00 00:31 00:15
2.500 03:36 02:50 00:31 00:15
Tabelle 5.10: Laufzeit bei einer verschiedenen Anzahl auszugebener frequent Itemsetspro Item (100 Gruppen, minSup = 10)
5.1.4 Performancevergleich zwischen MR-Partitition und PFP-Growth
Effektiv ist ein Vergleich der beiden Verfahren auf großen Datenmengen nicht moglich.Die Ausfuhrung des MapPartition-Algorithmus mit dem Datensatz webdocs.dat brichtbereits nach wenigen Minuten wegen Speichermangels ab. Mit einer sequentiellen Im-plementierung des Partition-Algorithmus wurde ermittelt, wie viele frequent Itemsets inden einzelnen Iterationen entstehen (Tabelle 5.11). Bereits bei sehr kleinen Datenmen-gen werden unheimlich große Mengen (> 400.000) frequent Itemsets gefunden, wenn einsehr kleiner minimaler Support (hier 0,0001) gewahlt.
Itemset-Lange Anzahl Itemsets1 8672 110.7933 152.8054 80.7105 39.9546 16.1727 6.2258 2.4739 95410 31811 8012 1313 114 0
Gesamt 411.365Laufzeit 749 Sekunden
Tabelle 5.11: Anzahl gefundener frequent Itemsets fur T10I4D100K.dat
Eine Suche mit demselben minimalen Support von 0,0001 mit dem Datensatz T40I10-D100K.dat wurde nach 7 Stunden und 3 Minuten abgebrochen. Zu diesem Zeitpunkt hat-te der Algorithmus bereits 924 Itemsets der Lange 1, 179.740 der Lange 2 und 1.383.971
108
Itemsets der Lange 3 geliefert. Ein Ausfuhrung des Algorithmus ist also generell nur beieinem relativ großen Support moglich.
Im Gegensatz dazu steht die Ausfuhrung der Versuche aus Abschnitt 5.1.2, die mitdem MR-Partition-Algorithmus durchgefuhrt wurden, mit dem Parallel FP-Growth-Algorithmus.
minimaler Support T10I4D100K T40I10D100K accidents0,01 (1.000 Transaktionen) 00:51 00:49 00:530,001 (100 Transaktionen) 00:44 00:47 00:540,0001 (10 Transaktionen) 00:54 00:49 00:49
Tabelle 5.12: PFP-Algorithmus - Test mit verschiedenen Datensatzen
Die Ergebnisse (Tabelle 5.12) zeigen auch, dass die Laufzeit des Algorithmus auch beidiesen Versuchen weitestgehend unabhangig von der Parameterzahl ist und die Daten-satze, im Gegensatz zum problemlos verarbeitet werden konnen.
5.2 Clusteranalyse
In den Versuchsreihen mit den beiden Clustering-Algorithen, dem MapReduce-kMeans-und MapReduce-DBSCAN-Algorithmus, sollen die Verhaltensweisen der Algorithmenunter verschiedenen Einflussen getestet werden. Es soll zum einen untersucht werden,wie sich unterschiedliche Blockgroßen der Eingabedaten und Knotenzahlen auf denMapReduce-kMeans-Algorithmus auswirken, fur den MapReduce-DBSCAN-Algorithmussollen das Laufzeitverhalten bei verschiedenen Steuerparameterauspragungen und Kno-tenzahlen untersucht werden. Abschließend werden beide Algorithmen in einem Versuchgegeneinander getestet.
Als Testdaten fur das Clustering kommen zwei verschiedene Geodatensatze von Open-StreetMap zum Einsatz. Bei diesen handelt es sich um die Datensatze fur Deutschlandund Europa, die von der Geofabrik GmbH5 bereitgestellt werden. Aus diesen Daten-satzen werden lediglich die ”Road”-Objekte genutzt. Aus dessen Geometrien werden diePunkt-Koordinaten extrahiert und von Duplikaten befreit. Als Format fur diese wirddas SequenceFileFormat genutzt, so dass als Schlussel die Zeilennummer und als Wertder Punkt in Form eines zweidimensionalen Vektors verwendet wird. Die Eingabedatenbesitzen die folgenden Charakteristika:
• DE - Deutschland, 7.949.433 Punkte (248 MB)
• EU - Europa, 64.684.856 Punkte (2,3 GB)
5http://download.geofabrik.de/
109
5.2.1 Auswirkungen der Blockgroße und Knotenanzahl auf dieLaufzeit am Beispiel des MR-kMeans-Algorithmus
In diesem Versuch wird untersucht, wie sich eine variable Blockgroße fur im HDFSgespeicherten Dateien sowie eine verschiedene Anzahl von Rechenknoten auf die Laufzeitder MapReduce-Implementierung auswirkt. Fur diese Betrachtung wird explizit der MR-kMeans-Algorithmus genutzt, da er so gut wie keine sequentiellen Komponenten enthaltund somit ideal fur einen Vergleich verschiedener Knotenzahlen ist. Getestet werden zumeinen die Laufzeiten, wenn nur bestimmte Knoten des Clusters verwendet werden sowiedie Auswirkungen auf die Laufzeit bei Blockgroßen von 32 MB, 64 MB und 128 MB.Fur den Versuch werden die Straßendaten von Europa (Testdatensatz EU) verwendet.
Blockgroße 1 Knoten 2 Knoten 3 Knoten32 MB 16:02 min 06:41 min 02:39 min64 MB 13:35 min 04:53 min 02:21 min128 MB 12:18 min 05:16 min 02:23 min
Tabelle 5.13: Ergebnisse der Versuche mit dem MR-kMeans-Algorithmus fur variableKnotenzahl und Blockgroße
Die Ergebnisse in Tabelle 5.13 zeigen hinsichtlich der Blockgroße, dass diese nur beider Verwendung von einem Rechenknoten gravierende Anderungen bewirken, bzw. beizwei Rechenknoten nur beim Sprung von 32 MB auf 64 MB eine signifikante Laufzeit-verbesserung bewirken. Bei der Verwendung von drei Rechenknoten ist bereits keineUnterscheidung der Laufzeit bei verschiedenen Blockgroßen mehr moglich. Die starkenUnterschiede der Laufzeit bei unterschiedlichen Blockgroßen bei einem Knoten erklarensich durch die Tatsache, dass fur jeden Teil der Eingabe ein Map-Tasks erzeugt wird.Eine geringe Blockgroße bedeutet folglich, dass eine großere Anzahl von Map-Tasks ge-neriert wird, was dann zu einem großeren Overhead fuhrt fur das Starten und Beendenvon JVMs, die die Tasks ausfuhren.
In Bezug auf die Laufzeit bei Verwendung einer verschiedenen Anzahl von Rechenknotenlasst sich unabhangig von der Blockgroße festhalten, dass der Speed-Up annahernd linearist; eine Verdoppelung der Rechenkapazitat fuhrt grob zu einer Halbierung der Laufzeit,was anschaulich in Abbildung 5.3 zu sehen ist.
5.2.2 Einfluss der Parameterwahl und Knotenzahl auf den MR-DBSCAN-Algorithmus
In diesem Abschnitt wird eine experimentelle Untersuchung des MR-DBSCAN-Algo-rithmus durchgefuhrt. Hierbei stehen die drei Parameter zur Steuerung der maximalen
110
Abbildung 5.3: Einfluss verschiedener Blockgroßen und Knotenzahlen auf die Laufzeit
Partitionsgroße, der Nachbarschaftsgroße sowie des fur Kernpunkte notwendigen Nach-barschaftsumfangs im Mittelpunkt. Die Untersuchung wird in drei verschiedene Versucheaufgeteilt. Im ersten Versuch wird der Einfluss der Partitionsgroße auf die Laufzeit desAlgorithmus untersucht. Im zweiten Versuch wird betrachtet, welche Auswirkungen dieWahl der Nachbarschaftsgroße sowie die Anzahl der fur Kernpunkte notwendigen Punkt-zahl sich auf die Laufzeit auswirken. Eine Untersuchung des Speed-Up wird in einemdritten Versuch vorgenommen. Hierbei wird bei einer festen Parameterwahl und varia-bler Knotenzahl untersucht, wie sich eine unterschiedliche Anzahl von Rechenknoten aufdie Gesamtlaufzeit auswirkt. Die Versuche werden auf drei Rechenknoten ausgefuhrt.Map- und Reduce-Tasks stehen 1GB Speicher pro Tasks zur Verfugung, wovon 768MBfur den Heap der JVM, die den Task ausfuhrt, bereitgestellt werden. Verwendet wirdder Datensatz DE mit den Straßendaten von OpenStreetMap fur Deutschland.
Partitionsgroße
In einem ersten Test mit des MR-DBSCAN-Algorithmus soll die Auswirkung der Par-titionsgroße auf die Laufzeit des Algorithmus getestet werden. Der Test wird mit 3Rechenknoten auf dem DE-Datensatz ausgefuhrt fur minPts = 350 und ε = 1500, wo-bei fur jeden Task 1GB Speicher bereitgestellt wird, von welchem 768MB als Heap furdie ausfuhrende Java-VM verwendet werden.
111
Abbildung 5.4: Laufzeit in den einzelnen Phasen des MR-DBSCAN-Algorithmus fur denDE-Datensatz
Was auf den ersten Blick in den Ergebnissen aus Abbildung 5.4 ins Auge fallt sind diestarken Ausreißer fur das Clustering und das Relabeling der Daten fur eine maximalePartitionsgroße von 5000 Punkten. Es ist klar, dass bei einer derart geringen Anzahl vonPunkten pro Partition eine große Anzahl von Partitionen gebildet wird. Fur jede vondiesen wird ein Reduce-Tasks erzeugt, so dass die schiere Anzahl von abzuarbeitendenTasks und dem daraus resultierenden Overhead fur die lange Laufzeit verantwortlichsind. Die Ursache fur die lange Laufzeit des Relabelings sind der Tatsache geschuldet,dass es durch die große Anzahl von Partitionen eine entsprechende hohe Anzahl von an-einander angrenzenden Paaren von Partitionen gibt. Folglich existiert eine große Anzahlvon Punkten in Uberlappungsbereichen, so dass fur eine großere Anzahl von Punktenmindestens zwei verschiedene Klassifikationen und Clusteridentifikatoren vorliegen, dievereinheitlicht mussen. Zusatzlich ist in den Ergebnissen gut zu sehen, dass bereits abeiner Partitionsgroße von 100.000-250.000 Punkten fur den verwendeten Testdatensatzeine Reduzierung der Laufzeit mehr festzustellen ist.
Abbildung 5.5 zeigt die Laufzeit der einzelnen Testlaufe noch einmal reduziert auf dieGesamtlaufzeit. Es zeigt sich, dass die Laufzeit des Algorithmus fur den gewahlten Da-tensatz bis zu einer Partitionsgroße von 250.000 Punkten mit jeder Verdoppelung derGroße etwa um ein Drittel reduziert wird.
112
Abbildung 5.5: Gesamtlaufzeit des MR-DBSCAN-Algorithmus fur den DE-Datensatzmit 3 Knoten, minPts = 50, ε = 250
Anzahl der Rechenknoten
In diesem Versuch wird die Laufzeit des MR-DBSCAN-Algorithmus untersucht, wenneine unterschiedliche Anzahl von Rechenknoten fur die Berechnung verwendet. Als Para-meter wurden hier eps = 1500 und minPts = 350 und eine Partitionsgroße von 250.000Punkten verwendet.
Die Betrachtung der Gesamtlaufzeit (Abbildung 5.6) zeigt, das das Verfahren im Rahmendieses Versuches einen linearen Speed-Up besitzt; eine Verdoppelung der Rechenleistungbedeutet also eine Halbierung der Laufzeit.
Eine genauere Betrachtung der Laufzeit (Abbildung 5.7) der einzelnen Phasen des Algo-rithmus zeigt, dass besonders das Clustering und das Relabeling von einer Erhohung derKnotenzahl profitieren. Bei diesen fuhrt eine Verdopplung der Rechenleistung hier anna-hernd zu einer Halbierung der Laufzeit. Wenig Einfluss hat die Knotenzahl hingegen aufdie Berechnung des MER des Datensatzes, der Partitionierung und der Vereinigungsab-bildung. Fur die Berechnung des MERs ist eine signifikante Auswirkung erst zu erwarten,wenn die zu verarbeitende Datenmenge stark ansteigt, so dass das parallele Lesen derEingabedaten davon profitiert. Ahnliches gilt fur die Partitionierung, da die Berechnung
113
Abbildung 5.6: Gesamtlaufzeit des MR-DBSCAN-Algorithmus bei variabler Knotenzahl
der Teilergebnisse zur Bestimmung eines Rasters mit der Punktdichteverteilung des Da-tensatzes so auf mehrere Rechenknoten verteilt werden kann. Nicht betroffen hiervon istjedoch die eigentliche Berechnung der Partitionen, die rein sequentiell auf einem Kno-ten ausgefuhrt; hier ist fur eine Erhohung der Knotenzahl keine Laufzeitreduktion zuerwarten. Fur das Erzeugung der Vereinigungsabbildung ist nur bei einer großen Men-ge von Punkten in Uberlappungsbereichen mit einer Beschleunigung der Map-Phase zurechnen, in dessen Folge mehrere Map-Tasks fur die Berechnung der Punkt-Paare ausuberlappenden Partitionsrandern erzeugt werden. Die Reduce-Phase ist hiervon unbe-einflusst, da die Erzeugung der eigentlichen Abbildung sequentiell in einem Reduce-Taskausgefuhrt wird.
Variation der Nachbarschaftsgroße
In diesem Versuch wird untersucht, wie sich der Algorithmus verhalt, wenn die Großeder Nachbarschaft variiert. Verwendet wurden 3 Rechenknoten, die Partitionsgroße liegtbei 250.000 Punkten und die Kernpunktklassifikation betragt 350.
Die Betrachtung der Gesamtlaufzeiten in Abbildung 5.8 zeigt recht anschaulich, dassNachbarschaftsgroßen von weniger als 500 zu einer massiven Verlangerung der Laufzeitfuhren. Die zentrale Ursache hierfur liegt in der Tatsache, dass der gesamte Datensatzin Raster unterteilt wird, in der jede Rasterzelle die Kantenlange ε, also die Nachbar-schaftsgroße, besitzt. Eine kleine Nachbarschaft bedeutet also zwangslaufig, dass eineRasterisierung mit vielen Zellen entstehen. Hieraus entstehen gravierende Folgen fur dieBerechnung der Partitionierung. Dies bedeutet zum einen, dass fur die binare Recht-eckaufteilung viele Schnittlinien und folglich viele verschiedene Varianten von Rechteck-
114
Abbildung 5.7: Aufgeschlusselte Laufzeiten des MR-DBSCAN-Algorithmus bei variablerKnotenzahl
Unterteilungen in Frage kommen, die zu testen sind. Zum anderen bedeutet dies, dassfur die Kostenberechnung der Rechtecke eine große Menge von Zellen betrachtet werdenmuss, die von den resultierenden Rechtecken uberdeckt werden.
Festzuhalten ist weiterhin, dass fur eine Nachbarschaftsgroße von 1000 oder 2000 in derGesamtlaufzeit keine Unterschiede vorhanden sind. Eine Betrachtung der aufgeschlus-selten Laufzeiten (Abbildung 5.9) der einzelnen Phasen zeigt jedoch, dass eine Verdop-pelung der Nachbarschaftsgroße von 1000 auf 2000 zu einer Verdoppelung der Laufzeitdes Clusterings fuhrt.
Diese wird jedoch ausgeglichen durch eine starke Reduktion der Laufzeit der Partitio-nierung, da durch die großere Nachbarschaft weniger Rasterzellen und folglich wenigerSchnittlinien entstehen, die fur die binare Rechteckunterteilung betrachtet werden mus-sen.
Gleichzeitig bedeutet eine großere Nachbarschaft auch, dass die Uberlappungsbereicheder Partitionen großer werden. In der Folge gibt es mehr Punktpaare in diesen Uberlap-pungsbereichen, die fur die Berechnung der Vereinigungsabbildung verarbeitet werdenmussen. Dies hat ebenfalls zur Folge, dass fur die Umbennung mehr Punkte verarbeitet
115
Abbildung 5.8: Gesamtlaufzeit des MR-DBSCAN-Algorithmus bei variabler Nachbar-schaftsgroße
werden mussen, fur die mehr als ein Paar von Klassifikation und Cluster-Identifikatorexistiert.
Variation der Kernpunktklassifikation
In diesem Versuch wird untersucht, wie sich die Anzahl der Punkte, die fur eine Klassi-fikation als Kernpunkt notwendig sind, auf die Laufzeit des Algorithmus auswirkt.
Ein Blick auf die Gesamtlaufzeit (Abbildung 5.10) zeigt, dass die Kernpunktklassifikationkeine messbaren Einfluss auf die Gesamtlaufzeit des Algorithmus hat.
Wird jedoch die detaillierte Laufzeit der einzelnen Phasen (Abbildung 5.11) betrachtet,so zeigt sich, dass die Laufzeit des Clusterings bei einer großeren Anzahl notwendigerKernpunkte etwas ansteigt. Außerdem bedeutet dies auch, das weniger Punkte in denRandbereichen als Kernpunkte klassifiziert werden, so dass sich gleichzeitig die Laufzeitzur Berechnung der Vereinigungsabbildung reduziert, da weniger Punkte in den uber-lappenden Partitionsbereichen betrachtet werden mussen.
116
Abbildung 5.9: Aufgeschlusselte Laufzeiten des MR-DBSCAN-Algorithmus bei variablerNachbarschaftsgroße
Ein Beispiel fur ein Clustering des DE-Datensatzes mit MapReduce-DBSCAN-Algorith-mus ist in Abbildung 5.12 dargestellt. Dieses wurde mit einer Kernpunktklassifikationvon 350 Punkten, einer Nachbarschaftsgroße von 1500 und einer Partitionsgroße von250.000 Punkten durchgefuhrt.
5.2.3 MapReduce-kMeans und MapReduce-DBSCAN im Ver-gleich
In diesem Versuch werden die beiden Cluster-Algorithmen direkt gegenubergestellt. Die-se werden auf dem DE und EU Datensatz ausgefuhrt. Fur den MR-kMeans-Algorithmuswerden 50 Zentroide zufallig aus der Datenmenge ausgewahlt und eine Iteration ausge-fuhrt. Fur den MR-DBSCAN-Algorithmus wird eine Nachbarschaftsgroße von 3.000,eine Kernpunktklassifikation von 1.000 und eine Partitionsgroße von 750.000 Punktenverwendet. Die Hadoop-Konfiguration wurde fur diesen Versuch dahingehend verandert,dass jedem Container 1,5 GB Speicher zu Verfugung stehen, von denen 1,2 GB von derJVM als Heap genutzt werden konnen.
Die Ergebnisse in Tabelle zeigen recht deutlich, dass der MR-kMeans-Algorithmus eineIteration bedeutend schneller ausfuhrt als der MR-DBSCAN-Algorithmus. Trotz eineretwa 8-mal großeren Punktmenge steigt die Laufzeit nicht im selben Umfang an. DieLaufzeit des MR-DBSCAN-Algorithmus steigt um etwa das 18-fache.
117
Abbildung 5.10: Gesamtlaufzeit des MR-DBSCAN-Algorithmus bei variabler Kern-punktklassifikation
Europa DeutschlandMR-DBSCAN 03:14:17 00:11:15MR-kMeans 00:02:12 00:00:47
Tabelle 5.14: Laufzeitvergleich MR-DBCSCAN und MR-kMeans
DE EUMBR 18s 1m 4s
Partitionierung 20s 2h 58m 3sClustering 9m 7s 5m 9s
Merge-Mapping 30s 2m 21sUmbenennung 1m 7m 40s
Gesamtzeit 11m 15s 3h 14m 17s
Tabelle 5.15: Einzellaufzeiten des MR-DBSCAN-Algorithmus
Eine Betrachtung der Laufzeiten der einzelnen Phasen (Tabelle 5.15) zeigt, dass diePartitionierung fur den massiven Laufzeitanstieg verantwortlich ist. Hier treten die sel-ben Effekte auf, die bereits in den Tests des MR-DBSCAN-Algorithmus auf dem DE-Datensatz mit verschiedenen Nachbarschaftsgroßen in Abschnitt 5.2.2 beobachtet wur-den. In diesem Fall treten die Effekte jedoch auch bei großen Nachbarschaften wegen
118
Abbildung 5.11: Aufgeschlusselte Laufzeiten des MR-DBSCAN-Algorithmus bei varia-bler Kernpunktklassifikation
der großen raumlichen Ausdehnung der Daten auf. Die Ursache hierfur liegt in der Ver-rasterung des minimal-einschließenden Rechtecks des Datensatzes, welches zu einer sehrgroßen Anzahl von Rasterzellen mit einer Kantenlange, die dem Radius der Nachbar-schaftsgroße entspricht, fuhrt. Entsprechend groß ist folglich die Anzahl der Zellen, diefur jede Kostenberechnung eines Rechtecks wahrend der Partitionierung betrachtet wer-den muss. Ein interessanter Effekt ist weiterhin, dass die Laufzeit des Clusterings furden DE-Datensatz fast doppelt so lange dauert wie fur den EU-Datensatz.
Fazit
Auf den ersten Blick erscheint es, als sei der MapReduce-kMeans-Algorithmus fur dasClustering raumlicher Daten die deutlich bessere Losung. Nicht vergessen werden darfjedoch, dass in der Regel mehrere Iteration notwendig sind, bis die finalen Clusterschwer-punkte gefunden worden sind. Zusatzlich sind gegebenenfalls mehrere Anwendungen desVerfahrens oder eine Vorabanalyse der Daten notwendig, um eine passende Anzahl so-wie Position initialer Clusterschwerpunkte zu bestimmen. Die reine Reduktion auf dieLaufzeit einer Iteration ist folglich nicht geeignet, um ein Urteil uber die grundsatzli-che Tauglichkeit oder Untauglichkeit eines Verfahrens zu treffen, zumal die Wahl desVerfahrens maßgeblich von der Aufgabenstellung bestimmt wird.
119
Abbildung 5.12: Visualisierung des Clusterings fur die Versuche in 5.2.2
120
Kapitel 6
Fazit
Die Versuche, die in Kapitel 5 durchgefuhrt wurden, zeigen, dass das MapReduce-Paradigma nicht fur jedes Problem das Mittel der Wahl und nicht jeder Algorithmusgeeignet ist. Verfahren wie der Partition-Algorithmus, die bereits bei sequentieller Aus-fuhrung mit kleinen Datenmengen Probleme habe, lassen sich auch durch MapReduce-Implementierungen nicht effizient nutzen.
Grenzwertig sind Verfahren wie der MapReduce-DBSCAN-Algorithmus, welche inner-halb der Prozessausfuhrung sequentielle Phasen durchlaufen. So wird der Algorithmusdurch die sequentielle Berechnung einer adaptiven Partitionierung des Datensatzes furDatensatze mit einer großen raumlichen Ausdehnung massiv verlangsamt. Wie bereitsin Abschnitt 5.2.3 dargelegt, ist eine gezielte Optimierung von Engpassen notwendig,um eine Ausfuhrung in akzeptabler Zeit zu gewahrleisten. Dieses gilt hier insbesonderevor dem Hintergrund, dass bestimmte Problemstellungen moglicherweise einen kleinenNachbarschaftsradius erfordern; auf einem Datensatz mit großer raumlicher Ausdehnungkonnte dies zur Folge, dass eine Berechnung der Partitionierung eventuell gar nicht mog-lich ist, da der Speicherbedarf fur die Reprasentation des Rasters bereits den verfugbarenSpeicher uberschreitet. Folglich besteht an dieser Stelle Optimierungsbedarf. Vorstellbarist hierfur eine Entkopplung der Rasterzellengroße vom Radius der Nachbarschaftsan-fragen, so dass die Große der Rasterzellen separat definiert wird.
Ganz anders sieht es hingegen beim MapReduce-kMeans- und Parallel FP-Growth-Algorithmus aus. Diese kommen weitestgehend ohne sequentielle Phasen aus und pro-fitieren somit von der Parallelisierungsmoglichkeiten, die sich aus dem MapReduce-Paradigma ergibt.
Bei den Versuchen hat sich ebenfalls gezeigt, dass die Konfiguration der Ressourcen-Nutzung aufwandig sein kann. Es ist gegebenenfalls eine Justierung der Speicherkon-figuration in Try-and-Error-Manier notwendig, bis die Ausfuhrung einer MapReduce-Anwendung gelingt, ohne dass einzelne Tasks wegen Speichermangels von der ausfuhren-
121
den JVM terminiert werden. Dieses tritt insbesondere verstarkt in Erscheinung, wennAnwendungsparameter wie die Nachbarschafts- oder Partitionsgroße des MapReduce-DBSCAN-Algorithmus starken Einfluss auf den Speicherbedarf der einzelnen Jobs einerAnwendung haben.
Zusatzlich hat sich beim Aufsetzen des Hadoop-Clusters das geringe Alter und die hohemomentane Entwicklungsgeschwindigkeit von Hadoop bemerkbar gemacht. Die offizielleDokumentation fur aktuelle Versionen ist teilweise sehr durftig, wahrend sich inoffizielleDokumentation beispielsweise in Blogs oftmals auf veraltete Versionen bezieht nicht ohneweiteres auf neue Versionen ubertragbar.
Zusammenfassend lasst sich sagen, dass das MapReduce-Paradigma eine sehr gute Grund-lage fur die Parallelisierung von Data Mining-Algorithmen ist. Dieses liegt insbesonderein der Tatsache begrundet, dass fur die Implementierung von Verfahren keinerlei Kennt-nisse uber parallele Softwareentwicklung vorhanden sein muss und somit wahrend derEntwicklung der Aufwand zur Fehlersuche von beispielsweise Race-Conditions und ahn-lichen Problemen, die in parallelen Programmen auftreten konnen, wegfallt. Zusatzlichist die Erweiterung eines Hadoop-Clusters um zusatzliche Rechenknoten sehr einfach; esmuss im wesentlichen nur Hadoop und die Knotenkonfiguration auf eine neue Maschinekopiert werden. Im Gegenzug sind naturlich tiefgehende Kenntnisse uber die Funktions-weise von Hadoop, bzw. der jeweils verwendeten MapReduce-Implementierung, notwen-dig, um effiziente Programme zu schreiben, die alle Moglichkeiten zur Parallelisierungausreizen.
Zwar ist das MapReduce-Paradigma und die zugehorigen Implementierungen noch ver-haltnismaßig jung, jedoch ist zu erwarten, dass dieses in Zukunft einen festen Platz ein-nehmen wird, wenn es um massiv-parallele Datenanalyse mittels Data Mining-Algorithmengeht.
122
Abbildungsverzeichnis
2.1 Der KDD-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Beispiel eines Frequent-Pattern Baums . . . . . . . . . . . . . . . . . . . 17
2.3 Konstruktion eines FP-Baumes . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Beispiel fur die Generierung von Itemsets aus einem FP-Baum . . . . . . 21
2.5 Hierarchisches Clustering - Beispiel . . . . . . . . . . . . . . . . . . . . . 23
2.6 beispielhafte Darstellung des k-Means Algorithmus . . . . . . . . . . . . 25
2.7 ε-Nachbarschaft . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.8 DBSCAN - Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.9 MapReduce-Beispiel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.10 Der MapReduce-Prozess . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.11 Ablauf der Ausfuhrung einer MapReduce-Anwendung mit dem YARN-Framework [Whi12] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.1 Ablaufdiagramm des PFP-Algorithmus (nach [LWZ+08]) . . . . . . . . . 51
3.2 Die 90-10-Regel im hierarchischen Clustering . . . . . . . . . . . . . . . . 56
3.3 POP-Algorithmus - Uberlappende Partitionen . . . . . . . . . . . . . . . 57
3.4 Beispielhafte Abbildung der Phasen des DSDBSCAN-Algorithmus (nach[PPA+12]) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.5 Ablauf des MR-DBSCAN-Algorithmus [HTL+14] . . . . . . . . . . . . . 66
3.6 Beispiel fur kostenbasierte Partitionierung [HTL+14] . . . . . . . . . . . 69
3.7 Beispiel einer Partitionierung mit ε-Randbereichen [HTL+14] . . . . . . . 71
3.8 Beispiel einer minimal vollstandigen Partitionierungsmenge [HTL+14] . . 72
3.9 Beispiel eines Vereinigungs-Mappings . . . . . . . . . . . . . . . . . . . . 77
3.10 Graph-Reprasentation des Vereinigungs-Mappings . . . . . . . . . . . . . 78
123
3.11 Beispiel fur den Ablauf der Vereinigung sechs lokaler Dendrogramme zueinem globalen Dendrogramm (nach [HPA+12]) . . . . . . . . . . . . . . 80
3.12 SHRINK-Algorithmus - Beispiel . . . . . . . . . . . . . . . . . . . . . . . 84
3.13 MapReduce k-Means - Datenfluss . . . . . . . . . . . . . . . . . . . . . . 85
4.1 Ablauf der MapReduce-Implementierung des Partition-Algorithmus . . . 91
4.2 Ablauf der Implementierung des MR-DBSCAN-Algorithmus . . . . . . . 94
5.1 Laufzeit PFP-Algorithmus (Gruppen: 10, Support: 10, K: 50) . . . . . . 106
5.2 Laufzeiten der einzelnen Teile des PFP-Algorithmus . . . . . . . . . . . . 107
5.3 Einfluss verschiedener Blockgroßen und Knotenzahlen auf die Laufzeit . . 111
5.4 Laufzeit in den einzelnen Phasen des MR-DBSCAN-Algorithmus fur denDE-Datensatz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
5.5 Gesamtlaufzeit des MR-DBSCAN-Algorithmus fur den DE-Datensatz mit3 Knoten, minPts = 50, ε = 250 . . . . . . . . . . . . . . . . . . . . . . 113
5.6 Gesamtlaufzeit des MR-DBSCAN-Algorithmus bei variabler Knotenzahl . 114
5.7 Aufgeschlusselte Laufzeiten des MR-DBSCAN-Algorithmus bei variablerKnotenzahl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.8 Gesamtlaufzeit des MR-DBSCAN-Algorithmus bei variabler Nachbarschafts-große . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
5.9 Aufgeschlusselte Laufzeiten des MR-DBSCAN-Algorithmus bei variablerNachbarschaftsgroße . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
5.10 Gesamtlaufzeit des MR-DBSCAN-Algorithmus bei variabler Kernpunkt-klassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5.11 Aufgeschlusselte Laufzeiten des MR-DBSCAN-Algorithmus bei variablerKernpunktklassifikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.12 Visualisierung des Clusterings fur die Versuche in 5.2.2 . . . . . . . . . . 120
124
Tabellenverzeichnis
3.1 Ubersicht und Notation der verschiedenen Itemset-Mengen . . . . . . . . 44
5.1 Beispiel-Transaktionsdatenbank . . . . . . . . . . . . . . . . . . . . . . . 101
5.2 Haufige 1-Itemsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.3 Haufige 2-Itemsets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.4 3-Itemset Kandidaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.5 Gruppenabhangige Shards . . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.6 Anzahl gefundener Itemsets . . . . . . . . . . . . . . . . . . . . . . . . . 103
5.7 Testresultate fur den MR-Partition-Algorithmus . . . . . . . . . . . . . . 104
5.8 Laufzeit bei variabler Gruppenzahl (minSup = 10, K = 500) . . . . . . . 106
5.9 Laufzeit bei unterschiedlichem minimalen Support (100 Gruppen, K = 500)107
5.10 Laufzeit bei einer verschiedenen Anzahl auszugebener frequent Itemsetspro Item (100 Gruppen, minSup = 10) . . . . . . . . . . . . . . . . . . . 108
5.11 Anzahl gefundener frequent Itemsets fur T10I4D100K.dat . . . . . . . . . 108
5.12 PFP-Algorithmus - Test mit verschiedenen Datensatzen . . . . . . . . . . 109
5.13 Ergebnisse der Versuche mit dem MR-kMeans-Algorithmus fur variableKnotenzahl und Blockgroße . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.14 Laufzeitvergleich MR-DBCSCAN und MR-kMeans . . . . . . . . . . . . 118
5.15 Einzellaufzeiten des MR-DBSCAN-Algorithmus . . . . . . . . . . . . . . 118
125
Literaturverzeichnis
[AHU83] A. V. Aho, J. E. Hopcroft, J. D. Ullman. Data Structures And Algorithms.Addison-Wesley Publishing Company, 1983. ISBN 0-201-00023-7.
[AS94] R. Agrawal, R. Srikant. Fast Algorithms for Mining Association Rules inLarge Databases. In J. B. Bocca, M. Jarke, C. Zaniolo, Hg., Proc. VLDB.Morgan Kaufmann, 1994. ISBN 1-55860-153-8, 487–499.
[BCC10] E. Baralis, T. Cerquitelli, S. Chiusano. A persistent HY-Tree to efficient-ly support itemset mining on large datasets. In S. Y. Shin, S. Ossowski,M. Schumacher, M. J. Palakal, C.-C. Hung, Hg., SAC. ACM, 2010. ISBN978-1-60558-639-7, 1060–1064.
[BCCG13] E. Baralis, T. Cerquitelli, S. Chiusano, A. Grand. P-Mine: Parallel itemsetmining on large datasets. In C. Y. Chan, J. Lu, K. Nørvag, E. Tanin, Hg.,ICDE Workshops. IEEE Computer Society, 2013. ISBN 978-1-4673-5303-8,266–271.
[Bre13] J. Brehm. Parallelrechner. Vorlesungsfolien, 2013.
[DG04] J. Dean, S. Ghemawat. MapReduce: Simplified Data Processing on LargeClusters. In Proc. OSDI. USENIX Association, 2004, 137–150.
[DL01] M. Dash, H. Liu. Efficient Hierarchical Clustering Algorithms Using PartiallyOverlapping Partitions. In D. W.-L. Cheung, G. J. Williams, Q. Li, Hg.,PAKDD, Bd. 2035 von Lecture Notes in Computer Science. Springer, 2001.ISBN 3-540-41910-1, 495–506.
[DPS07] M. Dash, S. Petrutiu, P. Scheuermann. pPOP: Fast yet accurate parallelhierarchical clustering using partitioning. Data Knowl. Eng., 61(3), 2007,563–578.
[EKSX96] M. Ester, H.-P. Kriegel, J. Sander, X. Xu. A Density-Based Algorithm forDiscovering Clusters in Large Spatial Databases with Noise. In E. Simoudis,J. Han, U. M. Fayyad, Hg., Proc. KDD. AAAI Press, 1996. ISBN 1-57735-004-9, 226–231.
126
[ES00] M. Ester, J. Sander. Knowledge Discovery in Databases. Springer-Verlag,2000. ISBN 3-540-67328-8.
[HKP11] J. Han, M. Kamber, J. Pei. Data Mining - Concepts and Techniques. MorganKaufmann, 2011.
[HPA+12] W. Hendrix, M. M. A. Patwary, A. Agrawal, W. Liao, A. N. Choudhary.Parallel hierarchical clustering on shared memory platforms. In Proc. HiPC.IEEE, 2012. ISBN 978-1-4673-2372-7, 1–9.
[HPY00] J. Han, J. Pei, Y. Yin. Mining Frequent Patterns without Candidate Genera-tion. In W. Chen, J. F. Naughton, P. A. Bernstein, Hg., SIGMOD Conference.ACM, 2000. ISBN 1-58113-218-2, 1–12.
[HTL+14] Y. He, H. Tan, W. Luo, S. Feng, J. Fan. MR-DBSCAN: a scalableMapReduce-based DBSCAN algorithm for heavily skewed data. Frontiersof Computer Science, 8(1), 2014, 83–99.
[KPP03] W. A. Kosters, W. Pijls, V. Popova. Complexity Analysis of Depth First andFP-Growth Implementations of APRIORI. In P. Perner, A. Rosenfeld, Hg.,MLDM, Bd. 2734 von Lecture Notes in Computer Science. Springer, 2003.ISBN 3-540-40504-6, 284–292.
[LWZ+08] H. Li, Y. Wang, D. Zhang, M. Zhang, E. Y. Chang. Pfp: parallel fp-growthfor query recommendation. In P. Pu, D. G. Bridge, B. Mobasher, F. Ricci,Hg., Proc. RecSys. ACM, 2008. ISBN 978-1-60558-093-7, 107–114.
[Mei13] A. Meier. Efficient Algorithms. Vorlesungsskript, 2013.
[OH11] R. O. Obe, L. S. Hsu. PostGIS In Action. Manning Publications Co., 2011.
[PPA+12] M. A. Patwary, D. Palsetia, A. Agrawal, W.-k. Liao, F. Manne, A. Choud-hary. A New Scalable Parallel DBSCAN Algorithm Using the Disjoint-setData Structure. In In Proceedings of the International Conference on HighPerformance Computing, Networking, Storage and Analysis, SC ’12. IEEEComputer Society Press, Los Alamitos, CA, USA, 2012. ISBN 978-1-4673-0804-5, 62:1–62:11.
[RDFU12] M. Riondato, J. A. DeBrabant, R. Fonseca, E. Upfal. PARMA: A Par-allel Randomized Algorithm for Approximate Association Rules Mining inMapReduce. In Proceedings of the 21st ACM International Conference onInformation and Knowledge Management, CIKM ’12. ACM, New York, NY,USA, 2012. ISBN 978-1-4503-1156-4, 85–94.
[RU11] A. Rajaraman, J. D. Ullman. Mining of Massive Datasets. Cambridge Uni-versity Press, 2011.
127
[Sib73] R. Sibson. SLINK: An Optimally Efficient Algorithm for the Single-LinkCluster Method. Comput. J., 16(1), 1973, 30–34.
[SON95] A. Savasere, E. Omiecinski, S. B. Navathe. An Efficient Algorithm for MiningAssociation Rules in Large Databases. In U. Dayal, P. M. D. Gray, S. Nishio,Hg., Proc. VLDB. Morgan Kaufmann, 1995. ISBN 1-55860-379-4, 432–444.
[TSK05] P. Tan, M. Steinbach, V. Kumar. Introduction to Data Mining. Addison-Wesley, 2005.
[WD11] S. Wang, H. Dutta. PARABLE: A PArallel RAndom-partition Based Hier-archicaL ClustEring Algorithm for the MapReduce Framework. Techn. Ber.,Columbia University, 2011.
[Whi12] T. White. Hadoop - The Definitive Guide. O’Reilly, 2012.
[XJK99] X. Xu, J. Jager, H.-P. Kriegel. A Fast Parallel Clustering Algorithm for LargeSpatial Databases. Data Min. Knowl. Discov., 3(3), 1999, 263–290.
[ZEHL01] O. R. Zaıane, M. El-Hajj, P. Lu. Fast Parallel Association Rule Miningwithout Candidacy Generation. In N. Cercone, T. Y. Lin, X. Wu, Hg., ICDM.IEEE Computer Society, 2001. ISBN 0-7695-1119-8, 665–668.
[ZMH09] W. Zhao, H. Ma, Q. He. Parallel K-Means Clustering Based on MapRedu-ce. In Proceedings of the 1st International Conference on Cloud Computing,CloudCom ’09. Springer-Verlag, Berlin, Heidelberg, 2009. ISBN 978-3-642-10664-4, 674–679.
128
Erklarung
Hiermit versichere ich, dass ich die vorliegende Arbeit und die zugehorige Implemen-tierung selbststandig verfasst und dabei nur die angegebeben Quellen und Hilfsmittelverwendet habe.
Hannover, 24.04.2014
Oliver Pabst
129