JP6865219B2 - 連続クエリ処理におけるイベントバッチ処理、出力シーケンス化、およびログベースの状態記憶 - Google Patents

Description

関連出願への相互参照
本出願は、「連続クエリ処理におけるイベントバッチ処理、出力シーケンス化、およびログベースの状態記憶（“EVENT BATCHING, OUTPUT SEQUENCING, AND LOG BASED STATE STORAGE IN CONTINUOUS QUERY PROCESSING”）」と題された２０１６年５月２０日に出願された米国非仮特許出願第１５／１６１，０４３号の利益および優先権を主張し、それは、「連続クエリ処理におけるチェックポイントマーキングによるマイクロバッチ処理（“MICRO BATCHING WITH CHECKPOINT MARKING IN CONTINUOUS QUERY PROCESSING”）」と題された２０１５年１０月２２日に出願されたインド仮特許出願第５６８８/ＣＨＥ/２０１５号、「連続クエリ処理における１回だけのセマンティクスのための出力シーケンス化（“OUTPUT SEQUENCING FOR EXACT-ONCE SEMANTICS IN CONTINUOUS QUERY PROCESSING”）」と題された２０１５年１０月２２日に出願されたインド仮特許出願第５６８９号／ＣＨＥ／２０１５号、および「連続クエリ処理におけるフェイルオーバーに対するログベースの高速状態記憶」と題された２０１５年１０月２２日に提出されたインド仮特許出願第５６９０／ＣＨＥ／２０１５号の利益および優先権を主張し、各々の内容全体が、あらゆる目的のためにここに引用により援用される。

発明の背景
従来のデータベースシステムにおいて、データは、通常はテーブルの形態である１つ以上のデータベースに記憶される。そして、記憶されるデータは、構造化照会言語（ＳＱＬ）などのデータ管理言語を使用して照会および操作される。たとえば、ＳＱＬクエリは、データベースに記憶されるデータから関連するデータを識別するために定義および実行され得る。したがって、ＳＱＬクエリは、データベースに記憶されるデータの有限集合に対して実行される。さらに、ＳＱＬクエリが実行される時、それはひとたび有限データ集合に対して実行され、有限の静的結果（finite static result）を作成する。したがって、データベースは、有限の記憶されるデータ集合に対してクエリを実行するように最良に実装される。

しかしながら、いくつかの最新のアプリケーションおよびシステムは、有限のデータ集合の代わりに、連続的なデータまたはイベントのストリームの形態のデータを生成する。このようなアプリケーションの例としては、限定されるものではないが、センサーデータアプリケーション、株式相場表示装置、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム分析ツール、自動車トラフィック監視などが含まれる。このようなアプリケーションは、データストリームを処理することができる新しい種類のアプリケーションの必要を生じさせた。たとえば、温度センサーは、温度測定値を発信するように構成され得る。

これらのタイプのイベントストリームベースのアプリケーションについてのデータの管理および処理では、厳密な時間によるフォーカスを使用してデータ管理およびクエリ機能が作成される。連続的なデータの非有界集合に対する長期実行クエリ（long-running queries）を含む、異なる種類の照会メカニズムが必要である。現在、一部のベンダーはイベントストリーム処理を目的とした製品スーツを提供しているが、提供されるこれらの製品は、今日のイベント処理の需要に対処するために必要な処理の柔軟性に依然として欠けている。

イベントストリームのイベントを処理するための技術（例えば方法、システム、１つ以上のプロセッサによって実行可能なコードまたは命令を格納する非一時的なコンピュータ可読媒体）が提供される。一実施形態では、イベントストリームのイベントを処理し、システム障害が発生した場合にイベントストリーム内のイベントの回復を実行するイベント処理システムが開示される。

特定の実施形態では、複数の命令を格納するメモリと、メモリにアクセスするように構成された１つ以上のプロセッサとを備えるイベント処理システムが開示される。プロセッサは、アプリケーションに関連するイベントの連続入力ストリームを受信し、イベントの連続入力ストリームを処理して、アプリケーションに関連するイベントの出力ストリームを生成し、イベントの出力ストリームにおける出力イベントについて出力シーケンス番号を判断するよう構成される。プロセッサはさらに、イベントの出力ストリームにおける出力イベントを送信し、出力イベントの出力シーケンス番号を記憶するように構成される。いくつかの実施形態では、プロセッサは、イベントの連続入力ストリームが処理されている間に、システムの障害の表示を受信するように構成される。プロセッサは、イベントの出力ストリームにおける最も最近送信された出力イベントの現在の出力シーケンス番号を判断し、最も最近処理された入力イベントのバッチに対応する出力イベントの最後の出力シーケンス番号を判断し、現在のシーケンス番号および最後の出力シーケンス番号に基づいて送信されるべき出力ストリームの１つ以上の出力イベントのセットを判断するよう構成される。いくつかの実施形態では、プロセッサは、さらに、アプリケーションに関連する１つ以上の出力イベントのセットを送信するように構成される。

いくつかの実施形態では、プロセッサは、さらに、送信されるべき１つ以上の出力イベントのセット内の１つ以上の出力イベントを除外するように構成される。いくつかの実施形態では、プロセッサは、システムの障害の表示を受信することに基づいて、イベントの出力ストリームにおける最も最近送信された出力イベントの現在の出力シーケンス番号から出力イベントを送信するように構成される。

いくつかの実施形態では、プロセッサは、さらに、イベントの連続入力ストリームから１つ以上のイベントバッチのセットを生成することを、チェックポイントマーカイベントを生成することと、 チェックポイントマーカイベントをイベントの連続入力ストリームに挿入することと、チェックポイントマーカイベントに基づいて１つ以上のイベントバッチのセットを生成することととによって行なうよう構成される。ある例では、チェックポイントマーカイベントは、イベントの連続入力ストリームにおける入力イベントに関連する情報を表す。ある例では、イベントバッチのサイズは、チェックポイントマーカイベントに基づいて判断される。

ある例では、プロセッサは、さらに、チェックポイントマーカイベントを処理し、チェックポイントマーカイベントの処理に基づいて、１つ以上のイベントバッチのセット内の第１のイベントバッチの処理の完了を示す確認メッセージを送信し、システムの現在の状態のスナップショットを生成するように構成される。いくつかの例では、システムの現在の状態のスナップショットは、少なくともイベントの第１のバッチに関連する入力待ち行列状態、演算子状態、または出力待ち行列状態のうちの少なくとも１つに関連する情報を含む。ある実施形態では、プロセッサは、イベントの出力ストリームにおける出力イベントの出力シーケンス番号を、スナップショットの一部として記憶するように構成される。

上記および下記の技術は、多くの方法で、および多くの状況で実施することができる。以下でより詳細に説明するように、いくつかの例示的な実現例および状況が、以下の図を参照して提供される。しかしながら、以下の実現例および状況は多くのもののうちのほんの一部である。

分散イベント処理を実行するための技術が実装され得るシステムまたはアーキテクチャ１００の簡略化された例を示す。 本開示の一実施形態を組み込むことができるイベント処理システム２００の簡略化されたハイレベル図を示す。 本開示の一実施形態によるイベント処理サービスを提供するイベント処理アプリケーション３０２を含むイベント処理システム３００の例示的な図である。 本開示の一実施形態による、イベント処理システムがイベントの正確な回復を実行することができる態様の例示である。 本開示の一実施形態による、イベント処理サービスを提供するイベント処理アプリケーション５０２を含むイベント処理システム５００の例示的な図である。 本開示の一実施形態によるイベント処理サービスを提供するための例示的なプロセス６００のフロー図を示す。 本開示の一実施形態による連続したイベントのストリームにおいてイベントを処理するための例示的なプロセス７００のフロー図を示す。 本開示の一実施形態による、出力ストリームで送信されるべき１つ以上の出力イベントのセットを判断するためのプロセス例８００のフロー図を示す。 本開示の一実施形態による、イベント処理サービスを提供するイベント処理アプリケーション９０２を含むイベント処理システム９００の例示的な図である。 本開示の一実施形態による、イベントストリーム内のイベントの処理中に識別される連続クエリの異なるタイプの演算子に対する異なるタイプのスナップショットの生成を示す例示的なテーブルである。 本発明の特定の実施形態によるイベント処理サービスを提供するためのプロセス１１００を示す例示的なフロー図を示す。 本開示の一実施形態を実施するための分散型システム１２００の簡略図を示す。 本発明の実施形態を実施するために使用され得る例示的なコンピュータシステム１３００を示す。

発明の詳細な説明
以下の説明では、さまざまな実施形態について説明する。説明のために、具体的な構成および詳細は、実施形態の完全な理解を提供するために記載される。しかしながら、実施形態が具体的な詳細なしに実施されてもよいことも、当業者には明らかであろう。さらに、周知の特徴は、説明される実施形態を不明瞭にしないために省略または簡略化されてもよい。

複合イベント処理（ＣＥＰ）の概要
複合イベント処理（ＣＥＰ）は、イベント駆動型アーキテクチャに基づいてアプリケーションを構築するためのモジュール式プラットフォームを提供する。ＣＥＰプラットフォームの中心には、アプリケーションが宣言型ＳＱＬ状言語を使用してデータのストリームに対してパターンマッチング操作をフィルタリング、照会および実行できるようにする連続問い合わせ言語（ＣＱＬ）がある。開発者はアプリケーションを書くためにＣＱＬを軽量なＪａｖａ（登録商標）プログラミングモデルと組み合わせて使用できる。他のプラットフォームモジュールには、機能豊富なＩＤＥ、管理コンソール、クラスタ化、分散キャッシュ化、イベントリポジトリ、および監視などがある。

イベント駆動型アーキテクチャおよび複合イベント処理はエンタープライズコンピューティング環境の顕著な機能となっているため、ＣＥＰ技術を使用してミッションクリティカルなアプリケーションを構築し始めている企業が増えている。今日、ミッションクリティカルなＣＥＰアプリケーションは、さまざまな業界で見出され得る。たとえば、ＣＥＰ技術は、電力産業においては、電気需要の変化に瞬時に反応できるようにすることにより、ユーティリティをより効率的にするために使用されている。ＣＥＰ技術は、クレジットカード業界では、潜在的に不正な取引がリアルタイムで発生した場合にそのような取引を検出するために使用されている。ミッションクリティカルなＣＥＰアプリケーションのリストは増加を続けている。ミッションクリティカルなアプリケーションを構築するためにＣＥＰ技術を使用することにより、ＣＥＰアプリケーションの高可用性とフォールトトレラント化が求められるに至った。

今日の情報技術（ＩＴ）環境は、金融市場およびネットワークパフォーマンスの監視から、ビジネスプロセスの実行およびＲＦＴＤタグ付き資産のトラッキングまで、あらゆることに対して連続したデータのストリームを生成する。ＣＥＰは、ビジネス処理の有効性を向上させるためにイベント処理アプリケーションを開発するための豊富で宣言的な環境を提供する。ＣＥＰは、複数のイベントストリームを処理してパターンおよび傾向をリアルタイムで検出して、企業に対して、新たな機会を活用したり開発リスクを軽減するために必要な可視性を提供する。

連続したデータのストリーム（イベントストリームとも呼ばれる）は、明示的な終了のない事実上連続的または非有界であってもよいデータまたはイベントのストリームを含むことができる。論理的に、イベントまたはデータストリームは、データ要素（イベントともいわれる）のシーケンスであり得て、各データ要素は、関連付けられたタイムスタンプを有する。連続イベントストリームは、要素のバッグまたはセット（ｓ，Ｔ）として論理的に表わされ得て、ここで「ｓ」はデータ部分を表わし、「Ｔ」は時間ドメインに属する。「ｓ」部分は、概してタプルまたはイベントといわれる。したがって、イベントストリームは、タイムスタンプを持つタプルまたはイベントのシーケンスであり得る。

一部の局面において、ストリームにおけるイベントに関連付けられるタイムスタンプは、クロックタイムと同等とされ得る。しかしながら、他の例において、イベントストリームにおけるイベントに関連付けられる時間は、アプリケーションドメインによって定義され得て、クロックタイムに対応しない場合があるが、たとえば、代わりにシーケンス番号によって表わされ得る。このため、イベントストリームにおけるイベントに関連付けられる時間情報は、数字、タイムスタンプ、または時間の概念を表わす他の情報によって表され得る。入力イベントストリームを受信するシステムについては、イベントは、タイムスタンプの増加順でシステムに到達する。同じタイムスタンプを有する２つ以上のイベントがあり得る。

一部の例において、イベントストリームにおけるイベントは、いくぶん世俗的なイベント（たとえば、温度センサーが値を新しい値に変更した場合や、株式表示記号の価格が変化した場合など）の発生を表わし得て、イベントに関連付けられる時間情報は、データストリームイベントによって表わされる世俗的なイベントが発生した場合を示し得る。

イベントストリームを介して受信したイベントについては、イベントストリームにおけるイベントが確実にタイムスタンプ値の増加順で到達するように、イベントに関連付けられる時間情報が使用され得る。これにより、イベントストリームにおいて受信されたイベントを、それらに関連付けられる時間情報に基づいて順序付けることができる。この順序付けを可能にするために、後に生成されるイベントが前に生成されるイベントよりも後のタイムスタンプを有するように、タイムスタンプがイベントストリームにおけるイベントに対して非減少の態様で関連付けられ得る。他の例として、シーケンス番号が時間情報として使用されている場合、後に生成されるイベントに関連付けられるシーケンス番号は、前に生成されるイベントに関連付けられるシーケンス番号よりも大きくなり得る。一部の例において、たとえばデータストリームイベントによって表される世俗的なイベントが同時に発生した場合に、複数のイベントが、同じタイムスタンプまたは同じシーケンス番号に関連付けられ得る。同じイベントストリームに属するイベントは、概して、関連付けられる時間情報によってイベントに対して加えられる順序で処理され得て、前のイベントは後のイベントの前に処理される。

イベントストリームにおけるイベントに関連付けられる時間情報（たとえば、タイムスタンプ）は、ストリームのソースによって設定され得る、または代替的にストリームを受信するシステムによって設定され得る。たとえば、特定の実施形態において、イベントストリームを受信するシステムに対してハートビートが維持され得て、イベントに関連付けられる時間は、ハートビートによって測定されるようにシステムへのイベントの到達の時間に基づき得る。イベントストリームにおける２つのイベントが同じ時間情報を有することは可能である。なお、タイムスタンプ順序付け要件は１つのイベントストリームに対して特定のものであるが、異なるストリームのイベントが適宜インターリーブされ得る。

イベントストリームは、関連付けられるスキーマ「Ｓ」を有し、スキーマは、時間情報と、１つ以上の指定される名前付き属性の集合とを含む。特定のイベントストリームに属するすべてのイベントは、その特定のイベントストリームに関連付けられるスキーマに準拠する。このため、イベントストリーム（ｓ，Ｔ）については、イベントストリームは、スキーマ「Ｓ」を(<time_stamp>,<attribute(s)>)として有し得て、ここで<attributes>は、スキーマのデータ部分を表わし、１つ以上の属性を含み得る。たとえば、株式相場表示装置イベントストリームについてのスキーマは、<stock symbol>および<stock price>の属性を含み得る。このようなストリームを介して受信される各イベントは、タイムスタンプと２つの属性とを有する。たとえば、株式相場表示装置イベントストリームは、以下のイベントおよび関連付けられるタイムスタンプを受け取り得る。

…
(<timestamp_N>,<NVDA,4>)
(<timestamp_N+1>,<ORCL,62>)
(<timestamp_N+2>,<PCAR,38>)
(<timestamp_N+3>,<SPOT,53>)
(<timestamp_N+4>,<PDCO,44>)
(<timestamp_N+5>,<PTEN,50>)
…
上記のストリームにおいて、ストリーム要素(<timestamp_N+1>,<ORCL,62>)については、イベントは、「stock_symbol」および「stock_value」を伴う<ORCL,62>である。ストリーム要素に関連付けられるタイムスタンプは、「timestamp_N+1」である。したがって、連続イベントストリームはイベントのフローであり、各イベントは同じ一連の属性を有する。

記載したように、ストリームはＣＱＬクエリが作用し得るデータの主要なソースであり得る。ストリームＳは、要素（ｓ，Ｔ）のバッグ（「マルチセットともいわれる）であり得て、ここで「s」はＳのスキーマに属し、「Ｔ」は時間ドメインに属する。加えて、ストリーム要素は、タプルとタイムスタンプのペアであり得て、タイムスタンプを持つタプル挿入のシーケンスとして表わされ得る。言い換えると、ストリームは、タイムスタンプを持つタプルのシーケンスであり得る。一部の場合において、同じタイムスタンプを有する２つ以上のタプルがあり得る。また、入力ストリームのタプルは、タイムスタンプの増加順でシステムに到達する必要があり得る。代替的に、リレーション（「時間で変化するリレーション」ともいわれ、リレーショナルデータベースからのデータを含み得る「リレーショナルデータ」と混同されない）は、時間ドメインからスキーマＲのタプルの非有界バッグへのマッピングであり得る。一部の例において、リレーションは、順序付けされていない、時間で変化するタプルのバッグ（すなわち、瞬間的なリレーション）であり得る。一部の場合において、時間の各瞬間では、リレーションは有界集合であり得る。これは、挿入、消去、および／または更新を含んでリレーションの変化する状態を捕捉し得る、タイムスタンプを持つタプルのシーケンスとしても表わされ得る。ストリームと同様に、リレーションは、リレーションの各タプルが準拠し得る固定スキーマを有し得る。さらに、本願明細書で使用される連続クエリは、概してストリームおよび／またはリレーションのデータを処理する（すなわち、照会する）ことが可能であり得る。加えて、リレーションは、ストリームのデータを参照し得る。

一部の例において、ビジネスインテリジェンス（ＢＩ）は、特定の間隔で（たとえば、一部の場合においては毎日）事業実施の運営および最適化を補助し得る。このタイプのＢＩは、通常、オペレーショナルビジネスインテリジェンス、リアルタイムビジネスインテリジェンス、またはオペレーショナルインテリジェンス（ＯＩ）と呼ばれる。オペレーショナルインテリジェンスは、一部の例において、ＢＩと事業活動の監視（ＢＡＭ）との線引きを不明瞭にする。たとえば、ＢＩは、過去データの周期的なクエリにフォーカスし得る。このようなことから、ＢＩは、後向きフォーカスを有し得る。しかしながら、ＢＩは、実施用途にも利用され得て、このため、単なる戦略的分析ツールから事業実施における前線へ拡大し得る。このようなことから、ＢＩシステムは、イベントストリームを分析し、リアルタイムで集合を演算するようにも構成され得る。

一部の例において、連続クエリ言語サービス（ＣＱサービス）は、連続クエリを取り扱うとともにリアルタイムの警告を可能にするように、ＢＩ分析サーバーを拡張するように構成され得る。ＣＱサービスは、一部の局面において、ＢＩ分析サーバーおよびＣＱＬエンジンとの統合を提供し得る。例示のみであるが、ＢＩ分析サーバーは、連続クエリをＣＱサービスに転付し得て、ＣＱサービスは、ＣＱＬエンジンのための論理データベース（ＤＢ）ゲートウェイとしても作用し得る。この方法により、ＣＱＬエンジンは、その分析能力およびセマンティックモデリングのために、ＢＩ分析サーバーを活用することが可能となり得る。

一部の例において、ＣＱサービスは、とりわけ、以下の機能を提供し得る。
・ＣＱＬエンジンゲートウェイとしてＢＩ分析サーバーのためのリモーティングサービス
・イベントソース／シンクアダプタ
・論理ＳＱＬにＣＱＬ拡張を加えたものからのデータ定義言語（ＤＤＬ）の生成
・すべてのタイプの連続クエリおよび実施選択のための統一モデルの提供
・メタデータおよびサポート再開可能性の維持
・高い利用可能性およびスケーラビリティのサポート
加えて、一部の例において、ＯＩは、事業実施に対して可視性および見識をもたらすリアルタイムの動的事業分析の形態である。大量の情報から理解可能とすることを助けるという点において、ＯＩは、ＢＩまたはリアルタイムＢＩに対してリンクまたは比較されることが多い。しかしながら、いくつかの基本的な違いがある。ＯＩは、主に活動中心的であり得て、ＢＩは主にデータ中心的であり得る。加えて、ＯＩは、進展する状況（たとえば、傾向およびパターン）を検知する、およびこれに対応するのにより適し得て、これに対してＢＩは、事後ベースおよび報告ベースの手法として従来より使用され得る。

一部の例において、事業イベント分析および監視システムは、インフライトデータを処理および／または受信するためにＣＱＬエンジンを含み得る。たとえば、ＣＱＬエンジンは、受信中のリアルタイムの情報を照会またはそれ以外に処理するように構成されるメモリ内リアルタイムイベント処理エンジンであり得る（たとえば、ＢＩまたはＯＩ）。ＣＱＬエンジンは、一時セマンティクスを利用または理解し得るとともに、データのウィンドウの定義を処理することを可能にするように構成され得る。ＣＱＬエンジンを利用することは、一部の場合において、受信中のデータに対して常にクエリを実行することを伴う。

一部の局面において、ＣＱＬエンジンは、完全に発達したクエリ言語を含み得る。このようなことから、ユーザは、クエリに関して演算を特定し得る。加えて、ＣＱＬエンジンは、メモリの最適化、クエリ言語特性の利用、演算子の共有、リッチパターンマッチング、リッチ言語構成などのために設計され得る。加えて、一部の例において、ＣＱＬエンジンは、過去データおよびストリーミングデータの両方を処理し得る。たとえば、ユーザは、カリフォルニアの販売が特定のターゲットを超えた時に警告を送るようにクエリを設定し得る。したがって、一部の例において、警告は、過去の販売データおよび受信中のライブ（すなわち、リアルタイム）販売データに基づき得る。

一部の例において、ＣＱＬエンジンまたは以下に記載されるコンセプトの他の特徴は、リアルタイムで過去のコンテキスト（すなわち、ウェアハウスデータ）と受信中のデータとを結合するように構成され得る。したがって、一部の場合において、本開示は、データベースに記憶される情報とインフライト情報との間の境界を記載し得る。データベースに記憶される情報およびインフライト情報の両方は、ＢＩデータを含み得る。このようなことから、データベースは、一部の例において、ＢＩサーバーであり得る、または任意のタイプのデータベースであり得る。さらに、一部の例において、本開示の特徴は、ユーザがどのようにプログラムするのか、またはそれ以外にどのようにコードを書くのかを知らなくとも上記の特徴の実施を可能とし得る。言い換えると、特徴は、多機能ユーザインターフェイス（ＵＩ）において提供され得る、または過去データとリアルタイムのデータとの結合を非開発者が実施することを可能とする態様で提供され得る。

一部の例において、上記のコンセプトは、複合イベント処理に関連付けられるリッチリアルタイム連続イベント処理能力を活用するために利用され得る。限定されないが、アーカイブされたリレーションなどのいくつかの特徴がサポートされ得る。このようなことから、このような特徴（たとえば、リッチリアルタイム連続イベント処理）を活用するために、システムは、リレーショナルデータのスタートアップ状態およびランタイム状態に透明に対処するように構成され得る。言い換えると、システムは、作成の瞬間おいては空でないクエリ（すなわち、アーカイブされたリレーション）を管理するように構成され得る。

一部の例において、アーカイブされたリレーションが利用され得る。このようなことから、アーカイブされたリレーションに基づくことを示すクエリをＣＱＬエンジンが確認した場合、そのアーカイブされたリレーションは、たとえば、過去のコンテキストについてクエリを呼び出すことができる特定のエンティティがあることを示し得る。一部の例において、データ定義言語（ＤＤＬ）は、照会をどのように行なうか、テーブル内の重要なカラムは何か、および／または残りのデータをどこへ送信するかなど、アーカイブされたリレーションについての注釈を示し得るが、これらに限定されない。一部の例において、ひとたびクエリがＣＱＬエンジンにおいて構築されると（たとえば、グラフとして）、システムはクエリグラフを分析し得る。加えて、一部の局面において、「distinct」、「group aggr」、「pattern」、および／または「group by」のような、ステートフルな特定の演算子がある。しかしながら、ステートレスな演算子は、入力を取り、それをたとえば下流の演算子などの親に送るのみであり得る。このため、１つの手法は、このテーブル全体をここに記憶することである。しかしながら、アーカイブされたリレーションを利用することにより、システムは、クエリグラフを分析し、アーカイブを照会するために使用することができる最低のステートフル演算子がどれかを決定し得る。一部の例において、システム（または１つ以上のコンピュータ実行方法）は、グラフを横断しながら到達した最低のステートフル演算子において状態を検索し得る。たとえば、クエリグラフは、ソースからのトポロジー順序において分析され得る。この第１のステートフル演算子に基づき、ＣＱＬエンジンは、アーカイブされたリレーションに対して定義されるクエリについての演算子の状態を初期化するために、取得されるデータの最適量を判定し得る。

少なくとも１つの非限定的な例において、リレーションおよび／またはソースのようなソース演算子は、トポロジー横断線において最初に置かれ得て、クエリ出力および／またはルートは最後に置かれ得る。たとえば、ＣＱＬクエリが、select sum(c1) from R1 where c2>c25のような場合、このクエリについてのプランは、RelationSource→SELECT→GroupAggrのようになり得る。したがって、トポロジー順序に従うとともに、RelationSourceおよびSELECTが両方ともステートレスであることから、最低のステートフル演算子はGroupAggrであり得る。この方法により、クエリのステートフル演算子（この例では、GroupAggr）は、クエリエンジンがストリーミングデータを受信する前にデータストアから過去データをクエリエンジンに集合させることを可能にし得る。これは、アーカイブされたリレーションをクエリが分析しており、そのアーカイブされたリレーションがそのように示されているという事実に基づいて可能となり得る。

一部の例において、所与のアーカイブされたリレーションのウィンドウサイズは、ユーザによって指定され得る。一部の局面において、ウィンドウは、アーカイブされたリレーションに関連して、受信中のストリーミングされたコンテンツを分析またはそれ以外に評価するクエリグラフにおけるノードを含み得る。言い換えると、ウィンドウは、クエリエンジンによって分析および／または処理されるストリーミングされたコンテンツの量、および／またはアーカイブされたリレーションに含まれる過去データの量を定義し得る。

高いレベルにおいて、ひとたびウィンドウがStreamに対して適用されると、それはRelationとなり、リレーショナルデータベースと同様に、通常のリレーショナルロジックが適用され得る。タプルが到着してウィンドウを離れると、考慮中のRelationは、それに対してコンパイルされるクエリによって変化し、同時に結果を発する。ＣＱＬは、RANGE（ナノ秒粒度に至る）、ROWS、PARTITION BY、および拡張可能ウィンドウをサポートし得る。これらのウィンドウは、ストリームからリレーションへの演算子（stream-to-relation operators）の例である。他方、ISTREAM（すなわち、挿入ストリーム）、DSTREAM（すなわち、削除ストリーム）、およびRSTREAM（すなわち、リレーションストリームは、リレーションからストリームへの演算子（relation-to-stream operators）である。一部の例において、ユーザ、開発者、および／または管理者は、クエリエンジンまたはクエリエンジンを操作またはホスティングする１つ以上のコンピューティングシステムによって提供されるウィンドウサイズを（たとえば、ＵＩを介して）設定し得る。一部の例において、ストリーム上のウィンドウは、時間ベースの範囲ウィンドウであり得る。たとえば、アーカイブされたリレーション上のコンフィギュラブル値ウィンドウは、ウィンドウサイズおよびウィンドウが計算される属性を使用して特定され得る。アーカイブされたリレーションの上部に特定されるコンフィギュラブル値ウィンドウがある場合、スナップショットクエリが演算され得て、ウィンドウ限界内のスナップショットタプルが出力され得る。加えて、状態の初期化後、値ウィンドウは、受信中のアクティブデータに対して適用され得る。一部の例において、ウィンドウ属性の値がウィンドウサイズよりも小さい現在イベント時間とは異なるウィンドウには受信中のアクティブデータのみが挿入される。

さらに、いくつかの例では、本開示の特徴は、リアルタイムデータ分析をサポートするために、ＣＱＬエンジンおよび／またはＣＥＰエンジンの連続クエリ処理能力を活用することもできる。いくつかの態様では、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、従来はストリーム指向型分析エンジンであったかもしれない。しかしながら、それは、耐久性のあるストア（たとえば、上記のアーカイブされたリレーション）によってバックアップされるストリーム指向のデータをサポートするように拡張することができる。たとえば、本開示は、耐久性のあるストア（データベースおよび／またはテーブル）であるデータオブジェクト（ＤＯ）の概念をサポートすることができる機能について説明する。ＤＯに対して行われる変更は、事実上データストリームを作成する関心のあるリスナーに対して変更通知をブロードキャストさせ得る。このデータストリームは、実行中のクエリのサポートにおいてＣＱＬエンジンおよび／またはＣＥＰエンジンによって消費され得る。しかしながら、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、ＤＯバッキングストア内の既存のデータを考慮に入れて設計されていなかった可能性がある。たとえば、ＣＱＬエンジンおよび／またはＣＥＰエンジンは、ＣＱＬエンジンおよび／またはＣＥＰエンジンで実行されているクエリの初期状態が現在ＤＯバッキングストアにあるすべてのデータを含むＤＯの現在の状態を反映することを要求し得る。このクエリがそのように初期化されると、ＣＱＬエンジンおよび/またはＣＥＰエンジンは、従来のストリーム指向のスタイルにおいて、その時点から、ＤＯ変更通知のストリームに関わる必要があるだけである。

いくつかの態様では、ＣＱＬエンジンおよび／またはＣＥＰエンジンはストリームまたはアーカイブされていないリレーションを従来的に処理し得、したがって初期状態は存在しないかもしれない。たとえば、クエリがロードされ得、それは、実行および変更のリスニングを開始し得る。場合によっては、ユーザが棒グラフで州別に売上を求めた後、誰かが新たな販売を行なった場合、テーブルが更新され、ユーザはグラフの変更が売上に表示されるのを見ることを予想し得る。しかしながら、ダッシュボードを閉じて１週間後に戻って販売を改めると、ユーザは合計された売上データのテーブルに従って売上の合計を得ることを予想し得る。言い換えれば、クエリは、クエリをアーカイブの状態にしてから、アクティブな変更をリスニングする必要があってもよい。

いくつかの態様では、たとえば、ＣＱＬエンジンは、アーカイブされたデータで事前に初期化されてもよい。初期化されると、ＣＱＬエンジンは、（たとえば、アーカイブからのデータの挿入、削除などのためにＡＰＩ呼び出しに基づいて）変更通知についてJava Messaging Service（ＪＭＳ）または他のメッセンジャーをリスニングすることができる。したがって、サービスはリスニングすることができ、ＪＭＳがリスニングサービスがリスニングしているのと同じトピックでパブリッシュする場合、それはデータを受信し得る。サービスは、誰がパブリッシュしているのか、またはそれらがそうしているのか否かを知る必要はない。リスニングサービスはただリスニングすることができ、何かが起こった場合、リスニングサービスはそれを聞き得る。いくつかの例では、これは、持続性の、たとえばそれのコンシューマからの分離方法である。さらに、いくつかの例では、アラートエンジンは、アラートエンジンが聞くもの、潜在的には、そしてさらには、リスナーに関連するプロセスクエリを聴取しているかもしれないＳＱＬエンジンに基づいて、アラートを生成し得る。

いくつかの例では、ＣＱＬ、ＳＱＬ、および／またはＣＥＰエンジンでクエリを開始し得、アーカイブデータを取得して（たとえば、ポンプをプライミングし）次いでこれらのＪＭＳメッセージを聞き始めるよう、命令を構成してもよい。しかしながら、挿入、削除などが多数あると、大量の情報が含まれる可能性がある。さらに、リスナーがメッセージを聞くまでにタイムラグがあることがあり、リスニングは、いくつかの例では、飛び込んで、アーカイブに照会し、戻ってきて、リスニングを開始し得る。したがって、イベントの喪失および／または二重カウントの可能性がある。

さらに、エンジンが単にクエリを実行する場合、クエリを実行している間にさまざまなものがＪＭＳに入り、エンジンがリスニングしていなかったところでパブリッシュされ得る。そのため、リスナーを最初にセットアップし、アーカイブクエリを実行してから戻って実際に待ち行列から引き出して、何も見逃さないように、エンジンを構成してもよい。したがって、ＪＭＳはさまざまなものを待ち行列に入れ得、そしてそれらがバックアップされる場合、エンジンがクエリを行なっている間は大丈夫であり、なぜならばそれはあとでキャッチアップでき、それが同期しているかどうかを心配する必要はないからである。それがここになく、聞いている場合、それはそれを見逃すことはなく、それのリスナーが確立されている限り、エンジンが戻ってくるまでただ待ち行列に入れられる。

さらに、いくつかの例では、システムコラムをユーザのデータに追加することができる。このシステムコラムは、ダブルカウントおよび／または喪失操作問題を処理しようとするトランザクションＩＤを示すためのものであってもよい。しかしながら、他の例では、システムは、トランザクションコンテキストテーブルを提供するか、そうでなければ生成することができる。さらに、２つの追加のコラムTRANSACTION_CIDおよびTRANSACTION_TIDが存在してもよい。コンテキストテーブルは、最後にコミットされたトランザクションＩＤのスレッド（コンテキスト）様式を知るために、持続性サービスによって常に維持されてもよい。トランザクションＩＤは、スレッド（コンテキスト）の昇順でコミットされることが保証され得る。たとえば、サーバは、起動すると、持続性サービスを実行してもよい。各々は、事前初期化された情報のデータがＪＭＳを通過したすべてのデータを含むかどうかを判断するためのコンテキストＩＤとトランザクションＩＤとのセットを割り当てることができる。さらに、いくつかのケースでは、（ＪＴＡに準拠して、および/または高可用性（ＨＡ）を実現するために、複数の出力サーバを利用することができ、各サーバは、他のサーバによって管理される他のテーブルとは完全に別個のコンテキスト/トランザクションテーブルの単一セットを管理してもよい。

いくつかの実施形態では、連続的な（たとえばＣＱＬ）クエリが作成または登録されると、それは構文および意味論解析を受けてもよく、その最後に論理クエリプランが作成される。たとえば、 "alter query <queryname> start" ＤＤＬを発行してＣＱＬクエリを開始すると、論理クエリプランは物理クエリプランに変換されてもよい。一例では、物理クエリプランは、物理演算子の有向非循環グラフ（ＤＡＧ）として表されてもよい。次に、物理演算子を実行演算子に変換して、そのＣＱＬクエリの最終クエリプランに到達してもよい。ＣＱＬエンジンへの入来イベントは、ソース演算子に到達し、最終的に、演算子のイベントでの処理を実行し、適切な出力イベントを生成する方法で、演算子とともに下流に移動する。

上記および下記の技術は、いくつかの方法およびいくつかの状況において実施され得る。以下においてより詳細に記載されるように、いくつかの例示的な実施および状況が以下の図面を参照して提供される。しかしながら、以下の実施および状況は多くのうちの一部である。

例示的システム
図１は、分散型イベント処理を実行するための技術が実施され得る、簡易化された例示的なシステムまたはアーキテクチャ１００を示す。アーキテクチャ１００において、１人以上のユーザ１０２が、コンピューティングデバイス１０４（１）〜１０４（Ｎ）（まとめて、「ユーザデバイス１０４」）を利用し、１つ以上のネットワーク１０８を介して１つ以上のサービスプロバイダコンピュータ１０６にアクセスし得る。一部の局面において、サービスプロバイダコンピュータ１０６は、ネットワーク１０８を介して、１つ以上のストリーミングデータソースコンピュータ１１０および／または１つ以上のデータベース１１２と通信し得る。たとえば、ユーザ１０２は、サービスプロバイダコンピュータ１０６を利用し、ストリーミングデータソースコンピュータ１１０および／またはデータベース１１２のデータにアクセスし得る、またはそれ以外にデータを管理し得る（たとえば、１１０および１１２のうちのいずれかまたは両方に対してクエリが実行され得る）。データベース１１２は、リレーショナルデータベースまたはＳＱＬサーバーなどであり得て、一部の例においては、過去データ、イベントデータ、リレーション、またはアーカイブされたリレーションなどをユーザ１０２の代わりに管理し得る。加えて、データベース１１２は、ストリーミングデータソースコンピュータ１１０によって提供されるデータを受信またはそれ以外に記憶し得る。一部の例において、ユーザ１０２は、ユーザデバイス１０４を利用し、データ（たとえば、過去のイベントデータ、ストリーミングイベントデータなど）についてのクエリ（「クエリ宣言」ともいう）または他のリクエストを提供することによってサービスプロバイダコンピュータ１０６と対話し得る。そして、このようなクエリまたはリクエストは、サービスプロバイダコンピュータ１０６によって実行され、データベース１１２のデータおよび／またはストリーミングデータソースコンピュータ１１０からの受信中のデータが処理され得る。さらに、一部の例において、ストリーミングデータソースコンピュータ１１０および／またはデータベース１１２は、サービスプロバイダコンピュータ１０６に関連付けられる、統合された分散環境の一部であり得る。

一部の例において、ネットワーク１０８は、ケーブルネットワーク、インターネット、無線ネットワーク、携帯電話ネットワーク、イントラネットシステム、ならびに／または他の私的および／もしくは公共ネットワークなど、複数の異なるタイプのネットワークのうちの１つまたはこれらの組み合わせを含み得る。示される例は、ユーザ１０２がネットワーク１０８を介してサービスプロバイダコンピュータ１０６にアクセスすることを表わしているが、記載の技術は、ユーザ１０２が固定電話で１つ以上のユーザデバイス１０４を介して、キオスクを介して、または他の方法により１つ以上のサービスプロバイダコンピュータ１０６と対話する場合においても等しく適用され得る。また、記載の技術は、他のクライアント／サーバー構成（たとえば、セットトップボックスなど）および非クライアント／サーバー構成（たとえば、ローカルに記憶されるアプリケーションなど）においても適用され得る。

ユーザデバイス１０４は、携帯電話、スマートフォン、パーソナルデジタルアシスタント（ＰＤＡ）、ラップトップコンピュータ、デスクトップコンピュータ、シンクライアントデバイス、タブレットＰＣなどの任意のタイプのコンピューティングデバイスであり得るが、これらに限定されない。一部の例において、ユーザデバイス１０４は、ネットワーク１０８を介して、または他のネットワーク接続を介して、サービスプロバイダコンピュータ１０６と通信し得る。さらに、ユーザデバイス１０４は、データベース１１２（または他のデータストア）の処理されるデータを要求するための１つ以上のクエリまたはクエリ宣言を提供するようにも構成され得る。

一部の局面において、サービスプロバイダコンピュータ１０６は、モバイル、デスクトップ、シンクライアント、および／またはサーバーのようなクラウドコンピューティングデバイスなど、任意のタイプのコンピューティングデバイスでもあり得るが、これらに限定されない。一部の例において、サービスプロバイダコンピュータ１０６は、ネットワーク１０８を介して、または他のネットワーク接続を介してユーザデバイス１０４と通信し得る。サービスプロバイダコンピュータ１０６は、場合によってはクラスターにおいて、サーバーファームとして、または互いに関連付けられていない個別のサーバーとして構成される１つ以上のサーバーを含み得る。これらのサーバーは、本願明細書において記載されるイベント処理を含むが、それに限定されない、本願明細書に記載される特徴を行なう、またはホスティングするように構成され得る。加えて、一部の局面において、サービスプロバイダコンピュータ１０６は、ストリーミングデータソースコンピュータ１１０および／またはデータベース１１２を含む、統合された分散コンピューティング環境の一部として構成され得る。

１つの例示的な構成において、サービスプロバイダコンピュータ１０６は、少なくとも１つのメモリ１１４と１つ以上の処理ユニット（プロセッサ）１２６とを含み得る。プロセッサ１２６は、ハードウェア、コンピュータ実行可能命令、ファームウェア、またはこれらの組み合わせにおいて適切に実施され得る。プロセッサ１２６のコンピュータ実行可能命令またはファームウェアの実施は、記載される様々な機能を行なうために任意の適したプログラミング言語で書かれたコンピュータ実行可能命令またはマシン実行可能命令を含み得る。

メモリ１１４は、プロセッサ１２６上でローディング可能および実行可能なプログラム命令ならびにこれらのプログラムの実行時に生成されるデータを記憶し得る。サービスプロバイダコンピュータ１０６の構成およびタイプに応じて、メモリ１１４は、揮発性（ランダムアクセスメモリ（ＲＡＭ）など）および／または不揮発性（読み取り専用メモリ（ＲＯＭ）、フラッシュメモリなど）であり得る。サービスプロバイダコンピュータ１０６またはサーバーは、追加の記憶部１２８も含み得て、この記憶部１２８は、リムーバブル記憶部および／または非リムーバブル記憶部を含み得る。追加の記憶部１２８は、磁気記憶部、光学ディスク、および／またはテープ記憶部を含み得るが、これらに限定されない。ディスクドライブおよびこれに関連付けられるコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、およびコンピューティングデバイスのための他のデータの不揮発性記憶部を提供し得る。一部の実施において、メモリ１１４は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、ダイナミックランダムアクセスメモリ（ＤＲＡＭ）、またはＲＯＭなどの複数の異なるタイプのメモリを含み得る。

メモリ１１４ならびにリムーバブルおよび非リムーバブルの両方の追加の記憶部１２８は、すべてコンピュータ可読記憶媒体の例である。たとえば、コンピュータ可読記憶媒体は、コンピュータ可読命令、データ構造、プログラムモジュール、もしくは他のデータなどの情報の記憶のための任意の方法もしくは技術において実施される、揮発性もしくは不揮発性のリムーバブルまたは非リムーバブル媒体を含み得る。メモリ１１４および追加の記憶部１２８は、すべてコンピュータ記憶媒体の例である。

サービスプロバイダコンピュータ１０６は、記憶されるデータベース、他のコンピューティングデバイスもしくはサーバー、ユーザ端末、および／またはネットワーク１０８上の他のデバイスとそれが通信することを可能にする通信接続１３０も含み得る。サービスプロバイダコンピュータ１０６は、キーボード、マウス、ペン、音声入力デバイス、タッチ入力デバイス、ディスプレイ、１つ以上のスピーカー、プリンターなどの入力／出力（Ｉ／Ｏ）デバイス１３４も含み得る。

より詳細にメモリ１１４の内容を見ると、メモリ１１４は、オペレーティングシステム１１６と、本願明細書に開示される機能を実施するための１つ以上のアプリケーションプログラムまたはサービスとを含み得る。一実施形態では、メモリ１１４は、アプリケーションに関連する入力ストリームを処理して、アプリケーションに関連するイベントの出力ストリームを生成するように構成されたイベント処理サービス１１８を含むことができる。一実施形態では、イベント処理サービスは、イベントバッチ生成部１２０、系統トラッキングモジュール１２２、出力シーケンス番号生成部１２４、イベント回復モジュール１２６、およびスナップショット持続期間判断モジュール１２４などの１つ以上のモジュールを含んで、ここに記載されるイベント処理サービスを実現することができる。本明細書で使用される場合、モジュールは、サービスの一部であるサーバまたはサーバのクラスタによって実行されるプログラミングモジュールを指し得る。この特定の状況では、モジュールは、サービスプロバイダコンピュータ１０６の一部であるサーバまたはサーバのクラスタによって実行されてもよい。

本開示のいくつかの実施形態では、サービスプロバイダコンピュータ１０６は、イベント処理システムとして実施されてもよい。図２は、本開示の一実施形態を組み込むことができるイベント処理システム２００の単純化されたハイレベル図を示す。イベント処理システム２００は、１つ以上のイベントソース（２０４，２０６，２０８）と、イベントストリームを処理するための環境を提供するように構成されたイベント処理サービス（ＥＰＳ）２０２（ＣＱサービス２０２とも称される）と、１つ以上のイベントシンク（２１０，２１２）とを備え得る。イベントソースは、ＥＰＳ２０２によって受信されるイベントストリームを生成する。ＥＰＳ２０２は、１つ以上のイベントソースから１つ以上のイベントストリームを受信し得る。たとえば、図２に示されるように、ＥＰＳ２０２は、イベントソース２０４から第１の入力イベントストリーム２１４を受信し、イベントソース２０６から第２の入力イベントストリーム２１６を受信し、イベントソース２０８から第３のイベントストリーム２１８を受信する。１つ以上のイベント処理アプリケーション（２２０，２２２および２２４）がＥＰＳ２０２上にデプロイされてＥＰＳ２０２によって実行され得る。ＥＰＳ２０２によって実行されるイベント処理アプリケーションは、１つ以上の入力イベントストリームをリスニングし、注目イベントとして入力イベントストリームから１つ以上のイベントを選択する処理論理に基づいて、１つ以上のイベントストリームを介して受信したイベントを処理するように構成され得る。次いで、当該注目イベントは、１つ以上の出力イベントストリームの形態で１つ以上のイベントシンク（２１０，２１２）に送信され得る。たとえば、図２では、ＥＰＳ２０２は、第１の出力イベントストリーム２２６をイベントシンク２１０に出力し、第２の出力イベントストリーム２２８をイベントシンク２１２に出力する。特定の実施形態では、イベントソース、イベント処理アプリケーションおよびイベントシンクは、他のコンポーネントに対する変更を生じさせることなくこれらのコンポーネントのうちのいずれかを追加または除去することができるように互いに分離される。

一実施形態では、ＥＰＳ２０２は、共有サービスを有する、Equinox OSGiに基づくものなどの軽量Ｊａｖａ（登録商標）アプリケーションコンテナを備えるＪａｖａサーバとして実現され得る。いくつかの実施形態では、ＥＰＳ２０２は、たとえばJRockit Real Timeを使用してイベントを処理するための超高スループットおよびマイクロ秒レイテンシをサポートし得る。また、ＥＰＳ２０２は、イベント処理アプリケーションを開発するためのツール（たとえば、オラクルＣＥＰビジュアライザおよびオラクルＣＥＰ ＩＤＥ）を含む開発プラットフォーム（たとえば、完全なリアルタイムのエンドツーエンドＪａｖａイベント駆動アーキテクチャ（Event-Driven Architecture：ＥＤＡ）開発プラットフォーム）を提供し得る。

イベント処理アプリケーションは、１つ以上の入力イベントストリームをリスニングして、１つ以上の入力イベントストリームから１つ以上の注目イベントを選択するための論理（たとえば、クエリ）を実行し、選択された注目イベントを１つ以上の出力イベントストリームを介して１つ以上のイベントソースに出力するように構成される。図２は、１つのこのようなイベント処理アプリケーション２２０のためのドリルダウンを提供する。図２に示されるように、イベント処理アプリケーション２２０は、入力イベントストリーム２１８をリスニングして、入力イベントストリーム２１８から１つ以上の注目イベントを選択するための論理を備える連続クエリ２３０を実行し、選択された注目イベントを出力イベントストリーム２２８を介してイベントシンク２１２に出力するように構成される。イベントソースの例としては、アダプタ（たとえば、ＪＭＳ、ＨＴＴＰおよびファイル）、チャネル、プロセッサ、テーブル、キャッシュなどが挙げられるが、それらに限定されるものではない。イベントシンクの例としては、アダプタ（たとえば、ＪＭＳ、ＨＴＴＰおよびファイル）、チャネル、プロセッサ、キャッシュなどが挙げられるが、それらに限定されるものではない。

図２におけるイベント処理アプリケーション２２０は、１つの入力ストリームをリスニングして、選択されたイベントを１つの出力ストリームを介して出力するものとして示されているが、これは限定的であるよう意図されるものではない。代替的な実施形態では、イベント処理アプリケーションは、１つ以上のイベントソースから受信した複数の入力ストリームをリスニングして、監視されたストリームからイベントを選択し、選択されたイベントを１つ以上の出力イベントストリームを介して１つ以上のイベントシンクに出力するように構成され得る。同一のクエリを２つ以上のイベントシンクおよび異なるタイプのイベントシンクに関連付けることができる。

無限の性質のために、イベントストリームを介して受信されるデータの量は、一般に非常に多い。その結果、照会目的で全てのデータを格納またはアーカイブすることは、一般に非現実的であり、望ましくない。イベントストリームの処理は、受信した全てのイベントデータを格納する必要なしにイベントがＥＰＳ２０２によって受信されるときにリアルタイムでイベントの処理を必要とする。したがって、ＥＰＳ２０２は、受信した全てのイベントを格納する必要なしにイベントがＥＰＳ２０２によって受信されるときにイベントの処理を実行することを可能にする特別な照会機構を提供する。

イベント駆動アプリケーションは、ルール駆動であり、これらのルールは、入力ストリームを処理するために使用される連続クエリの形態で表現され得る。連続クエリは、クエリ処理の結果として、どのイベントを注目イベントとして選択して出力すべきかを含む、受信したイベントに対して実行される処理を識別する命令（たとえば、ビジネス論理）を備え得る。連続クエリは、データストアに留まって、イベントの入力ストリームの処理およびイベントの出力ストリームの生成に使用され得る。連続クエリは、一般に、フィルタリングおよび集計機能を実行して、入力イベントストリームから注目イベントを発見して抽出する。その結果、出力イベントストリームにおける送信イベントの数は、一般に、イベントが選択される入力イベントストリームにおけるイベントの数よりもはるかに少なくなる。

有限のデータセットに対して一度実行されるＳＱＬクエリとは異なって、ＥＰＳ２０２を有するアプリケーションによって特定のイベントストリームのために登録された連続クエリは、当該イベントストリームにおいてイベントが受信されるたびに実行され得る。連続クエリの実行の一部として、ＥＰＳ２０２は、連続クエリによって指定された命令に基づいて、受信したイベントを評価して、連続クエリの実行の結果として、１つ以上のイベントを注目イベントとして選択すべきか否かを判断して出力する。

連続クエリは、さまざまな言語を使用してプログラミングされ得る。特定の実施形態では、連続クエリは、オラクル社によって提供されるＣＱＬを使用して構成され、オラクルの複合イベント処理（ＣＥＰ）製品提供によって使用され得る。オラクルのＣＱＬは、イベントストリームに対して実行可能なクエリ（ＣＱＬクエリと称される）をプログラミングするために使用できる宣言型言語である。特定の実施形態では、ＣＱＬは、ストリーミングイベントデータの処理をサポートする追加の構造を有するＳＱＬに基づく。

一実施形態では、イベント処理アプリケーションは、以下のコンポーネントタイプで構成され得る。

（１）入力および出力ストリームならびにリレーションソースおよびシンクに直接インターフェイスする１つ以上のアダプタ。アダプタは、入力および出力ストリームプロトコルを理解するように構成され、イベントデータを、アプリケーションプロセッサによって照会可能な正規化された形態に変換する役割を担う。アダプタは、正規化されたイベントデータをチャネルまたは出力ストリームおよびリレーションシンクに転送し得る。イベントアダプタは、さまざまなデータソースおよびシンクについて定義され得る。

（２）イベント処理終点の役割を果たす１つ以上のチャネル。とりわけ、チャネルは、イベント処理エージェントがイベントデータに対して作用することができるまでイベントデータを待ち行列に入れる役割を担う。

（３）１つ以上のアプリケーションプロセッサ（または、イベント処理エージェント）は、正規化されたイベントデータをチャネルから消費し、クエリを使用してそれを処理して注目イベントを選択し、選択された注目イベントを出力チャネルに転送（または、コピー）するように構成される。

（４）１つ以上のビーンは、出力チャネルをリスニングするように構成され、出力チャネルへの新たなイベントの挿入によってトリガされる。いくつかの実施形態では、このユーザコードは、プレーンオールドＪａｖａオブジェクト（plain-old-Java-object：ＰＯＪＯ）である。ユーザアプリケーションは、ＪＭＳ、ウェブサービスおよびファイルライタなどの外部サービス一式を活用して、生成されたイベントを外部イベントシンクに転送することができる。

（５）イベントビーンは、出力チャネルをリスニングするように登録され得て、出力チャネルへの新たなイベントの挿入によってトリガされる。いくつかの実施形態では、このユーザコードは、ビーンがオラクルＣＥＰによって管理できるようにオラクルＣＥＰイベントビーンＡＰＩを使用し得る。

一実施形態では、イベントアダプタは、イベントデータを入力チャネルに提供する。入力チャネルは、入力チャネルによって提供されるイベント上で動作する１つ以上のＣＱＬクエリに関連付けられたＣＱＬプロセッサに接続される。ＣＱＬプロセッサは、クエリ結果が書込まれる出力チャネルに接続される。

いくつかの実施形態では、イベント処理アプリケーションのさまざまなコンポーネント、コンポーネントがどのように接続されるか、アプリケーションによって処理されるイベントタイプを記述するアセンブリファイルがイベント処理アプリケーションに対して提供され得る。イベントの選択のために連続クエリまたはビジネス論理を指定するために別々のファイルが提供されてもよい。

図２に示されるシステム２００は、図２に示されているコンポーネント以外の他のコンポーネントを有していてもよいということが理解されるべきである。さらに、図２に示される実施形態は、本開示の実施形態を組み込むことができるシステムの一例に過ぎない。いくつかの他の実施形態では、システム２００は、図２に示されるよりも多くのコンポーネントもしくは少ないコンポーネントを有していてもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。システム２００は、図１に記載されるサービスプロバイダコンピュータ１０６、パーソナルコンピュータ、ポータブルデバイス（たとえば、携帯電話またはデバイス）、ワークステーション、ネットワークコンピュータ、メインフレーム、キオスク、サーバ、またはその他のデータ処理システムを含むさまざまなタイプのシステムであってもよい。いくつかの他の実施形態では、システム２００は、システム２００の１つ以上のコンポーネントがクラウド内の１つ以上のネットワークにわたって分散される分散型システムとして構成されてもよい。

図２に示されるコンポーネントのうちの１つ以上は、ソフトウェア、ハードウェア、またはそれらの組み合わせで実現されてもよい。いくつかの実施形態では、ソフトウェアは、メモリ内に格納されてもよく（たとえば、非一時的なコンピュータ可読媒体）、メモリデバイス上に格納されてもよく、または何らかの他の物理メモリ上に格納されてもよく、１つ以上の処理ユニット（たとえば、１つ以上のプロセッサ、１つ以上のプロセッサコア、１つ以上のＧＰＵなど）によって実行されてもよい。

連続クエリ処理でイベントバッチを使用してイベントを処理する技法
上記したように、ミッションクリティカルなアプリケーションを構築するためにＣＥＰ技術を使用することにより、ＣＥＰアプリケーションの高可用性とフォールトトレラント化が求められるに至った。コンピュータシステムのあらゆる計算資源と同様に、ＣＥＰシステムは、ハードウェア障害およびソフトウェア障害の両方を被り得、それは、対処されなければ、データまたはサービス損失の可能性がある。高可用性システムは、一般に、ハードウェア、ソフトウェア、管理、監視、ポリシー、および計画の組み合わせによって、そのような障害の可能性および影響の両方を軽減しようとする。

任意のフォールトトレラントシステムでのように、フェイルオーバーで厳密に何が起こるかの詳細は、システムに提供できる忠実度のレベルに影響する。フェイルオーバーメカニズムが異なると、エンドユーザ要件、ならびにコスト、パフォーマンス、および正確さの制約によって、異なるレベルの精度が生じる可能性がある。最も好都合なレベルの忠実度は、上流側の障害が発生せず、欠落したイベントも重複したイベントも許されなかった場合に生成されたであろう全く同じイベントのストリームを下流のクライアントが見る、正確な回復である。

上述したように、イベント処理システム（たとえば２００）は、潜在的に非有界のリアルタイムデータストリームにわたってクエリを継続的に実行するように構成することができる。たとえば、イベント処理システムは、１つ以上のデータストリームを受信し、データストリームに対してクエリを登録し、新たなデータがストリームに現れるとクエリを継続的に実行することができる。このタイプの連続クエリは長期にわたって実行されるので、イベント処理システムは、更新された結果の連続ストリームをクライアントに提供することができる。

イベント処理システムは通常、入力イベントの連続ストリームを受信するので、イベント処理システムの状態は、入来イベントが到着するのと同じくらい急速に変化する可能性が高い。したがって、このシステム状態をシステム性能を失うことなく確実かつ正確に保つことが望ましい。システムの状態を保つための従来的なアプローチには、典型的には、システムの挙動の複製、システムの状態の複製、または状態を生成したイベントのストリームの保存が含まれる。これらのアプローチは、いくつかのリソース（たとえばマシン）ではうまくいくが、それらは、多数のリソースが関与する場合、非効率的なリソース利用をもたらす傾向があり、なぜならば、これらのリソースの一部が、アイドリング状態であるか、またはイベントの処理を再び繰り返す場合があるからである。

本開示の一実施形態では、イベント処理システムの状態は、１つ以上のイベントバッチ内のイベントの連続入力ストリームを処理することによって保存されてもよい。本明細書で使用されるように、イベントバッチは、ある期間にわたってバッチ化またはグループ化された連続入力イベントストリームの一連のイベントを含むことができる。一実施形態では、イベント処理システムは、イベントバッチを生成するために、所定の時間間隔でチェックポイントマーカイベントを連続入力イベントストリームに挿入することができる。したがって、一実施形態では、イベント処理システムは、チェックポイントマーカイベントに基づいて、イベントバッチのサイズおよび／またはイベントバッチの間隔を判断することができる。チェックポイントマーカイベントは、連続イベントストリーム内のイベントに関連する情報および／またはメタデータを含むイベントを表すことができる。いくつかの例では、チェックポイントマーカイベントは、ハートビートイベントを表すことができる。他の例では、チェックポイントマーカイベントは、チェックポイントマーカなどの特別な種類のイベント、通常のイベント、ＰＬＵＳイベント、ＭＩＮＵＳイベント、ハートビートイベントなどを表すことができる。

イベント処理システムが、イベントバッチを生成するためにチェックポイントマーカイベントを連続入力イベントストリームに導入する頻度および／または時間の間隔を判断することができるさまざまな方法がある。一例では、チェックポイントマーカイベントを挿入する時間の間隔は、ストリーミングアプリケーションのタイプ、およびイベントがストリーミングアプリケーションによって生成される頻度に基づいて判断されてもよい。たとえば、イベント処理システムは、財務データに関連するイベントをストリーミングする財務アプリケーションに対しては、チェックポイントマーカがイベントストリームに１０分ごとに挿入されると判断してもよく、一方、ネットワークトラフィックに関連するイベントをストリーミングするセンサアプリケーションについては、マーカは５分ごとにストリームに挿入されると判断してもよい。他の例では、イベント処理システムは、アプリケーションによって生成されたイベントのサイズ、アプリケーションによって生成されたイベントのレイテンシ要件などに基づいて、時間の間隔を判断することができる。いくつかの例では、イベント処理システムは、ユーザ情報、サンプリング情報、組織によって使用される最善の実務などに基づいて時間の間隔を判断することができる。

いくつかの実施形態では、イベント処理システムは、入力イベントストリームを監視し、クエリ実行計画を使用してシステム状態の推定サイズを計算することができる。たとえば、入力イベントの平均数が１０００／秒であり、イベントの平均サイズが１ｋであり、「ストックから価格を選択［範囲１分］」のようなクエリがイベントストリーム上で実行されるイベントストリームを考える。この例では、クエリ実行プランにはクエリ演算子RangeWindowおよびProjectが含まれており、システム状態の推定サイズは、瞬間で１０００＊６０（秒）＊１ｋ＝６０Ｍと計算され得、なぜならば、システム状態は、通常、RangeWindow演算子のシノプシスから計算されるからである。このシステム状態の推定サイズは、移動平均を使用してさらに平均化することができ、しきい値と比較して、チェックポイントマーカをいつイベントストリームに挿入するかを判断することができる。

本開示の特定の実施形態では、イベント処理システムは、チェックポイントマーカイベントを処理するように構成されてもよい。チェックポイントマーカイベントが完全に処理されると、イベント処理システムは、チェックポイントマーカイベントを含むイベントストリームのイベントのセット（すなわちイベントバッチ）も完全に処理されたことを示すチェックポイント確認メッセージを受信するように構成されてもよい。次に、イベント処理システムは、システムの現在の状態のスナップショットの生成をトリガするように構成されてもよい。本明細書で説明されるように、スナップショットは、ある時間間隔にわたって連続クエリの１つ以上の演算子によって処理された（たとえばイベントバッチからの）イベントのセットに関する情報を含むことができる。

上記のようなイベントバッチ内のイベントの処理は、システムパフォーマンスを向上させる結果となり、なぜならば、イベントバッチ内のすべての個々のイベントを処理するのではなく、各イベントバッチ内のチェックポイントマーカイベントのみが処理されるからである。システム障害が発生した場合、チェックポイントマーカイベントの後に発生したイベントのみが再処理される必要がある。したがって、システムの回復時には、障害の前および状態をチェックポイントマーカイベントにリコンサイルした後に発生したイベントのみを再処理して再生する必要がある。イベント処理システムが、チェックポイントマーカイベントを使用してイベントのバッチを処理する方法については、図３に関連して詳細に説明する。

図３は、本開示の一実施形態による、イベント処理サービスを提供するイベント処理アプリケーション３０２を含むイベント処理システム３００の例示図である。一実施形態では、イベント処理アプリケーション３０２は、イベント処理システムによって提供されるイベント処理サービス（たとえば図２に示す２０２など）の一部であってもよい。図３に示される実施形態では、イベント処理アプリケーション３０２は、入力チャネル３０４と、ＣＱＬプロセッサ３０６と、出力チャネル３０８とを含む。イベント処理システム３００は、図３に示すコンポーネント以外のコンポーネントを有してもよい。図３において示される実施の形態は、この発明の実施の形態を組込んでもよいイベント処理システムの単なる１つの例である。他のいくつかの実施の形態では、イベント処理システム３００は、図３において示されるよりも多数もしくは少数のコンポーネントを有してもよく、または２つ以上のコンポーネントを組合せてもよく、またはコンポーネントの異なる構成もしくは配置を有してもよい。

入力チャネル３０４は、アプリケーションに関連するイベントの連続入力ストリームを受信し、イベントの連続入力ストリームから１つ以上のイベントバッチのセットを生成するように構成される。一実施形態では、入力チャネル３０４は、イベントバッチ生成モジュール３１０を含むことができる。イベントバッチ生成モジュール３１４は、チェックポイントマーカイベントを所定の時間間隔で連続入力イベントストリームに導入することによって、イベントバッチを生成するように構成することができる。上述のように、イベントバッチ生成モジュール３１０がチェックポイントマーカイベントをイベントストリームに挿入することができる所定の時間間隔は、イベントの連続ストリームを生成するストリーミングアプリケーションのタイプに基づいて判断されてもよい。所定の間隔はまた、イベントがストリーミングアプリケーションによって生成される頻度、アプリケーションによって生成されるイベントのサイズ、アプリケーションによって生成されるイベントのレイテンシ要件、ユーザ情報、サンプリング情報、組織によって使用される最善の実務などに基づいて判断されてもよい。さらに、上述したように、チェックポイントマーカイベントは、ハートビートイベントまたは新たなイベントタイプを有するイベントによって表される特別なイベントである。

ＣＱＬプロセッサ３０６は、イベントバッチ内のイベントのセットを処理するように構成することができる。一実施形態では、イベントの処理は、各イベントバッチにおけるチェックポイントマーカイベントの処理を含むことができる。いくつかの実施形態では、ＣＱＬプロセッサ３０８は、系統トラッキングモジュール３１２を含むことができる。系統トラッキングモジュール３１２は、チェックポイントマーカイベントの系統トラッキングを行うことによって、チェックポイントマーカイベントを処理するように構成されてもよい。ここで説明するように、系統トラッキングは、入力イベントの派生イベント（系統）の有向グラフを処理することにより、イベントストリーム中のイベントの信頼できるデータ処理を行うための技術を指す。入力イベント（たとえばチェックポイントイベント）のイベントのグラフ全体を処理することにより、信頼できるデータ処理と、障害が発生した場合に処理を再開する能力とが保証される。

一実施形態では、系統トラッキングアルゴリズムをチェックポイントマーカイベントに適用することができる。一例では、チェックポイントマーカイベントは、システムの現在の状態のスナップショットが生成される前までの状態に依然として寄与する各入力ストリーム上の最も古いイベントの識別子を指してもよい。チェックポイントマーカイベントは、ハートビートイベントと同様に入力ストリームに注入することができる。チェックポイントマーカイベントは、各演算子がチェックポイントマーカイベントをその子演算子に送信することができるパススルーイベントと同様であってもよい。一実施形態では、チェックポイントマーカイベントの系統トラッキングは、Twitter（登録商標） Corporationによって提供されるＳｔｏｒｍオープンソースストリーム処理システムによって使用される技術を使用して実行されてもよい。Ｓｔｏｒｍによって使用される技法の例示的な実現例は、イベント識別子の排他的論理和演算を使用し、以下のように説明することができる。
・ソースによって放出されるすべてのイベントは、ランダム識別子（ＩＤ）でマークされる。各ソースについて、フレームワークは各初期イベントごとにペアの組（イベントＩＤ、署名）を維持する。署名は、最初に、イベントＩＤによって初期化される。
・下流のノードは、受信したイベントに基づいてゼロ個以上のイベントを生成できる。各イベントは、独自のランダムＩＤと初期イベントのＩＤとを担持する。
・グラフにおいて次のノードがイベントを正常に受信して処理した場合、このノードは、対応する初期イベントの署名を（ａ）入来イベントのＩＤおよび（ｂ）入来イベントに基づいて生成されたすべてのイベントのＩＤとＸＯＲすることにより、署名を更新する。
・イベントは複数の入来イベントに基づいて生成することができる。
・イベントは、それの署名がゼロになるとすぐに正常に処理されたとみなされ、つまり、最終ノードが、グラフ内の最後のイベントが正常に処理されたことが確認される。

チェックポイントマーカイベントが系統トラッキングモジュール３１２によって完全に処理されたことを検出すると、系統トラッキングモジュール３１２は、チェックポイント終了マーカイベントを生成する。チェックポイント終了マーカイベントを受信すると、出力チャネル３０８は、チェックポイント確認メッセージを入力チャネル３０４に送信する。これは、システムの現在の状態のスナップショット３２０の生成をトリガする。一実施形態では、システムの現在の状態のスナップショット３２０は、イベントストリーム内のイベントの処理されたバッチに関連する入力待ち行列状態、演算子状態、または出力待ち行列状態のうちの少なくとも１つに関連する情報を含む。本明細書で説明するように、入力待ち行列状態は、入力チャネルの状態を指す。一実施形態では、以下で詳細に説明するように、入力チャネルは、記憶機構（たとえば、Apache（登録商標）Corporationによって提供されるKafka）を使用してもよく、入力チャネルの状態は、データ記憶システム（例：Kafkaストレージ）からの読出オフセットを含んでもよい）。いくつかの例では、読出オフセットは、入力イベントが関連付けられているストレージコンテナ（たとえばKafkaトピック）の現在の位置を示すことができる。出力待ち行列状態は、出力チャネルの状態を指す。一実施形態では、出力トリミングが使用されるとき、出力チャネルの状態は出力シーケンス番号を含むことができる。出力シーケンス番号および出力トリミングに関連する追加的詳細は、以下のとおりである。演算子シノプシスは、イベントストリーム内のイベントを処理する連続クエリのクエリプランにおいて識別される演算子オブジェクトの状態を指す。一実施形態では、演算子シノプシスは、イベントの最後のタイムスタンプのような、イベントを処理するための演算子の可変状態、およびウィンドウ演算子についての指定されたウィンドウサイズまたはGroupAggr演算子についての集計結果についてのイベントのリストのような、イベントを処理するためのイベントの概要を含む実際のシノプシスを指してもよい。

いくつかの例では、システムの現在の状態に関連する情報は、マシンのクラスタ内において、ログベースのストレージシステム３２２内において、シノプシスログの形式で記憶されてもよい。一実施形態では、マシンのクラスタは、Apache（登録商標）Corporationによって提供されるKafkaクラスタとして実施されてもよい。本明細書で使用するように、Kafkaは、分散した、区分された、複製されたデータストレージメカニズムを指し、マシンのクラスタにわたって区分されるデータストリームからの情報の保存を可能にする。Kafkaは、１台のマシンの能力よりも大きなデータストリームを処理できるように、マシンのクラスタにわたってデータストリームを区分できるため、耐久性およびフォールトトレランスの保証を提供するユーザ中心の設計を提供する。

いくつかの実施形態では、システムの現在の状態３２０は、入力待ち行列状態（読出オフセット３１４を含み得る）、演算子シノプシス（シノプシスログ読出オフセット３１６を含み得る）、および出力待ち行列状態（出力シーケンス３１８を含み得る）に関連する情報を含んでもよい。いくつかの例では、読出オフセット３１４は、入力イベントを記憶するストレージコンテナ（たとえばカフカトピック）の現在位置を含むことができる。シノプシスログ読出オフセット３１６は、たとえば、ストレージコンテナ（たとえばKafkaトピック）に書き込まれるシノプシスログの位置を含むことができる。出力シーケンス３１８は、イベント処理システムによって処理されるイベントの出力シーケンス番号に関連する情報を含むことができる。

いくつかの実施形態では、ログベースのストレージ３２２は、システムの現在の状態に関連する情報をバックグラウンドスレッドにおいて（たとえば非同期で）コンテナ（たとえばKafkaトピック）に継続的に記憶されるシノプシス変更ログとして記憶するように構成できる。いくつかの例では、ログベースのストレージ３２２は、演算子の状態を記憶するためにシノプシスのメモリ内スナップショットを作成することができる。各演算子は、異なる種類のデータ構造を記憶に使用し、それらのうちのいくつかは比較的大きなメモリダンプを生成することがある。一例では、スナップショットの作成から追加のパフォーマンスペナルティを導入しないために、特定の演算子のための連続的／非同期ログベースの状態記憶が使用されてもよい。したがって、いくつかの実施形態では、ログベースのストレージ３２２は、連続クエリの特定の演算子のための連続的および／または非同期のログに基づく状態記憶を表すことができる。この手法では、すべてのシノプシス操作（挿入操作、更新操作、および削除操作など）をログ操作として捕えることができる。状態は、アペンド専用ログと見ることができる。内部パブリッシュ／サブスクライブ待ち行列を持つ別のスレッドを使用すると、この操作は非同期で実行でき、すべての演算子がイベント処理を停止する遅延を最小限に抑えることができる。

ログベースのストレージ３２２から状態をリコンサイルおよび／または再構築するために、ログは開始点から所望の点まで再生されなければならない。このようなアプローチは、高速回復には望ましくない可能性がある。より効率的な回復を提供するために、本開示の一実施形態では、ログは、所定の持続期間内にフルスナップショットを含むことができ、別々のシノプシススナップショットを生成して、ログベースのストレージからの状態をリコンサイルすることができる。他の実施形態では、範囲ウィンドウ演算子のシノプシスは、本質的に範囲ウィンドウ演算子のシノプシスが、フルスナップショットを再構築した後の入力イベントと同じイベントのセットを必要とするため、イベントを再生することによって再構築することができる。このアプローチはまた、シノプシスログに記憶される情報の量も減少し得る。

上記のように、イベントバッチの個々のイベントをすべて処理するのではなく、各イベントバッチでチェックポイントマーカイベントのみを処理する結果、システムパフォーマンスが向上する。障害が発生した場合、チェックポイントマーカイベントの後に発生したイベントのみを再処理する必要がある。このように、回復時には、障害の前および状態をチェックポイントにリコンサイルした後に発生した入力イベントのみが再処理され、再生される。

いくつかの実施形態では、回復時に、システムの状態は、障害前のチェックポイントマーカイベントに巻き戻る。一例では、リーダオフセットはスナップショットに記憶された位置に巻き戻され、リーダオフセットは、障害前のスナップショットに対する同じ入力イベントのセットを読み出すために使用される。

障害の前および状態をチェックポイントにリコンサイルした後に発生したイベントが再処理されるため、上記の手法では、（最も最近処理されたイベントバッチにおける）最後のチェックポイントマーカイベントから障害ポイントまで再処理されるイベントについて重複出力イベントが生成される結果となる可能性がある。しかしながら、上流側の障害が発生せず、欠落したイベントも重複したイベントも許されなかった場合に生成されたであろう全く同じイベントのストリームを下流のクライアントが見る、正確なイベントの回復を達成することが望ましい。

正確な回復を提供する１つの手法は、出力待ち行列トリミングを使用することである。本明細書で説明するように、「出力待ち行列トリミング」は、システムが、システムによって待ち行列に入れられたイベントが回復のためにもはや必要でないと判断したときに、当該イベントを積極的に破棄することを指す。このような構成を使用すると、アクティブな主サーバは、それが実際に処理したイベントを、１つ以上の副サーバに通信する。これにより、副サーバは、特定の時点で主サーバによって送信されなかったイベントのみを含むように、副サーバの出力イベントのバッファを「トリミング」することができる。これにより、イベントはそれらが現在の主サーバによって送信された後にのみトリミングされるため、副サーバは、フェイルオーバーが発生したときに出力イベントを失うことを回避できる。

アクティブな主サーバがアクティブな副サーバに待ち行列トリミングメッセージを送信する頻度は、設定可能であってもよい。たとえば、待ち行列トリミングメッセージは、イベントベースで、たとえばｎ回のイベント（０＜ｎ）ごとに送信することができ、これにより、重複出力イベントの数が、フェイルオーバー時に最大ｎ個のイベントに、または時間ベースでｎミリ秒（０＜ｎ）ごとに制限される。待ち行列トリミングアダプタには、アクティブな主副間で一貫してイベントを識別する方法を必要とする。

そのような構成では、副サーバは、アダプタを介して、主サーバによってパブリッシュされているイベントストリームをリスニングするようにセットアップされる。アダプタを信頼性の高い配信のために構成することにより、副サーバが認識するイベントストリームは、まったく、主サーバが出力するイベントストリームであるため、フェイルオーバーにより、新たな主サーバは、古い主サーバによって配信されないイベントを正確に出力できる。待ち行列トリミングの利点は、出力イベントが決して失われないことである。しかしながら、通信される必要があるトリミングメッセージを送信するために、アクティブな主サーバにはパフォーマンスオーバーヘッドがあり、このオーバーヘッドはトリミングの忠実度が高くなるにつれて増加する。

連続クエリ処理でイベントバッチおよび出力シーケンス化を使用してイベントを処理する技法
本開示の一実施形態では、イベントの正確な回復は、チェックポイントマーキングとともに、出力シーケンス化の使用によって達成され得る。この実施形態では、イベント処理システムによって生成される判断論的出力イベントのためにカウンタを使用することができる。イベント処理システムによって送信される各出力イベントは、出力シーケンス番号に関連付けられる。システムの現在の状態のスナップショットが生成されると、現在の出力シーケンス番号がスナップショットの一部として記憶される。いくつかの例では、記憶された出力シーケンス番号は、スナップショットに関する「最後の出力シーケンス番号」を表す。たとえば、一例では、出力シーケンス番号は、図３に示す出力状態待ち行列において出力シーケンス（３１８）の一部として格納することができる。いくつかの例では、現在の出力シーケンス番号は、障害後であってもシステムに利用可能にされる。現在の出力シーケンス番号は、それが変化したときに、ストレージに永続保存される。現在の出力シーケンスは、ある実施形態では、システム障害の場合にシステムが他のマシンからそれを取り出すことができるように、分散ハッシュテーブルに格納することもできる。

一実施形態では、イベント処理システムは、システム障害後のイベントの正確な回復を以下のように達成することができる。イベント処理システムは、最も最近送信された出力イベントの「現在の出力シーケンス番号」と、最も最近処理されたイベントのバッチに対応する（すなわち、最も最近処理されたチェックポイントマーカイベントからの）スナップショットに格納される「最後の出力シーケンス番号」とを識別する。次に、イベント処理システムは、出力チャネルの状態を「ＲＥＣＯＮＣＩＬＥ（リコンサイル）」に設定し、システム障害の前に、最も最近処理されたチェックポイントマーカイベントの後に発生したイベントの再処理を開始する。しかしながら、これらのイベントの再処理は、すでにシステムによって正常に送信された１つ以上の出力イベントの再生成をもたらす可能性がある。これらの出力イベントの再送信を回避するために、一実施形態では、イベント処理システムは、再処理されたイベントの次の出力シーケンス番号を現在の出力シーケンス番号と比較する。再処理されたイベントの次の出力シーケンス番号が現在の出力シーケンス番号よりも小さい場合、イベントは無視され、再出力されない。イベント処理システムは、再処理されたイベントの次の出力シーケンス番号が現在のシーケンス番号以上になると、出力チャネルの状態を「ＮＯＲＭＡＬ」に変更し、最も最近送信された出力イベントに対応する現在のシーケンス番号から出力イベントを送信することを開始する。

図４は、本開示の一実施形態による、イベント処理システムがイベントの正確な回復を実行することができる方法の例示的な図である。図４に示される実施形態において、参照符号４００は、イベント処理システム（たとえば３００）から受信される連続入力イベントストリームを表す。参照番号４０６，４０８は、所定の時間間隔でチェックポイントマーカイベントＣＰ１、ＣＰ２を連続入力イベントストリームに挿入することによって、イベント処理システムによって生成されるイベントバッチを表す。上述したように、チェックポイントマーカイベント（たとえば、ＣＰ１、ＣＰ２）は、チェックポイントマーカイベントの系統トラッキングを行うことによって処理されてもよい。チェックポイントマーカイベント（たとえば、ＣＰ１またはＣＰ２）が完全に処理されると、イベント処理システムは、チェックポイントマーカイベント（ＣＰ１またはＣＰ２）を含むイベントストリームのイベントバッチ（たとえば４０６または４０８）が完全に処理されたことを示すチェックポイント確認メッセージを受信する。次に、イベント処理システムは、システムの現在の状態のスナップショット（４１２，４１４）の生成をトリガする。

参照番号４０２は、連続入力イベントストリーム４００を処理した結果としてイベント処理システムによって生成される１つ以上の出力イベントのセットを含む出力ストリームを表す。一実施形態では、各出力イベントは、Ｏｉとして識別されてもよく、ここで、ｉは、イベント処理システムによる出力イベントの生成の順番で出力イベントに割り当てられた出力シーケンス番号を示す整数である。したがって、ある出力イベントはＯ１として識別され、１はその出力イベントに割り当てられたシーケンス番号である。連続入力イベントストリーム４００内の各入力イベントは、Ｅｊとして識別されてもよく、ここで、ｊは、入力イベントに対する固有の識別子を表す。たとえば、ある入力イベントは、Ｅ１として識別されてもよく、ここで、１は、入力イベントに対する固有の識別子である。図５に示すように、単一の入力イベントＥ１の処理は、対応する単一の出力イベントＯ１の生成をもたらすと仮定される。しかしながら、いくつかの他の実施形態では、複数の入力イベントの処理の結果として出力イベントＯ１が生成されてもよいことを理解されたい。たとえば、一例では、入力イベントＥ１、Ｅ２、およびＥ３を処理した結果として、出力イベントＯ１を生成することができる。

イベント処理システム４１６によってシステム障害が検出されると、イベント処理システムは、最も最近処理されたイベントバッチ（たとえば４０８）の最後のチェックポイントマーカイベント（ＣＰ２）以降の障害以前に発生したイベントを識別し、これらのイベントを再処理する。しかしながら、これらのイベント（たとえば、Ｅ２１、Ｅ２２、Ｅ２３およびＥ２４）の再処理は、１つ以上の出力イベントＯ２１，Ｏ２２，Ｏ２３およびＯ２４の重複セットの生成をもたらす結果となり得、なぜならば、これらの出力イベントは既に出力ストリーム４０２に送信されているからである。一実施形態では、出力イベントの重複セットの生成を防止するために、イベント処理システムは、最後のチェックポイントマーカイベント以降の出力イベントの最後の出力シーケンス番号Ｏ２０と、最も最近送信された出力イベントの現在の出力シーケンス番号Ｏ２４とを識別する。次に、イベント処理システムは、対応する入力イベント（Ｅ２１、Ｅ２２、およびＥ２３）の再処理のため、最後の出力シーケンス番号Ｏ２０と現在の出力シーケンス番号Ｏ２４との間で生成され得る任意の出力イベント（たとえば、Ｏ２１，Ｏ２２およびＯ２３）を無視する。

上述のように、一実施形態では、イベント処理システムは、最後のチェックポイントマーカイベントからの対応する再処理されたイベント（たとえばＥ２１）の次の出力シーケンス番号（たとえばＯ２１）を現在の出力シーケンス番号（たとえばＯ２４）と比較する。次の出力シーケンス番号（たとえばＯ２１）が現在のシーケンス番号（たとえばＯ２４）よりも小さい場合、そのイベントは無視され、再出力されない。再処理されたイベントの次の出力シーケンス番号が現在の出力シーケンス番号（たとえばＯ２４）以上になると、イベント処理システムは出力チャネルの状態を「ＮＯＲＭＡＬ」に変更し、イベントの出力ストリームにおける最も最近送信された出力イベント（たとえばＯ２４）の現在の出力シーケンス番号から出力イベント（たとえばＯ２５）の再送信を開始する。したがって、再送信されるべき１つ以上の出力イベントのセットにおいて１つ以上の出力イベントを除外することによって、イベント処理システムは、イベントの正確な回復を達成しながら重複イベントの送信を防止する。

図５は、本開示の一実施形態による、イベント処理サービスを提供するイベント処理アプリケーション５０２を含むイベント処理システム５００の例示的な図である。一実施形態では、イベント処理アプリケーション５０２は、図３に示すイベント処理システム（たとえば３０２）と同様または同じであってもよく、図３に示すように、入力チャネル３０４、ＣＱＬプロセッサ３０６、および出力チャネル３０８などのコンポーネントを含むことができる。さらに、図５において示される実施の形態は、本発明の実施形態を組み込むことができるイベント処理システムの一例である。他のいくつかの実施の形態では、イベント処理システム５００は、図５において示されるよりも多数もしくは少数のコンポーネントを有してもよく、または２つ以上のコンポーネントを組合せてもよく、またはコンポーネントの異なる構成もしくは配置を有してもよい。

図３に関して上述したように、入力チャネル３０４は、アプリケーションに関連するイベントの連続入力ストリームを受信し、イベントの連続入力ストリームから１つ以上のイベントバッチのセットを生成するように構成される。ある実施形態では、入力チャネル３０４におけるイベントバッチ判断モジュール３１０は、チェックポイントマーカイベントを所定の時間間隔で連続入力イベントストリームに導入することによって、イベントバッチを生成するように構成することができる。

ＣＱＬプロセッサ３０６は、イベントバッチ内のイベントのセットを処理するように構成することができる。上述したように、イベントの処理は、各イベントバッチにおけるチェックポイントマーカイベントの処理を含むことができる。チェックポイントマーカイベントが系統トラッキングモジュール３１２によって完全に処理されたことを検出すると、系統トラッキングモジュール３１２は、チェックポイント終了マーカイベントを生成する。チェックポイント終了マーカイベントを受信すると、出力チャネル３０８は、チェックポイント確認メッセージを入力チャネル３０４に送信する。これは、システムの現在の状態のスナップショット３２０の生成をトリガする。一実施形態では、システムの現在の状態のスナップショット３２０は、ログベースのストレージ３２２（シノプシスログ）の形態でマシンのクラスタに保存することができる。

いくつかの実施形態によれば、出力チャネル３０８は、出力シーケンス番号生成部５０２およびイベント回復モジュール５０４を含むことができる。出力シーケンス番号生成部５０２は、イベント処理システムによって生成される各出力イベントの出力シーケンス番号を生成するように構成することができる。イベント回復モジュール５０４は、イベント処理システムにおけるイベントの正確な回復を実行するように構成することができる。システム障害が検出されると、イベント回復モジュール５０４は、最も最近送信された出力イベントの「現在の出力シーケンス番号」と、最も最近処理されたイベントのバッチに対応する（すなわち、最も最近処理されたチェックポイントマーカイベントからの）スナップショットに格納される「最後の出力シーケンス番号」とを識別する。次に、イベント回復モジュール５０４は、出力チャネルの状態を「ＲＥＣＯＮＣＩＬＥ（リコンサイル）」に設定し、システム障害の前で、最も最近処理されたチェックポイントマーカイベントの後に発生したイベントの再処理を開始する。しかしながら、上記したように、これらのイベントの再処理は、すでにシステムによって正常に送信された１つ以上の出力イベントの再生成をもたらす可能性がある。これらの出力イベントの再送信を回避するために、一実施形態では、イベント回復モジュール５０４は、再処理されたイベントの出力シーケンス番号を現在の出力シーケンス番号と比較する。再処理されたイベントの出力シーケンス番号が、最も最近送信された出力イベントの現在の出力シーケンス番号よりも小さい場合、そのイベントは無視され、再送信されない。再処理されたイベントの出力シーケンス番号が最も最近送信された出力イベントの現在のシーケンス番号以上になると、イベント処理システムは、出力チャネルの状態を「ＮＯＲＭＡＬ」に変更し、最も最近送信された出力イベントに対応する現在のシーケンス番号からの出力イベントの送信を開始する。

例示的プロセス
図６〜図８は、本発明の特定の実施形態によるイベント処理サービスを提供するそれぞれのプロセス６００，７００および８００を示す例示的なフロー図を示す。これらのプロセスは論理フロー図として示されており、それらの各動作は、ハードウェア、コンピュータ命令、またはそれらの組み合わせで実施することができる。コンピュータ命令の文脈において、動作は、１つ以上のプロセッサによって実行されると、記載された動作を実行する１つ以上のコンピュータ可読記憶媒体に格納されたコンピュータ実行可能命令を表すことができる。一般に、コンピュータ実行可能命令は、特定の機能を実行するかまたは特定のデータ型を実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。動作が記載される順序は、限定として解釈されることを意図するものではなく、任意の数の記載された動作を、任意の順序および／または並列で組み合わせて、プロセスを実施することができる。

さらに、プロセスのいくつか、いずれか、またはすべては、実行可能命令とともに構成された１つ以上のコンピュータシステムの制御下で実行されてもよく、まとめて、１つ以上のプロセッサ上で、ハードウェアによって、またはそれらの組み合わせで実行されるコード（たとえば実行可能命令、１つ以上のコンピュータプログラム、または１つ以上のアプリケーション）として実現されてもよい。上記のように、コードは、たとえば、１つ以上のプロセッサによって実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ可読記憶媒体に格納されてもよい。コンピュータ可読記憶媒体は、非一時的であってもよい。いくつかの例では、少なくとも図２、図３、図５（およびその他）に示すイベント処理システム（たとえば少なくとも入力チャネル３０４、イベントバッチ判断部３１０、系統トラッキングモジュール３１２、出力シーケンス番号生成部５０２およびイベント回復モジュール５０４を利用する）は、それぞれ、図６〜図８のプロセス６００，７００、および８００を実行することができる。

図６は、本開示の一実施形態によるイベント処理サービスを提供するための例示的なプロセス６００のフロー図を示す。プロセス６００は、６０２において、アプリケーションに関連するイベントの連続入力ストリームがイベント処理システムによって受信されたときに開始されてもよい。たとえば、イベント処理システムは、図２に示すように、１つ以上のイベントソース（２０４，２０６または２０８）からイベントの連続入力ストリームを受信することができる。イベントの連続入力ストリームを受信すると、６０４で、イベント処理システムは、イベントの連続入力ストリームから１つ以上のイベントバッチのセットを生成する。上述したように、一実施形態では、イベント処理システムは、所定の時間間隔でチェックポイントマーカイベントを連続入力イベントストリームに導入することによって、イベントバッチを生成することができる。

６０６において、イベント処理システムは、イベントバッチ内のイベントを処理して、アプリケーションに関連するイベントの出力ストリームを生成する。イベント処理システムがイベントバッチ内のイベントを処理する方法は、図７に関連してさらに詳細に説明する。

６０８において、イベント処理システムは、イベントの出力ストリームにおける出力イベントについて出力シーケンス番号を判断する。上述したように、出力シーケンス番号は、イベント処理システムによる出力イベントの生成順に出力イベントに割り当てられたシーケンス番号に対応する。６１０において、イベント処理システムは出力イベントを送信する。６１２で、イベント処理システムは、出力イベントの出力シーケンス番号を記憶する。たとえば、上述したように、一実施形態では、出力シーケンス番号は、図３に示す出力状態待ち行列における出力シーケンス情報（３１８）の一部として格納することができる。

いくつかの実施形態では、６１４で、イベント処理システムは、イベントの連続入力ストリームを処理している間に、システムの障害の表示を受信し得る。６１６において、イベント処理システムは、出力イベントに割り当てられた出力シーケンス番号に基づいて、送信されるべき出力ストリームの１つ以上の出力イベントのセットを判断する。イベント処理システムが、送信されるべき１つ以上の出力イベントのセットを判断できる方法に関する追加の詳細は、図８に関連して論じられる。６１８で、イベント処理システムは、アプリケーションに関連する１つ以上の出力イベントのセットを送信する。

図７は、本開示の一実施形態による連続したイベントのストリームにおいてイベントを処理するための例示的なプロセス７００のフロー図を示す。プロセス７００は、図６のプロセス６０６を実行する追加の詳細を提供する。一実施形態では、このプロセスは、イベント処理システム内のイベントバッチ判断部３１０および系統トラッキングモジュール３１２によって実行することができる。

いくつかの実施形態では、プロセス７００は、７０２において、イベント処理システムがチェックポイントマーカイベントを生成するときに開始する。上記のように、チェックポイントマーカイベントは、イベントの連続入力ストリーム内のイベントに関連する情報および／またはメタデータを含むイベントを表すことができる。いくつかの例では、チェックポイントマーカイベントは、ハートビートイベントを表すこともできる。

７０４において、イベント処理システムは、チェックポイントマーカイベントを所定の時間間隔でイベントの連続入力ストリームに挿入する。上述のように、所定の時間間隔は、ストリーミングアプリケーションのタイプ、イベントがストリーミングアプリケーションによって生成される頻度、アプリケーションによって生成されるイベントのサイズ、アプリケーションによって生成されるイベントのレイテンシ要件、ユーザ情報、サンプリング情報、最良の実務などに基づいて判断されてもよい。

７０６において、イベント処理システムは、チェックポイントマーカイベントに基づいて第１のイベントバッチを生成する。したがって、一実施形態では、イベントストリームにおけるイベントバッチのサイズおよび／または間隔は、チェックポイントマーカイベントがイベントストリームに挿入される点（または時間）に基づいて判断されてもよい。

いくつかの例では、７０８において、イベント処理システムは、チェックポイントマーカイベントを処理する。上記のように、チェックポイントマーカイベントの処理は、チェックポイントマーカイベントの系統トラッキングを行うことを含むことができる。いくつかの例では、チェックポイントマーカイベントの処理が成功すると、７１０において、イベント処理システムは、チェックポイントマーカイベントを含む第１のイベントバッチの処理の完了を示す確認メッセージを送信してもよい。７１２で、イベント処理システムは、システムの現在の状態のスナップショットを生成する。いくつかの例では、システムの現在の状態のスナップショットは、イベントストリーム内のイベントの少なくとも第１のバッチに関連する入力待ち行列状態、演算子状態、または出力待ち行列状態のうちの少なくとも１つに関連する情報を含む。

図８は、本開示の一実施形態による、出力ストリームで送信されるべき１つ以上の出力イベントのセットを判断するためのプロセス例８００のフロー図を示す。プロセス８００は、図６のプロセス６１６を実行する追加の詳細を提供する。一実施形態では、この処理は、イベント処理システム内の出力シーケンス番号生成部５０２およびイベント回復モジュール５０４によって実行されてもよい。

いくつかの実施形態では、プロセス８００は、８０２で、イベント処理システムがイベントの連続入力ストリームを処理している間に障害の表示を受信すると、開始してもよい。８０４において、イベント処理システムは、イベントの出力ストリームにおいて最も最近送信された出力イベントの現在のシーケンス番号を判断する。８０６において、イベント処理システムは、最も最近処理されたイベントのバッチに対応する出力イベントの最後の出力シーケンス番号を判断する。

いくつかの例では、８０８において、イベント処理システムは、システム障害の結果として再処理されている１つ以上のイベントのセットを識別する。８１０で、イベント処理システムは、再処理されたイベントの次の出力シーケンス番号（最も最近処理されたイベントのバッチに対応する出力イベントの最後のシーケンス番号の後）が、イベントの出力ストリームにおける最も最近送信された出力イベントの現在の出力シーケンス番号以上であるかどうかを判断する。イベント処理システムは、再処理されたイベントの次の出力シーケンス番号が、イベントの出力ストリームにおける最も最近送信された出力イベントの現在の出力シーケンス番号以上でないと判断した場合、イベント処理システムは、生成された出力イベントを無視し、それを再送信しないので、出力イベントの重複送信を防止する。一旦、再処理されたイベントの次の出力シーケンス番号が、イベントの出力ストリームにおける最も最近送信された出力イベントの現在の出力シーケンス番号以上になると、８１２で、イベント処理システムは出力イベントをもう一度送信し始める。

連続イベント処理におけるフェイルオーバーに対してログベースの高速状態回復を実行するための技法
イベントがイベント処理システムに絶えず到着するなか、システム性能を失うことなく、システムの状態を確実かつ正確に保つことが望ましい。本開示の一実施形態では、イベント処理システムの状態は、システムの現在の状態のスナップショットを作成することによって保存することができる。上述したように、スナップショットは、ある時間間隔にわたって連続クエリによって処理された（たとえばイベントバッチからの）イベントのセットに関する情報を含むことができる。たとえば、スナップショットは、イベントストリーム内のイベントに関連する入力待ち行列状態、演算子状態、または出力待ち行列状態に関する情報を含むことができる。演算子状態は、通常、イベントストリームのイベントを処理する連続クエリにおいて識別される演算子の状態に関する情報を含む。各演算子は記憶のために異なるタイプのデータ構造（すなわちシノプシス）を使用するので、これらの演算子を使用して生成されるスナップショットは、比較的大きなメモリダンプに変換される可能性がある。これは、潜在的に、スナップショットが生成されるたびに、ログベースのストレージ（たとえば３２２）に書き込まれる必要がある比較的大きなバイト配列をもたらす可能性がある。

本開示の一実施形態では、システムの現在の状態の「フルスナップショット」を生成する代わりに、イベント処理システムを、システムの現在の状態の「ジャーナリングされたスナップショット」を生成するように構成することができる。本明細書で説明するように、「ジャーナリングされたスナップショット」は、演算子シノプシス上で実行される操作のログに基づいて増分的に生成されるシステムの現在の状態のスナップショットを指す。たとえば、操作のログには、 'Range Window'演算子で使用されるリストデータ構造に対する挿入操作および削除操作が含まれる。「ジャーナリングされた演算子」とは、ジャーナリングされたスナップショットの作成をサポートする演算子を指す。「ジャーナリングされた演算子」の例としては、たとえば、ウィンドウ演算子、groupBy演算子などが挙げられる。連続クエリの「ジャーナリングされた演算子」の実行に対応する「ジャーナリングされたスナップショット」の生成は、（イベントバッチなどにおける）イベントのセットが処理されるたびにログベースのストレージに書き込まれるバイト配列を低減する結果となる。

本開示の目的のための「フルスナップショット」は、イベントストリームのイベントのセットに対する連続クエリの「ジャーナリングされた演算子」および「ジャーナリングされていない演算子」を含む１つ以上の演算子の実行に基づいて生成されるシステムの現在の状態のスナップショットを指す。本明細書で使用する「ジャーナリングされていない演算子」とは、ジャーナリングされたスナップショットの生成をサポートしない演算子を指す。ジャーナリングされていない演算子の例には、たとえば、メジアン演算子、最小演算子、最大演算子などが含まれ、ジャーナリングされていない演算子は通常、現在の状態をフルスナップショットとしてダンプし、なぜならば、特定の状況では、ジャーナリングされたスナップショットの作成は、フルスナップショットを作成するよりも高価になる可能性があるからである。

本開示のいくつかの実施形態では、イベント処理システムが、システムの現在の状態のスナップショットが生成される必要があると判断した場合（たとえばイベントバッチ内のイベントのセットが処理されると）、イベント処理システムは、イベントバッチ内の処理されたイベントに対して、システムの現在の状態の「ジャーナリングされたスナップショット」または「フルスナップショット」が生成されるかどうかを判断する。たとえば、一実施形態では、イベント処理システムは、処理されたイベントの第１のバッチ内のすべてのイベントについて、システムの現在の状態の「フルスナップショット」を生成することができる。後で処理されるイベントのバッチに対しては、イベント処理システムは、以下のように、「ジャーナリングされたスナップショット」と「フルスナップショット」との組み合わせを生成することができる。たとえば、一実施形態では、イベント処理システムは、イベントバッチのイベントのセットに対する「ジャーナリングされた演算子」の実行に対応する、システムの現在の状態の「ジャーナリングされたスナップショット」と、イベントバッチのイベントのセットに対する「ジャーナリングされた演算子」および「ジャーナリングされない演算子」を含むすべての演算子の実行に対応する、システムの現在の状態の「フルスナップショット」とを生成することができる。

上述したような連続クエリの「ジャーナリングされた演算子」の実行に対応する「ジャーナリングされたスナップショット」の生成は、（たとえば、イベントバッチ内の）イベントのセットが処理されるたびにログベースのストレージに書き込まれるバイト配列の低減をもたらす結果となる。これは、「ジャーナリングされた演算子」は、演算子シノプシスに実行された操作を記録することを必要とされるためである。たとえば、’［範囲１分］’を伴うRangeWindow演算子を有する連続クエリがあるとする。この場合、処理を実行する「ジャーナリングされた演算子」の「状態」は、イベントがウィンドウの範囲内にある場合は「挿入」であり、イベントがウィンドウの範囲外であり、シノプシスから削除されるべき場合には、「削除」である。言い換えれば、RangeWindow演算子の「状態」は、これまでにバッチで実行された、実行されたすべての操作をシノプシスに記録する。したがって、「ジャーナリングされた演算子」として識別される連続クエリの演算子に対応する「ジャーナリングされたスナップショット」を生成することにより、ログベースのストレージに書き込まれる必要があるバイト配列を大幅に削減することができる。一方、「フルスナップショット」は、通常、完全なシノプシスがメモリにダンプされることを必要とするであろう。イベント処理システムがシステムの現在の状態のスナップショットを生成する方法については、図９に関連して詳細に説明する。

図９は、本開示の一実施形態による、イベント処理サービスを提供するイベント処理アプリケーション９０２を含むイベント処理システム９００の例示的な図である。一実施形態では、イベント処理アプリケーション９０２は、イベント処理システムによって提供されるイベント処理サービス（たとえば図２に示す２０２など）の一部であってもよい。一実施形態では、イベント処理アプリケーション９０２は、図３または図５に示すイベント処理システム（たとえば３０２または５０２）と同様または同じであってもよく、入力チャネル３０４、ＣＱＬプロセッサ３０６、および出力チャネル３０８などのコンポーネントを含むことができる。図９において示される実施の形態は、本発明の実施形態を組み込むことができるイベント処理システムの一例である。他のいくつかの実施の形態では、イベント処理システム９００は、図９において示されるよりも多数もしくは少数のコンポーネントを有してもよく、または２つ以上のコンポーネントを組合せてもよく、またはコンポーネントの異なる構成もしくは配置を有してもよい。

図３および図５に関して上述したように、入力チャネル３０４は、アプリケーションに関連するイベントの連続入力ストリームを受信し、イベントの連続入力ストリームから１つ以上のイベントバッチのセットを生成するように構成される。ある実施形態では、入力チャネル３０４におけるイベントバッチ判断モジュール３１０は、チェックポイントマーカイベントを所定の時間間隔で連続入力イベントストリームに導入することによって、イベントバッチを生成するように構成することができる。

ＣＱＬプロセッサ３０６は、イベントバッチ内のイベントのセットを処理するように構成することができる。上述したように、イベントの処理は、各イベントバッチにおけるチェックポイントマーカイベントの処理を含むことができる。チェックポイントマーカイベントが系統トラッキングモジュール３１２によって完全に処理されたことを検出すると、系統トラッキングモジュール３１２は、チェックポイント終了マーカイベントを生成する。チェックポイント終了マーカイベントを受信すると、出力チャネル３０８は、チェックポイント確認メッセージを入力チャネル３０４に送信する。これは、システムの現在の状態のスナップショット３２０の生成をトリガする。一実施形態では、システムの現在の状態のスナップショット３２０は、ログベースのストレージ３２２（シノプシスログ）の形態でマシンのクラスタに保存することができる。

本開示の一実施形態では、イベント処理システムは、スナップショット持続時間判断モジュール９０４を含むことができる。スナップショット持続時間判断モジュール９０４は、システムの現在の状態の「フルスナップショット」（たとえば３２０）がどの程度の頻度で生成されるかを判断するよう構成されてもよい。たとえば、スナップショット持続時間判断モジュール９０４は、イベントバッチ内のイベントのセットが処理されるたびに「フルスナップショット」の生成をトリガするように構成されてもよい。いくつかの例では、スナップショット持続時間判断モジュール９０４は、所定の数の（たとえば３つの）イベントバッチが処理された後に「フルスナップショット」の生成をトリガするように構成されてもよい。いくつかの例では、スナップショット持続時間判断モジュール９０４は、上述したように、システムの現在の状態の「フルスナップショット」または「ジャーナリングされたスナップショット」の生成をトリガするように構成されてもよい。たとえば、スナップショット持続時間判断モジュール９０４は、処理されたイベントの第１のバッチに対しては「フルスナップショット」の生成をトリガし、次いで、後続のイベントのバッチに対しては「フルスナップショット」と「ジャーナリングされたスナップショット」との組み合わせの生成をトリガするように構成されてもよい。他の例では、スナップショット持続時間判断モジュール９０４は、予め設定された時間間隔で（たとえば所定の数（たとえば１０個）のイベントバッチが処理された後に）「フルスナップショット」の生成をトリガするように構成されてもよい。

上述したように、イベント処理システムは、連続クエリによってイベントバッチにおけるイベントを処理する間に「ジャーナリングされた演算子」として識別された演算子に対応する「ジャーナリングされたスナップショット」と、イベントの処理中に「ジャーナリングされない演算子」として識別された演算子に対応する「フルスナップショット」とを生成してもよい。

いくつかの実施形態では、イベント処理システムは、スナップショットの一部として「シノプシス情報」および「可変状態情報」を記憶するように構成することができる。「シノプシス情報」および「可変状態情報」は、イベントバッチ内でイベントを処理する連続クエリの演算子に関連する情報に対応する。たとえば、「シノプシス情報」は、たとえば、演算子に関連する範囲ウィンドウ内のイベントを表すRangeWindowのシノプシスによって使用されるリストデータ構造を含んでもよく、一方、「可変状態情報」は、たとえば、演算子が、処理されたイベントの最後のタイムスタンプを、演算子に関係付けられる状態で、覚えておくために演算子が維持する最後のタイムスタンプを含んでもよい。いくつかの例では、イベント処理システムは、演算子がシステムの現在の状態の「ジャーナリングされたスナップショット」または「フルスナップショット」を生成することができるかどうかに応じて、演算子に関連する「シノプシス情報」または「可変状態情報」を記憶するよう構成されてもよい。一実施形態では、イベント処理システムは、システムの現在の状態の「ジャーナリングされたスナップショット」の生成をサポートする演算子に関連する「シノプシス情報」と、システムの現在の状態の「フルスナップショット」の生成をサポートする演算子に関連する「可変状態情報」とを記憶するよう構成されてもよい。

いくつかの例では、演算子は、システムの現在の状態の「ジャーナリングされたスナップショット」または「フルスナップショット」のいずれかを生成することができてもよい。図１０は、本開示の一実施形態による、イベントストリーム内のイベントの処理中に識別される連続クエリの異なるタイプの演算子に対する異なるタイプのスナップショットの生成を示す例示的なテーブルである。

図１０において、Ｂ１、Ｂ２、Ｂ３およびＢ４は、イベント処理システムによって生成される例示的なイベントバッチを表す。演算子タイプの列は、イベントストリーム内のイベントの処理中にイベント処理システムによって識別された連続クエリの演算子のセットを識別する。図１０に示される例では、演算子のセットは、Window演算子、Aggr演算子、およびgroupBy演算子を含む。本明細書で説明するように、イベントストリームは、イベントの連続ストリームを表す。Window演算子は、さらなる処理のために、イベントのサブセット（たとえば最後のＮ個のイベント）を選択する方法を提供する。Window演算子からの出力は、イベントストリームの結合、または合計および平均などの集計関数の計算など、さらなる処理に使用できる一連のイベントである。たとえば、ウィンドウ演算子は、過去１時間に配されたすべてのイベント（たとえば製品の受注）を収集し、１時間に１回、その受注の平均値を出力することができる。Aggr演算子は、イベントストリームのイベントのセットの合計、平均、カウント、最大などの集計関数を計算できる演算子である。groupBy演算子は、イベントストリーム内のイベントのグループ化および集計を実行できる演算子を指す。

本開示の一実施形態では、イベント処理システムは、イベントの第１のバッチＢ１については識別されたすべての演算子について「フルスナップショット」を生成するように構成することができる。後続のイベントのバッチＢ２およびＢ３については、イベント処理システムは、ジャーナリングされていない演算子（たとえばAggr演算子）に対応する「フルスナップショット」、およびジャーナリングされた演算子（たとえば 、Window演算子、groupBy演算子）に対応する「ジャーナリングされたスナップショット」を生成するよう構成されてもよい。上記の例でさらに示されているように、いくつかの実施形態では、イベント処理システムは、演算子が「ジャーナリングされた演算子」または「ジャーナリングされない演算子」であるかどうかにかかわらず、イベントのバッチＢ４の処理中に識別されるすべての演算子について「フルスナップショット」を生成するよう構成されてもよい。図１０に示すイベント処理システムによる４つのイベントバッチの生成は、説明のためのものである。他の実施形態では、イベント処理システムは、イベントストリームから、より少数またはより多数のイベントバッチを生成するように構成することができる。

上記したように、望ましいレベルの忠実度は、上流側の障害が発生せず、欠落したイベントも重複したイベントも許されなかった場合に生成されたであろう全く同じイベントのストリームを下流のクライアントが見るような正確な回復である。したがって、パフォーマンスにあまり影響を与えることなく連続クエリの正確な回復を提供することが望ましい。典型的には、連続クエリの正確な回復は、演算子の状態がクラスタ内の他のピアマシン上に復元された場合に与えられる。一実施形態では、イベント処理システムは、演算子の状態を定義し、この状態を低レイテンシ読出し書込み能力を有するフォールトトレラントな記憶媒体上に保存する。

既存の連続クエリシステムは、１つの連続クエリがクラスタの２つのノードで同期して実行されるアクティブ−アクティブ方式に依存している。一方のノードは、入力データの同じストリームに対して同じ連続クエリ演算子のセットを実行することによって、別のノードのバックアップとして機能する。これにより、通常、クラスタハードウェアの使用率はわずか５０％になる。

本開示の一実施形態では、上記の問題は、分散型フォールトトレラント記憶媒体において連続クエリの演算子の状態を保存するためにログベースの高速状態記憶を実行することによって対処することができる。一実施形態では、ログベースの高速状態記憶のプロセスは、イベント処理システム（たとえば９００）によって実行されてもよい。ログベースのアプローチを使用すると、状態は、後で回復するために、アペンド専用モードで関連データおよびメタデータとともに記憶媒体に永続保存される。

連続クエリは、連続して実行される演算子のグラフとして表すことができ、各ステートフル演算子は、自身の状態をメモリ内シノプシスの形式で維持する。失敗したクエリを回復するためには、イベント処理システムは、クエリグラフのすべてのステートフル演算子のメモリ内シノプシスを回復しなければならない。上述のように、システムの現在の状態は、イベントストリーム内のイベントに関連する入力待ち行列状態、演算子状態もしくはシノプシス、または出力待ち行列状態の３つの成分の複合表現として表すことができる。

演算子シノプシスは、本明細書で「演算子シノプシス」と呼ばれるメモリ内データ構造の形で各ステートフル連続演算子の状態を定義することを指す。任意の時刻ｔにおいて、演算子のシノプシスは、演算子の演算に関連する入力イベントおよびメタデータの収集を維持する。演算子シノプシスは、連続クエリの状態を定義し、イベント処理システムによってフェイルオーバーセマンティクスをサポートするよう使用できる。各演算子シノプシスは、メモリ内データ構造についての抽象化を表すので、イベント処理システムは、このデータ構造をアペンド専用のログベースのストレージにマッピングする。シノプシスデータ構造上のすべての操作に対して、イベント処理システムは、高速書込み機能を使用して、変更イベントを分散型フォールトストレージに追加する。イベント処理システムは、各演算子シノプシスを永続媒体のアペンド専用データ構造にマッピングする。

フェイルオーバーの前に、イベント処理システムは入力データストリームを継続的に受信し、それに応じて演算子の状態を更新する。連続クエリに対して入力ストリームからイベントバッチを完全に処理した後、イベント処理は入力モジュールからバッチ終了通知を受け取り、そのクエリにおけるすべての連続演算子に対する演算子シノプシスの永続保存を開始する。各演算子シノプシスについて、イベント処理システムは、そのシノプシスの関連付けられたデータ構造についてのすべての変更イベントを含むトランザクションを計算し、それをコンテナ（たとえばトピック）にアペンド専用スタイルで書き戻す。いくつかの例では、イベント処理システムは、永続状態において既存のログエントリを更新しようとしないことがある。

いくつかの実施形態では、イベント処理システムは、フェイルオーバーセマンティクス要件に基づいて上記の３つのオプションから状態成分を選択することによって、クエリの状態を定義する。イベント処理システムにおけるフェイルオーバーセマンティクスは、ａ）きっかり１回、ｂ）少なくとも１回、およびｃ）最大で１回の入力イベントの処理に基づいて定義することができる。

一実施形態では、イベント処理システムは、入力ストリームからの入来イベントをきっかり１回処理してもよい。連続クエリは、入力イベントをクエリグラフにおいてきっかり１回処理することによって出力イベントを発行する。きっかり１回のセマンティクスを提供するために、イベント処理システムは、連続クエリ状態を、演算子シノプシス、未処理のイベントバッチおよび出力シーケンス化メタデータの組み合わせとして定義する。

いくつかの実施形態では、イベント処理システムは、入力ストリームからの入力イベントを少なくとも１回処理してもよい。連続クエリは、連続演算子の状態回復の過程で複数回処理されるかもしれない入力イベントに対応する重複出力イベントを発し得る。少なくともセマンティクスを提供するために、イベント処理システムは、連続クエリ状態を演算子シノプシスと未処理の入力イベントバッチとの組み合わせとして定義する。このセマンティクスを使用して重複が許され得るので、出力シーケンス化メタデータを含める必要はない。

いくつかの実施形態では、イベント処理システムは、最大で１回だけ入力ストリームからの入力イベントを処理してもよい。連続クエリは、フェイルオーバープロセス中に処理されなかった入力イベントに対応するいくつかの出力イベントをスキップしてもよい。最大で１回のセマンティクスを提供するために、イベント処理システムは、これらのセマンティクスがフェイルオーバープロセス中にいくつかの出力イベントをスキップすることを許すので、連続クエリ状態を演算子シノプシスとして定義する。

一実施形態では、イベント処理システムは、ログベースの状態記憶から演算子シノプシスを再構成することができる。このプロセスには、入力ストリームの処理を開始する前に回復すべき連続クエリのクエリプランを初期化することが含まれる。たとえば、クエリプランの初期化中、イベント処理システムは、クエリプランの有向アクセスグラフ（ＤＡＧ）内の各連続演算子のメモリ内データ構造を作成し、初期化することができる。このプロセスは、連続演算子のメモリ内データ構造を初期化するために変更イベントのログを読み出すことを含む。このプロセスの間、イベント処理システムは、演算子状態について開始マーカから開始する変更イベントのパーシステントログからメッセージを読み出すことによって演算子シノプシスを初期化することができる。開始マーカは、連続クエリ演算子のシノプシスを再構築するのに必要なすべての変更イベントを含むようログ内の開始点を印すパーシステントログ内のオフセットを与える。一実施形態では、イベント処理システムは、これらのイベントを１つずつ読み出して、メモリ内データ構造を更新することができる。ログを読み終えると、連続演算子のメモリ内データ構造が初期化される。

いくつかの実施形態では、プロセスは、クエリ演算子を初期化するために、連続クエリ演算子の有向アクセスグラフをトポロジカルな順序でトラバースするステップをさらに含む。トラバースが終了すると、最初のクエリおよび演算子シノプシス復元のプロセスに対応する完全なＤＡＧが完了する。演算子シノプシスを完全に復元すると、プロセスは、入来データをイベントバッチの形で処理することを含んでもよい。一実施形態では、プロセスは、フェイルオーバーのセマンティクスに基づいて、どのバッチを読み出すべきかに関するイベント処理システムによる判断を実行することを含んでもよい。たとえば、一実施形態では、最大で１回の場合、イベント処理システムは、コンテナ（たとえばKafkaトピック）から最新のオフセットに対応するバッチを読み出す。コンテナから最新のオフセットを有するイベントが読み出されるので、イベント処理システムは、連続クエリの回復時間の間に受信された入力ストリームからいくつかのイベントを逃すかもしれない。別の実施形態では、イベント処理システムは、「きっかり１回」または「少なくとも１回」セマンティクスの場合に、コンテナから第１の未処理または部分的に処理されたイベントバッチを読み出すことができる。「きっかり１回」セマンティクスをサポートするために、イベント処理システムは、いくつかの例では、上述した出力シーケンス化を利用することができる。

例示的なプロセス
図１１は、本発明の特定の実施形態によるイベント処理サービスを提供するためのプロセス１１００を示す例示的なフロー図を示す。このプロセスは論理フロー図として示されており、その各動作は、ハードウェア、コンピュータ命令、またはそれらの組み合わせで実施することができる。コンピュータ命令の文脈において、動作は、１つ以上のプロセッサによって実行されると、記載された動作を実行する１つ以上のコンピュータ可読記憶媒体に格納されたコンピュータ実行可能命令を表すことができる。一般に、コンピュータ実行可能命令は、特定の機能を実行するかまたは特定のデータ型を実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。動作が記載される順序は、限定として解釈されることを意図するものではなく、任意の数の記載された動作を、任意の順序および／または並列で組み合わせて、プロセスを実施することができる。

さらに、プロセスのいくつか、いずれか、またはすべては、実行可能命令とともに構成された１つ以上のコンピュータシステムの制御下で実行されてもよく、まとめて、１つ以上のプロセッサ上で、ハードウェアによって、またはそれらの組み合わせで実行されるコード（たとえば実行可能命令、１つ以上のコンピュータプログラム、または１つ以上のアプリケーション）として実現されてもよい。上記のように、コードは、たとえば、１つ以上のプロセッサによって実行可能な複数の命令を含むコンピュータプログラムの形態で、コンピュータ可読記憶媒体に格納されてもよい。コンピュータ可読記憶媒体は、非一時的であってもよい。いくつかの例では、少なくとも図２、図３、図５は、図９（およびその他）に示されるイベント処理システム（たとえば少なくとも入力チャネル３０４、イベントバッチ判断部３０４、系統トラッキングモジュール３１２、出力シーケンス番号生成部５０２、イベント回復モジュール５０４およびスナップショット持続時間判断モジュール９０４を利用する）は、図６〜図８のプロセス６００，７００、および８００を実行することができる。

図１１は、本開示の一実施形態によるイベント処理サービスを提供するための例示的なプロセス１１００のフロー図を示す。プロセス１１００は、１１０２において、アプリケーションに関連するイベントの連続入力ストリームがイベント処理システムによって受信されたときに開始されてもよい。たとえば、イベント処理システムは、図２に示すように、１つ以上のイベントソース（２０４，２０６または２０８）からイベントの連続入力ストリームを受信することができる。イベントの連続入力ストリームを受信すると、１１０４で、イベント処理システムは、連続クエリを使用してイベントの第１のバッチを処理して、アプリケーションに関連するイベントの出力ストリームを生成する。１１０６で、イベント処理システムは、連続クエリの１つ以上の演算子を識別する。たとえば、イベント処理システムは、クエリに対して生成される物理クエリプランから連続クエリの演算子を識別することができる。上述のように、物理クエリプランは、連続クエリの物理演算子の有向非循環グラフ（ＤＡＧ）を含むことができる。

いくつかの例では、１１０８において、イベント処理システムは、連続クエリの演算子が「ジャーナリングされた演算子」であるかどうかを判断する。次いで、スナップショット持続時間判断部９０４によってイベントの第１のバッチに対して「ジャーナリングされたスナップショット」が生成される。上述のように、「ジャーナリングされた演算子」は、ジャーナリングされたスナップショットを作成することができる演算子を指す。演算子が「ジャーナリングされた演算子」であると識別された場合、１１１４で、イベント処理システムは、イベントストリームのイベントのセット（すなわち、イベントの第１のバッチ）における「ジャーナリングされた演算子」の実行に対応するシステムの現在の状態の「ジャーナリングされたスナップショット」を生成する。いくつかの例では、１１１６において、イベント処理システムは、システムの現在の状態の「ジャーナリングされたスナップショット」を記憶する。演算子が「ジャーナリングされていない演算子」であると識別された場合、１１１６で、イベント処理システムは、イベントストリームのイベントのセット（たとえばイベントの第１のバッチ）についてシステムの現在の状態の「フルスナップショット」を生成する。いくつかの例では、１１１２で、イベント処理システムは、システムの現在の状態の「フルスナップショット」を記憶する。

図１２〜図１３は、さまざまな実施形態による本発明の態様を実施するための例示的環境の態様を示す。図１２は、本開示の一実施形態を実施するための分散型システム１２００の簡略図を示す。図示の実施形態では、分散型システム１２００は、１つ以上のネットワーク１２１０でウェブブラウザ、所有権を主張できるクライアント（たとえばOracle Forms）などのクライアントアプリケーションを実行し動作させるように構成された１つ以上のクライアントコンピューティングデバイス２００２，２００４，２００６および２００８を含む。サーバ１２１２は、ネットワーク１２１０を介してリモートクライアントコンピューティングデバイス１２０２，１２０４，１２０６および１２０８と通信可能に結合されてもよい。

さまざまな実施形態では、サーバ１２１２は、アイデンティティ管理サービスを提供するサービスおよびアプリケーションなどの１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。特定の実施形態では、サーバ１２１２は、非仮想および仮想環境を含むことができる他のサービスまたはソフトウェアアプリケーションも提供できる。いくつかの実施形態では、これらのサービスは、ウェブベースのサービスもしくはクラウドサービスとして、またはソフトウェア・アズ・ア・サービス（ＳａａＳ）モデルの下で、クライアントコンピューティングデバイス１２０２，１２０４，１２０６および/または１２０８のユーザに対して提供されてもよい。クライアントコンピューティングデバイス１２０２，１２０４，１２０６および/または１２０８を動作させるユーザは、次いで、１つ以上のクライアントアプリケーションを利用してサーバ１２１２と対話して、これらのコンポーネントによって提供されるサービスを利用してもよい。

図１２に示される構成では、システム１２００のソフトウェアコンポーネント１２１８，１２２０および１２２２は、サーバ１２１２上で実現されるものとして示されている。他の実施形態では、システム１２００のコンポーネントのうちの１つ以上および／またはこれらのコンポーネントによって提供されるサービスは、クライアントコンピューティングデバイス１２０２，１２０４，１２０６および／または１２０８のうちの１つ以上によって実現されてもよい。クライアントコンピューティングデバイスを動作させるユーザは、次いで、１つ以上のクライアントアプリケーションを利用して、これらのコンポーネントによって提供されるサービスを用いてもよい。これらのコンポーネントはハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せにおいて実現されてもよい。分散型システム１２００とは異なってもよいさまざまな異なるシステム構成が可能であることが理解されるべきである。図１２に示される実施形態は、したがって、実施形態のシステムを実現するための分散型システムの一例であり、限定的であるよう意図されるものではない。

クライアントコンピューティングデバイス１２０２，１２０４，１２０６、および／または１２０８は、さまざまなタイプのコンピューティングシステムを含むことができる。たとえば、クライアントデバイスは、携帯可能な手持ち式のデバイス（たとえば、ｉＰｈｏｎｅ（登録商標）、セルラー電話、ｉＰａｄ（登録商標）、コンピューティングタブレット、携帯情報端末（ＰＤＡ））またはウェアラブルデバイス（たとえばＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）頭部装着型ディスプレイ）であってもよく、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標） Ｍｏｂｉｌｅ（登録商標）などのソフトウェア、および／もしくは、ｉＯＳ、Ｗｉｎｄｏｗｓ Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ、ＢｌａｃｋＢｅｒｒｙ１０、Ｐａｌｍ ＯＳなどのさまざまなモバイルオペレーティングシステムを動作させる。クライアントデバイスは、インターネット関連アプリケーション、電子メール、ショートメッセージサービス（ＳＭＳ）アプリケーションのようなさまざまなアプリケーションをサポートしてもよく、さまざまな他の通信プロトコルを使用してもよい。クライアントコンピューティングデバイスは、汎用パーソナルコンピュータであってもよく、一例として、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、 Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）および／またはＬｉｎｕｘ（登録商標）オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび／またはラップトップコンピュータも含んでもよい。クライアントコンピューティングデバイスは、たとえばＧｏｏｇｌｅ Ｃｈｒｏｍｅ ＯＳなどのさまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステムを限定を伴うことなく含む、さまざまな市場で入手可能なＵＮＩＸ（登録商標）またはＵＮＩＸのようなオペレーティングシステムのいずれかを実行するワークステーションコンピュータであり得る。クライアントコンピューティングデバイスは、また、ネットワーク１２１０を介して通信することができる、シンクライアントコンピュータ、インターネットにより可能化されるゲームシステム（たとえば、Ｋｉｎｅｃｔ（登録商標）ジェスチャ入力デバイスを伴うかまたは伴わないＭｉｃｒｏｓｏｆｔ Ｘｂｏｘゲームコンソール）および／または個人メッセージ伝達デバイスなどの電子デバイスを含んでもよい。

図１２の分散型システム１２００は、４つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを伴うデバイスなど、他のデバイスがサーバ１２１２と対話してもよい。

分散型システム１２００におけるネットワーク１２１０は、ＴＣＰ／ＩＰ（伝送制御プロトコル／インターネットプロトコル）、ＳＮＡ（システムネットワークアーキテクチャ）、ＩＰＸ（インターネットパケット交換）、ＡｐｐｌｅＴａｌｋなどを限定を伴うことなく含む、さまざまな入手可能なプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者が精通している任意のタイプのネットワークであってもよい。単なる例として、ネットワーク１２１０は、ローカルエリアネットワーク（ＬＡＮ）、イーサネット（登録商標）に基づくネットワーク、トークンリング、ワイドエリアネットワーク、インターネット（登録商標）、仮想ネットワーク、仮想プライベートネットワーク（ＶＰＮ）、イントラネット、エクストラネット、公衆交換電話網（ＰＳＴＮ）、赤外線ネットワーク、無線ネットワーク（たとえば電気電子学会（ＩＥＥＥ）１００２．１１プロトコルのいずれかの下で動作するネットワーク、ブルートゥース（登録商標）および／もしくは任意の他の無線プロトコル）、ならびに／またはこれらおよび／もしくは他のネットワークの任意の組み合わせを含むことができる。

サーバ１２１２は、１つ以上の汎用コンピュータ、専用のサーバコンピュータ（一例としてＰＣ（パーソナルコンピュータ）サーバ、ＵＮＩＸ（登録商標）サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む）、サーバファーム、サーバクラスタ、またはその他の適切な構成および／または組み合わせで構成されてもよい。サーバ１２１２は、仮想オペレーティングシステムを実行する１つ以上の仮想マシン、または仮想化を伴う他のコンピューティングアーキテクチャを含み得る。論理ストレージデバイスの１つ以上の柔軟なプールを仮想化してサーバのために仮想ストレージデバイスを維持することができる。仮想ネットワークを、サーバ１２１２によって、ソフトウェア定義のネットワーク接続を用いて制御することができる。さまざまな実施形態において、サーバ１２１２は、前述の開示に記載される１つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。たとえば、サーバ１２１２は、本開示の実施形態に従って上記の処理を実行するためのサーバに対応してもよい。

サーバ１２１２は、上記のもののうちのいずれかを含むオペレーティングシステム、および任意の市場で入手可能なサーバオペレーティングシステムを実行してもよい。サーバ１２１２は、ＨＴＴＰ（ハイパーテキスト転送プロトコル）サーバ、ＦＴＰ（ファイル転送プロトコル）サーバ、ＣＧＩ（コモンゲートウェイインターフェイス）サーバ、ＪＡＶＡ（登録商標）サーバ、データベースサーバなどを含むさまざまなさらに他のサーバアプリケーションおよび／または中間層アプリケーションのうちのいずれかも実行してもよい。例示的なデータベースサーバは、オラクル、マイクロソフト、サイベース、ＩＢＭ（インターナショナルビジネスマシンズ）などから市場で入手可能なものを含むが、それらに限定されるものではない。

いくつかの実現例では、サーバ１２１２は、クライアントコンピューティングデバイス１２０２，１２０４，１２０６および１２０８のユーザから受信されるデータフィードおよび／またはイベント更新情報を解析および整理統合するための１つ以上のアプリケーションを含んでもよい。一例として、データフィードおよび／またはイベント更新情報は、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通監視などに関連するリアルタイムのイベントを含んでもよい、１つ以上の第三者情報源および連続データストリームから受信される、Ｔｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新情報またはリアルタイムの更新情報を含んでもよいが、それらに限定されるものではない。サーバ１２１２は、データフィードおよび／またはリアルタイムのイベントをクライアントコンピューティングデバイス１２０２，１２０４，１２０６および１２０８の１つ以上の表示デバイスを介して表示するための１つ以上のアプリケーションも含んでもよい。

分散型システム１２００は、１つ以上のデータベース１２１４および１２１６も含んでもよい。これらのデータベースは、ユーザ識別情報、および本発明の実施形態によって使用される他の情報などの情報を格納するためのメカニズムを提供することができる。データベース１２１４および１２１６は、さまざまな位置にあってもよい。一例として、データベース１２１４および１２１６のうちの１つ以上は、サーバ１２１２に局在する（および／またはサーバ１２１２に常駐する）非一時的な記憶媒体にあってもよい。代替的に、データベース１２１４および１２１６は、サーバ１２１２から遠隔にあり、ネットワークベースまたは専用の接続を介してサーバ１２１２と通信してもよい。一組の実施形態では、データベース１２１４および１２１６は、記憶域ネットワーク（ＳＡＮ）にあってもよい。同様に、サーバ１２１２に帰する機能を実行するための任意の必要なファイルが、適宜、サーバ１２１２上においてローカルに、および／または遠隔で格納されてもよい。一組の実施形態では、データベース１２１４および１２１６は、ＳＱＬフォーマットされたコマンドに応答してデータを格納、更新および検索取得するように適合される、オラクルによって提供されるデータベースなどのリレーショナルデータベースを含んでもよい。

図１３は、本発明の実施形態を実施するために使用され得る例示的なコンピュータシステム１３００を示す。いくつかの実施形態では、コンピュータシステム１３００を使用して、上述したさまざまなサーバおよびコンピュータシステムのいずれかを実装することができる。図１３に示すように、コンピュータシステム１３００は、バスサブシステム１３０２を介して複数の周辺サブシステムと通信する処理サブシステム１３０４を含むさまざまなサブシステムを含む。これらの周辺サブシステムは、処理加速ユニット１３０６、Ｉ／Ｏサブシステム１３０８、ストレージサブシステム１３１８および通信サブシステム１３２４を含んでもよい。ストレージサブシステム１３１８は、有形のコンピュータ可読記憶媒体１３２２およびシステムメモリ１１３１０を含む。

バスサブシステム１３０２は、コンピュータシステム１３００のさまざまなコンポーネントおよびサブシステムに意図されるように互いに通信させるための機構を提供する。バスサブシステム１３０２は単一のバスとして概略的に示されているが、バスサブシステムの代替的実施例は、複数のバスを利用してもよい。バスサブシステム１３０２は、さまざまなバスアーキテクチャのうちのいずれかを用いるメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、業界標準アーキテクチャ（Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ：ＩＳＡ）バス、マイクロチャネルアーキテクチャ（Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ：ＭＣＡ）バス、エンハンストＩＳＡ（Ｅｎｈａｎｃｅｄ ＩＳＡ：ＥＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ：ＶＥＳＡ）ローカルバス、およびＩＥＥＥ Ｐ１３８６．１規格に従って製造される中二階バスとして実現され得る周辺コンポーネントインターコネクト（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ：ＰＣＩ）バスなどを含んでもよい。

処理サブシステム１３０４は、コンピュータシステム１３００の動作を制御し、１つ以上の処理ユニット１３３２，１３３４などを含むことができる。処理ユニットは、単一コアまたはマルチコアプロセッサを含む１つ以上のプロセッサ、１つ以上のプロセッサコア、またはそれらの組み合わせであってもよい。いくつかの実施形態では、処理サブシステム１３０４は、グラフィックスプロセッサ、デジタル信号プロセッサ（ＤＳＰ）などのような１つ以上の専用コプロセッサを含むことができる。いくつかの実施形態では、処理サブシステム１３０４の処理ユニットの一部または全部は、特定用途向け集積回路（ＡＳＩＣ）またはフィールドプログラマブルゲートアレイ（ＦＰＧＡ）などのカスタマイズされた回路を使用して実装することができる。

いくつかの実施形態では、処理サブシステム１３０４内の処理ユニットは、システムメモリ１３１０またはコンピュータ可読記憶媒体１３２２に格納された命令を実行することができる。さまざまな実施形態では、処理ユニットはさまざまなプログラムまたはコード命令を実行し、複数の同時に実行するプログラムまたはプロセスを維持できる。任意の所与の時点で、実行されるべきプログラムコードの一部または全部は、システムメモリ１３１０および／または潜在的に１つ以上の記憶装置を含むコンピュータ可読記憶媒体１３１０に常駐することができる。適切なプログラミングを介して、処理サブシステム１３０４は、使用パターンに応答して文書（たとえばウェブページ）を動的に修正するために上記のさまざまな機能を提供することができる。

特定の実施形態では、コンピュータシステム１３００によって実行される全体的な処理を加速するよう、カスタマイズされた処理を実行するために、または処理サブシステム１３０４によって実行される処理の一部をオフロードするために、処理加速ユニット１３０６を設けることができる。

Ｉ／Ｏサブシステム１３０８は、コンピュータシステム１３００に情報を入力するための、および／またはコンピュータシステム１３００から、もしくはコンピュータシステム１３００を介して、情報を出力するための、デバイスおよび機構を含むことができる。一般に、「入力デバイス」という語の使用は、コンピュータシステム１３００に情報を入力するための全ての考えられ得るタイプのデバイスおよび機構を含むよう意図される。ユーザインターフェイス入力デバイスは、たとえば、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを伴う音声入力デバイス、マイクロフォン、および他のタイプの入力デバイスを含んでもよい。ユーザインタフェース入力デバイスは、ユーザが入力デバイスを制御しそれと対話することを可能にするＭｉｃｒｏｓｏｆｔ Ｋｉｎｅｃｔ（登録商標）モーションセンサ、Ｍｉｃｒｏｓｏｆｔ Ｘｂｏｘ（登録商標）３６０ゲームコントローラ、ジェスチャーおよび音声コマンドを用いる入力を受信するためのインタフェースを提供するデバイスなど、モーションセンシングおよび／またはジェスチャ認識デバイスも含んでもよい。ユーザインターフェイス入力デバイスは、ユーザから目の動き（たとえば、写真を撮っている間および／またはメニュー選択を行なっている間の「まばたき」）を検出し、アイジェスチャを入力デバイス（たとえばＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標））への入力として変換するＧｏｏｇｌｅ Ｇｌａｓｓ（登録商標）瞬き検出器などのアイジェスチャ認識デバイスも含んでもよい。また、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを介して音声認識システム（たとえばＳｉｒｉ（登録商標）ナビゲータ）と対話することを可能にする音声認識感知デバイスを含んでもよい。

ユーザインターフェイス入力デバイスの他の例は、三次元（３Ｄ）マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびにスピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ３Ｄスキャナ、３Ｄプリンタ、レーザレンジファインダ、および視線追跡デバイスなどの聴覚／視覚デバイスも含んでもよいが、それらに限定されるものではない。また、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影、磁気共鳴撮像、ポジションエミッショントモグラフィー、医療用超音波検査デバイスなどの医療用画像化入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、たとえば、ＭＩＤＩキーボード、デジタル楽器などの音声入力デバイスも含んでもよい。

ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、インジケータライト、または音声出力デバイスなどの非ビジュアルディスプレイなどを含んでもよい。ディスプレイサブシステムは、陰極線管（ＣＲＴ）、液晶ディスプレイ（ＬＣＤ）またはプラズマディスプレイを使うものなどのフラットパネルデバイス、投影デバイス、タッチスクリーンなどであってもよい。一般に、「出力デバイス」という語の使用は、コンピュータシステム１３００からユーザまたは他のコンピュータに情報を出力するための全ての考えられ得るタイプのデバイスおよび機構を含むよう意図される。たとえば、ユーザインターフェイス出力デバイスは、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力デバイスおよびモデムなどの、テキスト、グラフィックスおよび音声／映像情報を視覚的に伝えるさまざまな表示デバイスを含んでもよいが、それらに限定されるものではない。

ストレージサブシステム１３１８は、コンピュータシステム１３００によって使用される情報を格納するためのリポジトリまたはデータストアを提供する。ストレージサブシステム１３１８は、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構成を記憶するための有形の非一時的なコンピュータ可読記憶媒体を提供する。処理サブシステム１３０４によって実行されると、上述の機能を提供するソフトウェア（プログラム、コードモジュール、命令）が、ストレージサブシステム１３１８に格納されてもよい。ソフトウェアは、処理サブシステム１３０４の１つ以上の処理ユニットによって実行されてもよい。ストレージサブシステム１３１８はまた、本発明に従って使用されるデータを格納するためのリポジトリを提供してもよい。

ストレージサブシステム１３１８は、揮発性および不揮発性メモリデバイスを含む１つ以上の非一時的メモリデバイスを含むことができる。図１３に示すように、ストレージサブシステム１３１８は、システムメモリ１３１０およびコンピュータ可読記憶媒体１３２２を含む。システムメモリ１３１０は、プログラム実行中に命令およびデータを記憶するための揮発性主ランダムアクセスメモリ（ＲＡＭ）と、固定命令が記憶される不揮発性読み出し専用メモリ（ＲＯＭ）またはフラッシュメモリとを含む、いくつかのメモリを含むことができる。いくつかの実現例では、起動中などにコンピュータシステム１３００内の要素間における情報の転送を助ける基本的なルーチンを含むベーシックインプット／アウトプットシステム（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ：ＢＩＯＳ）は、典型的には、ＲＯＭに記憶されてもよい。ＲＡＭは、通常、処理サブシステム１３０４によって現在動作され実行されているデータおよび／またはプログラムモジュールを含む。いくつかの実現例では、システムメモリ１３１０は、スタティックランダムアクセスメモリ（ＳＲＡＭ）またはダイナミックランダムアクセスメモリ（ＤＲＡＭ）などの複数の異なるタイプのメモリを含んでもよい。

一例として、限定を伴うことなく、図１３に示されるように、システムメモリ１３１０は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム（ＲＤＢＭＳ）などを含んでもよいアプリケーションプログラム１３１２、プログラムデータ１３１４およびオペレーティングシステム１３１６を記憶してもよい。一例として、オペレーティングシステム１３１６は、Ｍｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ａｐｐｌｅ Ｍａｃｉｎｔｏｓｈ（登録商標）および／もしくはＬｉｎｕｘオペレーティングシステム、さまざまな市場で入手可能なＵＮＩＸ（登録商標）またはＵＮＩＸのようなオペレーティングシステム（さまざまなＧＮＵ／Ｌｉｎｕｘオペレーティングシステム、Ｇｏｏｇｌｅ Ｃｈｒｏｍｅ（登録商標）ＯＳなどを含むがそれらに限定されない）、ならびに／または、ｉＯＳ、Ｗｉｎｄｏｗｓ（登録商標） Ｐｈｏｎｅ、Ａｎｄｒｏｉｄ（登録商標） ＯＳ、ＢｌａｃｋＢｅｒｒｙ（登録商標）１０ ＯＳ、およびＰａｌｍ（登録商標） ＯＳオペレーティングシステムなどのモバイルオペレーティングシステムのさまざまなバージョンを含んでもよい。

コンピュータ可読記憶媒体１３２２は、いくつかの実施形態の機能性を提供するプログラミングおよびデータ構成を格納することができる。処理サブシステム１３０４によって実行されると、プロセッサが上記の機能を提供するソフトウェア（プログラム、コードモジュール、命令）は、ストレージサブシステム１３１８に格納されてもよい。一例として、コンピュータ可読記憶媒体１３２２は、ハードディスクドライブ、磁気ディスクドライブ、ＣＤ ＲＯＭ、ＤＶＤ、Ｂｌｕ−Ｒａｙ（登録商標）ディスクなどの光ディスクドライブ、またはその他の光学媒体のような不揮発性メモリを含むことができる。コンピュータ可読記憶媒体１３２２は、Ｚｉｐ（登録商標）ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス（ＵＳＢ）フラッシュドライブ、セキュアデジタル（ＳＤ）カード、ＤＶＤディスク、デジタルビデオテープなどを含んでもよいが、それらに限定されるものではない。コンピュータ可読記憶媒体１３２２は、フラッシュメモリベースのＳＳＤ、エンタープライズフラッシュドライブ、ソリッドステートＲＯＭなどの不揮発性メモリに基づくソリッドステートドライブ（ＳＳＤ）、ソリッドステートＲＡＭ、ダイナミックＲＡＭ、スタティックＲＡＭなどの揮発性メモリに基づくＳＳＤ、ＤＲＡＭベースのＳＳＤ、磁気抵抗ＲＡＭ（ＭＲＡＭ）ＳＳＤ、およびＤＲＡＭとフラッシュメモリベースのＳＳＤとの組み合わせを使用するハイブリッドＳＳＤも含んでもよい。コンピュータ可読媒体１３２２は、コンピュータシステム１３００のためのコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージを提供することができる。

ある実施形態では、ストレージサブシステム１３１８は、コンピュータ可読記憶媒体１３２２にさらに接続可能なコンピュータ可読記憶媒体リーダ１３２０も含んでもよい。システムメモリ１３１０とともに、およびオプションとしてシステムメモリ１３１０との組み合わせで、コンピュータ可読記憶媒体１３２２は、コンピュータ可読情報を記憶するためにリモート、ローカル、固定および／またはリムーバブル記憶装置に記憶媒体を加えたものを包括的に表してもよい。

特定の実施形態では、コンピュータシステム３００は、１つ以上の仮想マシンを実行するためのサポートを提供することができる。コンピュータシステム１３００は、仮想マシンの構成および管理を容易にするためのハイパーバイザなどのプログラムを実行することができる。各仮想マシンは、メモリ、計算（たとえばプロセッサ、コア）、Ｉ／Ｏ、およびネットワーキングリソースを割り当てられてもよい。各仮想マシンは、通常、コンピュータシステム１３００によって実行される他の仮想マシンによって実行されるオペレーティングシステムと同じでも異なってもよい、それ自体のオペレーティングシステムを実行する。したがって、複数のオペレーティングシステムが潜在的にコンピュータシステム１３００によって同時に実行され得る。各仮想マシンは、通常、他の仮想マシンとは独立して動作する。

通信サブシステム１３２４は、他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム１３２４は、他のシステムとコンピュータシステム１３００との間のデータの送受のためのインターフェイスとして働く。たとえば、通信サブシステム１３２４は、コンピュータシステム１３００が、１つ以上のクライアントデバイスとの間で情報を送受信するために、インターネットを介して１つ以上のクライアントデバイスへの通信チャネルを確立することを可能にすることができる。さらに、通信サブシステム１３２４を使用して、成功したログインの通知、または特権アカウントマネージャから要求側ユーザへのパスワードの再入力の通知を伝達することができる。

通信サブシステム１３２４は、有線および／または無線通信プロトコルの両方をサポートすることができる。たとえば、ある実施形態では、通信サブシステム１３２４は、（たとえば、セルラー電話技術、３Ｇ、４ＧもしくはＥＤＧＥ（グローバル進化のための高速データレート）などの先進データネットワーク技術、ＷｉＦｉ（ＩＥＥＥ８０２．１１ファミリー規格、もしくは他のモバイル通信技術、またはそれらのいずれかの組み合わせを用いて）無線音声および／またはデータネットワークにアクセスするための無線周波数（ＲＦ）送受信機コンポーネント、グローバルポジショニングシステム（ＧＰＳ）受信機コンポーネント、ならびに／または他のコンポーネントを含んでもよい。いくつかの実施形態では、通信サブシステム１３２４は、無線インターフェイスに加えて、またはその代わりに、有線ネットワーク接続（たとえば、イーサネット）を提供することができる。

通信サブシステム１３２４は、さまざまな形式でデータを受信し、送信することができる。たとえば、いくつかの実施形態では、通信サブシステム１３２４は、構造化データフィードおよび／または非構造化データフィード１３２６、イベントストリーム１３２８、イベント更新１３３０などの形式で入力通信を受信することができる。たとえば、通信サブシステム１３２４は、ソーシャルメディアネットワークおよび／またはＴｗｉｔｔｅｒ（登録商標）フィード、Ｆａｃｅｂｏｏｋ（登録商標）更新情報、Ｒｉｃｈ Ｓｉｔｅ Ｓｕｍｍａｒｙ（ＲＳＳ）フィードなどのウェブフィード、および／もしくは１つ以上の第三者情報源からのリアルタイム更新情報などの他の通信サービスのユーザからリアルタイムでデータフィード１３２６を受信（または送信）するように構成されてもよい。

ある実施形態では、通信サブシステム１３２４は、連続データストリームの形式でデータを受信するように構成されてもよく、当該連続データストリームは、明確な終端を持たない、本来は連続的または無限であり得るリアルタイムイベントのイベントストリーム１３２８および／またはイベント更新情報１３３０を含んでもよい。連続データを生成するアプリケーションの例としては、たとえば、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通監視などを挙げることができる。

また、通信サブシステム１３２４は、構造化されたおよび／または構造化されていないデータフィード１３２６、イベントストリーム１３２８、イベント更新情報１３３０などを、コンピュータシステム１３００に結合される１つ以上のストリーミングデータソースコンピュータと通信し得る１つ以上のデータベースに出力するよう構成されてもよい。

コンピュータシステム１３００は、手持ち式の携帯デバイス（たとえば、ｉＰｈｏｎｅ（登録商標）携帯電話、ｉＰａｄ（登録商標）コンピューティングタブレット、ＰＤＡ）、ウェアラブルデバイス（たとえば、Ｇｏｏｇｌｅ Ｇｌａｓｓ（登録商標）頭部装着型ディスプレイ）、パソコン、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、さまざまなタイプのもののうちの１つであり得る。

常に変化するコンピュータおよびネットワークの性質のため、図１３に示されるコンピュータシステム１３００の記載は、単に具体的な例として意図される。図１３に示されるシステムよりも多くのコンポーネントまたは少ないコンポーネントを有する多くの他の構成が可能である。本明細書における開示および教示に基づいて、当業者は、さまざまな実施形態を実現するための他の態様および／または方法を理解するであろう。

いくつかの図面に示されたシステムは、さまざまな構成で提供されてもよい。いくつかの実施形態では、システムは、システムの１つ以上のコンポーネントが１つ以上のクラウドインフラストラクチャシステムの１つ以上のネットワークに分散された分散型システムとして構成することができる。

クラウドインフラストラクチャシステムは、１つ以上のサーバコンピューティングデバイス、ネットワークデバイス、および／またはストレージデバイスの集合である。これらのリソースは、クラウドサービスプロバイダによって分割され、何らかの方法で顧客に割り当てられてもよい。たとえば、カリフォルニア州レッドウッドショアーズのオラクルコーポレーションのようなクラウドサービスプロバイダは、さまざまなタイプのクラウドサービスを提供し得、それらは、サービスとしてのソフトウェア（ＳａａＳ）カテゴリで提供される１つ以上のサービス、サービスとしてのプラットフォーム（ＰａａＳ）カテゴリで提供されるサービス、サービスとしてのインフラストラクチャ（ｌａａＳ）カテゴリで提供されるサービス、またはハイブリッドサービスを含む他のカテゴリのサービスを含むが、それらに限定はされない。ＳａａＳサービスの例としては、Oracle Fusionアプリケーションなどのオンデマンドアプリケーションの一式を構築して提供する機能があるが、これに限定されない。ＳａａＳサービスは、顧客が、クラウドインフラストラクチャシステム上で実行されているアプリケーションのためのソフトウェアを購入する必要なく、そのようなアプリケーションを利用することを可能にする。ＰａａＳサービスの例としては、組織（オラクルなど）が共有された共通アーキテクチャー上で既存のアプリケーションを統合できるようにするサービスや、Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS)などのプラットフォームによって提供される共有サービスを活用する新たなアプリケーションを構築する能力を含むが、それらに限定はされない。ＩａａＳサービスは、通常、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客のためのストレージ、ネットワーク、およびその他の基本的な計算資源などの基盤となる計算資源の管理および制御を容易にする。

本発明の特定の実施形態について説明したが、本発明の範囲内で、さまざまな修正、変更、代替構成、および同等物も包含される。本発明の実施形態は、ある特定のデータ処理環境内の動作に限定されず、複数のデータ処理環境内で自由に動作することができる。さらに、本発明の実施形態は特定の一連のトランザクションおよびステップを使用して記載されたが、本発明の範囲は記載された一連のトランザクションおよびステップに限定されないことは当業者には明らかである。上述した実施形態のさまざまな特徴および態様は、個別にまたはともに使用されてもよい。

さらに、本発明の実施形態をハードウェアとソフトウェアとの特定の組み合わせを用いて記載したが、ハードウェアとソフトウェアとの他の組み合わせも本発明の範囲内であることを認識すべきである。本発明の実施形態は、ハードウェアでのみ、またはソフトウェアでのみ、またはそれらの組み合わせを用いて実施されてもよい。本明細書に記載されたさまざまなプロセスは、同じプロセッサまたは任意の組み合わせの異なるプロセッサ上で実現できる。したがって、構成要素またはモジュールが特定の動作を実行するように構成されるとして記載されている場合、そのような構成は、たとえば、動作を実行する電子回路を設計すること、プログラミング可能な電子回路（マイクロプロセッサなど）をプログラミングして動作を実行すること、またはそれらの任意の組み合わせによって達成され得る。プロセスは、プロセス間通信のための従来の技術を含むがこれに限定されないさまざまな技術を使用して通信することができ、異なる対のプロセスは異なる技術を使用してもよく、同じ対のプロセスは異なる時間に異なる技術を使用してもよい。

別の実施形態によれば、本開示は、以下の節を使用して説明することができる：アプリケーションに関連するイベントの連続入力ストリームを受信するための手段と、アプリケーションに関連するイベントの出力ストリームを生成するためにイベントの連続入力ストリームを処理するための手段と、イベントの出力ストリームにおける出力イベントについて出力シーケンス番号を判断するための手段と、イベントの出力ストリームにおける出力イベントを送信するための手段と、出力イベントの出力シーケンス番号を記憶するための手段と、イベントの連続入力ストリームが処理されている間にシステムの障害の表示を受信するための手段と、イベントの出力ストリームにおける最も最近送信された出力イベントの現在の出力シーケンス番号を判断するための手段と、入力イベントの最も最近処理されたバッチに対応する出力イベントの最後の出力シーケンス番号を判断するための手段と、現在のシーケンス番号および最後の出力シーケンス番号に基づいて、送信されるべき出力ストリームの１つ以上の出力イベントのセットを判断するための手段と、アプリケーションに関連する１つ以上の出力イベントのセットを送信するための手段とを含む、システム。いくつかの実施形態では、システムは、システムの障害の表示を受信することに基づいて、イベントの出力ストリームにおける最も最近送信された出力イベントの現在の出力シーケンス番号から出力イベントを送信するための手段を含む。このシステムは、イベントの連続入力ストリームから１つ以上のイベントバッチのセットを生成するための手段を備える。いくつかの実施形態では、システムは、チェックポイントマーカイベントを生成するための手段と、チェックポイントマーカイベントをイベントの連続入力ストリームに挿入するための手段と、チェックポイントマーカイベントに基づいて１つ以上のイベントバッチのセットを生成するための手段とを備える。

したがって、明細書および図面は、限定的な意味ではなく例示的であると見なされるべきである。しかしながら、特許請求の範囲に記載されたより広範な精神および範囲から逸脱することなく、追加、削減、削除、ならびに他の修正および変更がなされ得ることは明らかであろう。このように、特定の発明の実施形態を説明したが、これらは限定することを意図するものではない。さまざまな修正および均等物は、特許請求の範囲内にある。修正および変形は、開示された特徴/要素の任意の関連する組み合わせを含む。

Claims (17)

1. システムであって、
   複数の命令を格納するメモリと、
   前記メモリにアクセスするように構成された１つ以上のプロセッサとを備え、前記１つ以上のプロセッサは、さらに、前記複数の命令を実行して、少なくとも、
   アプリケーションに関連するイベントの連続入力ストリームを受信し、
   前記イベントの連続入力ストリームを処理して、前記アプリケーションに関連するイベントの出力ストリームを生成し、
   前記イベントの出力ストリームにおける出力イベントについて出力シーケンス番号を判断し、
   前記イベントの出力ストリームにおける前記出力イベントを送信し、
   前記出力イベントの前記出力シーケンス番号を記憶し、
   前記イベントの連続入力ストリームが処理されている間に、前記システムの障害の表示を受信し、
   前記イベントの出力ストリームにおいて最も最近送信された出力イベントの現在の出力シーケンス番号を判断し、
   最も最近処理された入力イベントのバッチに対応する出力イベントの最後の出力シーケンス番号を判断し、
   前記現在の出力シーケンス番号および前記最後の出力シーケンス番号に基づいて送信されるべき前記出力ストリームの１つ以上の出力イベントのセットを判断し、
   前記アプリケーションに関連する前記１つ以上の出力イベントのセットを送信するよう構成されている、システム。
2. 前記１つ以上のプロセッサは、送信されるべき前記１つ以上の出力イベントのセットにおいて１つ以上の出力イベントを除外するようにさらに構成されている、請求項１に記載のシステム。
3. 前記１つ以上のプロセッサは、前記システムの障害の表示を受信することに基づいて、前記イベントの出力ストリーム内の前記最も最近送信された出力イベントの前記現在の出力シーケンス番号から出力イベントを送信するようにさらに構成されている、請求項１または２に記載のシステム。
4. 前記１つ以上のプロセッサは、前記イベントの連続入力ストリームから１つ以上のイベントバッチのセットを生成するようにさらに構成されている、請求項１から３のいずれか１項に記載のシステム。
5. 前記１つ以上のプロセッサは、さらに、
   チェックポイントマーカイベントを生成し、
   前記チェックポイントマーカイベントを前記イベントの連続入力ストリームに挿入し、
   前記チェックポイントマーカイベントに基づいて前記１つ以上のイベントバッチのセットを生成するよう構成されている、請求項４に記載のシステム。
6. 前記チェックポイントマーカイベントは、前記イベントの連続入力ストリームにおける入力イベントに関連する情報を表す、請求項５に記載のシステム。
7. イベントバッチのサイズは、前記チェックポイントマーカイベントに基づいて判断される、請求項５または６に記載のシステム。
8. 前記１つ以上のプロセッサは、さらに、
   前記チェックポイントマーカイベントを処理し、
   前記チェックポイントマーカイベントの処理に基づいて、前記１つ以上のイベントバッチのセット内の第１のイベントバッチの処理の完了を示す確認メッセージを送信し、
   前記システムの現在の状態のスナップショットを生成するように構成されている、請求項５〜７のいずれか１項に記載のシステム。
9. 前記システムの現在の状態のスナップショットは、少なくとも前記イベントの第１のバッチに関連する入力待ち行列状態、演算子状態、または出力待ち行列状態のうちの少なくとも１つに関連する情報を含む、請求項８に記載のシステム。
10. 前記１つ以上のプロセッサは、前記イベントの出力ストリームにおける出力イベントの出力シーケンス番号を、前記スナップショットの一部として記憶するようにさらに構成されている、請求項８または９に記載のシステム。
11. システムによって実行される方法であって、
    前記システムのプロセッサが、アプリケーションに関連するイベントの連続入力ストリームを受信することと、
    前記プロセッサが、前記イベントの連続入力ストリームを処理して、前記アプリケーションに関連するイベントの出力ストリームを生成することと、
    前記プロセッサが、前記イベントの出力ストリームにおける出力イベントについて出力シーケンス番号を判断することと、
    前記プロセッサが、前記イベントの出力ストリームにおける前記出力イベントを送信することと、
    前記プロセッサが、前記出力イベントの前記出力シーケンス番号を前記システムのメモリに記憶することと、
    前記プロセッサが、前記イベントの連続入力ストリームが処理されている間に、前記システムの障害の表示を受信することと、
    前記プロセッサが、前記イベントの出力ストリームにおいて最も最近送信された出力イベントの現在の出力シーケンス番号を判断することと、
    前記プロセッサが、最も最近処理された入力イベントのバッチに対応する出力イベントの最後の出力シーケンス番号を判断することと、
    前記プロセッサが、前記現在の出力シーケンス番号および前記最後の出力シーケンス番号に基づいて送信されるべき前記出力ストリームの１つ以上の出力イベントのセットを判断することと、
    前記プロセッサが、アプリケーションに関連する前記１つ以上の出力イベントのセットを送信することとを備える、方法。
12. 前記プロセッサが、送信されるべき前記１つ以上の出力イベントのセットにおいて１つ以上の出力イベントを含まないことをさらに備える、請求項１１に記載の方法。
13. 前記システムの障害の表示を受信することに基づいて、前記プロセッサが、前記イベントの出力ストリーム内の前記最も最近送信された出力イベントの前記現在の出力シーケンス番号から出力イベントを送信することをさらに備える、請求項１１または１２に記載の方法。
14. 前記プロセッサが、前記イベントの連続入力ストリームから１つ以上のイベントバッチのセットを生成することをさらに備え、前記１つ以上のイベントバッチのセットを生成することは、
    チェックポイントマーカイベントを生成することと、
    前記チェックポイントマーカイベントを前記イベントの連続入力ストリームに挿入することと、
    前記チェックポイントマーカイベントに基づいて前記１つ以上のイベントバッチのセットを生成することとを含む、請求項１１から１３のいずれか１項に記載の方法。
15. 前記チェックポイントマーカイベントは、前記イベントの連続入力ストリームにおける入力イベントに関連する情報を表し、イベントバッチのサイズは、前記チェックポイントマーカイベントに基づいて判断される、請求項１４に記載の方法。
16. 前記プロセッサが、前記チェックポイントマーカイベントを処理することと、
    前記プロセッサが、前記チェックポイントマーカイベントの処理に基づいて、前記１つ以上のイベントバッチのセット内の第１のイベントバッチの処理の完了を示す確認メッセージを送信することと、
    前記プロセッサが、前記システムの現在の状態のスナップショットを生成することとをさらに備える、請求項１４または１５に記載の方法。
17. 請求項１１〜１６のいずれかに記載の方法をコンピュータに実行させるためのプログラム。

Images