(57)【要約】  １つまたは複数の入力イベントストリームに対する変換を形成して１つまたは複数の出力イベントストリームを生成する。よって、変換は、元の入力イベントストリームに対するクエリと考えられ得る。イベントクエリは、特定の実行コンテキストで使用可能な入力イベントストリームを表すイベントストリームソース表現を含む。イベントクエリは、実行コンテキストで入力イベントストリームに対して実行される変換セットを特定する変換モジュールをさらに含む。クエリが適切に形成されると、実行モジュールが、指定された入力イベントストリームに対して変換を実行させて出力イベントストリームを生成させ得る。
2017527024.tif 000002
【特許請求の範囲】
【請求項１】
１つまたは複数のプロセッサで実行されたときに、前記１つまたは複数のプロセッサに、
実行コンテキストで使用可能なイベントストリームを表すイベントストリームソース表現と、
変換モジュールにより表される１つまたは複数の入力イベントストリームに対して実行される１つまたは複数の変換の変換セットを特定し、前記イベントストリームソース表現を参照することにより前記イベントストリームを前記イベントストリームの１つとして特定し、前記イベントストリームソース表現を参照することにより前記イベントストリームを前記入力イベントストリームの１つとして特定する変換モジュールと、
前記変換モジュールを解釈して、前記特定された入力ストリームに対して前記変換セットを前記実行コンテキストで実行させて結果のイベントストリームを生成する実行モジュールと
をインスタンス化および実行するためのシステムアーキテクチャを実装させるコンピュータ実行可能命令を有する１つまたは複数のコンピュータ可読媒体を備えるコンピュータプログラム製品。
【請求項２】
前記コンピュータ可読媒体の前記コンピュータ実行可能命令が、
作成者が前記イベントストリームソース表現および前記変換モジュールをオーサリングできるように構成されたオーサリングモジュール
をさらに備える、請求項１に記載のコンピュータプログラム製品。
【請求項３】
前記コンピュータ可読媒体の前記コンピュータ実行可能命令が、
前記実行コンテキストを前記実行モジュールに対して特定して、前記実行モジュールが前記変換セットを前記実行コンテキストで実行させることができるようにするコンテキスト特定モジュール
をさらに備える、請求項１に記載のコンピュータプログラム製品。
【請求項４】
前記コンピュータ可読媒体の前記コンピュータ実行可能命令が、
ユーザ入力が検知されたときに前記実行モジュールを開始するように構成された開始コントロール
をさらに備える、請求項１に記載のコンピュータプログラム製品。
【請求項５】
１つまたは複数の入力イベントストリームに対して変換セットを実行することにより結果のイベントストリームを生成させるコンピュータ実装方法であって、前記コンピュータ実装方法のためのコンピュータ実行可能命令を実行する１つまたは複数のプロセッサにより実行され、
実行コンテキストで使用可能な特定のイベントストリームを表すイベントストリームソース表現にアクセスすることと、
変換モジュールが、前記変換モジュールにより表される１つまたは複数の入力イベントストリームに対して実行される１つまたは複数の変換の変換セットを特定し、前記変換モジュールが、前記イベントストリームソース表現を参照することにより前記特定のイベントストリームを前記１つまたは複数の入力イベントストリームの１つとして特定することと、
実行モジュールが、前記変換モジュールを解釈して、前記特定された１つまたは複数の入力ストリームに対して前記変換セットを前記実行コンテキストで実行させて結果のイベントストリームを生成することと
を含む、コンピュータ実装方法。
【請求項６】
前記特定のイベントストリームが最新イベントストリームであり、前記イベントストリームソース表現が最新イベントストリームソース表現である、請求項５に記載のコンピュータ実装方法。
【請求項７】
実行コンテキストで使用可能な履歴イベントストリームを表す履歴イベントストリームソース表現にアクセスすること
をさらに含む、請求項６に記載のコンピュータ実装方法。
【請求項８】
前記１つまたは複数の変換が、前記特定のイベントストリームに適用されるフィルタ処理操作を含む、請求項５に記載のコンピュータ実装方法。
【請求項９】
前記１つまたは複数の変換が、前記結果のイベントストリームのイベントを生成するイベント生成ロジックを含み、前記イベント生成ロジックが、フィルタ処理された前記特定のイベントストリームを入力として使用する、請求項８に記載のコンピュータ実装方法。
【請求項１０】
前記１つまたは複数の変換が、前記結果のイベントストリームのイベントを生成するイベント生成ロジックを含み、前記イベント生成ロジックが、前記イベント生成ロジックが、前記特定のイベントストリームを入力として使用する、請求項５に記載のコンピュータ実装方法。
【発明の詳細な説明】
【背景技術】
【０００１】
[0001]  イベントとは、１つまたは複数のタイムスタンプと関連付けられたデータ片である。イベントストリームとは、イベントのストリームである。イベントソースは、イベントを受け取り、それらのイベントをタイムスタンプで並べ替え、順序付きのイベントストリームを提供することができる。イベントストリームを処理するためのさまざまな機構が従来より存在する。各機構は、イベントストリームに対する変換の表現および実行を含む。しかし、イベントおよび並行処理の非同期的な性質に起因して、ストリーミングドメインは必然的に複雑である。結果として、新たなユーザにとってイベントストリームに対するクエリの学習曲線は、従来きわめて急峻である。
【０００２】
[0002]  現在、イベント処理でデータ変換を表現する主要なアプローチは２つある。すなわち、ドメイン固有言語（DSL）と、汎用プログラミング言語（GPPL）である。ＤＳＬは通常、ＳＱＬに似た言語の形式をとり、時間次元を処理する追加機能を備える。ＤＳＬは、クエリを高度な抽象化で記述するための宣言的な方法を提供する。さらに、ＤＳＬは、ＳＱＬと同様に、学習曲線を緩和するのに役立ち、開発者以外の人でもクエリを記述できるようにする。ＤＳＬの大きな問題は、ユーザ定義の拡張や、通常はＧＰＰＬで記述されるアプリケーションとの統合が、困難であるということである。クエリをＧＰＰＬで直接記述するほうが、データを使用するアプリケーションとの統合は円滑になるが、それには作成者がＧＰＰＬを知っている必要がある。
【０００３】
[0003]  本明細書で特許請求されている主題は、上述した欠点を解決する実施形態または上述したものなどの環境のみで動作する実施形態に限定されない。むしろ本背景は、本明細書に記載された一部の実施形態が実践され得る１つの例示的な技術領域を示すためにのみ提供されている。
【発明の概要】
【０００４】
[0004]  本明細書に記載された少なくとも一部の実施形態は、１つまたは複数の入力イベントストリームに対する変換を形成して１つまたは複数の出力イベントストリームを生成することに関する。よって、変換は、元の入力イベントストリームに対するクエリと考えることができる。イベントクエリは、特定の実行コンテキストで使用可能な入力イベントストリームを表すイベントストリームソース表現を含む。イベントクエリは、実行コンテキストで入力イベントストリームに対して実行される変換セットを特定する変換モジュールをさらに含む。クエリが適切に形成されると、実行モジュールは、指定された入力イベントストリームに対して変換を実行して、出力イベントストリームを生成することができる。
【０００５】
[0005]  一部の実施形態では、入力イベントストリームを表現するために使用できるプログラミング抽象化は、入力イベントストリームに関係なく、同じである。たとえば、最新イベントストリームならびに履歴イベントストリームを指定するために、同じプログラミング抽象化を使用することができる。プログラミング抽象化により、最新イベントストリームを、同じイベントストリームの履歴バージョンと組み合わせることが可能になり得る。
【０００６】
[0006]  本概要は、以下の「発明を実施するための形態」でさらに詳しく説明する概念の一部を、簡単な形式で紹介するために設けられている。本「発明の概要」は、特許請求されている主題の主要な特徴または必須の特徴を特定することを意図しておらず、特許請求されている主題の範囲を判断しやすくするものとして使用されることも意図していない。
【０００７】
[0007]  本発明の上記引用した利点および特徴ならびに他の利点および特徴を得ることができる態様を記述するために、上記概説した本発明のさらに詳細な記述を、添付の図面に示された本発明の具体的な実施形態を参照しながら以下に示す。これらの図面が本発明の典型的な実施形態のみを示すものであり、よって本発明の範囲を限定するものと考えられるべきものではないという理解に基づき、添付の図面を使用して追加の特異性および詳細を示しながら本発明について記述および説明する。
【図面の簡単な説明】
【０００８】
【図１】[0008]イベント処理プログラミングモデルのオーサリング環境の態様を示す図である。
【図２】[0009]イベント処理プログラミングモデルの実行環境の態様を示す図である。
【図３】[0010]変換コンポーネントを実行環境での操作のために準備する方法のフローチャートである。
【図４】[0011]変換プロセスを示すフローグラフである。
【図５】[0012]１０分間のタンブリングウィンドウにわたる平均が考慮されるイベントストリームを示す図である。
【図６】[0013]最新イベントストリームと履歴イベントストリームの２つのイベントストリームの結合と関連付けられたイベントフローを示す図である。
【図７】[0014]本明細書に記載された原理が動作し得る例示的コンピューティングシステムを示す図である。
【発明を実施するための形態】
【０００９】
[0015]  包括的でありながらも使いやすいイベント処理プログラミングモデルについて、本明細書で記述する。このイベント処理プログラミングモデルでは、１つまたは複数のイベントストリームに対してクエリを表現および実行して、１つまたは複数の結果のイベントストリームを得ることができる。イベントとは、１つまたは複数のタイムスタンプと関連付けられたデータ片である。本明細書で記述される少なくとも一部の実施形態は、１つまたは複数の入力イベントストリームに対する変換を形成して１つまたは複数の出力イベントストリームを生成することに関する。よって、変換は、元の入力イベントストリームに対するクエリと考えることができる。イベントクエリは、特定の実行コンテキストで使用可能な入力イベントストリームを表すイベントストリームソース表現を含む。イベントクエリは、実行コンテキストで入力イベントストリームに対して実行される変換セットを特定する変換モジュールをさらに含む。クエリが適切に形成されると、実行モジュールは、指定された入力イベントストリームに対して変換を実行して、出力イベントストリームを生成することができる。
【００１０】
[0016]  一部の実施形態では、入力イベントストリームを表現するために利用できるプログラミング抽象化は、入力イベントストリームに関係なく、同じである。たとえば、現代（たとえば、ライブ）イベントストリームならびに履歴イベントストリームを指定するために、同じプログラミング抽象化をおそらく同じクエリでも使用することができる。「１日の時間枠での平均エネルギー消費量が１年前の同じ日に消費されたエネルギーよりも５０％高い場合にアラームをトリガする」という自然言語で表現された以下のクエリを考えてみる。従来、そのようなシナリオには、ユーザが複雑なカスタムロジックを記述することで対処していた。プログラミング抽象化により、最新イベントストリームを、同じイベントストリームの履歴バージョンと組み合わせることが可能になり得る。よって、（イベントストリームが実行コンテキストにおいて使用可能である限り）イベントストリームの種類に依存しない、一元化されたイベントクエリモデルが記述される。
【００１１】
[0017]  イベントストリームのクエリ変換セットをプログラミングする体験は、実行コンテキストに関係なく（たとえば、実行コンテキストがローカルコンピューティングシステム上であるか、リモートサーバ上であるか、クラウド内であるかに関係なく）、実質的に同じであり得る。実行コンテキストは、コンテキスト特定を使用して、実行コンテキストを特定し、クエリ変換セットを指定された実行コンテキストで実行させるために必要な情報を取得する。イベントクエリ処理の実行における、このような柔軟性により、入力イベントストリームが生成される場所および／または出力イベントストリームが消費される場所の近くで、計算を発生させることができる。よって、イベント処理プログラミングモデルの実施形態は、（実行モジュールがクエリを特定して実行コンテキストで展開するための十分な情報を持っている限り）実行コンテキストに依存しない。
【００１２】
[0018]  本明細書で記述されるイベント処理モデルの実施形態は、ユーザにとって学習曲線が緩やかである一方、表現力と拡張性も備えている。イベントおよび並列処理の非同期的な性質に起因して、ストリーミングドメインは必然的に複雑である。結果として、新たなユーザにとってイベントストリームに対するクエリの学習曲線は、従来きわめて急峻である。使いやすくするため、イベント処理プログラミングモデルは、ユーザに公開されるアプリケーションプログラミングインターフェイス（API）での概念／抽象化の数を制限し、そのような抽象化のセマンティクスを明確に定義している。同時に、表現力を実現するため、これらの抽象化は組み立て可能であり、ユーザは原始的な組み込みイベント処理計算からより高水準なクエリロジックを構築することができる。記述されるイベント処理プログラミングモデルは、ドメイン固有言語（DSL）および汎用プログラミング言語（GPPL）の両方で表現することができる抽象化を定義する。
【００１３】
[0019]  イベント処理プログラミングモデルは、イベントストリームの時間的モデルを実装するものとして記述される。以下で記述するアプリケーションプログラミングインターフェイス（API）では、各イベントに、そのイベントが生成された時刻を表す単一のタイムスタンプが関連付けられている。しかし、本明細書で記述される、より一般的な原理は、シーケンスモデル、インターバル／スナップショットモデル、または他の任意のイベント処理時間モデルをサポートすることもできる。また、本明細書で記述される原理は、イベント処理時間モデル間の明確に定義されたユーザ体験分離により、複数のイベント処理時間モデル（時間的モデル、インターバル／スナップショットモデル等）との対話を可能にするイベント処理プログラミングモデルに適用することもできる。
【００１４】
[0020]  また、イベント処理プログラミングモデルは、時間の概念を明示的に定義し、仮想時間（すなわち、アプリケーション時間）で稼働する。多くの監視および遠隔測定シナリオは、実時間（すなわち、システム時間）と異なる独自の時間軸を有するログ記録の分析を含む。そのようなクエリの自然言語形式の例として、「１時間の時間枠内に応答がない場合、すべてのケースにアラートする」がある。そのようなクエリは、システム時間の評価を含まない。
【００１５】
[0021]  イベント処理プログラミングモデルは、クエリを実行する基盤サービスにより自動的に並列化される態様でイベント処理計算を定義することにより、表現力を提供する。よって、イベント処理プログラミングモデルは、便利なグループ化抽象化を提供することにより、計算を弾力的にスケールアウトすることができる。
【００１６】
[0022]  最初に、時間的データ処理モデルの概念を紹介する。以下のシナリオを考えてみる。データセンターの異なるマシンから取得された、パフォーマンスカウンタ値のセットがあると仮定する。このシナリオでは、システムは、パフォーマンスカウンタ値の異常を経時的に発見する。パフォーマンスカウンタ値の時刻は、その値が読み取られた時刻であり、対応するイベントが処理される時刻ではない。よって、イベント処理プログラミングモデルは、時間的モデルを導入する。
【００１７】
[0023]  この時間的モデルは、仮想時間に基づいており、複合イベント検知および応答（Complex Event Detection and Response）（CEDR）代数のサブセット上に構築され、仮想時間に基づく。時間的モデルにおけるすべての演算子は、各イベント内の仮想時間タイムスタンプを参照する。一実施形態では、ユーザにとってセマンティクスを簡素化するために、時間的モデル内のイベントはポイントイベントであり、イベントが各々厳密に１つのタイムスタンプを有し、時間内の１つのポイントのペイロードを運ぶ。ポイントイベントの例として、メーター読み取り、電子メールの到達、ユーザのウェブクリック、ストックティック（stock tick）またはログへのエントリなどがある。
【００１８】
[0024]  この時間的モデルのすべての演算子は決定性であり得、演算子の出力は反復可能であり得る。一例では、クエリは、ソースと呼ばれるイベントストリームをその入力として受け取り、そのイベントストリーム入力を使用して変換（たとえば、フィルタ処理、選択等）を実行し（すなわち、その入力イベントストリームに対してクエリを実行し）、シンク（sink）と呼ばれる結果のデータストリームを生成する。ソースは、さまざまな場所からさまざまなイベントを受け取り、結果のイベントストリームを提供する。一部の実施形態では、ソースは、時刻によるイベントの並べ替え等の何らかの追加処理をイベントに対して実行してイベントストリームを作り出すこともある。
【００１９】
[0025]  図１は、イベント処理プログラミングモデルのオーサリング環境１００の態様を示す。オーサリングモジュール１４１は、作成者がイベントストリームソース表現１１０、イベントストリームシンク表現１２０、変換モジュール１３０、およびコンテキスト特定モジュール１５０をオーサリングすることを可能にする。
【００２０】
[0026]  オーサリング後、開始コマンド１６０が開始され得、このコマンドにより変換モジュール１３０がコンテキスト特定モジュール１５０で特定された実行コンテキストで自動的に実行される。たとえば、図２は、実行環境２００で実行される実行可能変換コンポーネント２３０を示している。
【００２１】
[0027]  クエリ変換モジュール１３０は、入力イベントストリームに対して実行され、それによって出力（または結果の）イベントストリームを生成する、具体的なクエリを表す。具体的には、クエリ変換モジュール１３０は、１つまたは複数の入力イベントストリームに対して実行され、それによって１つまたは複数の出力イベントストリームを生成する、１つまたは複数の変換の変換セットを表し得る。変換操作の例として、１つまたは複数のイベントストリームソースのそれぞれをフィルタ処理して、一部のイベントのみが通過を許可されるようにすることがあり得る。その他の変換として、イベントストリームソースのイベントを使用して実行され、それによって１つまたは複数の結果のイベントを生成するロジックがあり得る。そのようなロジックは、イベントストリームソースに対して直接実行されるか、または１つもしくは複数のフィルタを通じてフィルタ処理されたイベントのみに対して実行され得る。
【００２２】
[0028]  実行環境では、対応するクエリ変換コンポーネント２３０がイベントストリームソース２１０を入力として受け取る。イベントストリームソース２１０は、イベント２０１（イベント２０１Ａ、２０１Ｂ、２０１Ｃ、および省略記号２０１Ｄにより表される他の多数のものを含み得る）を受け取り、結果を入力イベントストリーム２１１として提供する。クエリ変換コンポーネント２３０は、入力イベントストリームを処理し、それによってクエリ変換モジュール１３０で表されたクエリを実行する。処理の結果として、クエリ変換コンポーネント２３０は、イベントストリームシンク２２０に提供される出力（結果の）イベントストリーム２２１を生成する。出力イベントストリーム２２１は、クエリ変換コンポーネントと関連付けられたクエリが入力イベントストリーム２１１に適用されたときのクエリ結果を表す。イベントストリームソース２１０およびイベントストリームシンク２２０は、それら自体がイベントストリームと考えられ得る。よって、イベントストリームシンクは、後で異なるクエリ処理のイベントストリームソースとして機能し得る。
【００２３】
[0029]  オーサリング時には、作成者はオーサリングモジュール１４１を使用して、実行コンテキスト２００で使用可能なイベントストリームソース２１０を表すイベントストリームソース表現１１０を形成する。オーサリングモジュール１４１は、変換モジュールにより表される（または変換モジュールと関連付けられる）１つまたは複数の入力イベントストリームに対して実行される、１つまたは複数の変換の変換セットを特定するクエリ変換モジュール１３０を形成するためにも使用される。変換モジュール１３０は、イベントストリームソース表現１１０を参照するか、またはイベントストリームソース表現１１０と関連付けられ得る。オーサリングモジュール１４１は、実行コンテキスト２００で使用可能なイベントストリームシンク２２０を表すイベントストリームシンク表現１２０を形成するためにも使用される。変換モジュール１３０は、イベントストリームシンク表現１２０を参照するか、またはイベントストリームシンク表現１２０と関連付けられ得る。オーサリングモジュール１４１は、実行コンテキストを特定するコンテキスト特定モジュール１５０を形成するためにも使用される。
【００２４】
[0030]  実行コンテキスト１５０は、コンテキストで使用可能なイベントストリームソースおよびイベントストリームシンクの定義を含む。拡張により、使用可能な操作のセットを、使用可能なソース定義およびシンク定義から推測することもできる。たとえば、図２に示すように、実行コンテキスト２００は、イベントストリームソース１１０のインスタンス２１０と、イベントストリームシンク１２０のインスタンス２２０とを含む。コンテキスト特定モジュール１５０は、コンテキストを暗黙的に（たとえば、表現されたコンテキスト特定がない場合のデフォルトコンテキストとして）特定するか、または明示的に特定し得る。たとえば、デフォルトコンテキストは、クエリを開始したのと同じシステムでクエリ変換コンポーネント１３０のインスタンスを単純に実行するだけである可能性がある。単なる例として、実行コンテキストは、ローカルコンピューティングシステム、クラウドコンピューティング環境、または他の任意の実行環境である可能性がある。
【００２５】
[0031]  オーサリング環境１００は、１つまたは複数の条件および／またはイベントの検知時に変換モジュール１３０を解釈して、実行コンテキスト２００で実行中の対応するクエリ変換コンポーネント２３０を実行する実行モジュール１６１をさらに含む。たとえば、実行モジュール１６１は、ユーザ入力の検知時に実行モジュール１６１を開始するように構成された開始コマンドまたはコントロール１６０（または「管理API」）を含み得る。開始コマンド１６０は、イベント処理プログラミングモデルを実行コンテキスト２００で自動的に実行させる。たとえば、コンテンツ特定コンポーネント１５０で特定されるコンテキストが、クエリをローカルに実行することを示している場合、クエリ変換コンポーネント２３０はローカルコンピューティングシステムでローカルに実行され得る。コンテキスト特定コンポーネント１５０で特定される実行コンテキストが、クラウドコンピューティング環境または何らかの種類のリモートサーバである場合、クエリ変換モジュール１３０がそのクラウドコンピューティング環境または他の種類のリモートサーバにアップロードされ、クエリ変換コンポーネント２３０がインスタンス化され、そのリモート環境で実行される。クエリ変換コンポーネント１３０のインスタンス２３０が実行されるコンテキストは、クエリ変換コンポーネント１３０自体のクエリロジックを一切変更することなく、コンテキスト特定コンポーネント１５０内で特定され得ることに留意されたい。
【００２６】
[0032]  図３は、変換コンポーネント２３０を実行環境２００での操作のために準備する方法３００のフローチャートを示す。方法３００は、作成者が図１の開始コマンド１６０を開始したことに応じて実行され得る。
【００２７】
[0033]  イベントストリームソース表現へのアクセスが行われる（行為３０１Ａ）。たとえば、図１では、イベントストリームソース表現１１０へのアクセスが行われる。イベントストリームソース表現は１つだけに限定されるわけではない。よって、別のイベントストリームソース表現へのアクセスが行われることもある（行為３０１Ｂ）。他のイベントストリームソース表現も、実行コンテキスト２００で使用可能な特定のイベントストリームを表す（ただし、図２には示されていない）。例として、イベントストリームソース１１０が最新イベントストリームであり、追加のイベントストリームソース（図示せず）が履歴イベントストリームである可能性がある。変換は、入力の最新イベントストリームの履歴タイムシフトバージョンを実行することを含む可能性がある。
【００２８】
[0034]  変換モジュールへのアクセスも行われる（行為３０２）。たとえば、図１では、変換モジュール１３０へのアクセスが行われ得る。また、イベントストリームシンク表現へのアクセス（行為３０３）も、コンテキスト特定コンポーネントへのアクセス（行為３０４）と共に行われ得る。たとえば、実行モジュール１６１は、変換モジュール１３０、イベントストリームシンク表現１２０、およびコンテキスト特定コンポーネント１５０にアクセスする可能性がある。
【００２９】
[0035]  次に、実行モジュールは、変換モジュールを解釈し（行為３１０）、変換セットを実行コンテキスト２００で１つまたは複数の特定された入力イベントストリームに対して実行して、結果のイベントストリームを生成する。そうするために、実行モジュール１６１は、コンテキスト特定モジュール１５０内のコンテキスト特定を使用する。たとえば、実行モジュールは、変換コンポーネント２３０等の変換コンポーネントのインスタンスを取得する（行為３１１）。また実行モジュールは、イベントストリームソース表現（イベントストリームソース表現１１０等）により特定された任意のイベントストリームソース（イベントストリームソース２１０等）に変換コンポーネントを結合する（行為３１２）。また実行モジュールは、イベントストリームシンク表現（イベントストリームシンク表現１２０等）により特定された任意のイベントストリームシンク（イベントストリームシンク２２０等）に変換コンポーネントを結合する（行為３１３）。次に、変換コンポーネント２３０が実行され得る（行為３１４）。
【００３０】
[0036]  図１に戻り、オーサリングモジュール１４１は、イベントストリームソース表現１１０、イベントストリームシンク表現１２０、クエリ変換モジュール１３０、およびコンテキスト特定コンポーネント１５０を形成するために作成者により使用され得るプログラミング抽象化のセット１４０を含む。たとえば、抽象化１４０は、抽象化１４１〜１４４を含むものとして示されている。ただし、省略記号１４５は、イベントストリーム表現１１０および１２０ならびにモジュール１３０および１５０をオーサリングするためにプログラマにより使用される任意の数の抽象化が存在し得ることを表している。
【００３１】
[0037]  本明細書で記載される実施形態では、イベントストリームソース１１０およびイベントストリームシンク１２０の身元および種類が、おそらくはイベントストリームソース１１０自体の特定および／またはイベントストリームシンク１２０自体の特定の変更を除いて、クエリ変換モジュール１３０に何らかの根本的な変更を加えることなく、変更され得る。
【００３２】
[0038]  たとえば、図１の例では、抽象化１４０の１つが、イベントストリームソース（イベントストリームソース１１０等）を特定するために使用され得る。以下は、ITemporalSourceDefinitionインターフェイスと呼ばれる抽象化の例である。もちろん、本明細書で記載される特定の抽象化の名前は、いずれも任意のものである。より重要なのは、抽象化の機能である。以下は、ITemporalSourceDefinitionインターフェイスを使用する例示的なＨＴＴＰソース定義である。
【００３３】
【数１】
2017527024.tif 000003
【００３４】
[0039]  時間的ソース（上記定義されたＨＴＴＰソース等）は、仮想時間で順序付けられたイベントを作り出す。時間的ソースは、ソースの種類に応じて、何らかの具体的なパラメータを持つことができる。たとえば、一部の種類の時間的イベントストリームソースでは、クエリ名が関連性を有する可能性がある。他の種類の時間的イベントストリームソースは、タイムスタンプ選択またはグループ化キーセレクタを有する可能性がある。
【００３５】
[0040]  分散シナリオでは、イベントストリームソース（たとえばイベントストリームソース２１０）がイベント（たとえばイベント２０１等）を順序違いで受け取る可能性がある。イベントストリームソースは、仮想時間を追跡する。イベントが受け取られると、イベントストリームソースは、そのイベントと関連付けられた時点を判断し、アプリケーション時間を適切に進める。しかし、イベントは順序違いで到着することがあるため、一部のイベントは、現在のアプリケーション時間よりも前のタイムスタンプでイベントストリームソースに到着する可能性がある。言い換えると、イベントは、仮想時間に反して、過去にタイムスタンプが設定される。
【００３６】
[0041]  タイムスタンプＴ１、Ｔ２、およびＴ３を有する３つのイベントがある状況を考える。アプリケーション時間に従うと、タイムスタンプＴ１は、タイムスタンプＴ２よりも前であり、タイムスタンプＴ２は、タイムスタンプＴ３よりも前である。これらのイベントが異なるルートをとってイベントストリームソースに届いた場合、タイムスタンプＴ１およびＴ３のイベントが先に到着し、その後でタイムスタンプＴ２のイベントが到着する可能性がある。タイムスタンプＴ３のイベントが到着したときにイベントストリームソースが仮想時間をＴ３に動かすと、タイムスタンプＴ２のイベントに対して何をすればよいかわからなくなる。
【００３７】
[0042]  時間的イベントストリームソースには、ユーザが順序違いで到着するイベントの問題に対処するのを支援するパラメータが２つある。パラメータの１つは、「調整」または「破棄」のいずれかとなり得る順序違いポリシーである。調整ポリシーを適用すると、現在の仮想時間を下回るタイムスタンプを有するすべてのイベントに、現在の仮想時間でタイムスタンプが再設定される。破棄ポリシーを適用すると、それらのイベントがすべて破棄される。ただし、他の種類の順序違いポリシーがイベントストリームソースにより強要される可能性がある。別の順序違いポリシーの例として、イベントが順序違いで到着することにより、結果のイベントストリームに対するクエリを中止させる「中止」ポリシーがある。
【００３８】
[0043]  順序違いイベントの許容を実現するもう１つのパラメータは、句読点（punctuation）生成設定である。句読点生成設定は、サービスが入力の仮想時間をどのように進めるべきかを定義する。イベントが順序違いで届いたが、ユーザが順序違いポリシーによりそれらのイベントにタイムスタンプを再設定するのを望まない場合、ユーザは、仮想時間前進関数を使用して、ソースに対して句読点をどのように生成するかを明示的に設定することができる。仮想時間前進関数は、現在の仮想時間と、バッファされたすべてのイベントのリストとを入力として受け取り、新しい仮想時間を返す。たとえば、仮想時間の１０秒の遅延を許容するために、ユーザは以下の関数を提供することができる。
【００３９】
【数２】
2017527024.tif 000004
【００４０】
[0044]  抽象化１４０のもう１つの例は、結果のイベントストリームが向かうイベントストリームシンク２２０を特定し、潜在的に定義するための抽象化である。本明細書の例では、そのような抽象化はITemporalSinkDefinitionインターフェイスと呼ばれる。以下は、ITemporalSinkDefinitionインターフェイスを使用するイベントストリームシンク定義のサンプルである。
【００４１】
【数３】
2017527024.tif 000005
【００４２】
[0045]  クエリ変換モジュール１３０自体と関連付けられたクエリは、クエリ変換モジュール１３０にイベントストリームソース１１０を関連付ける抽象化を使用して、クエリ変換コンポーネント１３０のインスタンス２３０が実行されたときにインスタンスが入力イベントストリーム２１１を対応するイベントストリームソース２１０から受け取る態様で定義され得る。これを行うために使用され得る抽象化１４０の例は、本明細書では「From」メソッドと呼ばれる。
【００４３】
[0046]  また、クエリ変換モジュール１３０と関連付けられたクエリは、クエリ変換コンポーネント１３０にイベントストリームシンク１２０を関連付ける抽象化を使用して、クエリ変換コンポーネント１３０のインスタンス２３０が実行されたときにインスタンスが出力イベントストリーム２２１を対応するイベントストリームシンク２２０に提供する態様で定義され得る。これを行うために使用され得る抽象化１４０の例は、本明細書では「To」メソッドと呼ばれる。
【００４４】
[0047]  以下は、さまざまな抽象化１４０を使用してイベントソースを定義し、イベントストリームシンクを定義し、クエリロジックを定義し、クエリロジックを定義されたイベントソースおよびイベントシンクに接続する、例示的なエンドツーエンドクエリである。
【００４５】
【数４】
2017527024.tif 000006
この例で、イベントストリームソースはＨＴＴＰソースであり、クエリロジックはマシンごとの平均ＣＰＵ利用率の計算を含む。
【００４６】
[0048]  本明細書で記述されるイベント処理プログラミングモデルは、そのユーザが、低遅延で、インクリメンタルで、スケールアウトされた、信頼性のある、データの計算を表現することを可能にする。データの取り扱いおよびデータの計算について、以下に説明する。上述したように、データはイベントストリームに編成される。各イベントストリームは、経時的に添付されるデータの潜在的に無限のコレクションを記述する。たとえば、各イベントは、データと、関連するタイムスタンプとからなる。データの計算はクエリによって表され、クエリはグラフとして表すことができる。よって、クエリを定義するとき、ユーザは基本的な構成単位（たとえば、イベントソースおよびイベントシンクの定義）を使用してデータ変換のグラフ構造を定義し、さらに関連する変換自体を定義する。そのようなクエリ定義は、宣言的に実行され得る。
【００４７】
[0049]  たとえば、図４は、変換プロセスを示すフローグラフを示している。図４で、ユーザはパフォーマンスカウンタソース定義を取得し、フィルタ（「where」）変換および選択変換を適用し、すべてをキューに出力している。このグラフを（たとえば、開始コマンド１６０の実行による）実行のために（コンテキスト特定コンポーネント１５０により特定されるような）適切なコンテキストに送ると、グラフが計算のサービス内で実行される。サービスは、実行時にグラフを解釈してグラフを実行する。サービスは、パフォーマンスカウンタから実行時データを取得し、それをフィルタ処理して投影（project）し、キューに出力する。このグラフの実行時インスタンス化はクエリである。よって、イベント処理プログラミングモデルは、実行時エンティティにマップする定義エンティティからなる。
【００４８】
[0050]  定義エンティティは、データフローおよびそれらの計算を宣言的に記述するために使用される。これらの概念は、挙動を定義するだけであり、いかなる実行時成分も持たない。たとえば、「フィルタ」の定義は、着信するデータが何らかの述語に応じてフィルタ処理されることを指定する。プログラミング言語と比較して言うと、定義は、クラスに類似する。クエリの組み立てはクライアント側でイベント処理プログラミングモデルを使用して行われるが、クエリの実際のインスタンス化および実行はイベント処理エンジン（任意の場所の任意のデバイスに存在し得る）で行われる。
【００４９】
[0051]  よって、実行時エンティティは、定義を実現する実行インスタンスである。実行時エンティティは、イベント処理エンジンまたはサービスによりホストおよび実行され、データの実際の処理を行う。実行時エンティティは、プログラミング言語におけるオブジェクトに類似する。たとえば、実行時には、イベントストリームソース１１０のインスタンスが動作し、クエリ変換チェーン１３０のインスタンスが動作し、イベントストリームシンク１３０のインスタンスが動作している。
【００５０】
[0052]  次に、Ｃ＃プログラミング言語を使用して例示的クエリを実行するためにイベント処理プログラミングモデルを実装する方法の例を示す。この例では、ＨＴＴＰエンドポイントが存在し、部屋のすべてのセンサが現在の温度を送ると仮定する。このシナリオでは、いずれかのセンサからの１分間のウィンドウにわたる平均温度がセ氏９０度を超えた場合に、アプリケーションがアラームを生成する必要がある。さらに、アラームをＡｚｕｒｅキューに書き込む必要がある。以下は、対応するＣ＃のクエリ例であり、クエリロジック、使用するイベントストリームソース、使用するイベントストリームシンク、クエリが実行されるコンテキスト、および対応する開始コマンドを表している。後ほど参照および整理するために、行番号と適切なスペースが設けられている。
【００５１】
【数５】
2017527024.tif 000007
【００５２】
[0053]  この例では、クエリは５つの論理ステップで実装されている。１行目で、クエリが実行されるコンテキストが特定される。これは、図１のコンテキスト特定コンポーネント１５０の例である。この例では、図１の抽象化１４０の例を表すServiceContextメソッドを使用して、コンテキストが取得される。
【００５３】
[0054]  ２行目で、イベントストリームソースが定義される。この例では、イベントストリームソースはＨＴＴＰイベントストリームソースである。ただし、イベント処理エンジンは、幅広い種類のイベントストリームソースを処理することが可能であり得る。よって、抽象化１４０は、異なる種類のイベントストリームソースのための組み込みサポートを含み得る。ソースを定義するとき、ユーザはイベントの種類（この場合はTemperature）を選択することができる。特定の種類のソースに固有の何らかの他のパラメータ（この例ではingressUriのような）が存在する可能性がある。２行目の呼び出しの最後のパラメータは、図１の抽象化１４０の別の例であるグループ化条件である。クエリでは、クエリで定義されるすべての操作がグループの各メンバに個別に適用されるようにするために、何らかのキーで特定されるそのようなグループ化条件を使用することがある。上記の例では、クエリはSensorIdによりグループ化される。つまり、Average／Where／Select操作（５〜１０行目）は、各センサからのデータに独立して適用されることになる。２行目は、図１のイベントストリームソース１１０の例である。
【００５４】
[0055]  ３〜４行目で、イベントストリームシンクが定義される。イベントストリームシンクは、出力データ（たとえば、出力イベントストリーム）がどこに行き着くかを定義する。上記の例では、３〜４行目は、データをＡｚｕｒｅキューに書き込むシンクを指定している。３〜４行目は、図１のイベントストリームシンク１２０の例である。
【００５５】
[0056]  ５〜１０行目には、データをソースからシンクに変換するクエリロジック自体がある。クエリは、相互に組み合わされた異なるソース／シンク定義からなる。この例では、まず１分間のウィンドウの平均が計算される。その後、温度が９０度を超えるすべてのイベントがフィルタ処理される。それらすべてのイベントについて、「select」変換を使用してアラームが作成される。５〜１０行目は、図１のクエリ変換コンポーネント１３０の例である。
【００５６】
[0057]  １１行目で、クエリがイベント処理サービス内で実行される（１１行目）。最後の操作により、クエリの実行インスタンスが、イベント処理サービスで指定された名前により作成される。クエリをサービスに送るために、ユーザは１行目で取得されたサービスコンテキストを使用する。よって、１１行目は、図１の開始コマンド１６０の例である。
【００５７】
[0058]  この例はＣ＃で与えられているが、イベント処理プログラミングモデルは言語非依存であり得る。たとえば、イベント処理プログラミングモデルは、Ｃ＃、Ｊａｖａ（登録商標）Ｓｃｒｉｐｔ等を含むさまざまな言語でＳＤＫを提供し得る。
【００５８】
[0059]  前の節で紹介したイベントソース定義の概念は、イベント処理プログラミングモデルでライブデータと履歴データとの間、ならびにデバイスから生じたデータとクラウドから生じたデータとの間で体験を一元化することを可能にする。プログラミングモデルの観点から見ると、データがその場で生成されているか（HttpSourceの場合のように）、またはテーブルから取得されているか（AzureTableSourceの場合のように）は問題ではなく、特定のソース定義の詳細に過ぎない。デバイスから生じたソース定義と、クラウドから生じたソース定義についても同様である。異なる種類のデータソースを一元化することで、プログラミングモデルは、ユーザがクエリのビジネスロジックに専念することを可能にする。ビジネスロジックは、将来的にデータソースが変更されても変化しない。たとえば、図１では、ユーザはクエリ変換コンポーネント１３０のオーサリングに専念することができ、一方で基本的な抽象化１４０を使用して適切なソース、シンク、およびコンテキスト特定を定義することができる。
【００５９】
[0060]  前のシナリオに戻り、ユーザは、ＨＴＴＰソース（上述した例の２行目）を生成する代わりに、およびすべてのデータをクラウドにプッシュしてそこで解析する（上述した例の１行目および１１行目）代わりに、デバイスでインスタンス化される組み込みのデバイスソース定義（たとえば、後述する例の１行目のservice.GetDeviceSource）を使用することができる。コードの例は以下のようになる。
【００６０】
【数６】
2017527024.tif 000008
【００６１】
[0061]  データ変換ロジック（〜１０行目）は、まったく変わっていない。主な違いは２つだけである。第１に、１行目のソース定義が（前の例の２行目と比べて）わずかに変更されて、ソースをデバイスで使用可能なものとして特定している。第２に、前の例の１行目が削除され、１０行目の開始コマンドがデフォルトコンテキスト（たとえば、デバイスで使用可能なイベント処理サービス）で実行されるようになっている。これで、サービス自体が、クエリをより良く分散および実行する方法を決定することができる。上記の例の場合、平均の計算、温度のフィルタ処理、およびアラームの生成をデバイスで発生させつつ、アラームイベントを必要なときにのみクラウドに伝搬させることが考えられる。同じ方法で、リレーショナルデータベースを表すソース定義にクエリ計算の一部をプッシュしたり、実行エンジンをマップ／低減したりすることができる。
【００６２】
[0062]  （イベント処理プログラミングモデルの原理とＡＰＩ）
[0063]  この節では、イベント処理プログラミングモデルの背後にある主な原理について論じ、例示的なアプリケーションプログラミングインターフェイスの要素をより詳しく紹介する。
【００６３】
[0064]  仮想時間で動作するイベント計算の場合、アプリケーション時間を進める方法が必要である。典型的に、イベント処理エンジンでは、仮想時間の前進は句読点と呼ばれる特別なイベントにより伝えられる。クエリ処理時に、仮想時間は句読点イベントにより駆動される。句読点イベントは、この具体的な入力に対してタイムラインの特定部分がそれ以上変化しないことをサービスに伝えることにより、イベントをコミットし、計算結果をクエリ出力にリリースするために使用される。句読点を時間Ｔでキューに入れることにより、入力は、Ｔより前の期間に影響を与えるであろう後続イベントを作り出さないことを約束する。これは、入力で句読点がキューに入れられた後、他のすべてのイベントの仮想時間はキューに入れられた句読点を下回らないことを暗示する。このルールの違反は、「句読点違反」と呼ばれる。句読点違反に対処するためのポリシーにはさまざまなものがあり得る（すなわち、イベントの破棄、クエリの中断、またはイベント時間の調整）。
【００６４】
[0065]  イベント処理プログラミングモデルでは、すべてのイベントを句読点と考えることもできる。よってユーザは、データフローに句読点を明示的に挿入する義務はない。ただし、ユーザがステートフルな演算子の現在の状態をフラッシュするときなど、句読点が依然として使用されるケースもある。たとえば、以下に示す図５の例を考えてみる。この例では、１０分間のタンブリングウィンドウの平均が考慮される。
【００６５】
[0066]  図５では、演算子は、期間Ｔ２に属する仮想時間を持つ次のイベントを確認するまで、期間Ｔ１の出力を生成することができない。これは、イベントが均等に分散しておらず、新しいイベントが期間Ｔ２の最後にくる場合に、長い遅延につながる可能性がある。これに対処するため、ユーザは、時間を前に動かす句読点を発行し、演算子に現在のウィンドウを閉じさせることができる（右側の絵）。
【００６６】
[0067]  仮想時間を動かすことに加えて、「on error」句読点や「on complete」句読点などの他の種類の句読点も存在し得る。「on error」句読点は、イベント処理中にエラーが発生した場合に、下流の演算子に伝えられる。「on complete」は、この入力のイベントがそれ以上見込まれないときに発行される。
【００６７】
[0068]  イベント処理プログラミングモデルは、演算子に再現性を提供する。演算子は、同じ初期状態および同じ入力で同じ出力を決定的に作り出すときに、再現性を有する。再現性欠如の主な原因は２つある。すなわち、演算子が非決定性であることと、（タイマなどの物理的な時間に依存する演算子の場合のような）等価の入力を提供できないことである。非決定性の演算子は、内部的に非決定性な演算子（状態が何らかの形式のランダム関数／外的変化状態に依存する）と、入力が非決定性な演算子、すなわち出力が異なる入力間のイベントの順序に依存する演算子とにさらに細分化することができる。
【００６８】
[0069]  （グループ化）
[0070]  イベント処理プログラミングモデルは、グループ化の概念を使用したイベント処理計算の柔軟なスケールアウトを提供する。たとえば、以下のクエリはグループ化を使用する。
【００６９】
【数７】
2017527024.tif 000009
【００７０】
[0071]  イベント処理プログラミングモデルのイベントストリームは、ユーザが指定したグループ化キーを使用して、非結合のグループに細分化され得る。よって、イベントの各ストリームは、キーの一意の値にそれぞれ対応したサブストリームのセットである。クエリのすべての演算子は、各サブストリームに独立して適用され、状態を共有しない。上記のクエリでは、ユーザは各サブストリームの独立した結果を受け取る。たとえば、マシンごと、５分間の時間ウィンドウごとに、１つの平均ＣＰＵ使用率を受け取る。
【００７１】
[0072]  この例では、グループ化の概念は、本明細書でRegroupBy演算子と呼ばれる、キーセレクタをパラメータとして受け取る抽象化１４０の１つの例により公開される。グループ条件が指定されていない場合、データフローを、すべてのイベントを含む単一の論理グループとして見ることができる。
【００７２】
[0073]  一部のイベントストリームソースは、便宜上、グループ関数をパラメータとして受け取ることもできる。そのようなイベントストリームソース定義の例として、var table = service. GetAzureTableSource<int,CpuReading> (..., e => e.Machineld);がある。
【００７３】
[0074]  すべてのイベントに対して動作するために、ユーザは定数を返すキーセレクタでデータフローを再グループ化することができる。
【００７４】
[0075]  （例示的なＡＰＩ）
[0076]  この節では、主なＡＰＩコンストラクト要素（それぞれが図１の抽象化１４０の例である）の例について詳述する。ただし、これは単なる例である。
【００７５】
[0077]  （定義エンティティの要約）
[0078]  ソース：イベントストリームを作り出す機構または計算を定義する。たとえば、HTTPSourceDefinitionは、特定のＨＴＴＰ  ＵＲＬに送信されたすべての要求からイベントのストリームを作成する機構を定義する。
【００７６】
[0079]  シンク：イベントストリームを消費する機構または計算を定義する。たとえば、AzureBLOBSinkDefinitionの例は、イベントのストリームをＡｚｕｒｅ  ＢＬＯＢに格納する機構を定義する。
【００７７】
[0080]  QueryDefinition：ソースからすべてのイベントを受け取ってシンクに入れる計算を定義する。たとえば、HTTPSource(ingressUri)からすべてのイベントを受け取り、AzureBLOBSink(blobUri, storageAccountConnectionString)に入れる。
【００７８】
[0081]  （実行時エンティティの要約）
[0082]  ただしこれは、クエリを消費する基盤のイベント処理サービスに大きく依存する。
【００７９】
[0083]  クエリ：QueryDefinitionから作成されるクエリは、ソース（SourceDefinitionからインスタンス化される）からすべてのイベントを受け取ってシンク（SinkDefinitionからインスタンス化される）に入れる実行時計算を表す。
【００８０】
[0084]  ストリーム：サービスの施設（facility）であるストリームは、イベント処理サービスによりホストおよび制御されるストリームからインスタンス化されるイベントストリームである。サービスは、イベントを消費または作り出すソースおよびシンクを、ストリームに提供する。
【００８１】
[0085]  （イベントとストリーム）
[0086]  イベントはレコードであり、キー・値／連想コレクションである。値は、プリミティブ型（.net/JSON）、配列、または連想コレクション(maps/dictionaries)のいずれかになり得る。
【００８２】
[0087]  ストリームは、順序付きの時間的イベントに対する決定性を提供する。同じ順序付きの入力と、同じクエリとを与えられた場合、ストリームは常に同じ順序付きの出力を生成する。
【００８３】
[0088]  イベントストリームは、その時間的および順序付きの性質により特徴付けられる。ストリームのソースはISourceを実装する。ソースは、グループ化のためのセレクタ表現を使用して構成することができる。これらの要素のいずれかが欠落している場合、基盤のソースは、その特定の要素に対してデフォルトの挙動を使用することになる。以下は、例示的なISource定義である。
【００８４】
【数８】
2017527024.tif 000010
【００８５】
[0089]  イベントストリームのシンク（ISinkを実装）は、イベントストリームの時間的および順序付きの属性を維持する。
【００８６】
【数９】
2017527024.tif 000011
【００８７】
[0090]  イベントストリームは、グループに細分化され得る。グループは、グループ化キーにより指定される。実際上、この場合、イベントストリームは、キーの一意の値にそれぞれ対応したサブストリームのセットである。計算は、各サブストリームに独立して適用される。再グループ化コンストラクトを使用して、グループ化を変更することができる。グループにまたがるすべてのイベントに対して動作するために、ユーザはすべてのグループを１つのグループに再グループ化することができる。
【００８８】
[0091]  （サービスコンテキスト）
[0092]  クエリは、サービスの内部で展開される。サービスは、クエリ定義を処理し、Start／Stopクエリなどのクエリで管理操作を実行することができる。サービスコンテキストを初期化する簡単なジェスチャは、以下のようになり得る。
【００８９】
【数１０】
2017527024.tif 000012
【００９０】
[0093]  （From／To）
[0094]  クエリは、ISourceをパラメータとして受け取り、イベントストリームに対して使用可能な演算子のセットを定義するIGroupedStreamインターフェイスを返す、Temporallnput.From(source)ジェスチャから始まるかたちで定義される。IGroupedStreamは、分割されたイベントストリームを表す。クエリ定義は、ISinkをパラメータとして、IGroupeStreamに関してToジェスチャが呼び出されたときに返される。
【００９１】
[0095]  （SteamR演算子）
[0096]  （フィルタ（where））
[0097]  各個別イベントに適用されるユーザ定義の述語表現に基づき、どのイベントをグループ化ストリームで維持または削除するかを決定する。
【００９２】
【数１１】
2017527024.tif 000013
【００９３】
[0098]  （投影（select））
[0099]  各個別イベントにユーザ表現を適用し、潜在的に異なる種類の新しいイベントを作り出す。以下のコード例は、フィルタ処理および投影の使用方法を示している。
【００９４】
【数１２】
2017527024.tif 000014
【００９５】
[00100]  （マルチキャスト／ユニオン（multicast／union））
[00101]  マルチキャスト演算子は、各グループ化ストリームの複数のコピーを作成する（グループメンバシップ／キーはマルチキャストにより変更されない）。ユニオン演算子は、複数のグループ化ストリームを単一のグループ化ストリームに組み合わせる（グループメンバシップ／キーは変更されず、同じキーを持つイベントは同じグループになる）。順序はユニオンにより維持される。
【００９６】
[00102]  （アグリゲート（aggregate））
[00103]  アグリゲート演算子は、アグリゲート関数をグループ化ストリームのサブセットに適用する。このウィンドウを、時間的属性（ウィンドウ期間等）、各グループの個別のイベントの数（カウントウィンドウ）、またはサブセットの開始および終了を定義する述語（フレームまたは条件ベースのウィンドウ）により定義することができる。アグリゲート関数は、Average、Min、Max、Count、SumおよびStdDevである。
【００９７】
[00104]  アグリゲートは以下のように設定され得る。
【００９８】
【数１３】
2017527024.tif 000015
【００９９】
[00105]  マルチアグリゲート計算もサポートされる。ＡＰＩは、いくつかのアグリゲート関数をペイロードに適用することを可能にする。以下の例は、イベントペイロードへの３つのアグリゲート関数の適用を示している。
【０１００】
【数１４】
2017527024.tif 000016
【０１０１】
[00106]  （トップＫ（topK））
[00107]  トップＫは、グループ化ストリームのサブセットを形成するイベントをランク付けし、グループ化ストリーム内のグループごとに上位Ｋ個の値を出力として作り出すアグリゲート関数である。このサブセット（またはウィンドウ）を、時間的属性（ウィンドウ期間等）、各グループの個別のイベントの数（カウントウィンドウ）、またはサブセットの開始および終了を定義する述語（フレームまたは条件）により定義することができる。トップＫは、上記コードスニペットにおける関数の適用と同じ方法で適用される。
【０１０２】
[00108]  （ウィンドウ定義（*window））
[00109]  ウィンドウは、カウント（カウントウィンドウ）、条件、または時間的属性（ウィンドウ期間等）に基づいて、イベントのサブセットをバッファする。このサブセットに、演算子の任意のセットを適用することができる。タンブリングウィンドウ演算子のコード例を以下に示す。
【０１０３】
【数１５】
2017527024.tif 000017
【０１０４】
[00110]  イベント処理プログラミングモデルは、いずれもウィンドウ演算子から継承される４つの具体的なウィンドウを定義する。これらは、CountWindow、ConditionalWindow、TumblingWindow、およびHoppingWindowである。
【０１０５】
[00111]  （再グループ化／マージ（regroupBy／merge））
[00112]  再グループ化演算子は、各個別イベントに新しいキーイング関数を適用することにより、イベントグループのメンバシップを再定義する。出力として、再グループ化演算子は、新しいキーに基づくグループ化ストリームの新しいセットを作り出す。マージ演算子は、単に再グループ化に基づくマクロであり、キーは一定の値である（結果として、すべてのイベントが同じグループメンバシップを有し、すなわち、１つだけのグループによるグループ化ストリームのセットとなる）。
【０１０６】
【数１６】
2017527024.tif 000018
【０１０７】
[00113]  （結合（join））
[00114]  結合は、その最も簡単な形式では、カウントウィンドウ上で２つのグループ化ストリームを相関させる。
【０１０８】
[00115]  （時間的結合（temporalJoin））
[00116]  一対のイベントに適用されるユーザ定義の述語表現およびユーザ定義の投射表現に基づき、所与の時間的ウィンドウ（期間）内で２つのグループ化ストリームを相関させる。
【０１０９】
[00117]  （タイムトラベル結合）
[00118]  ２つのグループ化ストリームを相関させるという点で時間的結合に類似するが、さらに、一群のグループ化ストリームのいずれかの履歴を回顧することができる（タイムトラベルとも言う）。以下は、履歴ストリームとライブストリームによるクエリの例である。
【０１１０】
【数１７】
2017527024.tif 000019
【０１１１】
[00119]  タイムトラベル結合は、もう少し詳しく説明するに値する特別な演算子である。ライブデータおよび履歴データの高度な分析を可能にするために、イベント処理プログラミングモデルは、タイムトラベルを備える時間的結合を導入することができる。上述した例は、典型的なシナリオを表している。
【０１１２】
[00120]  この演算子を使用すると、履歴データを時間的に遡り（rightTimeTravelShiftパラメータに応じてイベントを再生し、そのタイムスタンプを変更する）、それをＣＥＤＲ時間的結合によりライブストリームと相関させることができる。rightDurationパラメータは、履歴イベントの期間をどのように変更してライブストリームのポイントイベントと結合できるようにするかを指定する。タイムトラベル結合の非常に興味深いところは、ライブストリームのタイムラインにより駆動されるという点である。
【０１１３】
[00121]  最も簡単な実装では、完全な履歴ストリームが時間の開始から読み取られ、ライブストリームと結合される。ただし、これは多くの場合に望ましくない。なぜなら、履歴ストリームは不要なデータを多く含む可能性があり、ライブストリームと履歴ストリームを時間で揃えるまでにかなりの時間がかかる可能性があるからである。たとえば、履歴ストリームが過去１０年間のデータを含む場合、実際に結合できる部分に到達するまでに、９年分のデータを事前処理する必要がある。
【０１１４】
[00122]  図６は、最新イベントストリームと履歴イベントストリームの２つのイベントストリームの結合と関連付けられたイベントフローを示す。開始時点からのすべてのイベントを繰り返す代わりに、興味があるのは過去１年間のデータだけであることを履歴ストリームのソースに伝えるほうが効率的である。興味がある時間位置を、クエリのコンパイル段階で判断することはできない。開始時間位置は、結合がライブストリームから最初のイベントを受け取ったときに初めて検出される。
【０１１５】
[00123]  （マッピング）
[00124]  これまで説明してきたユーザサーフェス層は、簡単な標準データ変換（「where」、「select」等）を定義して、煩雑性をユーザから隠す役割を果たす。この層は、クライアント側のＳＤＫまたはＤＳＬにより表される。この層は、特定のプログラミング言語のサービスエンティティのクライアント側プロキシを含み、組み立てのための手段を提供する。この層で、ユーザは組み込みの定義を取得し、それらをクエリに組み立てることができる。
【０１１６】
[00125]  この層のもう１つの役割は、言語依存のＳＤＫエンティティを、言語に依存せず、エンティティ組立層により理解することが可能な内部表現に変換することである。このプロセスは、正規化と呼ばれる。このプロセスでは、後でクラウドまたはエッジで実行されるエンジンでマップすることが可能な何らかの規準的な形式で、クエリをマップする。実際のイベント処理エンジンは異なる種類のものが存在し得るが、ユーザにとってはどれも同じである。
【０１１７】
[00126]  本文書では、イベントプログラミングモデルの概念について記述した。イベント処理プログラミングモデルは、ストリーム処理の異なる次元を一元化し、オフラインの分析とオンラインの分析の便利な統合と、クラウド内のデータとデバイス上のデータの収集とを、拡張可能かつ直観的な態様で実現する。
【０１１８】
[00127]  さまざまな定義のオーサリングはコンピューティングシステムを使用して実行される可能性があり、対応するクエリはコンピューティングシステムを使用して実行されるため、次に、例示的なコンピューティングシステムについて説明する。
【０１１９】
[00128]  コンピューティングシステムは、今日、ますます多様な形式をとりつつある。コンピューティングシステムは、たとえば、ハンドヘルドデバイス、アプライアンス、ラップトップコンピュータ、デスクトップコンピュータ、メインフレーム、分散コンピューティングシステム、さらには従来コンピューティングシステムとは考えられていなかったデバイス等であり得る。本明細書および特許請求の範囲において、「コンピューティングシステム」という用語は、少なくとも１つの物理的かつ有形のプロセッサと、当該プロセッサにより実行され得るコンピュータ実行可能命令を保持することができる物理的かつ有形のメモリとを含む任意のデバイスまたはシステム（またはそれらの組み合わせ）を含むものとして幅広く定義される。メモリは、任意の形式をとり得、コンピューティングシステムの性質および形式に依存し得る。コンピューティングシステムは、ネットワーク環境に分散され得、複数の構成コンピューティングシステムを含み得る。
【０１２０】
[00129]  図７に示すように、コンピューティングシステム７００は、その最も基本的な構成において、少なくとも１つのハードウェア処理ユニット７０２と、メモリ７０４とを典型的に含む。メモリ７０４は、物理システムメモリであり得、揮発性、不揮発性、またはそれら２つの何らかの組み合わせであり得る。「メモリ」という用語は、本明細書で、物理ストレージ媒体等の不揮発性大容量ストレージを指すためにも使用され得る。コンピューティングシステムが分散されている場合、処理機能、メモリ機能、および／またはストレージ機能も分散され得る。本明細書で使用される場合、「実行可能モジュール」または「実行可能コンポーネント」という用語は、コンピューティングシステムで実行され得るソフトウェアオブジェクト、ルーチン、またはメソッドを指し得る。本明細書で記述されるさまざまなコンポーネント、モジュール、エンジン、およびサービスは、コンピューティングシステムで（たとえば、独立したスレッドとして）実行されるオブジェクトまたはプロセスとして実装され得る。
【０１２１】
[00130]  以下の記述では、実施形態について、１つまたは複数のコンピューティングシステムにより実行される行為を参照しながら記述する。そのような行為がソフトウェアで実装されている場合、行為を実行する関連コンピューティングシステムの１つまたは複数のプロセッサは、コンピュータ実行可能命令を実行したことに応じて、コンピューティングシステムの操作を指揮する。たとえば、そのようなコンピュータ実行可能命令は、コンピュータプログラム製品を形成する１つまたは複数のコンピュータ可読媒体で具現化され得る。そのような操作の例として、データの操作がある。コンピュータ実行可能命令（および操作対象データ）は、コンピューティングシステム７００のメモリ７０４に格納され得る。コンピューティングシステム７００は、コンピューティングシステム７００がたとえばネットワーク７１０を通じて他のメッセージプロセッサと通信することを可能にする通信チャネル７０８をさらに含み得る。コンピューティングシステム７００は、視覚的表現をユーザに表示するために使用することができるディスプレイをさらに含む。
【０１２２】
[00131]  本明細書で記載される実施形態は、以下でさらに詳細に論じるように、たとえば１つまたは複数のプロセッサやシステムメモリのコンピュータハードウェアを含む専用コンピュータまたは汎用コンピュータを備えるか、または利用し得る。本明細書で記載される実施形態は、コンピュータ実行可能命令および／またはデータ構造を運搬または格納するために、物理媒体および他のコンピュータ可読媒体をさらに含む。そのようなコンピュータ可読媒体は、汎用コンピュータシステムまたは専用コンピュータシステムからアクセスすることができる任意の使用可能な媒体であり得る。コンピュータ実行可能命令を格納するコンピュータ可読媒体は、物理ストレージ媒体である。コンピュータ実行可能命令を運搬するコンピュータ可読媒体は、伝送媒体である。よって、限定ではなく例として、本発明の実施形態は、コンピュータストレージ媒体と送信媒体という、２つの明確に異なる種類のコンピュータ可読媒体を少なくとも備えることができる。
【０１２３】
[00132]  コンピュータストレージ媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、ＣＤ−ＲＯＭもしくは他の光ディスクストレージ、磁気ディスクストレージもしくは他の磁気ストレージデバイス、またはコンピュータ実行可能命令もしくはデータ構造の形式をした所望のプログラムコード手段を格納するために使用でき汎用コンピュータもしくは専用コンピュータからアクセスすることが可能な他の任意の物理的かつ有形のストレージ媒体を含む。
【０１２４】
[00133]  「ネットワーク」は、コンピュータシステムおよび／またはモジュールおよび／または他の電子デバイス間での電子データの移送を実現する１つまたは複数のデータリンクとして定義される。情報がネットワークまたは別の通信接続（有線、無線、または有線と無線の組み合わせのいずれか）でコンピュータに移送または提供されるとき、コンピュータはその接続を送信媒体として正しく認識する。送信媒体は、コンピュータ実行可能命令またはデータ構造の形式をした所望のプログラムコード手段を運ぶために使用でき、かつ汎用コンピュータまたは専用コンピュータからアクセスすることが可能な、ネットワークおよび／またはデータリンクを含み得る。上記事項の組み合わせも、コンピュータ可読媒体の範囲に含まれる。
【０１２５】
[00134]  さらに、コンピュータ実行可能命令またはデータ構造の形式をしたプログラムコード手段は、さまざまなコンピュータシステムコンポーネントに到達すると、送信媒体からコンピュータストレージ媒体へ（またはその逆に）自動的に移送され得る。たとえば、ネットワークまたはデータリンクを介して受け取られるコンピュータ実行可能命令またはデータ構造は、ネットワークインターフェイスモジュール（たとえば、「NIC」）内のＲＡＭにバッファされ、次いで最終的にコンピュータシステムのＲＡＭおよび／またはコンピュータシステムのより揮発性の低いコンピュータストレージ媒体に移送され得る。よって、コンピュータストレージ媒体は送信媒体をさらに（または主として）利用するコンピュータシステムコンポーネントに含まれ得ることを理解する必要がある。
【０１２６】
[00135]  コンピュータ実行可能命令は、たとえば、プロセッサで実行されたときに汎用コンピュータ、専用コンピュータ、または専用処理デバイスに特定の機能または機能のグループを実行させる命令およびデータを備える。コンピュータ実行可能命令は、たとえば、バイナリ、プロセッサにより直接実行される前に何らかの翻訳（コンパイル等）を経るアセンブリ言語等の中間形式の命令、またはソースコードであり得る。主題について構造的特徴および／または方法論的行為に固有の言語で記述してきたが、添付の特許請求の範囲で定義される主題は、上記記述された特徴または行為に必ずしも限定されないことを理解する必要がある。むしろ、記述された特徴および行為は、特許請求の範囲を実装する例示的な形式として開示されている。
【０１２７】
[00136]  当業者は、本発明がパーソナルコンピュータ、デスクトップコンピュータ、ラップトップコンピュータ、メッセージプロセッサ、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、携帯電話、ＰＤＡ、ポケットベル、ルータ、スイッチ等の多数の種類のコンピュータシステム構成を有するネットワークコンピューティング環境で実践され得ることを理解する。本発明は、ネットワークを通じて（有線データリンク、無線データリンク、または有線データリンクと無線データリンクの組み合わせにより）リンクされたローカルコンピュータシステムとリモートコンピュータシステムの両方がタスクを実行する分散システム環境でも実践され得る。分散システム環境では、プログラムモジュールは、ローカルのメモリストレージ装置とリモートのメモリストレージ装置の両方に存在する可能性がある。
【０１２８】
[00137]  本発明は、その精神または必須の特性から逸脱することなく、他の特定の形式で具現化され得る。記述された実施形態は、あらゆる点において、限定的なものではなく、単なる例示であると考えられる。よって本発明の範囲は、上記記述によってではなく、添付の特許請求の範囲によって示される。特許請求の範囲の均等の意味および範囲内に該当するすべての変更は、特許請求の範囲に含まれる。
【図１】
2017527024.tif 000020
【図２】
2017527024.tif 000021
【図３】
2017527024.tif 000022
【図４】
2017527024.tif 000023
【図５】
2017527024.tif 000024
【図６】
2017527024.tif 000025
【図７】
2017527024.tif 000026
【手続補正書】
【提出日】平成28年12月1日(2016.12.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
１つまたは複数のプロセッサで実行されたときに、前記１つまたは複数のプロセッサに、
実行コンテキストで使用可能なイベントストリームを表すイベントストリームソース表現にアクセスすることと、
前記実行コンテキストで使用可能なイベントストリームシンクを表すイベントストリームシンク表現を提供することと、
変換モジュールが、前記変換モジュールに関連付けられた１つまたは複数の入力イベントストリームに対して実行される１つまたは複数の変換の変換セットを特定し、前記変換モジュールが、前記イベントストリームを前記入力イベントストリームの１つとして特定することであって、前記変換モジュールは、前記イベントストリームソース表現及び前記イベントストリームシンク表現に関連付けられている、ことと、
実行モジュールが、前記変換モジュールを解釈して、前記特定された入力ストリームに対して前記変換セットを前記実行コンテキストで実行させて、少なくとも１つの出力イベントストリームを生成することであって、前記実行コンテキストは、ローカル、リモート、クラウドの１つである、ことと
を実行させるコンピュータ実行可能命令を有する１つまたは複数のコンピュータ可読媒体を備えるコンピュータプログラム製品。
【請求項２】
前記コンピュータ可読媒体の前記コンピュータ実行可能命令が、
作成者が前記イベントストリームソース表現および前記変換モジュールをオーサリングできるように構成されたオーサリングモジュール
をさらに備える、請求項１に記載のコンピュータプログラム製品。
【請求項３】
前記コンピュータ可読媒体の前記コンピュータ実行可能命令が、
前記実行コンテキストを前記実行モジュールに対して特定して、前記実行モジュールが前記変換セットを前記実行コンテキストで実行させることができるようにするコンテキスト特定モジュール
をさらに備える、請求項１に記載のコンピュータプログラム製品。
【請求項４】
前記コンピュータ可読媒体の前記コンピュータ実行可能命令が、
ユーザ入力が検知されたときに前記実行モジュールを開始するように構成された開始コントロール
をさらに備える、請求項１に記載のコンピュータプログラム製品。
【請求項５】
１つまたは複数の入力イベントストリームに対して変換セットを実行することにより結果のイベントストリームを生成させるコンピュータ実装方法であって、前記コンピュータ実装方法のためのコンピュータ実行可能命令を実行する１つまたは複数のプロセッサにより実行され、
実行コンテキストで使用可能な特定のイベントストリームを表すイベントストリームソース表現にアクセスすることと、
前記実行コンテキストで使用可能なイベントストリームシンクを表すイベントストリームシンク表現を提供することと、
変換モジュールが、前記変換モジュールに関連付けられた１つまたは複数の入力イベントストリームに対して実行される１つまたは複数の変換の変換セットを特定し、前記変換モジュールが、前記特定のイベントストリームを前記１つまたは複数の入力イベントストリームの１つとして特定することであって、前記変換モジュールは、前記イベントストリームソース表現及び前記イベントストリームシンク表現に関連付けられている、ことと、
実行モジュールが、前記変換モジュールを解釈して、前記特定された１つまたは複数の入力ストリームに対して前記変換セットを前記実行コンテキストで実行させて、少なくとも１つの出力イベントストリームを生成することであって、前記実行コンテキストは、ローカル、リモート、クラウドの１つである、ことと
を含む、コンピュータ実装方法。
【請求項６】
前記特定のイベントストリームが最新イベントストリームであり、前記イベントストリームソース表現が最新イベントストリームソース表現である、請求項５に記載のコンピュータ実装方法。
【請求項７】
実行コンテキストで使用可能な履歴イベントストリームを表す履歴イベントストリームソース表現にアクセスすること
をさらに含む、請求項６に記載のコンピュータ実装方法。
【請求項８】
前記１つまたは複数の変換が、前記特定のイベントストリームに適用されるフィルタ処理操作を含む、請求項５に記載のコンピュータ実装方法。
【請求項９】
前記１つまたは複数の変換が、前記結果のイベントストリームのイベントを生成するイベント生成ロジックを含み、前記イベント生成ロジックが、フィルタ処理された前記特定のイベントストリームを入力として使用する、請求項８に記載のコンピュータ実装方法。
【請求項１０】
前記１つまたは複数の変換が、前記結果のイベントストリームのイベントを生成するイベント生成ロジックを含み、前記イベント生成ロジックが、前記イベント生成ロジックが、前記特定のイベントストリームを入力として使用する、請求項５に記載のコンピュータ実装方法。
【国際調査報告】
2017527024.tif 000027
2017527024.tif 000028