FernUniversität in Hagen. Seminar im Sommersemester 2005

Transkript

1 FernUniversität in Hagen Seminar im Sommersemester 2005

2 Neue Techniken der Anfragebearbeitung: Datenströme, kontinuierliche Anfragen und adaptive Auswertung Thema 8 Aurora Referentin: Ute Quandt

3 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

4 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) Gliederung des Vortrags 5. Stand der Arbeiten und Schlussfolgerungen 5.1 Aurora-graphische Benutzerschnittstelle 5.2 Zusammenfassung der Ergebnisse 5.3 Verwandte Arbeiten

5 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

6 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

7 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

8 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

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

10 2. Aurora-System-Modell 2.2 Abfragemodell

11 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

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

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

14 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

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

16 2. Aurora-System-Modell 2.3 SQuAl Stream Query Algebra Auroras Strom-Abfragealgebra Ordnungssensible Operatoren: BSort Slack=2 Zeit Eingab estrom Puffer Ausgab estrom

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

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

19 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

20 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

21 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

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

23 4. Aurora-Laufzeitarchitektur 4.1 Allgemeines

24 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

25 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

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

27 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

28 4. Aurora-Laufzeitarchitektur 4.4 Echtzeit-Ablaufplanung Leistung der Zeitablaufplanung: Aurora-Prototyp: Netzwerk mit 40 Boxen Eingabe 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

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

30 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ögerungsbasierter 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

31 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

32 5. Stand der Arbeiten und Schlussfolgerungen 5.1 Aurora - Grafische Benutzerschnittstelle Werkzeug zur Überwachung der Warteschlangen

33 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

34 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

35 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

36 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

37 Vielen Dank für die Aufmerksamkeit!