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

Im Rahmen des Seminars

Support For Non-standard Datatypes in DBMS

27.01.2004

Tina Scherer


2

Gliederung

• Motivation

• Besonderheiten von Streaming Daten

• Hash Joins– Simple Hash Join– Pipeline Hash Join

• XJoin– Memory-Overflow (3 Phasen)– Duplikate


3

• MJoin– Schwankende Eingaberate– Window Join

• Zusammenfassung

• Referenz


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


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


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


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 B1


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


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


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)


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






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


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.


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






Speicher

Festplatte


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 A4

Tupel A4 Tupel B3Tupel B2Tupel B1

Speicher

Festplatte

Tupel A3 Tupel A2 Tupel A1


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


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


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


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


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


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


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


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


24

BeispielSzenario Ankunft von b (S3)

Disk-to-Memory-OperationMemory-Overflow in S3 & Ergebnis


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.


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)


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.


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.

Documents

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