FernUniversität in Hagen Seminar 01912 im Sommersemester...

FernUniversität in Hagen

Seminar 01912

im Sommersemester 2005

“Neue Techniken der Anfragebearbeitung: Datenströme, kontinuierliche Anfragen

und adaptive Auswertung”

Thema 8 Aurora

Referentin: Ute Quandt

Gliederung des Vortrags 1. Einführung

1.1 Charakteristik traditioneller DBMS 1.2 Probleme der Kontrollanwendungen in traditionellen DBMS und ihre

Anforderungen an DBMS 1.3 Aurora - Prototyp für eine bessere Unterstützung der

Kontrollanwendungen

2. Aurora-System-Modell

2.1 Grundlegende Funktionalität 2.2 Abfragemodell

2.3 SQuAl - Stream Query Algebra - Auroras Strom-Abfragealgebra

3. Aurora – Optimierung

3.1 Anforderungen an die Abfrageoptimierung

3.2 Dynamische kontinuierliche Abfrageoptimierung

Gliederung des Vortrags 4. Aurora - Laufzeitarchitektur

4.1 Allgemeines 4.2 QoS - Datenstrukturen

4.3 ASM - Aurora-Speicher-Manager

4.4 Echtzeit-Ablaufplanung 4.5 Selbstüberwachung

4.6 Lastabwurf (load shedding)

5. Stand der Arbeiten und Schlussfolgerungen 5.1 Aurora-graphische Benutzerschnittstelle

5.2 Zusammenfassung der Ergebnisse

5.3 Verwandte Arbeiten

1. Einführung 1.1 Charakteristik traditioneller DBMS

Traditionelle DBMS - Ausrichtung auf die geschäftliche Datenverarbeitung

Anforderungen: 1. HADP Human-Active, DBMS-Passive

2. Einzig wichtig ist der aktuelle Zustand der Daten

3. Alarmzustände und –auslöser sind zweitrangig

4. Synchronisierung der Daten 5. Anwendungen erfordern keinen Echtzeit-Service

1. Einführung 1.2 Probleme der Kontrollanwendungen in traditionellen DBMS und ihre Anforderungen an DBMS

Anforderungen: 1. DAHP DBMS-Active, Human-Passive

2. Berücksichtigung der Historie der Werte im Datenstrom durch das

Datenmanagement 3. Unterstützung der Orientierung der Kontrollanwendungen auf

Alarmauslöser durch das DBMS

4. Kompensierung von Datenverlusten

Bei Notwendigkeit ungefähre Antworten 5. Echtzeitanforderungen der Kontrollanwendungen

1. Einführung 1.3 Aurora-Prototyp für eine bessere Unterstützung der Kontrollanwendungen

Entwicklung an: • Brandeis University in Waltham – USA • Brown University in Providence – USA • M.I.T. in Cambridge – USA Lösungsmöglichkeiten für Anforderungen von Kontrollanwendungen bei traditionellen DBMS: • sehr teuer • sehr schwierig zu installieren • beeinträchtigen die Performance negativ • Schätzungsfragen wurde noch in keinem DBMS realisiert

alle Basis-Mechanismen in den gegenwärtigen DBMS überdacht

2. Aurora-System-Modell 2.1 Grundlegende Funktionalität

Basisaufgabe: Verarbeitung der eingehenden Ströme auf einem vom

Anwendungsadministrator definierten Weg

Funktionalitäten: • Datenfluss-System

• Behälter-und-Pfeile-Modell (boxes and arrows model)

• Kontrolle der Servicequalität (QoS)

• Aurora-Zeitstempel für jedes eingehende Tupel • einheitlicher Quell-Identifizierer pro Datenquelle

2. Aurora-System-Modell 2.1 Grundlegende Funktionalität

2. Aurora-System-Modell 2.2 Abfragemodell

2. Aurora-System-Modell 2.3 SQuAl – Stream Query Algebra – Auroras Strom-Abfragealgebra

Strom - zusammengefügte Serie von Tupeln mit einheitlichem Typ

Unterstützung von 7 stromorientierten Operatoren in Aurora

Zwei Arten der Operatoren:

Ordnungs-agnostische: Filter, Map, Union

Ordnungs-sensible: BSort, Aggregate, Join, Resample

2. Aurora-System-Modell 2.3 SQuAl – Stream Query Algebra – Auroras Strom-Abfragealgebra

Ordnungsagnostische Operatoren: Verarbeitung der Tupel in der Ordnung, in der sie ankommen

Filter Ähnlich dem relationalen select, filtert verschiedene Aussagen, kann die Tupel entsprechend führen

Filter (P1, ...Pm) (S)

2. Aurora-System-Modell 2.3 SQuAl – Stream Query Algebra – Auroras Strom-Abfragealgebra

Ordnungsagnostische Operatoren: Map Ähnlich dem relationalen projection,

wendet Funktionen auf die zu verarbeitenden Tupel an

Map (B1=F1, ... , Bm=Fm) (S)

Union Analog dem relationalen union, Mischung von 2 oder mehr Eingabeströmen zu einem Ausgabestrom

Union (S1, ... , Sn)

2. Aurora-System-Modell 2.3 SQuAl – Stream Query Algebra – Auroras Strom-Abfragealgebra

Ordnungssensible Operatoren:

Garantie der Ausführung bei:

• endlichem Pufferplatz

• endlicher Zeit • Gewährleistung einer Ordnung über die Eingabetupel

(mit begrenzter Unordnung)

Beschreibung der Ordnung ankommender Tupel Order (On A, Slack n, GroupBy B1, ..., Bm)

alle Tupel, die nicht mit der Ordnungsspezifikation übereinstimmen,

fallen weg

2. Aurora-System-Modell 2.3 SQuAl – Stream Query Algebra – Auroras Strom-Abfragealgebra

Ordnungssensible Operatoren:

BSort angenähert dem Sort-Operator

BSort (Assuming O) (S)

2. Aurora-System-Modell 2.3 SQuAl – Stream Query Algebra – Auroras Strom-Abfragealgebra

Ordnungssensible Operatoren: BSort Slack=2

Zeit

1

2

3

4

5

6

7

8

9

10

Eingabestrom

1

3

5

1

2

3

5

5

8

5

Puffer

1

1

1

3

3

3

5

5

5

5

3

3

5

5

5

3

5

5

8

5

1

2

3

5

5

8

5

Ausgabestrom

1

1

2

3

3

5

5

5

2. Aurora-System-Modell 2.3 SQuAl – Stream Query Algebra – Auroras Strom-Abfragealgebra

Ordnungssensible Operatoren:

Aggregate wendet „Fenster-Funktionen“ an, um das Fenster über dem Eingabestrom zu verschieben

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

2. Aurora-System-Modell 2.3 SQuAl – Stream Query Algebra – Auroras Strom-Abfragealgebra

Beispiel: Erzeuge eine Ausgabe , wenn m Soldaten eine

Grenze k zur gleichen Zeit

überschritten haben! k>20, m=2, n(Slack)=1

(Sid,Time,Posn) (Sid,Time,Pos) (Time,Cnt) (Time,Cnt) (1,1,30) (1,1,30) (1,2) (1,2) (1,2,19) (2,2,23) (2,2) (2,2) (2,1,12) Filter (3,1,33) Aggregate (3,1) Filter (2,2,23) (3,2,23) (3,1,33) (3,3,39) (3,2,23) (3,3,39)

2. Aurora-System-Modell 2.3 SQuAl – Stream Query Algebra – Auroras Strom-Abfragealgebra

Ordnungssensible Operatoren:

Join Ähnlich dem relationalen join,

Binärer join-Operator

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

Verkettung der Tupel der beiden Eingabeströme

2. Aurora-System-Modell 2.3 SQuAl – Stream Query Algebra – Auroras Strom-Abfragealgebra

Ordnungssensible Operatoren:

Resample Asymmetrischer semijoinartiger Synchronisationsoperator, Ausrichtung von Paaren von Strömen

Resample (F, Size s, Left Assuming O1, Right Assuming O2) (S1, S2)

Bildung interpolierter Werte aus S1 unter Verwendung von S2

3. Aurora-Optimierung 3.1 Anforderungen an die Abfrage-Optimierung

Eines der wichtigsten Ziele:

Minimierung der Anzahl der Iterationen

Es wird erwartet: · eine große Menge von Boxen

· hohe Datenraten

· häufige Wechsel

· eine Offline-Nutzung des Netzwerks für eine Optimierung scheint unvernünftig

3. Aurora-Optimierung 3.2 Dynamische kontinuierliche Abfrageoptimierung

Ausgangspunkt: nicht optimiertes Aurora-Netzwerk

Während der Ausführung: • Erstellung der Laufzeit-Statistiken

• Laufzeit-Optimierung

Methode: Selektieren eines Teils des Netzwerkes

Auf das Subnetzwerk angewandte Taktiken: • eingefügte Projektionen (Inserting projections)

• kombinierte Boxen (Combining boxes)

• umorganisierte Boxen (Reordering boxes)

4. Aurora-Laufzeitarchitektur 4.1 Allgemeines

4. Aurora-Laufzeitarchitektur 4.2 QoS-Datenstrukturen

QoS (Quality of Service) - Servicequalität Maximierung des QoS für die produzierten Ausgaben Attribute der multidimensionalen QoS-Funktion : • Reaktionszeiten (response times) (a) • Tupel-Abwurf (Tupel drops) (b) • Produzierte Werte (values produced) (c)

(a) Delay-based

(b) Drop-based

(c) Value-based

4. Aurora-Laufzeitarchitektur 4.3 ASM Aurora-Storage-Manager (Aurora-Speicherverwaltung)

Zwei Anforderungen: 1. Organisierung der Speicherung der Tupel, die das Aurora-Netzwerk

durchlaufen 2. Gesonderte Tupel-Speicherung an den Verbindungspunkten Verwaltung der Warteschlange – Queue Management • Verwaltung einer Sammlung von Warteschlangen von Tupeln • Änderung der Priorität der Boxen durch Zeitablaufplaner • Periodisch Prüfung der Priorität für den Hauptspeicheraufenthalt der

Warteschlangen Verwaltung der Verbindungspunkte – Connection point management • Unterstützung von ad-hoc-Abfragen • Anforderung der Historie • Optionaler Speicherschlüssel

4. Aurora-Laufzeitarchitektur 4.4 Echtzeit-Ablaufplanung

Ziele von Aurora im gesamten System: 1. Maximierung der QoS 2. Reduktion der Verarbeitungskosten der Tupel Zeitablaufplanung für Züge (Train scheduling) Züge: Stapeln mehrerer Tupel als Eingabe für eine Einzelbox Superboxen: Tupelzug durch mehrere Boxen Ziele: 1. Reduzierung der pro Tupel durchgeführten E/A-Operationen 2. Minimierung der Anzahl von Boxenaufrufen pro Tupel Auswertung von Nichtlinearitäten zur Kostenreduktion: • Nichtlinearität zwischen den Boxen (Interbox non-linearity) • Nichtlinearität innerhalb der Box (Intrabox non-linearity)

4. Aurora-Laufzeitarchitektur 4.4 Echtzeit-Ablaufplanung

Hauptaufgabe der Echtzeit-Ablaufplanung: Prioritätenbestimmung für die Ausgaben Wartezeiten pro Ausgabe zur Maximierung der QoS

zwei Verfahren der Prioritätenbestimmung : 1. Statusbasiertes Verfahren

2. Rückkopplungsbasiertes Verfahren

Lösung des Problems: Nutzung von Erfahrungswerten für

Erfüllung der Echtzeit-Anforderungen und die Kostenreduktion durch Prioritätenbestimmung

4. Aurora-Laufzeitarchitektur 4.4 Echtzeit-Ablaufplanung

Leistung der Zeitablaufplanung: Aurora-Prototyp: Netzwerk mit 40 Boxen

Eingabe 50.000 Tupel 3200 Boxen pro Sekunde 830 Ausgabetupel pro Sekunde

Einzelboxverarbeitung

Tupelzugverarbeitung Verarbeitungszeit Reduktion um 0,48

Superbox-Zeitablaufplanung

zusätzliche

Verarbeitungszeit Reduktion um 0.43

4. Aurora-Laufzeitarchitektur 4.5 Selbstüberwachung

Ziel: Überlastungssituationen vorhersagen und entdecken Statische Analyse Stabiler Status abhängig von Tupelverarbeitungskosten und Rate der Tupelproduktion Kein stabiler Status erreichbar Lösung: Neuentwurf der Anwendung unter Änderung der

Ressourcenanforderung, Verfügbarkeit neuer Ressourcen zur Erhöhung der Systemkapazität,

Lastabwurf (load shedding) Dynamische Analyse Übergabe der Ausgabetupel (mit Zeitstempel) Prüfung des korrespondierenden verzögerungsbasierten QoS-Graphen auf „gute Zone“ des QoS-Graphen (good zone)

4. Aurora-Laufzeitarchitektur 4.6 Lastabwurf (load shedding)

statischen oder dynamischen Analyse Überlast Lastabwurf Lastabwurf durch wegfallende Tupel Realisierung in Netzwerkbereichen, in denen größere Abweichungen akzeptiert werden Als Resultat der statischen Analyse – Nutzung Abwurf-basierter QoS-Graphen Als Resultat der dynamischen Analyse – Nutzung verzögerungs-

basierter QoS-Graphen Semantischer Lastabwurf durch gefilterte Tupel Kontrolle der Wirkung der wegfallenden Tupel auf die Anwendungssemantik - Nutzung wertebasierter QoS-Graphen Filterboxen mit den am geringsten frequentierten Aussagen

5. Stand der Arbeiten und Schlussfolgerungen 5.1 Aurora - Grafische Benutzerschnittstelle

Implementierung

Prototyp Aurora

März 2003

Laufzeit-System:

Zeitablaufplaner

Rudimentärer Speichermanager

Code zur Boxenausführung

5. Stand der Arbeiten und Schlussfolgerungen 5.1 Aurora - Grafische Benutzerschnittstelle

Werkzeug zur

Überwachung der Warteschlangen

5. Stand der Arbeiten und Schlussfolgerungen 5.2 Zusammenfassung der Ergebnisse

Aurora

DAHP-System

Verarbeitung von Datenströmen für Kontrollanwendungen

SQuAl – 7 stromorientierte Operatoren

Speicherorganisation

Optimierung des Aurora-Netzwerkes

Echtzeit-Ablaufplanung

Selbstüberwachung

QoS-Graphen

Lastabwurf

5. Stand der Arbeiten und Schlussfolgerungen 5.2 Zusammenfassung der Ergebnisse

Aurora

Verarbeitung von Massendaten

Datenquelle – Hardwaresensoren

Banken / Steuerveraltung

Verarbeitung von Massendaten

Datenquelle – Datenfernübertragung

Hohe Sicherheit – kein Lastabwurf

Selbstüberwachungssysteme interessant

Lösungen für verteilte Systeme – u.a. wegen Lastspitzen

Weiterentwicklung Aurora Verarbeitung auf Einzelcomputer Verteilte Architektur Arbeit mit replizierten Boxen

5. Stand der Arbeiten und Schlussfolgerungen 5.3 Verwandte Arbeiten

STREAM

Realisierung eines umfassenden Datenmanagements

Erzielung von Verarbeitungsfunktionalitäten

Gemeinsamkeit zu Aurora:

Daten- und Ressourcen-Management, aber unterschiedliche Lösungen

STREAM Aurora

QoS unbekannt QoS-Spezifikationen

SQL spezielle Operatoren

5. Stand der Arbeiten und Schlussfolgerungen 5.3 Verwandte Arbeiten

Aurora Medusa

Borealis

Verteilte Stromverarbeitungsmaschine der zweiten Generation

Stromverarbeitungsfunktionalität Teilungsfunktionalität

Modifikation und Erweiterung

Unterstützung der Überarbeitung von Informationen in einem Strom mit drei Arten von Stromnachrichten

Wechsel der Boxensemantik während der Abarbeitung

QoS-basiertes Optimierungsmodell – operiert zwischen Server- und Sensornetzwerken

Fehler-Toleranz der Stromverarbeitung

Vielen Dank für die Aufmerksamkeit !