JP2019537092A - 自動時間進行についての処理タイムスタンプおよびハートビートイベント - Google Patents

Abstract

イベントストリームにおけるイベントを処理するためのイベント処理システムが開示される。システムは、ストリームソースからの入来イベントをマイクロバッチするようにストリームプロセッサを構成するように構成される。システムはさらに、入来イベントのマイクロバッチについての単一のタイムスタンプを生成するように、および／またはストリームソースからの入来イベントのマイクロバッチを受信するように構成される。システムはさらに、単一のタイムスタンプをマイクロバッチの各イベントに割り当てるように、および／またはマイクロバッチのそれぞれのイベントごとに別個のタイムスタンプ値を生成するように構成され得る。いくつかの例では、システムはさらに、マイクロバッチのそれぞれのイベントごとに、別個のタイムスタンプ値のうちの個々のタイムスタンプ値を割り当てるように構成され得る。

Description

関連出願の相互参照
本願は、２０１６年９月１５日に出願され「自動時間進行についての処理タイムスタンプおよびハートビートイベント（PROCESSING TIMESTAMPS AND HEARTBEAT EVENTS FOR AUTOMATIC TIME PROGRESSION）」と題された米国仮出願番号第６２／３９５，０４４号の利益および優先権を米国特許法第１１９条（ｅ）のもとで主張し、その開示全体をあらゆる目的のために本明細書に引用により援用する。

また、本願は、本願と同日に出願され「分散型イベント処理システムにおけるデータ直列化（DATA SERIALIZATION IN A DISTRIBUTED EVENT PROCESSING SYSTEM）」と題された出願連続番号第 号および代理人整理番号第０８８３２５−１０４３３３４（１７７６００ＵＳ）号と、本願と同日に出願され「分散型イベント処理システムのためのグラフ生成（GRAPH GENERATION FOR A DISTRIBUTED EVENT PROCESSING SYSTEM）」と題された出願連続番号第 号および代理人整理番号第０８８３２５−１０４３３３５（１７７６１０ＵＳ）号と、本願と同日に出願され「クラスタリングイベント処理エンジン（CLUSTERING EVENT PROCESSING ENGINES）」と題された出願連続番号第 号および代理人整理番号第０８８３２５−１０４３３３６（１７７６２０ＵＳ）号と、本願と同日に出願され「分散型イベント処理システムにおけるデータパーティショニングおよび並列処理（DATA PARTITIONING AND PARALLELISM IN A DISTRIBUTED EVENT PROCESSING SYSTEM）」と題された出願連続番号第 号および代理人整理番号第０８８３２５−１０４３３３７（１７７６３０ＵＳ）号とに関連する。各出願の内容全体をその全体が記載されているが如く本明細書に引用により援用する。

背景
従来のデータベースシステムでは、データは、通常はテーブルの形態の１つ以上のデータベースに格納される。格納されたデータは、次いで、構造化照会言語（ＳＱＬ）などのデータ管理言語を使用して照会され操作される。たとえば、ＳＱＬクエリは、データベースに格納されたデータから関連データを識別するように定義され実行されてもよい。したがって、ＳＱＬクエリは、データベースに格納された有限のデータセットに対して実行される。さらに、ＳＱＬクエリが実行される場合、それは有限のデータセットに対して一度実行されて、有限の静的な結果を生成する。したがって、格納された有限のデータセットに対して照会を行うようにデータベースが最適に準備される。

しかし、多数の現代のアプリケーションおよびシステムは、有限のデータセットの代わりに、連続データまたはイベントストリームの形態のデータを生成する。このようなアプリケーションの例としては、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール（たとえば、ネットワーク監視およびトラフィック管理アプリケーション）、クリックストリーム解析ツール、自動車交通監視などが挙げられるが、それらに限定されるものではない。このようなアプリケーションは、データストリームを処理することができる新しいタイプのアプリケーションの必要性を生じさせてきた。たとえば、温度センサは、温度読取値を送信するように構成されてもよい。

これらのタイプのイベントストリームベースのアプリケーションのためのデータの管理および処理は、強力な時間的焦点を有するデータ管理および照会機能を構築することを必要とする。連続的な無限のデータセットに対して長期間照会を行うことを含む異なる種類の照会機構が必要である。イベントストリーム処理に適合した製品一式を提供しているベンダもいるが、これらの製品提供は、依然として、今日のイベント処理ニーズに対処するのに必要な処理柔軟性が欠如している。

簡単な概要
ストリームソースからの入来イベントをマイクロバッチするようにストリームプロセッサを構成するための技術（たとえば、方法、システム、１つ以上のプロセッサによって実行可能なコードまたは命令を格納している非一時的なコンピュータ読取可能な媒体）が提供される。ある実施形態では、システムは、入来イベントのマイクロバッチについての単一のタイムスタンプを生成するように、および／またはストリームソースからの入来イベントのマイクロバッチを受信するように構成される。システムはさらに、単一のタイムスタンプをマイクロバッチの各イベントに割り当てるように、および／またはアルゴリズムに少なくとも部分的に基づいて、マイクロバッチのそれぞれのイベントごとに別個のタイムスタンプ値を生成するように構成される。いくつかの例では、システムはさらに、マイクロバッチのそれぞれのイベントごとに、別個のタイムスタンプ値のうちの個々のタイムスタンプ値を割り当てるように構成され得る。

特定の実施形態では、アルゴリズムは、ウォールクロック進行アルゴリズム、均等分散型アルゴリズム、均等分散型トップオフアルゴリズム、または単純なシーケンスアルゴリズムを含む。いくつかの例では、別個のタイムスタンプ値のうちの個々のタイムスタンプ値を割り当てることは、別個のタイムスタンプ値のうちの個々のタイムスタンプ値を、マイクロバッチの各イベントについての単一のタイムスタンプに付加することを含む。さらに、アルゴリズムは、マイクロバッチの各イベントに固有のタイムスタンプを提供し、および／またはアルゴリズムは、マイクロバッチの各イベントがマイクロバッチの一部として識別可能であることを保証する。場合によっては、システムはさらに、各イベントを、１つ以上の連続クエリ言語エンジンパーティションに割り当てるように、１つ以上の連続クエリ言語エンジンパーティションの第１のパーティションを識別するように、および／または第１のパーティションが、第１のパーティションに割り当てられるバッチにおける複数のイベントのイベント数よりも大きいウィンドウサイズを有すると判断するように構成され得る。さらに、場合によっては、システムは、第１のパーティションについてのハートビートイベントを生成するように、および／またはハートビートイベントを第１のパーティションに挿入するように構成され得る。

上記および下記の技術は、多くの方法でおよび多くの文脈で実現することができる。以下でさらに詳細に説明するように、以下の図面を参照していくつかの例示的な実現例および文脈を提供する。しかし、以下の実現例および文脈は、多くのもののうちのいくつかに過ぎない。

本開示の実施形態に従う例示的なイベント処理システムの態様を示す図である。 本開示の実施形態を組み込むことができるイベント処理システムの簡略化された高レベル図である。 本開示の実施形態に従う分散型イベント処理システムの例示的なユースケースを示すブロック図である。 本開示の一実施形態に従う処理の例示的なフロー図である。 本開示の別の実施形態に従う処理の例示的なフロー図である。 本開示の別の実施形態に従う処理の例示的なフロー図である。 本開示の実施形態を実現するための分散型システムの簡略図である。 本開示の実施形態に従って実施形態のシステムの１つ以上のコンポーネントによって提供されるサービスをクラウドサービスとして提供することができるシステム環境の１つ以上のコンポーネントの簡略ブロック図である。 本開示の実施形態を実現するために用いられ得る例示的なコンピュータシステムを示す図である。

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

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

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

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

連続的なデータストリーム（イベントストリームとも称される）は、明確な終端を持たない、本来は連続的または無限であり得るデータまたはイベントのストリームを含み得る。論理的には、イベントまたはデータストリームは、一連のデータ要素（イベントとも称される）であり得、各データ要素は、関連付けられたタイムスタンプを有する。連続的なイベントストリームは、論理的には、一袋または一組の要素（ｓ，Ｔ）として表現され得、「ｓ」はデータ部分を表わし、「Ｔ」は時間領域内にある。「ｓ」部分は、一般にタプルまたはイベントと称される。したがって、イベントストリームは、一連のタイムスタンプ付きタプルまたはイベントであり得る。

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

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

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

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

イベントストリームは、関連付けられたスキーマ「Ｓ」を有し、当該スキーマは、時間情報と、一組の１つ以上の名前付き属性とを備える。特定のイベントストリームに属する全てのイベントは、当該特定のイベントストリームに関連付けられたスキーマに一致する。したがって、イベントストリーム（ｓ，Ｔ）では、イベントストリームは、（<time_stamp>, <attribute(s)>）としてスキーマ「Ｓ」を有し得、<attributes>は、スキーマのデータ部分を表わし、１つ以上の属性を備え得る。たとえば、株式相場表示機イベントストリームのためのスキーマは、属性<stock symbol>および<stock price>を備えていてもよい。このようなストリームを介して受信した各イベントは、タイムスタンプと、２つの属性を有することになる。たとえば、株式相場表示機イベントストリームは、以下のイベントおよび関連付けられたタイムスタンプを受信し得る。

上記のストリームにおいて、ストリーム要素（<timestamp_N+l>, <ORCL,62>）では、イベントは、属性「stock_symbol」および「stock_value」を有する<ORCL,62>である。当該ストリーム要素に関連付けられたタイムスタンプは、「timestamp_N+l」である。したがって、連続的なイベントストリームはイベントのフローであり、各イベントは同一の一連の属性を有する。

上記のように、ストリームは、ＣＱＬクエリが作用し得る原理データソースであり得る。ストリームＳは、一袋の（「複数組の」とも称される）要素（ｓ，Ｔ）であり得、「ｓ」はスキーマＳ内にあり、「Ｔ」は時間領域内にある。さらに、ストリーム要素は、一連のタイムスタンプ付きタプル挿入として表わすことができるタプル・タイムスタンプ対であり得る。言い換えれば、ストリームは、一連のタイムスタンプ付きタプルであり得る。場合によっては、同一のタイムスタンプを有する２つ以上のタプルがあってもよい。そして、入力ストリームのタプルは、タイムスタンプが増加する順にシステムに到着することを要求され得る。代替的に、関係（「時間変化関係」とも称され、リレーショナルデータベースからのデータを含み得る「リレーショナルデータ」と混同すべきではない）は、時間領域からスキーマＲのタプルの無限の集合へのマッピングであってもよい。いくつかの例では、関係は、タプルの順序付けされていない、時間変化的な集合（すなわち、瞬間的な関係）であってもよい。場合によっては、時間の各インスタンスにおいて、関係は、有界集合であってもよい。また、関係は、関係の変化する状態を取り込むための挿入、削除および／または更新を含み得る一連のタイムスタンプ付きタプルとして表わすこともできる。ストリームと同様に、関係は、関係の各タプルが一致し得る固定のスキーマを有し得る。さらに、本明細書では、連続クエリは、一般に、ストリームおよび／または関係の（すなわち、ストリームおよび／または関係に対して照会される）データを処理することが可能であり得る。また、関係は、ストリームのデータを参照し得る。

いくつかの局面では、ＣＱＬエンジンは、本格的なクエリ言語を含み得る。したがって、ユーザは、クエリの観点から計算を指定し得る。さらに、ＣＱＬエンジンは、クエリ言語特徴、オペレータ共有、豊かなパターンマッチング、豊かな言語構造などを利用してメモリを最適化するように設計され得る。さらに、いくつかの例では、ＣＱＬエンジンは、履歴データもストリーミングデータも処理し得る。たとえば、ユーザは、カリフォルニアセールスが特定の目標値を上回ると警告を送信するようにクエリを設定してもよい。したがって、いくつかの例では、当該警告は、少なくとも一部には履歴販売データおよび入来ライブ（すなわち、リアルタイム）販売データに基づき得る。

いくつかの例では、ＣＱＬエンジンまたは以下で説明する概念の他の特徴は、リアルタイムの態様で履歴文脈（すなわち、倉庫データ）と入来データとを組み合わせるように構成され得る。したがって、場合によっては、本開示は、データベース格納情報および流れている情報の境界について説明することができる。データベース格納情報も流れている情報もＢＩデータを含み得る。したがって、いくつかの例では、データベースは、ＢＩサーバであってもよく、またはいずれかのタイプのデータベースであってもよい。さらに、いくつかの例では、本開示の特徴は、どのようにしてコードをプログラムするか、またはそうでなければどのようにしてコードを書込むかをユーザが知らなくても、上記の特徴を実現することを可能にし得る。言い換えれば、当該特徴は、非開発者が履歴データとリアルタイムデータとの組み合わせを実現することを可能にする機能豊富なユーザインターフェイス（ＵＩ）または他の態様で提供され得る。

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

イベント処理アプリケーション
ＩＴ環境におけるｒａｗインフラストラクチャおよびビジネスイベントの量と速度は、飛躍的に増加している。金融サービスのための株式データをストリーミングしているか、軍事用の衛星データをストリーミングしているか、または運送および物流業界のリアルタイムな車両位置データをストリーミングしているかにかかわらず、さまざまな業界の企業が、大量の複雑なデータをリアルタイムで処理しなければならない。さらに、モバイルデバイスの急激な増加および高速接続の普及により、モバイルデータも飛躍的に増加している。同時に、ビジネスプロセスの俊敏性および実行に対する需要も高まっている。これら２つの傾向によって、組織は、実装のイベント駆動型のアーキテクチャパターンをサポートできる必要性に迫られている。リアルタイムなイベント処理には、イベント処理要件を実行するインフラストラクチャとアプリケーション開発環境の両方が必要である。これらの要件は、日常的なユースケースから非常に高速なデータおよびイベントのスループットまでをスケーリングするニーズが含まれる場合が多く、潜在的に、秒単位ではなくマイクロ秒単位で測定される待ち時間を伴う。また、イベント処理アプリケーションで、これらのイベントのフローの複雑なパターンの検出が必要となる場合が多い。

Oracle Stream Analyticsプラットフォームは、幅広い業界および機能分野を対象としている。以下は、ユースケースの一部である。

電気通信：リアルタイムな呼詳細（ＣＤＲ）記録を監視し、分散サービス妨害攻撃を検出する能力。

金融サービス：ミリ秒またはマイクロ秒単位で存在する裁定取引の機会を資本化する能力。金融証券取引のリアルタイムなリスク分析、監視および報告を実行し、外国為替価格を計算する能力。

運送：出発地や到着地の都市の天候、地上クルーの作業、空港のセキュリティなどにより運航の問題が発生した場合に、乗客に通知して、荷物の場所を検出する能力。

公共機関/軍隊：地理的に分散した敵の情報を検出し、抽象化し、敵の攻撃の可能性が高い場合を解読する能力。該当するほとんどのリソースに対し、緊急事態への対応の警告を出す能力。

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

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

処理タイムスタンプ
近年、潜在的に無限のリアルタイムデータストリームに対してクエリを連続的に実行することができるデータストリーム管理システム（ＤＳＭ）が開発されている。新たなＤＳＭの中には、単一のフレームワークからバッチ処理とストリーム処理との組み合わせを提供するためにマイクロバッチ方式のストリーム処理を採用しているシステムもある。Spark（登録商標）上で動作するSpark Streamingは、このようなシステムの１つである。しかし、マイクロバッチ方式のストリーム処理は、イベントごとの処理を提供せず、マイクロバッチについての全てのイベントに同一のタイムスタンプを割り当てる。その結果、マイクロバッチ方式のストリーム処理は、同一のマイクロバッチ内の関係を検出することができないか、または、ウィンドウスライド持続時間がミリ秒もしくはナノ秒であるべき特定の場合について正確な結果を作成することができなかった。

Oracle Stream Analyticsを用いた上記の問題に対する１つの解決策は、マイクロバッチにおける各イベントに固有のタイムスタンプを生成することである。

タイムスタンプを生成する際には以下のアルゴリズムが用いられる。
１） バッチについて生成されたイベントの開始時間として「batchTime」を用いる
２） バッチ−１の終端がハートビートイベントとして送信される
３） バッチから作成されたタプルについての全てのタイムスタンプは範囲（currentBatchTime＋batchDuration−２）内にあるべきである
４） タプルが作成される摂取段階においてタイムスタンプが割り当てられる
５） currentBatchTimeからcurrentBatchTime＋batchDurationの範囲内にタイムスタンプを分散させるための４つの異なるポリシーがある（ウォールクロック進行（wall clock progression）、均等分散型、均等分散型トップオフ、および／またはシーケンス型トップオフ）
この解決策では、以下が新しい。

−マイクロバッチ方式のストリーム処理に対して処理タイムスタンプを追加する
−自動時間進行についての処理タイムスタンプについてハートビートを追加する
本明細書に記載の特徴を使用する前は、マイクロバッチ方式のストリーム処理は、イベントごとに異なるタイムスタンプを割り当てることができず、イベントごとの処理が不可能であった。イベントごとの処理がないと、ストリーム処理および時系列分析が不可能ではないにしても非常に困難である。これは、イベントごとの処理を追加し、マイクロバッチ方式のストリーム処理では解決不可能であったユースケースを解決可能にすることによって、マイクロバッチ方式のストリーム処理のいくつかの欠点を解決する。

図１は、マイクロバッチ方式のシステム内でタイムスタンプを処理するための例示的なフロー１００を示す。いくつかの例では、ドライバ１０４の一部として実行されるＤＡＧスケジューラ１０２がマイクロバッチジョブを起動する。このジョブは、入力イベントを読み出し、ＣＱＬＲＤＤ１０８を子変換として有するConvertToTupleRDD変換を使用するcreateTuples１０６を使用してタプルを作成するＥＴＬ変換を含み得る。ＣＱＬＲＤＤ１０８の計算方法は、現在のバッチ時間を開始時間としてセットし、親（ConvertToTupleRDD）変換の計算方法を呼出す。いくつかの例では、ConvertToTupleRDDの計算方法は、処理時間発生器１１０を使用して処理タイムスタンプをＲＤＤ内のタプルにセットする。処理時間発生器１１０は、さまざまな分散方策を使用してタイムスタンプをバッチ同士の間に分散させる。たとえば、処理時間発生器１１０は、ウォールクロック分散方策１１２、均等分散型分散方策１１４、均等分散型トップオフ分散方策１１６、またはシーケンス型トップオフ分散方策１１８を使用し得る。

ウォールクロック進行１１２：
・現在時刻のベースとの差を使用する
・摂取遅延を組み込む
・オーバーフロー保護
−上記の差を最大で何らかの時間（たとえばバッチ持続時間の１／２または２／３）にキャップする
−キャップに到達した後にシーケンスを使用する
均等分散型１１４：
・マイクロバッチにおけるイベントの数を取得する
・間隔＝（バッチ持続時間）／（イベントの数）
均等分散型トップオフ１１６：
・分散は「maxRate」を提供することによってユーザによって制御される

シーケンス型トップオフ（単純なシーケンス）１１８：
・マイクロバッチにおける各イベントはバッチ時間からシーケンス番号を取得する
・単位は、バッチの終端に達した後にナノ秒に進むことによってオーバーフロー保護を有するミリ秒である
イベント処理サービス
図２は、本開示の一実施形態を組み込むことができるイベント処理システム２００の簡略化された高レベル図を示す。ある実施形態では、イベント処理システム２００は、オラクル（登録商標）によって管理されるOracle Event Processor（ＯＥＰ）システムを表わし得る。イベント処理システム２００は、１つ以上のイベントソース（６０４，２０６，２０８）と、イベントストリームを処理するための環境を提供するように構成されたイベント処理サービス（ＥＰＳ）２０２（ＣＱサービス２０２とも称される）と、１つ以上のイベントシンク（６１０，２１２）とを備え得る。イベントソースは、ＥＰＳ２０２によって受信されるイベントストリームを生成する。ＥＰＳ２０２は、１つ以上のイベントソースから１つ以上のイベントストリームを受信し得る。

たとえば、図２に示されるように、ＥＰＳ２０２は、イベントソース２０４から第１の入力イベントストリーム２１４を受信し、イベントソース２０６から第２の入力イベントストリーム２１６を受信し、イベントソース２０８から第３のイベントストリーム２１８を受信する。１つ以上のイベント処理アプリケーション（６１４，２１６および２１８）がＥＰＳ２０２上にデプロイされてＥＰＳ２０２によって実行され得る。ＥＰＳ２０２によって実行されるイベント処理アプリケーションは、１つ以上の入力イベントストリームを聞き取り、注目すべきイベントとして入力イベントストリームから１つ以上のイベントを選択する処理ロジックに基づいて、この１つ以上のイベントストリームを介して受信したイベントを処理するように構成され得る。次いで、この注目すべきイベントは、１つ以上の出力イベントストリームの形態で１つ以上のイベントシンク（６１０，２１２）に送信され得る。たとえば、図２では、ＥＰＳ２０２は、第１の出力イベントストリーム２２０をイベントシンク２１０に出力し、第２の出力イベントストリーム２２２をイベントシンク２１２に出力する。特定の実施形態では、イベントソース、イベント処理アプリケーション、およびイベントシンクは、他のコンポーネントに対する変更を生じさせることなくこれらのコンポーネントのうちのいずれかを追加または除去することができるように互いに分離される。

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

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

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

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

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

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

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

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

いくつかの例では、マイクロバッチ方式のストリーム処理は、イベントごとの処理を提供せず、マイクロバッチ内の全てのイベントに同一のタイムスタンプを割り当てる。その結果、マイクロバッチ方式のストリーム処理は、同一のマイクロバッチ内のイベントから関係を検出することができない場合がある。

マイクロバッチ内の全てのイベントに同一のタイムスタンプを有することについてのより深刻な問題は、ウィンドウスライド持続時間がミリ秒またはナノ秒でない限りは、正確な結果が作成されない場合があることである。図３はそのような場合を示しており、このユースケースは、３秒間隔で３つ以上のトランザクションを有するクレジットカードにフラグを立てることである。バッチ間隔は各々が１秒であってもよく、イベント到着率は２イベント／秒／バッチであると仮定する。処理タイムスタンプは、システムへの摂取からタプルを作成する際にタプルに割り当てられるタイムスタンプである。各タイムスタンプは単調に増加すべきであり、先のタイムスタンプと重なり合うべきでなく、または先のタイムスタンプで複製されるべきでない。各バッチに同一のタイムスタンプを用いることによって、システムは２つのウィンドウについて以下のイベントを見ることになる。

時間ｔ０におけるウィンドウ：｛（Ｅ１，ＣＣ１），（Ｅ２，ＣＣ２），（Ｅ３，ＣＣ３），（Ｅ４，ＣＣ４），（Ｅ５，ＣＣ５），（Ｅ６，ＣＣ６）｝
時間ｔ１におけるウィンドウ：｛（Ｅ３，ＣＣ３），（Ｅ４，ＣＣ４），（Ｅ５，ＣＣ５），（Ｅ６，ＣＣ２），（Ｅ７，ＣＣ２），（Ｅ８，ＣＣ６）｝
ウィンドウ長が３秒であると仮定して、時間ｔ０におけるウィンドウはｔ０からｔ３に進み、一方、時間ｔ１におけるウィンドウはｔ１からｔ４に進む。したがって、ＣＣ２，ｔ０．５：（Ｅ２，ＣＣ２），ｔ２．５：（Ｅ６，ＣＣ２），ｔ３：（Ｅ７，ＣＣ２）についてのイベントのみを見ると、０．５秒のスライドを有する３秒のウィンドウ内に３つのトランザクションがあるが、各バッチに同一のタイムスタンプを使用する上記のシステムはこれを見過ごす。言い換えれば、当該システムは、イベントＥ７およびＥ８の両方にバッチ時間ｔ４を割り当て、デフォルトでこのバッチ間隔を使用してスライドする。しかし、１秒スライドすることによって、当該システムは、ｔ＝３．５におけるＣＣ２に３つのトランザクションがあったという事実を見過ごすことになる。

自動時間進行についてのハートビートイベント
イベントごとの処理を提供するために、処理タイムスタンプおよびイベントタイムスタンプが追加されている。イベントごとの処理システム内では、システムは時間を連続的に進行させる必要がある。そうしなければ、
−出力の遅延
−ウィンドウからの満了がない
−イベント検出パターンマッチングを見過ごすことによって持続時間ファイアがない
などの問題が生じ得る。

この問題を説明するために、２つのエグゼキュータ上で動作する２つのｃｑｌエンジン上で動作する範囲ウィンドウを有する例を挙げてみる。簡潔にするために、各バッチは１つのレコードを含むと仮定する。

クエリ：SELECT * FROM S[RANGE 3]
入力：

１００１および１００２は、処理パーティション−１であるＣＱＬエンジン１に進むと仮定する。したがって、ＣＱＬエンジン１のウィンドウは以下の２つのレコード
｛（１００１，１），（１００２，２）｝
を有することになる。

また、残りの３つのイベントは、処理パーティション−２であるＣＱＬエンジン２に進む。したがって、ＣＱＬエンジン２のウィンドウは以下の３つのレコード
｛（１００３，３），（１００４，４），（１００５，５）｝
を有することになる。

ゆえに、このアプリケーションタイムスタンプの場合、（１００３，３）はノード２上で動作するパーティションに属するため、（１００３，３）が到着するとノード１における空のＣＱＬ ＲＤＤが評価されることになる。次に他の３つの入力によって、タイムスタンプは１００５に移動する。したがって、理想的には、ＣＱＬエンジン１におけるウィンドウのイベントはウィンドウサイズが３であるときに満了すべきである。これらのイベントを満了させるために、ＣＱＬエンジン１はＣＱＬ ＲＤＤ計算からのハートビートを必要とし得る。しかし、誰が１００３のハートビートをＣＱＬエンジン１に伝播するのかが分からない/不明である場合がある。

いくつかの例では、１つの解決策は、パーティショニング前からのハートビートを挿入し、次にパーティションの最新のイベントタイムスタンプを追跡することである。別の実施形態は、出力イベントをタイムスタンプでソートし、最新のハートビートを全てのパーティションに伝播することである。たとえば、
カスタムパーティショナーからのハートビートが挿入され得る。

そして次に、
ＣＱＬ ＲＤＤから、スナップショット情報が送信され得、パーティションからの最大イベント時間が追加され得る。場合によっては、バッチのmax（largest eventtime）がgetCQLEngine要求の一部としてＣＱＬ ＲＤＤに返される。

バッチ１

CQLEngineTracker
ｐ１の最大イベントタイムスタンプ−１００２
ｐ２の最大イベントタイムスタンプ−１００５
バッチの最大イベントタイムスタンプ＝１００５
バッチ２
１００２＜１００５であるため、getCQLEngine(P1)が１００５を返す
（１００５）のハートビートが入力タプルの前にCQLEngineに送信される
ｐ１の最大イベントタイムスタンプ−１００５
１００５＝１００５であるため、getCQLEngine(P2)はハートビートを含まない
図４は、ハートビートを生成するためのフロー４００を示す。ConvertToTupleRDD変換から処理タイムスタンプを作成する間、初期のハートビートが生成される。各バッチについて、バッチについての処理タイムスタンプ持続時間内の最高のタイムスタンプを有するバッチの最後に、１つのハートビートイベントを付加する。バッチが空であり、バッチについての入力イベントがない場合でも、時間進行を保証するために依然として１つのハートビートイベントを挿入する。

ハートビートは、以下のアルゴリズムを使用してパーティショニング論理から伝播する。

１．４０２において、タイムスタンプをキーとしてsortBykey変換を使用してＲＤＤにおけるタプルをソートする
２．４０４において、HeartbeatPropagateRDDを使用してハートビートをパーティションにコピーする
３．４０６において、partitionBy変換を使用して実際のパーティショニングを行ない、さらに、パーティションへのハートビートの実際の伝播も行なわれる
実際のHeartbeatPropagationアルゴリズムは以下のように働く。

１．最後の１つを除いて全てのハートビートをスキップする
２．複製のハートビートタイムスタンプを除去する
３．パーティション番号を持つHBParitionValueを有することによって、ハートビートを全てのパーティションにコピーする
パーティショニングはフィールドによって何らかのグループによって行なわれるため、ハートビートイベントはタイムスタンプしか持っていないので、ハートビートイベントをこのような判断基準を用いてパーティションすることはできない。HBParitionValueは、内部にパーティション情報を持つ特別なマークオブジェクトである。パーティショナーがハートビートイベントからのHBParitionValueを見ると、パーティション値が適切に抽出され得、ハートビートイベントをパーティションにセットするために使用される。

例示的な方法
図５は、本開示の実施形態に従ってタイムスタンプを処理するための一組の動作を記述する処理５００の例示的なフロー図である。特定の実施形態では、処理５００は、図１のドライバ１０４などのドライバ、図１の処理時間発生器１１０などの発生器、および／または図２のイベント処理サービス２００などのサービスによって実行され得、これらの各々は分散型イベント処理システムの一部であってもよい。図５の処理は、イベントのバッチにおけるデータがタイムスタンプされ得る１つの技術を説明している。図５に示される特定の一連の処理ステップは限定的であるよう意図されるものではない。代替の実施形態は、さまざまな配置および組み合わせにおいて図５に示されるよりも多くのステップまたは少ないステップを有し得る。

特定の実施形態では、処理５００は５０２において、ストリームソースからの入来イベントをマイクロバッチするようにストリームプロセッサを構成することによって開始する。５０４において、処理は、入来イベントのマイクロバッチについての単一のタイムスタンプを生成することを含む。特定の例では、処理５００は、５０６においてストリームソースから入来イベントのマイクロバッチを受信することと、５０８において単一のタイムスタンプをマイクロバッチの各イベントに割り当てることとを含み得る。５１０において、処理５００は、アルゴリズムに少なくとも部分的に基づいて、マイクロバッチのそれぞれのイベントごとに別個のタイムスタンプ値を生成することを含む。さらに、５１２において、処理５００は、マイクロバッチのそれぞれのイベントごとに、別個のタイムスタンプ値のうちの個々のタイムスタンプ値を割り当てることを含む。

図６は、ハートビートイベントを生成して、マイクロバッチされたデータにハートビートイベントを挿入するための一組の動作を記述する処理６００の例示的なフロー図である。ある実施形態では、処理６００は図５の処理５００の動作の付加的な詳細を説明している。特定の例では、処理６００は６０２において、各イベントを１つ以上の連続クエリ言語エンジンパーティションに割り当てることによって開始する。６０４において、処理は、１つ以上の連続クエリ言語エンジンパーティションの第１のパーティションを識別することを含む。６０６において、処理は、第１のパーティションが、第１のパーティションに割り当てられるバッチにおける複数のイベントのイベント数よりも大きいウィンドウサイズを有すると判断することを含む。６０８において、処理は、第１のパーティションについてのハートビートイベントを生成することを含む。６１０において、処理は、ハートビートイベントを第１のパーティションに挿入することを含む。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

特定の実施形態では、クラウドインフラストラクチャシステム８０２は、セルフサービスの、サブスクリプションベースの、弾性的にスケーラブルで、信頼性があり、高可用性の、安全な態様で顧客に対して配送される一連のアプリケーション、ミドルウェア、およびデータベースサービス提供を含んでもよい。そのようなクラウドインフラストラクチャシステムの一例は、本譲受人によって提供されるOracle Public Cloudである。

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

いくつかの実施形態では、クラウドインフラストラクチャシステム８０２によって提供されるサービスは、ソフトウェア・アズ・ア・サービス（ＳａａＳ）カテゴリ、プラットフォーム・アズ・ア・サービス（ＰａａＳ）カテゴリ、インフラストラクチャ・アズ・ア・サービス（ＩａａＳ）カテゴリ、またはハイブリッドサービスを含む他のサービスのカテゴリの下で提供される１つ以上のサービスを含んでもよい。顧客は、サブスクリプションオーダーを介して、クラウドインフラストラクチャシステム８０２によって提供される１つ以上のサービスをオーダーしてもよい。クラウドインフラストラクチャシステム８０２は、次いで、処理を実行して、顧客のサブスクリプションオーダーにおけるサービスを提供する。

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

いくつかの実施形態では、プラットフォームサービスは、クラウドインフラストラクチャシステムによってＰａａＳプラットフォームを介して提供されてもよい。ＰａａＳプラットフォームは、ＰａａＳカテゴリに入るクラウドサービスを提供するように構成されてもよい。プラットフォームサービスの例としては、（オラクルなどの）組織が既存のアプリケーションを共有の共通のアーキテクチャにおいて整理統合することができるサービス、およびプラットフォームによって提供される共有サービスを活用する新たなアプリケーションを構築する機能を挙げることができるが、それらに限定されるものではない。ＰａａＳプラットフォームは、ＰａａＳサービスを提供するための基本的なソフトウェアおよびインフラストラクチャを管理および制御してもよい。顧客は、クラウドインフラストラクチャシステムによって提供されるＰａａＳサービスを、別個のライセンスおよびサポートを購入する必要なく取得することができる。プラットフォームサービスの例としては、Oracle Java Cloud Service（ＪＣＳ）、Oracle Database Cloud Service（ＤＢＣＳ）などが挙げられるが、それらに限定されるものではない。

ＰａａＳプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを使用することができ、デプロイされたサービスを制御することもできる。いくつかの実施形態では、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス（たとえばOracle Fusion Middlewareサービス）、およびＪａｖａクラウドサービスを含んでもよい。一実施形態では、データベースクラウドサービスは、組織がデータベースリソースをプールし、顧客にデータベース・アズ・ア・サービスをデータベースクラウドの形式で提供することを可能にする共有のサービスデプロイメントモデルをサポートしてもよい。ミドルウェアクラウドサービスは、顧客がさまざまなビジネスアプリケーションを開発およびデプロイするためのプラットフォームをクラウドインフラストラクチャシステムにおいて提供してもよく、Ｊａｖａクラウドサービスは、顧客がＪａｖａアプリケーションをデプロイするためのプラットフォームをクラウドインフラストラクチャシステムにおいて提供してもよい。

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

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

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

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

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

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

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

オーダーが顧客によって行われた後、オーダー情報は、クラウドＵＩ８１２，８１４および／または８１６を介して受信される。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Claims (20)

1. 方法であって、
   ストリームソースからの入来イベントをマイクロバッチするようにストリームプロセッサを構成することと、
   前記入来イベントのマイクロバッチについての単一のタイムスタンプを生成することと、
   前記ストリームソースからの前記入来イベントの前記マイクロバッチを受信することと、
   前記単一のタイムスタンプを前記マイクロバッチの各イベントに割り当てることと、
   アルゴリズムに少なくとも部分的に基づいて、前記マイクロバッチのそれぞれのイベントごとに別個のタイムスタンプ値を生成することと、
   前記マイクロバッチのそれぞれのイベントごとに、前記別個のタイムスタンプ値のうちの個々のタイムスタンプ値を割り当てることとを備える、方法。
2. 前記アルゴリズムは、ウォールクロック進行アルゴリズム、均等分散型アルゴリズム、均等分散型トップオフアルゴリズム、または単純なシーケンスアルゴリズムを備える、請求項１に記載の方法。
3. 前記別個のタイムスタンプ値のうちの個々のタイムスタンプ値を割り当てることは、前記別個のタイムスタンプ値のうちの前記個々のタイムスタンプ値を、前記マイクロバッチの各イベントについての前記単一のタイムスタンプに付加することを備える、請求項１または２に記載の方法。
4. 前記アルゴリズムは、前記マイクロバッチの各イベントに固有のタイムスタンプを提供する、請求項１から３のいずれか１項に記載の方法。
5. 前記アルゴリズムは、前記マイクロバッチの各イベントが前記マイクロバッチの一部として識別可能であることを保証する、請求項４に記載の方法。
6. 各イベントを、１つ以上の連続クエリ言語エンジンパーティションに割り当てることをさらに備える、請求項１から５のいずれか１項に記載の方法。
7. 前記１つ以上の連続クエリ言語エンジンパーティションの第１のパーティションを識別することと、
   前記第１のパーティションが、前記第１のパーティションに割り当てられる前記マイクロバッチにおける複数のイベントのイベント数よりも大きいウィンドウサイズを有すると判断することとをさらに備える、請求項６に記載の方法。
8. 前記第１のパーティションについてのハートビートイベントを生成することと、
   前記ハートビートイベントを前記第１のパーティションに挿入することとをさらに備える、請求項７に記載の方法。
9. システムであって、
   コンピュータによって実行可能な命令を格納するように構成されたメモリと、
   前記メモリにアクセスして、前記コンピュータによって実行可能な命令を実行するように構成されたプロセッサとを備え、前記コンピュータによって実行可能な命令は、少なくとも、
   ストリームソースからの入来イベントをマイクロバッチするようにストリームプロセッサを構成する命令と、
   前記入来イベントのマイクロバッチについての単一のタイムスタンプを生成する命令と、
   前記ストリームソースからの前記入来イベントの前記マイクロバッチを受信する命令と、
   前記単一のタイムスタンプを前記マイクロバッチの各イベントに割り当てる命令と、
   アルゴリズムに少なくとも部分的に基づいて、前記マイクロバッチのそれぞれのイベントごとに別個のタイムスタンプ値を生成する命令と、
   前記マイクロバッチのそれぞれのイベントごとに、前記別個のタイムスタンプ値のうちの個々のタイムスタンプ値を割り当てる命令とを備える、システム。
10. 前記アルゴリズムは、ウォールクロック進行アルゴリズム、均等分散型アルゴリズム、均等分散型トップオフアルゴリズム、または単純なシーケンスアルゴリズムを備える、請求項９に記載のシステム。
11. 前記別個のタイムスタンプ値のうちの個々のタイムスタンプ値を割り当てることは、前記別個のタイムスタンプ値のうちの前記個々のタイムスタンプ値を、前記マイクロバッチの各イベントについての前記単一のタイムスタンプに付加することを備える、請求項９または１０に記載のシステム。
12. 前記アルゴリズムは、前記マイクロバッチの各イベントに固有のタイムスタンプを提供する、請求項９か１１のいずれか１項に記載のシステム。
13. 前記アルゴリズムは、前記マイクロバッチの各イベントが前記マイクロバッチの一部として識別可能であることを保証する、請求項１２に記載のシステム。
14. 前記プロセッサは、少なくとも、
    各イベントを、１つ以上の連続クエリ言語エンジンパーティションに割り当てる、前記コンピュータによって実行可能な命令と、
    前記１つ以上の連続クエリ言語エンジンパーティションの第１のパーティションを識別する、前記コンピュータによって実行可能な命令と、
    前記第１のパーティションが、前記第１のパーティションに割り当てられる前記マイクロバッチにおける複数のイベントのイベント数よりも大きいウィンドウサイズを有すると判断する、前記コンピュータによって実行可能な命令と、
    前記第１のパーティションについてのハートビートイベントを生成する、前記コンピュータによって実行可能な命令と、
    前記ハートビートイベントを前記第１のパーティションに挿入する、前記コンピュータによって実行可能な命令とを実行するようにさらに構成される、請求項９から１３のいずれか１項に記載のシステム。
15. コンピュータによって実行可能なコードを格納しているコンピュータ読取可能な媒体であって、前記コンピュータによって実行可能なコードは、プロセッサによって実行されると前記プロセッサに動作を行なわせ、前記動作は、
    ストリームソースからの入来イベントをマイクロバッチするようにストリームプロセッサを構成することと、
    前記入来イベントのマイクロバッチについての単一のタイムスタンプを生成することと、
    前記ストリームソースからの前記入来イベントの前記マイクロバッチを受信することと、
    前記単一のタイムスタンプを前記マイクロバッチの各イベントに割り当てることと、
    アルゴリズムに少なくとも部分的に基づいて、前記マイクロバッチのそれぞれのイベントごとに別個のタイムスタンプ値を生成することと、
    前記マイクロバッチのそれぞれのイベントごとに、前記別個のタイムスタンプ値のうちの個々のタイムスタンプ値を割り当てることとを備える、コンピュータ読取可能な媒体。
16. 前記アルゴリズムは、ウォールクロック進行アルゴリズム、均等分散型アルゴリズム、均等分散型トップオフアルゴリズム、または単純なシーケンスアルゴリズムを備える、請求項１５に記載のコンピュータ読取可能な媒体。
17. 前記別個のタイムスタンプ値のうちの個々のタイムスタンプ値を割り当てることは、前記別個のタイムスタンプ値のうちの前記個々のタイムスタンプ値を、前記マイクロバッチの各イベントについての前記単一のタイムスタンプに付加することを備える、請求項１５または１６に記載のコンピュータ読取可能な媒体。
18. 前記アルゴリズムは、前記マイクロバッチの各イベントに固有のタイムスタンプを提供する、請求項１５から１７のいずれか１項に記載のコンピュータ読取可能な媒体。
19. 前記アルゴリズムは、前記マイクロバッチの各イベントが前記マイクロバッチの一部として識別可能であることを保証する、請求項１８に記載のコンピュータ読取可能な媒体。
20. 前記動作は、
    各イベントを、１つ以上の連続クエリ言語エンジンパーティションに割り当てることと、
    前記１つ以上の連続クエリ言語エンジンパーティションの第１のパーティションを識別することと、
    前記第１のパーティションが、前記第１のパーティションに割り当てられる前記マイクロバッチにおける複数のイベントのイベント数よりも大きいウィンドウサイズを有すると判断することと、
    前記第１のパーティションについてのハートビートイベントを生成することと、
    前記ハートビートイベントを前記第１のパーティションに挿入することとを備える、請求項１５から１９のいずれか１項に記載のコンピュータ読取可能な媒体。