ppt
Werbung
Michael Klein, 19. Oktober 2001 Freitag, 19. Oktober 2001 Eine Pipelining-Algebra für die effiziente Anfragebearbeitung im KDD-Prozess Diplomarbeit von Michael Klein Betreuer: Dipl.-Inform. Matthias Gimbel Michael Klein, 19. Oktober 2001 Einleitung Eine Pipelining-Algebra für die effiziente Anfragebearbeitung im KDD-Prozess 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 • iterativer Prozess Rohdaten Vorverarbeitung Data Mining Nachbearbeitung Wissen Michael Klein, 19. Oktober 2001 Probleme und Lösungsansätze Ansatz zum Erreichen der Forderung: Parallelität Standardvorgehensweise: Datenparallelität Probleme 1. 2. Abhängigkeit von der Datenverteilung Fehlende Ressourcenkontrolle Lösungsansätze Pipelining Datenqualität Deshalb: Kontrollparallelität / Pipelining 3. 4. 5. 6. Operatoren unterschiedlich komplex Feingranulare Aufspaltung schwierig Lose Kopplung zwischen DBMS und Analysesystem Keine Interaktivität Algebra Optimierer Pipelining-Algebra (1) Michael Klein, 19. Oktober 2001 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 GROUP Berechnet f auf Gruppen mit gleichem Wert unter [A1...An] JOIN Verbindet zwei Datenströme anhand [A1...An] und [B1...Bn] SAMPLE NORMALIZE 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) Michael Klein, 19. Oktober 2001 Zerlegung der Operatorimplementierungen collectBlockGroup sortMergeJoin 1. [collect] Sammle Tupel mit gleichem Wert in [A1...An] in einer Hashtabelle und gebe diese hintereinander aus 1a. [sort] Sortiere erste Relation nach [A1...An] 1b. [sort] Sortiere zweite Relation nach [B1...Bn] 2. [block] Wende auf jeden wertzusammenhängenden Block f an 2. [merge] Verbinde die beiden Relationen reißverschlussartig countPickSample countMinmaxNormalize 1. [count] Bestimme die Anzahl M der Tupel im Fluss 1. [count] Bestimme min(Ai) und max(Ai) 2. [pick] Leite jedes k-te Tupel durch (k = M/g). 2. [minmax] Passe das Attribut Ai tupelweise proportional zu [min(Ai),max(Ai)] in das neue Intervall [a,b] ein Pipelining-Algebra (3) Michael Klein, 19. Oktober 2001 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) Michael Klein, 19. Oktober 2001 Definitionen Datenqualität = Zustand der Aufbereitung eines Datenstroms. A = [A1,...,An] bezeichnet eine Folge von Attributen Sortierung Ein Datenstrom D hat die Datenqualität S+(A) gdw. die Tupel lexikographisch aufsteigend nach A sortiert sind. Wertzusammenhang Ein Datenstrom D hat die Datenqualität W(A) gdw. die bzgl. A gleichen Tupel im Fluss aufeinander folgen. Wertverschiedenheit Ein Datenstrom D hat die Datenqualität D(A) gdw. sich keine zwei Tupel bzgl. A gleichen. Wertkenntnis 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. Michael Klein, 19. Oktober 2001 Datenqualität (2) Datenqualitätsanforderungen und –transformationen Für jede Implementierungsvariante erforderlich: • Mindestdatenqualität der Eingangsdatenströme • Datenqualitätstransformation blockierender Ausgang verzögernder Ausgang Notation: Mindestdatenqualität implementierungsName Ausgangsdatenqualität Beispiel: GROUP hashGroup(A, f) W(A) D(A) blockGroup(A, f) noopGroup(A, f) D(A) S(*) anz D(A) anz Datenqualität (3) Michael Klein, 19. Oktober 2001 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 Hilbertkurve Michael Klein, 19. Oktober 2001 entstehende Datenqualität: Pseudosortierung: PSk(A) k = max. Anzahl der Wertkombinationen pro Block Datenqualität (4) Verwendung raumfüllender Kurven 12 1 9 2 4 13 10 6 3 3 14 5 4 11 3 7 8 4 5 1 2 1 2 Datenqualitätsanforderungen Abschwächung der Anforderungen 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 Bereichsanfragen Pseudodatenqualität (1) Michael Klein, 19. Oktober 2001 Verwendung • Direkte Verwendung von Pseudodatenqualitäten nicht möglich • Bereitstellung spezieller Implementierungen zu deren Aufbereitung PS(A) PW(A) k-Sort(A) k-Collect(A) S(A) W(A) Pseudodatenqualität (2) Michael Klein, 19. Oktober 2001 Beispiel SELECT Vorname, Nachname, AVG(Note) AS Schnitt FROM Klausurergebnis GROUP BY Vorname, Nachname ORDER BY Nachname, Schnitt index PS([N,V]) PW([N,V]) k-Collect([N,V]) PS([N,V]) W([N,V]) W([V,N]) blockGroup([V,N], AVG) S([N,V]) S([N]) D([V,N]) blockSort([N,S]) k-Sort([N,V]) S([N,S]) D([V,N]) PS([N,V]) D([V,N]) out Fazit Michael Klein, 19. Oktober 2001 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 Michael Klein, 19. Oktober 2001 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: 1. Theoretische Optimierung Ziel: Finden des Ausführungsplans P, der theoretisch die beste Start- und Gesamtzeit bietet 2. Praktische Optimierung P Ziel: Optimale Verteilung der Einzelschritte von P auf real vorhandene Recheneinheiten Michael Klein, 19. Oktober 2001 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, Mindest-DQ: W(A) laufen durch den selben Teilfluss. Mindest-SQ: VEREINT(A) index PW(A) hashPW(A) index Split PW(A) W(A) k-Collect blockGroup A [A1] A [A1] A [A1] k-Collect D(A) blockGroup D(A) tupelMerge D(A) out Michael Klein, 19. Oktober 2001 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 L WHERE O.OK = L.OK ORDERS PS([O.OK]) LINEITEM PS([L.OK]) k-Sort k-Sort Zeit in s S([O.OK]) S([L.OK]) mergeJoin • Mit k wächst Startzeit 700 • Startzeit viel geringer als Gesamtzeit 600 500 Gesamtzeit 400 • Wichtig für Gesamtzeit: ausgeglichene Pipeline 300 200 100 Startzeit 101 102 103 104 105 106 Blockgröße k Michael Klein, 19. Oktober 2001 Messergebnisse (2) Komplexe Anfragen: Vergleich mit Standardimplementierungen Dritte Anfrage aus TPC-H: 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 LINEITEM PS([O.OK]) PS([L.OK]) k-Sort k-Sort S([O.OK]) S([L.OK]) mergeJoin S([O.OK]) S([L.OK]) block Sort S([O.OK]) S([L.OK]) SD>95-03-15 CUSTOMER MS='BUILDING' oneHash Join S([L.OK,O.OD,O.SP]) block Group Michael Klein, 19. Oktober 2001 Messergebnisse (3) Komplexe Anfragen: Vergleich mit Standardimplementierungen Zeit in s • Startzeit bei Ausführungsplan mit DQ immer niedriger 360 • Gesamtzeit bei Ausführungsplan mit DQ kleiner für x unter 2 Mio. 300 • Größere Relationen nur mit DQ 240 180 120 60 0 1 Startzeit mit DQ 2 3 4 Gesamtzeit mit DQ 5 5.5 5.9 x in Mio Startzeit = Gesamtzeit ohne DQ Michael Klein, 19. Oktober 2001 Zusammenfassung & Ausblick Pipelining-Ansatz wenig Vorwissen über Datenverteilung Effiziente Anfragebearbeitung im KDD-Prozess Datenqualität komplexe Einzeloperatoren Algebra hoher Parallelisierungsgrad, lange Pipelines wünschenswert lose Kopplung zwischen DBMS und Analysesystem raumfüllende Kurven Ad-hoc-Anfragen, keine ausgezeichneten Attribute sehr große Datenmengen, Skalierbarkeit komplexe Anfragen Interaktivitätsgerechte Optimierung riesiger Optimierungsspielraum Interaktivität nötig geringe Startzeit Pseudodatenqualität unausgeglichene Pipelines beschränkte Ressourcen Erweiterungen geringe Gesamtzeit wünschenswert aufwändige Lernverfahren
