Implementierung der SQL Operatoren GROUP BY und CUBE

Transkript

1 Implementierung der SQL Operatoren GROUP BY und CUBE Seminararbeit von Christian Brandt Seminar Advanced Data Warehousing WS 2003/2004 Einführung Ein zentrales Element von OLAP - Anwendungen ist die Aggregation und insbesondere bei multidimensionaler Datenanalyse die Aggregation über viele Mengen von Attributen. Ein Einzelhandelsgeschäft könnte zum Beispiel eine Tabelle 'Verkauf' haben, in der für jedes Datum, jeden Kunden und für jedes Produkt der Umsatz gespeichert ist. Mögliche Anfragen sind dann: Gib für jedes Produkt eine Aufschlüsselung der Verkäufe pro Monat! Wieviel Umsatz brachte jedes einzelne Produkt? Wie groß ist der Gesamtumsatz? oder all diese Informationen auf einmal... Eine Möglichkeit der mehrdimensionalen Aggregation ist der CUBE - Operator, auf dessen Implementation, wie in [Agarwal96] vorgeschlagen, hier näher eingegangen wird. Außerdem werden einführend zwei Ansätze zur Berechnung einfacher Aggregate mit GROUP BY nach [Lehner03] beschrieben. Begriffe Aggregate kombinieren eine Menge von Tupeln zu einem einzigen Wert. In Standard SQL gibt es die Aggregatfunktionen COUNT(), SUM(), MIN(), MAX() und AVG(), in IBM DB2 werden zusätzlich Funktionen für Standardabweichung und Varianz zur Verfügung gestellt. Man unterscheidet folgende Klassen von Aggregatfunktionen: Die distributiven Funktionen erlauben die Zerlegung der Eingabemenge in disjunkte Teile, die einzeln aggregiert und später kombiniert werden können. Das heißt es gibt eine Funktion G, die aus den Ergebnissen der Aggregatfunktion F über den einzelnen Teilen das Gesamtresultat berechnet. Beispiele sind MIN(), MAX(), COUNT() und SUM(). 1

2 Algebraische Aggregatfunktionen können mit Hilfe von einer festen Menge distributiver Funktionen ausgedrückt werden. Der Durchschnitt AVG() kann zum Beispiel mit Hilfe der zwei Funktionen COUNT() und SUM() berechnet werden. Bei holistischen Funktionen kann die Eingabemenge nicht zerlegt werden. Die Berechnung des MEDIAN() aus einer Menge distributiver Funktionen ist nicht möglich. Es werden hier lediglich distributive und algebraische Aggregatfunktionen betrachtet. In SQL dient der GROUP BY - Operator zur Aggregation. Die Tupel werden nach den Attributen in der GROUP BY - Klausel partitioniert und für jede Partition die Aggregatfunktion berechnet. Die Ergebnisrelation enthält für jede Gruppe genau eine Zeile. Dabei dürfen im SELECT - Statement nur Aggregatfunktionen, Konstanten und die in der GROUP BY - Klausel auftretenden Ausdrücke und Attribute vorkommen. Der CUBE - Operator ist "die n-dimensionale Verallgemeinerung des GROUP BY - Operators". Er berechnet die Gruppierung für jede mögliche Teilmenge der Attributliste. Das sind bei n Attributen 2 n Kombinationen. In SQL könnte eine CUBE - Anfrage so aussehen: select K, P, sum(umsatz) as Summe from Verkauf group by cube (K, P) Diese Anfrage ist semantisch äquivalent zu einer Vereinigung aus den GROUP BYs über den Attributmengen: KP, K, P und einer Aggregation über alle Tupel der Relation. Eine Partition nach einer Attributmenge ist die Aufteilung der Relation in Teilmengen, deren Tupel in diesen Attributen identische Werte haben. Realisierung des GROUP BY - Operators In einem naiven Ansatz zur Berechnung von Gruppierungen wird der Tupelstrom der inneren Query nach den Gruppierungsattributen partitioniert. Anschließend wird für jede Partition das Aggregat berechnet, das Ergebnis nach den Bedingungen der HAVING - Klausel selektiert und zuletzt nach der durch ORDER BY gegebenen Reihenfolge sortiert. Die offensichtlichen Speicher- und Laufzeitprobleme dieses Vorgehens werden von den zwei folgenden Implementierungsvarianten teilweise gelöst. Unter der Voraussetzung, daß genügend Hauptspeicher vorhanden ist, wird bei der hashbasierten Variante anfangs auf jede Zeile des Tupelstroms eine über den Gruppierungsattributen definierte Hashfunktion angewendet, sodaß Tupel mit gleichen Werten in den Gruppierungsattributen auch im gleichen Bereich der Hashtabelle liegen. Danach werden alle Einträge der Tabelle durchlaufen und die Werte aggregiert, wobei die Ergebnistupel direkt an den nächsten Operator weitergereicht werden können (Pipelining). Bei der sortierungsbasierten Variante wird in der ersten Phase der Datenstrom nach den Gruppierungsattributen (evtl. auf dem Sekundärspeicher) sortiert, das heißt Tupel der gleichen Gruppe folgen direkt aufeinander. In der zweiten Phase werden die sortierten Datensätze sequentiell gelesen und 2

3 aggregiert. Bei jedem Wechsel der Gruppe wird ein Ergebnistupel ausgegeben Im Normalfall läuft diese Variante nicht in zwei getrennten Phasen ab, sondern die Ergebnistupel der Sortierung werden direkt an die Gruppierung übergeben. Die sortierungsbasierte Variante ist, wahrscheinlich wegen des geringen Hauptspeicherbedarfs, die bevorzugte. Realisierung des CUBE - Operators Die naive Realisierung des CUBE - Operators berechnet alle durch die Definition gegebenen Gruppierungskombinationen isoliert auf dem eingehenden Datenstrom. Die 2 n Gruppierungen werden durch Vereinigung am Ende zu einem Ergebnis zusammengefasst. Auf diese Art wird der möglicherweise große Datenstrom sehr häufig gelesen und das kostet Zeit. Bei der Auswertung des CUBE kann die direkte Ableitbarkeit höherwertiger Aggregate aus niederwertigen ausgenutzt werden, sodaß nicht stets die Basisdaten beansprucht werden müssen, sondern bereits berechnete Gruppierungen verwendet werden. CUBE(A,B,C) CUBE(A,B,C) (A,B,C) (A,B) (A,C) (B,C) (A) (B) (C) () naiver Ansatz Mögliche Optimierungen UNION (A,B,C) (B,C) (A,C) (A,B) (B) (C) () (A) UNION Ausnutzen der direkten Ableitbarkeit Im Folgenden geht es um einige Heuristiken, die Optimierungen bei der Auswertung von mehreren ableitbaren GROUP BYs vornehmen. Smallest parent ist eine Optimierung deren Ziel es ist, ein GROUP BY aus dem vorhergehenden (niederwertigen) zu berechnen, welches die kleinste Kardinalität hat. Man spart dadurch Aggregierungskosten. Um die Kardinalität eines GROUP BY zu kalkulieren ist es notwendig, gute Abschätzungen über die Anzahl verschiedener Werte einer Spalte zu haben. Zum Beispiel kann AB aus ABC, ABD und ABCD berechnet werden. Natürlich wählt man hier nicht ABCD, aber auch zwischen ABC und ABD kann es deutliche Größenunterschiede geben. Cache results ist eine Optimierung, mit deren Hilfe Plattenzugriffe gespart werden sollen. Zu diesem Zweck wird das Ergebnis einer GROUP BY - Berechnung im Hauptspeicher gehalten, um daraus die höherwertigen Aggregate zu errechnen. Wurde ABC gerade berechnet, so kann AB daraus ermittelt werden, während ABC noch im Hauptspeicher ist, ohne zusätzliches Lesen vom Sekundärspeicher. 3

4 Amortize scans ist eine Optimierung, bei der ebenfalls versucht wird Plattenzugriffe zu sparen, indem während eines sequentiellen Scans so viele GROUP BYs wie möglich im Hauptspeicher berechnet werden. Befindet sich etwa des Ergebnis der Gruppierung ABCD auf Platte, so könnten ABC, ABD, ACD und BCD in einem Durchlauf daraus berechnet werden. Share sorts ist eine Optimierung speziell für sortierungsbasierte Methoden. Sie zielt darauf ab, eine vorhandene Sortierung auf den Attributen einer Relation oder einer vorhergehenden Gruppierung für die Berechnung mehrerer GROUP BYs zu verwenden, um Sortierungskosten zu sparen. Share partitions ist eine Optimierung speziell für hashbasierte Methoden. Reicht der Hauptspeicher für die Hashtabelle nicht aus, so werden die Daten partitioniert. Die Aggregation wird auf den Partitionen durchgeführt, die in den Speicher passen. Es werden hier mehrere Gruppierungen auf den vorhandenen Partitionen berechnet, um Partitionierungskosten zu sparen. Die angesprochenen Verfahren sind in der Praxis oft widersprüchlich. Normalerweise ist der Hauptspeicher wesentlich kleiner als die zu aggregierenden Daten. In diesem Fall können sich smallest parent und cache results widersprechen. Wählt man zum Errechnen den kleinsten Vorgänger, so muß dieser evtl. von Platte gelesen werden. Wählt man einen Vorgänger aus dem Cache, so ist der evtl. groß und die Aggregation aufwendig. Analog dazu verhalten sich smallest parent und share sorts, zwischen denen im folgenden Algorithmus ein Kompromiß gesucht wird. Algorithmus PipeSort Der Algorithmus erzeugt mit Hilfe vieler Abschätzungen einen Berechnungsplan für die Auswertung einer CUBE - Anfrage, bei dem es eine festgelegte Reihenfolge der Attribute gibt, nach der die Tupel sortiert sind. Die Sortierung wird dann zur Berechnung mehrerer GROUP BYs im Pipeline - Verfahren genutzt. Während der Berechnung einer Pipeline muß für jedes GROUP BY nur ein Tupel im Speicher gehalten werden. Als Eingabe erhält der Algorithmus einen gerichteten azyklischen Graphen. Eingabe: Aggregationsgitter Angenommen man hat für jedes GROUP BY die geschätzte Anzahl Ergebnistupel. Dann wird der Eingabegraph (Aggregationsgitter) wie folgt konstruiert. Ein Knoten entspricht einer durch den CUBE definierten Gruppierung (Attributmenge). Es gibt eine gerichtete Kante zwischen Knoten i und j, wenn j aus i ableitbar ist, das heißt wenn j genau ein Attribut weniger hat als i und sonst identisch ist. Der Knoten i heißt dann parent von j. Jede Kante ist mit A- und S- Kantengewichten versehen: S ij geschätzte Kosten um i zu sortieren, wenn es unsortiert in den Attributen von j vorliegt, wenn also Tupel einer Gruppe nicht direkt aufeinander folgen. S ij enthält auch die geschätzten Aggregationskosten. A ij geschätzte Kosten, wenn i sortiert in den Attributen von j vorliegt. Das sind nur die Kosten der Aggregation. 4

5 all A B C D AB AC AD BC BD CD ABC ABD ACD BCD Beispiel für ein Aggregationsgitter, all bezeichnet das leere GROUP BY Ausgabe: Berechnungsplan Die Ausgabe ist ein Subgraph des Aggregationsgitters, der den Berechnungsplan repräsentiert. Dieser hat folgende Eigenschaften: Jeder GROUP BY - Knoten ist mit einem einzelnen parent, aus dem er später berechnet wird, verbunden und hat eine festgelegte Sortierreihenfolge seiner Attribute. Eine Kante e ij hat nur noch ein Gewicht: A ij - Knoten j bestimmt die Reihenfolge der Attribute von i während der Berechnung. Die Sortierung wird bei der Aggregation genutzt. S ij - i muß erst sortiert werden, damit j daraus berechnet werden kann. Von einem Knoten i kann nur eine A - Kante ausgehen, denn es gibt ja nur ein Präfix, das genau ein Zeichen weniger hat. Ziel des Algorithmus ist es einen Subgraphen zu finden, dessen Kantensumme minimal ist. Einen solchen Subgraphen wird PipeSort nicht suchen, stattdessen wird eine Methode verwendet, die Ebene für Ebene vorgeht und lokal die Kantensumme minimiert. PipeSort ABCD PipeSort betrachtet das Aggregationsgitter Ebene für Ebene. Für jede Ebene k, wobei k die Anzahl Attribute in den Gruppierungen ist, sucht es den günstigsten Weg um alle Knoten darin aus k +1 zu berechnen. Das Problem wird auf das gewichtete Matching in bipartiten Graphen reduziert. Einschub: Was ist ein bipartites Matching minimalen Gewichtes? In einem bipartiten Graphen gibt es zwei disjunkte Knotenmengen, innerhalb derer keine Kanten verlaufen. Die Endknoten aller Kanten liegen in verschiedenen Partitionen. Ein Matching eines Graphen ist eine Teilmenge M der Kanten, sodaß keine zwei Kanten aus M einen gemeinsamen Knoten haben. Ein Matching maximalen Gewichtes ist ein Matching, sodaß die Summe der Gewichte aller Kanten aus M maximal wird. 5

6 Das Problem eines Matching minimalen Gewichtes läßt sich leicht darauf abbilden. Man ersetzt die Kantengewichte w(e) aller Kanten e durch max - w(e), wobei max das Gewicht der schwersten Kante ist. Für die Reduktion wird jeder Knoten der Ebene k+1 (parent Ebene) mit seinen Kanten zu Ebene k kopiert. Die Kanten der Originalknoten werden mit A - Kosten markiert, die Kanten der Kopien mit S - Kosten. Nach der Berechnung des Matchings sind alle Knoten j aus k mit genau einem Knoten i aus k+1 verbunden. Die Komplexität des verwendeten Matching Algorithmus ist O(n 3 ), wobei n die Knotenzahl ist. A B C A B C A B C AB AC BC Ebenen k und k+1 AB 2 AB AC AC BC BC Kopie der Elternknoten bezeichnet A - Kante bezeichnet S - Kante AB 2 AB AC AC BC nach dem Matching BC 20 Ergebnis Das Ergebnis des Algorithmus ist ein Spannbaum des Aggregationsgitters, aus dem sich mögliche Pipelines und notwendige Sortierungen direkt ablesen lassen. all A B C D BA AC AD CB DB CD CBA BAD ACD DBC CBAD Basisdaten Ein fertiger Berechnungsplan 6

7 all C B A D CB BA AC DB AD CD CBA BAD ACD DBC BAD ACD ACD CBAD CBAD CBAD CBAD Basisdaten Es werden also die Rohdaten nach den Attributen ABCD sortiert und aggregiert. Jedes Ergebnistupel der Aggregation wird für die Berechnung von CBA hochpropagiert, deren Ergebnisse an CB und so weiter. Für die weiteren Pipelines müssen bereits vorliegende GROUP BYs neu sortiert werden. Pseudocode Eingabe: Aggregationsgitter mit A- und S-Kantengewichten für Ebene k = 0 bis N-1 erzeuge Kopien jedes k+1 - Knotens markiere die Kanten der Originale mit den A- Kosten markiere die Kanten der Kopien mit den S- Kosten finde minimal gewichtetes Matching auf den modifizierten Ebenen für jedes GROUP BY in Ebene k+1 lege Attribut-Reihenfolge der Knoten fest, die mit A-Kanten verbunden sind Ausgabe: Graph mit verbliebenen A- und S- Kanten und festgelegter Reihenfolge der Attribute in den Elternknoten. Zusammenfassung Die hier gezeigte Methode PipeSort ist nur bedingt einsetzbar. Das Ziel einer guten Balance zwischen Sortier- und Aggregieraufwand ist gelungen, dabei wurden aber Betrachtungen zum Speicherbedarf und daraus resultierender Partitionierung der Daten völlig außer Acht gelassen. Die mittels Matching für jede Ebene gefundene Lösung ist nicht beweisbar optimal in Bezug auf die Gesamtkantensumme. Aber selbst wenn sie es wäre, ließe sich der fertige Berechnungsplan mit Blick auf den Speicherbedarf gewiß noch verbessern. Abgesehen davon sind die Gewichte natürlich nur Schätzungen. Algorithmus PipeHash Die auszuwertenden Pipelines Pipelinekante Sortierkante Der Algorithmus führt die Berechnung des CUBE in ausgewählten Teilbäumen des Aggregationsgitters durch, dabei werden vor allem die Optimierungen cache results und amortize scans betrachtet. Das heißt das Hauptaugenmerk liegt auf vorsichtiger Speicherallokation für mehrere Hashtabellen. Es werden für die Eingabe nur 7

8 Größenabschätzungen der Gruppierungen benötigt. Wenn der Hauptspeicher nicht beschränkt wäre, könnte man mit folgender Methode fast alle genannten Optimierungen nutzen: für Ebene k = N-1 bis 0 für jedes GROUP BY g in Ebene k+1 Berechne in einem Durchlauf alle GROUP BYs der Ebene k, für die g smallest parent ist speichere g auf Platte und gib Hauptspeicher frei Normalerweise sind die Datenmengen allerdings zu groß für den Hauptspeicher. Die Daten werden dann auf einem oder mehreren Attributen partitioniert, sodaß die Hashtabellen dafür in den Speicher passen. Die Entscheidung, welche GROUP BYs zusammen zu berechnen sind, wann Speicher zu allozieren und zu deallozieren ist und nach welchen Attributen zu große Relationen partitioniert werden sollen, um insgesamt eine minimale Laufzeit bzw. minimale Anzahl Lesevorgänge unter den gegebenen Speicherbeschränkungen zu erhalten, ist offensichtlich ein schwieriges, vermutlich NPvollständiges Problem. Die angegebene Methode nutzt Heuristiken, um sich der Lösung zu nähern. Ein- und Ausgabe Die Eingabe dieses Algorithmus ist das oben bereits erwähnte Aggregationsgitter, mit dem Unterschied, daß die Kanten jetzt mit der Kardinalität des GROUP BY, von dem sie ausgehen, als einzigem Gewicht markiert sind. Die Ausgabe ist die fertige Berechnung des CUBE. Dabei werden ausgehend von einem minimal spannenden Baum des Aggregationsgitters Teilbäume ausgewählt und einzeln ausgewertet. PipeHash PipeHash findet zuerst einen minimal spannenden Baum auf dem Aggregationsgitter. Um die Optimierung amortize scans zu nutzen wird ein großer Teilbaum ausgewählt, um anschließend die Aggregate vieler Kinderknoten zu berechnen. Die Daten müssen wahrscheinlich partitioniert werden. Die Attribute, nach denen partitioniert wird, beschränken den Teilbaum auf die Gruppierungen, in denen sie vorkommen. Daher werden die partitionierenden Attribute so gewählt, daß unter Beachtung des Speicherbedarfs, ein möglichst großer Teilbaum ausgewählt werden kann. Die Heuristik Select-subtree befasst sich mit dieser Aufgabe. Compute-subtree berechnet dann für die Partitionen alle Aggregate des Teilbaums. Pseudocode Eingabe: Aggregationsgitter mit Kardinalitäts-Kantengewichten Berechne minimal spannenden Baum des Gitters und trage ihn in eine Liste ein Solange die Liste nicht leer ist entnimm irgendeinen Baum T U = Select-subtree(T) Compute-subtree(U) 8

9 Select-subtree Der übergebene Baum sei T, die Attributmenge seiner Wurzel sei S und s S. T s bezeichne den Teilbaum von T, der alle GROUP BYs enthält in denen s vorkommt und P s die Anzahl Partitionen des Wurzelknotens nach s. Select-subtree wählt unter allen s S den größten Teilbaum T s, dessen benötigter Speicher geteilt durch P s den verfügbaren Speicher nicht überschreitet. Der Teilbaum wird entfernt. Es bleibt ein Wald kleinerer Bäume, sie werden zur Liste hinzugefügt. Wenn von T benötigter Speicher < verfügbarer Speicher gib T zurück S = Menge der Attribute in root(t), der Wurzel von T für alle s S schätze Ps = # Partitionen von root(t) wenn auf s partitioniert Wähle s S sodaß Speicherbedarf(Ts)/Ps < verfügbarer Speicher und Ts größtmöglich Entferne Ts aus T. Füge verbleibenden Wald zur Liste hinzu gib Ts zurück Compute-subtree Compute-subtree führt die oben erwähnte Methode auf dem gewählten Teilbaum für jede Partition des Wurzelknotens durch, dabei wird share partitions ausgenutzt. Partitioniere root(u) nach s für jede Partition von root(u) für jeden Knoten i aus U in Breitensuche - Reihenfolge berechne alle Kinderknoten von i in einem Durchlauf gib Speicher für die Hashtabelle von i frei all all A B C D A A B C D AB AC AD BC BD CD AB AC AD AB BC BD CD ABC ABD ACD BCD ABC ABD ACD ABC BCD ABCD ABCD ABCD Basisdaten Basisdaten ein minimal spannender Baum T{A} verbleibender Wald 9

10 Beispiel Angenommen der Baum passt nicht vollständig in den Hauptspeicher, dann müssen die Daten zum Beispiel auf A partitioniert werden (siehe Abbildung) Für jede Partition wird am Anfang die Gruppierung ABCD berechnet. Der dargestellte Teilbaum wird wie folgt abgearbeitet. Durchlaufe ABCD im Speicher, um ABC, ABD und ACD daraus zu berechnen. ABCD und ABD werden nicht weiter benötigt und können rausgeschrieben werden. Durchlaufe ACD, um AD zu erhalten, schreibe ACD und AD. Durchlaufe ABC, um AB und AC zu berechnen, schreibe ABC und AC. Durchlaufe AB, um A zu berechnen und schreibe endlich AB und A. Das wiederholt sich für jede Partition. Nachdem T {A} fertig berechnet ist, wird der nächste Baum aus der Liste entnommen. Zusammenfassung Die PipeHash Methode ist für Speicherbeschränkungen optimiert. Sie leidet ebenso wie PipeSort unter vielen Abschätzungen, zum Beispiel bei der Kardinalität der Gruppierungen, den Partitionsgrößen und der Anzahl der Partitionen. Es kann deshalb nicht garantiert werden, daß jede Partition bzw. jeder Teilbaum in den Speicher paßt. Die angestrebten Optimierungen cache results, amortize scans und share partitions sind, vorausgesetzt die Schätzungen stimmen, gut umgesetzt. Allerdings wurde hier nicht auf Sortierungen und Größe der Elternknoten eingegangen. Da die Partitionen, über denen aggregiert wird, im Hauptspeicher vorliegen, sind die Sortierungs- und Aggregationskosten gering im Vergleich mit den entsprechenden Sekundärspeicheroperationen. Schluß Ein Vergleich der Methoden auf synthetischen Datenmengen zeigte, daß die PipeHash Methode auf dichten Werteverteilungen und PipeSort auf dünn besetzten Werteverteilungen im Vorteil ist. Beide Algorithmen sind schneller als entsprechende naive sortierungs- und hashbasierte Methoden. Nachträglich ist noch zu erwähnen, daß mir die Darstellung des PipeHash Algorithmus in [Agarwal96] unverständlich war und hier eine vereinfachte Variante beschrieben wird. Als Alternative zu den genannten Verfahren gibt es noch die Overlap - Methode aus dem selben Papier, die auch partielle Sortierreihenfolgen ausnutzt. Sie wurde aus Zeitgründen im Referat nicht behandelt. 10

11 Quellen [Agarwal96] [Lehner03] Agarwal, S., Agrawal, R., Deshpande, P., Gupta, A., Naughton, J. F., Ramakrishnan, R. and Sarawagi, S. (1996). "On the Computation of Multidimensional Aggregates". 22nd Conference on Very Large Data Bases, Bombay, India. Lehner, W. (2003). "Datenbanktechnologie für Data-Warehouse- Systeme", dpunkt.verlag. (Kap. 8.3) 11