Data Streams Thema: Operatoren auf Data Streams Ou Yi [email protected] Technische Universität Kaiserslautern Lehrgebiet Datenverwaltungssysteme

Data Streams

Thema: Operatoren auf Data Streams

Ou Yi

[email protected]

Technische Universität Kaiserslautern

Lehrgebiet Datenverwaltungssysteme

Seminar Datenbanken und Informationssystemeim Sommersemester 2005

11. April 2023 Operatoren auf Data Streams Folie 2

Überblick

Einleitung

Probleme der Strom-Verarbeitung

Semantik der Operatoren

• STREAM

• Aurora

Join-Operatoren

Zusammenfassung


Einleitung

Merkmale des Datenstrommodells

• kontinuierlich, potenziell hohe Ankunftsrate

• potenziell unendlich lang

• Reihenfolge kann verfälscht sein

Grundkonzepte

• gleitendes Fenster (endliche Teilmenge)

• Zeitstempel (implizit & explizit)

Klassifikation der Anfragen

• kontinuierliche Anfragen vs. einmalige Anfragen

• vordefinierte Anfragen vs. "ad hoc"-Anfragen

• DSMS: rechtzeitige Auswertung der kontinuierlichen Anfragen

(eventuell auch Funktionalität von DBMS)


Probleme der Strom-Verarbeitung

Exakte Antwort unmöglich

• >> Approximierung

Blockierung

• blockierende Operatoren (z. B. Aggregat-Operator)

• nicht-blockierende Operatoren (z. B. Filter)

• >> nicht-blockierende Verfahren + Fenstertechnik

verfälschte Reihenfolge (expliziter Zeitstempel)

• >> Pufferung und Sortierung

Kombination mit Relationen

• unterschiedliches Datenmodell und Verarbeitungsmodell


Semantik der Operatoren in STREAM

Ziel: kontinuierlichen Anfragen auf Datenströmen und Relationen

Def.: Strom S

• eine möglicherweise unendliche Multimenge von Elementen <s, t> Datenanteil s: feste Attributmenge

Zeitstempel t: Zeitdomäne T, diskret und geordnet

Def.: Relation R

• eine Abbildung von einer Zeitdomäne auf eine endliche, aber

unbegrenzte Multimenge von Tupeln zu jedem Zeitpunkt t T bestimmt R eine Multimenge R(t)

Ströme Relationen

Strom-zu-Relation

Relation-zu-Strom

Relation-zu-Relation


STREAM - Operatorklassen

Implementierte Operatoren

• Strom-zu-Relation-Opertoren seq-window (zeitbasiert, tupelbasiert und partitioniert)

• Relation-zu-Strom-Operatoren i-stream, d-stream, r-stream

• Relation-zu-Relation-Operatoren select, project, joins, union, intersect, aggregate etc.

abgeleitet vom Relationenmodell, ähnliche Semantik

• System-Operatoren für die Semantik einer Anfrage irrelevant

isolieren Anfrage-Operatoren von Aspekten der unteren System-Ebenen


STREAM – Strom-zu-Relation-Operatoren

Zeitbasiertes Fenster

• Eingabe: Strom S, Parameter: Zeitintervall Z, Ausgabe: Relation R

• Extremfall Z = 0, Fenster = [t, t]

• Beispiel: Eingabe-Strom-Schema: <Datenanteil, Zeitstempel>

Eingabe-Strom: <a, 0>, <b, 0>, <c, 1>, <c, 2>, <d, 2>, <e, 3>, <f, 4>, <f, 5>...

Parameter: Z = 2

[max(t-Z, 0), t]: [0, 0]

[0, 1]

[0, 2]

[1, 3]

[2, 4]

Ausgabe-Relation: R(t)

R(0) R(1) R(2) R(3) R(4) ...

<a> <a> <a> <c> <c>

 <c> <d>

<c> <c> <d><e>

<e>

<c> <f>

<d>

}),0,max('',|{)( tZttStsstR


STREAM – Strom-zu-Relation-Operatoren (2)

Tupelbasiertes Fenster

• Eingabe: Strom S, Parameter: Integer N, Ausgabe: Relation R

• R(t): die jüngsten N Tupel

• Beispiel: Eingabe-Strom-Schema: <Datenanteil, Zeitstempel> Eingabe-Strom: <a, 0>, <b, 0>, <c, 1>, <c, 2>, <d, 2>, <e, 3>, <f, 4>, <f, 5>...

Parameter: N = 2

Partitioniertes Fenster (tupelbasiert)

• zusätzlich eine Attributmenge (ähnlich zum GroupBy im RM)

• R(t): Vereinigung der tupelbasierten Fenster über allen Subströmen

R(0) R(1) R(2) R(3) R(4) ...<a> <a> or <c> <c> or <d> <e> <c> <d> <e> <f>


STREAM – Relation-zu-Strom-Operatoren

Rstream (relation stream)

• Eingabe R, Ausgabe S

• <s, t> S immer dann, wenn s R(t)

• Beispiel: Eingabe-Relation R(t):

Ausgabe-Strom: <a, 0>, <b, 0>, <c, 1>, <c, 2>, <d, 2> ...

Istream (insert stream)

Dstream (delete stream)

0

}){)(()(

t

ttRRRstream

R(0) R(1) R(2) ...<a> <c> <c> <d>


STREAM – Relation-zu-Relation-Operatoren

Keine Strom-zu-Strom-Operatoren

Vorteil: Wiederverwendung der formalen Grundlagen und

Implementierungstechniken des Relationenmodells

Ströme Relationen

Strom-zu-Relation

Relation-zu-Strom

Relation-zu-Relation


Semantik der Operatoren - Aurora

Strom-zu-Strom-System, Relationen nicht explizit unterstützt

Anfrage-Algebra

• Stream Query Algebra

Sieben primitive Operatoren

• Reihenfolgeirrelevant Filter, Map und Union

ähnlich zu Selektion, Projektion und Mengenvereinigung im RM

• Reihenfolgesensitiv BSort, Aggregate, Join und Resample

Ausführung mit begrenztem Speicherplatz und in begrenztem Zeitraum nur möglich, wenn eine Ordnung auf einem Attribut vorliegt (Beispiel: Join kann auf Sortierung basieren)


Aurora - Reihenfolgespezifikation

Reihenfolgespezifikation

O = Order (On A, Slack n, GroupBy B1, ..., Bm)

• A: welches Attribut ist geordnet

• n (optional): die Anzahl der jüngeren Tupel, die vor einem

verspäteten Tupel ankommen dürfen

• B1, ..., Bm (optional): Partitionierung

• Beispiel Eingabe-Strom-Schema: (A, B) Eingabe-Strom: ..., (1, x), (2, x), (2, y), (2, y), (5, x), (4, x), (5, y), (3, x), (6, x), ...

O = Order ( on A, Slack 1, GroupBy B ) in zwei Subströme (B = x und B = y) partitioniert erlaubt: (4, x), verworfen: (3, x)


Aurora - BSort

BSort

• Puffer-basierte approximierte Sortierung

• BSort (Assuming O) (S),

mit O = Order (On A, Slack n, GroupBy B1, ..., Bm)

• O spezifiziert die Qualität der Ausgabe

• äquivalent zu n-Durchläufe-Bubblesort

• Puffer von n+1 Tupeln: immer das "kleinste" Tupel ausgeben

• je größer der Puffer, desto genauer die Sortierung, aber größere

Verzögerung


Aurora – BSort (2)

BSort (Forts.)

• Beispiel: n = 2

Zeitpunkt 1 2 3 4 5 6 7 8 9 10 ...

Eingabe-Strom 2 3 1 2 5 4 8 3 4 6 ...

2 2 2 2 2 3 4 3 4 5

Puffer - 3 3 3 3 4 5 5 5 6 ...

- - 1 2 5 5 8 8 8 8

Ausgabe-Strom 1 2 2 3 4 3 4 5 ...

1-Durchlauf-Bubble-Sort 2 1 2 3 4 5 3 4 6 8

2-Durchläufe-Bubble-Sort 1 2 2 3 4 3 4 5 6 8


Aurora - Aggregate

Aggregate

• Aggregate ( F, Assuming O, Size s, Advance i ) ( S )

• O spezifiziert eine Ordnung für S

Order (On A, Slack n, GroupBy B1, ..., Bm)

• F: Aggregat-Fkt in SQL-Stil oder UDF, auf Fenster

• Ausgabe-Tupel: ( A = a, B1 = u1, ..., Bm = um ) + + ( F ( W ) )

• W: Fenster spezifiziert durch s und i s: Fenstergröße bzgl. A, Eingabe-Tupel t mit t.A [a, a+s-1]

i: Größe der Fensterbewegung

• Beispiel


Aurora – Aggregate (2)• Beispiel (Forts.)

Eingabe-Strom-Schema: (StockId, Time, Price) berechne die stündlichen durchschnittlichen Preise für jede Aktie Aggregate(Avg(Price), Assuming O, Size 1 hour, Advance 1 hour)(S),

mit O = Order(On Time, GroupBy StockId)

...

11.(MSF, 2:00, 22)

10.(INT, 2:00, 16)

9. (IBM, 2:00, 17)

8. (IBM, 1:45, 13)

7. (INT, 1:30, 12)

6. (MSF, 1:30, 24)

5. (IBM, 1:30, 23)

4. (IBM, 1:15, 20)

3. (IBM, 1:00, 24)

2. (INT, 1:00, 16)

1. (MSF, 1:00, 20)MSF: 1-1:59

Tupel: 1, 6

INT: 1-1:59

Tupel: 2, 7

IBM: 1-1:59

Tupel: 3, 4, 5, 8

MSF: 2-2:59

Tupel: 11,...

INT: 2-2:59

Tupel: 10,...

IBM: 2-2:59

Tupel: 9,...

Eingabe-Strom Fenster Ausgabe-Strom

...

3. (MSF, 1:00, 22)

2. (INT, 1:00, 14)

1. (IBM, 1:00, 20)


Join-Operatoren

ressourcenaufwändig, potenziell alle Tupel der Eingabe zu

durchlaufen, unmöglich für Strom-Verarbeitung

klassische Algorithmen

• Nested-Loop-Join, Hash-Join, Sort-Merge-Join

hash-basierte Joins

• auf Gleichheitsprädikat eingeschränkt

• Symmetrischer Hash-Join (SHJ) nach dem Prinzip des "Pipelining"

Hauptspeicher-Algorithmus, für große Datenmengen nicht geeignet

• XJoin (Erweiterung von SHJ) nicht mehr auf den Hauptspeicher eingeschränkt

behandelt unstabile Eingabe


Join-Operatoren (2)

sortierbasierte Joins

• nicht auf Gleichheitsprädikat eingeschränkt

• Sort-Merge-Join (SMJ)

• ganze Eingabe in der Sortierphase einlesen (blockierend)

• Progressive Merge Join (PMJ) nicht-blockierende Variante von SMJ

kann schon in der Sortierphase Ergebnis-Tupel erzeugen

mit Fenstertechnik kann auf Strom adaptiert werden (TPMJ)


Join-Operatoren (3)

Join in Aurora

• simuliert Band-Join der Relationenalgebra

• Join (P, Size s, Left Assuming O1, Right Assuming O2) (S1, S2)

• P: Join-Prädikat

• O1 bzgl. A für S1, O2 bzgl. B für S2

• t S1 und u S2 werden verbunden, falls |t.A – u.B| s P(t, u)

• Beispiel: Aktienpreisinfos aus zwei Märkten, X und Y, mit Schema (StockId,

Time, Price)

finde Aktien-Paare, deren Preise innerhalb 10 Min in zwei Märkten gleich sind


Join-Operatoren (4)

• Beispiel (Forts.): Join (P, Size 10 Min, Assuming Left O, Assuming Right O) (X, Y)

wobei P(x, y) <=> x.Price = y.Price und O = Order(On Time)

X Y Ausgabe-Strom von Join

01. (IBM, 2:00, 3) 01. (SMS, 1:55, 3) 01. (IBM, 2:00, 3, SMS, 1:55, 3)

02. (MSF, 2:00, 1) 02. (SAP, 1:55, 4) 02. (IBM, 2:00, 3, SMS, 2:05, 3)

03. (INT, 2:00, 1) 03. (BMW, 1:55, 5) 03. (IBM, 2:05, 4, SAP, 1:55, 4)

04. (IBM, 2:05, 4) 04. (DML, 1:55, 6) 04. (IBM, 2:05, 4, SAP, 2:05, 4)

05. (MSF, 2:05, 2) 05. (SMS, 2:05, 3) 05. (IBM, 2:05, 4, SMS, 2:15, 4)

06. (INT, 2:05, 1) 06. (SAP, 2:05, 4) 06. (IBM, 2:05, 4, SAP, 2:15, 4)

07. (IBM, 2:10, 4) 07. (BMW, 2:05, 5) 07. (IBM, 2:10, 4, SAP, 2:05, 4)

08. (MSF, 2:10, 3) 08. (DML, 2:05, 6) 08. (IBM, 2:10, 4, SMS, 2:15, 4)

09. (INT, 2:10, 1) 09. (SMS, 2:15, 4) 09. (IBM, 2:10, 4, SAP, 2:15, 4)

10. (IBM, 2:15, 2) 10. (SAP, 2:15, 4) 10. (MSF, 2:10, 3, SMS, 2:05, 3)

11. (MSF, 2:15, 4) 11. (BMW, 2:15, 5) 11. (MSF, 2:15, 4, SAP, 2:05, 4)

12. (INT, 2:15, 1) 12. (DML, 2:15, 6) 12. (MSF, 2:15, 4, SMS, 2:15, 4)

... ... 13. (MSF, 2:15, 4, SAP, 2:15, 4)

...


STREAM vs. Aurora

Ähnlichkeit

• Stromorientiert, unterstützen die Auswertung kont. Anfragen auf DS

• Modellierung eines Stroms: feste Attributmenge und min. ein geordnetes Attribut

explizite Zeitstempel (für Semantik eines Operators)

• Fenstertechnik

Unterschied

• Unterstützung von Relationen

• Behandlung des Reihenfolgeproblems

• Fenster auf jedem geordneten Attribut (Aurora) STREAM: <s, t>

Aurora: (a1, ..., am)


Zusammenfassung

Operatoren in DBMS sind im DSMS vorhanden und werden dort

erweitert oder simuliert

bei unendlicher Eingabe: Approximierung und Fenstertechnik

Zeitstempel für Strom-Verarbeitung erforderlich

• Bestimmung des Fensters

• notiert die Reihenfolge, für blockierende Operatoren wichtig

keine standardisierte "Strom-Algebra"

• verschiedene Mengen von Operatoren

• verschiedene Datentypen

Vielen Dank für ihre Aufmerksamkeit!

Fragen?


Zusatz

Zusammenspiel der Operatoren im STREAM

• Beispiel: Aktienpreisinfos als Daten-Elemente <s, t>

s gehört zu S(StockId, Price), t gehört zur Zeitdomäne T

finde solche Aktien, deren Preis höher als 50 ist

CQL-Anfrage:Select Rstream(*)

From S [Now]

Where Price > 50

1. Strom-zu-Relation: zeitbasiertes Fenster mit Z = 0, [t,t]

2. Relation-zu-Relation: Filter nach der Bedingung Price > 50

3. Relation-zu-Strom: Rstream


Zusatz

Zusammenspiel der Operatoren im Aurora

• Daten fließen durch einen azyklischen gerichteten Graph von

Operatoren

• Beispiel generiere eine Nachricht, wenn die Preise von mehr als m Aktien

gleichzeitig über eine Grenze k gehen.

Eingabe-Strom: (StockId, Time, Preis)

Filter (Price k)

Aggregate (CNT, Assuming O, Size 1, Advance 1)

Filter (CNT m)

O = Order ( On Time, Slack n)(Time,CNT)

Documents

Data Streams Thema: Operatoren auf Data Streams Ou Yi [email protected] Technische Universität Kaiserslautern Lehrgebiet Datenverwaltungssysteme