次の方法で共有

StreamInsight

  • [アーティクル]

Microsoft StreamInsight により大量データ ストリームを使いこなす

Rob Pierry

[コード サンプルのダウンロード](https://archive.msdn.microsoft.com/mag201106streaminsig)

製造ラインがダウンしている、ユーザーのメディア ストリームがスキップされる、製品の 1 つが "必須" になっているといったことは、既にそのような事象が発生してしまっていれば、見つけ出すのは簡単です。本当に難しいのは、このようなシナリオが発生した時点で特定したり、過去の傾向を基にこのようなシナリオを予測したりすることです。

このようなシナリオを正確に予測するには、ほぼリアルタイムのアプローチが必要です。関連データを抽出、変換し、SQL Server Analysis Services (SSAS) のような従来のビジネス インテリジェンス (BI) ソリューションに読み込む頃には、状況はとっくに変わってしまっています。同様に、要求 - 応答パターンを使用してトランザクション データ ストア (SQL Server Reporting Services (SSRS) レポートなど) から最新データを要求するシステムでは、要求とポーリングの間隔の最後近くの古いデータを常に操作しています。通常、ポーリング間隔は決まっているため、目的の動作が一気に発生しても、こうしたシステムは次のポーリング間隔になるまで認識しません。それどころか、関連条件が満たされた瞬間に連続的に通知が行われます。

新たに起こる傾向を検出するときは、時間間隔が重要です。つまり、過去 5 か月間にわたって規則的に少しずつ起きる傾向よりも、最後の 5 分間で特定の商品が 100 個購入されるといった事象の方が、新しく起きた傾向をより明らかに示していることは明白です。SSAS や SSRS のような従来のシステムでは、開発者がキューブの個々のディメンションや、トランザクション ストア内のタイムスタンプの列を利用して、各自のデータの時系列の状況を把握することが必要です。新しく事象が起こるシナリオを特定するツールは、時間の概念を持ち、その概念を操作する豊富な API が用意されているのが理想的です。

最終的には、将来を適切に示す指標は、過去を分析することから得られます。事実、これこそが従来の BI が目指すところです。つまり、大量の履歴データを集計および分析して、傾向を判断します。残念ながら、このようなシステムを使用している場合、トランザクションを多用するシステムと比べたら、さまざまなツールやクエリ言語が必要になります。新しい事象が起こるシナリオを正しく特定するには、過去と現在のデータのシームレスな関連付けが必要です。この種の緊密な関連付けは、過去と現在のデータ両方に、同じツールとクエリ言語を使用する場合のみ可能です。

製造ラインの監視などの特定のシナリオには、こうした機能の実行に特化したカスタム ツールが存在しますが、このようなツールは比較的高価で、汎用的ではないことがほとんどです。

製造ラインのダウンを防いだり、製品の価格が適宜設定されたりするためには、状況の変化に応じて特定および調整できるだ応答性を持つことが重要です。このようなシナリオを簡単かつ迅速に特定するには、履歴のクエリとリアルタイムのクエリは開発者が使い慣れた同じツールセットとクエリ言語を使用し、システムは大量のデータをほぼリアルタイムで処理し (1 秒あたり何十万ものイベントを処理)、エンジンは広範な問題領域にまたがるシナリオを処理できるだけの柔軟性を備えている必要があります。

さいわい、これを実現するツールが存在します。それが Microsoft StreamInsight です。

StreamInsight のアーキテクチャの概要

StreamInsight は、きわめて短い待機時間で、1 秒間に何十万ものイベントを処理できる複合イベント処理エンジンです。Windows サービスなどの任意のプロセスでホストすることも、アプリケーションに直接埋め込むことも可能です。StreamInsight は、データの入出力を行うシンプルなアダプター モデルを採用し、Microsoft .NET Framework の任意の言語から他のアセンブリと同様にアクセスできる LINQ 構文を使用して、リアルタイム データと履歴データの両方を照会します。このツールは SQL Server 2008 R2 の一部としてライセンスが付与されます。

StreamInsight のアーキテクチャは非常にシンプルです。入力アダプターを通じてさまざまなソースからイベントを収集します。収集したイベントをクエリを使って分析および変換し、このクエリの結果を出力アダプターを通じて他のシステムやユーザーに配布します。図 1 は、このシンプルな構造を示しています。

High-Level Architecture of Microsoft StreamInsight

図 1 Microsoft StreamInsight のアーキテクチャの概要

サービス指向のアーキテクチャがメッセージに関連し、データベース システムが行に関連するのと同じように、StreamInsight のような複合イベント処理システムはイベントを基に体系化されます。イベントとは、シンプルなデータに、そのデータに関連する時間を添えたものです。たとえば、1 日の特定の時間に行われたセンサーの読み取り値や株価のようなものです。イベントが表すデータを、ペイロードと呼びます。

StreamInsight では、3 種類のイベントをサポートします。ポイント イベントは、ある瞬間のイベントで持続期間はありません。期間イベントは、ペイロードが一定期間に関連しているイベントです。エッジ イベントは期間イベントに似ていますが、イベント発生時点ではそのイベントの持続期間が不明な点が異なります。代わりに、開始時間が設定され、別のエッジ イベントが発生して終了時間が設定されるまでイベントの持続期間は事実上無限です。たとえば、速度計の読み取り値は絶えず変わるためポイント イベントですが、スーパーマーケットでの牛乳の価格は長い期間に変わらないため、エッジ イベントになる可能性があります。たとえば、卸業者の価格に応じて牛乳の小売価格が変わるときは、新しい価格の持続期間がわからないため、期間イベントよりもエッジ イベントの方が適しています。その後、卸業者が価格設定を再度更新すると、新しいエッジ イベントが発生して以前の価格の持続期間が終わり、新しい価格で別のエッジ イベントが始まります。

StreamInsight の入力アダプターと出力アダプターは、アダプター (Adapter) 設計パターンを抽象化した例です。StreamInsight エンジンは、独自のイベント表現を使ってイベントを操作しますが、イベントの実際のソースは、ハードウェア センサーの独自のインターフェイスから、企業のアプリケーションが生成するステータス メッセージまで多岐にわたります。入力アダプターは、ソース イベントをエンジンが認識するイベントのストリームに変換します。

StreamInsight クエリの結果は、ビジネス上の具体的な知識を表し、非常に特殊になることがあります。そのため、これらの結果を最も適切な場所にルーティングすることが重要です。出力アダプターは、イベントの内部表現を、コンソールに表示するテキスト、Windows Communication Foundation (WCF) 経由で別のシステムに送信するメッセージ、Windows Presentation Foundation アプリケーションのグラフ上の点などに変換できます。テキスト ファイル、WCF、SQL などを操作するサンプル アダプターは、streaminsight.codeplex.com (英語) で入手できます。

StreamInsight クエリの例

一見、StreamInsight のクエリは、データベースから行を取得するクエリに似ているように思われますが、大きな違いがあります。データベースにクエリするときは、クエリが構成および実行されてから、結果が返されます。基のデータが変化しても、クエリは既に実行されているため、出力には影響しません。データベース クエリの結果は、その時点のスナップショットを表し、要求 - 応答のパラダイムを通じて使用できます。

StreamInsight のクエリは継続クエリです。新しい入力イベントが発生するたびに、クエリは絶え間なく反応し、必要に応じて、新しい出力イベントを作成します。

ここで説明するクエリの例は、ダウンロードして入手できるサンプル ソリューションに含めています。最初のサンプルは単純ですが、クエリ言語の新しい機能を取り入れるにしたがって、より強力になります。すべてのクエリは、ペイロードに同じクラスを使用します。Region プロパティと Value プロパティを備えた単純なクラスの定義を次に示します。

public class EventPayload {
  public string Region { get; set; }
  public double Value { get; set; }

  public override string ToString() {
    return string.Format("{0}\t{1:F4}", Region, Value);
  }
}

サンプル アプリケーションのクエリは、データをランダムに生成する入力アダプターと、各イベントを単純にコンソールに書き込む出力アダプターを使用します。サンプル アプリケーションのアダプターは、説明をわかりやすくするために単純化しています。

各クエリを実行するには、サンプル ソリューションの Program.cs ファイルのコメントを解除し、クエリを "template" というローカル変数に代入します。

Value プロパティによりイベントにフィルターをかける基本的なクエリを次に示します。

var filtered =
  from i in inputStream
  where i.Value > 0.5
  select i;

LINQ を使用した経験がある開発者であれば、このクエリは見覚えがあるでしょう。StreamInsight では、クエリ言語として LINQ を使用するため、このクエリは、データベースにアクセスしたり、IList のメモリ内フィルター処理を行ったりする LINQ to SQL クエリとほぼ同じです。入力アダプターからイベントが発生すると、そのペイロードを調査し、Value プロパティの値が 0.5 よりも大きければ、ペイロードを出力アダプターに渡して、コンソールに表示します。

アプリケーションを実行すると、イベントが絶えず出力されることがわかります。これは事実上、プッシュ モデルです。StreamInsight は、アプリケーションからデータ ソースを定期的にポーリングして新しいデータの存在を確認する必要がある、データベースのようなプル モデルではなく、イベントの発生時に入力から新しい出力イベントを生成します。これは、Microsoft .NET Framework 4 で使用できる IObservable のサポートにうまく適合します。これについては後で説明します。

ポーリングではなく、絶えずデータをプッシュするモデルを使用することもすばらしい点ですが、StreamInsight の真の威力は、時間関連のプロパティでクエリするときに明らかになります。入力アダプターを通じてイベントが発生するときに、タイムスタンプが添えられます。このタイムスタンプは、(イベントが時間を明示的に格納する列を含む履歴データを表すとして) データ ソース自体のタイムスタンプを表す場合と、イベントが発生した時刻に設定される場合があります。時間は、実際、StreamInsight のクエリ言語を最も特徴付けているものです。

クエリは、"5 秒ごと" や "5 秒間で 3 秒ごと" など、末尾に時間の修飾子が付いている標準のデータベース クエリのように見えます。たとえば、5 秒ごとに Value プロパティの平均値を確認する単純なクエリを次に示します。

var aggregated =
  from i in inputStream
    .TumblingWindow(TimeSpan.FromSeconds(5), 
    HoppingWindowOutputPolicy.ClipToWindowEnd)
  select new { Avg = i.Avg(p => p.Value)};

データのウィンドウ

時間という考え方は複合イベント処理システムにとっては根本的かつ必須のものなので、システムでクエリ ロジックの時間コンポーネントを操作する単純な方法を用意しておくことが重要です。StreamInsight では、ウィンドウ (期間) という考え方を採用して、時間別のグループを表します。前述のクエリは、タンブリング ウィンドウを使用しています。このアプリケーションを実行すると、クエリは 5 秒ごとに 1 つの出力イベントを生成します (5 秒というのがウィンドウのサイズです)。出力イベントは、最後の 5 秒間の平均値を表します。LINQ to SQL や LINQ to Objects と同様、Sum や Average などの集計メソッドを使って、時間別にグループ化したイベントを 1 つの値にまとめたり、Select を使用して出力を異なる形式に投影できます。

タンブリング ウィンドウは、ホッピング ウィンドウと呼ばれる別の種類のウィンドウの特殊な例に過ぎません。ホッピング ウィンドウにはサイズもありますが、ホップ サイズも存在します。これはウィンドウ サイズと等しくはありません。つまり、ホッピング ウィンドウは相互に重なり合うことができます。

たとえば、ウィンドウ サイズが 5 秒でホップ サイズが 3 秒のホッピング ウィンドウでは、出力が 3 秒 (ホップ サイズ) ごとに生成され、最後の 5 秒間 (ウィンドウ サイズ) の平均値が返されます。つまり、3 秒に 1 回ホップし、5 秒間持続します。図 2 に、タンブリング ウィンドウとホッピング ウィンドウにグループ化されたイベント ストリームを示します。

Tumbling and Hopping Windows

図 2 タンブリング ウィンドウとホッピング ウィンドウ

タンブリング ウィンドウは重なりませんが、ホッピング ウィンドウは、ホップ サイズがウィンドウ サイズよりも小さければ重なる可能性があります。ウィンドウが重なり合う場合は、ウィンドウ 1 とウィンドウ 2 の両方に含まれる 3 つ目のイベントのように、イベントが最終的に複数になることがあります。エッジ イベント (持続期間を含む) でもウィンドウの境界が重なり合い、タンブリング ウィンドウの 2 個目のウィンドウから最後のウィンドウにかけてのイベントのように、最終的に複数のウィンドウにまたがることがあります。

よく使われるもう 1 つのウィンドウの種類は、カウント ウィンドウです。カウント ウィンドウは、特定の時点や一定期間のイベントではなく、具体的なイベント数を保持します。最後に発生した 3 つのイベントの平均値を求めるクエリでは、カウント ウィンドウを使用することになります。現時点で、カウント ウィンドウには、Sum や Average といった組み込みの集計メソッドがサポートされないという制限事項があります。つまり、ユーザー定義の集計メソッドを作成する必要があります。この簡単な処理については、後半で説明します。

最後のウィンドウの種類は、スナップショット ウィンドウです。スナップショット ウィンドウは、エッジ イベントのコンテキストで理解するのが最も簡単です。イベントが開始または終了するたびに、現在のウィンドウが完了し、新しいウィンドウが始まります。図 3 に、エッジ イベントがスナップショット ウィンドウにグループ化されるようすを示します。各イベントの境界がウィンドウの境界のトリガーになっているのがわかります。E1 が始まると w1 が始まります。E2 が始まると、w1 が完了し、w2 が始まります。次のエッジは E1 の終了時点で、これにより w2 が完了して w3 が始まります。結果として、E1 を含む w1、E1 を含む w2、および E2 を含む w3 の、3 つのウィンドウになります。イベントをウィンドウにグループ化すると、ウィンドウが伸縮するため、ウィンドウが開始および終了するときにイベントが開始および終了するように見えます。

Snapshot Windows

図 3 スナップショット ウィンドウ

複雑なクエリ

これらの使用可能なウィンドウと、where、group by、order by などの基本的なクエリ手法を使用すると、さまざまなクエリを実現できます。入力イベントを領域でグループ化してから、ホッピング ウィンドウを使用して、最後の瞬間の各領域のペイロード値の合計を出力するクエリを次に示します。

var payloadByRegion =
  from i in inputStream
  group i by i.Region into byRegion
  from c in byRegion.HoppingWindow(
    TimeSpan.FromMinutes(1),
    TimeSpan.FromSeconds(2), 
    HoppingWindowOutputPolicy.ClipToWindowEnd)
  select new { 
    Region = byRegion.Key, 
    Sum = c.Sum(p => p.Value) };

これらのウィンドウでは、ホップ サイズとして 2 秒を使用しているため、エンジンは出力イベントを 2 秒ごとに送信します。

クエリ演算子は IQueryable インターフェイスで定義されるため、クエリの構成が可能です。次のコードでは、領域別に合計を求める先ほどのクエリを使用して、合計値が最も高い領域を計算します。スナップショット ウィンドウでは、イベント ストリームを合計で並べ替えることができるため、Take メソッドで合計値が最も高い領域を取得できます。

var highestRegion = 
  // Uses groupBy query 
  (from i in payloadByRegion.SnapshotWindow(
    SnapshotWindowOutputPolicy.Clip)
    from sumByRegion in i
    orderby sumByRegion.Sum descending
    select sumByRegion).Take(1);

よくあるシナリオは、変化の激しいイベント (センサーからの読み取りなど) のストリームを、変化の少ない (または静的な) 参照データ (センサーの設置場所など) に関連付けるクエリです。クエリでは、結合を使用して、この目標を実現します。

StreamInsight の結合構文は、他の LINQ の結合と同じですが、1 つ重要な注意点があります。イベントは、持続期間が重なり合う場合しか結合されません。センサー 1 が t1 の時点の値をレポートする場合に、センサー 1 の設置場所の参照データが t2 ～ t3 でのみ有効であれば、その結合は一致しません。持続期間についての結合条件は、クエリ定義に明示的に記述しません。これは StreamInsight のエンジンの基本的な特性です。静的データを操作するときは、一般に、入力アダプターは、事実上持続期間が無限のエッジ イベントとしてデータを扱います。このようにすれば、変化が激しいイベントのストリームでのすべての結合が成功します。

結合を通じて複数のイベント ストリームを相互に関連付けることは、強力な概念です。組立ライン、石油採掘施設、またはアクセス数の多い Web サイトは、1 つのイベントが原因で失敗することはそう多くありません。通常、1 つの機器が温度アラームをトリガーしても製造ラインがダウンすることはありません。たとえば、しばらくの間温度が高くなりすぎている状態が続き、その間特定のツールの使用頻度が高いときに、オペレーターの勤務交替が行われるといった、複数の状況が組み合わせて生じたときにダウンします。

結合がなければ、単独のイベントはそれほど大きなビジネス価値を持ちません。履歴データに対して結合と StreamInsight のクエリを使用すると、ユーザーは単独のストリームを、非常に具体的な監視の条件と相互に関連付けて、リアルタイムに監視できます。継続クエリは、すべての製造ラインがダウンするまで待機するのではなく、障害につながる状況を探して、過熱状態の機器をオフラインにする方法を認識しているシステムにルーティングできる出力イベントを自動生成できます。

小売のシナリオでは、時間の経過とともに商品ごとの販売量に関するイベントを監視し、そのデータを価格システムや顧客の注文履歴に送り、商品ごとに最適な価格設定を行ったり、顧客が精算する前に商品を薦めたりといった対応が可能になります。クエリは簡単に作成、変更、および構成できるため、シンプルなシナリオから始めて、時間をかけて改良し、ビジネスにとっての価値を高めていくことができます。

ユーザー定義の集計

StreamInsight には、Count、Sum、Average など、よく使われる集計関数が付属しています。これらの関数で物足りない場合 (または前述のようにカウント ウィンドウでの集計が必要な場合) に備えて、StreamInsight ではユーザー定義の集計関数をサポートします。

ユーザー定義集計を作成するには、実際の集計メソッドを記述し、拡張メソッドを通じてメソッドを LINQ に公開するという 2 つの手順を実行します。

最初の手順では、CepAggregate<TInput, TOutput> (集計が時間に依存しない場合)、または CepTimeSensitiveAggregate<TInput,TOutput> (集計が時間に依存する場合) のいずれかからの継承が必要です。これらの抽象クラスには、GenerateOutput というメソッドが 1 つ実装されています。図 4 に、EveryOtherSum 集計の実装を示します。これにより、他のすべてのイベントが累計加算されます。

図 4 EveryOtherSum 集計

public class EveryOtherSum : 
  CepAggregate<double, double> {

  public override double GenerateOutput(
    IEnumerable<double> payloads) {

    var sum = default(double);
    var include = true;
    foreach (var d in payloads) {
      if (include) sum += d;
      include = !include;
    }
    return sum;
  }
}

2 つ目の手順では、作成した集計をクエリで使用できるように、CepWindow<TPayload> に拡張メソッドを作成する必要があります。CepUserDefinedAggregateAttribute を拡張メソッドに適用し、集計の実装場所 (この場合は 1 つ目の手順で作成したクラス) を StreamInsight に通知します。このプロセスの両方の手順のコードは、ダウンロード可能なサンプル アプリケーションの EveryOtherSum.cs ファイルで入手できます。

アダプターの詳細

クエリは、アダプターから提供されるデータを操作するビジネス ロジックを表します。サンプル アプリケーションでは、ランダムなデータを生成するシンプルな入力アダプターと、コンソールに書き込む出力アダプターを使用しています。いずれのアダプターも同じパターンに従いますが、CodePlex サイトで入手できるアダプターもこのパターンに従います。

StreamInsight では、アダプターの作成に Factory パターンを使用します。構成クラスを指定すると、ファクトリが適切なアダプターのインスタンスを作成します。サンプル アプリケーションの入力アダプターと出力アダプターの構成クラスはかなり簡単です。出力アダプターの構成には、出力を書き込む際に使用する書式設定文字列を保持する 1 つのフィールドがあります。入力アダプターの構成には、ランダムなイベント生成の合間にスリープする時間のフィールドと、CtiFrequency というもう 1 つのフィールドがあります。

CtiFrequency の Cti は、Current Time Increment (現在時刻の増加) を表します。StreamInsight では、Cti イベントを使用して、イベントが適切な順序で配信されるようにします。既定では、StreamInsight では、順不同で発生するイベントをサポートします。エンジンは、クエリを通じてイベントを渡す場合に、イベントの順序を自動的に適切に並べ替えます。ただし、この並べ替えには制限があります。

イベントが本当に任意の順序で発生すると仮定すると、一番早いイベントが発生し、クエリを通じてプッシュできることを、いったいどのようにして判断できるでしょう。次のイベントの時刻が、既に受け取った最も早いイベントよりも早い時刻の可能性があれば、このようなプッシュは不可能です。StreamInsight では、Cti イベントを使用して、既に受け取っているイベントよりも早いイベントを発生させないように、エンジンに通知します。Cti イベントは、事実上、発生したイベントを処理し、その後、タイムスタンプが現在時刻よりも早いすべてのイベントを無視または調整するよう、エンジンに合図します。

サンプルの入力アダプターは、順序付けされたイベント ストリームを生成するため、生成されたすべてのイベントの後に Cti イベントを自動挿入して、イベントが適切に進むようにします。以前に入力アダプターを記述してプログラムで出力が生成されないという経験をした方は、アダプターで Cti を挿入するようにしてください。Cti がないと、エンジンは永遠に待機することになります。

StreamInsight には、typed、untyped、point、interval、edge といった、アダプターのさまざまな基本クラスが付属しています。Typed (厳密に型指定される) アダプターでは、常に、よく知られているペイロードの種類 (この場合は、RandomPayload クラス) を伴うイベントが生成されます。Untyped (型指定されない) アダプターは、複数の種類のイベントを生成する可能性があるイベント ソースや、行のレイアウトとコンテンツが事前にわからない CSV ファイルなどに適しています。

サンプルの入力アダプターは、既知のペイロードの種類を使用し、ポイント イベントを生成するため、TypedPointInputAdapter<RandomPayload> から継承します。基本クラスには、Start と Resume という、実装する必要がある 2 つの抽象メソッドがあります。サンプルでは、Start メソッドでは、構成で指定された間隔で起動するタイマーを有効にします。このタイマーの Elapsed イベントは ProduceEvent メソッドを実行し、アダプターの主な処理を行います。このメソッドの本文は、一般的なパターンに従います。

まず、アダプターは、エンジンが最後に実行されてから停止しているか、実行を継続しているかを確認します。次に、基本クラスのメソッドを呼び出してポイント イベントのインスタンスを作成し、そのペイロードを設定して、イベントをストリームのキューに追加します。サンプルでは、SetRandomEventPayload が、すべての実際のアダプター ロジック (たとえば、ファイルからの読み取り、センサーへの通知、またはデータベースのクエリなど) の代わりを務めます。

入力アダプターのファクトリもシンプルです。このファクトリは、厳密に型指定されるアダプターのファクトリなので、ITypedInputAdapterFactory<RandomPayloadConfig> インターフェイスを実装します。このファクトリで唯一凝らした技巧は、ITypedDeclareAdvanceTimeProperties<RandomPayloadConfig> インターフェイスも実装する点です。このインターフェイスにより、ファクトリは、先ほど説明したように Cti の挿入を処理できます。

サンプル アプリケーションの出力アダプターは、入力アダプターとほぼ同じパターンに従います。構成クラス、ファクトリ、および出力アダプターそのものがあります。出力アダプター クラスは、入力アダプターによく似ています。主な違いは、出力アダプターではイベントをキューに追加するのではなく、キューからイベントを削除する点です。Cti イベントは他のイベントと同様のイベントなので、出力アダプターでも発生し、単純に無視されます。

監視可能

アダプター モデルは非常にシンプルですが、エンジンでイベントの入出力を行うさらに簡単な方法があります。アプリケーションが StreamInsight の埋め込み配置モデルを使用している場合は、エンジンの入出力に IEnumerable と IObservable の両方を使用できます。IEnumerable または IObservable があれば、ToStream、ToPointStream、ToIntervalStream、または ToEdgeStream のような提供されている拡張メソッドの 1 つを呼び出して、入力ストリームを作成できます。これにより、入力アダプターで作成したイベント ストリームとまったく同じように見えるイベント ストリームが作成されます。

同様に、クエリを使用して、ToObservable と ToEnumerable、ToPointObservable と ToPointEnumerable、ToIntervalObservable と ToIntervalEnumerable、または ToEdgeObservable と ToEdgeEnumerable といった拡張メソッドにより、クエリの出力がそれぞれ IObservable または IEnumerable にルーティングされます。これらのパターンは、データベースに保存された履歴データを再生するのに特に役立ちます。

Entity Framework または LINQ to SQL を使用して、データベース クエリを作成します。ToStream 拡張メソッドを使用して、データベースの結果をイベント ストリームに変換し、これを使用する StreamInsight のクエリを定義します。最後に、ToEnumerable を使用し、簡単に foreach ループを使用して表示できる場所に StreamInsight の結果をルーティングします。

配置モデルとその他のツール

Observable と Enumerable のサポートを使用するために、StreamInsight をアプリケーションに埋め込む必要があります。ただし、StreamInsight がサポートするのはスタンドアロン モデルです。インストール時に、既定のインスタンスをホストする Windows サービスを作成するかどうかをたずねられます。このサービスで StreamInsight をホストすると、複数のアプリケーションを同一のインスタンスに接続して、アダプターとクエリを共有できます。

埋め込みサーバーではなく共有サーバーと通信する場合は、単純に、Server クラスのさまざまな静的メソッドが必要になります。インスタンス名を使用して Create を呼び出すのではなく、共有インスタンスを指す EndpointAddress を使用して Connect を呼び出します。この配置方針は、複数のアプリケーションから共有のクエリやアダプターを使用する必要がある企業シナリオにとって有用です。

いずれの場合も、StreamInsight が生成した出力が目的どおりになっていない理由を突き止める必要がある場合があります。このために、StreamInsight には、Event Flow Debugger と呼ばれるツールが付属しています。このツールの使用については説明しませんが、一般に、インスタンスに接続して、クエリを通じて入力からイベントをトレースし、出力に渡すことができます。

柔軟性があり応答性の高いツール

柔軟性がある配置オプション、使い慣れたプログラミング モデル、および簡単に作成できるアダプターにより、StreamInsight はさまざまなシナリオに適した優れた選択肢となっています。何千ものセンサー入力を少しの時間でクエリして関連付ける一元化されたインスタンスから、1 つのアプリケーション内で現在と過去のイベントを監視する埋め込みインスタンスまで、StreamInsight では、LINQ のような開発者が使い慣れたフレームワークを使用して、高度にカスタマイズ可能なソリューションを実現します。

簡単に作成できるアダプター、およびイベント ストリームと IEnumerable や IObservable との変換を行う組み込みのサポートにより、ソリューションの迅速な起動や実行が簡単になるため、特定のビジネス知識をカプセル化するクエリを段階的に作成および改良する作業に着手できます。これらのクエリを改良していくにつれて、より多くの価値を実現できるため、アプリケーションや組織は、絶好の機会を逃すことなく、関連シナリオが発生したときにこれらを特定して対応できます。

Rob Pierry は、Captura 社 (capturaonline.com、英語) の主任コンサルタントです。同社は、スケーラブルなテクノロジでサポートされる革新的なユーザー エクスペリエンスを提供しています。連絡先は、rpierry+msdn@gmail.com (英語のみ) です。

この記事のレビューに協力してくれた技術スタッフの Ramkumar Krishnan、Douglas Laudenschlager、および Roman Schindlauer に心より感謝いたします。