Efficient Join Processing in Streaming Data Im Rahmen des Seminars Support For Non-standard Datatypes in DBMS Tina Scherer

Efficient Join Processing in Streaming Data 2 Gliederung Motivation Besonderheiten von Streaming Daten Hash Joins –Simple Hash Join –Pipeline Hash Join XJoin –Memory-Overflow (3 Phasen) –Duplikate

Efficient Join Processing in Streaming Data 3 MJoin –Schwankende Eingaberate –Window Join Zusammenfassung Referenz

Efficient Join Processing in Streaming Data 4 Motivation Streaming Data: Multimedia Daten, Messdaten von Maschinen... Beispiel Atomkraftwerk: Temperatur der Brennstäbe, Temperatur des Kühlwassers... Oft nicht alle Daten interessant, sondern nur in Zusammenhang mit anderen Daten (Beispiel: wenn Brennstäbe heiß & Kühlwasser heiß -> Alarm!) => Join notwendig

Efficient Join Processing in Streaming Data 5 Besondere Merkmale von Streaming Daten Meist unendlich viele Daten (nicht-abreißender Datenstrom) schwankende Eingaberate (Daten stehen nicht auf Abruf bereit, sondern erscheinen einfach => Wartezeiten) Ergebnisse sollen so schnell wie möglich verfügbar sein Mehrer Streams sollen gleichzeitig bearbeitet werden können Jedes Tupel von jedem Stream soll zu jeder Zeit akzeptiert werden können

Efficient Join Processing in Streaming Data 6 Hash Joins Wir betrachten zuerst Hash-Joins, da es sich gezeigt hat, dass diese für Equi-Joins am besten geeignet sind Die bekannten Hash-Joins (Grace Hash-Join, Simple Hash-Join & Hybrid Hash-Join) sind alle festplatten- basiert und unterscheiden sich nur durch die Art, wie sie die Platte benutzen, deshalb betrachten wir nur den Simple Hash Join

Efficient Join Processing in Streaming Data 7 Simple Hash Join 1. Phase: ein kompletter Operand (der kleinste) wird in die Hash-Tabelle des Speichers gelesen 2. Phase: die Tupel des 2. Operanden werde der Reihe nach gelesen, jedes Tupel wird gehasht und mit den entsprechenden Tupeln des 1. Operanden (dem in der Hash-Tabelle) kombiniert Das Ergebnis wird nur in der 2. Phase gebildet asymmetrisch in Operanden Tupel A55 Tupel A54 Tupel A Tupel A3 Tupel A2 Tupel A1 Tupel B1

Efficient Join Processing in Streaming Data 8 Pipeline Hash Join Ziel: Ergebnisse so schnell wie möglich Hash-Tabelle für beide Operanden Joinprozess hat nur 1 Phase: Eingehende Tupel werden gehasht und dann mit dem Teil der Hash-Tabelle (der bereits aufgebaut wurde) des anderen Operanden verglichen Tupel A10 Tupel A9 Tupel A8 Tupel A7 Tupel A6 Tupel A5 Tupel A4 Tupel A3 Tupel A2 Tupel A1 Tupel B9 Tupel B8 Tupel B7 Tupel B6 Tupel B5 Tupel B4 Tupel B3 Tupel B2 Tupel B1 Tupel A11 einfügen Überprüfen auf Matches

Efficient Join Processing in Streaming Data 9 Pipeline Hash Join Wenn ein Match gefunden wurde, wird das Ergebnis ausgegeben Dann wird das Tupel in die Hash-Tabelle seines Operanden eingefügt Wenn von einem Operanden das letzte Tupel eingelesen wurde, wird der Aufbau der Hash-Tabelle des anderen Operanden gestoppt. Degeneriert zum Simple Hash Join, wenn ein Operand komplett im Speicher Symmetrisch

Efficient Join Processing in Streaming Data 10 Vom Hash Join zum XJoin Problem: da alles in den Hauptspeicher gelesen wird läuft dieser besonders bei (meist unendlichlangen) Streams über (Memory-Overflow) Lösung: XJoin, basiert auf symmetrischem Hash Join (Pipeline), beinhaltet unter anderem Speicherüberlauf- Behandlung Aufteilen der Tupel auf –Speicheranteil (alle neu-angekommenen Tupel) –Festplattenanteil (Rest der Tupel)

Efficient Join Processing in Streaming Data 11 Basis Algorithmus Erstelle Hash-Tabelle für jeden Operanden Füge ankommendes Tupel in entsprechende Hash-Tabelle ein Untersuche auf Matches mit Tupels aus der anderen Hash-Tabelle Quelle A Quelle B Tupel A3 Tupel A2 Tupel A1 Tupel B3 Tupel B2 Tupel B1 Tupel A3 Tupel A2 Tupel A1 Tupel B3 Tupel B2 Tupel B1 Tupel A3 Tupel A2 Tupel A1 Tupel B3 Tupel B2 Tupel B1

Efficient Join Processing in Streaming Data 12 Memory-Overflow Problem: da wir keinen unbegrenzten Hauptspeicher haben kann es zu einem Speicherüberlauf (Memory- Overflow) kommen Lösung: ältere Tupel werden auf die Festplatte geschoben Somit gliedert sich der XJoin in 3 Phasen

Efficient Join Processing in Streaming Data 13 Die 3 Phasen 1. Phase: neue Tupel werden eingefügt und auf Matches untersucht 2. Phase: Tupel von der Festplatte werden auf Matches mit Tupeln aus dem Speicher untersucht 3. Phase: (Clean-up) Erzeugt alle Ergebnisse, die von der 1. und 2. Phase nicht berechnet wurden.

Efficient Join Processing in Streaming Data Phase (Memory-to-Memory) Ankommendes Tupel wird bei vorhandenem Platz im Speicher in seine Hash-Tabelle eingefügt Neues Tupel und Tupel des anderen Eingabestroms, die sich im Hauptspeicher befinden werden auf Matches untersucht Matches werden als Ergebnis ausgegeben Quelle A Quelle B Tupel A3 Tupel A2 Tupel A1 Tupel B3 Tupel B2 Tupel B1 Tupel A3 Tupel A2 Tupel A1 Tupel B3 Tupel B2 Tupel B1 Tupel A3 Tupel A2 Tupel A1 Tupel B3 Tupel B2 Tupel B1 Speicher Festplatte

Efficient Join Processing in Streaming Data 15 Phase Falls kein Platz im Hauptspeicher: ein Speicherteil wird auf die Festplatte geschoben Wenn 1. Phase blockt (aufgrund Mangelnden Datenstroms) beginnt 2. Phase Ist beendet, wenn keine weiteren Daten mehr ankommen Quelle A Quelle B Tupel A4 Tupel A3 Tupel A2 Tupel A1 Tupel B3 Tupel B2 Tupel B1 Tupel A4 Tupel B3 Tupel B2 Tupel B1 Speicher Festplatte Tupel A3 Tupel A2 Tupel A1

Efficient Join Processing in Streaming Data 16 2.Phase (Disk-to-Memory) Beginnt, wenn 1. Phase blockt (z.B. bei Eingabemangel) Nimmt Menge Tupel von der Festplatte und untersucht sie auf Matches mit den Tupel, die im Speicher liegen. Ergebnisse werden ausgegeben Tupel A15 Tupel A14 Tupel A13 Tupel B10 Tupel B9 Tupel B8 Tupel A12 Tupel A11 Tupel A 10 Tupel A Speicher Tupel B7 Tupel B6 Tupel B5 Tupel B Danach wird geprüft, ob zur 1. Phase zurückgekehrt werden kann Wenn nicht, wird die nächste Menge untersucht

Efficient Join Processing in Streaming Data Phase (Disk-toDisk) Beginnt, wenn Phase 1 und 2 abgeschlossen sind (Wenn keine neuen Tupel mehr hereinkommen) Stellt sicher, dass alle Ergebnisse gefunden werden Phase 3 Joint alle Partitionen Warum reichen 1. und 2. Phase nicht dazu aus? –1. Phase: nur Tupel, die zur gleichen Zeit im Speicher sind können gejoint werden –2. Phase: joint nur Tupel, wenn eines im Speicher und eines auf der Festplatte liegt Tupel A14 Tupel A13 Tupel A12 Tupel A11 Tupel A10 Tupel A Tupel A14 Tupel A13 Tupel A12 Tupel A11 Tupel A 10 Tupel A Tupel 16 Tupel 15 Tupel 17 Tupel 16 Tupel 15

Efficient Join Processing in Streaming Data 18 Duplikate Problem: In der 2. und 3. Phase können Duplikate entstehen Lösung: Verwendung von Timestamps (Zeitstempel): –Ankunfts-Timestamp (ATP) (bei Ankunft im Speicher) –Abreise-Timestamp (DTP) (wenn auf Festplatte geschoben wird) –ATP und DTP beschreiben Intervall, in dem Tupel im Speicher

Efficient Join Processing in Streaming Data 19 Tupel B Tupel in der 1. Phase gejoint A ist vor B1 im Hauptspeicher und verlässt ihn nach B1 Tupel A DTSATS Tupel B Tupel nicht in der 1. Phase gejoint A ist bei Ankuft von B2 nicht mehr im Hauptspeicher Tupel A DTSATS Ermittlung von Tupeln, die in der 1. Phase gejoint wurden (zur gleichen Zeit im Speicher) Überschneidung Keine Überschneidung

Efficient Join Processing in Streaming Data 20 Tupel A DTS ATS Tupel B DTS ATS Ermittlung von Tupeln, die in der 2. Phase gejoint wurden ProbeTS DTS last Partition Partition Partion 3 History-Liste der entsprechenden Partition (enthält Zeiten, zu denen die 2. Phase ausgeführt wurde) Partition Partition 2 Alle Tupel vor DTSlast wurden in der 2. Phase, zur Zeit ProbeTS, gejoint Alle Tupel von A in Partition 2, bis zu DTSlast 250, wurden mit Tupeln aus dem Speicher gejoint, die vor Partition 2s ProbeTS ankamen zurück

Efficient Join Processing in Streaming Data 21 Vorteile und Nachteile XJoin ist bereits für Datenströme geeignet: –Überbrückt Wartezeiten (2. Phase) –Gibt schnell Ergebnisse aus (1. Phase) –Duplikate nicht möglich –Riesige Datenmengen kein Problem Problem: nur 2 Datenströme gleichzeitig möglich Lösung: MJoin

Efficient Join Processing in Streaming Data 22 MJoin Mehr als 2 Streams als Eingabe möglich Idee: Verallgemeinern von symmertischem Hash Join (Pipeline) und XJoin, so dass mit mehr als 2 Eingaben gearbeitet werden kann. Probleme: Akzeptieren jedes Tupels von jedem Stream zu jeder Zeit, Ergebnis so schnell wie möglich & keine Duplikate, schwankende Eingaberate, nicht abreißender Datenstrom.....

Efficient Join Processing in Streaming Data 23 Basis Algorithmus Erzeuge für jeden Eingabestrom eine Hash-Tabelle Füge Tupel in entsprechende Hash-Tabelle ein Untersuche auf Matches Memory-Overflow-Behandlung

Efficient Join Processing in Streaming Data 24 Beispiel Szenario Ankunft von b (S3) Disk-to-Memory-Operation Memory-Overflow in S3 & Ergebnis

Efficient Join Processing in Streaming Data 25 Verhalten bei schwankender Eingaberate S3 hat variierende Eingaberate: -schnell -langsam -schnell Die Performance und Ausgaberate ist bei MJoin besser als bei den anderen beiden. FSLow und FSHigh wechseln sich je nach Geschwindigkeit ab.

Efficient Join Processing in Streaming Data 26 Window Joins Problem: Datenströme sind meist unendlich, d.h. sie benötigen unendlich viel Speicherplatz. Lösung: Window-based Joins (Joins, die nur in einem begrenztem Zeitintervall Tupels joinen) Verwendetes Zeitfenster: 10,000 Tupel MJoin ist am schnellsten. Grund: alle Berechnungen können, aufgrund des Fensters, im Speicher ausgeführt werden (MJoin ist für Operationen innerhalb des Speichers optimiert)

Efficient Join Processing in Streaming Data 27 Zusammenfassung Beim Join von Streams müssen folgende Dinge beachtet werden: –gute Speicherverwaltung, da Streams riesig bis unendlich sein können –schwankende Eingaberaten –schnelle Ergebnisse (aber nicht unbedingt vollständig) –mehr als 2 Streams gleichzeitig –Keine Duplikate XJoin ist dafür schon gut geeignet, kann aber nur 2 Streams gleichzeitig joinen MJoin erweitert XJoin dahingehen, dass nun auch mehrer Streams gleichzeitig gejoint werden können.

Efficient Join Processing in Streaming Data 28 Referenzen Annita N. Wilschut, Peter M. G. Apers: Dataflow Query Execution in a Parallel Main-Memory Environment, in Distributed and Parallel Databases. vol. 1, no. 1,1993. Urhan, Franklin: XJoin: Getting Fast Answers from slow and bursty Networks, University of Maryland, 2000 Stratis D. Viglas, Jeffrey F. Naughton, Josef Burger: Maximizing the Output Rate of Multi-Way Join Queries over Streaming Information Sources, in Proc. of the 29th Int'l Conference on Very Large Databases (VLDB)