JP7018435B2 - スナップショットおよび状態のマイクロバッチ方式による管理 - Google Patents

Description

関連出願への相互参照
本出願は、「スナップショットおよび状態のマイクロバッチ方式による管理（MANAGING SNAPSHOTS AND STATE WITH MICRO-BATCHING）」と題される、２０１６年９月１５日に出願されたインド仮出願番号第２０１６４１０３１４７９号の優先権および利益を主張し、その全内容を、すべての目的のためにここに引用により援用する。

本出願は、これとともに同日に出願された、「マイクロバッチストリーミングのための複合イベント処理（COMPLEX EVENT PROCESSING FOR MICRO-BATCH STREAMING）」と題される、代理人番号第０８８３２５－１０５２９５６号である、出願連続番号第 号に関連し、その全内容を、ここに完全に記載されるがごとくここに引用により援用する。

背景
従来のデータベースシステムにおいて、データは、通常はテーブルの形態である１つ以上のデータベースに記憶される。そして、記憶されるデータは、構造化照会言語（ＳＱＬ）などのデータ管理言語を使用して照会および操作される。たとえば、ＳＱＬクエリは、データベースに記憶されるデータから関連するデータを識別するために定義および実行され得る。したがって、ＳＱＬクエリは、データベースに記憶されるデータの有限集合に対して実行される。さらに、ＳＱＬクエリが実行される時、それはひとたび有限データ集合に対して実行され、有限の静的結果（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" ＤＤＬを発行してＣＱＬクエリを開始すると、論理クエリプランは物理クエリプランに変換されてもよい。一例では、物理クエリプランは、物理演算子の有向非循環グラフ（ＤＡＧ）として表されてもよい。次に、物理演算子を実行演算子に変換して、そのＣＱＬクエリの最終クエリプランに到達してもよい。ＣＱＬエンジンへの入来イベントは、ソース演算子に到達し、最終的に、演算子のイベントでの処理を実行し、適切な出力イベントを生成する方法で、演算子とともに下流に移動する。

イベント処理アプリケーション
ローインフラストラクチャおよびビジネスイベントの両方の量ならびに速度は、ＩＴ環境で急激に増加している。それは、金融サービスのために株式データをストリーミングするのであれ、軍事用に衛星データをストリーミングするのであれ、運輸および物流ビジネスのためにリアルタイムの車両位置データをストリーミングするのであれ、複数の業界の企業が大量の複雑なデータをリアルタイムで処理しなければならない。さらに、モバイル機器の急増および高速接続の普及は、モバイルデータの急増を助長する。同時に、ビジネスプロセスの俊敏性および実行に対する需要も高まっている。これら２つの傾向は、組織に対して、組織の、実装のイベント駆動型アーキテクチャパターンをサポートする能力を高めるよう、圧力をかけている。リアルタイムのイベント処理では、インフラストラクチャおよびアプリケーション開発環境の両方がイベント処理要件を実行する必要がある。これらの要件には、おそらくは秒単位ではなくマイクロ秒単位の応答時間で測定されるレイテンシで日常のユースケースから非常に高速のデータおよびイベントのスループットへ基準化するニーズが含まれることがよくある。さらに、イベント処理アプリケーションは、これらのイベントの流れの中で複雑なパターンを検出しなければならないことがよくある。

Oracle Stream Analyticsプラットフォームは、多くの業界と機能分野をターゲットとしている。以下は、いくつかのユースケースである。

電気通信：リアルタイム呼詳細（ＣＤＲ）レコードモニタリングおよび分散型サービス妨害攻撃検出を実行する能力。

金融サービス：ミリ秒またはマイクロ秒のウィンドウ内に存在する裁定機会を利用する能力。金融証券取引のリアルタイムのリスク分析、モニタリングおよび報告を実行し、外国為替価格を計算する能力。

運輸：地方または目的地の都市の天候、地上業務員のオペレーション、空港のセキュリティなどによる飛行の不具合が発生した場合に、旅客警報を発令して手荷物の場所を検出する能力。

公共部門/軍：分散した地理上の敵の情報を検出し、それを抽象化し、高確率の敵の攻撃を解読する能力。緊急事態に対応するために最も適切なリソースに警告する能力。

保険：潜在的に不正な請求を学習し、検出する能力。
ＩＴシステム：故障したアプリケーションやサーバをリアルタイムで検出し、是正措置をトリガする能力。

サプライチェーンおよび物流：リアルタイムで出荷を追跡し、潜在的な到着の遅れを検出して報告する能力。

リアルタイムストリーミングおよびイベント処理分析
接続デバイス数の増加によるデータの爆発的増加に伴い、大量の動的に変化するデータが増加しており、データは組織内だけでなく、ファイアウォールの外側にも移動する。高速データは、特に変わり易いビジネスプロセスに高い価値をもたらす。しかしながら、このデータの一部は短い時間枠でその運用上の価値を失う。ビッグデータは、有効な洞察のための処理において時間的な余裕がある。一方、ファストデータでは、非常に動的で戦略的なデータから最大値を抽出する必要がある。それははるかに速く処理することを必要とし、生成されたデータのできるだけ近くでタイムリーなアクションをとることを容易にする。Oracle Stream Analyticsプラットフォームは、即応性のあるファストデータを実現する。Oracle Edge Analyticsは、リアルタイムで実践的な洞察を得るために、ネットワークエッジに対するデータの処理、相関付け、フィルタリング、および分析をプッシュする。

Oracle Stream Analyticsプラットフォームは、着信ストリーミングイベントを永続データと結合する機能を提供し、それによってコンテキストを意識したフィルタリング、相関付け、集約およびパターンマッチングを実現する。それは、一般的なイベントソースのために、軽量で、そのまま使用できるアダプタを提供する。それは、カスタムアダプタ開発用の使いやすいアダプタフレームワークも提供する。このプラットフォームで、組織は、機会と、一見無関係のイベントによって表される脅威とを識別し、予測することができる。その増分処理パラダイムは、最小量のリソースを使用してイベントを処理することができ、極端に低いレイテンシの処理を可能にする。それはまた、それが、非常にタイムリーな警報を発令し、次のような紛失イベントや遅延イベントを即座に検出することを可能にする。

相関付けられたイベント：イベントＡが発生した場合、イベントＢはほぼ常にそれの後２秒以内に発生する。

紛失イベントまたはシーケンス外イベント：イベントＡ、Ｂ、Ｃは順番に発生するべきである。ＣはＡの直後に、Ｂなしで見られる。

原因となるイベント：製造品目の重量がゆっくりと低下する傾向にあるか、または読み取り値が許容基準外である。これは潜在的な問題または将来のメンテナンスの必要性を示している。

リアルタイムのイベントソーシングに加えて、Oracle Stream Analyticsプラットフォーム設計環境およびランタイム実行は、イベントストリームとデータベースや高性能データグリッドなどの永続データストアとの両方にわたる標準ベースの連続クエリ実行をサポートする。これにより、プラットフォームは、他の態様では気付かれないであろうパターンおよび傾向を識別するためにマイクロ秒単位または分単位で回答を必要とするシステムに対するインテリジェンスの中心として機能することができる。イベント処理のユースケースでは、標準データベースＳＱＬの数学的精度および信頼性を備えたインメモリ処理の速度が必要である。このプラットフォームクエリは、着信イベントストリームをリスニングし、クエリ最適化のための高度な自動化されたアルゴリズムを利用して、登録されたクエリを各イベントについてインメモリで継続的に実行する。インメモリ実行モデルに基づいているが、このプラットフォームはクエリ開発に標準のＡＮＳＩ ＳＱＬ構文を利用しているため、クエリ構築の正確性および拡張性が保証される。このプラットフォームは、ＡＮＳＩ ＳＱＬ’９９規格に完全に準拠しており、リアルタイムの連続クエリパターンマッチングのために標準ＳＱＬに対するＡＮＳＩ ＳＱＬレビュー拡張をサポートするべく業界で利用可能な最初の製品の１つである。ＣＱＬエンジンはプロセッサ内のクエリの実行を最適化し、開発者は最適化よりもビジネスロジックに集中するようになる。

Oracle Stream Analyticsプラットフォームでは、ＳＱＬおよびＪａｖａコードの両方を組み合わせて、堅牢なイベント処理アプリケーションを提供できる。標準の業界用語を利用してイベントソース、プロセッサ、およびイベント出力またはシンクを記述して、このプラットフォームは、アプリケーション内でイベントを定義および操作するためにメタデータ駆動型のアプローチを提供する。その開発者は、アプリケーションの設計に視覚的な有向グラフのキャンバスおよびパレットを用いて、イベントの流れおよびイベントとデータソースとの両方にわたる処理を迅速に概説する。ドラッグアンドドロップモデリングおよび設定ウィザードを介してフローを開発して、開発者は、次いで、適切なメタデータ定義を入力して設計を実装に結び付けることができる。必要または好まれる場合には、次いで、ワンクリックで、開発者は、カスタムＪａｖａコード開発に立ち寄ること、またはSpring（登録商標）フレームワークを直接使用して高度な概念を彼らのアプリケーションにコーディングすることができる。

イベント駆動型アプリケーションは、非常に高速のストリーミング入力データを処理しながら、低くかつ決定論的なレイテンシを与えることに対するニーズによって特徴付けられることがよくある。Oracle Stream Analyticsプラットフォームの基盤は、ＯＳＧｉ（登録商標）バックプレーンに基づく軽量のＪａｖａコンテナである。それは、セキュリティ、ロギング、および作業管理アルゴリズムなど、WebLogic JEEアプリケーションサーバからの成熟したコンポーネントが含むが、リアルタイムのイベント処理環境でそれらのサービスを利用する。統合されたリアルタイムカーネルは、独自のサービスを提供して、ＪＭＸフレームワークによってサポートされるスレッドおよびメモリ管理を最適化し、パフォーマンスおよび構成のためにコンテナとの対話を可能にする。Ｗｅｂ２．０リッチインターネットアプリケーションはＨＴＴＰパブリッシュおよびサブスクライブサービスを用いてプラットフォームと通信でき、これにより、それらは、アプリケーションチャネルにサブスクライブし、イベントをクライアントにプッシュされることができる。フットプリントが小さいため、このプラットフォームは軽量のＪａｖａベースのコンテナであり、製品化までの時間がより速くなり、総オーナーシップコストが削減される。

Oracle Stream Analyticsプラットフォームには、標準の商品ハードウェア上でマイクロ秒の処理レイテンシで、またはOracle Exalogicおよびその他の工学システムのそのポートフォリオで最適に、毎秒数百万のイベントを処理する機能がある。これは、高性能イベント処理のユースケースに設計重点を置いただけでなく、エンタープライズクラスのリアルタイム処理インフラストラクチャコンポーネントとの緊密な統合で、完全な「トップダウン」の階層化されたソリューションを通して達成される。パフォーマンス指向のサーバクラスタのプラットフォームアーキテクチャは、Oracle Coherence技術への緊密な統合で、信頼性、故障許容、および非常に高い柔軟性に重点を置き、企業はデータグリッド全体に渡ってミッションクリティカルなアプリケーションを予測可能に基準化でき、継続的なデータの可用性およびトランザクションの保全性を確保できる。

さらに、このプラットフォームでは決定論的処理が可能であり、つまり、同じイベントを異なるレートで複数のサーバまたは同じサーバに供給して、毎回同じ結果を得ることができる。これにより、稼働中のサーバのシステムクロックにのみ依存するシステムに対して驚くべき利点が得られる。

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

マイクロバッチベースのストリーム処理システムにおけるイベントごとのイベント処理のためのフレームワーク
近年、データストリーム管理システム（ＤＳＭ）が開発されてきており、これは潜在的に無限のリアルタイムデータストリーム上で連続的にクエリを実行することができる。新たなＤＳＭの中で、これらのシステムは一般に、単一のフレームワークからバッチ処理とストリーム処理との組み合わせを提供するためにマイクロバッチ方式ベースのストリーム処理を採用する。そのようなシステムの例は、Spark（登録商標）プラットフォーム上で動作するSpark Streamingアプリケーションである。マイクロバッチ方式ストリーム処理は、ステートフル処理が複雑になる可能性があるシステムの設計の性質上、いくつかの欠点がある。そのような欠点の１つは、「パターンマッチング」操作を実行できないことである。パターンマッチングは、ストリーム処理システムがサポートすることが望ましい重要な機能であり、パターンマッチングでは、ステートマシンを実行してアンバウンド（unbound）のイベントストリームからパターンを検出するために、非常にステートフルな処理が必要である。

前述のOracle Stream Analytics Platformを使用することで、提案されたソリューションはステートフル処理をマイクロバッチ方式ストリーム処理と組み合わせる。基本的に、このソリューションは複合イベント処理(ＣＥＰ)とマイクロバッチ方式ストリーム処理とを組み合わせる。ステートフル処理は、連続クエリ言語（Continuous Query Language）（ＣＱＬ）で書かれた連続クエリ処理エンジンであるＣＱＬエンジンによって処理される。完全にステートフルなクエリ処理をサポートするために、一実施形態では、ＣＱＬクエリエンジンはマイクロバッチ方式ストリーム処理内に追加される。

一実施形態では、有向非巡回グラフ（ＤＡＧ）変換に追加することができるＣＱＬ変換アルゴリズムが開示される。特定の実施形態において、変換アルゴリズムは以下のように実施されてもよい。（ｉ）ストリーム処理アプリケーションからのドライバは、決して戻ることのない長期実行タスクとしてエグゼキュータの１つ以上にＣＱＬエンジンを起動する。（ｉｉ）ＣＱＬエンジンは動作し続け、クエリ状態を維持する。（ｉｉｉ）各マイクロバッチジョブでは、ＣＱＬ変換はマイクロバッチジョブの一部として実行される。（ｉｖ）ＣＱＬ変換が実行されると、マイクロバッチの入力イベントはＣＱＬエンジンに送信される。ＣＱＬエンジンは、マイクロバッチ内の各イベントをイベントごとに処理し、クエリに対してインクリメンタルコンピュテーション（incremental computation）を実行し、出力イベントを作成する。（ｖ）マイクロバッチ内のイベントが処理されている間に出力イベントは待ち行列内に捕捉される。（ｖｉ）マイクロバッチ内の各すべてのイベントがＣＱＬエンジンで完了した後、結果待ち行列内の出力イベントはＣＱＬ変換の結果として返される。（ｖｉｉ）ＣＱＬ変換の次の変換は、追加の変換なしで出力イベントを消費できる。

開示されたＣＱＬ変換アルゴリズム／プロセスは、一般的なストリーム処理システムにおいてＣＱＬを処理するためにＣＱＬ変換を追加する能力を提供する。加えて、ＣＱＬエンジンを使用することで、機能処理とステートフル処理とを組み合わせることができる。開示されたプロセスは、複合イベント処理を追加することによってマイクロバッチ方式ベースのストリーム処理のいくつかの欠点を解決する。また、ＣＥＰ技術のインクリメンタルコンピュテーションを用いることで、分析の一部をより効率的に実行できる。

図１は、本開示の一実施形態を組み込んでもよいイベント処理ネットワーク（ＥＰＮ）を表現する図である。図１に示すように、ＥＰＮ１００は、各々がイベントストリーム内のイベントの処理において異なる役割を果たすいくつかのステージから構成されてもよい。イベントは定義上時間ベースであるため、ストリームはその意味においてイベントの自然な状態である。それは、イベントデータがOracle Event Processingアプリケーションにどのように到着するかである。Oracle Event Processingでイベントを処理するために、ＥＰＮ１００などのＥＰＮをコアとするアプリケーションが構築される。ＥＰＮ１００は、イベントデータの受信から、データの照会、イベントに関して発見されたことに基づいたロジックの実行まで、各々がイベントの処理において異なる役割を果たすステージで構成されている。アプリケーションは生のイベントデータを受信し、そのデータをイベントタイプにバインドしてから、処理のためにステージ間でイベントをルーティングする。ＥＰＮにおける接続されたステージは、ＥＰＮを通過するイベントに対してさまざまな種類のコードを実行する方法を提供する。ステージの種類は、アダプタ、プロセッサ、およびビーンを含むことができる。より具体的には、様々な実施形態において、ＥＰＮ１００は、イベントを受信するイベントソース１０５と、ステージを接続するチャネル１１０と、連続クエリ言語（ＣＱＬ）のクエリコードを含むＣＱＬプロセッサなどのプロセッサ１１５と、一般的な処理ロジックを実行するビーン１２０、コード１２５、および／またはシンク１３０とを含む。本明細書に記載されているように、イベントのストリームは、次々と、時間による連続した順序にある。

いくつかの実施形態では、イベントソース１０５は、アダプタ（たとえば、ＪＭＳ、ＨＴＴＰおよびファイル）、チャネル、プロセッサ、テーブル、キャッシュなどが挙げられるが、それらに限定されるものではない。たとえば、イベントソース１０５は１つ以上のアダプタを含んでもよい。１つ以上のアダプタは入力および出力ストリームならびにリレーションソースおよびシンクに直接インターフェイスしてもよい。１つ以上のアダプタは、入力および出力ストリームプロトコルを理解するように構成されてもよく、イベントデータを、アプリケーションプロセッサによって照会可能な正規化された形態に変換する役割を担う。例えば、アダプタは、イベントデータを受信し、それをイベントタイプインスタンスにバインドし、次いでそのイベントをプロセッサ１１５に渡すことができる。１つ以上のイベントアダプタは、さまざまなデータソースおよびシンクについて定義され得る。チャネル１１０はイベント処理終点の役割を果たす。とりわけ、チャネル１１０は、イベント処理エージェントがイベントデータに対して作用することができるまでイベントデータを待ち行列に入れる役割を担う。プロセッサ１１５は、イベントデータに対するクエリの実行など、イベントデータに対するアクションを実行するように構成されたイベント処理エージェントであり得る。特定の実施形態では、プロセッサ１１５は、入力チャネル（例えば、チャネル１１０）によって提供されるイベントに作用する１つ以上のＣＱＬクエリと関連付けることができるＣＱＬプロセッサを備える。例えば、プロセッサのＣＱＬコードは、（ＳＱＬコードがデータベース行に照会するように）イベントに照会することができ、データがＥＰＮ１００を流れるときにデータ内の特定のパターンを探す。ＣＱＬプロセッサは、クエリ結果が書き込まれる出力チャネル（例えば、チャネル１１０）に接続されてもよい。例えば、パターン基準を満たすイベントは、（例えば、Ｊａｖａで書かれた）ビーン１２０またはコード１２５に渡すことができ、そこでデータは、外部ソースから検索されたデータと共に計算に使用することができる。さらに下流のビーン１２０またはコード１２５は、計算結果を用い、外部コンポーネントを用いてプロセスを実行することができる。ビーン１２０またはコード１２５は、出力チャネルをリスニングするように登録され得、出力チャネルへの新たなイベントの挿入によってトリガされる。いくつかの実施形態では、ビーン１２０の処理ロジックは、Ｊａｖａ（登録商標）またはplain-old-Java-object（ＰＯＪＯ）などのプログラミング言語で書くことができる。いくつかの実施形態では、処理ロジックは、ビーンがオラクルＣＥＰによって管理できるようにオラクルＣＥＰイベントビーンＡＰＩを用い得る。ＥＰＮ１００内でイベントを受信または送信するように設計された任意のコンポーネント（ＥＰＮステージなど）は、そうするために特に実装されるビーンであってもよい。イベントを受信することができるコンポーネントはイベントシンク１３０として知られ、イベントを送信するコンポーネントはイベントソース１０５として知られている。１つのコンポーネントは、イベントソースとシンクとの両方になることができる。ＣＱＬプロセッサの基盤となるアダプタやコンポーネントなど、Oracle Event Processingに含まれる記載のステージコンポーネントは、必要な機能をすでにサポートしている。開発者は、ＯＥＰ ＡＰＩからインターフェイスを実装することで、イベントシンクおよびソースサポートを、彼らが書くビーン、新たなアダプタ、およびその他のコードに追加できる。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図３は、マイクロバッチ方式ストリーム処理を用いたステートフル処理のために構成されたストリーム処理アプリケーション３００を実装することができる例示的なシステムまたはアーキテクチャである。様々な実施形態において、ストリーム処理アプリケーション３００は１つ以上のデータストリーム３０５を含む。データストリーム３０５は、しばしばもっぱら新たな要素の挿入を通して、絶えず変化しているデータを表す。多くのタイプのアプリケーションは、センサデータアプリケーション、財務ティッカー、ネットワーク性能測定ツール、ネットワークモニタリングおよびトラフィック管理アプリケーション、ならびにクリックストリーム分析ツールを含む、データセットとは対照的なデータストリーム３０５を生成する。いくつかの実施形態では、Spark Streamingは、Spark用の増分的マイクロバッチ方式ストリーム処理フレームワーク３１０であり、Spark Streamingは、連続データストリームを扱う複雑さを隠し、プログラマのためにそれを一度に１つのＲＤＤを使用することと同じくらい容易にする離散化されたストリーム（Dstream）３１５と呼ばれるデータ抽象化を提供する。Dstreamは基本的に、バッチのために入力ストリームから受け取ったデータを要素とするレジリエント分散データセット（ＲＤＤ）のストリームである（おそらくはウィンドウ化されるかまたはステートフルな演算子によって範囲が拡張される）。ＲＤＤはSparkの基本的なデータ構造である。それはオブジェクトの不変の分散コレクションである。ＲＤＤにおける各データセットは論理パーティションに分割され、それらはクラスタの異なるノードで計算されてもよい。ＲＤＤには、ユーザー定義クラスを含む、Python、Java、またはScalaオブジェクトのうちの任意のタイプを含むことができる。ストリーム処理フレームワーク３１０によって実行されるマイクロバッチ化では、バッチは本質的に一度に１つのＲＤＤである。したがって、データストリーム３０５を一度に１レコードずつ処理する代わりに、Spark Streamingのレシーバは、データを並列で受け取り、それをSparkのワーカーノードのメモリにバッファする。その後、レイテンシ最適化されたSparkエンジンは短いタスク（数十ミリ秒）を実行してバッチを処理して結果を他のシステムに出力する。

ストリーム処理アプリケーション３００は、ＣＱＬエンジン３２０をさらに含む。離散化されたストリーム３１５内などのアンバウンドのイベントストリームからパターンを検出するために必要なステートフル処理は、ＣＱＬで書かれた連続クエリ処理エンジンであるＣＱＬエンジン３２０によって処理される。完全にステートフルなクエリ処理をサポートするために、一実施形態では、ＣＱＬエンジン３２０は、離散化されたストリーム３１５内のイベントまたはデータに対するマイクロバッチ方式ストリーム処理に加えられる。ＣＱＬエンジン３２０は、ＤＡＧ変換に追加され得るＣＱＬ変換アルゴリズムを用いて、ＣＱＬプロセッサなどのプロセッサ内でステートフルクエリ処理の実行を最適化する。変換アルゴリズムは、離散化されたストリーム３１５を入力として受け取り、ＣＱＬプロセッサと組んで結果３２５を生成するのを助ける。理解されるように、結果を得るためにＲＤＤ上で実行されることができる２つのタイプの操作がある：（ｉ）マップ、フィルタのような、別のＲＤＤ３２５をもたらす変換、および（ｉｉ）カウントのような、出力をもたらすアクション。スパークジョブは通常、ＲＤＤ上で変換およびアクションを実行するタスクのＤＡＧから構成される。ＣＱＬプロセッサコードは、データがＥＰＮ（例えば、図１に関して説明したようにＥＰＮ１００）を通って流れるときにデータ内の特定のパターンを探して、離散化されたストリーム３１５内のイベントに照会することができる。パターン基準を満たすイベントは、結果３２５としてビーン、コード、またはシンクに渡すことができ、そこで最終的に結果３２５は用いられ、外部ソースから検索されたデータを用いた計算において入力３３０として渡すことができる。

図４、図７および図８は、いくつかの実施形態による完全にステートフルなクエリ処理をサポートするためにマイクロバッチ方式ストリームを処理するための技法を示す図である。個々の実施形態は、フローチャート、フロー図、データフロー図、構造図またはブロック図として示されるプロセスとして説明されてもよい。フローチャートは動作をシーケンシャルなプロセスとして説明することができるが、動作の多くは並列または同時に実行されてもよい。さらに、動作の順序は並べ替えられてもよい。プロセスは、その動作が完了すると終了するが、図に含まれていないさらなるステップを有し得る。プロセスは、メソッド、関数、プロシージャ、サブルーチン、サブプログラムなどに対応し得る。プロセスが関数に対応している場合、その終了は、その関数を呼出し関数またはｍａｉｎ関数へと戻すことに対応し得る。

図４、図７、および図８において示されるプロセスおよび／または動作は、１つ以上の処理ユニット（たとえば、プロセッサコア）によって実行されるソフトウェア（たとえば、コード、命令、プログラム）、ハードウェア、またはそれらの組み合わせで実装され得る。ソフトウェアは、メモリ（例えば、メモリデバイス上、非一時的コンピュータ可読記憶媒体上）に格納することができる。図４、図７、および図８における特定の一連の処理ステップは、限定的であることを意図しない。代替の実施形態に従って、他の一連のステップも実行することができる。例えば、代替的実施形態では、上で概説したステップは異なる順序で実行されてもよい。さらに、図４、図７、および図８に示される個々のステップは、個々のステップに適切であるように様々なシーケンスで実行され得る複数のサブステップを含み得る。さらに、特定の用途に応じて追加のステップを追加または削除することができる。当業者は、多くの変形形態、修正形態、および代替形態を認識するであろう。

図４は、本開示の実施形態によって実施される完全にステートフルなクエリ処理をサポートするためにマイクロバッチ方式ストリームの処理を示すフローチャート４００を示す。いくつかの実施形態では、フローチャート４００に示されているプロセスは、図１、図２および図３のイベント処理システムによって実施することができる。ステップ４０５で、連続クエリ言語で書かれた連続クエリ処理エンジンが起動される。いくつかの実施形態では、ストリーム処理アプリケーションからのドライバが、決して戻ることのない長期実行タスクとして１つ以上のエグゼキュータにＣＱＬエンジンを起動する。ＣＱＬエンジンは動作し続け、マイクロバッチストリームに対するクエリ状態を維持する。ステップ４１０で、連続クエリが受信される。いくつかの実施形態では、クエリはパターン認識を含む。たとえば、ＣＱＬのMATCH_RECOGNIZE句およびその副次句を呼び出して、ＣＱＬクエリでパターン認識を実行できる。ステップ４１５で、連続クエリに対してクエリプランを生成するために、連続クエリに操作が適用される。クエリプラン（またはクエリ実行プラン）は、クエリまたは連続クエリの処理のために、たとえばＳＱＬリレーショナルデータベース管理システムにおいてデータにアクセスするために使用される順序付けられたステップのセットである。いくつかの実施形態では、操作はＤＡＧ変換であり、クエリプランはＤＡＧクエリプランである。ＤＡＧ変換は頂点と辺との集合であり、頂点はＲＤＤを表し、辺はＲＤＤに適用されるべき操作を表す。ステップ４２０において、クエリプランは、変換されたクエリプランを生成するために変換アルゴリズムを用いて変換される。様々な実施形態において、変換アルゴリズムはＣＱＬ変換である。たとえば、クエリプランを生成するためにマイクロバッチまたはＲＤＤが操作される各インスタンスで、ＣＱＬ変換が実行される。いくつかの実施形態では、変換されたクエリプランを生成するために、ＣＱＬ変換がＤＡＧ変換に追加される。ステップ４２５で、アプリケーションに関連する入力イベントのマイクロバッチストリームが受信される。いくつかの実施形態では、Spark Streamingは、連続するデータストリームを１秒未満の小さいマイクロバッチつまりマイクロバッチストリームに離散させることができる。ステップ４３０で、入力イベントは、少なくとも部分的に、変換されたクエリプランに基づいて、処理され、アプリケーションに関連する出力イベントのセットが生成される。いくつかの実施形態では、処理は連続クエリ処理エンジンを用いて実行され、処理は出力イベントを生成するために入力イベントの各々を増分的に処理することを含む。たとえば、ＣＱＬ変換などの変換アルゴリズムが実行されると、マイクロバッチの入力イベントはＣＱＬエンジンに送信される。ＣＱＬエンジンは、マイクロバッチの各入力イベントをイベントごとに処理し、変換されたクエリプランに少なくとも部分的に基づいて、クエリについてマイクロバッチの各入力イベント上でインクリメンタルコンピュテーションを実行し、マイクロバッチにおける各入力イベントに対する出力イベントを作成する。したがって、ステートフル処理はＣＱＬエンジンによって実行される。ステップ４３５で、アプリケーションに関連する出力イベントのセットが出力待ち行列に格納される。いくつかの実施形態では、マイクロバッチ内の残りのイベントがＣＱＬエンジンによって処理されている間に、出力イベントが出力待ち行列に捕捉される。ステップ４４０で、マイクロバッチ内の各イベントが処理された後、出力待ち行列内の出力イベントが連続クエリの結果として返されおよび／または送信される。

マイクロバッチベースのイベント処理におけるスナップショットおよびアプリケーション状態の管理
近年、データストリーム管理システム（ＤＳＭ）が開発されてきており、これは潜在的に無限のリアルタイムデータストリーム上で連続的にクエリを実行することができる。新たなＤＳＭの中で、これらのシステムは一般に、単一のフレームワークからバッチ処理とストリーム処理との組み合わせを提供するためにマイクロバッチ方式ベースのストリーム処理を採用する。そのようなシステムの例は、Spark（登録商標）プラットフォーム上で動作するSpark Streamingアプリケーションである。マイクロバッチ方式ストリーム処理は、ステートフル処理が複雑になる可能性があるシステムの設計の性質上、いくつかの欠点がある。そのような欠点の１つは、「パターンマッチング」操作を実行できないことである。パターンマッチングは、ストリーム処理システムがサポートすることが望ましい重要な機能であり、パターンマッチングでは、ステートマシンを実行してアンバウンドのイベントストリームからパターンを検出するために、非常にステートフルな処理が必要である。

完全にステートフルなクエリ処理をサポートするために、一実施形態では、ここに記載されるように、ＣＱＬクエリエンジンはマイクロバッチ方式ストリーム処理内に追加される。本質的に、このソリューションは複合イベント処理（ＣＥＰ）とマイクロバッチ方式ストリーム処理とを組み合わせる。ステートフル処理は、連続クエリ言語（ＣＱＬ）で書かれた連続クエリ処理エンジンであるＣＱＬエンジンによって処理される。

特定の状況では、クラスタ内に複数のＣＱＬエンジンが存在する可能性があり、各エンジンは個別にチェックポイントを設定するために状態スナップショットを作成する必要がある。そのため、マイクロバッチ処理が完了した後にスナップショットの生成を調整し、スナップショットの保持など、スナップショットを管理する必要がある。

図５は、本開示の実施形態による、スナップショット生成を調整し、スナップショットを管理するために、ＣＱＬエンジントラッカー６０５を実装することができる例示的なシステムまたはアーキテクチャ５００である。様々な実施形態において、システムまたはアーキテクチャ５００はリスナー５１０と通信するＣＱＬエンジントラッカー５０５を含む。ＣＱＬエンジントラッカー５０５およびリスナー５１０は、ドライバ５１５内に配置することができる。ＣＱＬエンジントラッカー５０５は、ＣＱＬエンジン５２０から作成されたスナップショットを管理するように構成され、ＣＱＬエンジン５２０は、クラスタ内の１つ以上のエグゼキュータ５２５上にあり得る。特定の実施形態では、ＣＱＬエンジントラッカー５０５は、スナップショットを管理するために２つのディレクトリ構造、つまりSnapshot Map（スナップショットマップ）およびMap（マップ）を使用することができる。Snapshot Mapディレクトリ構造を用いて、特定のqueryid（クエリｉｄ）、パーティションおよび時間ならびにマップからスナップショット情報に直接アクセスできる。Snapshot Mapを用いて、回復またはクリーンアップすべきスナップショットを見つけることができる。Snapshot Mapディレクトリ構造の例示的なデータ構造を図６Ａに示す。Mapディレクトリ構造：(queryId, partitionId, time) -> mark。Map :(queryId, partitionId) -> 逆順序でList of Snapshot(time,mark,fullFlag)。Mapディレクトリ構造の例示的なデータ構造を図６Ｂに示す。ＣＱＬエンジン５２０からのスナップショットおよびＣＱＬエンジントラッカー５０５からのメタデータは、スナップショットストレージ５３０に書き込まれてもよい。

一実施形態では、ＣＱＬエンジントラッカーはＣＱＬエンジンと連携してスナップショット管理アルゴリズムを実装することができる。いくつかの実施形態では、スナップショット管理アルゴリズムは、スナップショットを追加するプロセス、スナップショットを取得するプロセス、およびスナップショットをクリーンにするプロセスを含み得る。いくつかの実施形態では、AddSnapshot Processは以下の操作を含む。（ｉ）スナップショットを管理するために、一次構造は逆順序でlist of Snapshot(time, mark, full_flag)に対するPartitionKey(queryId, partitionId)のマップを用いる。（ｉｉ）ＣＱＬエンジンは、計算が終了した後にＣＱＬエンジントラッカーに対するaddSnapshot RPCを呼び出し、queryId、partitionId、時間およびナップショットマーク情報、ならびにfull_flagでスナップショットを作成する。（ｉｉｉ）AddSnapshotが呼び出される。（ｉｖ）PartitionKeyオブジェクトがqueryIdおよびpartitionIdで作成される。（ｖ）マップ内にpartitionKeyに対するリストがない場合は、新しいリストが作成され、それ以外の場合は、既存のリストを使用する。（ｖｉ）Snapshotオブジェクトが時間、マーク、およびfull_flagで作成される。

いくつかの実施形態では、GetSnapshots Processは、以下の操作を含む。（ｉ）状態を復元するためにスナップショットのリストを取得するために計算を開始する前に、ＣＱＬ ＲＤＤ（Resilient Distributed Dataset（レジリエント分散データセット））がＣＱＬエンジントラッカーに対してgetSnapshot RPC (Remote Procedure Call（リモートプロシージャコール）)をqueryId, partitionIdおよび時間で呼び出す。（ｉｉ）GetSnapshots PartitionKeyがqueryIdおよびpartitionIdで作成される。（ｉｉｉｉ）スナップショットが、partitionKeyを用いてスナップショットマップから検索される。（ｉｖ）保存されたスナップショットマップがない場合は、empty[Snapshot]を返す。（ｖ） 逆順リストの各スナップショットに対して、Stack[Snapshot]が作成される。（ｖｉ）スナップショット時間が(time - batchDuration) （時間 - バッチ継続期間）より小さい場合は、それをスタックに追加し、スタックをリストに変換して返す。

いくつかの実施形態では、CleanSnapshots Processは、以下の操作を含む。（ｉ）バッチが完了すると、スナップショットを削除しても安全であり得る。（ｉｉ）バッチが完了すると、onEndBatch（バッチの終わり）がジョブスケジューラから呼び出され、それは、バッチ時間でEndOfBatch RPC呼び出しを呼び出す。（ｉｉｉ）アルゴリズムは、フルスナップショットを除き、所与のバッチ時間前にすべてのスナップショットを削除する。（ｉｖ）スナップショットマップの各エントリおよびスナップショットリストの各スナップショットに対するCleanSnapshots。（ｖ）（スナップショット時間がバッチ時間より短い場合）それをマップから削除し、スナップショットストレージからも削除する。

図７は、本開示の実施形態によって実施される完全にステートフルなクエリ処理をサポートするためにマイクロバッチ方式ストリームの処理を示すフローチャート７００を示す。いくつかの実施形態では、フローチャート７００に示されているプロセスは、図１、図２、図３および図５のイベント処理システムによって実施することができる。ステップ７０５で、アプリケーションに関連する入力イベントのマイクロバッチストリームが受信される。いくつかの実施形態では、Spark Streamingは、連続するデータストリームを１秒未満の小さいマイクロバッチつまりマイクロバッチストリームに離散させることができる。ステップ７１０において、入力イベントは、アプリケーションに関連した出力イベントのセットを生成するために連続クエリ処理エンジンを使用して処理される。いくつかの実施形態では、処理は、入力イベントの各々を増分的に処理して出力イベントを生成することを含む。たとえば、ＣＱＬ変換などの変換アルゴリズムが実行されると、マイクロバッチの入力イベントはＣＱＬエンジンに送信される。ＣＱＬエンジンは、マイクロバッチの各入力イベントをイベントごとに処理し、変換されたクエリプランに少なくとも部分的に基づいて、クエリについてマイクロバッチの各入力イベント上でインクリメンタルコンピュテーションを実行し、マイクロバッチにおける各入力イベントに対する出力イベントを作成する。したがって、ステートフル処理はＣＱＬエンジンによって実行される。ステップ７１５で、システムに関連するイベントの出力セットに少なくとも部分的に基づいてシステムの現在の状態のスナップショットが生成される。いくつかの実施形態では、スナップショットは、ＣＱＬエンジンによって実現されるスナップショット管理アルゴリズムを用いて生成される。特定の実施形態では、スナップショット管理アルゴリズムは、スナップショットを追加するプロセス、スナップショットを取得するプロセス、およびスナップショットをクリーンにするプロセスを含み得る。ステップ７２０で、システムの現在の状態のスナップショットに関連付けられるスナップショット情報にアクセスするために第１のディレクトリ構造が生成される。いくつかの実施形態では、第１のディレクトリ構造はSnapshot Mapディレクトリ構造である。ステップ７２５で、システムの現在の状態に関連付けられるスナップショットのリストを生成するために第２のディレクトリ構造が生成される。いくつかの実施形態では、第２のディレクトリ構造はMapディレクトリ構造である。ステップ７３０で、システムの現在の状態に関するスナップショットのリストを生成、追加、またはクリーンにするためにスナップショット管理アルゴリズムに少なくとも部分的に基づいてプロセスが決定される。いくつかの実施形態では、スナップショット管理アルゴリズムがスナップショットを追加するためのプロセスを含むとき、そのプロセスはシステムの現在の状態に関するスナップショットのリストを追加するよう決定される。いくつかの実施形態では、スナップショット管理アルゴリズムがスナップショットを取得するためのプロセスを含むとき、そのプロセスはシステムの現在の状態に関するスナップショットのリストを取得するよう決定される。いくつかの実施形態では、スナップショット管理アルゴリズムがスナップショットをクリーンにするためのプロセスを含むとき、そのプロセスはシステムの現在の状態に関するスナップショットのリストをクリーンにするよう決定される。理解されるように、プロセスは、図４に関して説明されたステップをさらに含み得、例えば、連続クエリ処理エンジンを起動し、連続クエリに操作を適用して連続クエリに対するクエリプランを生成し、クエリプランを変換して、変換されたクエリプランを生成し、変換されたクエリプランに少なくとも部分的に基づいて入力イベントを処理して出力イベントのセットを生成し、アプリケーションに関連する出力イベントのセットを出力待ち行列に格納し、マイクロバッチ内の各イベントが処理された後に、出力待ち行列内の出力イベントが連続クエリの結果として返されるおよび／または送信されてもよい。

本開示の実施形態は、Spark Streamingシステムにおける実行状態を維持し、マイクロバッチ方式ストリーム処理内で完全にステートフルなＣＱＬエンジンを提供し、分散されたＣＱＬエンジンから作成されたスナップショットを管理し、増分スナップショットを処理するための保持アルゴリズムを提供する。開示された技術は、イベントごとのＣＥＰ処理をマイクロバッチ方式ベースのストリーム処理に追加した後でも高可用性を可能にする。

Spark Streamingにおけるステージの出力の非侵入的モニタリング
近年、データストリーム管理システム（ＤＳＭ）が開発されてきており、これは潜在的に無限のリアルタイムデータストリーム上で連続的にクエリを実行することができる。新たなＤＳＭの中で、これらのシステムは一般に、単一のフレームワークからバッチ処理とストリーム処理との組み合わせを提供するためにマイクロバッチ方式ベースのストリーム処理を採用する。そのようなシステムの例は、Spark（登録商標）プラットフォーム上で動作するSpark Streamingアプリケーションである。

ＤＳＭＳにおける典型的なアプリケーションは、操作または変換のＤＡＧ（有向非巡回グラフ）の形態での「トポロジ」として設計される。トポロジはデータ変換パイプラインとして機能する。ほとんどのストリーム処理システム（例えばSpark Streamingシステム）は、アプリケーションのトポロジをマシンのクラスタに迅速に展開する方法を提供し、結果を即座に見ることができる。このような展開の迅速なターンアラウンドサイクルは、アプリケーションに変更を加えるために重要である。ターンアラウンドサイクルが十分速い場合、ユーザは展開の遅延を待たずに結果を確認できる。これは「ストリーム探索」と呼ばれる。

ストリーム探索モードでは、カスタマは、通常、既存のトポロジまたはデータ変換パイプラインに新しいコンポーネントを追加することによって、ビジネスアプリケーションを増分的に開発する。このような探索モードでは、変更からの即時出力、およびパイプラインの各ステージからの中間出力も確認することが重要である。

Spark（登録商標）StreamingやApache（登録商標）Flinkなどの現在のＤＳＭＳでは、トポロジはJava, Scala, Closureなどのプログラミング言語を用いて記述されている。その結果、アプリケーション開発者が１つの変換からの中間出力をモニタリングしたい場合、開発者はプログラムを変更して出力操作を追加する必要がある。これは面倒なだけでなく侵入的でもあり、なぜならば、Spark Streamingのようないくつかのシステムでは、通常、すべての出力操作が追加のジョブになるからである。現在、アプリケーションの実行中に出力モニタリングがアプリケーションに入れられた後にそれをオンにするメカニズムはないため、状況をより複雑にしている。

一実施形態では、以下の特徴を有するモニタリング変換プロセスが開示される。（ｉ）指定された宛先に出力を送信しながらいかなる変換も追加することなく次のパイプラインに出力を生成するパススルー変換、（ｉｉ）モニタリング出力がアプリケーションに構成される。（ｉｉｉ）アプリケーションの実行中にモニタリング出力をオフにするか変更することができる。

一実施形態では、上記の機能は、次の例を用いて実装することができる。
val s1 = cc.cql(inputs, "select * from stream")
val producerConfig = KafkaMonitorConfig(outputTopic, brokerList)
val s1output = s1.monitor(KafkaMonitorOutput(producerConfig));
val s2output = cc.cql(s1output, "select * from s1")
上記の例のフローは、以下のように説明され得る。（ｉ）'s1' DStreamに対して'monitor'を呼び出すことによって、MonitorDStreamが、's1'のCQLDStreamの後でＤＡＧに追加される。MonitorDStreamは、KafkaMonitorOutputに関する情報を、構成とともに担持する。（ｉｉ）ジョブ生成ステップは、MonitorDStreamからMonitorRDDを作成する。（ｉｉｉ）ジョブが実行されると、MonitorRDD.computeが呼び出される。（ｉｖ）タプルを次のパイプラインに返す一方で、pathThroughIteratorが、構成されたモニタ出力に出力を書き込む。

モニタリング出力をオフにするかまたは構成を更新するフローは、以下のように実施することができる。（ｉ）RESTサービスがアプリケーションから実行されて、更新を取得する。（ｉｉ）アプリケーションおよびステージに対する生成されたMonitorDStreamインスタンスはアプリケーションに保存され、それは、appname（アプリケーション名）およびstagename（ステージ名）をキーとして、見つけ出されることができる。（ｉｉｉ）'/monitoroutput/<appname>/<stagename>/offに対するPUT操作または新たな構成を伴う'/monitoroutput/<appname>/<stagename>/configureに対するPOST操作などのREST要求は'MonitorOutputManager'コンポーネントにデリゲートされる。（ｉｖ）MonitorOutputManagerは、MonitorDStreamオブジェクトインスタンスの設定または構成を変更する。（ｖ）ジョブランナーによって実行される次のジョブは、変更の影響を受ける。

図８は、本開示の実施形態によって実施される完全にステートフルなクエリ処理をサポートするためにマイクロバッチ方式ストリームの処理を示すフローチャート８００を示す。いくつかの実施形態では、フローチャート８００に示されているプロセスは、図１、図２および図３のイベント処理システムによって実施することができる。ステップ８０５で、連続クエリが受信される。いくつかの実施形態では、クエリはパターン認識を含む。たとえば、ＣＱＬのMATCH_RECOGNIZE句およびその副次句を呼び出して、ＣＱＬクエリでパターン認識を実行できる。ステップ８１０で、連続クエリに対してクエリプランを生成するために、連続クエリに操作が適用される。クエリプラン（またはクエリ実行プラン）は、クエリまたは連続クエリの処理のために、たとえばＳＱＬリレーショナルデータベース管理システムにおいてデータにアクセスするために使用される順序付けられたステップのセットである。いくつかの実施形態では、操作はＤＡＧ変換であり、クエリプランはＤＡＧクエリプランである。ＤＡＧ変換は頂点と辺との集合であり、頂点はＲＤＤを表し、辺はＲＤＤに適用されるべき操作を表す。ステップ８１５で、モニタリング変換プロセスを用いて連続クエリがモニタリングされる。たとえば、モニタリング変換プロセスには、次のような特徴がある。（ｉ）指定された宛先に出力を送信しながらいかなる変換も追加することなく次のパイプラインに出力を生成するパススルー変換、（ｉｉ）モニタリング出力がアプリケーションに構成される。（ｉｉｉ）アプリケーションの実行中にモニタリング出力をオフにするか変更することができる。ステップ８２０で、アプリケーションに関連する入力イベントのマイクロバッチストリームが受信される。いくつかの実施形態では、Spark Streamingは、連続するデータストリームを１秒未満の小さいマイクロバッチつまりマイクロバッチストリームに離散させることができる。ステップ８２５で、入力イベントは、モニタリング変換プロセスに少なくとも部分的に基づいて処理されて、アプリケーションに関連する出力イベントのセットが生成される。いくつかの実施形態では、処理は連続クエリ処理エンジンを用いて実行され、処理は出力イベントを生成するために入力イベントの各々を増分的に処理することを含む。たとえば、モニタリング変換プロセスが実行されると、マイクロバッチの入力イベントはＣＱＬエンジンに送信される。ＣＱＬエンジンは、マイクロバッチの各入力イベントをイベントごとに処理し、モニタリング変換プロセスに少なくとも部分的に基づいて、クエリについてマイクロバッチの各入力イベント上でインクリメンタルコンピュテーションを実行し、マイクロバッチにおける各入力イベントに対する出力イベントを作成する。したがって、ステートフル処理はＣＱＬエンジンによって実行される。アプリケーションに関連する出力イベントのセットは、出力待ち行列に格納される。いくつかの実施形態では、マイクロバッチ内の残りのイベントがＣＱＬエンジンによって処理されている間に、出力イベントが出力待ち行列に捕捉される。理解されるように、プロセスは、図４に関して説明されたステップをさらに含み得、例えば、連続クエリ処理エンジンを起動し、マイクロバッチ内の各イベントが処理された後、出力待ち行列内の出力イベントが、連続クエリの結果として返されおよび／または送信されてもよい。

本開示の実施形態は、Spark Streamingを用いた非侵入的出力モニタリング技術、および実行中のSpark Streamingアプリケーションからの中間出力をオン／オフにする技術を提供する。さらに、開示された技術は、ストリーム探索のために中間出力モニタリングを追加し、出力を変更することを可能にする。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

図１１は、本開示の実施形態に従って、実施形態のシステムの１つ以上のコンポーネントによって提供されるサービスがクラウドサービスとして提供されてもよいシステム環境１１００の１つ以上のコンポーネントの簡略ブロック図である。示される実施形態において、システム環境１１００は、クラウドサービスを提供するクラウドインフラストラクチャシステム１１０２と対話するようユーザによって用いられてもよい１つ以上のクライアントコンピューティングデバイス１１０４，１１０６および１１０８を含む。クライアントコンピューティングデバイスは、クラウドインフラストラクチャシステム１１０２と対話して、クラウドインフラストラクチャシステム１１０２によって提供されるサービスを用いるよう、クライアントコンピューティングデバイスのユーザによって用いられてもよい、ウェブブラウザ、所有権付きクライアントアプリケーション（たとえばOracle Forms）または何らかの他のアプリケーションなどのようなクライアントアプリケーションを動作させるよう構成されてもよい。

図に示されるクラウドインフラストラクチャシステム１１０２は図示されるもの以外のコンポーネントを有してもよいことが理解されるべきである。さらに、図に示される実施形態は、本開示の実施形態を組み込んでもよいクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施形態において、クラウドインフラストラクチャシステム１１０２は、図に示されるよりも多いかもしくは少ないコンポーネントを有してもよく、２つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有してもよい。

クライアントコンピューティングデバイス１１０４，１１０６および１１０８は、９０２，９０４，９０６および９０８に対して上記されたものと同様のデバイスであってもよい。

例示的なシステム環境１１００は３つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを伴うデバイスなどのような他のデバイスがクラウドインフラストラクチャシステム１１０２と対話してもよい。

ネットワーク１１１０はクライアント１１０４，１１０６および１１０８とクラウドインフラストラクチャシステム１１０２との間におけるデータの通信および交換を容易にし得る。各ネットワークは、ネットワーク９１０に対して上記されたものを含む、さまざまな市場で入手可能なプロトコルの任意のものを用いてデータ通信をサポートすることができる、当業者が精通している任意のタイプのネットワークであってもよい。

クラウドインフラストラクチャシステム１１０２は、サーバ９１２に対して上記されたものを含んでもよい１つ以上のコンピュータおよび／またはサーバを備えてもよい。

特定の実施形態において、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブに基づくｅメールサービス、運営管理されるオフィススイートおよびドキュメントコラボレーションサービス、データベース処理、管理される技術サポートサービスなどのような、オンデマンドでクラウドインフラストラクチャシステムのユーザに利用可能にされるサービスのホストを含んでもよい。クラウドインフラストラクチャシステムによって提供されるサービスは動的にスケーリングしてそのユーザのニーズを満たすことができる。クラウドインフラストラクチャシステムによって提供されるあるサービスのある具体的なインスタンス化は本明細書では「サービスインスタンス」と呼ばれる。一般的に、クラウドサービスプロバイダのシステムからインターネットなどのような通信ネットワークを介してユーザに利用可能にされる任意のサービスは「クラウドサービス」と呼ばれる。典型的には、パブリックなクラウド環境においては、クラウドサービスプロバイダのシステムを形成するサーバおよびシステムは顧客自身のオンプレミスのサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムはアプリケーションを運営管理してもよく、ユーザは、インターネットなどのような通信ネットワークを介して、オンデマンドで、アプリケーションをオーダーし使用してもよい。

いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、ストレージ、運営管理されるデータベース、運営管理されるウェブサーバ、ソフトウェアアプリケーション、またはクラウドベンダーによってユーザに提供されるかもしくは他の態様で当該技術分野において公知であるような他のサービスに対する保護されたコンピュータネットワークアクセスを含んでもよい。たとえば、サービスは、クラウド上の遠隔ストレージに対するインターネットを介してのパスワード保護されたアクセスを含むことができる。別の例として、サービスは、ネットワーク接続された開発者による個人的な使用のために、ウェブサービスに基づく運営管理されたリレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含むことができる。別の例として、サービスは、クラウドベンダーのウェブサイトにおいて運営管理されるｅメールソフトウェアアプリケーションに対するアクセスを含むことができる。

特定の実施形態において、クラウドインフラストラクチャシステム１１０２は、セルフサービスの、サブスクリプションに基づく、順応性を持ってスケーラブルで、信頼性があり、非常に利用可能性があり、およびセキュリティ上安全な態様で顧客に対して配送されるアプリケーションの組、ミドルウェア、データベースサービス提供を含んでもよい。そのようなクラウドインフラストラクチャシステムの一例は本譲受人によって提供されるＯｒａｃｌｅ Ｐｕｂｌｉｃ Ｃｌｏｕｄである。

さまざまな実施形態において、クラウドインフラストラクチャシステム１１０２は、クラウドインフラストラクチャシステム１１０２によって提供されるサービスに対する顧客のサブスクリプションを自動的にプロビジョニング、管理、およびトラッキングするように構成されてもよい。クラウドインフラストラクチャシステム１１０２はクラウドサービスを異なる開発モデルを介して提供してもよい。たとえば、サービスは、クラウドインフラストラクチャシステム１１０２が（たとえばＯｒａｃｌｅによって所有される）クラウドサービスを販売する組織によって所有され、サービスが一般大衆または異なる業界エンタープライズに対して利用可能にされるパブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム１１０２が単一の組織に対してのみ動作され、その組織内における１つ以上のエンティティに対してサービスを提供してもよい、プライベートクラウドモデルの下で提供されてもよい。クラウドサービスは、さらに、クラウドインフラストラクチャシステム１１０２およびクラウドインフラストラクチャシステム１１０２によって提供されるサービスが関係付けられるコミュニティにおけるいくつかの組織によって共有されるコミュニティクラウドモデルの下で提供されてもよい。クラウドサービスは、さらに、２つ以上の異なるモデルの組合せであるハイブリッドクラウドモデルの下で提供されてもよい。

いくつかの実施形態において、クラウドインフラストラクチャシステム１１０２によって提供されるサービスは、Ｓｏｆｔｗａｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＳａａＳ）カテゴリ、Ｐｌａｔｆｏｒｍ ａｓ ａ Ｓｅｒｖｉｃｅ（ＰａａＳ）カテゴリ、Ｉｎｆｒａｓｔｒｕｃｔｕｒｅ ａｓ ａ Ｓｅｒｖｉｃｅ（ＩａａＳ）カテゴリ、またはハイブリッドサービスを含む他のサービスのカテゴリの下で提供される、１つ以上のサービスを含んでもよい。顧客は、サブスクリプションオーダーを介して、クラウドインフラストラクチャシステム１１０２によって提供される１つ以上のサービスをオーダーしてもよい。クラウドインフラストラクチャシステム１１０２は、次いで、処理を実行して、顧客のサブスクリプションオーダーにおけるサービスを提供する。

いくつかの実施形態において、クラウドインフラストラクチャシステム１１０２によって提供されるサービスは、限定を伴わずに、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含んでもよい。いくつかの例では、アプリケーションサービスはクラウドインフラストラクチャシステムによってＳａａＳプラットフォームを介して提供されてもよい。ＳａａＳプラットフォームは、ＳａａＳカテゴリに入るクラウドサービスを提供するよう構成されてもよい。たとえば、ＳａａＳプラットフォームは、一式のオンデマンドアプリケーションを統合された開発およびデプロイプラットフォーム上で構築し配送する能力を提供してもよい。ＳａａＳプラットフォームは、ＳａａＳサービスを提供するための基底のソフトウェアおよびインフラストラクチャを管理および制御してもよい。ＳａａＳプラットフォームによって提供されるサービスを利用することによって、顧客はクラウドインフラストラクチャシステムにおいて実行されるアプリケーションを利用することができる。顧客は、別のライセンスおよびサポートを購入する必要なくアプリケーションサービスを獲得することができる。さまざまな異なるＳａａＳサービスが提供されてもよい。その例は、限定を伴うことなく、大きな組織に対する売上実績管理、エンタープライズ統合、および事業柔軟性に対するソリューションを提供するサービスを含む。

いくつかの実施形態において、プラットフォームサービスはクラウドインフラストラクチャシステムによってＰａａＳプラットフォームを介して提供されてもよい。ＰａａＳプラットフォームはＰａａＳカテゴリの下におけるクラウドサービスを提供するよう構成されてもよい。プラットフォームサービスの例は、限定を伴わずに、（Ｏｒａｃｌｅなどのような）組織が既存のアプリケーションを共有される共通のアーキテクチャにおいて整理統合することができるサービス、およびプラットフォームによって提供される共有されるサービスをてこ入れする新たなアプリケーションを構築する能力を含んでもよい。ＰａａＳプラットフォームはＰａａＳサービスを提供するための基底のソフトウェアおよびインフラストラクチャを管理および制御してもよい。顧客は、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを、別のライセンスおよびサポートを購入する必要なく獲得することができる。プラットフォームサービスの例は、限定を伴わずに、Ｏｒａｃｌｅ Ｊａｖａ Ｃｌｏｕｄ Ｓｅｒｖｉｃｅ（ＪＣＳ）、Ｏｒａｃｌｅ Ｄａｔａｂａｓｅ Ｃｌｏｕｄ Ｓｅｒｖｉｃｅ（ＤＢＣＳ）などを含む。

ＰａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを使用することができ、デプロイされたサービスを制御することもできる。いくつかの実施形態において、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえばＯｒａｃｌｅ Ｆｕｓｉｏｎ（登録商標） Ｍｉｄｄｌｅｗａｒｅサービス）、およびＪａｖａクラウドサービスを含んでもよい。一実施形態において、データベースクラウドサービスは、組織がデータベース資源をプールし、顧客にＤａｔａｂａｓｅ ａｓ ａ Ｓｅｒｖｉｃｅをデータベースクラウドの形式で提供することを可能にする、共有されるサービスデプロイモデルをサポートしてもよい。ミドルウェアクラウドサービスは、顧客のためのプラットフォームを提供してさまざまなビジネスアプリケーションを開発およびデプロイしてもよく、Ｊａｖａクラウドサービスは顧客のためのプラットフォームを提供してＪａｖａアプリケーションをクラウドインフラストラクチャシステムにおいてデプロイしてもよい。

さまざまな異なるインフラストラクチャサービスがＩａａＳプラットフォームによってクラウドインフラストラクチャシステムにおいて提供されてもよい。インフラストラクチャサービスは、ＳａａＳプラットフォームおよびＰａａＳプラットフォームによって提供されるサービスを利用する顧客に対するストレージ、ネットワーク、他の基礎的計算資源などのような基底の計算資源の管理および制御を容易にする。

特定の実施形態において、クラウドインフラストラクチャシステム１１０２は、さらに、クラウドインフラストラクチャシステムの顧客に対してさまざまなサービスを提供するよう用いられる資源を提供するためのインフラストラクチャ資源１１３０を含んでもよい。一実施形態において、インフラストラクチャ資源１１３０は、ＰａａＳプラットフォームおよびＳａａＳプラットフォームによって提供されるサービスを実行するよう、サーバ、ストレージおよびネットワーク接続資源などのような、ハードウェアの予め統合され最適化された組合せを含んでもよい。

いくつかの実施形態において、クラウドインフラストラクチャシステム１１０２における資源は、複数のユーザによって共有され、要望に付き動的に再割当てされてもよい。加えて、資源はユーザに対して異なる時間ゾーンで割当てられてもよい。たとえば、クラウドインフラストラクチャシステム１１３０は、第１の時間ゾーンにおける第１の組のユーザがクラウドインフラストラクチャシステムの資源をある特定化された時間数の間利用することを可能にし、次いで、異なる時間ゾーンに位置する別の組のユーザに対する同じ資源の再割当てを可能にし、それによって、資源の利用を最大限にしてもよい。

特定の実施形態において、クラウドインフラストラクチャシステム１１０２の異なるコンポーネントまたはモジュール、およびクラウドインフラストラクチャシステム１１０２によって提供されるサービスによって共有される、ある数の内部の共有されるサービス１１３２が提供されてもよい。これらの内部の共有されるサービスは、限定を伴うことなく、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性、バックアップおよびリカバリサービス、クラウドサポートを可能にするためのサービス、ｅメールサービス、通知サービス、ファイル転送サービスなどを含んでもよい。

特定の実施形態において、クラウドインフラストラクチャシステム１１０２は、クラウドインフラストラクチャシステムにおいてクラウドサービス（たとえばＳａａＳ、ＰａａＳ、およびＩａａＳサービス）の包括的な管理を提供してもよい。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム１１０２によって受信される顧客のサブスクリプションをプロビジョニングし、管理し、およびトラッキングする能力などを含んでもよい。

一実施形態において、図に示されるように、クラウド管理機能は、オーダー管理モジュール１１２０、オーダーオーケストレーションモジュール１１２２、オーダープロビジョニングモジュール１１２４、オーダー管理およびモニタリングモジュール１１２６、ならびにアイデンティティ管理モジュール１１２８などのような１つ以上のモジュールによって提供されてもよい。これらのモジュールは、１つ以上のコンピュータおよび／またはサーバを含むかもしくはそれらを用いて提供されてもよく、それらは汎用コンピュータ、特殊化されたサーバコンピュータ、サーバファーム、サーバクラスタ、または任意の他の適切な構成および／もしくは組合せであってもよい。

例示的な動作１１３４においては、クライアントデバイス１１０４、１１０６または１１０８などのようなクライアントデバイスを用いる顧客は、クラウドインフラストラクチャシステム１１０２によって提供される１つ以上のサービスを要求すること、およびクラウドインフラストラクチャシステム１１０２によって提供される１つ以上のサービスに対するサブスクリプションに対するオーダーを行うことによって、クラウドインフラストラクチャシステム１１０２と対話してもよい。特定の実施形態において、顧客は、クラウドユーザインターフェイス（ＵＩ）、クラウドＵＩ１１１２、クラウドＵＩ１１１４および／またはクラウドＵＩ１１１６にアクセスし、サブスクリプションオーダーをこれらのＵＩを介して行ってもよい。顧客がオーダーを行うことに応答してクラウドインフラストラクチャシステム１１０２によって受取られるオーダー情報は、顧客を識別する情報、およびクラウドインフラストラクチャシステム１１０２によって提供される、その顧客が利用することを意図する１つ以上のサービスを含んでもよい。

オーダーが顧客によってなされた後、オーダー情報はクラウドＵＩ１１１２、１１１４および／または１１１６を介して受取られてもよい。

動作１１３６において、オーダーはオーダーデータベース１１１８に格納される。オーダーデータベース１１１８は、クラウドインフラストラクチャシステム１１１８によって動作されるいくつかのデータベースの１つであり得、他のシステム要素との関連において動作され得る。

動作１１３８で、オーダー情報はオーダー管理モジュール１１２０に転送される。いくつかの例では、オーダー管理モジュール１１２０は、オーダーを検証すること、および検証でそのオーダーを予約することなど、オーダーに関係付けられる請求および課金機能を実行するよう構成されてもよい。

動作１１４０で、オーダーに関する情報がオーダーオーケストレーションモジュール１１２２に通信される。オーダーオーケストレーションモジュール１１２２は、オーダー情報を利用して、顧客によってなされたオーダーに対してサービスおよび資源のプロビジョニングをオーケストレーションしてもよい。いくつかの例では、オーダーオーケストレーションモジュール１１２２は、資源のプロビジョニングをオーケストレーションして、利用されるサービスを、オーダープロビジョニングモジュール１１２４のサービスを用いてサポートしてもよい。

特定の実施形態において、オーダーオーケストレーションモジュール１１２２は、各オーダーに関連付けられるビジネスプロセスの管理を可能にし、ビジネスロジックを適用して、オーダーがプロビジョニングに進むべきかどうかを判断する。動作１１４２で、新たなサブスクリプションに対するオーダーが受取られると、オーダーオーケストレーションモジュール１１２２は、オーダープロビジョニングモジュール１１２４に対して、資源を割当て、サブスクリプションオーダーを満たすよう必要とされる資源を構成するよう、要求を送る。オーダープロビジョニングモジュール１１２４は、顧客によってオーダーされたサービスに対する資源の割当てを可能にする。オーダープロビジョニングモジュール１１２４は、クラウドインフラストラクチャシステム１１００によって提供されるクラウドサービスと、要求されたサービスを提供するための資源をプロビジョニングするよう用いられる物理的インプリメンテーション層との間におけるある抽象レベルを与える。オーダーオーケストレーションモジュール１１２２は、したがって、サービスおよび資源がオンザフライで実際にプロビジョニングされるか、または予めプロビジョニングされ、要求でのみ割当て／分配されるかどうかなど、インプリメンテーション詳細から隔離されてもよい。

動作１１４４で、サービスおよび資源がプロビジョニングされると、提供されるサービスの通知が、クラウドインフラストラクチャシステム３０２のオーダープロビジョニングモジュール１１２４によってクライアントデバイス１１０４、１１０６および／または１１０８における顧客に送信されてもよい。動作１１４６で、顧客のサブスクリプションオーダーはオーダー管理およびモニタリングモジュール１１２６によって管理およびトラッキングされてもよい。いくつかの例では、オーダー管理およびモニタリングモジュール１１２６は、用いられるストレージの量、転送されるデータ量、ユーザの数、システムアップ時間およびシステムダウン時間の量などのような、サブスクリプションオーダーにおけるサービスに対する使用統計を収集するよう構成されてもよい。

特定の実施形態において、クラウドインフラストラクチャシステム１１００はアイデンティティ管理モジュール１１２８を含んでもよい。アイデンティティ管理モジュール１１２８は、クラウドインフラストラクチャシステム１１００におけるアクセス管理および承認サービスなどのようなアイデンティティサービスを提供するよう構成されてもよい。いくつかの実施形態において、アイデンティティ管理モジュール１１２８は、クラウドインフラストラクチャシステム１１０２によって提供されるサービスを利用することを望む顧客についての情報を制御してもよい。そのような情報は、そのような顧客のアイデンティティを認証する情報、およびそれらの顧客がさまざまなシステム資源（たとえばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど）に対してどのアクションを実行するよう承認されるかを記述する情報を含むことができる。アイデンティティ管理モジュール１１２８は、さらに、各顧客についての記述的情報およびどのように誰によってその記述的情報がアクセスおよび修正され得るかの管理を含んでもよい。

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

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

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

Claims (15)

1. 連続クエリ言語（ＣＱＬ）エンジンから作成されるスナップショットを管理するための方法であって、
   コンピューティングデバイスが、アプリケーションに関連する入力イベントのマイクロバッチストリームを受信することと、
   前記コンピューティングデバイスが、前記ＣＱＬエンジンを用いて、前記入力イベントを処理して、前記アプリケーションに関連する出力イベントのセットを生成することと、
   前記コンピューティングデバイスが、前記ＣＱＬエンジンによって実現されるスナップショット管理アルゴリズムを用いて、前記アプリケーションに関連する前記出力イベントのセットに少なくとも部分的に基づいて、システムの現在の状態のスナップショットを生成することと、
   前記コンピューティングデバイスが、前記システムの前記現在の状態の前記スナップショットに関連付けられるスナップショット情報にアクセスするために第１のディレクトリ構造を生成することと、
   前記コンピューティングデバイスが、前記システムの前記現在の状態に関連付けられるスナップショットのリストを生成するために第２のディレクトリ構造を生成することと、
   前記コンピューティングデバイスが、前記システムの前記現在の状態に関連付けられる前記スナップショットのリストを取得、追加、またはクリーンにするために前記スナップショット管理アルゴリズムに少なくとも部分的に基づいてプロセスを決定することと、
   前記コンピューティングデバイスが、前記アプリケーションに関連する前記出力イベントのセットを出力待ち行列に格納することと、
   前記入力イベントのすべてが処理されたときに、前記コンピューティングデバイスが前記出力待ち行列内の前記出力イベントを送信することとを備える、方法。
2. 前記マイクロバッチストリームは、１秒未満のマイクロバッチに離散化されたデータの連続ストリームである、請求項１に記載の方法。
3. 前記入力イベントを処理することは、変換されたクエリプランに少なくとも部分的に基づいて、前記入力イベントを処理することを含む、請求項２に記載の方法。
4. 前記マイクロバッチストリームは、マイクロバッチのデータまたはレジリエント分散データセット（ＲＤＤ）を含む、請求項１～３のいずれかに記載の方法。
5. 前記入力イベントの各々を処理することは、前記変換されたクエリプランに少なくとも部分的に基づいて、前記入力イベントの各々に対して計算を実行することを含む、請求項４に記載の方法。
6. 前記コンピューティングデバイスが、連続クエリを受信することと、前記連続クエリに変換を適用して前記連続クエリについてクエリプランを生成することと、変換アルゴリズムを用いて前記クエリプランを変換して前記変換されたクエリプランを生成することとをさらに備え、前記連続クエリはパターンマッチングを含む、請求項５に記載の方法。
7. システムであって、
   コンピュータ実行可能命令を格納するように構成されたメモリと、
   前記メモリにアクセスし、前記コンピュータ実行可能命令を実行して、
   アプリケーションに関連する入力イベントのマイクロバッチストリームを受信し、
   ＣＱＬエンジンを用いて、前記入力イベントを処理して、前記アプリケーションに関連する出力イベントのセットを生成し、
   前記ＣＱＬエンジンによって実現されるスナップショット管理アルゴリズムを用いて、前記アプリケーションに関連する前記出力イベントのセットに少なくとも部分的に基づいて、システムの現在の状態のスナップショットを生成し、
   前記システムの前記現在の状態の前記スナップショットに関連付けられるスナップショット情報にアクセスするために第１のディレクトリ構造を生成し、
   前記システムの前記現在の状態に関連付けられるスナップショットのリストを生成するために第２のディレクトリ構造を生成し、
   前記システムの前記現在の状態に関連付けられる前記スナップショットのリストを取得、追加、またはクリーンにするために前記スナップショット管理アルゴリズムに少なくとも部分的に基づいてプロセスを決定し、
   前記アプリケーションに関連する前記出力イベントのセットを出力待ち行列に格納し、
   前記入力イベントのすべてが処理されたときに、前記出力待ち行列内の前記出力イベントを送信するよう構成されるプロセッサとを備える、システム。
8. 完全にステートフルなクエリ処理をサポートするようマイクロバッチ方式ストリームを処理するための方法であって、
   コンピューティングデバイスが、連続クエリを受信することと、
   前記コンピューティングデバイスが、前記連続クエリに対して変換を適用して、前記連続クエリについてクエリプランを生成することと、
   前記コンピューティングデバイスが、モニタリング変換プロセスを用いて前記連続クエリを監視することと、
   前記コンピューティングデバイスが、アプリケーションに関連する入力イベントのマイクロバッチストリームを受信することと、
   前記コンピューティングデバイスが、前記モニタリング変換プロセスに少なくとも部分的に基づいて、前記マイクロバッチストリームの前記入力イベントを処理して、前記アプリケーションに関連する出力イベントのセットを生成することと、
   前記コンピューティングデバイスが、前記アプリケーションに関連する前記出力イベントのセットを出力待ち行列に格納することと、
   前記入力イベントのすべてが処理されたときに、前記コンピューティングデバイスが前記出力待ち行列内の前記出力イベントを送信することを備える、方法。
9. 前記処理は連続クエリ処理エンジンを用いて実行され、前記処理は前記出力イベントを生成するために前記入力イベントの各々を増分的に処理することを含む、請求項８に記載の方法。
10. 前記変換は有向非巡回グラフ（ＤＡＧ）変換である、請求項９に記載の方法。
11. 前記マイクロバッチストリームはマイクロバッチのデータまたはレジリエント分散データセット（ＲＤＤ）を含み、前記ＤＡＧ変換は頂点と辺とのセットであり、前記頂点は前記ＲＤＤを表し、前記辺は前記ＲＤＤに適用されるべき操作を表す、請求項１０に記載の方法。
12. 前記入力イベントの各々を処理することは、変換されたクエリプランに少なくとも部分的に基づいて、前記入力イベントの各々に対して計算を実行することを含む、請求項１１に記載の方法。
13. 前記連続クエリはパターンマッチングを含む、請求項１２に記載の方法。
14. システムであって、
    コンピュータ実行可能命令を格納するように構成されたメモリと、
    前記メモリにアクセスし、前記コンピュータ実行可能命令を実行して、
    連続クエリを受信し、
    前記連続クエリに対して変換を適用して、前記連続クエリについてクエリプランを生成し、
    モニタリング変換プロセスを用いて前記連続クエリを監視し、
    アプリケーションに関連する入力イベントのマイクロバッチストリームを受信し、
    前記モニタリング変換プロセスに少なくとも部分的に基づいて、前記マイクロバッチストリームの前記入力イベントを処理して、前記アプリケーションに関連する出力イベントのセットを生成し、
    前記アプリケーションに関連する前記出力イベントのセットを出力待ち行列に格納し、
    前記入力イベントのすべてが処理されたときに、前記出力待ち行列内の前記出力イベントを送信するよう構成されるプロセッサとを備える、システム。
15. 請求項１～５および８～１３のいずれか１項に記載の方法をプロセッサに実行させるためのコンピュータ可読プログラム。

Images