Data Streams

Data Streams

Thema: Operatoren auf Data Streams

Ou Yi

o_yi@informatik.uni-kl.de

Technische Universität Kaiserslautern Lehrgebiet Datenverwaltungssysteme

Seminar Datenbanken und Informationssysteme im Sommersemester 2005

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

<b> <b> <b> <c> <d>

<c> <c> <d>

<e>

<e>

<c> <f>

<d>





' '

,

| { )

(t s s t S t t Z t

R      

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 <b> <c> <c> or <d> <e>

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

t t R R

Rstream

R(0) R(1) R(2) ...

<a> <c> <c>

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

, ..., B

)

• A: welches Attribut ist geordnet

• n (optional): die Anzahl der jüngeren Tupel, die vor einem verspäteten Tupel ankommen dürfen

• B₁, ..., B_m (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 B₁, ..., B_m)

• 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 B₁, ..., B_m)

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

• Ausgabe-Tupel: ( A = a, B₁ = u₁, ..., B_m = u_m ) + + ( 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 O₁, Right Assuming O₂) (S₁, S₂)

• 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

)