Freitag, 19. Oktober 2001
This presentation is the property of its rightful owner.
Sponsored Links
1 / 19

Eine Pipelining-Algebra für die effiziente Anfragebearbeitung im KDD-Prozess PowerPoint PPT Presentation


  • 54 Views
  • Uploaded on
  • Presentation posted in: General

Freitag, 19. Oktober 2001. Eine Pipelining-Algebra für die effiziente Anfragebearbeitung im KDD-Prozess. Diplomarbeit von Michael Klein Betreuer: Dipl.-Inform. Matthias Gimbel. interaktive Benutzung des Systems trotz großer Rohdatenbestände spontaner Anfragen komplexer Operationen

Download Presentation

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

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Eine pipelining algebra f r die effiziente anfragebearbeitung im kdd prozess

Freitag, 19. Oktober 2001

Eine Pipelining-Algebrafür die effiziente Anfragebearbeitung im KDD-Prozess

Diplomarbeit von Michael Klein

Betreuer: Dipl.-Inform. Matthias Gimbel


Einleitung

  • interaktive Benutzung des Systems

  • trotz

  • großer Rohdatenbestände

  • spontaner Anfragen

  • komplexer Operationen

  • wenig Vorwissen über Daten

Knowledge Discovery in Databases

Wissensentdeckung in Datenbanken

  • Finden von neuen und nützlichen Mustern in Daten

  • mehrstufiger Prozess

Wissen

Vorverarbeitung

Data Mining

Nachbearbeitung

Einleitung

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

  • iterativer Prozess

Rohdaten


Probleme und l sungsans tze

Algebra

Probleme und Lösungsansätze

Ansatz zum Erreichen der Forderung: Parallelität

Standardvorgehensweise: Datenparallelität

Probleme

Lösungsansätze

  • Abhängigkeit von der Datenverteilung

  • Fehlende Ressourcenkontrolle

Pipelining

Datenqualität

Deshalb: Kontrollparallelität / Pipelining

  • Operatoren unterschiedlich komplex

  • Feingranulare Aufspaltung schwierig

  • Lose Kopplung zwischen DBMS und Analysesystem

  • Keine Interaktivität

Optimierer


Pipelining algebra 1

GROUP

JOIN

SAMPLE

NORMALIZE

Pipelining-Algebra (1)

Ziele und Beispieloperatoren

Ziele

  • Zerlegung von Anfragen in Form eines Operatorbaums in möglichst feingranulare Pipeline

  • Ausgeglichene Lastsituation

Überlegung

  • Verwendung unterschiedlicher Implementierungsvarianten für die Operatoren

  • Untersuchung auf Zerlegbarkeit

Beispieloperatoren

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

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


Pipelining algebra 2

collectBlockGroup

sortMergeJoin

countPickSample

countMinmaxNormalize

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

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).

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

Pipelining-Algebra (3)

Ergebnisse

  • Aufspaltung der Implementierungen möglich

1. Datenaufbereitungsschritt

2. Kontinuierlicher und ressourcenschonender Verarbeitungsschritt

  • Begrenzte Zahl von Aufbereitungsstufen

Nur Wertzusammenhang, Sortierung,

Bekanntheit von Anzahl, Minima, Maxima

  • Noch keine Kostengleichheit

Aufbereitungsschritt zeitaufwändig und oft ressourcenintensiv

Ziel: effizienter Datenbereitstellungsmechanismus mit

angebbarer Aufbereitungsstufe

  • Interaktivität durch Vermeidung der Aufbereitung

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


Datenqualit t 1

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 (1)

Definitionen

Datenqualität = Zustand der Aufbereitung eines Datenstroms.

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


Datenqualit t 2

verzögernder Ausgang

blockierender Ausgang

implementierungsName

hashGroup(A, f)

blockGroup(A, f)

noopGroup(A, f)

Datenqualität (2)

Datenqualitätsanforderungen und –transformationen

  • Für jede Implementierungsvariante erforderlich:

  • Mindestdatenqualität der Eingangsdatenströme

  • Datenqualitätstransformation

Notation:

Mindestdatenqualität

Ausgangsdatenqualität

Beispiel:GROUP

D(A) S(*) anz

W(A)

D(A) anz

D(A)


Datenqualit t 3

Hilbertkurve

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

  • Funktion: mehrdimensionaler Raum  lineare Folge von Adressen

  • Lokalitätseigenschaft


Datenqualit t 4

Datenqualität (4)

entstehende Datenqualität:

Pseudosortierung: PSk(A)

k = max. Anzahl der Wertkombinationen pro Block

Verwendung raumfüllender Kurven

12

13

14

1

5

9

10

11

4

2

6

7

8

3

1

3

4

5

4

3

2

1

2

Datenqualitäts-anforderungen

Abschwächung der Anforderungen

Bereichsanfragen

Lesen der Kurvenabschnitte von Platte, die im Anfragequader liegen

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

Verbreiterung der Streifen, so dass die Sortierung nur blockweise gegeben ist, nicht jedoch innerhalb eines Blocks.

 effizient

 ineffizient

 Effizienz einstellbar


Pseudodatenqualit t 1

PS(A)

S(A)

k-Sort(A)

PW(A)

W(A)

k-Collect(A)

Pseudodatenqualität (1)

Verwendung

  • Direkte Verwendung von Pseudodatenqualitäten nicht möglich

  • Bereitstellung spezieller Implementierungen zu deren Aufbereitung


Pseudodatenqualit t 2

SELECT Vorname, Nachname, AVG(Note) AS Schnitt

FROM Klausurergebnis

GROUP BY Vorname, Nachname

ORDER BY Nachname, Schnitt

PS([N,V])

PS([N,V])

index

k-Collect([N,V])

W([N,V])  W([V,N])

blockGroup([V,N], AVG)

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

PS([N,V])

k-Sort([N,V])

D([V,N])

D([V,N])

S([N,S])

blockSort([N,S])

out

D([V,N])

Pseudodatenqualität (2)

Beispiel

 PW([N,V])


Fazit

Fazit

Was 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 optimierer

1. Theoretische Optimierung

2. Praktische Optimierung

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

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

P

Interaktivitätsgerechter Optimierer

Grundziel: Interaktivität

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

Grundsätzliches Vorgehen in zwei unabhängigen Schritten:


Erweiterung datenparallelit t

index

PW(A)

hash-Split

PW(A)

tupel-Merge

D(A)

D(A)

A

A

A

[A1]

[A1]

[A1]

k-Collect

blockGroup

Erweiterung: 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

Splitqualität: VEREINT(A)

Tupel, die bezüglich A gleich sind, laufen durch den selben Teilfluss.

Mindest-DQ: W(A)

Mindest-SQ: VEREINT(A)

PW(A)

W(A)

D(A)

index

k-Collect

blockGroup

out


Messergebnisse 1

PS([O.OK])

S([O.OK])

SELECT *

FROM ORDERS O, LINEITEM L

WHERE O.OK = L.OK

ORDERS

k-Sort

merge-

Join

PS([L.OK])

S([L.OK])

LINEITEM

k-Sort

Zeit in s

700

600

500

Gesamtzeit

400

300

200

100

Startzeit

101

102

103

104

105

106

Blockgröße k

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)

  • Mit k wächst Startzeit

  • Startzeit viel geringer als Gesamtzeit

  • Wichtig für Gesamtzeit: ausgeglichene Pipeline


Messergebnisse 2

SELECT L.OK, SUM(L.PRICE), O.ORDERDATE, O.PRIORITY

FROM CUSTOMER C, ORDERS O, LINEITEM L

WHERE O.MKTSEGMENT = 'BUILDING'

AND O.ORDERDATE < 1995-03-15

AND L.SHIPDATE > 1995-03-15

AND C.CK = O.CK

AND L.OK = O.OK

AND O.OK > x

GROUP BY L.OK, O.ORDERDATE, O.PRIORITY

ORDERS

OD<95-03-15

PS([O.OK])

S([O.OK])

k-Sort

merge-

Join

S([O.OK])

PS([L.OK])

S([L.OK])

S([L.OK])

LINEITEM

SD>95-03-15

k-Sort

oneHash

Join

S([O.OK])

block

Sort

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

block

Group

CUSTOMERMS='BUILDING'

S([L.OK])

Messergebnisse (2)

Komplexe Anfragen: Vergleich mit Standardimplementierungen

Dritte Anfrage aus TPC-H:


Messergebnisse 3

Zeit

in s

360

300

240

180

120

60

0

1

2

3

4

5

5.5

5.9

x in Mio

Startzeit mit DQ

Gesamtzeit mit DQ

Startzeit = Gesamtzeit ohne DQ

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


Zusammenfassung ausblick

Pipelining-Ansatz

wenig Vorwissen

über Datenverteilung

Datenqualität

Pseudodatenqualität

komplexe

Einzeloperatoren

unausgeglichene

Pipelines

Algebra

komplexe

Anfragen

beschränkte

Ressourcen

hoher Parallelisierungsgrad,

lange Pipelineswünschenswert

sehr große

Datenmengen,

Skalierbarkeit

lose Kopplung zwischen

DBMS und Analysesystem

Erweiterungen

Interaktivitätsgerechte Optimierung

geringe Gesamtzeit

wünschenswert

riesiger

Optimierungsspielraum

raumfüllende Kurven

Ad-hoc-Anfragen,

keine ausgezeichneten

Attribute

aufwändige

Lernverfahren

Interaktivität nötig

geringe Startzeit

Zusammenfassung & Ausblick

Effiziente Anfragebearbeitung im KDD-Prozess


  • Login