View
105
Download
1
Category
Preview:
Citation preview
Efficient Join Processing in Streaming Data
Im Rahmen des Seminars
Support For Non-standard Datatypes in DBMS
27.01.2004
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 A55Tupel A54Tupel A53
..........
Tupel A3Tupel A2Tupel 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 A10Tupel A9Tupel A8Tupel A7Tupel A6Tupel A5Tupel A4Tupel A3Tupel A2Tupel A1
Tupel B9Tupel 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 A2Tupel A1
Tupel B3Tupel B2Tupel B1
Tupel A3Tupel A2Tupel A1
Tupel B3Tupel B2Tupel B1
Tupel A3Tupel A2Tupel A1
Tupel B3Tupel B2Tupel 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
14
1. 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 A2Tupel A1
Tupel B3Tupel B2Tupel B1
Tupel A3Tupel A2Tupel A1
Tupel B3Tupel B2Tupel B1
Tupel A3Tupel A2Tupel A1
Tupel B3Tupel B2Tupel B1
Speicher
Festplatte
Efficient Join Processing in Streaming Data
15
Phase 1 - 2• 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 A3Tupel A2Tupel A1
Tupel B3Tupel B2Tupel B1
Tupel A4
Tupel A4 Tupel B3Tupel B2Tupel 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 A15Tupel A14Tupel A13
Tupel B10Tupel B9Tupel B8
Tupel A12Tupel A11Tupel A 10Tupel A 9
...........
Speicher
Tupel B7Tupel B6Tupel B5Tupel B4..............
•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
17
3. 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 A14Tupel A13Tupel A12Tupel A11Tupel A10Tupel A9...........
Tupel A14Tupel A13Tupel A12Tupel A11Tupel A 10Tupel A 9
...........
Tupel 16Tupel 15
Tupel 17Tupel 16Tupel 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 B1 178 198
• Tupel in der 1. Phase gejoint
• A ist vor B1 im Hauptspeicher und verlässt ihn nach B1
Tupel A 102 234
DTSATS
Tupel B2 348 601
• Tupel nicht in der 1. Phase gejoint
• A ist bei Ankuft von B2 nicht mehr im Hauptspeicher
Tupel A 102 234
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
100 200
ATS
Tupel B
DTS
500 600
ATS
Ermittlung von Tupeln, die in der 2. Phase gejoint wurden
ProbeTSDTSlast
20 340
Partition 1
250 550
Partition 2
300 700
Partion 3
History-Liste der entsprechenden Partition
(enthält Zeiten, zu denen die 2. Phase ausgeführt wurde)
100 300
Partition 1
800 900
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 2’s 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
BeispielSzenario Ankunft von b (S3)
Disk-to-Memory-OperationMemory-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). 2003.
Recommended