11. Datenstrommanagementsysteme

1. 11. Datenstrommanagementsysteme Bernhard SeegerPhilipps-Universität Marburg

2. Informationslandschaft

3. Überblick • Motivation • Anwendungen • Eigenschaften von Datenströmen • Überblick zur Anfrageverarbeitung • Objektrelationale vs. strombasiert • Zeitintervalle • Logische Algebra • Snapshot-Reduzierbarkeit • Physische Algebra • Operatoren • Sweep-Areas • Zusammenfassung und Ausblick

4. Verkehrsmanagement • Sensor zur Datenerfassung • Anfragen über die Verkehrslast • Wie viele LKWs haben die Ausfahrt9 der A5 in Richtung Frankfurtpassiert? • Auf welchen Straßen ist für mehrals 10 Minuten die durchschnittlicheGeschwindigkeit unter 20 Km/h. • Eigenschaften • Variable Datenraten • Kombination von Daten aus Strömen und persistenten Datenbanken • Verarbeitung von Daten • Schnell und approximativ  exakt und langsam • Datenbezug zu Raum und Zeit

5. Monitoring eines Netzwerks • Motivation • Netzwerk einer Uni oder einer Firma • Frühes Erkennen von Anomalien und Angriffen • Denial of service attacks

6. Weitere Anwendungen • Wissenschaftliche Beobachtung • Satelliten • Beobachtung von sich bewegenden Objekte • Waren, Autos, Tiere, … • Kontrolle von Vitalitätsdaten • Clickstreams • Informationsticker • Anwendungsspezifische Eigenschaften • Elementgröße • Eingaberate • Fusion von Datenströmen

7. Eigenschaften von Datenströmen • Ordnung und Stromrate • Abhängig von der aktiven Datenquelle • Datentransfer eines Elements • einmal • Append-only • Keine Updates • Lange Anfragedauer • Potentiell unendlich • Approximation • Raum- und Zeitbezug • Direkte Verarbeitung der Datenströme • Abspeicherung und Anfragen kompletter Datenströme ist zu teuer!

8. Übersicht • Motivation • Anwendungen • Eigenschaften von Datenströmen • Überblick zur Anfrageverarbeitung • Objektrelationale vs. strombasierte • Zeitintervalle • Logische Algebra • Snapshot-Reduzierbarkeit • Physische Algebra • Operatoren • Sweep-Areas • Zusammenfassung und Ausblick

9. Objektrelationale Anfrageverarbeitung • Übersetzten einer deklarativen Anfrage in einen Ausführungsplan • Logischer Ausführungsplan • DBMS unterscheidet zwischen Operatoren • der logischen Algebra • der physischen Algebra • Logische Algebra eines object-relationalen DBMS • Relationale Algebra • Zusätzliche Funktionalität von SQL • Multisets • Aggregation, Group by, Map  Extended Relational Algebra • Logische Optimierung • Äquivalenz algebraischer Ausdrücke • Physische Algebra • Planoperatoren • Demand-driven • ONC-Schnittstelle

10. Anfrageverarbeitung auf Datenströmen • Data-driven Verarbeitung • Pufferung der Eingabedaten • Explizite Ablaufsteuerung der Operatoren • Probleme bei Planoperatoren • Blockierende Operatoren: Sortieren, … • Operatoren mit großem Ressourcenbedarf: Join, … • Laufzeitadaptivität • Hohe Verweildauer von Anfragen im System • Veränderung der Metadaten der Eingaben • Semantik • Was ist überhaupt eine geeignete Algebra für Datenströme?

11. Blockierung und Ressourcenbedarf • Gleitende Fenster • Dynamische Teilmenge des Datenstroms • Einschränkung der Verarbeitung auf die Daten im Fenster • Zählerbasierte Fenster • Verwaltung einer Menge konstanter Größe w • Neues Element verdrängt Elemente aus dem Fenster • Semantik ? • Abhängig vom Scheduling der Operatoren

12. (3,3) (3,3) (3,3) (3,3) (2,2) (2,2) (2,2) (2,2) 2 2 3 3 3 3 2 2 Beispiel 2 2 3 3 3 3 2 2

13. Nichtblockierende Operatoren • Gleitende Fenster • Dynamische Teilmenge des Datenstroms • Einschränkung der Verarbeitung auf die Daten im Fenster • Zeitbasierte Fenster • Annahme: • Jedes Element verfügt über ein Zeitattribut • Datenstrom liefert die Elemente in einer zeitlicher Reihenfolge • Elemente, die innerhalb der letzen w Zeiteinheiten gültig sind, werden im Speicher gehalten. • Viele Systeme verfolgen inzwischen diesen Ansatz • Wie z. B. PIPES

14. Übersicht • Motivation • Anwendungen • Eigenschaften von Datenströmen • Überblick zur Anfrageverarbeitung • Objektrelationale vs. strombasiert • Datenmodell und Zeitintervalle • Snapshot-Reduzierbarkeit • Physische Algebra • Operatoren • Sweep-Areas • Zusammenfassung und Ausblick

15. Zeitintervalle • Datenstrom = zeitlich geordnete Folge von Elementen, die • Informationsteil • Zeitstempel • Beispiel: Temperatursensoren • Sensor 1: (20, 9:00), (21, 9:30), (21, 10:00), … • Sensor 2: (19, 9:00), (20, 9:30), (22, 10:00), … • … • Äquivalente Transformation der Daten mit Zeitintervallen • Sensor1: (20, 9:00, 9:30), (21, 9:30, 10:00) … • Sensor 2: (19, 9:00, 9:30), (20, 9:30, 10:00), (22, 10:00, 10:30), … • …

16. Zeitintervalle • Datenstrom = zeitlich geordnete Folge von Elementen, die • Informationsteil • Zeitstempel • Beispiel: Verkehrssensor • A5, km 200: (430, 9:00), (410, 9:01), (450, 9:05), … • A5, km 201: (410, 9:00), (410, 9:03), (411, 9:12), … • … • Äquivalente Transformation der Daten mit Zeitintervallen • A5, km 200: (430, 9:00, *), (410, 9:01, *), (450, 9:05, *), … • A5, km 201: (410, 9:00, *), (410, 9:03, *), (411, 9:12, *), … • …

17. Zeitintervalle • Datenstrom = zeitlich geordnete Folge von Elementen, die • Informationsteil • diskreter Zeitstempel • Beispiel: Verkehrssensor • A5, km 200: (450, 9:00, 1), (430, 9:05,2), (350, 9:10, 1), … • A5, km 201: (430, 9:00, 2), (430, 9:05, 2), (410, 9:10, 1), … • … • Äquivalente Transformation der Daten mit Zeitintervallen • A5, km 200: (450, (9:00, 9:05), 1), (430, (9:05,9:10), 2), … • A5, km 201: (430, (9:00, 9:05), 2), (410, (9:05, 9:10), 1), … • …

18. Repräsentation • Transformation von Elementen mit Häufigkeit k } value, tstart value, tstart+1 … value, tend-1 { value, [tstart,tend) value, tstart value, tstart+1 … value, tend-1 value, [tstart,tend) k-mal value, tstart value, tstart+1 … value, tend-1 value, [tstart,tend) value, tstart value, tstart+1 … value, tend-1 value, [tstart,tend) k-mal value, tstart, k value, tstart+1, k … value, tend-1, k value, [tstart,tend), k Intervall-Repräsentation ChrononRepräsentation

19. Datamodell in PIPES • Datenstrom ist eine Folge von Elementen (value, [tstart, tend)) • Interpretation:Sensor liefert den Wert value, der im Zeitintervall [tstart, tend) gültig ist. • Elemente können mehrmals im Strom vorkommen • Vorteile: • Verkürzung von Zeitintervallen • Reduktion des Ressourcenverbrauchs • Deblockierung von blockierenden Operatoren • Eindeutige Zuordnung von Intervallen zu Zwischenergebnissen • An welchen Sensoren war das Verkehrsaufkommen identisch? select S1.value, max(S1.tstart,S2.tstart), min(S1.tend,S2.tend)from Stream S1, Stream S2where S1.value = S2.value and S1.tstart < S2.tend and S2.tstart < S1.tend

20. Snapshot-Reduzierbarkeit • Anfragesemantik in temporalen Datenbanken. PIPES RelationaleAlgebra • Ansatz im Stream-Projekt (Univ. of Stanford) • View-Maintainance • Berechne die Anfrage mit den entsprechenden Operatoren der relationalen Algebra • Transformiere die Ausgabe wieder in ein Datenstrom

21. Algebraische Transformationsregeln • Regeln sind Grundlage für die Anfrageoptimierung • Snapshot-äqivalente Ausdrücke …

22. Überblick • Motivation • Anwendungen • Eigenschaften von Datenströmen • Überblick zur Anfrageverarbeitung • Objektrelationale vs. strombasiert • Datenmodell und Zeitintervalle • Snapshot-Reduzierbarkeit • Physische Algebra • Operatoren • Sweep-Areas • Zusammenfassung und Ausblick

23. Logische und Physische Algebra • Ziel • Direkte Implementierung der logischen Operatoren basierend auf einer geeigneten physischen Repräsentation

24. 1 2 3 Physische Algebra in PIPES • Physische Repräsentation der Datenströme Folge von Elementen (value, [tstart, tend)) lexikographisch geordnet bzgl. tstart, tend T

25. Operatoren für Datenströme • Entsprechende Operatoren wie bei der relationalen Algebra • Kartesisches Produkt • Selektion • Vereinigung • Differenz • Projektion • Zusätzliche Operatoren zur Aggregation • Gruppieren • Aggregatberechnung • Spezialoperatoren • Join

26. Anfragegraph

27. s Implementierungsaspekte • Data-driven • Direkte Verarbeitung derElemente bei deren Ankunft • Publish-Subscribe Schnittstelle • Gemeinsame Schnittstelleder physischen Operatoren unsubscribe subscribe publish subscribe unsubscribe publish

28. g Statuslose Operatoren • Beispiele • Selektion • Projektion • Gruppieren • Verarbeitung • Wenn immer ein Element empfangen wird, kann sofort der Operator angewendet werden. • Gruppieren • Zerlegung der Eingabe in verschiedene Ausgabeströme • Pro Gruppe ein Ausgabestrom

29. 1 • neues Element 7 Aggregatberechnung • Beispiele: Summe • Reorganisieren • Einfügen 5 • Status der Aggregation 4 3 6 4 5 T • Effiziente Implementierung • Segmentbaum • Amortisierte logarithmische Kosten pro Elemement

30. Zweck Chronon-Repräsentation  Interval-Repräsentation Reduzieren der Elemente im Strom Funktionalität Verschmelzen von benachbarten Tupeln mit gleichen Werten. Tradeoff Länge der Intervalle  Outputrate 1 1 2 new element (id, value) (idj, valj) 1 (idj, valj) 1 1 new element (idj, valj) (idj, valj) 2 current state (idj, valj) 1 (idj, valj) T (idj, valj) Coalesce Operator Reorganization Insertion current state

31. Join Operator • Invarianten • Jedes Element verfügt über ein Zeitintervall • Datenströme sind sortiert bzgl. des linken Eckpunkts des Zeitintervalls, bei Gleichheit zusätzlich bezgl. des rechten Eckpunkts • Joinverarbeitung • Eingabe: zwei Datenströme • Ausgabe: select S1.value, max(S1.tstart,S2.tstart), min(S1.tend,S2.tend)from Stream S1, Stream S2where S1.value = S2.value and S1.tstart < S2.tend and S2.tstart < S1.tend

32. Symmetric Hash Join • Typische Art der Verarbeitung unter Verwendung eines Status pro Eingabestrom • Sortierung der Ergebnisse in einem Heap • Sicherstellung der Sortierung • Problem: Überlauf des Speichers • Neue Joinvarianten: • XJoin, • Progressive Merge Join • Verkleinerung der Zeitfenster • Qualität der Ergebnisse Memory SA SB probe insert A B

33. Sweep-Areas • Statusbehaftete Operatoren • Derzeitiger Status: eine oder mehrere Mengen von Stromelementen • Berechnung erfolgt auf Basis der bisherigen Stromelemente • Elemente sind noch nicht fertig für die Ausgabe bzw. können noch nicht aus dem Status gelöscht werden. • Sweep-Areas sind dynamische Datenstrukturen (im Hauptspeicher) • Für die Realisierung von zeitbasierten Fenstern • Interface SweepArea • insert(Element new) • query(Element new) • Mögliche Ausgabe von Elementen  Join • reorganize(Element new) • Mögliche Ausgabe von Elementen  Aggregation, Difference • Entfernen von Elementen

34. T tanf tend Aufräumen der Sweep-Areas • Invariante • Ein Element aus einer Sweep-Area kann dann entfernt werden, wenn es keinen Einfluß auf das zukünftige Ergebnis hat. • Beispiel (Join) • Wird ein Element mit Zeitintervall [tanf, tend) empfangen, kann man in dem nicht zu dieser Eingabe gehörenden Status alle Elemente entfernen, deren Endzeitpunkt links von tanf liegt. • Problem • Wenn eine Datenquelle nicht sehr oft Daten sendet, führt dies zum Anwachsen des Status der anderen Quelle. 

35. Plangenerierung

36. Laufzeitumgebung

37. Scheduler (Ablaufsteuerung) • Aufgabe • Aktivierung eines Operators zur Verarbeitung • Ziele • Minimierung des Ressourcenbedarfs (Zeit und/oder Speicherplatz) • Minimierung der Verweildauer eines Elements • Erfüllung von gewissen Qualitätsvorgaben (QoS = ``Quality of Service´´) • Strategien • Auswahl des Operators mit den meisten wartenden Elementen • Voraussetzung: es gibt eine Queue zwischen zwei aufeinanderfolgenden Operatoren • Fifo (First in first out) • Zu einer Eingabe werden alle Ergebnisse direkt produziert. • Chain-Strategie • Minimierung der Längen der Warteschlangen vor den Operatoren (Reduktion des benötigten Speicherplatz)

38. Memory Manager (Speicherverwaltung) • Aufgabe • Dynamische Verteilung des Speichers auf den Operatoren des Operatorgraphen • Anforderung • Verarbeitung aller Daten im gleitenden Zeitfenster • Zwischenzeitlich stark belastete Operatoren benötigen für einen kurzen Zeitraum mehr Speicher! • Adaptive Verteilungsstrategie • Speicherzuteilung eines Operators zur Laufzeit (abhängig von der Systemlast) • Voraussetzung sind speicheradaptive Implementierungen der Operatoren • Basiert auf Verwendung eines Kostenmodells • wie z. B. in Pipes  Diplomarbeit von Sonny Vaupel

39. QueryOptimizer (Anfrageoptimierung) • Aufgaben • Optimierrung des gesamten Anfragegraphen • Einbringen von neuen Anfrageplänen • Vermeidung von Redundanz bei der Berechnung • Re-Optimierung von Teilen des Anfragegraphen zur Laufzeit • Ziele • Minimierung des Berechnungs- und Speicheraufwands zur Verarbeitung aller Anfragen • Problem • Größe der Eingabe ist potentiell unendlich • Stattdessen nutzt man die Eingaberate (Tupel/sec) • Techniken • Monitoring und Schätzung relevanter Metadaten zur Laufzeit • Beispiel • Selektion sollte nicht unbedingt vor dem Join ausgeführt werden.

40. Überblick • Motivation • Anwendungen • Eigenschaften von Datenströmen • Überblick zur Anfrageverarbeitung • Objektrelationale vs. strombasiert • Zeitintervalle und Datenmodell • Snapshot-Reduzierbarkeit • Physische Algebra • Operatoren • Sweep-Areas • Zusammenfassung und Ausblick

41. Relevanz • Heterogene Informationslandschaft • Datenströme sind ein wichtiger Bestandteil • Kommerzielle Applikationen • Verkehrsmangagement, Netzwerkkontrolle, … • Kommerzielle Systeme • Oracle Streams, … • Verschiedene Projekte in Nordamerika • UC Berkeley, MIT, Stanford, U Waterloo, … • Unser Ansatz: Nahtlose Erweiterung der XXL-Bibliothek

42. PIPES Logische Algebra mit klarer Semantik Zeitintervalle Physische Algebra Coalesc zum Verbinden von aufeinandefolgenden äquivalenten Elementen SweepAreas für den Status Publish-Subscribe Architektur Komplexe Anfragegraphen Effektive Laufzeitumgebung Ablaufsteuerung Speichermanagement Online-Optimierung Indexstrukturen Erweiterte relationale Algebra Anfrageoptimierung Native Unterstützung von XML Rahmenwerk für Joins … XXL Bibliothek

43. Derzeitige Themen • Laufzeitumgebung • Anwendbar auch im Kontext traditioneller DBMS • Strategien bei der Ablaufsteuerung • Anfrageoptimierung sehr großer Anfragegraphen • Data Mining auf Datenströmen • Synopsen für Dichteschätzung • Datenströme für Metadaten • Entdeckung und Einbindung von nützlichen Ressourcen