Ausarbeitung
Werbung
FernUniversität in Hagen Seminar 1912 im Sommersemester 2005: Neue Techniken der Anfragebearbeitung: ” Datenströme, kontinuierliche Anfragen und adaptive Auswertung“ Thema 7 STREAM: The Stanford Stream Data Manager Referent: Udo Werner Seite 1 Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Inhaltsverzeichnis 1 Einleitung 1.1 Beispielszenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 2 Einführung in STREAM 2.1 Überblick Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 STREAM Überblick: Anforderungen an DSMS . . . . . . . . . . . . . . . . . 4 4 5 3 DSMS-Anfragesprache: CQL 3.1 Sprachkonzepte von CQL . . . . . . . 3.1.1 Strom-zu-Relation-Operatoren 3.1.2 Relation-zu-Strom-Operatoren 3.1.3 Beispiel-Anfragen . . . . . . . 3.2 Vereinfachungen und Standardwerte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 7 8 9 9 4 DSMS-Konzepte in STREAM 4.1 Anfrageplanung und -ausführung . . . 4.1.1 Komponenten der Anfragepläne 4.1.2 Scheduling . . . . . . . . . . . . 4.2 Ressourcen-Verwaltung . . . . . . . . . 4.2.1 Anfrageoptimierung . . . . . . . 4.2.2 Redundanz-Minimierung . . . . 4.2.3 Nutzung von Einschränkungen . 4.3 Näherungsverfahren . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10 10 11 14 15 15 16 17 5 Zusammenfassung und Ausblick 18 6 Abkürzungen 19 Abbildungsverzeichnis 1 2 3 4 5 6 Beispielszenario: Überwachung von Bank-Transaktionen . . . . . . Beispielszenario: identifizierte Datenströme . . . . . . . . . . . . . Beziehungen von Datentypen und Operatoren [ABW03, ABB+04] STREAM: Systemaufbau im Überblick [ABB+03] . . . . . . . . . Beispiel: Anfrageplan in STREAM . . . . . . . . . . . . . . . . . Beispiel: optmierter Anfrageplan in STREAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 4 5 12 16 Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager 1 Seite 2 Einleitung In immer mehr Anwendungsbereichen spielen nicht mehr nur persistente Daten eine Rolle, sondern in zunehmendem Maße auch Datenströme und deren vielseitige Analyse. Beispiele dafür sind die Überwachung und das Management von Netzwerkverkehr, Börsenticker oder Sensornetze. Datenbank-Management-Systeme (DBMS) bieten trotz einiger Gemeinsamkeiten von üblichen relationalen Daten mit Datenströmen nicht die für die Verarbeitung von Datenströmen erforderlichen Funktionalitäten, da Datenströme eine Reihe von spezifischen Eigenschaften besitzen, die sie von den traditionell persistent gehaltenen relationalen Daten unterscheiden. So ist man bei DBMS-Systemen in den meisten Fällen eher an Anfragen interessiert, die den (endlichen) Zustand der gespeicherten Datensätze zu einem bestimmten Zeitpunkt wiederspiegeln, während bei Datenströmen eher kontinuierliche Anfragen über die Werte und ihre Veränderungen im Laufe der Zeit von Interesse sind. [ABB+04] Mit dem Stanford Stream Data Manager (STREAM) wird in dieser Ausarbeitung ein Vertreter einer neuen Klasse von Daten Management Systemen, den Datenstrom-ManagementSystemen (DSMS), vorgestellt. STREAM verfolgt das Ziel, möglichst universell verwendbar und gleichzeitig ohne großen Einarbeitungsaufwand bedienbar zu sein. Erreicht werden soll dies, indem sowohl für DBMS als auch für DSMS benötigte Funktionen nicht völlig neu entworfen werden. Stattdessen werden bereits existierende Konzepte einschließlich der Anfragesprache SQL um die für DSMS zusätzlich notwendigen Aspekte erweitert. Im Rahmen dieser Ausarbeitung wird nach einem kurzen Vergleich der Eigenschaften von Datenströmen und persistenten relationalen Daten gezeigt, wie STREAM konkret versucht, die daraus resultierenden besonderen Anforderungen für DSMS umzusetzen um beide Welten zu verbinden. Dabei wird speziell auf CQL, die im Zusammenhang mit STREAM als Erweiterung von SQL entwickelte Anfragesprache, und die weiteren für die Zielstellung von STREAM besonders wichtigen Konzepte eingegangen. Zu diesen Konzepten zählen die Erstellung von Anfrageplänen und deren Optimierung, sowie die Anpassung der Anfrageverarbeitung an veränderte Rahmenbedingungen zur Laufzeit. Abschließend werden der aktuelle Stand der Entwicklung sowie die zukünftig geplanten Erweiterungen und Verbesserungen beschrieben. 1.1 Beispielszenario Zur Verdeutlichung wird in den einzelnen Kapiteln jeweils auf ein beispielhaftes Anwendungsszenario Bezug genommen, welches in Abbildung 1 dargestellt ist: Entsprechend bestimmter Richtlinien ist eine Bank verpflichtet, die Transaktionen in Zusammenhang mit den Konten Ihrer Kunden überwachen zu können und speziell bestimmten Einrichtungen wie einem Geldwäschebeauftragten oder den Finanzämtern Zugriffsmöglichkeiten zur Verfügung zu stellen. Für das Beispiel wird angenommen, daß es bei einer Bank einen Zentralrechner gibt, der u.a. alle Überweisungen von Kunden der Bank bzw. an Kunden der Bank verarbeitet. Weiterhin gibt es Listen von Personen und Konten, die zu überwachen sind. Abbildung 2 zeigt nun, welche Datenströme es in diesem Szenario geben könnte: Da nie alle Kunden zum gleichen Zeitpunkt Überweisungen vornehmen werden, handelt es sich bei den Überweisungen jeweils um Datenströme. Auch bei der Überwachungsliste kann angenommen werden, daß sich der Inhalt dieser Liste ständig ändert, so daß diese Änderungen einen Datenstrom darstellen, der beim Zentralrechner eintrifft. Da Ermittlungsergebnisse sofort vorliegen sollen oder z.B. das Auftauchen von besonders großen Überweisungen sofort gemeldet werden soll, handelt es sich dabei auch um kontinuierliche Anfragen, die als Ergebniss einen Datenstrom von Werten liefern. Seite 3 Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Abbildung 1: Beispielszenario: Überwachung von Bank-Transaktionen Abbildung 2: Beispielszenario: identifizierte Datenströme Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager 2 Seite 4 Einführung in STREAM Ziel dieses Kapitels ist es, STREAM als DSMS in groben Zügen vorzustellen. Dazu muß zunächst geklärt werden, wie bestimmte Begriffe im Kontext von STREAM definiert sind und was die bei der Entwicklung von STREAM relevanten Aspekte von DSMS sind. Daraus abgeleitet wird der Aufbau von STREAM in seiner Umgebung beschrieben. 2.1 Überblick Begriffe Abbildung 3: Beziehungen von Datentypen und Operatoren [ABW03, ABB+04] Wie in Abbildung 3 zu sehen ist, gibt es in STREAM zwei Arten von Daten, nämlich Datenströme und Relationen. Auf diese Datentypen können drei unterschiedliche Arten von Operatoren angewendet werden. Dies sind entweder Relation-zu-Relation-Operatoren, Strom-zu-Relation-Operatoren oder Relation-zu-Strom-Operatoren. Es gibt keine Strom-zuStrom-Operatoren. Die entsprechende Funktionalität lässt sich aber über den Umweg“ von ” Strom-zu-Relation nach Relation-zu-Strom realisieren. [ABB+04] Datenstrom: Ein Datenstrom ist eine kontinuierliche, unbegrenzte Sequenz von Wertepaaren. Diese Wertepaare bestehen jeweils aus Datentupeln und einem Zeitstempel, der die logische Ankunftszeit des Datentupels innerhalb des Datenstroms kennzeichnet. Die Reihenfolge, in der die Wertepaare tatsächlich eintreffen, ist nicht (immer) vorhersagbar. Relation: Eine Relation ist eine in Abhängigkeit der Zeit veränderliche Menge von Tupeln. Eine entsprechende Menge von Tupeln zu einem bestimmten Zeitpunkt wird unmittelbare Relation genannt. Relation-zu-Relation-Operator: Ein Relation-zu-Relation-Operator nimmt eine oder mehrere Relationen als Eingangsparameter an und gibt eine Relation als Ausgangsparameter aus. Diese Klasse von Operatoren entspricht den Operatoren von DBMS. Strom-zu-Relation-Operator Ein Strom-zu-Relation-Operator nimmt einen oder mehrere Datenströme als Eingangsparameter an und gibt eine Relation als Ausgangsparameter aus. Relation-zu-Strom-Operator: Ein Relation-zu-Strom-Operator nimmt einen oder mehrere Relationen als Eingangsparameter an und gibt einen Strom als Ausgangsparameter aus. Seite 5 Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Kontinuierliche Anfrage: Eine kontinuierliche Anfrage ist ein Baum von Operatoren, wobei die Eingänge der Blätter die Eingangswerte der Anfrage darstellen und die Ausgabe der Wurzel die Ergebniswerte. Als Eingänge können sowohl Ströme als auch Relationen verwendet werden. Die Art des Ergebnisses wird vom Typ des Wurzeloperators bestimmt. 2.2 STREAM Überblick: Anforderungen an DSMS Abbildung 4: STREAM: Systemaufbau im Überblick [ABB+03] In Abbildung 4 ist das DSMS und seine Umgebung entsprechend dem Kontext von STREAM zu sehen. Aus diesem Systemaufbau, bei dem das DSMS als Blackbox dargestellt wird, lassen sich einige Anforderungen an die erforderliche Funktionalität und den inneren Aufbau der Box identifizieren. Auf den ersten Blick ist erkennbar, daß es ein DSMS ermöglichen soll, kontinuierliche Anfragen über Datenströme zu erstellen. Aus dem zuvor beschriebenen Wesen von Datenströmen und dem Aufbau der Anfragen für STREAM lassen sich bestimmte Eigenschaften ableiten, über die ein entsprechendes DSMS verfügen muß. Zunächst muß es in der Lage sein, mehrere potentiell unbegrenzte und sich über die Zeit verändernde Datenströme zu verarbeiten, ebenso aber auch gespeicherte Relationen. Es muß seinen Benutzern Möglichkeiten anbieten, Anfragen zu definieren, die wie bei DBMS bestimmte Teilmengen der Eingangswerte als Ergebnis liefern, dies aber sowohl für Relationen, als auch für Datenströme und bestimmte Verknüpfungen zwischen beiden Arten. Die Ergebnismenge muß aufgrund der geforderten Kontinuität permanent aktualisiert werden. Beispiel: Kommt eine Überweisung beim Zentralrechner an, deren Betrag über einem bestimmten registrierten Grenzwert liegt, muß die Warnungsliste“, die das Ergebnis einer Anfrage des ” Geldwäschebeauftragten ist, sofort aktualisiert werden. Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Seite 6 Aus der Langlebigkeit der Anfragen auf der einen Seite und der potentiell unbegrenzten Menge an einströmenden Daten auf der anderen Seite ergeben sich je nach Art der Ergebnisbildung eine Reihe von Problemen, die es bei DBMS in der Form nicht gibt [GTO03]: • Die Semantik und das Datenmodell der Operatoren sollten sowohl zeit- als auch reihenfolgeabhängige Anfragedefinitionen ermöglichen. • Während DBMS immer auf einem vollständigen, persistent gespeicherten Datenbestand operieren können, ist ein Speichern von Strömen auf Grund ihrer potentiellen Unendlichkeit nicht möglich. Ein DSMS muß also über Funktionalitäten verfügen, die das System in die Lage versetzen, auch nach dem Verwerfen eines Teils der Wertepaare wenigstens annhäherungsweise bestimmte Aussagen zur Gesamtheit aller Wertepaare treffen zu können. Dabei muß der Benutzer in Kauf nehmen, daß er nicht immer exakte Ergebnisse erhält. • Kontinuierliche Anfragen auf Ströme dürfen nur nicht-blockierend sein, da der Strom als unendlich betrachtet werden soll und die Anfrage deshalb auch unendlich lange aktiv ist. Würde sie blockieren, wäre das auch für einen unendlich langen Zeitraum möglich. • Wenn Anfragen permanent Ergebnisse liefern sollen, ist es in vielen Fällen aus Gründen der Reaktionszeit unmöglich, den kompletten vergangenen Strom bzw. größere Teile davon rückwirkend zu betrachten. Operatoren für solche Online-Anfragen müssen also eine Einweg-Verarbeitung von Wertepaaren vornehmen können. • Bei langer Laufzeit von Anfragen können sich die für die Ausführung relevanten Umgebungsbedingungen wie Durchsatz des Stroms, verfügbarer Arbeitsspeicher usw. grundlegend ändern. Die Ausführungsplanung des DSMS muß also in der Lage sein, dynamisch auf sich ändernde Rahmenbedingungen zu reagieren und Anpassungen vorzunehmen. 3 DSMS-Anfragesprache: CQL Bevor man die von STREAM umzusetzenden Konzepte und den inneren Aufbau genau betrachtet, sollte man die Art und Weise der Anfragedefinition kennen, denn dadurch wird festgelegt, welche Funktionalitäten zur Verarbeitung und Ausgabe umgesetzt werden müssen. Für STREAM ist die Anfragesprache Continuous Query Language (CQL) definiert worden, die nachfolgend näher betrachtet wird. 3.1 Sprachkonzepte von CQL Ein zentraler Aspekt beim Entwurf von STREAM sollte die Einfachheit der Anfragedefinition sein: Der Benutzer soll in die Lage versetzt werden, möglichst intuitiv und mit möglichst wenig zusätzlichem Lernaufwand Anfragen über Datenströme und etwaige gespeicherte Relationen erstellen zu können. Deshalb war es naheliegend, die im Bereich der DBMS etablierte Anfragesprache Structured Query Language (SQL) als Vorlage zu verwenden, da diese bereits die für die Verarbeitung von Relationen notwendigen Funktionen anbietet. Auf diese Art und Weise ist die in Kapitel 2.1 beschriebene Klasse der Relation-zu-Relation-Operatoren implementiert. Um zusätzlich dem Wesen von kontinuierlichen Anfragen auf Datenströme Seite 7 Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager zu genügen, wurde SQL um Konstrukte für die Strom-zu-Relation- und Relation-zu-StromOperatoren erweitert. Das Ergebnis dieser Erweiterungen, die jetzt beschrieben werden, ist die Anfragesprache CQL. 3.1.1 Strom-zu-Relation-Operatoren In CQL arbeiten sämtliche Strom-zu-Relation-Operatoren nach dem Konzept der gleitenden Fenster (sliding windows). Konkret bedeutet dies, daß ein Fenster jeweils eine bestimmte begrenzte Menge von Wertepaaren enthält, die in der Vergangenheit im Strom aufgetreten sind. Es gibt derzeit drei verschiedene Typen von Fenstern: Zeitbasierte Fenster Zeitbasierte Fenster auf einen Datenstrom werden über einen Parameter T definiert, der festlegt, aus welchem vergangenen Zeitintervall Wertepaare verwendet werden. Relevant ist jedoch nicht die Echtzeit, sondern der Zeitstempel der Wertepaare, da von einem nach Zeitstempeln sortierten Strom ausgegangen wird. Daraus folgt, daß das Intervall vom aktuell gültigen Zeitstempel S bis zum Zeitstempel S’:=S-T reicht. Neben üblichen Zeiteinheiten wie Sekunden, Minuten oder Tagen, können für den Parameter T auch zwei Sonderfälle definiert werden: Now und Unbounded. Now legt dabei fest, daß nur diejenigen Wertepaare verwendet werden, die den aktuell gültigen Zeitstempel besitzen, während Unbounded festlegt, daß jedes bisher eingetroffene Wertepaar zum Fenster gehört. Folgende Beispiele zeigen mögliche Definitionen solcher Fenster: • eingehendeUeberweisungen [Range 10 Minutes] definiert ein Fenster, in dem alle Elemente des Datenstromes eingehendeUeberweisungen enthalten sind, die in den vergangenen 10 Minuten beim Zentralrechner registriert wurden. • ausgehenedeUeberweisungen [Range Now] definiert ein Fenster, in dem nur die Elemente des Datenstromes ausgehendeUeberweisungen enthalten sind, die mit dem gerade gültigen Zeitstempel beim Zentralrechner angekommen sind. • Ueberwachungsliste [Range Unbounded] definiert ein Fenster, in dem alle Elemente aufgeführt sind, die im Datenstrom Ueberwachungsliste vorgekommen sind, d.h. es handelt sich hier um die vollständige Überwachungsliste. Anzahlbasierte Fenster Anzahlbasierte Fenster auf einen Datenstrom werden über einen Parameter N definiert, der festlegt, wieviele der in der Vergangenheit auf dem Datenstrom aufgetretenen Wertepaare zum Fenster gehören. Bei N handelt es sich um einen ganzzahligen, positiven Wert. Das Fenster enthält dann genau die N Wertepaare, die den jeweils höchsten Zeitstempel aufweisen bzw. alle Wertepaare, solange noch keine N Wertepaare im Datenstrom aufgetreten sind. Haben mehrere Wertepaare den gleichen Zeitstempel, wird das Fenster trotzdem auf N Elemente beschränkt und etwaige überzählige Elemente werden abgeschnitten. Da es keine Regel gibt, nach welchem Schema bei Überschreitung von N Wertepaare mit gleichem Zeitstempel ausgewählt werden, sind anzahlbasierte Fenster indeterministisch, da man selbst bei gleichartigen Mustern von Wertepaaren zu bestimmten Zeitpunkten unterschiedliche Inhalte erhalten kann. Auch bei anzahlbasierten Fenstern gibt es den Sonderfall, bei dem N als Unbounded definiert werden kann. Die Semantik ist dann die gleiche wie für [Range Unbounded] bei zeitbasierten Fenstern. Folgende Beispiele zeigen Definitionen für anzahlbasierte Fenster: • eingehendeUeberweisungen [Rows 1000] definiert ein Fenster, in dem die letzten 1000 Elemente des Datenstromes eingehendeUeberweisungen enthalten sind. Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Seite 8 • Ueberwachungsliste [Rows Unbounded] definiert ein Fenster, zu dem wieder alle Elemente gehören, die je im Datenstrom Ueberwachungsliste aufgetreten sind. Unterteilte Fenster Unterteilte Fenster auf einen Datenstrom werden über einen Parameter N und eine Teilmenge der Attribute des Datenstroms definiert, wobei der Strom anhand der Attributmenge in entsprechende Teilströme unterteilt wird. Jedes der so entstandenen Teilfenster ist dann wie ein anzahlbasiertes Fenster auf N Wertepaare des Datenstroms begrenzt. Die Unterteilung in Teilströme kann man sich analog zur "GROUP BY"-Klausel bei SQL vorstellen: Die Zugehörigkeit zu einem Teilstrom wird durch das Auftreten gleicher Werte bei den angegebenen Attributen festgestellt, wobei die Fenster für jeden Teilstrom zunächst einzeln berechnet werden. Die Ergebnismenge des unterteilten Fensters ist dann die Vereinigung der Menge der Teilfenster. Folgende Beispiele zeigen mögliche Definitionen solcher Fenster: • eingehendeUeberweisungen [Partition By EmpKontoID Rows 5] definiert ein Fenster, das zu jeder EmpKontoID die letzten 5 Elemente enthält, die im Datenstrom eingehendeUeberweisungen aufgetreten sind. • ausgehendeUeberweisungen [Partition By AbsKontoID, EmpKontoID Rows 1] definiert ein Fenster, das zu jeder vorgekommenen Kombination von AbsKontoID und EmpKontoID (also jedem Paar von Absender- und Empfänger-Konto) das zuletzt auf dem Datenstrom ausgehendeUeberweisungen aufgetretene Element enthält. Zusätzlich zur Beschränkung der Größe eines Fensters auf einen Strom sieht CQL auch noch die optionale Möglichkeit vor, Fenster durch zufälliges Abtasten (sampling) zu befüllen anstatt den gesamten Datenstrom zu verwenden. Dazu wird zusätzlich der Operator Sample(N) anfügt. Der ganzzahlige Wert N legt fest, mit welcher Wahrscheinlichkeit ein Wertepaar in das Fenster aufgenommen wird. [Range 1000] Sample(50) definiert beispielsweise ein Fenster mit 1000 Wertepaaren, wobei im Durchschnitt nur jedes zweite Wertepaar, daß im Datenstrom auftritt, auch tatsächlich in das Fenster aufgenommen wird. Der Rest wird verworfen. [MWA+03] 3.1.2 Relation-zu-Strom-Operatoren In CQL werden drei verschiedene Relation-zu-Strom-Operatoren definiert: • Istream: Erzeugt einen input stream, d.h. die Folge aller Wertepaare, die zu einer Relation hinzugefügt werden, wobei der Zeitstempel des Wertepaares innerhalb des Istream dem Zeitpunkt entspricht, an dem das Wertepaar zur Relation zugefügt wurde. • Dstream: Erzeugt einen delete stream, d.h. die Folge aller Wertepaare, die aus einer Relation entfernt werden, wobei der Zeitstempel des Wertepaares innerhalb des Dstream dem Zeitpunkt entspricht, ab dem das Wertepaar nicht mehr zur Relation gehörte. • Rstream: Erzeugt einen relation stream, der zu jedem Zeitpunkt alle in einer Relation befindlichen Wertepaare enthält, d.h. alle Wertepaare, die zu einem bestimmten Zeitpunkt in der Relation vorkommen, treten mit dem entsprechenden Zeitstempel im Rstream auf. Wie man an den Definitionen erkennen kann, lassen sich sowohl Istream als auch Dstream durch Kombinationen von Rstream und zeitbasierten Fenstern sowie relationalen Operatoren ausdrücken. Im Vordergrund steht bei CQL und STREAM aber die Einfachheit der Sprache, weshalb die Funktionen direkt zugänglich gemacht wurden. [ABW03] Seite 9 3.1.3 Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Beispiel-Anfragen Select Istream(*) From ausgehendeUeberweisungen [Range Unbounded] Where Betrag>15000 Diese Anfrage besteht aus drei Operatoren: einem zeitbasierten Fenster (Strom-zu-RelationOperator), das alle bis zum jeweils gültigen Zeitstempel in ausgehendeUeberweisungen vorgekommenen Wertepaare liefert, die allerdings durch den zum Relation-zu-Relation-Operator SELECT gehörenden Prädikat Betrag>15000 auf die Überweisungen mit einem Betrag größer 15000 eingeschränkt werden. Das Ergebnis der Anfrage wird über den Relation-zu-StromOperator Istream(*) kontinuierlich ausgegeben, d.h. bei Auftauchen einer Überweisung über diesem Grenzbetrag wird das entsprechende Wertepaar an den Ausgangsstrom geschickt. Das gleiche Verhalten kann aber auch mit folgender Anfrage erreicht werden: Select Rstream(*) From ausgehendeUeberweisungen [Now] Where Betrag>15000 Auch hier sind wieder drei Operatoren enthalten: aus dem Datenstrom der ausgehendenUeberweisungen werden wieder diejenigen ausgewählt, deren Wertepaare beim Attribut Betrag einen Wert über dem Grenzwert 15000 haben. Der Strom-zu-Relation-Operator [Now] beschränkt die Wertepaare allerdings zuvor in Form eines zeitbasierten Fensters auf die Wertepaare mit dem gerade gültigen Zeitstempel. Das Ergebnis wird als Rstream ausgegeben, d.h. es werden alle gerade auftretenden Überweisungen mit Betrag oberhalb des Grenzwertes ausgegeben. 3.2 Vereinfachungen und Standardwerte Wie beim vorhergehenden Beispiel gezeigt wurde, kann man in CQL mit unterschiedlichen Definitionen das gleiche Anfrageergebnis erhalten, indem man bestimmte Operatoren durch Kombinationen von anderen Operatoren ersetzt. Neben den Auswirkungen auf die Optimierung von Anfrageplänen, die dies haben kann und die zu einem späteren Zeitpunkt noch beschrieben werden, ermöglicht diese Eigenschaft von CQL eine möglichst intuitive Anfrageformulierung. CQL bietet darüber hinaus weitere Vereinfachungen durch sog. shortcuts und die Verwendung von Standardwerten, wenn kein Wert angegeben wird. So kann auf die explizite Aufführung von Fensterdefinitionen und Relation-zu-Strom-Operatoren in bestimmten Situationen verzichtet werden. [ABW03] Das zuvor bereits in zwei verschiedenen Varianten beschriebene Anfragebeispiel kann vereinfacht auch wie folgt geschrieben werden: Select * From ausgehendeUeberweisungen Where Betrag>150000 Wird in CQL ein Datenstrom referenziert, wie es im Beispiel bei ausgehendeUeberweisungen der Fall ist, wird standardmäßig ein unbegrenztes Fenster angenommen, weil dies der häufigste Anwendungsfall ist. Da die meisten kontinuierlichen Anfragen, wie auch im Beispiel, einen Datenstrom als Ausgabe erwarten, wird standardmäßig der Istream-Operator angewendet. Auch bei Unter-Anfragen wird für die weitere Verarbeitung in den meisten Fällen ein den üblichen Datenströmen entsprechendes montones Verhalten erwartet und deshalb der Istream-Operator als Standard verwendet. Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager 4 Seite 10 DSMS-Konzepte in STREAM In den vorhergehenden Kapiteln wurden die grundlegenden Begriffe aus der Welt der DatenstromManagement-Systeme aus Sicht des STREAM-Projektes erklärt und die für STREAM geschaffene Anfragesprache CQL vorgestellt. Dieses Kapitel soll nun einen tieferen Einblick in den inneren Aufbau von STREAM und die von STREAM implementierten Konzepte geben. 4.1 Anfrageplanung und -ausführung Wie auch bei Datenbank-Management-Systemen werden Anfragen in STREAM vom Benutzer in einer abstrakten Sprache definiert. Das System muß sich für die Ausführung der Anfrage selbst darum kümmern, einen entsprechenden Anfrageplan zu erstellen. Dieser wird zusammengesetzt aus den internen Operatoren, die die tatsächliche Verarbeitung übernehmen, sowie aus Warteschlangen, die Wertepaare oder Referenzen darauf zwischenspeichern, und Zustandsspeichern (sog. synopses). Am Ende ruft ein Scheduler die einzelnen Operatoren auf und übernimmt damit die Kontrolle über die Ausführung des Planes. [ABW03, ABB+04] 4.1.1 Komponenten der Anfragepläne Operatoren Die im zugrundeliegenden sprachlichen Modell vorgenommene Unterscheidung zwischen Datenströmen und Relationen wird bei der internen Verarbeitung von STREAM so nicht mehr vorgenommen. Stattdessen werden beide Typen als Sequenz von Wertepaaren implementiert, wobei jedes Wertepaar neben einem Zeitstempel auch noch über eine Markierung verfügt die anzeigt, ob das Wertepaar hinzugefügt (+) oder entfernt (-) wurde. Die Tripel (Wertepaar, Zeitstempel, Markierung) werden als Elemente bezeichnet. Bei Datenströmen wird es natürlich ausschließlich Elemente mit +-Markierungen geben, da nur neue Elemente auf den Strom gelangen können, aber deren Auftreten dort nicht rückwirkend rückgängig gemacht werden kann. Bei Relationen dagegen können beide Marker auftreten und so die Veränderungen der Relation über die Zeit dokumentieren. Elemente werden grundsätzlich in Warteschlangen gespeichert. Die Operatoren nehmen eine oder mehrere dieser Warteschlangen als Eingabe, verarbeiten sie und geben die Ergebnisse an eine andere Warteschlange aus. Einige Operatoren speichern relationale Ergebnisse in Zustandsspeichern zwischen, z.B. wenn Joins berechnet werden sollen, oder den Inhalt eines Fensters. In Tabelle 1 sind die derzeit von STREAM für Anfragepläne implementierten Operatoren aufgeführt. Auffällig ist, daß sämtliche Fensterarten durch den gleichen Operator implementiert werden und es somit nur einen einzigen Strom-zu-Relation-Operator gibt. Warteschlangen Warteschlangen enthalten eine bestimmte Sequenz von Elementen, die einen Teil eines Datenstromes oder einer Relation darstellen. Im Rahmen der Anfrageplanung verbindet eine Warteschlange jeweils den Operator, der sie befüllt mit dem Operator, der sie als Eingang benutzt. Die Elemente, die im Laufe der Zeit eine Warteschlange durchlaufen, entsprechen dem Strom bzw. der Relation, die vom Eingangsoperator erzeugt werden. Zustandsspeicher Einige Operatoren benötigen die Möglichkeit, Zwischenergebnisse zu speichern. Dafür gibt es Zustandsspeicher, die jeweils genau einem Operator zugeordnet sind. Zu den Operatoren mit Zustandsspeicher gehören die Join-Operatoren, die beispielsweise alle Elemente der aktuellen Fenster zweier Eingangsdatenströme kennen müssen, um die vereinigte Relation ausgeben zu können. Dagegen brauchen Operatoren wie select keinen Zwischenspeicher, da sie Entscheidungen immer nur bezogen auf das gerade verarbeitete Element treffen. Seite 11 Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Name select project Typ des Operators Kurzbeschreibung Relation-zu-Relation Filtern von Elementen Relation-zu-Relation Projektion unter Beibehaltung von Duplikaten binary-join Relation-zu-Relation Join von zwei Eingabe-Relationen mjoin Relation-zu-Relation Mehrweg-Join union Relation-zu-Relation Mengen-Vereinigung except Relation-zu-Relation Mengen-Differenz intersection Relation-zu-Relation Schnittmenge antisemijoin Relation-zu-Relation Komplementärmenge aggregate Relation-zu-Relation Gruppierungen und Aggregationen duplicate-eliminate Relation-zu-Relation Entfernen von Duplikaten seq-window Strom-zu-Relation unterteilte, zeit- und anzahlbasierte Fenster i-stream Relation-zu-Strom Istream-Implementierung d-stream Relation-zu-Strom Dstream-Implementierung r-stream Relation-zu-Strom Rstream-Implementierung Tabelle 1: Operatoren in der Anfrageplanung [ABB+04] Beispiel Die nachfolgende Anfrage soll jeweils den Namen des Absenders und dessen Kontonummer für jede beim Zentralrechner innerhalb der vergangenen 14 Tage eingetroffene ausgehende Überweisung ausgeben, wenn der Betrag der Überweisung den Grenzbetrag von 15000 überschreitet und der Absender unter den letzten 1000 Eintragungen auf der Überwachungsliste vermerkt ist. Select Ueberwachungsliste.Name, ausgehendeUeberweisungen.AbsKontoID From ausgehendeUeberweisungen [Range 14 Days], Ueberwachungsliste [Rows 1000] Where ausgehendeUeberweisungen.Betrag>15000 And ausgehendeUeberweisungen.Absender = Ueberwachungsliste.Name Der Anfrageplan, wie er in STREAM aufgebaut sein könnte, wird in Abbildung 5 dargestellt. Ganz unten sind die beiden Datenströme ausgehendeUeberweisungen und Ueberwachungsliste als Eingänge dargestellt, die die beiden Warteschlangen W1 und W2 befüllen. Diese beiden Warteschlangen werden jeweils von einem "seq-window"-Operator als Eingänge benutzt, die den Zustand ihres Fensters, also die Menge der gerade zum Fenster gehörenden Elemente des Datenstromes am Eingang, in den Zustandsspeichern Z1 und Z2 speichern und jeweils die Warteschlange W3 und W4 befüllen, die die Eingänge des "binary-join"-Operators sind. Dieser speichert den Zustand beider Basisrelationen in den Zustandsspeichern Z3 und Z4 und befüllt seinerseits die Warteschlange W5 mit den Ergebnissen seiner Verarbeitung. W5 wird vom "select"-Operator als Eingang verwendet, der entsprechend den Filterkriterien die Ergebnisse seiner Arbeit in die Warteschlange W6 übergibt, die die Ausgabe der Anfrage darstellt. 4.1.2 Scheduling Wie bereits erwähnt wurde, übernimmt in STREAM ein Scheduler die Ausführung der Anfragepläne, d.h. er entscheidet, welcher Operator zu einem bestimmten Zeitpunkt arbeiten soll und ruft diesen dann auf. Grundsätzlich funktioniert dieser Scheduler also genauso wie Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Seite 12 Abbildung 5: Beispiel: Anfrageplan in STREAM ein Scheduler in Datenbank-Management-Systemen. Da das Ergebnis der Verarbeitung bei einem Operator nicht von einer Echtzeit abhängig ist, sondern nur von den Zeitstempeln der Elemente, wäre es prinzipiell unkritisch, in welcher zeitlichen Reihenfolge Operatoren abgearbeitet werden. Natürlich ist es aus anderen Gesichtspunkten wie Latenzzeiten und Ressourcenverwendung nicht unerheblich, welcher Operator zu einem bestimmten Zeitpunkt arbeitet. Nachfolgend werden deshalb kurz einige Scheduling-Algorithmen für DatenstromManagement-System vorgestellt, die beim STREAM-Projekt berücksichtigt wurden. [MWA+03, ABB+04, BBDM03] Round Robin: Round Robin ist einer der einfachsten Algorithmen. Jeder Operator kommt der Reihe nach einmal zur Ausführung, angefangen bei den Blattoperatoren. Wurde jeder Operator einmal ausgeführt, beginnt die Reihe von vorn. Dieser Algorithmus läßt sich einfach implementieren und nimmt zur Laufzeit keine wesentlichen Ressourcen in Anspruch. Dafür wird er nur in Ausnahmefällen die optimale Ausführungsreihenfolge treffen und ansonsten für die Verarbeitung in der Regel mehr Zeit und mehr Speicher verbrauchen, als andere Algorithmen. Hat ein bestimmter Operator beispielsweise gar keine neuen Elemente in seiner/seinen Eingangswarteschlange/n, so würde er trotzdem aufgerufen werden. Seite 13 Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager FIFO: FIFO bedeutet First In First Out. Dieser Algorithmus richtet sich also nach dem Eingang von neuen Elementen. Für diese wird der komplette Teilbaum bis zur Ausgabe abgearbeitet, bevor eventuell zwischenzeitlich eingetroffene weitere Elemente verarbeitet werden können. Auch dieser Algorithmus läßt sich verhältnismäßig einfach implementieren und weist bezogen auf das einzelne Element die kürzeste Verarbeitungszeit innerhalb des Systems auf. Betrachtet man allerdings mehrere Ströme mit regelmäßig eingehenden Elementen, so kann dieser Algorithmus ineffizient sein, weil er keine Rücksicht auf die Leistungsfähigkeit der einzelnen Operatoren nimmt und keine Zusammenhänge zwischen einzelnen Elementen oder verschiedenen Strömen beachtet, die eventuell Optimierungspotentiale bei der Verarbeitung bieten könnten. Greedy: Der Greedy-Algorithmus verdankt seinen Namen dem gleichnamigen Adjektiv, das gefräßig bedeutet. Er arbeitet nach dem Prinzip, stets Operatoren mit höherer Datenreduktionsrate bevorzugt auszuführen. Dazu wird die Selektivität einzelner Operatoren herangezogen. Unter Selektivität versteht man in diesem Zusammenhang ähnlich wie beim Sampling die Quote von Elementen, die nach der Verarbeitung durch den Operator innerhalb einer Zeiteinheit von einer gegebenen Anzahl am Eingang des Operators noch auf dessen Ausgangswarteschlange gelegt werden. Je geringer die Selektivität eines Operators ist, desto weniger Warteschlangenplätze sind nach seiner Ausführung belegt (bezogen auf das gesamte System) und desto höher ist demnach seine Datenreduktionsrate. Der Greedy-Algorithmus sucht deshalb nach Operatoren mit möglichst hoher Datenreduktionsrate und priorisiert die Ausführung entsprechend. Dieser Algorithmus bedarf zusätzlicher Informationen über die Selektivität der Operatoren. Er ist damit deutlich komplexer als Round Robin oder FIFO, sorgt aber in vielen Fällen für eine bessere Leistungsfähigkeit des Systems. Allerdings wird jeder Operator einzeln betrachtet und nicht etwaige Zusammenhänge zwischen Operatoren, etwa den Pfad, den bestimmte Elemente im Ausführungsplan notwendiger Weise gehen müssten, und auch nicht den Zustand einzelner Warteschlangen. Hat man beispielsweise eine Anfrage mit einer Summenbildung über alle Elemente eines Outer-Joins, der sich aus zwei anzahlbasierten Fenstern zusammensetzt, so ergibt sich folgendes Bild: Die Summenbildung hat niedrigste Selektivität (nahe 0), weil sie lediglich einen Wert ausgibt, egal wie viele Werte am Eingang stehen. Der Outer-Join hat sicherlich die höchste Selektivität: Für jedes eingehende Element produziert er genau soviele Ausgangselemente, wie das andere Fenster jeweils Elemente enthält. Die Fenster-Operatoren haben annähernd eine Selektivität von 1, weil sie in der Regel genausoviele Elemente ausgeben wie am Eingang anliegen, es sei denn, es kommen mehr Einträge mit gleichem Zeitstempel an, als in das Fenster hineinpassen. Entsprechend der Selektivität würde der Greedy-Algorithmus für das Scheduling zuerst den Aggregat-Operator ausführen, dann die Fenster-Operatoren und dann den Join-Operator. Tatsächlich ist der Aggregat-Operator jedoch darauf angewiesen, daß der Join-Operator seine Eingangswarteschlange befüllt hat, damit er überhaupt etwas verarbeiten kann. Es kann also passieren, daß sich FIFO in bestimmten Situationen als effizienter erweist, weil sich logisch geordnete Gruppen von Operatoren nicht gegenseitig blockieren. Im genannten Beispielablauf sind Elemente, die am Eingang des Blocks ankommen, innerhalb von 4 Zeiteinheiten (jeweils eine pro Fenster, eine für den Join und eine für die Aggregation) aus dem System verschwunden, d.h. der Block hat eine durchschnittliche Datenreduktion von 0.25. Im anderen Fall würde der Aggregat-Operator u.U. umsonst gestartet, wenn gar keine Elemente zur Verarbeitung vorliegen. Dadurch braucht es in diesen Fällen 5 Zeiteinheiten Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Seite 14 zur Verarbeitung, bis die Elemente in keiner Warteschlange mehr vorhanden sind. Je nach Kontinuität des eingehenden Stromes wird sich für die Datenreduktionsrate ein Wert zwischen 0.2 und 0.25 ergeben. Kämen regelmäßig zu jeder Zeiteinheit neue Elemente, würde nur zum initialen Start der Aggregat-Operator einmal umsonst aufgerufen und sonst wie bei FIFO immer etwas zu verarbeiten haben. Weist ein Datenstrom aber eher ein burstartiges Verhalten auf, d.h. kommen Elemente eher stoßweise auf einmal als gleichmäßig verteilt, könnten die Lücken zwischen den Bursts dazu führen, daß dies öfter vorkommt, während FIFO grundsätzlich eingangsgesteuert arbeitet. Chain: Der Chain-Algorithmus versucht den Nachteil von Greedy zu umgehen, indem zusammengehörige Operatoren-Gruppen zu sog. Blocks zusammengefaßt werden. Grundsätzlich wird dann wie bei FIFO immer der erste Operator im Plan ausgewählt. Anschließend wird analog zu Greedy der Block mit der höchsten Datenreduktionsrate gesucht, der sich an diesen Operator anschließt. Entsprechend diesem Muster werden alle Blöcke in die Ausführungsreihenfolge gebracht. Dieser Algorithmus versucht die Vorteile von FIFO und Greedy zu vereinen und die jeweiligen Nachteile zu minimieren. Entsprechend erhöht sich aber auch die Komplexität der Ausführung, denn es müssen sowohl die Zusammensetzung einzelner Blöcke bekannt sein, als auch ihre Selektivität. Beides kann sich jedoch zur Laufzeit auf Grund veränderter Anfragen oder Unregelmäßigkeiten bei den Datenströmen ändern. Geht man im Beispielszenario davon aus, daß bestimmte Großkunden ihre Überweisungen auch immer gesammelt an die Bank übergeben, so wird man z.B. einem Join-Operator, der diese Überweisungen mit der Überwachungsliste verknüpft, eine schwankende Selektivität haben: Ist der gerade Überweisungen übertragende Großkunde auf der Überwachungsliste, steigt die Selektivität sprunghaft an, ist er es nicht, sinkt sie ab. Würde man stets den Mittelwert annehmen, würde man weder derartige Bursts optimal verarbeiten, noch die anderen Teile des Stroms außerhalb solcher Bursts. Es wäre also vorteilhaft, wenn statistische Erhebungen permanent durchgeführt werden würden und entsprechend zu dynamischen Anpassungen beim Scheduling führen würden. Im Abschnitt 4.2.1 wird beschrieben, wie STREAM versucht diese Anforderung umzusetzen. 4.2 Ressourcen-Verwaltung Elemente von Datenströmen sind zunächst immer nur auf flüchtigen Speichern wie Kommunikationskanälen vorhanden. Zur Verarbeitung in einem DSMS werden sie in Warteschlangen und Zustandsspeichern festgehalten. Im Gegensatz zu den klassischen, persistent gespeicherten Relationen in DBMS wird bei STREAM derzeit aber noch nicht mit Sekundärspeicher gearbeitet. Das bedeutet, daß die zur Verfügung stehenden Speicherressourcen sehr begrenzt sind und diese je nach den Volumina, die auf den verschiedenen eingehenden Datenströmen transportiert werden, auch schnell erschöpft sein können, wenn komplexe und umfangreiche Anfragen, z.B. mit großen Joins, berechnet werden. Außerdem wächst auch der Anspruch an die Rechenleistung für die Verarbeitung der Elemente in den einzelnen Operatoren mit zunehmender Frequenz der Eingänge von Elementen auf den Datenströmen. Viele Anwendungen haben jedoch den Anspruch, Auswertungsergebnisse in Echtzeit zur Verfügung zu haben, was auch einer der Gründe war, bisher auf Einbindung von Sekundärspeicher zu verzichten. STREAM legt deshalb spezielles Augenmerk auf die Verwaltung der Systemressourcen, die noch mehr als bei DBMS von Bedeutung ist. Seite 15 4.2.1 Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Anfrageoptimierung Da CQL eine Erweiterung von SQL darstellt, können viele Mechanismen der Optimierung von rein relationalen Anfragen mit keinem oder verhältnismäßig geringem Anpassungsaufwand übernommen werden. Durch die Möglichkeit, gleiches Verhalten unterschiedlich zu beschreiben, ergeben sich durch äquivalente Umformungen oft Möglichkeiten, die Anfrage aus Sicht des Systems optimiert umzuformulieren. So können beispielsweise Heuristiken wie Selections below Joins“ verwendet werden, um schon vor dem tatsächlichen Scheduling ” Optimierungen bezüglich des zu erwartenden Aufwands für die Verarbeitung einer Anfrage vorzunehmen. Ausserdem ist es häufig möglich, Zustandsspeicher innerhalb eines Anfrageplans nicht immer exklusiv von einem Operator nutzen zu lassen, sondern bei entsprechender Eignung mehrere Operatoren gemeinsam darauf zugreifen zu lassen. [ABW03] Da sich der Zustand des Systems insgesamt ständig ändern kann, wenn beispielsweise neue Anfragen gestellt werden oder bereits bestehende gelöscht oder verändert werden, gibt es in STREAM neben dem Optimierer, der die Pläne entsprechend der verschiedenen Regeln untersucht und umschreibt, auch Monitore, die Veränderungen am System und der Systemumgebung feststellen. Überwacht werden speziell Speicherbedarf und -verfügbarkeit für einzelne Anfragen, Durchsatz von Datenströmen sowie statistische Eigenschaften von Datenströmen, die zum Beispiel für die Bestimmung der Selektivität von Operatoren und damit für das Scheduling ausschlaggebend sind. Die Infrastruktur dazu nennt sich StreaMon. Sie verfügt über drei unterschiedliche Komponenten [ABB+04]: • einen Executor, der Anfragepläne entgegennimmt, diese ausführt und die Ergebnisse zurückliefert • einen Profiler, der Eigenschaften von Datenströmen und Anfrageplänen ermittelt • einen Reoptimizer, der Anfragepläne und Speicherverwaltung optimiert 4.2.2 Redundanz-Minimierung Wie schon im Zusammenhang mit der Anfrageoptimierung angedeutet, gibt es verschiedene Punkte, an denen Redundanzen im Anfrageplan auftreten können. Dies kann bereits innerhalb einer einzelnen Anfrage der Fall sein. Aber speziell bei der Betrachtung aller Anfragen, die gerade an das System gestellt werden, können weitere Redundanzen auftreten, beispielsweise wenn in zwei Anfragen das gleiche Fenster auf einen Datenstrom definiert ist. Im Beispiel aus Abbildung 5 könnte der binary-join Operator beispielsweise die Zustandsspeicher Z1 und Z2 mit nutzen, weil diese den gleichen Inhalt wie die ihm direkt zugeordneten Zustandsspeicher Z3 und Z4 haben. Da Operatoren aber nicht zum gleichen Zeitpunkt auf den Zustandsspeicher zugreifen, kann es passieren, daß es Elemente gibt, die von einem Operator schon verarbeitet wurden, vom anderen aber noch nicht. STREAM löst dieses Problem, indem der eigentliche Speicherort der Elemente eines Zustandsspeichers von dessen Zugriffseinheit getrennt wird. Der Zustandsspeicher selbst wird als sog. stub implementiert, der mit einem store (Speicher) verknüpft ist, der die Elemente tatsächlich enthält. Der Speicher hält dabei die Informationen über den Zustand der einzelnen Stubs und liefert ihnen zu jedem Zeitpunkt einen korrekten View auf die Menge der Elemente. Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Seite 16 Beispiel Zum Anfrageplan vom Beispiel aus Abschnitt 4.1.1, das in Abbildung 5 dargestellt ist, wird nun folgende Anfrage hinzugefügt: Select AbsKontoID, SUM(Betrag) From ausgehendeUeberweisungen [Range 14 Days] Sie soll zu jedem Konto die Summe der Beträge der Überweisungen der letzten 14 Tage ermitteln. Da das Fenster auf den Datenstrom ausgehendeUeberweisungen das gleiche ist, wie bei der ersten Anfrage, könnte hier der Speicher gemeinsam genutzt werden. Abbildung 6 zeigt, wie der Anfrageplan mit der Nutzung von Stubs und gemeinsam genutztem Speicher aussieht. Man kann leicht erkennen, daß Speicher 1 von drei Operatoren über deren Stubs genutzt wird. Abbildung 6: Beispiel: optmierter Anfrageplan in STREAM 4.2.3 Nutzung von Einschränkungen Viele Datenströme unterliegen Einschränkungen (constraints) bezüglich des Auftretens von bestimmten Elementen. So gibt es Anwendungsgebiete, in denen Elemente immer in bestimmten Abhängigkeiten von einander oder in periodisch wiederkehrenden Mustern auftreten. Wenn solche Einschränkungen bekannt sind, könnte man bei verschiedenen Anfragen unter Umständen auf bestimmte Informationen in den Zustandsspeichern verzichten und so Speicherplatz und Rechenzeit sparen. STREAM bietet Möglichkeiten, Constraints entweder gleich mit der Anbindung eines Datenstroms zu definieren oder auf Basis statistischer Methoden zur Laufzeit ermitteln zu lassen. Seite 17 Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Beispiel Die Kommunikation mit anderen Banken erfolgt in vielen Fällen über sog. Batchläufe, d.h. Überweisungen werden zunächst auf einem eigenen Server zwischengelagert und dann zu bestimmten Zeiten alle auf einmal an einen Server einer anderen Bank übermittelt, wobei stets nur eine Bank zur selben Zeit angebunden wird. Für das Beispiel wird angenommen, daß jede Bank nur einen Batchlauf pro Tag ausführt, dessen Datenübertragung bis zu 5 Minuten dauert. Folgende Anfrage summiert die Beträge aller eingehendenUeberweisungen pro Absenderkonto im Zeitraum der vergangenen 5 Minuten und gibt Kontonummer und Summe der Beträge aus, wenn der Grenzwert von 15000 überschritten wird. Select AbsKontoID, Sum(Betrag) From eingehendeUeberweisungen [Range 5 Minutes] Group By AbsKontoID Having Sum(Betrag) > 15000 Betrachtet man die bekannte Einschränkung, daß ein bestimmtes Absenderkonto nur im Rahmen des Batchlaufes der zugehörigen Bank auf dem Strom auftaucht, kann der entsprechende Eintrag eigentlich schon aus dem Fenster entfernt werden, sobald eine Überweisung mit einer anderen Absenderbankleitzahl auf dem Datenstrom entdeckt wurde. Somit müssen für die Batchläufe anderer Banken, die danach stattfinden, keine weiteren Einträge der vorhergehenden Bank gespeichert werden. Das reduziert den Speicherbedarf für das zeitbasierte Fenster auf eingehendeUeberweisungen, wenn die einzelnen Batchläufe im weniger als 5 Minuten lang sind, wovon im Regelfall auszugehen wäre. 4.3 Näherungsverfahren Besonders bei langlebigen Anfragen können sich Eigenschaften von Datenströmen ändern, so daß bestimmte Annahmen, die zum Zeitpunkt der Erstellung getroffen wurden, nicht mehr gelten. Die in Abschnitt 4.2.1 beschriebenen Möglichkeiten, Anfragen nicht nur bei der ersten Planerstellung, sondern auch dynamisch zu optimieren, reichen hier nicht in allen Fällen aus. Es kann trotzdem dazu kommen, daß Datenströme aufgrund einer besonders hohen Datenrate entweder die CPU oder den Speicher überlasten. Hierführ gibt es in STREAM zwei Arten von Näherungsverfahren [ABB+04]: Annäherung bei CPU-Überlastung: Da häufig nicht vorhersehbar ist, wie lange die Überlastung anhalten wird, viele Anwendungen aber Echtzeitanforderungen haben oder zumindestens den Anspruch, in angemessener Zeit“ Ergebnisse zu bekommen, setzt STREAM ” ein Verfahren namens load-shedding ein. Load-shedding ( Last-Abwurf“ als Analogie zum ” Ballonfahren) bedeutet, daß in Abhängigkeit von der Überlastsituation nur noch Teile eines Datenstroms zur Verarbeitung herangezogen werden. Zunächst wird ermittelt, in welchem Bereich die geringsten Abweichungen durch das Ignorieren von Elementen zu erwarten sind. Ist dort noch kein Sampling-Operator gesetzt, wird dieser automatisch intern eingefügt, ansonsten wird der Wert für das Sampling angepaßt. Dieser Vorgang wird wiederholt, bis die Überlast bewältigt ist. Sollten die Überwachungsmechanismen nach einer Weile ein Absinken der Datenrate feststellen, wird die Rate der verworfenen Elemente schrittweise auf den Ausgangswert zurück gesetzt. Annäherung bei Speicher-Überlastung: Wenn es viele, sehr komplexe Anfragen gibt oder Anfragen mit zeitbegrenzten Fenstern bei hoher Datenrate, dann kann der Primärspeicher zu voll werden, um noch alle neuen Elemente bei Beibehaltung der notwendigen alten Elemente aufnehmen zu können. Auslagerungsvorgänge sind aus Leistungsgründen meist Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Seite 18 nicht praktikabel. STREAM arbeitet hier ähnlich wie bei CPU-Überlastung, nur werden keine Werte direkt verworfen. Stattdessen werden Anpassungen an Fenstergrößen vorgenommen, um die Größe der Zwischenspeicher gezielt zu reduzieren. 5 Zusammenfassung und Ausblick In den vorangegangenen Kapiteln wurde STREAM als ein Vertreter der Datenstrom-Management-Systeme vorgestellt. Dabei wurde zunächst erläutert, welche Zielstellungen das Projekt verfolgt, wie das System eingesetzt werden soll und wie sich darauf ausgerichtet die Begriffe aus der Welt der DSMS definieren. Ein wichtiges Ziel wurde mit der danach vorgestellten Anfragesprache CQL erreicht - eine möglichst einfache und intuitive Möglichkeit für Benutzer, Anfragen zu definieren. Nach der Vorstellung der einzelnen Sprachelemente wurde deren Implementierung im System beschrieben. Neben der reinen Sprachumsetzung verfügt STREAM über viele für die generische Verarbeitung von Datenströmen wichtige Mechanismen, wobei sich zeigt, daß STREAM den Schwerpunkt auf eine hohe Leistungsfähigkeit des Systems gesetzt hat. Die entsprechenden Konzepte zur Ressourcenverwaltung und zur dynamischen Anpassung des Systems wurden abschließend beschrieben. Die Ziele des Projektes für die Zukunft gehen größtenteils in eine andere Richtung: Neben Verbesserungen bei den Näherungsverfahren zur Überlastbewältigung sind vor allem Möglichkeiten zur verteilten Verarbeitung von Datenströmen, Publish-Subscriber-Verfahren zur Optimierung der Ergebnisrückführung, sowie Wiederherstellungsmechanismen nach einem Systemabsturz, die Garantien analog zu den von Datenbank-Management-Systemen bekannten ACID-Bedingungen der Transaktionsverarbeitung ermöglichen sollen. Seite 19 6 Udo Werner, Thema 7: STREAM: The Stanford Stream Data Manager Abkürzungen ACID Atomicity, Consistency, Isolation, Durability CQL Continuous Query Language DBMS Datenbank-Management-System DSMS Datenstrom-Management-System SQL Structured Query Language STREAM Stanford Stream Data Manager Literaturverzeichnis [ABB+03] Arvind Arasu, Brian Babcock, Shivnath Babu, Mayur Datar, Keith Ito, Rajeev Motwani, Itaru Nishizawa, Utkarsh Srivastava, Dilys Thomas, Rohit Varma, und Jennifer Widom. STREAM: The Stanford Stream Data Manager. IEEE Data Eng. Bull., 26(1): Seiten 19-26, 2003. [ABB+04] A. Arasu, B. Babcock, S. Babu, J. Cieslewicz, M. Datar, K. Ito, R. Motwani, U. Srivastava, J. Widom. STREAM: The Stanford Data Stream Management System. Erscheint in M. Garofalakis, J. Gehrke, and R. Rastogi, editors, Data Stream Management: Processing High-Speed Data Streams, Springer-Verlag, 2004. [ABW03] Arasu, Arvind; Babu, Shivnath; Widom, Jennifer. The CQL Continuous Query Language: Semantic Foundations and Query Execution. Technical Report, The Stanford University Database Group, 2003, URL: http://dbpubs.stanford.edu/pub/2003-67 . [BBDM03] Babcock, Brian; Babu, Shivnath; Datar, Mayur; Motwani, Rajeev. Chain: Operator Scheduling for Memory Minimization in Data Stream Systems, Proc. of the ACM Intl Conf. on Management of Data (SIGMOD 2003) [GTO03] Lukasz Golab und M. Tamer Ozsu. Issues in Data Stream Management. In SIGMOD Record, Volume 32, Number 2, Juni 2003, Seiten 5-14. [GOL03] Lukasz Golab. Querying Sliding Windows over On-Line Data Streams. Proc. ICDE/EDBT Ph.D. Workshop, Seiten 1-10, März 2004. [MWA+03] Rajeev Motwani, Jennifer Widom, Arvind Arasu, Brian Babcock, Shivnath Babu, Mayur Datar, Gurmeet Singh Manku, Chris Olston, Justin Rosenstein, und Rohit Varma. Query processing, approximation, and resource management in a data stream management system. In CIDR, 2003.
