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

1. Freitag, 19. Oktober 2001 Eine Pipelining-Algebrafür die effiziente Anfragebearbeitung im KDD-Prozess Diplomarbeit von Michael Klein Betreuer: Dipl.-Inform. Matthias Gimbel

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

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

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

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

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

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

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

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

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

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

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

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

14. 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:

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

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

17. 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:

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

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