StreamInsight-Serverkonzepte

In diesem Thema wird beschrieben, wie Daten in Bezug auf den StreamInsight-Server dargestellt, verarbeitet, eingefügt und übertragen werden. Nach Abschluss dieses Themas sollten Sie mit den grundlegenden Konzepten der komplexen Ereignisverarbeitung in Microsoft StreamInsight vertraut sein. Zunächst werden Datenstrukturen und anschließend die StreamInsight-Serverkomponenten beschrieben, die auf die Daten reagieren oder diese verarbeiten.

Datenströme

Alle Daten in StreamInsight sind in Datenströmen organisiert. Jeder Datenstrom beschreibt eine potenziell endlose Auflistung von Daten, die sich im Laufe der Zeit ändern. Zum Beispiel stellt ein Börsentickerdatenstrom die Preise verschiedener Aktien bereit, die an einer Börse gehandelt werden und sich im Laufe der Zeit ändern. Ein weiteres Beispiel wäre ein Temperatursensordatenstrom, der vom Sensor gemeldete Temperaturwerte bereitstellt, die sich im Laufe der Zeit ändern.

Gehen wir einmal von einem Energieüberwachungsszenario aus, bei dem Energiemessgeräte überwacht werden, die die Leistungsaufnahme verschiedener Geräte messen. In regelmäßigen Abständen senden diese Energiemessgeräte Daten, die ihre Leistungsaufnahme in Wattzehnteln und einen zugeordneten Zeitstempel für das Ablesen enthalten. In der folgenden Tabelle werden die Energiemessgeräte-Ablesungen 3 Messgeräten gezeigt und angenommen, dass jedes Energiemessgerät eine Energieablesung pro Sekunde aussendet.

Da diese Informationen als Werte dargestellt werden können, die sich im Zeitverlauf ändern, können die Daten in einem Datenstrom dargestellt werden. Angesichts der Daten in diesem Datenstrom kann eine Abfrage für diesen Datenstrom das Messgerät mit dem höchsten oder niedrigsten Verbrauch im Verlauf eines bestimmten Zeitraums zurückgeben, oder das Messgerät gibt eine Liste der 10 Messgeräte mit der höchsten Leistungsaufnahme im Zeitverlauf zurück.

Ereignisse

Die zugrunde liegenden, im Datenstrom dargestellten Daten werden in Ereignisse verpackt. Ein Ereignis ist die grundlegende Einheit von Daten, die vom StreamInsight-Server verarbeitet wird. Jedes Ereignis besteht aus den folgenden Elementen:

• Header. Ein Ereignisheader enthält Metadaten, die die Ereignisart und einen oder mehrere Zeitstempel definieren, die das Zeitintervall für das Ereignis definieren. Die Zeitstempel sind anwendungsbasiert und werden von Datenquelle bereitgestellt. Sie stellen keine vom StreamInsight-Server bereitgestellte Systemzeit dar. Beachten Sie, dass die Zeitstempel den DateTimeOffset-Datentyp verwenden, der zeitzonensensibel ist und auf dem 24-Stunden-Format basiert. Der StreamInsight-Server normalisiert alle Zeiten zu UTC und überprüft bei Eingabe, ob das UTC-Flag in den Zeitstempelfeldern festgelegt ist.

• Nutzlast. Eine .NET-Datenstruktur, die die dem Ereignis zugeordneten Daten enthält. Die in der Nutzlast definierten Felder sind benutzerdefiniert. Ihre Typen basieren auf dem .NET-Typsystem.

Ereignisse im Datenstrom, deren Anwendungszeitstempel der Reihenfolge des Eingangs in die Abfrage entsprechen, sind geordnet. Ist dies nicht der Fall, gehen die Ereignisse ungeordnet ein. Der StreamInsight-Server garantiert, dass bei Eingang von Ereignissen außerhalb der Reihenfolge die Ausgabe der Abfrage dem Eingang der Ereignisse in Reihenfolge entspricht, es sei denn, der Abfrageschreiber gibt ausdrücklich etwas anderes an. Innerhalb eines Datenstroms sind typische Ereigniseingangsmuster:

• Eine gleichbleibende Rate, z. B. Datensätze aus Dateien oder Tabellen

• Eine periodische und zufällige Rate, z. B. Daten aus einem Einzelhandels-Barcodescanner.

• Eine periodische Rate mit abrupten Bursts, z. B. Webklicks oder Wettertelemetriedaten.

Ereignisheader

Der Header eines Ereignisses definiert die Ereignisart sowie die temporären Eigenschaften des Ereignisses.

Ereignisart

Die Ereignisart gibt an, ob das Ereignis ein neues Ereignis im Datenstrom ist, oder ob es die Vollständigkeit der vorhandenen Ereignisse im Datenstrom deklariert. StreamInsight unterstützt zwei Ereignisarten: INSERT und CTI (aktuelles Zeitinkrement).

Die INSERT-Ereignisart fügt dem Ereignisdatenstrom ein Ereignis mit seiner Nutzlast hinzu. Zusätzlich zur Nutzlast identifiziert der Header des INSERT-Ereignisses die Start- und Endzeit für das Ereignis. Das folgende Diagramm zeigt das Layout einer INSERT-Ereignisart an.

Die CTI-Ereignisart ist ein besonderes Interpunktionsereignis, das die Vollständigkeit der vorhandenen Ereignisse im Datenstrom angibt. Die CTI-Ereignisstruktur besteht aus einem einzelnen Feld, das einen aktuellen Zeitstempel bereitstellt. Ein CTI-Ereignis dient zwei Zwecken:

1. Zunächst aktiviert es eine Abfrage, um Ereignisse zu akzeptieren und zu verarbeiten, deren Anwendungszeitstempel nicht der Reihenfolge ihres Eingangs in die Abfrage entsprechen. Bei der Ausgabe eines CTI-Ereignisse zeigt es dem StreamInsight-Server an, dass keine nachfolgenden eingehenden INSERT-Ereignisse den Ereignisverlauf vor dem CTI-Zeitstempel überarbeiten. Das heißt, nachdem ein CTI-Ereignis ausgegeben wurde, kann kein INSERT-Ereignis über eine Startzeit verfügen, die früher ist als der Zeitstempel des CTI-Ereignisses. Durch diese Angabe der Vollständigkeit eines Datenstroms von Ereignissen kann der StreamInsight-Server die Ergebnisse der Fensterfunktionen oder anderer aggregierender Operatoren freigeben, die Status gesammelt haben, und so die effiziente Verarbeitung von Ereignissen durch das System sicherstellen.

2. Der zweite Zweck von CTI-Ereignissen ist, die Wartezeit der Abfrage niedrig zu halten. Häufig auftretende CTIs führen dazu, dass die Abfrage die Ergebnisse mit einer höheren Frequenz ausgibt.

Wichtig
Ohne im Eingabedatenstrom vorhandene CTI-Ereignisse wird von der Abfrage keine Ausgabe erstellt.

Weitere Informationen finden Sie unter Vorlauf der Anwendungszeit.

Das folgende Diagramm zeigt das Layout einer CTI-Ereignisart.

Ereignismodelle

Das Ereignismodell definiert die Form des Ereignisses auf der Grundlage der temporären Eigenschaften. StreamInsight unterstützt drei Ereignismodelle: Intervall, Punkt und Edge. Intervallereignisse können als der meiste generische Typ angesehen werden, von dem Rand und Punkt Spezialfälle sind.

Intervall

Das Intervallereignismodell stellt ein Ereignis dar, dessen Nutzlast für einen angegebenen Zeitraum gültig ist. Das Intervallereignismodell setzt voraus, dass sowohl die Start- als auch die Endzeit des Ereignisses in den Ereignismetadaten bereitgestellt wird. Intervallereignisse sind nur für dieses bestimmte Zeitintervall gültig. Es ist wichtig zu beachten, dass hinsichtlich der Gültigkeit der Nutzlast des Ereignisses Startzeiten eingeschlossen, Endzeiten dagegen ausgeschlossen werden.

Das folgende Diagramm zeigt das Layout eines Intervallereignismodells.

Beispiele für Intervallereignisse sind die Breite eines elektronischen Impulses, die Dauer (Gültigkeit) eines Auktionsgebots oder eine Börsentickeraktivität, in der das Gebot für eine Aktie für einen bestimmten Zeitraum gültig ist. Im Beispiel für die Energieüberwachung, das an früherer Stelle beschrieben wurde, kann der Energiemessgerät-Ereignisdatenstrom mittels der folgenden Intervallereignisse dargestellt werden.

Punkt

Das Punktereignismodell stellt ein Ereignisvorkommen als einzelnen Zeitpunkt dar. Das Punktereignismodell benötigt nur die Startzeit für das Ereignis. Der StreamInsight-Server leitet die gültige Endzeit ab, indem er der Startzeit (der kleinsten Zeiteinheit im zugrunde liegenden Zeitdatentyp) einen Takt hinzufügt, um das gültige Zeitintervall für das Ereignis festzulegen. Da Ereignisendzeiten ausgeschlossen werden, sind Punktereignisse sind nur für die einzelne Instanz ihrer Startzeit gültig.

Das folgende Diagramm zeigt das Layout eines Punktereignismodells.

Beispiele für Punktereignisse sind die Messgerätablesung, der Eingang einer E-Mail, ein Klick im Web durch einen Benutzer, ein Börsenticker oder ein Eintrag in das Windows-Ereignisprotokoll. Im Beispiel für die Energieüberwachung, das an früherer Stelle beschrieben wurde, kann der Energiemessgerät-Ereignisdatenstrom mittels der folgenden Punktereignisse dargestellt werden. Beachten Sie, dass die Endzeit als Startzeit plus 1 Takt (t) berechnet wird.

Edge

Ein Edge-Ereignismodell stellt ein Ereignisvorkommen dar, dessen Nutzlast für ein angegebenes Zeitintervall gültig ist; beim Eingang am StreamInsight-Server ist jedoch nur die Startzeit bekannt. Daher wird die Endzeit auf die maximale, in der Zukunft liegende Zeit festgelegt. Die tatsächliche Endzeit des Ereignisses wird später bekannt und aktualisiert. Das Edge-Ereignismodell enthält zwei Eigenschaften: die Zeit des Auftretens und einen Edge-Typ. Zusammen definieren diese Eigenschaften entweder den Start- oder den Endpunkt des Edge-Ereignisses. 

Das folgende Diagramm zeigt das Layout eines Edge-Ereignismodells.

Beispiele für Edge-Ereignisse sind Windows-Prozesse, Ablaufverfolgungsereignisse aus der Ereignisablaufverfolgung für Windows (Event Tracing for Windows, ETW), eine Webbenutzersitzung oder die Quantisierung eines analogen Signals. Das gültige Zeitintervall für die Nutzlast eines Edge-Ereignisses ist der Unterschied zwischen dem Zeitstempel des START-Ereignisses und dem Zeitstempel des END-Ereignisses. Beachten Sie im folgenden Diagramm, dass das Ereignis mit dem Nutzlastwert 'c' derzeit nicht über ein bekanntes Enddatum verfügt.

Die folgende Abbildung zeigt die Quantisierung eines analogen Signals mittels Edge-Ereignissen auf der Grundlage der in der Tabelle oben definierten Start- und Endzeiten. Ein kontinuierliches Signal wie dieses bedeutet, dass für jeden neuen Wert sowohl ein END- als auch ein START-Edge übermittelt werden muss. Die beschriebenen Edges in der Abbildung verweisen auf das Ereignis im Zeitraum zwischen t1 und t3.

Überlegungen zur Leistung im Hinblick auf die Wahl des Ereignismodells

Je nach Problemstellung muss das richtige Ereignismodell ausgewählt werden. Beispiel: Wenn Ereignisse für einen bestimmten Zeitraum vorhanden sind, und von der Anwendung sowohl Start- als auch Endzeit des Ereignisses festgelegt werden können, verwenden Sie zur Modellierung vorzugsweise Intervallereignisse. In einem Szenario, in dem bei Eingang des Ereignisses die Endzeit nicht bekannt ist, sollten Sie das Ereignis als Punktereignis modellieren, die Lebensdauer entsprechend verlängern und die Clip-Operation verwenden, um den Zeitpunkt im Lebenszyklus zu ändern, an dem das Ende des Ereignisses erkannt wird. Alternativ können Sie die Ereignisse als Edge-Ereignisse modellieren.

Edge-Ereignisse sind zwar ein sehr praktisches Ereignismodell, allerdings bestehen hier eine Reihe von leistungsbezogenen Implikationen, die Sie berücksichtigen sollten. Die Verarbeitung von Edge-Ereignissen funktioniert am besten, wenn die Ereignisse vollständig sortiert werden, d. h. alle Start-Edges werden bei der Startzeit und End-Edges bei der Endzeit sortiert, und die kombinierte Ereignissequenz wird ebenfalls entsprechend sortiert. Beispiel: Es liegt folgende Sequenz von Edge-Ereignissen vor:

Diese Sequenz ist für die Zeitstempel (1, 10, 3, 6, 5, 20) nicht sortiert. Da die Edge-Ereignisse nicht vollständig sortiert sind, wie etwa bei (1, 3, 5, 6, 10, 20), hat dies geringere Auswirkungen auf die Leistung bei der Abfrageverarbeitung. Diese von der Verarbeitung gefolgte Sortierung kann mühelos aktiviert werden. Verwenden Sie zur Problembehebung zwei Abfragen. Die erste Abfrage kann eine leere Abfrage sein, die Edge-Ereignisse als Eingabe empfängt, diese vollständig sortiert und als sortierte Edge-Ereignisse ausgibt. Von der zweiten Abfrage kann anhand dieser Eingabe die Hauptlogik durchgeführt werden. Die Definition sollte hierbei in Form zweier separater Abfragen erfolgen, anschließend in kombinierter Form anhand dynamischer Abfragezusammenstellung. Weitere Informationen finden Sie unter Erstellen von Abfragen zur Laufzeit.

Ereignisnutzlast

Die Nutzlast eines Ereignisses ist eine .NET-Datenstruktur, die die dem Ereignis zugeordneten Daten enthält. Die Felder in der Nutzlast sind benutzerdefiniert, und ihre Typen basieren auf dem .NET-Typsystem. Die meisten skalaren und elementaren CLR-Typen werden für Nutzlastfelder unterstützt. Geschachtelte Typen werden nicht unterstützt.

Adapter

Adapter übersetzen und übermitteln eingehende und ausgehende Ereignisdatenströme zu und vom StreamInsight-Server. StreamInsight stellt ein sehr flexibles Adapter-SDK bereit, mit dem Sie Adapter für die domänenspezifischen Ereignisquellen und Ausgabegeräte (Senken) erstellen können. Adapter sind in der C#-Programmiersprache implementiert und als Assemblys gespeichert. Die Adapterklassen werden zur Entwurfszeit als Vorlagen erstellt, auf dem StreamInsight-Server registriert und während der Laufzeit als Adapterinstanzen im Server instanziiert.

Eingabeadapter

Eine Eingabeadapterinstanz akzeptiert eingehende Ereignisdatenströme aus externen Quellen, beispielsweise Datenbanken, Dateien, Tickerfeeds, Netzwerkports oder Sensoren. Der Eingabeadapter liest die eingehenden Ereignisse in dem Format, in dem sie bereitgestellt werden, und wandelt diese Daten in das für den StreamInsight-Server geeignete Ereignisformat um.

Sie erstellen einen Eingabeadapter, um die spezifischen Ereignisquellen für die Datenquelle zu behandeln. Wenn die Ereignisquelle nur einen einzigen Ereignistyp erzeugt, kann der Adapter typisiert werden. Das heißt, er wird für die Ausgabe eines einzigen Ereignistyps implementiert. Mit einem typisierten Adapter erzeugen alle Instanzen des Adapters das gleiche feste Nutzlastformat, in dem die Anzahl der Felder und ihre Typen im Voraus bekannt sind. Beispiele für solche Ereignisse sind Tickerfeeddaten oder von einem bestimmten Gerät ausgegebene Sensordaten. Wenn die Ereignisquelle in verschiedenen Umständen unterschiedliche Typen ausgibt, d. h. wenn die Ereignisse möglicherweise verschiedene Nutzlastformate enthalten oder das Nutzlastformat möglicherweise nicht im Voraus bekannt ist, implementieren Sie einen nicht typisierten Adapter. Bei einem nicht typisierten (generischen) Adapter wird das Ereignisnutzlastformat dem Adapter bei der Abfragebindung als Teil einer Konfigurationsspezifikation bereitgestellt. Beispiele für solche Quellen sind CSV-Dateien, die eine veränderliche Anzahl von Feldern enthalten und für die der Typ der in der Datei gespeicherten Daten erst zum Zeitpunkt der Abfrageinstanziierung bekannt ist, oder ein Adapter für SQL Server-Tabellen, in denen die generierten Ereignisse vom Schema der Tabelle abhängig sind. Beachten Sie, dass eine einzelne Adapterinstanz zur Laufzeit immer Ereignisse eines bestimmten Typs ausgibt, unabhängig davon, ob sie typisiert oder nicht typisiert ist. Statt der Definition des Ereignistyps zum Zeitpunkt der Implementierung des Adapters, bieten nicht typisierte Adapter flexible Implementierung zur Annahme der Spezifikation des Ereignistyps zum Zeitpunkt der Abfragebindung.

Ausgabeadapter

Sie erstellen einen Ausgabeadapter, um die vom StreamInsight-Server verarbeiteten Ereignisse zu empfangen, die Ereignisse in ein vom Ausgabegerät (Senke) erwartetes Format zu übersetzen und die Daten an dieses Gerät auszugeben. Das Entwerfen und Erstellen eines Ausgabeadapters ist mit dem Entwerfen und Erstellen eines Eingabeadapters vergleichbar. Typisierte Ausgabeadapter werden für eine bestimmte Ereignisnutzlast entworfen, wohingegen nicht typisierte Ausgabeadapter erst zur Laufzeit mit dem Ereignistyp angegeben werden, wenn die Abfrage instanziiert wird.

Weitere Informationen finden Sie unter Erstellen von Eingabe- und Ausgabeadaptern. Die Kernadapter-API bietet maximale Flexibilität zur Implementierung für alle Ereignisquellen- oder senken. Zusätzlich werden von StreamInsight Ereignisquellen und -senken auf höherer Abstraktionsebene unterstützt, die die IObservable- oder IEnumerable-Schnittstellen implementieren. Weitere Informationen finden Sie unter Verwenden von Observable- und Enumerable-Ereignisquellen und -senken (StreamInsight).

Verarbeiten und Analysieren von Ereignissen

Mit StreamInsight wird die Ereignisverarbeitung auf der Grundlage der von Ihnen definierten Abfragelogik in Abfragen organisiert. Diese Abfragen akzeptieren einen potenziell unendlichen Feed zeitempfindlicher Eingabedaten (protokolliert oder Echtzeit), führen einige Berechnungen auf den Daten aus und geben das Ergebnis auf eine geeignete Weise aus.

Abfragevorlagen

Eine Abfragevorlage ist die wesentliche Einheit der Abfragekomposition. Sie ist die Struktur, die die erforderliche Geschäftslogik definiert, um vom Eingabeadapter an den StreamInsight-Server gesendete Ereignisse kontinuierlich zu analysieren und zu verarbeiten, und um einen Ereignisdatenstrom zu generieren, der vom Ausgabeadapter genutzt wird. Sie möchten z. B. eingehende Leistungsaufnahmeereignisse auf maximale oder minimale Werte im Verlauf eines bestimmten Zeitraums auswerten, die bestimmte, von Ihnen festgelegte Schwellenwerte überschreiten.

Abfragevorlagen können geschrieben werden, um bestimmte Arbeitseinheiten auszuführen, und dann zu komplexeren Abfragevorlagen zusammengestellt werden. Abfragevorlagen werden in LINQ in Verbindung mit der C#-Sprache geschrieben. LINQ ist eine Sprachplattform, die Ihnen ermöglicht, deklarative Berechnungen über Reihen auf eine Weise auszudrücken, die vollständig in die Hostsprache integriert ist. So haben Sie die Möglichkeit, die deklarative Verarbeitung von Ereignissen mit der Flexibilität von Verfahrensprogrammierung auf der gleichen Entwicklungsplattform zu kombinieren, ohne Impedanzkonflikte zwischen diesen beiden Programmierungsmodellen befürchten zu müssen.

Der StreamInsight-Server stellt die folgende Funktionalität bereit, um ausdrucksvolle Abfragen und Analysen zu schreiben:

• Berechnungen, um zusätzliche Ereigniseigenschaften einzuführen

  Anwendungsfälle wie Einheitenkonvertierungen erfordern es, Berechnungen auf den Ereignissen durchzuführen, die Sie empfangen. Mittels des Projektionsvorgangs auf dem StreamInsight-Server können Sie der Nutzlast weitere Felder hinzufügen und Berechnungen über die Felder im Eingabeereignis durchführen. Weitere Informationen finden Sie unter Projektion.

• Filtern von Ereignissen

  In bestimmten Anwendungsfällen, etwa bei Warnbenachrichtigungen, möchten Sie möglicherweise überprüfen, ob ein bestimmtes Nutzlastfeld die Betriebsschwellenwerte für die Ausrüstung überschreitet, die Sie überwachen. Im Allgemeinen ist nur eine Teilmenge von Ereignissen, die über bestimmte Eigenschaften verfügen, für diese Verwendungsfälle relevant. Ereignisse, die nicht über diese Eigenschaften verfügen, müssen nicht verarbeitet werden und können verworfen werden. Der Filtervorgang ermöglicht Ihnen den Ausdruck boolescher Prädikate über der Ereignisnutzlast und verwirft Ereignisse, die nicht über die Prädikate verfügen. Weitere Informationen finden Sie unter Filterung.

• Gruppieren von Ereignissen

  Betrachten Sie einen Ereignisdatenstrom, der Ihnen Temperaturablesungen aller Temperatursensoren zurückgibt. Wenn alle Ereignisse durch einen einzelnen Ereignisdatenstrom bereitgestellt werden, möchten Sie die eingehenden Ereignisse möglicherweise auf der Grundlage des Sensorspeicherorts oder der Sensor-ID partitionieren. Der StreamInsight-Server stellt einen Gruppierungsvorgang bereit, der Ihnen ermöglicht, den eingehenden Datenstrom auf der Grundlage von Ereigniseigenschaften wie dem Speicherort oder der ID zu partitionieren und dann andere Vorgänge anzuwenden oder Abfragefragmente für jede Gruppe getrennt abzuschließen. Weitere Informationen finden Sie unter Group/Apply. 

• Fenster im Zeitverlauf

  Das Gruppieren von Ereignissen im Zeitverlauf ist ein leistungsstarkes Konzept, das viele Szenarien ermöglicht. Sie möchten beispielsweise möglicherweise die Anzahl der Fehler überprüfen, die während eines festen Zeitraums auftreten, und ein Warnsignal auslösen, wenn diese einen Schwellenwert überschreiten. Springende und gleitende Fenster ermöglichen Ihnen, Fenster über den Ereignisdatenströmen zu definieren, um diese Art von Analyse auszuführen. Weitere Informationen finden Sie unter Verwenden von Ereignisfenstern.

• Aggregation

  Wenn Sie sich nicht um jedes einzelne Ereignis kümmern möchten, sollten Sie möglicherweise Aggregatwerte, z. B. Durchschnitt, Summe oder Anzahl, verwenden. Der StreamInsight-Server stellt integrierte Aggregationen für sum, count, min, max und average bereit, die in der Regel in Zeitfenstern ausgeführt werden. Weitere Informationen finden Sie unter Aggregationen.

• Identifizieren von TOP-N-Kandidaten

  Eine besondere Art von Aggregationsvorgang ist in Anwendungsfällen erforderlich, in denen Sie die Kandidatenereignisse identifizieren möchten, die gemäß einer bestimmten Metrik die höchsten Ränge in einem Ereignisdatenstrom einnehmen. Der TopK-Vorgang ermöglicht Ihnen, auf der Grundlage einer Reihenfolge nach diesen zu suchen, die Sie über den Ereignisfeldern im Datenstrom festlegen. Weitere Informationen finden Sie unter TopK.

• Finden einer Entsprechung für Ereignisse aus anderen Datenströmen

  Ein allgemeiner Verwendungsfall ist die Anforderung, Ereignisse zu analysieren, die aus mehreren Datenströmen empfangen werden. Da Ereignisquellen Zeitstempel in den Ereignisdaten bereitstellen, möchten Sie möglicherweise sicherstellen, dass Ereignisse in einem Datenstrom nur dann mit einem Ereignis in einem anderen Datenstrom verglichen werden, wenn sie zeitlich nahe beieinander liegen. Außerdem bestehen möglicherweise zusätzliche Einschränkungen, für welche Ereignisse nach Übereinstimmungen gesucht werden soll und wann dies erfolgen soll. Der StreamInsight-Server stellt eine leistungsstarke Joinoperation bereit, die beide Tasks ausführt: zunächst findet sie Übereinstimmungen von Ereignissen aus beiden Quellen, wenn sich die Zeiten überschneiden, und zweitens führt sie das in den Nutzlastfeldern angegebene Joinprädikat aus. Das Ergebnis einer solchen Übereinstimmung enthält sowohl die Nutzlasten des ersten als auch des zweiten Ereignisses. Weitere Informationen finden Sie unter Joins.

• Kombinieren von Ereignissen aus verschiedenen Datenströmen in einen Datenstrom

  Mehrere Datenquellen stellen möglicherweise Ereignisse des gleichen Typs bereit, den Sie in die gleiche Abfrage eingeben können. Die UNION-Operation, die durch den StreamInsight-Server bereitgestellt wird, ermöglicht Ihnen die Vereinigung mehrerer Eingabedatenströme in einen einzigen Ausgabedatenstrom. Weitere Informationen finden Sie unter Unions.

• Benutzerdefinierte Erweiterungen

  Die integrierte Abfragefunktionalität des StreamInsight-Servers ist möglicherweise nicht in allen Fällen ausreichend. Um domänenspezifische Erweiterungen zu berücksichtigen, können Abfragen auf dem StreamInsight-Server benutzerdefinierte Funktionen aufrufen, die über .NET-Assemblys bereitgestellt werden. Zusätzlich zu benutzerdefinierten Funktionen können Sie benutzerdefinierte Aggregationen oder Abfrageoperatoren definieren und implementieren. Weitere Informationen finden Sie unter Benutzerdefinierte Funktionen und Benutzerdefinierte Aggregate und Operatoren.

Weitere Informationen finden Sie unter Schreiben von Abfragevorlagen in LINQ. Eine detaillierte Anleitung zum Schreiben von LINQ-Abfragen für StreamInsight finden sie unter A Hitchhiker’s Guide to StreamInsight Queries.

Abfrageinstanzen

Beim Binden einer Abfragevorlage an bestimmte Eingabe- und Ausgabeadapter wird eine Abfrageinstanz im StreamInsight-Server registriert. Gebundene Abfragen können auf dem StreamInsight-Server gestartet, beendet und verwaltet werden. Sobald Daten über Eingabeadapter auf dem StreamInsight-Server eingegeben wurden, kann die Berechnung über die Daten kontinuierlich ausgeführt werden. Mit anderen Worten: Bei Eingang der einzelnen Ereignisse im Server werden diese Ereignisse von stehenden Abfragen verarbeitet, die Ausgabeereignisse als Reaktion auf den Eingang von Eingabeereignissen ausgeben. Die folgende Abbildung zeigt die StreamInsight-Abfragen und -Adapter zur Laufzeit. Der StreamInsight-Server nutzt und verarbeitet das Ereignis, wenn die Instanz des Eingabeadapters an eine Instanz einer Abfrage gebunden ist. Die verarbeiteten Daten werden dann zur Instanz des Ausgabeadapters geschoben, der an die gleiche Abfrageinstanz gebunden ist.

Siehe auch

Konzepte

StreamInsight-Serverarchitektur

StreamInsight-End-to-End-Beispiel