Implementierung und Analyse ausgewählter Verfahren zum Data Stream Mining

Transkript

1 Fakultät für Elektrotechnik und Informatik Institut für Praktische Informatik Fachgebiet Datenbanken und Informationssysteme Implementierung und Analyse ausgewählter Verfahren zum Data Stream Mining Bachelorarbeit im Studiengang Informatik Max-Ludwig Stadler Matrikelnummer: Prüfer: Prof. Dr. Udo Lipeck Zweitprüfer: Dr. Hans Hermann Brüggemann Betreuer: M.Sc. Oliver Pabst 17. August 2015

2

3 Zusammenfassung In vielen Bereichen des heutigen Lebens, sei es die Wetterbeobachtung, der Aktienhandel, oder die Telekommunikation, nimmt die Menge an zu analysierenden Daten stetig zu. Diese Daten treffen kontinuierlich in riesigen Datenströmen ein, die bereits im Bereich von Petabytes liegen. Während die meisten Verfahren des Data Minings, bspw. aus dem Bereich des Clusterings oder der Assoziationsanalyse einen gesamten Datensatz analysieren, ist mittlerweile auch die Entwicklung der Daten in solchen Datenströmen von immer größerem Interesse. Diese Arbeit beschäftigt sich mit der Implementierung und Ergebnisaufbereitung von Algorithmen, die einen kontinuierlichen Datenstrom in den beiden Bereichen Clustering und Assoziationsanalyse analysieren und mit deren Hilfe die Entwicklung dieser Ergebnisse über einen Zeitraum erfasst werden kann. Im ersten Teil dieser Arbeit werden zwei Algorithmen vorgestellt, mit deren Hilfe Datenströme ausgewertet werden können. Der erste Algorithmus heißt D-Stream und beschäftigt sich mit dem Bilden von Clustern auf solchen Datenströmen und der zeitlichen Entwicklung dieser Cluster. Mit Hilfe des zweiten Algorithmus namens Moment, ist es möglich, in einem Datenstrom häufig zusammen auftretende Datensätze zu finden. Auch hier kann die zeitliche Entwicklung dieser Trend-Kombinationen betrachtet werden. Im zweiten Teil wird die Implementierung dieser beiden Algorithmen gezeigt. Mit deren Hilfe werden anschließend einige Versuche durchgeführt um die Tauglichkeit dieser Algorithmen zu überprüfen und den Einfluss der unterschiedlichen Eingabeparameter zu untersuchen. Mit Hilfe von D-Stream werden Cluster aus einem OpenStreetMap-Datensatz gebildet und deren zeitliche Entwicklung beobachtet, während mit Moment die Entwicklung von häufig zusammen genutzten Wortkombinationen im Twitter-Datenstrom untersucht wird.

4

5 Inhaltsverzeichnis 1 Einleitung Motivation Überblick Grundlagen Clusteranalyse Partitionierendes Clustering Dichte-Basiertes Clustering Assoziationsanalyse Data Streams Algorithmen für Data Streams Der D-Stream-Algorithmus Die Datenstruktur hinter D-Stream Der Ablauf des D-Stream-Algorithmus Der Moment-Algorithmus Die Datenstruktur des Moment-Algorithmus Der Ablauf des Moment-Algorithmus Implementierung Clustering von OpenStreetMap-Daten Implementierung des D-Stream-Algorithmus Anwendung für das Clustern von OpenStreetMap-Daten Implementierung des Moment-Algorithmus

6 4.2.1 Implementierung des Moment-Algorithmus Anwendung des Moment-Algorithmus auf dem Twitter-Stream Ergebnisaufbereitung Clustering von Daten aus einem Datenstrom Clustering eines Punkt-Datensatzes Clustering von OpenStreetMap-Daten Einfluss der Parameter auf das Ergebnis Assoziationsanalyse auf dem Twitter-Stream Einfluss der Parameter auf das Ergebnis Versuche auf dem Twitter-Stream Fazit und Ausblick Fazit Ausblick Abbildungsverzeichnis 86 Tabellenverzeichnis 88 Literaturverzeichnis 89 6

7 Kapitel 1 Einleitung 1.1 Motivation Der heutige Informationsfluss tendiert zu immer größeren Datenmengen und umfasst bereits viele Bereiche des heutigen Lebens. Die Mengen an Daten, aus denen potenziell nützliches Wissen extrahiert werden können, steigen stetig an und bewegen sich bereits im Bereich von Petabytes. Viele dieser Daten treffen in Datenströmen ein, wodurch sich der Datensatz kontinuierlich vergrößert. Bei dieser Menge versagen herkömmliche Verfahren der Datenanalyse, da sie ein Speichern des gesamten Datensatzes voraussetzen, welches bei diesen Dimensionen nicht möglich ist. Zudem ist im Bereich der Datenstromanalyse meist die Entwicklung der Datensätze von größerem Interesse, als eine Gesamtanalyse aller Daten. Daher müssen neue Verfahren entwickelt werden, um aus dieser neuen Form der Datenmengen nützliche Informationen zu gewinnen. In dieser Arbeit werden zwei Algorithmen vorgestellt und implementiert, mit deren Hilfe eine Analyse von Daten aus einem kontinuierlichen Datenstrom möglich ist, ohne diesen Datenstrom komplett abzuspeichern. Der erste Algorithmus befasst sich dabei mit dem Clustern dieser Daten, während der zweite Algorithmus eine Assoziationsanalyse durchführt. In den Versuchen im späteren Verlauf dieser Arbeit soll anschließend herausgefunden werden, wie gut die vorgestellten Verfahren in einigen Beispiel-Bereichen anwendbar sind. Der Schwerpunkt der Analyse liegt dabei auf der Ergebnisaufbereitung. 7

8 1.2 Überblick In Kapitel 2 wird zunächst ein Überblick über die Grundlagen der Cluster- und Assoziationsanalyse geliefert, die den vorgestellten Verfahren zu Grunde liegen. Zudem werden Datenströme (data streams) eingeführt. Anschließend werden in Kapitel 3 die beiden Algorithmen D-Stream und Moment vorgestellt, mit denen es möglich ist, Datenanalysen auf Datenströmen durchzuführen. Der D-Stream-Algorithmus beschäftigt sich dabei mit dem Bilden von Clustern auf Datensätzen aus Datenströmen, sowie der Entwicklung solcher Cluster über Zeit. Mit Hilfe des Moment-Algorithmus ist es möglich, auf solchen Datensätzen Assoziationsanalysen durchzuführen und häufig zusammen auftretende Kombinationen zu ermitteln. Darüber hinaus ist es möglich, die zeitliche Entwicklung solcher Trend-Kombinationen zu analysieren. In Kapitel 4 werden diese beiden Algorithmen implementiert. Es wird ein umfassender Überblick über den Aufbau der Implementierung dieser beiden Algorithmen geliefert. Im Anschluss wird in Kapitel 5 untersucht, welche Ergebnisse die beiden Verfahren in einigen Beispielbereichen erzielen. Für die Cluster-Bildung mittels D-Stream werden dabei z.b. Datensätze von OpenStreetMap untersucht. Mit Hilfe des Moment-Algorithmus wird eine Assoziationsanalyse auf einem Teil des Twitter-Datenstroms durchgeführt, welcher nach einer Liste von bestimmten Schlagworten gefiltert ist. Zuletzt wird in Kapitel 6 ein abschließendes Fazit gezogen, sowie ein Ausblick auf weitere mögliche Fragestellungen gegeben. 8

9 Kapitel 2 Grundlagen In diesem Kapitel werden die Grundlagen erklärt, auf denen die in Kapitel 3 erläuterten Algorithmen aufbauen. Zunächst wird auf das Prinzip der Clusteranalyse eingegangen. In diesem Kontext werden Verfahren und Algorithmen gezeigt, um Datensätze in zusammenhängende Cluster zusammenzufassen. Anschließend wird die Assoziationsanalyse erläutert. Diese beinhaltet Verfahren, um aus einer Sammlung von Warenkörben Regeln für das häufige Auftreten bestimmter Item-Kombinationen aufzustellen. Zuletzt werden Data Streams vorgestellt, auf die sich beide in Kapitel 3 vorgestellten Algorithmen beziehen. 2.1 Clusteranalyse Der Bereich der Cluster-Analyse befasst sich mit dem Einteilen von Objekten in Gruppen (sogenannte Cluster). Die Objekte innerhalb eines solchen Clusters sollen dabei anhand ihrer Eigenschaften ähnlicher und zwischen den einzelnen Clustern unähnlicher zueinander sein. Ein häufig genutztes Verfahren zur Bestimmung der Ähnlichkeit zweier Objekte ist die Definition einer Distanzfunktion d, die zwei Objekten einen bestimmten Wert zuweist. Je kleiner dieser Wert ist, desto ähnlicher sind sich die beiden Objekte und umgekehrt. Wie solch eine Distanzfunktion arbeitet hängt von der Art der Eigenschaften dieser Objekte ab. Ein Beispiel für solch eine Distanzfunktion für zwei Objekte x = (x 1, x 2,..., x n ) und y = (y 1, y 2,..., y n ) mit numerischen Attributwerten wäre der in Gleichung 2.1 gezeigte euklidische Abstand. Zwei Punkte sind ähnlicher zueinander, je kleiner der euklidische Abstand zwischen ihnen ist. Bei zusammengesetzten Objekten, die jeweils eine beliebig große endliche Menge von Attributen enthalten, lässt sich hingegen die Distanz als der 9

10 Anteil der verschiedenen Elemente in x und y berechnen (Gleichung 2.2). d(x, y) = (x 1 + y 1 ) 2 + (x 2 + y 2 ) (x n + y n ) 2 (2.1) x y x y d(x, y) = (2.2) x y Im Folgenden wird das Clustering-Schema Partitionierendes Clustering erläutert. Hierfür werden auch Algorithmen vorgestellt, die nach diesem Schema Cluster aus einer Menge von Objekten bilden Partitionierendes Clustering Bei dem partitionierenden Clustering werden die Objekte in disjunkte Cluster eingeteilt. Somit ist jedes Objekt genau einem Cluster zugewiesen. Der am häufigsten genutzte Algorithmus, der nach diesem Prinzip arbeitet, ist der k-means-algorithmus. Der k-means-algorithmus Der k-means-algorithmus (Algorithmus 2.1) arbeitet auf der Grundlage des partitionierenden Clusterings. Als Voraussetzung müssen die einzelnen Objekte Punkte in einem d-dimensionalen euklidischen Vektorraum sein. Für die Ähnlichkeit zweier Objekte wird hier der in Gleichung 2.1 gezeigte euklidische Abstand zwischen den beiden Objekten verwendet. Zu Beginn muss die Anzahl k an Clustern festgelegt werden, die im Verlauf des Algorithmus gebildet werden sollen. Darüber hinaus wird jedem Cluster zu Beginn ein Schwerpunkt zugewiesen. Während jedes Durchlaufs des Algorithmus werden alle Objekte jeweils dem Cluster zugewiesen, dessen Schwerpunkt sie räumlich am nächsten liegen (Zeile 4). Im Anschluss werden alle Schwerpunkte anhand der Objekte, die ihren jeweiligen Clustern zugeordnet sind, neu berechnet (Zeile 5). Algorithmus 2.1 Der k-means-algorithmus ([TSK05] angepasst) Input k - Anzahl der Cluster, die gebildet werden sollen Input O - die Menge der Objekte aus denen die Cluster gebildet werden sollen 1: procedure k-means(k, O) 2: weise den k Schwerpunkten zufällige Startkoordinaten zu; 3: repeat 4: weise jedes Objekt aus O dem Cluster zu, dessen Schwerpunkt es am nächsten ist; 5: berechne die Schwerpunkte der Cluster neu; 6: until kein Schwerpunkt ändert seine Position Das Ergebnis des k-means-algorithmus hängt stark von der Position der Start-Schwerpunkte der einzelnen Cluster ab (siehe Abbildung 2.1). Es kommt vor, dass der k-means- 10

11 Algorithmus lediglich ein lokales Minimum findet. Wie gut das Ergebnis an Clustern eines Durchlaufs von k-means ist, wird mit Hilfe der Summe aller Abstände der Objekte x zu den Schwerpunkten m i ihrer jeweiligen Cluster C i bewertet (Gleichung 2.3). Die Distanzen werden dabei zuvor noch quadriert. Dieses Ergebnis wird SSE (für Sum of Squared Errors) genannt. Je niedriger der SSE-Wert, desto besser war das Ergebnis. SSE = K i=1 x C i d 2 (x, m i ) (2.3) Abbildung 2.1: Ergebnis von k-means bei unterschiedlichen Startpunkten ([TSK05]) Zudem kann der k-means-algorithmus nur sphärische Cluster bilden. Cluster anderer Formen werden nicht korrekt erkannt. 11

12 2.1.2 Dichte-Basiertes Clustering Ein Teilbereich des partitionierenden Clusterings ist das dichte-basierte Clustering. Hierbei sind Cluster Bereiche im d-dimensionalen Vektorraum, in denen Objekte (im weiteren als Punkte bezeichnet) dicht beieinander liegen. Punkte, die nicht in diesen dichten Bereichen liegen, werden als Rauschen oder Ausreißer bezeichnet und sind hier keinem Cluster zugeordnet. Anders als bei dem reinen partitionierenden Clustering können Punkte somit bei dem dichte-basierten Clustering keinem Cluster zugeordnet sein. Ein wichtiger Aspekt dieses Verfahrens ist die Menge N ε für einen Punkt p aus einer Menge von Punkten P (siehe Gleichung 2.4). Diese enthält alle Punkte aus P, deren euklidischer Abstand d (Gleichung 2.1 Seite 10) kleiner oder gleich einem festgelegten ε 0 ist (Abbildung 2.2). N ε (p) = {p P d(p, p ) ε} (2.4) p ε Abbildung 2.2: Menge N ε (p) für ein festgelegtes ε Ist die Kardinalität der Menge N ε (p) für ein p P größer oder gleich einem festgelegten Wert MinP ts, wird p als Kernpunkt der Menge P bezeichnet. Die Punkte, die in der N ε -Menge eines Kernpunktes p enthalten sind, heißen direkt dichte-erreichbar von p. Sie müssen dabei selbst keine Kernpunkte von P sein. Ein Punkt q ist von einem Kernpunkt p aus dichte-erreichbar, wenn es eine Menge von Punkten p 1,..., p n P mit p 1 = p und p n = q gibt, sodass gilt: p i+1 ist ein Kernpunkt und von p i aus direkt dichte-erreichbar für 1 i < n (Abbildung 2.3). Das bedeutet, dass alle Punkte dieser Kette bis auf q Kernpunkte von P sein müssen. Für q ist dies nicht zwingend notwendig. 12

13 q p ε Abbildung 2.3: Beispiel eines von p aus dichte-erreichbaren Punktes q Ein Cluster C in P besteht aus mindestens einem Kernpunkt p P. Darüber hinaus enthält er alle Punkte aus P, die von p aus dichte-erreichbar sind. Hierbei ist kein Kernpunkt in P in zwei Clustern gleichzeitig enthalten, ein Punkt von C, der jedoch kein Kernpunkt ist, wird Randpunkt genannt und kann in mehreren Clustern enthalten sein. Ein dichte-basiertes Clustering CL in P ist die Menge aller Cluster in P bezüglich ε und MinP ts. Alle Punkte in P, die nicht in CL enthalten sind, werden Ausreißer oder Rauschen genannt. Für diese Punkte wird eine Menge NOISE CL bezüglich CL definiert, die alle solche Punkte aus P enthält, die nicht in CL enthalten sind. Ein Algorithmus, der ein dichte-basiertes Clustering CL für eine Menge an Punkten P für ein festes ε und M inp ts bildet, ist der DBSCAN-Algorithmus (Density Based Clustering of Applications with Noise), der im Folgenden vorgestellt wird. Der DBSCAN-Algorithmus Der DBSCAN-Algorithmus (Algorithmus 2.2) bildet für eine Menge von Punkten P ein dichte-basiertes Clustering CL, indem jedem Objekt eine Identifikationsnummer zugewiesen wird. Diese Nummern stehen jeweils entweder für einen bestimmten Cluster aus CL, oder für die Menge der Ausreißer NOISE CL. Bei diesem Algorithmus wird jeder Punkt nur einem Cluster zugeordnet, deshalb kann es für die Zuordnung von Randpunkten, die zu mehreren Clustern gehören können, bei einer unterschiedlichen Reihenfolge der Punktmenge ein unterschiedliches Clustering geben. 13

14 Algorithmus 2.2 Der DBSCAN-Algorithmus ([EKSX96] angepasst) Input P - die Menge an Punkten, die den Clustern zugewiesen werden sollen Input ε - der Radius der N ε -Menge Input MinP ts - die Mindestanzahl an Punkten, die in der N ε -Menge eines Punktes liegen müssen, damit dieser Punkt ein Kernpunkt ist 1: procedure DBSCAN(P, ε, MinPts) 2: weise allen Punkten aus P die ID UNKLASSIFIZIERT zu; 3: ClusterId := eine neue ID für einen neuen Cluster; 4: for all (Punkte p in P ) do 5: if (p ist UNKLASSIFIZIERT ) then 6: if (ExpandiereCluster(P, p, ClusterId, ε,minpts)) then 7: ClusterId := eine neue ID für einen neuen Cluster; Zunächst sind alle Punkte der übergebenen Menge P keinem Cluster zugeordnet (Zeile 2). Der DBSCAN-Algorithmus durchläuft alle Punkte von P und ruft für jeden dieser Punkte den Algorithmus ExpandiereCluster (Algorithmus 2.3) auf, falls dieser Punkt bisher keinem Cluster zugeordnet wurde. Der Algorithmus ExpandiereCluster bildet den Cluster, zu dem der übergebene Punkt gehört. Anschließend wird eine neue Nummer für einen neuen Cluster generiert. In ExpandiereCluster wird zunächst die N ε -Menge des übergebenen Punktes gebildet und überprüft, ob der Punkt ein Kernpunkt ist. Ist dies der Fall, wird der Punkt dem Cluster mit der übergebenen Nummer zugewiesen. Anschließend werden alle Punkte aus der Menge der Nachbarn N ε dieses Punktes dem gleichen Cluster zugewiesen. Ist einer dieser Punkte ebenfalls ein Kernpunkt, so werden auch alle Punkte aus dessen N ε - Menge diesem Cluster zugewiesen und ebenfalls auf die Eigenschaft eines Kernpunktes überprüft. Auf diese Weise wird, vom übergebenen Startpunkt ausgehend, ein gesamter Cluster in einem Durchlauf von ExpandiereCluster gebildet. 14

15 Algorithmus 2.3 ExpandiereCluster (Teilfunktion von DBSCAN) ([EKSX96] angepasst) Input P - die Menge an Punkten, die den Clustern zugewiesen werden sollen Input start - der Startpunkt von dem aus der Cluster gebildet werden soll Input ClusterId - die ID des Clusters dem die Punkte in diesem Durchlauf des Algorithmus zugewiesen werden Input ε - der Radius der N ε -Menge Input MinP ts - die Mindestanzahl an Punkten, die in der N ε -Menge eines Punktes liegen müssen, damit dieser Punkt ein Kernpunkt ist Output - true falls der gegebene Startpunkt start ein Kernpunkt ist; sonst false 1: procedure ExpandiereCluster(P, start, ClusterId, ε, MinPts): boolean 2: seeds := N ε (start); 3: if ( seeds < MinP ts) then 4: return false; //start ist kein Kernpunkt 5: for all (Punkte p seeds) do 6: weise p die ID ClusterId zu; 7: lösche den Startpunkt start aus seeds; 8: while (seeds ) do 9: wähle einen Punkt x aus der Menge seeds; 10: Nachbarschaft := N ε (x); 11: if ( Nachbarschaft M inp ts) then //x ist ein Kernpunkt 12: for all (Punkte p Nachbarschaft) do 13: if (die ID von p ist NOISE CL oder UNKLASSIFIZIERT ) then 14: if (die ID von p ist NOISE CL ) then 15: füge p der Menge seeds hinzu; 16: weise p die ID ClusterID zu; 17: lösche den Punkt x aus seeds; 18: return true; Ein Vorteil des DBSCAN-Algorithmus im Vergleich zu anderen Verfahren, wie zum Beispiel dem k-means-algorithmus, ist, dass mit Hilfe des DBSCAN-Algorithmus Cluster beliebiger Formen gefunden werden können. Zusätzlich muss die Anzahl an Clustern zu Beginn des Algorithmus nicht bekannt sein. Darüber hinaus können Ausreißer, die zwischen den Ballungsräumen liegen, herausgefiltert werden. Allerdings gibt es auch Datensätze, die mittels DBSCAN nicht erfolgreich in Cluster eingeteilt werden können. Ein Beispiel dafür sind Datensätze, bei denen in verschiedenen Gebieten Ballungsräume von Punkten auftreten, die in ihrer Dichte stark variieren. Hierbei ist es schwer die geeignet Parameter zu wählen, um zum einen alle Cluster zu finden, diese jedoch zum anderen nicht mit den Ausreißern zu vermischen. 15

16 2.2 Assoziationsanalyse Die Assoziationsanalyse, auch Warenkorbanalyse genannt, beschäftigt sich mit dem Finden von Regeln und Zusammenhängen innerhalb einer Menge von Warenkörben. Solche Warenkörbe, im Folgenden Transaktionen genannt, sind jeweils Teilmengen einer Obermenge Σ und sind mit tatsächlichen Warenkörben eines Supermarktkunden vergleichbar. Jede Transaktion enthält dabei verschiedene Artikel des vom Supermarkt angebotenen Sortiments, wobei jedoch jeder Artikel maximal einmal in der Transaktion vorkommt. Das Ziel der Assoziationsanalyse besteht darin, für eine gegebene Menge an Transaktionen Regeln zu finden, die Zusammenhänge innerhalb der Transaktionen beschreiben, welche häufig auftreten. In dem Beispiel eines Supermarktes wären dies Artikel, die bedingt durch eine andere Gruppe von Artikeln häufig eingekauft werden. Würde beispielsweise in vielen Transaktionen, die die beiden Artikel Eier und Mehl enthalten, auch der Artikel Butter vorkommen, so könnte eine Regel der Form {{Eier, M ehl} {Butter}} aufgestellt werden. Im Folgenden Abschnitt werden Methoden und Datenstrukturen vorgestellt, mit deren Hilfe solche Assoziationsregeln gefunden werden können. Grundbegriffe Gegeben ist die Menge der verschiedenen Artikel (im Folgenden Items genannt) Σ, sowie eine Datenbank D, welche die Transaktionen enthält. All diese Transaktionen sind Teilmengen von Σ mit beliebiger Länge k. In den folgenden Beispielen wird Σ = {A, B, C, D, E} gewählt, sowie die in Tabelle 2.1 gezeigte Datenbank D mit den Transaktionen. Transaktion Items 1 {A,B,C,D} 2 {B,C,D} 3 {A,B,C,E} 4 {C,D} 5 {A,D} 6 {A} Tabelle 2.1: Beispieldatenbank D Die Anzahl an Transaktionen in D, in denen eine bestimmte Menge von Items (im Folgenden Itemset genannt) X vorkommt, wird Support count genannt. Die Funktion zur Berechnung des Support counts von X in D heißt σ (Gleichung 2.5), z.b.: σ({c, D}) = 3 (2.5) Der Support s(x) eines Itemsets X in D ist der Anteil der Transaktionen von D, in 16

17 denen X vorkommt (Gleichung 2.6), z.b.: s({c, D}) = σ({c, D}) D = 3 6 = 0, 5 (2.6) Für das Erstellen von Assoziationsregeln ist es notwendig, ein Maß zu bestimmen, für das ein Itemset innerhalb der Transaktionen in D als häufig angesehen wird. Dafür wird ein Wert minsup 0 bestimmt, sodass gilt: Ein Itemset X ist häufig in D, wenn s(x) minsup. Nach einem ähnlichen Verfahren werden häufige Regeln der Form {{X} {Y }} für zwei Itemsets X und Y ermittelt. Der Support s einer Regel dieser Form wird als Anteil aller Transaktionen in D berechnet, die sowohl X als auch Y enthalten (Gleichung 2.7). Er berechnet sich somit aus dem Support der Vereinigung von X und Y, z.b.: s({b, C} {A}) = σ({b, C} {A}) D = σ({a, B, C}) D = 2 6 = 0, 33 (2.7) Als zusätzliches Kriterium für eine Assoziationsregel der Form {{X} {Y }} lässt sich die Konfidenz c einer solchen Regel berechnen (Gleichung 2.8). Diese beschreibt den Anteil der Transaktionen aus D die X enthalten, welche auch das Itemset Y enthalten. Im Zuge der Assoziationsanalyse werden nur Regeln aufgestellt, wenn sie häufig in D sind und ihre Konfidenz c einen vom Nutzer spezifizierten Wert minconf 0 erreicht, bzw. überschreitet. c({b, C} {A}) = σ({b, C} {A}) σ({b, C}) = σ({a, B, C}) σ({b, C}) = 2 3 = 0, 67 (2.8) Da alle Assoziationsregeln, in denen die gleichen Items vorkommen, den gleichen Support besitzen, lässt sich die Aufgabe der Assoziationsanalyse in zwei Teilbereiche unterteilen: 1. Finde alle Itemsets in D, deren Support größer oder gleich dem gegebenen Mindestwert minsup ist. 2. Bilde aus diesen Itemset Regeln, deren Konfidenz größer oder gleich dem gegebenen Mindestwert minconf ist. Diese Arbeit setzt sich nicht mit dem Bilden von Assoziationsregeln auseinander, daher wird im Folgenden der Schwerpunkt auf das Finden der häufigen Itemsets gelegt. Das Apriori-Prinzip Das Apriori-Prinzip [AS94] bietet eine Möglichkeit, um effizienter die häufigen Itemsets aus einer Menge von Itemsets und deren Supports zu generieren. Da die Anzahl von möglichen Itemsets bei n Items 2 n beträgt und n sehr groß sein kann, ist es zu aufwendig, alle möglichen Itemsets zu finden und ihren Support zu überprüfen. Stattdessen kann 17

18 sich eine Anti-Monotonie-Eigenschaft der Itemsets zunutze gemacht werden (Gleichung 2.9). X Y s(x) s(y ) (2.9) Für ein nicht häufig auftretendes Itemset X gilt somit, dass alle Itemsets Y, die Obermengen von X sind (X Y ), ebenfalls nicht häufig sind, da ihr Support den Support von X nicht überschreiten kann. Im Umkehrschluss sind alle Itemsets X, die in einem häufigen Itemset Y enthalten sind, ebenfalls häufig, da ihr Support den Support von Y nicht unterschreiten kann. Für eine große Anzahl an Items kann jedoch auch die Menge an häufigen Itemsets sehr groß sein. Daher wird zusätzlich die Menge der maximal frequent Itemsets definiert. Dies ist die Menge an häufigen Itemsets, für die gilt: Ein häufiges Itemset X ist ein maximal frequent Itemset, wenn es kein häufiges Itemset Y = X I für alle Items I / X gibt. Die Menge der maximal frequent Itemsets ist sehr viel kleiner als die Menge der häufigen Itemsets. Es ist darüber hinaus möglich, die Menge an häufigen Itemsets aus der Menge der maximal frequent Itemsets zu bilden, jedoch kann man aus dieser Menge keine Rückschlüsse auf die Support-Werte der anderen häufigen Itemsets ziehen. Da dies in vielen Fällen allerdings von Interesse ist, wird eine zusätzliche Menge von closed frequent Itemsets definiert. Diese enthält alle häufigen Itemsets X für die gilt: Es gibt kein Itemset Y = X I mit dem gleichen Support wie X für alle Items I / X. Diese Menge ist größer als die Menge der maximal frequent Itemsets, jedoch immer noch kleiner als die Menge der häufigen Itemsets. Zusätzlich kann man die Menge der häufigen Itemsets inklusive aller Support-Werte aus der Menge der closed frequent Itemsets ableiten. In Abbildung 2.4 ist ein Beispiel der verschiedenen Mengen von Itemsets bei einem minimalen Support von 2 gegeben. Die einzelnen Transaktionen der Datenbank sind in der Tabelle 2.2 zu sehen. Transaktion Items 1 {A,B,C} 2 {A,B,C,D} 3 {B,C,E} 4 {A,C,D,E} 5 {D,E} Tabelle 2.2: Beispieldatenbank für die Abgrenzung der verschiedenen Itemset-Mengen 18

19 Abbildung 2.4: Beispiel der verschiedenen Mengen von Itemsets ([TSK05]) Der Frequent-Pattern-Growth-Algorithmus Eine Möglichkeit zur Generierung aller häufigen Itemsets aus einer Menge von Transaktionen ist der Frequent-Pattern-Growth-Algorithmus (kurz FP-Growth-Algorithmus) [TSK05]. Dieser Algorithmus speichert alle Transaktionen der Datenbank D in einer kompakten Baumstruktur. Je mehr Itemsets dabei die gleichen Präfixe haben, desto größer ist die Platzersparnis des Baumes. Die häufigen Itemsets werden anschließend beim Durchlaufen des Baumes gebildet. Beim Bilden der Baumstruktur (des sogenannten FP-Trees) wird nacheinander jede Transaktion eingelesen und als Pfad im Baum gespeichert. Die einzelnen Items der Transaktion bilden dabei jeweils die Knoten. Zusätzlich wird für jeden Knoten der Support für das Itemset gespeichert, das von der Wurzel bis zu dem Knoten gebildet wird, sowie ein Verweis auf das nächste Vorkommen dieses Items im Baum. Wird nun eine Transaktion hinzugefügt, deren Itemset bereits im FP-Tree enthalten ist, wird kein neuer Pfad im Baum angelegt, sondern lediglich der Support der Knoten, die zu diesem Itemset gehören, aktualisiert. Zusätzlich zu dem Baum wird eine Header Liste angelegt, welche die Verweise auf das erste Vorkommen der jeweiligen Items im Baum enthält. Die weiteren Vorkommen der Items sind in den einzelnen Knoten gespeichert. In Abbildung 2.5 ist der FP-Tree dargestellt, der aus den Transaktionen aus der Tabelle 2.2 gebaut wurde. 19

20 null: 5 A: 3 B: 1 D: 1 B: 2 C: 1 C: 1 E: 1 C: 2 D: 1 E: 1 D: 1 E: 1 Abbildung 2.5: FP-Tree aus Tabelle 2.2 generiert ([TSK05] angepasst) Um nun zu überprüfen, ob ein Item i häufig ist, werden alle Pfade im FP-Tree gesucht, die auf i enden. Alle anderen Teilpfade werden aus dem ursprünglichen FP-Tree gelöscht. Zusätzlich wird auch i selbst aus dem Baum gelöscht. Hierbei müssen die Support-Werte angepasst werden. Aus diesem neuen Baum (für ein Item i ein i-conditional FP-Tree) kann der Support für i aus der Wurzel abgelesen und somit ermittelt werden, ob i ein häufiges Item ist. Für ein Item j, das in diesem i-conditional FP-Tree enthalten ist, kann nun herausgefunden werden, ob das Itemset {j, i} häufig ist, indem aus dem i-conditional FP-Tree nach dem gleichen Verfahren ein j-conditional FP-Tree erstellt wird. Der Support, der anschließend in der Wurzel dieses Baumes gespeichert ist, repräsentiert den Support des Itemsets {j, i} in allen Transaktionen, die in den ursprünglichen FP-Tree eingefügt wurden. Auf dieser Grundlage arbeitet der FP-Growth-Algorithmus (2.4). Es werden zunächst lediglich die häufigen Items gesucht, indem für diese jeweils conditional FP-Trees gebildet werden. Anschließend wird rekursiv die gleiche Problemstellung in den einzelnen conditional FP-Trees gelöst, um so alle häufigen 2-elementigen Itemsets zu finden. Dieser Vorgang wiederholt sich für alle folgenden k-elementigen Itemsets. Teilbäume von nicht häufigen Itemsets werden aufgrund des Apriori-Prinzips nicht weiter zerlegt, da es unter den resultierenden Itemsets keine häufigen Itemsets geben kann. 20

21 Algorithmus 2.4 Der Frequent-Pattern-Growth-Algorithmus ([TSK05] angepasst) Input Σ - die Menge aller Items Input T - der initiale FP-Tree in den alle Transaktionen eingefügt wurden Input MinSup - der minimale Support den ein Item/-set haben muss um häufig zu sein Input suffix - die bisherige Endung des Itemsets (beim ersten Aufrufen null) Output - eine Liste mit allen häufigen Itemsets 1: procedure FP-Growth(Σ, T, MinSup, suffix) 2: frequentitemsets := ; 3: for all (Items i Σ, i / suffix) do 4: bilde den i-conditional FP-Tree T i aus T ; 5: if (der Support der Wurzel von T i ist größer oder gleich MinSup) then 6: füge frequentitemsets das Itemset {i suffix} hinzu; 7: if (T i besteht nicht nur aus der Wurzel) then 8: füge frequentitemsets FP-Growth(Σ, T i, MinSup, {i suffix}) hinzu; return frequentitemsets; 2.3 Data Streams Bei einem Datenstrom (data stream), werden kontinuierlich Datensätze übertragen. Die Rate, mit der diese Datensätze eintreffen, sowie deren Größe kann variieren. In der Regel ist das Volumen der übersandten Datensätze jedoch so groß, dass ein Speichern aller Datensätze vor deren Verarbeitung nicht möglich ist. Da die Datensätze nicht alle auf einmal eintreffen, verfügen die eintreffenden Datensätze in Datenströmen, anders als bei festen Datensätzen, zusätzlich noch über eine Zeitkomponente. Diese repräsentiert den Zeitpunkt, zu dem sie eingetroffen sind. Viele gängige Verfahren der Datenanalyse von festen Datensätzen können hier keine Anwendung finden, da ein mehrmaliges Durchlaufen des gesamten Datenstroms nicht möglich, dies jedoch ein fester Bestandteil vieler Techniken ist. In dieser Arbeit werden Datenströme vereinfacht als Liste von Datensätzen angesehen, von denen jeder Datensatz x aus einer Reihe (x 1, x 2,..., x n ) von Eigenschaften besteht und zu einem Zeitpunkt t eingelesen wird. 21

22 Kapitel 3 Algorithmen für Data Streams In diesem Kapitel werden zwei Verfahren zum Data Stream Mining detailliert vorgestellt. Das erste Verfahren ist der D-Stream-Algorithmus [CT07], mit dem es möglich ist, aus den einzelnen Datensätzen eines Data Streams Cluster zu bilden. Das zweite Verfahren ist der Moment-Algorithmus [CWYM06]. Dieser ermöglicht es, aus einem Data Stream die aktuellen closed frequent Itemsets zu bilden. 3.1 Der D-Stream-Algorithmus In diesem Abschnitt wird der Aufbau und die Funktionsweise des D-Stream-Algorithmus [CT07] erklärt. Mit Hilfe des D-Stream-Algorithmus ist es möglich, Cluster beliebiger Form in einem kontinuierlichen Datenstrom zu ermitteln. Zusätzlich wird dabei auch auf den Einfluss der Zeitkomponente der einzelnen Datensätze eingegangen. Diese bewirkt, dass neu eintreffende Datensätze eine größere Auswirkung auf die Cluster-Bildung haben als Datensätze, die schon vor längerer Zeit eingetroffen sind. Der D-Stream-Algorithmus orientiert sich beim Bilden der Cluster an dem in Kapitel 2 vorgestellten DBSCAN-Algorithmus. Zunächst wird auf die Datenstruktur eingegangen, in der die eintreffenden Datensätze gespeichert und verwaltet werden. Im Anschluss wird der D-Stream-Algorithmus an sich erläutert Die Datenstruktur hinter D-Stream Im folgenden Abschnitt wird die Datenstruktur vorgestellt, in der die eintreffenden Datensätze gespeichert und verwaltet werden. Da das Volumen an zu speichernden Da- 22

23 tensätzen bei Datenströmen kontinuierlich anwächst und eine enorme Größe erreichen kann, wäre es zu rechen- und speicherintensiv, jeden Datensatz wiederholt zu durchlaufen, nachdem er bereits eingelesen wurde. Daher werden die einzelnen Datensätze bei dem D-Stream-Algorithmus lediglich im Vorbeifliegen betrachtet. Die Informationen, die diese Datensätze enthalten, werden daraufhin direkt in eine effizientere Datenstruktur eingeordnet. Bei dieser Datenstruktur handelt es sich um ein Gitter, im Folgenden als Density Grid bezeichnet. Jeder Datensatz aus dem Datenstrom enthält eine Menge von Eigenschaften, mit deren Hilfe die einzelnen Datensätze in Bezug auf die Cluster-Bildung als ähnlich oder unähnlich angesehen werden können. Die einzelnen Eigenschaften bilden dabei jeweils eigene Wertebereiche, wodurch all diese Datensätze mit n Eigenschaften in ein n-dimensionales Koordinatensystem eingeordnet werden können. Stattdessen werden die Datensätze in das n-dimensionale Density Grid eingeordnet. Jede Zelle repräsentiert dabei einen bestimmten Wertebereich jeder Eigenschaft, wodurch jeder Datensatz genau einer Zelle des Density Grids zugeordnet werden kann (Abbildung 3.1). Abbildung 3.1: Einordnung eines Datensatzes in das Density Grid ([CT07] angepasst) Die Cluster-Bildung erfolgt lediglich auf der Grundlage des Density Grids, daher müssen alle wichtigen Eigenschaften für das Clustering auch nur für die einzelnen Zellen des Grids gespeichert werden. Dies bringt bereits eine hohe Speicherentlastung mit sich. Die Anzahl aller Zellen kann bei einem großen n allerdings ebenfalls stark anwachsen. Es zeigt sich jedoch in der Praxis, dass die meisten Zellen leer bleiben oder nur sehr selten mit neuen Datensätzen befüllt werden. Deshalb werden die einzelnen Zellen dynamisch erstellt, wenn ihnen Datensätze zugeordnet werden und in Abhängigkeit von ihrer Dichte zum Großteil gelöscht, wenn sie über eine gewisse Zeit nicht mit neuen Datensätzen befüllt werden. Lediglich ein paar Parameter werden für solche Zellen dennoch gespeichert. 23

24 Die Dichte eines einzelnen Datensatzes x (im Folgenden Dichte-Koeffizient genannt) berechnet sich in Abhängigkeit von der Differenz der aktuellen Zeit t und seines Zeitstempels (der Zeitpunkt zu dem der Datensatz aus dem Stream eingelesen wurde) T (x), sowie einem Alterungs-Faktor λ (0, 1), der die Senkung des Informationsgehaltes des Datensatzes über einen bestimmten Zeitraum bestimmt, wie folgt (Gleichung 3.1): D(x, t) = λ t T (x) (3.1) Aus der Formel wird ersichtlich, dass ein Datensatz zum Zeitpunkt seines Eintreffens einen Dichte-Koeffizienten von λ T (x) T (x) = λ 0 = 1 besitzt. Über die Zeit nähert sich dieser jedoch dem Wert 0 an. Wie stark der Dichte-Koeffizient des Datensatzes im Laufe der Zeit sinkt, hängt von dem gewählten λ ab. Die Dichte einer Zelle g des Density Grids zur Zeit t ist die Summe der Dichte-Koeffizienten aller Datensätze, die dieser Zelle zugeordnet sind (Gleichung 3.2). D(g, t) = x g D(x, t) (3.2) Damit nicht die Dichte-Koeffizienten für jeden einzelnen Datensatz gespeichert werden müssen, genügt es (da der Alterungs-Faktor λ für alle Datensätze gleich ist), nur die Dichte der einzelnen Zellen zu speichern. Dieser Wert verändert sich theoretisch kontinuierlich. Es ist jedoch nur eine Neuberechnung des Wertes nötig, wenn ein neuer Datensatz eintrifft. Dazu muss lediglich der Zeitpunkt der letzten Änderung (t l ) gespeichert werden (Gleichung 3.3). D(g, t) = λ t t l D(g, t l ) + 1 (3.3) Der Dichte-Koeffizient des neu eingetroffenen Datensatzes beträgt, wie oben beschrieben, eins und wird zu der Dichte der Zelle hinzu addiert. Zusätzlich zu der Dichte müssen noch einige andere Eigenschaften der einzelnen Zellen des Density Grids gespeichert werden. Dafür wird in jeder Zelle ein Characteristic Vector angelegt, der die wichtigsten Eigenschaften einer Zelle speichert. Dieser Vektor ist ein 5-Tupel mit folgenden Werten: 24

25 t l : Dies ist der letzte Zeitpunkt zu dem die Dichte der Zelle neu berechnet wurde. t m : Unter diesem Wert wird der letzte Zeitpunkt gespeichert, an dem diese Zelle zuletzt aus der Liste an Zellen gelöscht wurde (weil die Dichte der Zelle einen festgelegten Wert unterschritten hatte). Dieser Wert wird erst im späteren Verlauf benötigt. D : Die zuletzt (zum Zeitpunkt t l ) berechnete Dichte der Zelle. label : Hier wird der Name des Clusters gespeichert, dem die Zelle zugeordnet ist. status : Dieser Wert enthält einen von zwei möglichen Namen (SPORADIC oder NORMAL). Diese Kategorie ist (wie im folgenden Abschnitt erklärt) für das Löschen von selten frequentierten Zellen wichtig. Die Zellen des Density Grids, deren Dichte hoch genug ist, werden in einer Liste gespeichert. Diese wird im Folgenden als grid list bezeichnet Der Ablauf des D-Stream-Algorithmus Der D-Stream-Algorithmus (Algorithmus 3.1) läuft so lange, wie der Datenstrom aktiv ist. Er liest in jedem Durchlauf den nächsten Datensatz ein und weist ihm einen neuen Zeitstempel zu. Damit nicht nach jedem neuen Datensatz alle Cluster überprüft werden müssen, werden nur in einem bestimmten Intervall gap die Funktionen zum Verwalten der Cluster aufgerufen. Für die Bildung der Cluster werden die Zellen des Density Grids jeweils in eine von drei Kategorien eingeordnet: DENSE, TRANSITIONAL und SPARSE. In welche Kategorie eine Zelle x eingeteilt wird, hängt von ihrer jeweiligen Dichte zum Zeitpunkt t, sowie von zwei Konstanten (C m und C l ) ab, die zu Beginn des Algorithmus festgelegt werden müssen. Eine Zelle wird in die Kategorie DENSE eingeordnet, wenn ihre Dichte die Schranke D m überschreitet, die sich mit Hilfe der Konstanten C m > 1, des Alterungsfaktors λ und der Anzahl an Zellen N im Density Grid (ob leer oder nicht) berechnen lässt (Gleichung 3.4). C m D(g, t) N(1 λ) = D m (3.4) Der Wert der Dichte, den eine Zelle erreichen muss, um als DENSE zu gelten, wird daher bei einem größeren Density Grid kleiner. Im Gegensatz dazu wird eine Zelle als SPARSE bezeichnet, wenn ihre Dichte die Schranke D l unterschreitet, die sich ebenfalls über N 25

26 und λ, jedoch diesmal über den Wert 0 < C l < 1 berechnen lässt (Gleichung 3.5). D(g, t) C l N(1 λ) = D l (3.5) Wenn die Dichte zwischen den Schranken D m und D l liegt, wird die Zelle als TRANSI- TIONAL markiert (Gleichung 3.6). D l D(g, t) D m (3.6) Algorithmus 3.1 Ablauf von D-Stream ([CT07] angepasst) 1: procedure D-Stream 2: t c = 0; 3: initialisiere eine leere Hash-Tabelle grid list; 4: while (Data Stream ist aktiv) do 5: lese neuen Datensatz x = (x 1, x 2,..., x d ); 6: bestimme die Zelle g, der x zugeordnet wird; 7: if (g ist noch nicht in grid list enthalten) then 8: füge g in grid list ein; 9: aktualisiere den Characteristic V ector von g; 10: if (t c == gap) then 11: initial clustering(grid list); 12: else if (t c mod gap == 0) then 13: find sporadic grids(grid list, t c, gap); 14: adjust clustering(grid list); 15: t c = t c + 1; Das Löschen von Zellen Zellen, denen seit zu langer Zeit kein neuer Datensatz zugewiesen wurde, werden aus der grid list gelöscht. Da jedoch in dem Characteristic Vector der Zelle unter t m gespeichert ist, wann diese Zelle zuletzt aus der grid list gelöscht wurde, kann die Zelle nicht komplett aus dem Speicher entfernt werden. Stattdessen werden sämtliche Datensätze, die der Zelle zugeordnet waren, gelöscht und die Dichte der Zelle auf 0 gesetzt. Das Löschen der Zellen zum Zeitpunkt t findet in Algorithmus 3.2 statt. Die Density Threshold Function π einer Zelle g, deren Dichte zuletzt zum Zeitpunkt t l aktualisiert wurde, wird zum Zeitpunkt t t l wie folgt berechnet (Gleichung 3.7): π(t l, t) = C l(1 λ t t l+1 ) N(1 λ) (3.7) Falls die Dichte einer Zelle g zum Zeitpunkt t diesen Wert π(t l, t) unterschreitet und die Zelle zuvor noch nie aus der grid list gelöscht wurde (der Wert t m dieser Zelle noch 26

27 0 beträgt), wird sie als sporadische Zelle markiert. Sollte die Zelle seit Beginn des D- Stream-Algorithmus bereits ein oder mehrmals aus der grid list gelöscht worden sein (wenn für den Characteristic Vector der Zelle gilt: t m > 0), muss zusätzlich die Bedingung (Gleichung 3.8) für ein festgelegtes β > 0 gelten. t (1 + β)t m (3.8) Zellen, die in einem Durchlauf des Algorithmus 3.2 als sporadisch markiert werden, bleiben zunächst noch in der grid list gespeichert. Im nächsten Durchlauf wird anschließend bei allen als sporadisch markierten Zellen überprüft, ob seit dem letzten Durchlauf ein neuer Datensatz der Zelle hinzugefügt wurde. Dies lässt sich dadurch prüfen, ob für den Wert t l der Zelle (der Zeitpunkt zudem zuletzt ein Datensatz der Zelle hinzugefügt wurde) zum Zeitpunkt t gilt: t l t gap. Da gap das Zeitintervall ist, nach dem der Algorithmus 3.2 das nächste mal aufgerufen wird (siehe Algorithmus 3.1 auf Seite 26), muss innerhalb dieser Zeit ein neuer Datensatz der Zelle hinzugefügt worden sein. Ist dies der Fall, wird erneut überprüft, ob die Zelle als sporadisch markiert werden muss, sie wird jedoch in diesem Durchlauf nicht mehr gelöscht. Algorithmus 3.2 Das Finden und Löschen von zu wenig frequentierten Zellen Input grid list - die Liste der Zellen, die Datensätze enthalten Input t - die momentane Zeit Input gap - die Zeit die seit dem letzten Aufruf dieser Funktion vergangen ist 1: procedure find sporadic grids(grid list, t, gap) 2: for all (Zellen g in grid list) do 3: if (g ist als sporadische Zelle markiert) then 4: if (für den Characteristic Vector von g gilt: t l t gap) then 5: markiere g als normale Zelle; 6: else 7: lösche g aus der grid list; 8: lösche alle Datensätze die g zugeordnet sind; 9: setze die Dichte von g auf 0; 10: für g: t l := 0; 11: für g: t m := t; 12: for all (Zellen g in grid list) do 13: if (g ist als normale Zelle markiert g hat die Dichte-Kategorie SPARSE) then 14: if (für den Characteristic Vector von g gilt: D(g, t) < π(t l, t)) then 15: if (für den Characteristic Vector von g gilt: t m = 0) then 16: markiere g als sporadische Zelle; 17: else if (für den Characteristic Vector von g gilt: t (1 + β)t m ) then 18: markiere g als sporadische Zelle; 27

28 Die Ermittlung von gap Um zu ermitteln wie groß das Zeitintervall zwischen den Neuberechnungen der Cluster (gap) sein muss, wird die Zeit berechnet, die eine Zelle brauchen würde, um von einer der Kategorien SPARSE und DENSE zur jeweils anderen zu wechseln. Dabei muss gap so klein sein, dass jeder Wechsel zwischen den Kategorien erfasst werden kann. Auf der anderen Seite soll gap allerdings auch möglichst groß sein, um nicht unnötig Rechenzeit bei der Cluster-Bildung zu verschwenden. Für die minimale Zeit t, die eine Zelle zum Wechseln von DENSE zu SPARSE benötigt, ist zu berechnen, wie lange eine Zelle mit der Dichte D m (Gleichung 3.4 Seite 25) mindestens altern muss, bis sie die Dichte D l (Gleichung 3.5 Seite 26) erreicht (Gleichung 3.9). Das Zeitintervall gap darf demnach maximal so groß sein, dass diese benötigte Zeit nicht überschritten wird (Gleichung 3.10). C m N(1 λ) λt = C l N(1 λ) C m λ t = C l λ t = C l C m t = log λ gap ( ) Cl log λ C m C l C m (3.9) (3.10) Für die minimale Zeit, die eine Zelle zum umgekehrten Wechseln von SPARSE zu DEN- SE benötigt, ist davon auszugehen, dass jeder neu eintreffende Datensatz in diese Zelle eingefügt wird, welche zunächst die Dichte D l besitzt. Für jeden neuen Datensatz berechnet sich die Dichte demnach wie folgt (Tabelle 3.1): X-ter Datensatz Dichte der Zelle 1 λ D l λ (λ D l + 1) λ (λ (λ D l + 1) + 1) x λ x D l + x 1 i=0 λi = λ x D l + 1 λx 1 λ Tabelle 3.1: Dichte der Zelle nach dem jeweiligen Einfügen neuer Datensätze Gesucht ist nun die Menge x an Datensätzen, die nach x Zeitschritten in die Zelle eingefügt wurden, sodass die Dichte der Zelle den Wert D m erreicht (Gleichung 3.11). Somit darf gap zusätzlich zu der oben genannten Bedingung nur maximal so groß sein, dass auch diese Zeit nicht überschritten wird (Gleichung 3.12) λ x C l N(1 λ) + 1 λx 1 λ = C m N(1 λ) λx = N C m N C l (3.11) gap ( ) N Cm log λ N C l (3.12) 28

29 Das Ergebnis für gap aus der Vereinigung der beiden ermittelten Bedingungen ist das Minimum der Zeit die eine Zelle braucht, um von SPARSE zu DENSE oder von DENSE zu SPARSE zu wechseln (Gleichung 3.13). gap = min Das Bilden von Clustern { log λ C l C m } N C m, log λ N C l (3.13) Für das Bilden von Clustern müssen noch folgende Begriffe und Werte definiert werden: Zwei Zellen des Density Grids g 1 und g 2 werden benachbart genannt, wenn für die Koordinaten der beiden Zellen g 1 = (j 1 1, j 1 2,..., j 1 n) und g 2 = (j 2 1, j 2 2,..., j 2 n) ein 1 k n existiert, so dass gilt: 1. j 1 i = j 2 i, i = 1,..., k 1, k + 1,..., n 2. j 1 k j2 k = 1 In diesem Falle wären die beiden Zellen Nachbarn in der k-ten Dimension. Die Schreibweise dafür ist g 1 g 2. Das bedeutet, dass beispielsweise in einem zweidimensionalen Density Grid keine diagonalen Zellen benachbart wären (Abbildung 3.2). g Nachbar von g kein Nachbar von g Abbildung 3.2: Bestimmung von Nachbarn in einem 2-Dimensionalen Density Grid Eine Menge von Zellen G = (g 1,..., g n ) eines Density Grids ist eine Gruppe, wenn für alle Zellen g i, g j G eine Sequenz g k1,... g kl G existiert, für die gilt: 1. g k1 = g i und g kl = g j 2. g k1 g k2, g k2 g k3,..., g kl 1 g kl In einer solchen Gruppe wird eine Zelle Inside Grid genannt, wenn all ihre Nachbarzellen ebenfalls zu ihrer Gruppe gehören. Andernfalls wird die Zelle Outside Grid genannt. 29

30 Im Folgenden Abschnitt werden die Algorithmen zum Bilden der Cluster erläutert. Eine Gruppe von Zellen wird Cluster genannt, wenn all ihre Inside Grids in der Dichte- Kategorie DENSE und all ihre Outside Grids entweder in der Dichte-Kategorie DENSE oder TRANSITIONAL liegen. Dabei werden unterschiedliche Algorithmen aufgerufen (initial clustering(grid list) und adjust clustering(grid list)), je nachdem, ob zum ersten Mal seit dem Start von D-Stream Cluster gebildet werden (Algorithmus 3.3), oder die bereits bestehenden Cluster lediglich angepasst werden sollen (Algorithmus 3.4). Das erste Bilden von Clustern (siehe Algorithmus 3.1 auf Seite 26 Zeile 11) erfolgt im Algorithmus 3.3. Zunächst wird jeder Zelle, die zum momentanen Zeitpunkt die Dichte- Kategorie DENSE besitzt, ein eigener Cluster zugewiesen. Im Anschluss werden die Nachbarzellen aller Cluster (die zu Beginn je nur aus einer Zelle bestehen) betrachtet. Dabei werden benachbarte Cluster zu einem gemeinsamen Cluster verschmolzen. Zusätzlich werden Zellen, deren Dichte-Kategorie TRANSITIONAL ist, einem Cluster zugewiesen, zu dem sie benachbart sind. Sollte es keine Nachbarzelle geben, die einem Cluster zugeordnet ist, wird die Zelle keinem Cluster zugewiesen. Algorithmus 3.3 Das erste Bilden von Clustern ([CT07] angepasst) Input grid list - die Liste der Zellen, die Datensätze enthalten 1: procedure initial clustering(grid list) 2: aktualisiere die Dichte aller Zellen in grid list; 3: weise alle Zellen mit der Dichte-Kategorie DENSE einem eigenen Cluster zu; 4: repeat 5: for all (Cluster c) do 6: for all (Outside Grids g in c mit der Dichte-Kategorie DENSE) do 7: for all (Nachbarzellen h von g) do 8: if (h gehört zu Cluster c c) then 9: if ( c > c ) then 10: füge alle Zellen aus c in c ein; 11: else 12: füge alle Zellen aus c in c ein; 13: nenne den Cluster c um in c; 14: else if (h hat die Dichte-Kategorie TRANSITIONAL) then 15: füge h in c ein; 16: until keine Zelle ändert ihren Cluster Dadurch, dass in Zeile 6 lediglich die Zellen betrachtet werden, die mit ihrer Dichte in die Kategorie DENSE fallen, wird verhindert, dass eine Zelle mit der Dichte-Kategorie TRANSITIONAL zu einem Inside Grid des Clusters wird. Welchem Cluster die einzelnen Zellen zugeordnet sind, wird in ihrem jeweiligen Characteristic Vector unter der Variable label gespeichert. Ist eine Zelle keinem Cluster zugeordnet, ist in label der Wert NO CLASS gespeichert. 30

31 Nach dem ersten Bilden der Cluster wird in den folgenden Durchläufen (siehe Algorithmus 3.1 auf Seite 26 Zeile 14) der Algorithmus adjust clustering (Algorithmus 3.4) aufgerufen. Hier werden nur die Zellen betrachtet, deren Dichte-Kategorie sich im Vergleich zum letzten Aufruf von adjust clustering (bzw. initial clustering, falls dies der erste Aufruf von adjust clustering ist) verändert hat. Sollte die betrachtete Zelle auf die Dichte-Kategorie SPARSE abgefallen sein, wird sie aus ihrem derzeitigen Cluster entfernt. Dabei ist zu beachten, dass dieser Cluster nun geteilt sein könnte. In diesem Fall würden die zusammenhängenden Teile des Clusters nun eigene Cluster bilden. Eine Zelle, die nun die Dichte-Kategorie TRANSITIONAL besitzt, wird dem größten benachbarten Cluster zugeordnet, sofern diese Zelle innerhalb dieses Clusters ein Outside Grid wäre. Bei einer Zelle mit der Dichte-Kategorie DENSE, die bereits einem Cluster zugewiesen ist, wird der größte benachbarte Cluster dieser Zelle gesucht. Anschließend werden beide Cluster zu einem zusammengefasst. Sollte die Zelle noch keinem Cluster zugewiesen sein, bildet sie einen eigenen Cluster. Da die Dichte-Kategorie der einzelnen Zellen die meiste Zeit unverändert bleibt und adjust clustering (3.4) all diese Zellen beim Überprüfen der Dichte-Kategorie überspringt, ist der Algorithmus selbst bei einer großen Anzahl von Zellen relativ effizient. Bei der Aktualisierung der Dichte aller Zellen in Zeile 2 werden alle Zellen in einer Schleife durchlaufen und ihre neue Dichte zur aktuellen Zeit t nach der Gleichung 3.14 berechnet. Dabei wird überprüft, ob sich die Dichte-Kategorie dadurch verändert hat, um diese Zelle ab Zeile 3 weiter zu untersuchen. D(t) = λ t t l (3.14) Der Test, ob ein Cluster c keine Gruppe mehr ist und die daraus folgende Teilung des Clusters (Zeile 6-7) wird mit einem gesamten Durchlauf dieses Clusters realisiert. Da ein Cluster jedoch nur sehr selten geteilt wird, ist dieses Verfahren ausreichend und ohne große Leistungseinbußen realisierbar. Der Test auf die Eigenschaft eines Outside Grids (Zeile 18 und 23) erfolgt durch das Zählen von Nachbar-Zellen, die dem gleichen Cluster zugewiesen sind. Bei einem n- dimensionalen Gitter wäre eine Zelle von allen Seiten eingeschlossen, wenn sie 2n Nachbarn im gleichen Cluster hätte. Andernfalls ist eine Zelle ein Outside Grid. 31

32 Algorithmus 3.4 Das Anpassen der bereits vorhandenen Cluster ([CT07] angepasst) Input grid list - die Liste der Zellen, die Datensätze enthalten 1: procedure adjust clustering(grid list) 2: aktualisiere die Dichte aller Zellen in grid list; 3: for all (Zellen g aus grid list deren Dichte-Kategorie sich im Vergleich zum letzten Aufruf von adjust clustering geändert hat) do 4: if (g hat die Dichte-Kategorie SPARSE) then 5: lösche g aus seinem Cluster c (falls vorhanden); 6: if (c ist keine Gruppe mehr) then 7: teile c in zwei Cluster auf; 8: else if (g hat die Dichte-Kategorie DENSE) then 9: finde unter allen Nachbarn von g die Zelle h, die zu dem größten Cluster c h gehört; 10: if (h hat die Dichte-Kategorie DENSE) then 11: if (g ist keinem Cluster zugeordnet) then 12: weise g den Cluster c h zu; 13: else if (g gehört zu Cluster c und c > c h ) then 14: weise alle Zellen im Cluster c h dem Cluster c zu; 15: else if (g gehört zu Cluster c und c c h ) then 16: weise alle Zellen im Cluster c dem Cluster c h zu; 17: else if (h hat die Dichte-Kategorie TRANSITIONAL) then 18: if (g ist keinem Cluster zugeordnet und h wäre weiterhin ein Outside Grid wenn g dem Cluster hinzugefügt werden würde) then 19: weise g dem Cluster c h zu; 20: else if (g gehört zu Cluster c und c c h ) then 21: lösche h aus c h und weise h den Cluster c zu; 22: else if (g hat die Dichte-Kategorie TRANSITIONAL) then 23: finde unter allen Nachbarn von g die Zelle mit dem größten zugehörigen Cluster c, der nach dem Hinzufügen von g immer noch einen gültigen Cluster bildet; 24: füge g in c ein; 32

33 3.2 Der Moment-Algorithmus In diesem Abschnitt wird die Funktionsweise des Moment-Algorithmus [CWYM06] erklärt. Mit Hilfe des Moment-Algorithmus ist es möglich, häufige Itemsets aus einem kontinuierlichen Datenstrom zu ermitteln und zu verwalten. Dadurch können zu jedem Zeitpunkt die aktuellen closed frequent Itemsets ermittelt werden, um damit beispielsweise Trendanalysen durchzuführen. Hierfür wird ein sogenannter Closed-Enumeration-Tree (kurz CET ) angelegt, der im Verlauf dieses Kapitels näher beschrieben wird. In diesem CET werden alle Informationen gespeichert, um jederzeit die closed frequent Itemsets aus diesem Baum auslesen zu können. Für alle eintreffenden Transaktionen wird angenommen, dass die enthaltenen Items nach einer lexikographischen Ordnung sortiert und in aufsteigender Reihenfolge geordnet sind. Um darzustellen, dass ein Item, beziehungsweise ein Itemset A, lexikographisch kleiner als ein anderes Item oder Itemset B ist, wird die Form A B verwendet. Die Abbildungen dieses Kapitels stammen aus [CWYM06] und wurden in einigen Fällen lediglich um eine Legende erweitert Die Datenstruktur des Moment-Algorithmus Der Moment-Algorithmus liest Itemsets aus einem kontinuierlichen Datenstrom aus. Da zur Ermittlung der häufigen Itemsets nicht alle bereits eingetroffenen Itemsets ein weiteres Mal eingelesen werden können, werden zu jedem Zeitpunkt lediglich die N letzten eingetroffenen Transaktionen betrachtet. Im Folgenden wird die Menge der momentan betrachteten Transaktionen Fenster genannt (Abbildung 3.3). Abbildung 3.3: Beispiel eines Fensters der Größe 4 auf dem Datenstrom ([CWYM06]) Diese Transaktionen werden in einen dynamischen FP-Tree einsortiert und anschließend, wenn das N Transaktionen große Fenster auf dem Datenstrom weiter wandert, aus dem FP-Tree gelöscht. Hierbei ist zu beachten, dass die Itemsets zum schnelleren Auslesen 33

34 in umgekehrter Item-Reihenfolge in den Baum einsortiert werden. Daher sind die ersten Items der Transaktionen am Ende des FP-Trees einsortiert. Dadurch kann ein Itemset von einem Knoten aus schneller gebildet werden, da lediglich die jeweiligen Elternknoten aufgerufen werden müssen. Zusätzlich zu der in Kapitel 2 genannten Struktur eines FP-Trees wird noch eine Liste mit Verweisen auf die ersten Items aller im Fenster enthaltenen Transaktionen gespeichert (Abbildung 3.4). Abbildung 3.4: Der FP-Tree des obigen Beispiels bei dem ersten Fenster Der Closed-Enumeration-Tree Aus den im FP-Tree gespeicherten Transaktionen soll nun eine Datenstruktur erstellt werden, die alle notwendigen Itemsets speichert, um zu jeder Zeit die Menge der closed frequent Itemsets ermitteln zu können. Darüber hinaus soll gewährleistet sein, dass bei dem Hinzufügen neuer Itemsets und dem Löschen alter Itemsets möglichst wenig Operationen auf dieser Datenstruktur angewandt werden müssen. Für diese Aufgabe eignet sich der Closed-Enumeration-Tree (kurz CET). Bei einem CET speichert jeder Knoten n I ein eigenes Itemset I aus der Menge aller möglichen Itemsets aus dem FP-Tree. Um für n I einen Nachfolgeknoten n J zu bilden, wird dem Itemset I ein einzelnes Item hinzugefügt, sodass für das neu entstandene Itemset J gilt: I J. Die Menge aller möglichen Itemsets des FP-Trees kann bei einem großen Fenster rapide ansteigen. Deshalb werden lediglich bestimmte Itemsets im CET gespeichert. Diese sind zum einen alle closed frequent Itemsets und zum anderen die Itemsets, welche eine Grenze zu den übrigen (nicht im CET gespeicherten) Itemsets bilden, da es möglich ist, dass dort zukünftig ebenfalls häufige Itemsets auftreten. Da für die unterschiedlichen Eigenschaften der Knoten und ihren zugehörigen Itemsets unterschiedliche Aktionen ausgeführt werden sollen, wird jeder Knoten in eine von vier Kategorien eingeordnet: Infrequent Gateway Nodes, Unpromising Gateway Nodes, Intermediate Nodes, 34

35 und Closed Nodes. Der CET, der aus dem FP-Tree in Abbildung 3.4 gebildet wird, sowie die Support-Werte der einzelnen Knoten, ist in Abbildung 3.5 zu sehen. Der minimale Support für ein häufiges Item beträgt in diesem Beispiel 2. Abbildung 3.5: CET für das Fenster 1 und einen minimalen Support von 2 Ein Knoten n I ist ein Infrequent Gateway Node, wenn folgende Bedingungen erfüllt sind: 1. das zu n I gehörende Itemset I ist nicht häufig 2. n I s Elternknoten n J enthält ein häufiges Itemset J 3. für ein häufiges Itemset J aus einem der Nachbarknoten von n J gilt: I = J J Zu Beginn der Konstruktion des CETs werden alle Knoten auf der ersten Stufe unter der Wurzel gebildet, die ein Item aus der Menge aller Items Σ enthalten. Von diesen Knoten werden alle, die ein nicht häufiges Item enthalten, ebenfalls als Infrequent Gateway Nodes behandelt. Von einem Infrequent Gateway Node werden keine Nachfolgeknoten gebildet, da diese ebenfalls nicht häufige Itemsets enthalten müssten. Im Beispiel aus Abbildung 3.5 ist D nicht häufig und daher ein Infrequent Gateway Node. Darüber hinaus gibt es keine Knoten, die die Bedingungen erfüllen. Der Knoten CD ist beispielsweise kein Infrequent Gateway Node, da das Itemset nicht aus zwei häufigen Itemsets gebildet wird. Ein Knoten n I ist ein Unpromising Gateway Node, falls n I ein häufiges Itemset I enthält und zusätzlich gilt: Es gibt einen Knoten mit einem Itemset J mit J I und J I, das den gleichen Support wie I hat. Dies gilt im Beispiel für B und AC, da jeweils AB und ABC den gleichen Support haben. Auch von Unpromising Gateway Nodes werden keine Nachfolgeknoten gebildet, da kein Nachfolgeknoten von n I ein closed frequent Itemset enthalten kann. Sollte n I ein häufiges Itemset I enthalten, die zweite Bedingung für Unpromising Gateway Nodes jedoch nicht erfüllt ist, gehört dieser stattdessen zu den Intermediate Nodes, 35

36 falls es einen Nachfolgeknoten n J von n I gibt, dessen Itemset J den gleichen Support wie I hat. Im Beispiel ist A ein Intermediate Node, da A den gleichen Support wie AB hat und A somit kein closed frequent Itemset ist. Alle anderen Knoten mit häufigen Itemsets gehören zu den Closed Nodes. Diese Knoten enthalten die closed frequent Itemsets. Somit müssen für die Ausgabe aller häufigen Itemsets zu einem bestimmten Zeitpunkt lediglich alle Closed Nodes des CETs gefunden und ausgegeben werden. Aus dieser Menge der closed frequent Itemsets lassen sich im Anschluss alle häufigen Itemsets, sowie deren Support ableiten. Mit Hilfe des Apriori-Prinzips und den oben genannten Bedingungen lassen sich für die Knoten des CETs folgende drei Eigenschaften ableiten: 1. Wenn n I mit dem Itemset I ein Infrequent Gateway Node ist, enthält kein Knoten n J mit dem Itemset J I ein häufiges Itemset. 2. Ist ein Knoten n I ein Unpromising Gateway Node, so sind das Itemset von n I, sowie die Itemsets aller Nachfolgeknoten von n I, keine closed frequent Itemsets. 3. Ein Knoten n I aus der Kategorie Intermediate Nodes enthält kein closed frequent Itemset. Es gibt jedoch Nachfolgeknoten von n I, die closed frequent Itemsets enthalten. Mit Hilfe dieser Bedingungen ist es möglich, bestimmte Bereiche des CETs zu löschen, da es dort sicher keine relevanten Itemsets geben kann (wie im Beispiel alle Pfade unter B und C). Andererseits werden so auch Bereiche bewusst vor dem Löschen bewahrt, da hier möglicherweise häufige Itemsets zu finden sind (wie im Beispiel der Knoten A). Für jeden Knoten des CETs wird sowohl das zugehörige Itemset, als auch der Support des Itemsets gespeichert. Zusätzlich wird gespeichert, in welcher Kategorie sich der Knoten befindet. Es ist häufig notwendig zu prüfen, ob es im CET bereits ein closed frequent Itemset gibt, dass den selben Support hat wie das gerade betrachtete Itemset. Daher wird zusätzlich zu dem CET noch eine Tabelle angelegt, die alle closed frequent Itemsets des CET s enthält Der Ablauf des Moment-Algorithmus Der Moment-Algorithmus (Algorithmus 3.5) liest kontinuierlich die Itemsets der Transaktionen aus dem Datenstrom aus und speichert sie wie in Abbildung 3.4 gezeigt in einem FP-Tree. Dabei werden immer nur die N neuesten Transaktionen gespeichert, für jede weitere Transaktion wird die älteste gespeicherte Transaktion aus dem FP-Tree 36

37 gelöscht. Sobald die ersten N Transaktionen ausgelesen wurden, wird der CET mittels Explore (Algorithmus 3.6) aufgebaut. Für jede weitere eintreffende Transaktion wird über die Algorithmen Addition (Algorithmus 3.7) und Deletion (Algorithmus 3.8) jeweils die neu eingelesene Transaktion in den CET eingefügt und anschließend die älteste gespeicherte Transaktion gelöscht. Die Algorithmen Explore, Addition, sowie Deletion werden im weiteren Verlauf dieses Kapitels erklärt. Algorithmus 3.5 Ablauf des Moment-Algorithmus Input N - die Größe des Fensters Input MinSup - der minimale Support, den ein Itemset haben muss, um häufig zu sein 1: procedure Moment(N, MinSup) 2: erstelle leere Liste window; 3: x := 0; //Anzahl an bisher eingelesenen Transaktionen 4: while (Data Stream ist aktiv) do 5: lese neues Itemset I ein; 6: x := x + 1; 7: if x < N then 8: füge I ans Ende von window an; 9: else if (x = N) then 10: füge I ans Ende von window an; 11: erstelle Wurzelknoten n 0 ; 12: Explore(n 0, N, MinSup); 13: else 14: Addition(n 0, I, window, MinSup) 15: füge I ans Ende von window an; 16: I old = das Itemset am Anfang von window; 17: lösche I old aus window; 18: Deletion(n 0, I old, MinSup); Das Befüllen des Closed-Enumeration-Trees Der CET wird aufgebaut, sobald das Fenster mit der Größe N genau N Transaktionen beinhaltet. Diese Transaktionen bilden die momentane Datenbank D. Zu Beginn wird die Wurzel des CET s erstellt, in der lediglich die leere Menge als Itemset gespeichert wird. Anschließend wird für jedes Item I aus der Menge aller Items Σ ein Nachfolgeknoten n I von der Wurzel erstellt. Zum Schluss wird für jeden dieser Knoten n I der Algorithmus Explore aufgerufen (Algorithmus 3.6), wobei der Knoten selbst, die momentane Datenbank D, sowie der minimale Support für die häufigen Itemsets M insup, übergeben wird. Der Explore-Algorithmus ermittelt die Kategorie, in die der Knoten n I eingeordnet 37

38 werden muss und bildet alle wichtigen Nachfolgeknoten von n I, falls dieser Knoten weder ein Infrequent Gateway Node, noch ein Unpromising Gateway Node ist. Bei dem Bilden von Nachfolgeknoten wird die Vereinigung von I und den Itemsets der rechten Nachbarn von n I gebildet, welche häufige Itemsets enthalten. Im Beispiel in Abbildung 3.5 wird daher der Knoten CD nicht gebildet. Anschließend wird für jeden Nachfolgeknoten von n I ebenfalls Explore aufgerufen. Algorithmus 3.6 Der Explore-Algorithmus ([CWYM06] angepasst) Input n I - der Knoten des CET auf dem Explore ausgeführt werden soll Input D - die Menge der momentan betrachteten Transaktionen Input M insup - der Support-Wert, den ein Itemset mindestens haben muss um häufig zu sein 1: procedure Explore(n I, D, MinSup) 2: if (support(n I ) < MinSup) then 3: weise n I die Kategorie Infrequent Gateway Node zu; 4: else if (es gibt in der Tabelle aller closed frequent Itemsets ein Itemset J mit dem selben Support wie I und I J) then 5: weise n I die Kategorie Unpromising Gateway Node zu; 6: else 7: for all (rechte Nachbarknoten n K von n I mit häufigen Itemsets) do 8: bilde einen neuen Nachfolgeknoten n I K mit dem Itemset I K für n I ; 9: berechne den Support von n I K in D; 10: for all (Nachfolgenknoten n I von n I) do 11: Explore(n I, D, MinSup); 12: then if (es gibt einen Nachfolgeknoten n I von n I mit support(n I ) = support(n I)) 13: weise n I die Kategorie Intermediate Node zu; 14: else 15: weise n I die Kategorie Closed Node zu; 16: füge n I der Liste aller closed frequent Itemsets hinzu; In den Zeilen 2-3 wird überprüft, ob der betrachtete Knoten ein Infrequent Gateway Node ist. Dies ist der Fall, falls der Knoten ein nicht häufiges Itemset enthält. Im Anschluss wird in Zeile 4 geprüft, ob es in der Liste der closed frequent Itemsets ein Itemset J gibt, welches eine Obermenge des gerade betrachteten Itemsets ist und den gleichen Support hat. In diesem Fall wäre der Knoten ein Unpromising Gateway Node. In beiden Fällen müssten keine Nachfolgeknoten von solchen Knoten gebildet werden, da weder bei Infrequent Gateway Nodes, noch bei Unpromising Gateway Nodes Nachfolgeknoten existieren können, die closed frequent Itemsets enthalten. Sollte der Knoten zu keinem der beiden Kategorien gehören, so müssen mögliche Nachbarknoten gebildet werden, da es dort closed frequent Itemsets geben kann. Dazu werden 38

39 in den Zeilen 7-9 die Vereinigungen des betrachteten Knotens mit all seinen rechten Nachbarknoten, welche ein häufiges Itemset enthalten, gebildet. Da sich alle rechten Nachbarknoten von dem betrachteten Knoten nur im letzten Item des Itemsets unterscheiden, wird im Endeffekt nur das letzte Item der jeweiligen Knoten an das Itemset angehängt. Anschließend wird für jeden solcher Nachfolgeknoten ebenfalls Explore aufgerufen. Sollte einer dieser Nachfolger den gleichen Support wie sein Elternknoten haben, so ist der Elternknoten ein Intermediate Node (Zeilen 12-13). Andernfalls wird er in Zeile 15 der Kategorie Closed Node zugewiesen, da er ein closed frequent Itemset enthält. Für jede anschließend neu eingelesene Transaktion wird dem Fenster der betrachteten Transaktionen ein neues Itemset hinzugefügt, während die älteste Transaktion aus dem Fenster gelöscht wird. Diese beiden Veränderungen beeinflussen den CET. Daher werden in den folgenden beiden Abschnitten die Aktionen erläutert, die ausgeführt werden müssen, um ein neues Itemset in den CET einzufügen, beziehungsweise ein bereits im CET vorhandenes Itemset wieder aus diesem zu löschen. Das Hinzufügen eines neuen Itemsets in den CET Beim Hinzufügen eines neuen Itemsets müssen zunächst die Support-Werte der betroffenen Knoten neu berechnet werden. Währenddessen wird für jeden Knoten überprüft, ob sich dessen Kategorie verändert hat. In diesem Fall müssen Teile des CET angepasst werden, je nachdem welche Kategorie der betroffene Knoten vorher hatte. Dazu wird beim Eintreffen einer neuen Transaktion der Algorithmus Addition (Algorithmus 3.7) aufgerufen. Diesem wird der Wurzelknoten, sowie die bisherige Menge der Transaktionen D, der minimale Support MinSup und das Itemset der neuen Transaktion I new übergeben. Dabei wird zunächst geprüft, ob das Itemset des Knotens eine Teilmenge des neu hinzugefügten Itemsets, beziehungsweise die leere Menge, ist. Ist dies der Fall (diese Bedingung ist zu Beginn immer wahr, da der Wurzelknoten die leere Menge enthält), werden für alle Nachfolgeknoten dieses Knotens die Support-Werte aktualisiert. Anschließend werden die Kategorien aller Nachfolgeknoten überprüft. 39

40 Algorithmus 3.7 Der Addition-Algorithmus des CET ([CWYM06] angepasst) Input n I - der Knoten des CET auf dem Addition ausgeführt werden soll Input I new - das Itemset der neuen Transaktion Input D - die Menge der bisher betrachteten Transaktionen Input M insup - der Support-Wert, den ein Itemset mindestens haben muss um häufig zu sein 1: procedure Addition(n I, I new, D, MinSup) 2: if (I I new ) then 3: return ; //dieser Knoten ist irrelevant für das Hinzufügen 4: F := {}; //die Menge aller neuen häufigen Nachfolgeknoten von n I 5: for all (Nachfolgeknoten n I von n I ) do 6: aktualisiere den Support von n I ; 7: if (n I ist jetzt häufig geworden) then 8: füge n I in F ein; 9: for all (Nachfolgeknoten n I von n I ) do 10: if (support(n I ) < MinSup) then 11: weise n I die Kategorie Infrequent Gateway Node zu; 12: else if (es gibt in der Tabelle aller closed frequent Itemsets ein Itemset J mit dem selben Support wie I und I J) then 13: weise n I die Kategorie Unpromising Gateway Node zu; 14: else if (n I F oder n I war vorher ein Unpromising Gateway Node) then 15: Explore(n I, D, MinSup); 16: else 17: for all (n K F mit I K) do 18: füge n I einen neuen Nachfolgeknoten n I K hinzu; 19: Addition(n I, I new, D, MinSup); 20: if (es gibt keinen Nachfolgeknoten n I von n I mit support(n I ) = support(n I )) then 21: weise n I die Kategorie Closed Node zu; 22: füge I (falls noch nicht vorhanden) in die Liste aller closed frequent Itemsets ein; Im Beispiel ist der CET nach dem Einfügen der 5. Transaktion aus Abbildung 3.3 in der Abbildung 3.7 zu sehen (für den direkten Vergleich ist in Abbildung 3.6 der CET vor dem Einfügen zu sehen). 40

41 Abbildung 3.6: CET vor dem Hinzufügen in Abbildung 3.7 Abbildung 3.7: Der CET nach dem Hinzufügen der 5. Transaktion mittels Addition Zu Beginn von Addition wird in Zeile 2 geprüft, ob das Itemset des betrachteten Knotens eine Teilmenge des neuen Itemsets I new ist. Sollte dies nicht der Fall sein, so ist der Pfad unter diesem Knoten für das Hinzufügen des neuen Itemsets irrelevant, da hier keine Änderungen vorgenommen werden müssen. In der Abbildung 3.7 ist beispielsweise der gesamte Pfad unter dem Knoten B auch weiterhin uninteressant, da B keine Teilmenge des neu hinzugefügten Itemsets ACD ist und es somit in diesem Pfad keine Änderungen geben wird. Sollte der Pfad jedoch relevant für das Hinzufügen sein, so werden die Support-Werte aller Nachfolgeknoten n I von n I gebildet. Itemsets, die nach der Neuberechnung neuerdings häufig sind, werden in Zeile 8 in der zu Beginn leeren Menge F gespeichert. In der Abbildung 3.7 ist D durch das Hinzufügen nun häufig und wird daher in der Menge F gespeichert. Im darauf folgenden Teil wird die Kategorie für jeden Nachfolgeknoten neu berechnet. Die Tests auf die Kategorien Infrequent Gateway Node und Unpromising Gateway Node 41

42 in den Zeilen verlaufen dabei analog zu den Zeilen 2-5 von Explore (Algorithmus 3.6 auf Seite 38). Im Gegensatz zu Abbildung 3.5 hat der Knoten D nun die Kategorie Unpromising Gateway Node, da das Itemset D einen Support von 2 hat und somit häufig ist. Gehört ein Nachfolgeknoten durch das Hinzufügen des neuen Itemsets neuerdings nicht mehr zu der Kategorie Infrequent Gateway Node oder Unpromising Gateway Node, muss nun auch der bisher ignorierte Pfad unter diesem Knoten betrachtet werden. Dazu wird in Zeile 15 für all solche Knoten Explore aufgerufen, um den Pfad unter diesen Knoten zu bilden. Sollte der betrachtete Nachfolgeknoten bereits ein Intermediate Node oder ein Closed Node gewesen sein, so werden diesem in den Zeilen neue Nachfolgeknoten hinzugefügt, falls es neue rechte Nachbarn dieses Knotens gibt, die neuerdings häufige Itemsets enthalten. Im Beispiel wären dies die Knoten AD und CD, da D neuerdings ein häufiges Itemset ist. Im Anschluss wird auf dem betrachteten Nachfolgeknoten ebenfalls Addition ausgeführt. Danach wird in den Zeilen geprüft, ob der betrachtete Nachfolgeknoten Closed Node ist. Dafür darf es keinen Nachfolger dieses Knotens geben, welcher den gleichen Support hat. Im Beispiel ist A nun ein Closed Node, da A nun einen Support von 4 hat. Da direkt nach dem Hinzufügen einer neuen Transaktion die älteste gespeicherte Transaktion aus dem Fenster gelöscht wird, wird der minimale Support trotz eines größeren D nicht verändert. Daher kann sich die Anzahl an Knoten im CET, sowie die Anzahl an Itemsets in der Tabelle aller closed frequent Itemsets durch den Aufruf von Addition nie verringern. Das Löschen eines Itemsets aus dem CET Beim Löschen einer alten Transaktion müssen die Support-Werte der betroffenen Itemsets im CET angepasst werden. Dabei kann es passieren, dass häufige Itemsets nicht mehr häufig sind, oder Closed Nodes zu Gateway Nodes werden. In diesem Fall müssten alle Nachfolgeknoten dieser Itemsets aus dem CET gelöscht werden. Daher wird beim Löschen der Algorithmus Deletion (Algorithmus 3.8) aufgerufen. Dieser durchläuft den gesamten CET und überprüft, ob Zweige gelöscht, oder die Kategorien einzelner Knoten geändert werden müssen. Dafür wird ihm zu Beginn des Lösch-Vorgangs der Wurzelknoten des CET, sowie das zu löschende Itemset und der Wert MinSup übergeben. Deletion überprüft, ähnlich zu dem vorher vorgestellten Algorithmus Addition (Algorithmus 3.7), alle Knoten des CET auf ihre Kategorien, indem er sich selbst rekursiv für Nachfolgeknoten des übergebenen Knotens aufruft. Bei einem Wechsel der Kategorie eines Knotens werden gegebenenfalls alle Nachfolgeknoten gelöscht (falls der Knoten nun ein Gateway Node ist), oder nur ein Teil der Nachfolgeknoten, falls der Knoten nun ein Intermediate Node ist. Zusätzlich werden Itemsets, die nun nicht mehr zu der Menge der 42

43 closed frequent Itemsets gehören, aus der Tabelle aller closed frequent Itemsets gelöscht. Algorithmus 3.8 Der Deletion-Algorithmus des CET ([CWYM06] angepasst) Input n I - der Knoten des CET auf dem Addition ausgeführt werden soll Input I old - das zu löschende Itemset der alten Transaktion Input M insup - der Support-Wert, den ein Itemset mindestens haben muss um häufig zu sein 1: procedure Deletion(n I, I old, MinSup) 2: F := {}; //die Menge aller neuen nicht-häufigen Nachfolgeknoten von n I 3: for all (Nachfolgeknoten n I von n I ) do 4: aktualisiere den Support von n I ; 5: if (n I ist jetzt nicht mehr häufig) then 6: füge n I in F ein; 7: for all (Nachfolgeknoten n I von n I ) do 8: if (n I war ein Infrequent- oder ein Unpromising Gateway Node) then 9: if (support(n I ) < MinSup) then 10: weise n I die Kategorie Infrequent Gateway Node zu; 11: else if (n I F) then 12: lösche alle Nachfolgeknoten von n I aus dem CET; 13: weise n I die Kategorie Infrequent Gateway Node zu; 14: else if ((es gibt in der Tabelle aller closed frequent Itemsets ein Itemset J mit dem selben Support wie I und I J)) then 15: lösche alle Nachfolgeknoten von n I aus dem CET; 16: weise n I die Kategorie Unpromising Gateway Node zu; 17: else 18: for all (n K F mit I K) do 19: lösche den Nachfolgeknoten n I F von n I aus dem CET; 20: Deletion(n I, I old, MinSup); 21: if (n I war ein Closed Node und es gibt nun einen Nachfolgeknoten n I von n I mit support(n I ) = support(n I )) then 22: weise n I die Kategorie Intermediate Node zu; 23: lösche das Itemset I aus der Liste aller closed frequent Itemsets; In Abbildung 3.9 ist der CET nach dem Löschen der ersten Transaktion aus dem Beispiel zu sehen. Auch hier ist zum direkten Vergleich der CET vor dem Löschen in Abbildung 3.8 gegeben. 43

44 Abbildung 3.8: Der CET vor dem Löschen in Abbildung 3.9 Abbildung 3.9: Der CET nach dem Löschen der 1. Transaktion mittels Deletion Zu Beginn von Deletion werden in den Zeilen 3-6 die Support-Werte aller Nachfolgeknoten berechnet. Falls einer dieser Knoten durch das Löschen der ältesten Transaktion nun nicht mehr häufig ist, wird dieser Knoten in einer zunächst leeren Menge F gespeichert. Im Beispiel in Abbildung 3.9 ist D nun wieder ein nicht häufiges Itemset und würde daher in der Menge F gespeichert werden. Im Anschluss wird für alle Nachfolgeknoten n I geprüft, ob sich ihre Kategorie durch das Löschen verändert hat und ob somit eventuell Pfade des CET gelöscht werden müssen. War ein Knoten n I bereits ein Infrequent Gateway Node oder ein Unpromising Gateway Node, so muss für diesen Knoten lediglich in Zeile 9 überprüft werden, ob das enthaltene Itemset nicht häufig ist. In diesem Falle muss der Knoten der Kategorie Infrequent Gateway Node zugewiesen werden (Zeile 10). Da dieser Knoten jedoch in beiden Fällen keine Nachfolger besitzt, müssen ansonsten keine weiteren Aktionen durchgeführt werden. Im Beispiel in Abbildung 3.9 muss für die Knoten B und D lediglich die Kategorie von D geändert werden. Sollte n I bisher keiner der beiden Kategorien zugeordnet gewesen sein, wird in Zeile 44

45 11 überprüft, ob das Itemset des Knotens neuerdings nicht mehr häufig ist. Dafür wird getestet, ob der Knoten in der Menge F enthalten ist. Ist dies der Fall, so wird der Knoten zu einem Infrequent Gateway Node und all seine Nachfolger werden aus dem CET gelöscht. Falls dies nicht der Fall ist, wird in Zeile 14 analog zu der Zeile 4 in Explore (Algorithmus 3.6 auf Seite 38) getestet, ob der Knoten n I nun ein Umpromising Gateway Node ist. In diesem Fall müssen ebenfalls alle Nachfolger von n I gelöscht werden. Dies ist im Beispiel bei C der Fall, da dieses Itemset nun wieder den gleichen Support wie AC hat. Gehört ein Knoten weiterhin zu einer der beiden Kategorien Intermediate Node oder Closed Node, so müssen in den Zeilen diejenigen Nachfolgeknoten von n I gelöscht werden, die nun nicht häufige Itemsets enthalten. In der Abbildung 3.9 trifft dies auf AD zu, da D nun nicht mehr häufig ist. Deshalb wird dieser Knoten als Nachfolgeknoten von A gelöscht. Für die Nachfolgeknoten von n I, die nicht gelöscht wurden, wird in Zeile 20 ebenfalls Deletion ausgeführt. Zum Schluss wird in den Zeilen geprüft, ob der Knoten n I nun einen Nachfolgeknoten mit dem gleichen Support besitzt. In diesem Fall wird n I der Kategorie Intermediate Node zugewiesen und sein Itemset aus der Liste aller closed frequent Itemsets gelöscht. In der Abbildung 3.11 wurde eine weitere Transaktion aus dem CET gelöscht (siehe Abbildung 3.10 für den direkten Vergleich). Dadurch haben sowohl A, als auch AB nun Nachfolgeknoten mit dem gleichen Support. Diese beiden Knoten sind daher nach dem Löschen Intermediate Nodes. 45

46 Abbildung 3.10: Der CET vor dem erneuten Löschen in Abbildung 3.11 Abbildung 3.11: Der CET nach dem Löschen der 2. Transaktion mittels Deletion 46

47 Kapitel 4 Implementierung In diesem Kapitel wird die Implementierung der in Kapitel 3 beschriebenen Verfahren, sowie deren Anwendung auf bestimmte Einsatzbereiche vorgestellt. Zunächst wird die Umsetzung des D-Stream-Algorithmus für das Clustern von OpenStreetMap-Daten gezeigt. Anschließend wird die Implementierung des Moment-Algorithmus für das Finden von closed frequent Itemsets im Twitter-Stream erläutert. 4.1 Clustering von OpenStreetMap-Daten In diesem Abschnitt wird zunächst die Implementierung des D-Stream-Algorithmus anhand von UML-Diagrammen erläutert. Anschließend wird die Anwendung dieser Implementierung auf einem Datensatz von OpenStreetMap-Daten erklärt Implementierung des D-Stream-Algorithmus Die Implementierung des D-Stream-Algorithmus hält sich weitestgehend an den vorgestellten Algorithmus 3.1 auf Seite 26. Der Aufbau der Architektur ist in Abbildung 4.1 zu sehen. Sie teilt sich in die Datenstruktur Density Grid und die Kern-Komponenten, die sich um das Einfügen der Datensätze in das Gitter und das Bilden der Cluster kümmern. 47

48 D-Stream Core Density Grid ClusterManager T DensityGridGlobals 1 DensityGridCell T <<interface>> IRecordMapper T 1 1 DStream T 1 1 DensityGrid T * 1 CharacteristicVector Abbildung 4.1: UML-Diagramm der D-Stream-Implementierung Das Density Grid Die Datenstruktur hinter dem D-Stream-Algorithmus ist das Density Grid (siehe Abbildung 4.2). Diese besteht aus den einzelnen Zellen, welche von einem Objekt der Klasse DensityGrid verwaltet werden. Density Grid T DensityGridGlobals decayfactor : float N : int Cm : float Cl : float Dm : float Dl : float beta : float 1 1 DensityGridCell coords : int[ ] records : Vector<T> densitycategory : Density getdensityattime(time : int) : float addrecord(record : T, time : int) : void getcurrentdensitycategoriy() : Density getdensitythreshold(time : int) : float deletecell(time : int) : void 1 CharacteristicVector tg : int tm : int d : float label : string status : Status * T DensityGrid allgrids : Hashtable<String, DensityGridCell<T>> gridlist : Hashtable<String, DensityGridCell<T>> addrecord(record : T, time : int, coords : int[ ]) : void deletesporadicgrids(time : int, timeoflastinspection : int) : void marksporadicgrids(time : int) : void Abbildung 4.2: UML-Diagramm der Datenstruktur Density Grid 48

49 Für jede Zelle des Density Grids gibt es ein Objekt der Klasse DensityGridCell, welches alle wichtigen Eigenschaften der Zelle speichert. Diese sind die Koordinaten der Zelle innerhalb des Density Grids, die Dichte-Kategorie der Zelle (bspw. DENSE), sowie ein Objekt der Klasse Characteristic Vector. In diesem Characteristic Vector sind die in Kapitel 3 beschriebenen Eigenschaften der Zelle gespeichert. Außerdem enthält jede Zelle einen Verweis auf ein Objekt der Klasse DensityGridGlobals. Diese enthält die wichtigen Eigenschaften, die für das gesamte Density Grid gleich sind. Dazu gehören der Alterungsfaktor λ (in der Klasse decayfactor genannt), die Anzahl aller Zellen N, sowie die Werte für das Einordnen der Zellen in Dichte-Kategorien, C m, C l, D m und D l und der Wert β für das Löschen von Zellen (in der Klasse beta genannt). Zusätzlich ist in jeder Zelle eine Liste gespeichert, in die alle Datensätze eingefügt werden, die dieser Zelle zugewiesen werden. Jede DensityGridCell enthält die Funktionen getdensityattime und getcurrentdensity- Categoriy, mit deren Hilfe die aktuelle Dichte, sowie die Dichte-Kategorie (z.b. DENSE) der Zelle zu der gegebenen Zeit berechnet werden können. Die Funktion getdensityat- Time berechnet dabei die aktuelle Dichte der Zelle in Abhängigkeit von der gegebenen Zeit, sowie dem Alterungsfaktor λ und dem letzten Zeitpunkt t l, an dem dieser Zelle ein neuer Datensatz hinzugefügt wurde nach der Gleichung 3.14 auf Seite 31. Die Funktion getcurrentdensitycategory teilt die Dichte-Kategorie der Zelle in Abhängigkeit von ihrer aktuellen Dichte (siehe ebenfalls Gleichung 3.14) nach den in Kapitel 3 genannten Bedingungen ein. Die Funktion addrecord fügt einen neuen Datensatz in die Zelle ein, speichert ihn am Ende der Liste dieser Zelle und aktualisiert deren Dichte für den gegebenen Zeitpunkt nach der Gleichung 3.3 auf Seite 24. Wird eine Zelle gelöscht, so wird für diese Zelle die Funktion deletecell aufgerufen. Diese Funktion löscht alle Datensätze aus der Zelle und setzt all ihre Attribute auf die Anfangswerte. Lediglich in ihrem Characteristic Vector wird im Attribut t m der aktuelle Zeitpunkt gespeichert. Alle Zellen des Density Grids werden in einem Objekt der Klasse DensityGrid gespeichert. Da für alle Zellen unabhängig davon, ob sie gerade den Status gelöscht oder nicht gelöscht haben, gespeichert werden muss, wann sie zuletzt aus der grid list gelöscht wurden, werden zu Beginn des Programms alle Zellen des Density Grids erstellt und für einen schnelleren Zugriff in der Hash-Liste allgrids gespeichert. Der Schlüssel einer Zelle sind dabei ihre Koordinaten im Density Grid als Zeichenkette zusammengefasst. So ist gewährleistet, dass alle Zellen einen einzigartigen Schlüssel besitzen. Alle Zellen, die Datensätze enthalten, werden zusätzlich mit dem gleichen Schlüssel in der Hash-Liste gridlist gespeichert. Darüber hinaus enthält die Klasse DensityGrid die nötigen Funktionen, um die Zellen zu verwalten. Die Funktion addrecord ruft für die Zelle mit den gegebenen Koordinaten deren Funktion addrecord auf und übergibt ihr einen neuen Datensatz mit der aktuellen 49

50 Zeit. Sollte die angegebene Zelle zu diesem Zeitpunkt noch keine Datensätze enthalten (und somit auch nicht in der Liste gridlist gespeichert sein), wird sie zusätzlich in die Liste gridlist eingefügt. Die beiden Funktionen deletesporadicgrids und marksporadicgrids sind für das in Kapitel 3 beschriebene Löschen von Sporadischen Zellen verantwortlich. Dabei werden zuerst mittels deletesporadicgrids alle Zellen gelöscht, die bereits den Status SPORADIC besitzen und weiterhin die Eigenschaften einer sporadischen Zelle erfüllen und anschließend mit marksporadicgrids für alle Zellen geprüft, ob sie ihren Status zu SPORADIC wechseln müssen. Durch diese Reihenfolge ist sichergestellt, dass bei einem Löschvorgang keine Zelle gleichzeitig von normal zu sporadisch wechselt und direkt gelöscht wird. Um eine Zelle zu löschen, wird für sie die Funktion deletecell mit der aktuellen Zeit als Übergabeparameter aufgerufen. Anschließend wird sie aus der Liste gridlist entfernt (in der Liste allgrids bleibt sie jedoch weiterhin gespeichert). Der D-Stream-Algorithmus Die Hauptaufgaben des D-Stream-Algorithmus werden in den beiden Klassen Cluster- Manager und DStream bearbeitet (Abbildung 4.3). D-Stream Core Density Grid DensityGrid T 1 gap : int time : int DStream T 1 <<interface>> IRecordMapper T addrecord(record : T) : void getgrid() : DensityGridCell<T>[] maprecord(record : T) : int[ ] 1 T ClusterManager initialclustering(gridlist : DensityGridCell<T>[ ], time : int) adjustclustering(gridlist : DensityGridCell<T>[ ], time : int) Abbildung 4.3: UML-Diagramm der Hauptkomponenten von D-Stream Die Klasse DStream bildet eine Schnittstelle zwischen dem ClusterManager und der Datenstruktur. Sie speichert die aktuelle Zeit, sowie das Zeitintervall gap, in dem jeweils die Cluster-Algorithmen aufgerufen werden. Die wichtigste Funktion der Klasse ist addrecord. Diese fügt dem Density Grid einen neuen Datensatz hinzu und ruft gegebenenfalls die Funktionen der Klasse ClusterManager auf. Das Density Grid lässt sich mit Hilfe der Funktion getgrid jederzeit abrufen. Diese Funktion gibt ein Array mit allen Zellen 50

51 des Gitters zurück, welche momentan nicht gelöscht sind. In welche Zelle des Gitters ein neuer Datensatz eingeordnet werden muss, wird mit Hilfe eines IRecordMappers ermittelt. Dieser stellt die Funktion maprecord bereit, welche für einen übergebenen Datensatz die zugehörigen Koordinaten innerhalb des Gitters ermittelt. Da bei verschiedenen Experimenten die Einordnung der Datensätze von einigen Faktoren, wie zum Beispiel der Anzahl an Zellen im Gitter oder den Arten von Eigenschaften der einzelnen Datensätze, abhängt, ist diese Klasse lediglich ein Interface und muss für die jeweiligen Umstände angepasst implementiert werden. Diese Implementierung ist in Kapitel 5 jeweils angegeben. Alle gap Zeitschritte werden die beiden Funktionen der Klasse ClusterManager aufgerufen, welche die Liste gridlist des Density Grids als Übergabeparameter erhalten und für das Bilden der Cluster zuständig sind. Außerdem werden die beiden Funktionen deletesporadicgrids und marksporadicgrids der Klasse DensityGrid aufgerufen, um sporadische Zellen zu löschen. Die beiden Prozeduren initial clustering (Algorithmus 3.3 auf Seite 30) und adjust clustering (Algorithmus 3.4 auf Seite 32) werden innerhalb der Klasse Cluster- Manager nach ihren Vorlagen ausgeführt. Die Zuweisung der Cluster erfolgt dabei über die Variable label in dem jeweiligen Charcteristic Vector der Zelle. Die Namen neuer Cluster werden durchlaufend nummeriert, sodass keine zwei Cluster den gleichen Namen erhalten Anwendung für das Clustern von OpenStreetMap-Daten Für das Clustern und Ausgeben der OpenStreetMap-Daten sind die Klassen GeoOutput, sowie GeoBuffer und GeoMapper zuständig (siehe Abbildung 4.4). Die Hauptklasse ist dabei GeoOutput. Sie speichert ein Objekt der Klasse DStream, sowie einen GeoBuffer und GeoMapper. Die Klasse GeoMapper ist eine Implementierung des Interfaces IRecordMapper. Es speichert die minimalen und maximalen möglichen Koordinaten in X- und Y Richtung, sowie die Breite und Höhe einer Zelle des Gitters, dass über die gewünschte Karte gelegt wird. Die Funktion maprecords gibt anschließend für jedes übergebene Zahlenpaar (gespeichert in einem Vektor) die Koordinaten im Gitter zurück. Mit Hilfe der Klasse GeoBuffer lässt sich eine Verbindung zu dem gewünschte Datenbankserver aufbauen, auf dem die OpenStreetMap-Daten gespeichert sind und diese anschließend stückweise ausgeben. Dafür werden in dieser Klasse zum einen der Nutzername und das Passwort in einem Objekt der Klasse Properties und zum anderen die Adresse des Datenbankservers gespeichert. 51

52 Die Funktion getnextdata schickt eine Anfrage an den Datenbankserver, durch die die nächsten Datensätze nach Datum sortiert zurückgegeben werden. Dabei wird immer nur der nächste Block an Datensätzen zurückgegeben. Wie groß dieser Block ist, wird über die Variable limit bestimmt. Die Variable offset speichert, wie viele Blöcke von Datensätzen bereits ausgelesen wurden. Sollte es keine Datensätze mehr geben, gibt diese Funktion false zurück, andernfalls ist die Rückgabe true. Die beiden Funktionen getwholedataset und getnextdata geben die so erhaltenen und gespeicherten Datensätze entweder im Ganzen, oder einen nach dem anderen zurück. Die Klasse GeoOutput öffnet beim Aufruf der Main-Methode ein User-Interface, in dem alle Daten und Parameter für das Ausführen des Programms eingegeben werden können. Darunter fallen z.b. der Benutzername und das Passwort, sowie die Parameter des D- Stream-Algorithmus. Beim Drücken des Startknopfes werden über den GeoBuffer solange Daten eingelesen und dem D-Stream-Algorithmus übergeben, bis das Programm beendet wird, oder die Funktion getnextdata false zurückgibt, weil alle Datensätze ausgelesen wurden. Die Ergebnisse von D-Stream werden als Punktmengen in csv-dateien gespeichert, um sie später mit Hilfe von Visualisierungs-Tools für den Benutzer anzuzeigen. D-Stream OSM GeoBuffer Core DStream Vector<Float> 1 GeoOutput main(args : String[]) : void 1 GeoMapper 1 properties : Properties url : String limit : int offset : int getnextdata(fromtable : String) : boolean getwholedataset() : Vector<String> getnextdataset() : String 1 xmin : int xmax : int ymin : int ymax : int scalex : int scaley : int maprecord(record : Vector<Float>) : int[] Abbildung 4.4: UML-Diagramm der OpenStreetMap-Visualisierung 52

53 4.2 Implementierung des Moment-Algorithmus In diesem Abschnitt wird die Implementierung des Moment-Algorithmus (ebenfalls mit Hilfe von UML-Diagrammen) vorgestellt. Anschließend wird die Implementierung der Schnittstelle zum Twitter-Stream gezeigt Implementierung des Moment-Algorithmus Die Implementierung des Moment-Algorithmus nach [CWYM06] ist in 3 Komponenten unterteilt: Der CET, der FP-Baum und die Klasse Moment, die eine Schnittstelle zwischen den beiden Komponenten bildet (siehe Abbildung 4.5). Moment CET FP-Tree I I I CET 1 Moment 1 FPTree * I * * CETNode * FPNode I Abbildung 4.5: UML-Diagramm der Moment-Implementierung Abweichung zum Vorbild Der in Kapitel 3 vorgestellte Algorithmus sieht vor, dass die Menge der einzelnen Items, aus denen alle Itemsets bestehen, zu Beginn bekannt und nicht veränderbar ist. Allerdings zeigte sich in den in Kapitel 5 vorgestellten Tests, dass die Menge an einzelnen Items in vielen Fällen nicht vorher bekannt ist und sich im Verlauf des Programms stetig ändert. Daher wurde dies in der Implementierung berücksichtigt und weicht von dem in [CWYM06] vorgestellten Verfahren ab. Gleichzeitig wäre eine Funktion zum Löschen von Items mit einem Support von 0 aus dem CET auf lange Sicht womöglich hilfreich, da durch die obige Abweichung die Menge von Items stetig anwächst. Diese Funktion wurde allerdings nicht integriert, da in allen Experimenten keine spürbare Verlangsamung des Algorithmus auf Dauer zu messen war. 53

54 Der FP-Tree Die eingelesenen Itemsets werden zunächst in einem FP-Tree gespeichert (siehe Abbildung 4.6). Dieser besteht aus Objekten der Klasse FPNode, wobei jeder Knoten ein einzelnes Item enthält. Wie in [CWYM06] wird hierbei jedes Itemset in umgekehrter Reihenfolge gespeichert, um die Zeit für das Bilden des gesamten Itemsets von diesem Knoten aus zu verkürzen. FP-Tree FPTree headtable : Vector<FPNode<I>> getsupportof(itemset : Vector<I>) : int additemset(itemset : Vector<I>) : void deleteitemset(itemset : Vector<I>) : void I * I * item : I support : int FPNode addchild(newchild : FPNode) : void Abbildung 4.6: UML-Diagramm des FP-Trees und seiner Knoten Jedes Objekt der Klasse FPNode enthält ein einzelnes Item. Zusätzlich wird der Support- Wert des Itemsets in einem Knoten gespeichert, welches von diesem Knoten, bis zur Wurzel des FP-Trees gebildet wird. Außerdem sind in jedem Knoten Verweise auf die Nachfolgeknoten, den Elternknoten und den nächsten Knoten im Baum gespeichert, der das gleiche Item enthält. Die Funktion addchild fügt den übergebenen FPNode als neuen Nachfolgeknoten an diesen Knoten an. Zusätzlich werden die Verweise für das in diesem Knoten gespeicherte Item aktualisiert. Die einzelnen Knoten werden von der Klasse FPTree verwaltet. In dieser Klasse ist der Verweis auf den Wurzelknoten, sowie die Liste headtable gespeichert, welche die Verweise auf die ersten Vorkommen der einzelnen Items im Baum enthält. Die Funktion getsupportof der Klasse FPTree durchsucht den Baum nach allen Vorkommen des übergebenen Itemsets (Itemsets werden im gesamten Programm als Vektoren von Items gespeichert) und summiert deren Support-Werte. Diese Summe wird anschließend zurückgegeben. Die beiden Funktionen additemset und deleteitemset sind für das Hinzufügen, bzw. 54

55 Löschen von Itemsets im FP-Tree zuständig. Dabei werden die Support-Werte der betroffenen Knoten aktualisiert und bei Bedarf neue Knoten hinzugefügt, bzw. alte Knoten gelöscht. Auch die headtable wird dabei stetig aktualisiert. Der CET Der Closed-Enumeration-Tree speichert die closed frequent Itemsets, sowie die Itemsets, deren Obermengen eventuell in der Zukunft ebenfalls closed frequent Itemsets enthalten könnten (siehe Abbildung 4.7). Der CET besteht aus einzelnen Objekten der Klasse CETNode, die von einem CET verwaltet werden. CET CET closedfrequentitemsets : List<CETNode<I>> minsup : int differentitems : Vector<I> create(items : Vector<I>, D : FPTree<I>) : void additemset(newitemset : Vector<I>, D : FPTree<I>) deleteitemset(olditemset : Vector<I>, D : FPTree<I>) I * CETNode lastitem : I nodetype : NodeType support : int addchild(newchild : CETNode<I>) : void getrightsiblings() : Vector<CETNode<I>> I * Abbildung 4.7: UML-Diagramm des CET und seiner Knoten Jedes Objekt der Klasse CETNode enthält lediglich das letzte Item seines Itemsets. Im Gegensatz zu dem FP-Tree werden hier allerdings die Itemsets in der normalen Reihenfolge (mit den letzten Items an den Blättern) gespeichert. Darüber hinaus enthält jeder Knoten den Support seines zugehörigen Itemsets, den NodeType (z.b. Unpromising Gateway Node) und die Verweise auf seine Nachfolgeknoten und seinen Elternknoten. Die Funktion addchild fügt der Liste von Nachfolgeknoten den übergebenen CETNode hinzu. Dabei werden die Nachfolgeknoten aufsteigend, nach ihren enthaltenen Items sortiert, in einer Liste von Nachfolgeknoten gespeichert. getrightsiblings ist für das Bestimmen der Kategorie eines Knotens n wichtig. Sie springt zu dem Elternknoten von n und gibt alle CETNodes zurück, die in der Liste der Nachfolgeknoten hinter n gespeichert sind. Durch die Sortierung der Items werden so alle Nachbarknoten zurückgegeben, deren Items lexikographisch größer sind, als das Item von n. Wegen der Eigenschaften des CET können nur diese Items in den Nachfolgeknoten von n enthalten sein. Die Knoten werden von einem Objekt der Klasse CET verwaltet. Dieser speichert die Liste aller momentanen closed frequent Itemsets, den minimalen Support, sowie eine Liste aller einzelnen Items. Da es im Gegensatz zu [CWYM06] auch neue Items während des Programm-Durchlaufs geben kann, ändert sich die Liste stetig. Außerdem wird der Verweis auf den Wurzelknoten des CET gespeichert. 55

56 Die drei Funktionen der Klasse CET implementieren die drei Algorithmen 3.6, 3.7 und 3.8 aus Kapitel 3. Dabei wird in der Funktion create der CET komplett initialisiert. Anschließend wird für jedes Item der übergebenen Liste items ein Nachfolgeknoten der Wurzel angelegt. Zuletzt wird für jeden dieser Nachfolgeknoten der Algorithmus Explore (Algorithmus 3.6 auf Seite 38) aufgerufen. Die beiden Funktionen additemset und deleteitemset rufen für das neue, bzw. alte Itemset für den Wurzelknoten die Algorithmen Addition (Algorithmus 3.7 aus Seite 40), bzw. Deletion (Algorithmus 3.8 auf Seite 43) auf. In additemset wird vorher jedoch die Liste aller einzelnen Items differentitems aktualisiert, falls das neue Itemset noch nicht bekannte Items enthält. Die Klasse Moment Die Klasse Moment bildet eine Schnittstelle zwischen dem FP-Tree und dem CET (siehe Abbildung 4.8). Darüber hinaus verwaltet diese Klasse das Fenster für die ankommenden Itemsets und die Ausgabe aller closed frequent Itemsets nach außen. Moment CET I FP-Tree CET I 1 Moment window : Queue<Vector<I>> windowsize : int singleitems : Vector<I> 1 FPTree I additemset(itemset : Vector<I>) : boolean getclosedfrequentitemsets() : Vector<Vector<I>> Abbildung 4.8: UML-Diagramm der Klasse Moment Moment speichert eine Queue, welche das Fenster für die Itemsets darstellt (die Itemsets werden nach dem FIFO-Prinzip gespeichert und gelöscht), eine Liste mit allen einzelnen Items aller Itemsets und die maximale Größe dieses Fensters. Außerdem enthält die Klasse Verweise auf ein Objekt der Klasse CET und ein Objekt der Klasse FPTree. Die Funktion additemset fügt dem FP-Tree ein neues Itemset mittels dessen Funktion additemset hinzu. Zusätzlich wird das Itemset in der Queue gespeichert. Falls das Itemset Items enhält, die vorher noch nicht bekannt waren, wird die Liste singleitems aktualisiert. Sollte die Queue die Größe windowsize erreichen, so wird zusätzlich die Funktion create der Klasse CET aufgerufen. Dafür wird die Liste singleitems und der FP-Tree übergeben. Bei jedem weiteren Aufruf von additemset wird nun das Itemset in die Queue und in den 56

57 FP-Tree eingefügt und für den CET die Funktion additemset aufgerufen. Anschließend wird das erste Itemset aus der Queue gelöscht und für den FP-Tree und den CET die Funktion deleteitemset für dieses Item aufgerufen Anwendung des Moment-Algorithmus auf dem Twitter- Stream Die Verbindung mit Twitter wird über die Bibliothek Twitter4J ([TW4]) hergestellt. Mit Hilfe der dort enthaltenden Funktionen ist es möglich, den Datenstrom aller verfassten Tweets nach bestimmten Schlagworten zu filtern. Tweets, die eines der Schlagworte enthalten, werden ausgegeben und können anschließend zur Assoziationsanalyse genutzt werden. Die Implementierung dieser Funktionen ist in Abbildung 4.9 zu sehen. Sie besteht aus den beiden Klassen OwnStatusListener und TwitterStreamController. Moment Twitter Moment String 1 TwitterStreamController nextinput(hashtags : Vector<String>) : void getsingleitems() : Vector<String> gettransactioncount() : int getclosedfrequentitemsets() : Vector<Vector<String>> 1 1 OwnStatusListener onstatus(status status) : void Abbildung 4.9: UML-Diagramm der Twitter-Implementierung Um das Verwalten des Twitter-Streams kümmert sich die Klasse OwnStatusListener. Sie ist eine Erweiterung der Twitter4J-Klasse StatusListener und überschreibt deren Funktion onstatus. Diese wird bei jeder Nachricht des Twitter-Streams aufgerufen, die eines der vorgegebenen Schlagworte enthält. Die Funktion liest die Nachricht aus, filtert alle Hashtags heraus und speichert diese in einer Liste. Anschließend wird die Funktion nextinput des ihr zugewiesenen Objekts der Klasse TwitterStreamController aufgerufen und die Liste der Hashtags als Parameter übergeben. 57

58 Die Klasse TwitterStreamController enthält sowohl ein Objekt der Klasse OwnStatusListener, als auch ein Objekt der Klasse Moment (dabei ist der Typ der einzelnen Items im CET String). Sie erhält über die Funktion nextinput die Hashtags der nächsten Nachricht und ordnet die übergebene Liste alphabetisch, damit sie in einem CET alle notwendigen Eigenschaften eines Itemsets erfüllt. Anschließend ruft sie die Funktion additemset (siehe Abbildung 4.8) des Objekts der Klasse Moment auf und übergibt ihm die Liste der Hashtags als neues Itemset. Über die drei anderen Funktionen lassen sich die derzeitigen Informationen des in Moment gespeicherten CETs abrufen: getsingleitems gibt eine Liste aller Hashtags zurück, die in den Itemsets im CET mindestens ein Mal enthalten sind. gettransactioncount gibt die Anzahl an Itemsets zurück, die bereits in den CET eingefügt wurden, auch wenn sie mittlerweile schon gelöscht wurden. getclosedfrequentitemsets gibt eine Liste aller closed frequent Itemsets zurück, die im derzeitigen Fenster der CETs enthalten sind. 58

59 Kapitel 5 Ergebnisaufbereitung In diesem Kapitel werden die beiden implementierten Algorithmen in zwei Beispiel- Bereichen eingesetzt und die daraus resultierenden Ergebnisse sowie der Einfluss der Parameter untersucht. Dazu wird im ersten Abschnitt das Clustern von Daten auf einem selbst erstellten Punktdatensatz und anschließend auf OpenStreetMap-Datensätzen gezeigt. Im zweiten Abschnitt wird das Finden von closed frequent Itemsets im Twitter-Stream mit Hilfe des Moment-Algorithmus untersucht. 5.1 Clustering von Daten aus einem Datenstrom In diesem Abschnitt wird die Funktionalität des D-Stream-Algorithmus anhand von zwei Versuchs-Beispielen untersucht. Im ersten Teil wird dabei ein selbst erstellter Punkt- Datensatz benutzt, um das Entstehen und Zerfallen von Clustern mittels D-Stream zu untersuchen. Im zweiten Teil wird der D-Stream-Algorithmus auf OpenStreetMap- Datensätzen eingesetzt, um die zeitliche Entwicklung der hinzugefügten Datensätze in Bayern und anschließend in ganz Deutschland zu untersuchen. Der dritte Teil beschäftigt sich mit dem Einfluss der Parameter auf das Ergebnis von D-Stream Clustering eines Punkt-Datensatzes Um zu prüfen, ob mit Hilfe des implementierten D-Stream-Algorithmus tatsächlich Cluster gefunden und Rauschpunkte herausgefiltert werden können, wurde ein Datensatz mit Punkten im 2-dimensionalen Raum x = ([ 1, 1], [ 1, 1]) erstellt (siehe Abbildung 5.1). Von diesen Punkten wird pro Zeitschritt ein Punkt zufällig ausgewählt und dem D- 59

60 Stream-Algorithmus übergeben. Anschließend wird dieser Punkt aus der Liste gelöscht, bis alle Punkte aus der Liste entfernt wurden. Insgesamt wurden Punkte mit 4 Clustern erstellt. Die Aufteilung der Punkte ist in Tabelle 5.1 zu sehen. Teil des Datensatzes Anzahl an Punkten Gesamt 35k Rauschen 5k je Cluster 7.5k Tabelle 5.1: Aufteilung der Punkte im Datensatz Abbildung 5.1: Alle Punkte des Datensatzes Es wurde in Anlehnung an das in [CT07] vorgestellte Experiment ein quadratisches Gitter mit 400 Zellen (20 20) erstellt. Die Werte der einzelnen globalen Variablen des Gitters sind ebenfalls aus [CT07] übernommen und in Tabelle 5.2 dargestellt. Variable Wert C m 3.0 C l 0.8 λ β 0.3 Tabelle 5.2: Werte der Variablen des Density Grids 60

61 Über das Feld in Abbildung 5.1 wird ein Gitter mit den Maßen Felder gelegt. Die Implementierung der Klasse IRecordMapper aus Kapitel 4 für diesen Versuch, gibt bei dem Aufruf von maprecord die Koordinaten des Feldes in diesem Gitter zurück, in dem der übergebene Punkt in der Abbildung liegen würde. Die Ergebnisse während des Durchlaufs sind in Abbildung 5.2 zu sehen. Es ist erkennbar, dass die Cluster trotz ihrer unterschiedlichen Form zuverlässig gefunden und die meisten Rauschpunkte erfolgreich herausgefiltert werden. Da die beiden Halbkreise im unteren linken Quadranten sehr dicht beieinander liegen, werden beide Halbkreise als ein gemeinsamer Cluster erkannt. Abbildung 5.2: Cluster nach dem D-Stream-Durchlauf Um zu beobachten, wie sich die Entwicklung der einzelnen Cluster über die Zeit verhält, wird der gleiche Datensatz an Punkten wie im obigen Beispiel benutzt (siehe Abbildung 5.1). Diesmal werden die Punkte jedoch nicht zufällig aus der Liste ausgewählt und hinzugefügt. Stattdessen werden die Punkte jedes Clusters nacheinander komplett dem D-Stream-Algorithmus hinzugefügt (innerhalb des Clusters werden die Punkte zufällig bestimmt). Erst wenn ein Cluster komplett hinzugefügt wurde, werden die Punkte des nächsten Clusters hinzugefügt. Die beiden kleinen Halbkreise im unteren linken Quadranten werden dabei nacheinander eingefügt. Zusätzlich wird jeder 6. Punkt aus der Menge der Rauschpunkte genommen. Die Variablen entsprechen den Werten in Tabelle 5.2. Auch in diesem Falle wurde ein 400 Zellen großes, quadratisches Gitter benutzt. 61

62 Zu Beginn wird der Cluster im oberen linken Quadranten hinzugefügt (siehe Abbildung 5.3). Sobald diesem Cluster keine weiteren Punkte hinzugefügt werden, sinkt die Dichte der einzelnen Zellen, bis sie aus dem Gitter gelöscht werden (siehe Abbildung 5.4). Abbildung 5.3: Cluster während des D-Stream-Durchlaufs (8.750 hinzugefügte Punkte) Abbildung 5.4: Cluster während des D-Stream-Durchlaufs ( hinzugefügte Punkte) Dieses Altern der Daten lässt sich gut in Abbildung 5.5 und 5.6 sehen. Nachdem der linke der beiden Halbkreise hinzugefügt wurde, wird nun der rechte Halbkreis in das Gitter eingefügt. Währenddessen zerfällt bereits sein linker Nachbar (Abbildung 5.5). Ab einem gewissen Punkt wird dabei die Verbindung der beiden Halbkreise gelöscht, da die Dichte der Zellen zu weit gesunken ist. Dadurch bildet sich ein zweiter Cluster, der von dem ursprünglichen Cluster getrennt ist (zu sehen an der Änderung der Farbe in Abbildung 5.6). 62

63 Abbildung 5.5: Cluster während des D-Stream-Durchlaufs ( hinzugefügte Punkte) Abbildung 5.6: Cluster während des D-Stream-Durchlaufs ( hinzugefügte Punkte) Clustering von OpenStreetMap-Daten Als zweiten Versuch wird das Clustern von geographischen Daten mittels D-Stream untersucht. Dafür wird ein OpenStreetMap-Datensatz (im Folgenden nur OSM-Datensatz) aller Straßen in Bayern benutzt. Dieser Datensatz enthält Straßeneinträge aus den Jahren 2007 bis Die Koordinaten dieser Straßen werden, nach dem Datum ihres Erscheinens im Datensatz geordnet, dem D-Stream-Algorithmus übergeben. Alle Punkte wird das Zwischenergebnis des Clusterings gespeichert, um es zu visualisieren. Die Parameter des D-Stream-Algorithmus sind in Tabelle 5.3 zu sehen. Das Density Grid ist ein quadratisches Gitter mit Feldern. Aufgrund der großen Menge an 63

64 Punkten im Datensatz werden die einzelnen Werte im Vergleich zum vorigen Versuch etwas verändert, um die Schwelle, ab deren Dichte eine Zelle zu einem Cluster zugeordnet wird, zu erhöhen und weniger dichte Zellen schneller zu löschen. Variable Wert λ C m 4.0 C l 1.2 β 0.4 Tabelle 5.3: Parameter für das Clustern der OSM-Daten Die einzelnen Cluster werden auf einer Karte von Bayern angezeigt. Jeder Cluster hat dabei eine eigene Farbe. Das Ergebnis des Clusterings der ersten Punkte (im Jahr 2007) ist in Abbildung 5.7 zu sehen. Es ist ein erkennbarer Schwerpunkt an Clustern um einige der größten Städte Bayerns zu sehen. Besonders im Bereich der Landeshauptstadt München ist der größte Cluster mit Punkten (ca. 20% aller hinzugefügten Punkte) zu sehen. Zusätzlich sind vereinzelt kleinere Cluster am südlichen Rand Bayerns zu sehen. Im weiteren Verlauf des D-Stream-Algorithmus (bis zum Jahr 2009) ist eine Verschiebung der Cluster in den Norden zu sehen (Abbildung 5.8). Zum einen ist der Cluster um München herum geschrumpft (6.040 Punkte), da seit zu langer Zeit keine neuen Punkte hinzugefügt wurden. Zum anderen sind die Cluster im Süden Bayerns vollkommen verschwunden. Stattdessen ist eine Konzentration der Cluster in der nördlichen Hälfte Bayerns zu sehen. Den größten Cluster bildet das Gebiet zwischen Fürth und Bamberg mit Punkten. Durch die große Anzahl an Punkten, die überall in Bayern hinzugefügt werden, gibt es viele Zellen, die keinem Cluster zugeordnet sind, da ihre Dichte zu gering ist. Allerdings unterschreiten auch nur sehr wenige Zellen die Schwelle, ab der sie komplett gelöscht werden. Daher enthalten die Cluster später sehr viele Punkte und bilden zum Großteil sehr eckige Formen aus. Zu sehen ist dies in Abbildung 5.9. Im Gegensatz zu Abbildung 5.7 sind hier ( hinzugefügte Punkte im Jahr 2013) viele Cluster zu sehen, die nicht im Umfeld von großen Städten liegen. Der Cluster um München ist sogar ganz verschwunden. Stattdessen liegen die Cluster zum Großteil an den Stellen, an denen zu Beginn des Algorithmus keine Cluster zu sehen waren. Das bedeutet, dass diese Bereiche erst später in die OSM- Datensätze eingefügt wurden. 64

65 Abbildung 5.7: Darstellung der Cluster in Bayern im Jahr 2007 (100k Punkte) 65

66 Abbildung 5.8: Darstellung der Cluster in Bayern im Jahr 2009 (2750k Punkte) 66

67 Abbildung 5.9: Darstellung der Cluster in Bayern im Jahr 2013 (10900k Punkte) Der gleiche Versuch wird nun mit dem OSM-Datensatz von ganz Deutschland durchgeführt, um zu prüfen, ob dort eine ähnliche zeitliche Verteilung der Cluster entsteht. Die Parameter sind dabei unverändert (Tabelle 5.3). Der Datensatz enthält insgesamt Einträge aus den Jahren 2007 bis Das Ergebnis des Clusterings nach hinzugefügten Punkten (im Jahr 2007) ist in Abbildung 5.10 zu sehen. Wie auch bei dem Bayern-Datensatz ist hier einer der größten Cluster im Bereich von München zu sehen. Zusätzlich sind große Cluster um Hamburg und im Ruhrgebiet zu sehen. Die meisten anderen kleineren Cluster sind ebenfalls im 67

68 Gebiet um größere Städte gelegen. Auch bei dem Deutschland-Datensatz ist im Verlauf des Algorithmus eine Bewegung der Punktverteilungen zu sehen. So sind bereits im Jahr 2008 nach hinzugefügten Punkten (Abbildung 5.11) beispielsweise keine Cluster mehr um die beiden größten Anfangsgebiete München und Hamburg zu sehen. Auch um Berlin und Stuttgart werden im Verlauf des Algorithmus nicht genügend neue Punkte hinzugefügt, um Cluster zu bilden. Stattdessen gibt es wie auch im vorigen Versuch eine große Anzahl von Clustern in den Gebieten zwischen den großen Städten, wie zum Beispiel zwischen Stuttgart und Frankfurt, oder zwischen Köln und Dortmund. Zusätzlich gibt es vier Cluster am südlichen Rand von Deutschland. Im Gegensatz zum vorigen Versuch ist die Wanderung der Cluster im Deutschland-Datensatz allerdings bereits nach einem Jahr zu erkennen. Laufzeit und Speicherbedarf Die Laufzeiten der Versuche mit dem Bayern- und Deutschland-Datensatz sind nahezu gleich. Das Hinzufügen der Punkte des Bayern-Datensatzes dauert 61 Minuten und 49 Sekunden. Dies entspricht einer Rate von ca Punkten pro Sekunde. Das Hinzufügen der Punkte des Deutschland-Datensatzes dauert 53 Minuten und 58 Sekunden, was einer Rate von ca Punkten pro Sekunde entspricht. Der Unterschied der Laufzeit beträgt somit nur 82 Punkte pro Sekunde. Dieser Unterschied lässt sich darauf zurückführen, dass der Zugriff auf die Daten des Deutschland-Datensatzes aufgrund der größeren Menge an Punkten geringfügig länger dauert, als der Zugriff auf den Bayern-Datensatz. Der Speicherbedarf beträgt in beiden Versuchen zu Beginn ca. 2,7 Megabyte für das Density Grid des D-Stream-Algorithmus. Dieser wächst während das Versuches bis auf ca. 3,7 Megabyte an. Dazu kommen die noch nicht hinzugefügten Punkte, die zwischengespeichert werden. Insgesamt ist der Speicherbedarf somit sehr gering und steigt auch über einen längeren Zeitraum nur langsam an. 68

69 Abbildung 5.10: Darstellung der Cluster in Deutschland im Jahr 2007 (100k Punkte) 69