Michael Klein, 19. Oktober 2001 Eine Pipelining-Algebra für die effiziente Anfragebearbeitung im KDD-Prozess Diplomarbeit von Michael Klein Betreuer:

Michael Klein, 19. Oktober 2001

Eine Pipelining-Algebrafür die effiziente

Anfragebearbeitung im KDD-Prozess

Diplomarbeit von Michael Klein

Betreuer: Dipl.-Inform. Matthias Gimbel

Freitag, 19. Oktober 2001


EinleitungEine Pipelining-Algebra für die effiziente Anfragebearbeitung im KDD-Prozess

Vorverarbeitung Data Mining NachbearbeitungRohdaten Wissen

• iterativer Prozess

Knowledge Discovery in DatabasesWissensentdeckung in Datenbanken• Finden von neuen und

nützlichen Mustern in Daten

• mehrstufiger Prozess

interaktive Benutzung des Systemstrotz• großer Rohdatenbestände• spontaner Anfragen• komplexer Operationen• wenig Vorwissen über Daten

Michael Klein, 19. Oktober 2001Probleme und Lösungsansätze

Ansatz zum Erreichen der Forderung: Parallelität

Standardvorgehensweise: Datenparallelität

Probleme

1. Abhängigkeit von der Datenverteilung2. Fehlende Ressourcenkontrolle

Deshalb: Kontrollparallelität / Pipelining

3. Operatoren unterschiedlich komplex4. Feingranulare Aufspaltung schwierig5. Lose Kopplung zwischen DBMS und

Analysesystem6. Keine Interaktivität

Lösungsansätze

PipeliningDatenqualität

Optimierer

Algebra


Pipelining-Algebra (1)

Ziele• Zerlegung von Anfragen in Form eines

Operatorbaums in möglichst feingranulare Pipeline

• Ausgeglichene Lastsituation

Beispieloperatoren

GROUP

Berechnet f auf Gruppen mit gleichem Wert unter [A1...An]

JOIN SAMPLE NORMALIZE

Verbindet zwei Datenströme anhand [A1...An] und [B1...Bn]

Wählt eine zufällige Stichprobe der Größe g aus

Passt die Werte von Attribut Ai in das Interval [a,b] ein

Ziele und Beispieloperatoren

Überlegung• Verwendung unterschiedlicher

Implementierungsvarianten für die Operatoren

• Untersuchung auf Zerlegbarkeit


countPickSample

collectBlockGroup

Pipelining-Algebra (2)Zerlegung der Operatorimplementierungen

1. [collect] Sammle Tupel mit gleichem Wert in [A1...An] in einer Hashtabelle und gebe diese hintereinander aus

2. [block] Wende auf jeden wertzusammenhängenden Block f an

sortMergeJoin

1a. [sort] Sortiere erste Relation nach [A1...An]1b. [sort] Sortiere zweite Relation nach [B1...Bn]

2. [merge] Verbinde die beiden Relationen reißverschlussartig

1. [count] Bestimme die Anzahl M der Tupel im Fluss

2. [pick] Leite jedes k-te Tupel durch (k = M/g).

countMinmaxNormalize

1. [count] Bestimme min(Ai) und max(Ai)

2. [minmax] Passe das Attribut Ai tupelweise proportional zu [min(Ai),max(Ai)] in das neue Intervall [a,b] ein


Pipelining-Algebra (3)Ergebnisse

• Aufspaltung der Implementierungen möglich

• Begrenzte Zahl von Aufbereitungsstufen

• Noch keine Kostengleichheit

• Interaktivität durch Vermeidung der Aufbereitung

1. Datenaufbereitungsschritt2. Kontinuierlicher und ressourcenschonender Verarbeitungsschritt

Nur Wertzusammenhang, Sortierung, Bekanntheit von Anzahl, Minima, Maxima

Aufbereitungsschritt zeitaufwändig und oft ressourcenintensivZiel: effizienter Datenbereitstellungsmechanismus mit angebbarer Aufbereitungsstufe

Verzicht auf blockierende Aufbereitung durch genaue Buchführung und geschicktes gemeinsames Ausnutzen


Datenqualität (1)Definitionen

Datenqualität = Zustand der Aufbereitung eines Datenstroms.

A = [A1,...,An] bezeichnet eine Folge von Attributen

Ein Datenstrom D hat die Datenqualität S+(A)gdw. die Tupel lexikographisch aufsteigend nach A sortiert sind.

Sortierung

Ein Datenstrom D hat die Datenqualität W(A)gdw. die bzgl. A gleichen Tupel im Fluss aufeinander folgen.

Wertzusammenhang

Ein Datenstrom D hat die Datenqualität D(A)gdw. sich keine zwei Tupel bzgl. A gleichen.Wertverschiedenheit

Ein Datenstrom D hat die Datenqualität anz / min(A) / max(A)gdw. die Anzahl / das Minimum bzgl. A / das Maximum bzgl. A mit Ankunft des ersten Tupels bekannt ist.

Wertkenntnis


Datenqualität (2)Datenqualitätsanforderungen und –transformationen

Für jede Implementierungsvariante erforderlich:• Mindestdatenqualität der Eingangsdatenströme• Datenqualitätstransformation

Beispiel: GROUP

Notation:

implementierungsNameMindestdatenqualität Ausgangsdatenqualität

blockierender Ausgang

verzögernder Ausgang

hashGroup(A, f)D(A) S(*) anz

blockGroup(A, f)D(A) anzW(A)

noopGroup(A, f)D(A)


Datenqualität (3)Bereitstellung der Datenqualität

gesucht: Zugriffsmethode, • die Bereichs- und Wertanfragen unterstützt • die Daten effizient in Strom gewünschter Qualität anbietet

nicht geeignet: physische Clusterung

hier: Index auf Basis raumfüllender Kurven

• Lokalitätseigenschaft

• Funktion: mehrdimensionaler Raum lineare Folge von Adressen

Hilbertkurve


Datenqualität (4)Verwendung raumfüllender Kurven

BereichsanfragenLesen der Kurvenabschnitte von Platte, die im Anfragequader liegen

2

34

1

Datenqualitäts-anforderungen

Durch Zerlegung des Anfragequaders in schmale Streifen, die nacheinander gelesen werden

1 2

3 4 5

6 7 8

9 10 11

12 13 14

Abschwächung der AnforderungenVerbreiterung der Streifen, so dass die Sortierung nur blockweise gegeben ist, nicht jedoch innerhalb eines Blocks.

1

2

3

4 5

effizient ineffizient Effizienz einstellbar

entstehende Datenqualität:

Pseudosortierung: PSk(A)k = max. Anzahl der

Wertkombinationen pro Block


Pseudodatenqualität (1)Verwendung

• Direkte Verwendung von Pseudodatenqualitäten nicht möglich• Bereitstellung spezieller Implementierungen zu deren Aufbereitung

k-Collect(A)W(A)PW(A)

k-Sort(A)S(A)PS(A)


Pseudodatenqualität (2)Beispiel

SELECT Vorname, Nachname, AVG(Note) AS SchnittFROM KlausurergebnisGROUP BY Vorname, NachnameORDER BY Nachname, Schnitt

PW([N,V])PS([N,V])W([N,V]) W([V,N])indexindex

PS([N,V])k-Collect([N,V])k-Collect([N,V])

D([V,N])S([N,S])

blockSort([N,S])blockSort([N,S]) outout

S([N,V]) S([N])D([V,N]) k-Sort([N,V])k-Sort([N,V])

blockGroup([V,N], AVG)blockGroup([V,N], AVG)

D([V,N])PS([N,V])


FazitWas wurde erreicht?

• Hoher Paralellisierungsgrad durch vielstufige Pipeline

• Ausgeglichene Einzelschritte innerhalb der Pipeline durch Anpassung der Blöckgröße k

• Interaktive Abarbeitung aufgrund nicht-blockierender Implementierungen ( geringe Startzeit)

• Kontrollierbarer Ressourcenverbrauch über Blockgröße k

• Beliebig große Datenmengen aufgrund ressourcenschonender Implementierungen möglich

• Effiziente Bearbeitung auch von komplexen Anfragen durch genaue Buchführung und Mehrfachverwendung von Datenqualitäten möglich

• Unabhängigkeit von statischer Datenverteilung: Ad-hoc-Anfragen mit beliebigen Attributkombinationen durch Index basierend auf raumfüllenden Kurven möglich.

Aber: riesiger Optimierungsspielraum


Interaktivitätsgerechter OptimiererGrundziel: Interaktivität

Also: Ausführung der Anfrage mit möglichst geringer Start- und Gesamtzeit

Grundsätzliches Vorgehen in zwei unabhängigen Schritten:

1. Theoretische Optimierung

Ziel: Finden des Ausführungsplans P, der theoretisch die beste Start- und Gesamtzeit bietet

2. Praktische Optimierung

Ziel: Optimale Verteilung der Einzelschritte von P auf real vorhandene Recheneinheiten

P

Michael Klein, 19. Oktober 2001Erweiterung: Datenparallelität

Ziel: Datenparallele Ausführung ganzer Pipelineabschnitte zur Erhöhung des Parallelitätsgrads

Vorgehen: Einführung von zwei Spezialoperatoren zum Aufsplitten und Vereinen von Datenströmen

k-Collectk-Collectindexindex blockGroupblockGroup outoutW(A) D(A)PW(A)PW(A)

hash-Split

hash-Split

PW(A)tupel-Merge

tupel-Merge

D(A)D(A)

k-Collectk-Collect blockGroupblockGroup

A AA

Splitqualität: VEREINT(A)Tupel, die bezüglich A gleich

sind, laufen durch den selben Teilfluss.

Mindest-DQ: W(A)Mindest-SQ: VEREINT(A)

indexindex[A1]

[A1]

[A1]


Messergebnisse (1)Start- und Gesamtzeit in Abhängigkeit von k

Grundlage: TPC-H-Test für entscheidungsunterstützende Systeme

Drei Relationen: CUSTOMER (140 MB), ORDERS (600 MB), LINEITEM (1,4 GB)

SELECT *FROM ORDERS O, LINEITEM LWHERE O.OK = L.OK

ORDERSORDERS k-Sortk-Sort

k-Sortk-SortLINEITEMLINEITEM

merge-Join

merge-Join

PS([O.OK])

PS([L.OK])

S([O.OK])

S([L.OK])

Blockgröße k101 102 103 104 105 106

100

200

300

400

500

600

700

Zeit in s

Startzeit

Gesamtzeit

• Mit k wächst Startzeit

• Startzeit viel geringer als Gesamtzeit

• Wichtig für

Gesamtzeit: ausgeglichene Pipeline


Messergebnisse (2)Komplexe Anfragen: Vergleich mit Standardimplementierungen

SELECT L.OK, SUM(L.PRICE), O.ORDERDATE, O.PRIORITYFROM CUSTOMER C, ORDERS O, LINEITEM LWHERE O.MKTSEGMENT = 'BUILDING'AND O.ORDERDATE < 1995-03-15AND L.SHIPDATE > 1995-03-15AND C.CK = O.CKAND L.OK = O.OKAND O.OK > xGROUP BY L.OK, O.ORDERDATE, O.PRIORITY

Dritte Anfrage aus TPC-H:

ORDERSOD<95-03-15

ORDERSOD<95-03-15 k-Sortk-Sort

k-Sortk-SortLINEITEMSD>95-03-15

LINEITEMSD>95-03-15

merge-Join

merge-Join

PS([O.OK])

PS([L.OK])

S([O.OK])

S([L.OK])

CUSTOMERMS='BUILDING'

CUSTOMERMS='BUILDING'

oneHashJoin

oneHashJoin

blockSort

blockSort

S([O.OK])

S([L.OK])

S([O.OK])

S([L.OK])

blockGroup

blockGroup

S([L.OK,O.OD,O.SP])


Messergebnisse (3)Komplexe Anfragen: Vergleich mit Standardimplementierungen

• Startzeit bei Ausführungsplan mit DQ immer niedriger

• Gesamtzeit bei Ausführungsplan mit DQ kleiner für x unter 2 Mio.

• Größere Relationen nur mit DQ

Zeitin s

x in Mio0 1 2 3 4 5 5.5 5.9

60

120

180

240

300

360

Startzeit mit DQ Gesamtzeit mit DQ Startzeit = Gesamtzeit ohne DQ


ErweiterungenInteraktivitätsgerech

te Optimierung

raumfüllende Kurven

PseudodatenqualitätDatenqualität

Pipelining-Ansatz

Algebra

Zusammenfassung & Ausblick

Effiziente Anfragebearbeitung im KDD-Prozess

sehr großeDatenmengen,Skalierbarkeit

beschränkteRessourcen

Interaktivität nötiggeringe Startzeit

Ad-hoc-Anfragen,keine ausgezeichneten

Attribute

komplexeAnfragen

komplexe Einzeloperatoren

aufwändigeLernverfahren

geringe Gesamtzeitwünschenswertriesiger

Optimierungsspielraum

wenig Vorwissenüber Datenverteilung

hoher Parallelisierungsgrad,lange Pipelineswünschenswert

lose Kopplung zwischenDBMS und Analysesystem

unausgeglichenePipelines

Michael Klein, 19. Oktober 2001 Eine Pipelining-Algebra für die effiziente Anfragebearbeitung im KDD-Prozess Diplomarbeit von Michael Klein Betreuer:

Documents