IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ オラクル・インターナショナル・コーポレイションの特許一覧

特開2022-58578分散イベント処理システムにおけるデータシリアライズ
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2022058578
(43)【公開日】2022-04-12
(54)【発明の名称】分散イベント処理システムにおけるデータシリアライズ
(51)【国際特許分類】
   G06F 16/2455 20190101AFI20220405BHJP
   G06F 16/28 20190101ALI20220405BHJP
【FI】
G06F16/2455
G06F16/28
【審査請求】有
【請求項の数】9
【出願形態】OL
【外国語出願】
(21)【出願番号】P 2022003027
(22)【出願日】2022-01-12
(62)【分割の表示】P 2019514231の分割
【原出願日】2017-09-12
(31)【優先権主張番号】62/395,216
(32)【優先日】2016-09-15
(33)【優先権主張国・地域又は機関】US
(31)【優先権主張番号】15/700,784
(32)【優先日】2017-09-11
(33)【優先権主張国・地域又は機関】US
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.WINDOWS PHONE
2.iOS
(71)【出願人】
【識別番号】502303739
【氏名又は名称】オラクル・インターナショナル・コーポレイション
(74)【代理人】
【識別番号】110001195
【氏名又は名称】特許業務法人深見特許事務所
(72)【発明者】
【氏名】パーク,ホヨン
(72)【発明者】
【氏名】ビシュノイ,サンディープ
(72)【発明者】
【氏名】ツッカラム,プラブ
(57)【要約】      (修正有)
【課題】連続データストリームを介してイベントのバッチを受信しイベントのバッチにおけるデータのシリアライズを実行する分散イベント処理システム、方法及びコンピュータ可読媒体を提供する。
【解決手段】システムは、イベントのバッチにおける各イベントの第1の属性の第1のデータタイプを特定し、第1の属性によって表されるデータ値に対して実行する第1のタイプのデータ圧縮を決定する。システムは、第1の属性の第1のデータタイプに基づいて第1の属性によって表されるデータ値に対して実行する第1のタイプのデータ圧縮を決定する。次に、システムは、第1の属性に対するシリアライズされたデータ値の第1のセットを生成し、1つ以上の連続クエリのセットに対してシリアライズされたデータ値の第1のセットを処理することにより、出力イベントの第1のセットを生成する。
【選択図】図7
【特許請求の範囲】
【請求項1】
分散イベント処理システムを用いてイベントの連続データストリームを処理する方法であって、前記方法は、
前記分散イベント処理システムの複数のコンピューティングデバイスのうちのコンピューティングデバイスにおいて、イベントストリームからイベントのバッチを受信するステップを含み、前記イベントストリームは対応付けられたスキーマを有し、前記スキーマは、前記イベントストリームを介して受信する各イベントの1つ以上の属性を特定し、前記コンピューティングデバイスは、前記分散イベント処理システムのコンピューティングノードのクラスタに含まれ、前記コンピューティングノードのクラスタは、前記分散イベント処理システムの前記複数のコンピューティングデバイスの少なくともサブセットを含み、
前記コンピューティングデバイスが、前記イベントのバッチにおける各イベントの前記1つ以上の属性のうちの第1の属性の第1のデータタイプを特定するステップと、
前記コンピューティングデバイスが、前記イベントのバッチにおける各イベントの前記第1の属性によって表されるデータ値に対して実行する第1のタイプのデータ圧縮を決定するステップとを含み、前記第1のタイプのデータ圧縮は、前記第1の属性の前記第1のデータタイプに少なくとも一部基づいて決定され、
前記コンピューティングデバイスが、前記決定に少なくとも一部基づいて、前記第1の属性に対するシリアライズされたデータ値の第1のセットを生成するステップと、
前記コンピューティングデバイスが、前記第1の属性によって表される前記シリアライズされたデータ値の第1のセットを格納するステップと、
前記コンピューティングデバイスが、1つ以上の連続クエリのセットに対して前記第1の属性に対応する前記シリアライズされたデータ値の第1のセットを処理することにより、出力イベントの第1のセットを生成するステップと、
前記コンピューティングデバイスが、前記出力イベントの第1のセットをユーザに送信するステップとを含む、方法。
【請求項2】
前記コンピューティングデバイスが前記シリアライズされたデータ値の第1のセットを処理するステップはさらに、
前記コンピューティングデバイスが、前記シリアライズされたデータ値の第1のセットに少なくとも一部基づいて、前記第1の属性に対応するデシリアライズされたデータ値の第1のセットを生成するステップと、
前記コンピューティングデバイスが、前記1つ以上の連続クエリのセットに対して前記第1の属性に対応する前記デシリアライズされたデータ値の第1のセットを処理することにより、前記出力イベントの第1のセットを生成するステップとを含む、請求項1に記載の方法。
【請求項3】
前記コンピューティングデバイスが前記第1の属性に対応する前記デシリアライズされたデータ値の第1のセットを生成するステップはさらに、
前記コンピューティングデバイスが、前記第1の属性によって表される前記データ値に対して実行する前記第1のタイプのデータ圧縮を特定するステップと、
前記コンピューティングデバイスが、前記第1のタイプのデータ圧縮に従い、前記第1の属性によって表される前記シリアライズされたデータ値の第1のセットをデシリアライズするステップとを含む、請求項2に記載の方法。
【請求項4】
前記コンピューティングデバイスが、前記イベントのバッチにおける各イベントの前記1つ以上の属性のうちの第2の属性の第2のデータタイプを特定するステップをさらに含み、前記第2のデータタイプは前記第1のデータタイプと異なっており、
前記コンピューティングデバイスが、前記イベントのバッチにおけるイベントの前記第
2の属性によって表されるデータ値に対して実行する第2のタイプのデータ圧縮を決定するステップを含み、前記第2のタイプのデータ圧縮は前記第1のタイプのデータ圧縮と異なっており、
前記コンピューティングデバイスが、前記決定に少なくとも一部基づいて、前記第2の属性によって表されるシリアライズされたデータ値の第2のセットを生成するステップと、
前記コンピューティングデバイスが、前記第2の属性によって表される前記シリアライズされたデータ値の第2のセットを格納するステップとを含む、請求項1~3のいずれか1項に記載の方法。
【請求項5】
前記第2のタイプのデータ圧縮は、前記第2の属性の前記第2のデータタイプに少なくとも一部基づいて決定される、請求項4または5に記載の方法。
【請求項6】
前記コンピューティングデバイスが前記シリアライズされたデータ値の第2のセットを処理するステップをさらに含み、前記処理するステップは、
前記コンピューティングデバイスが、前記シリアライズされたデータ値の第2のセットに基づいて前記第2の属性に対応するデシリアライズされたデータ値の第2のセットを生成するステップと、
前記コンピューティングデバイスが、前記1つ以上の連続クエリのセットに対して前記第2の属性に対応する前記デシリアライズされたデータ値の第2のセットを処理することにより、前記出力イベントの第1のセットを生成するステップとを含む、請求項4または5に記載の方法。
【請求項7】
前記第1のタイプのデータ圧縮または前記第2のタイプのデータ圧縮は、ベース圧縮技術、値インデックス圧縮技術、または、精度低減値インデックス圧縮技術のうちの少なくとも1つを含む、請求項4~6のいずれか1項に記載の方法。
【請求項8】
前記コンピューティングデバイスが前記第1の属性に対応する前記シリアライズされたデータ値の第1のセットを処理するステップはさらに、
前記コンピューティングデバイスが、前記1つ以上の連続クエリのセットに基づいて前記イベントのバッチにおける各イベントに対して実行する1つ以上の動作のセットを特定するステップと、
前記コンピューティングデバイスが、前記1つ以上の動作のセットを、変換の連続クエリ言語(CQL)レジリエント分散データセット(RDD)有向非巡回グラフ(DAG)として表すステップと、
前記コンピューティングデバイスが、CQL変換に対して前記第1の属性に対応するシリアライズされたデータ値の第1のセットを処理することにより、出力イベントの第1のセットを生成するステップとを含む、請求項1~7のいずれか1項に記載の方法。
【請求項9】
前記第1の属性の第1のデータタイプは、数値データタイプであり、前記第2の属性の第2のデータタイプは、非数値データタイプである、請求項1~8のいずれか1項に記載の方法。
【請求項10】
1つ以上のプロセッサによって実行されると1つ以上のコンピュータシステムを少なくとも以下の命令を実行するように構成するコンピュータ実行可能命令を格納するコンピュータ可読媒体であって、前記コンピュータシステムは、少なくとも、
前記1つ以上のプロセッサに、分散イベント処理システムの複数のコンピューティングデバイスのうちのコンピューティングデバイスにおいて、イベントストリームからイベントのバッチを受信させる命令を実行し、前記イベントストリームは対応付けられたスキーマを有し、前記スキーマは、前記イベントストリームを介して受信する各イベントの1つ
以上の属性を特定し、前記コンピューティングデバイスは、前記分散イベント処理システムのコンピューティングノードのクラスタに含まれ、前記コンピューティングノードのクラスタは、前記分散イベント処理システムの前記複数のコンピューティングデバイスの少なくともサブセットを含み、さらに、
前記1つ以上のプロセッサに、前記イベントのバッチにおける各イベントの前記1つ以上の属性のうちの第1の属性の第1のデータタイプを特定させる命令と、
前記1つ以上のプロセッサに、前記イベントのバッチにおける各イベントの前記第1の属性によって表されるデータ値に対して実行する第1のタイプのデータ圧縮を決定させる命令とを実行し、前記第1のタイプのデータ圧縮は、前記第1の属性の前記第1のデータタイプに少なくとも一部基づいて決定され、さらに、
前記1つ以上のプロセッサに、前記決定に少なくとも一部基づいて、前記第1の属性に対するシリアライズされたデータ値の第1のセットを生成させる命令と、
前記1つ以上のプロセッサに、前記第1の属性によって表される前記シリアライズされたデータ値の第1のセットを格納させる命令と、
前記1つ以上のプロセッサに、1つ以上の連続クエリのセットに対して前記第1の属性に対応する前記シリアライズされたデータ値の第1のセットを処理することにより、出力イベントの第1のセットを生成させる命令と、
前記1つ以上のプロセッサに、前記出力イベントの第1のセットをユーザに送信させる命令とを実行するように、構成される、構成される、コンピュータ可読媒体。
【請求項11】
前記1つ以上のプロセッサに前記シリアライズされたデータ値の第1のセットを処理させる命令はさらに、
前記1つ以上のプロセッサに、前記シリアライズされたデータ値の第1のセットに少なくとも一部基づいて、前記第1の属性に対応するデシリアライズされたデータ値の第1のセットを生成させる命令と、
前記1つ以上のプロセッサに、前記1つ以上の連続クエリのセットに対して前記第1の属性に対応する前記デシリアライズされたデータ値の第1のセットを処理することにより、前記出力イベントの第1のセットを生成させる命令とを含む、請求項10に記載のコンピュータ可読媒体。
【請求項12】
前記1つ以上のプロセッサに前記第1の属性に対応する前記デシリアライズされたデータ値の第1のセットを生成させる命令はさらに、
前記1つ以上のプロセッサに、前記第1の属性によって表される前記データ値に対して実行する前記第1のタイプのデータ圧縮を特定させる命令と、
前記1つ以上のプロセッサに、前記第1のタイプのデータ圧縮に従い、前記第1の属性によって表される前記シリアライズされたデータ値の第1のセットをデシリアライズさせる命令とを含む、請求項11に記載のコンピュータ可読媒体。
【請求項13】
前記1つ以上のプロセッサに、前記イベントのバッチにおける各イベントの前記1つ以上の属性のうちの第2の属性の第2のデータタイプを特定させる命令をさらに含み、前記第2のデータタイプは前記第1のデータタイプと異なっており、さらに、
前記1つ以上のプロセッサに、前記イベントのバッチにおけるイベントの前記第2の属性によって表されるデータ値に対して実行する第2のタイプのデータ圧縮を決定させる命令を含み、前記第2のタイプのデータ圧縮は前記第1のタイプのデータ圧縮と異なっており、さらに、
前記実行する第2のタイプのデータ圧縮を前記1つ以上のプロセッサに決定させる命令に少なくとも一部基づいて、前記1つ以上のプロセッサに、前記第2の属性によって表されるシリアライズされたデータ値の第2のセットを生成させる命令と、
前記1つ以上のプロセッサに、前記第2の属性によって表される前記シリアライズされたデータ値の第2のセットを格納させる命令とを含む、請求項10~12のいずれか1項
に記載のコンピュータ可読媒体。
【請求項14】
前記第2のタイプのデータ圧縮は、前記第2の属性の前記第2のデータタイプに少なくとも一部基づいて決定される、請求項13に記載のコンピュータ可読媒体。
【請求項15】
前記第1のタイプのデータ圧縮または前記第2のタイプのデータ圧縮は、ベース圧縮技術、値インデックス圧縮技術、または、精度低減値インデックス圧縮技術のうちの少なくとも1つを含む、請求項13または14に記載のコンピュータ可読媒体。
【請求項16】
分散イベント処理システムであって、
複数の命令を格納するメモリと、
前記メモリにアクセスするように構成されたプロセッサとを備え、前記プロセッサはさらに、前記複数の命令を実行することにより、少なくとも、
前記分散イベント処理システムの複数のコンピューティングデバイスのうちのコンピューティングデバイスにおいて、イベントストリームからイベントのバッチを受信し、前記イベントストリームは対応付けられたスキーマを有し、前記スキーマは、前記イベントストリームを介して受信する各イベントの1つ以上の属性を特定し、前記コンピューティングデバイスは、前記分散イベント処理システムのコンピューティングノードのクラスタに含まれ、前記コンピューティングノードのクラスタは、前記分散イベント処理システムの前記複数のコンピューティングデバイスの少なくともサブセットを含み、さらに、
前記イベントのバッチにおける各イベントの前記1つ以上の属性のうちの第1の属性の第1のデータタイプを特定し、
前記イベントのバッチにおける各イベントの前記第1の属性によって表されるデータ値に対して実行する第1のタイプのデータ圧縮を決定し、前記第1のタイプのデータ圧縮は、前記第1の属性の前記第1のデータタイプに少なくとも一部基づいて決定され、さらに、
前記決定をさせる命令に少なくとも一部基づいて、前記第1の属性に対するシリアライズされたデータ値の第1のセットを生成し、
前記第1の属性によって表される前記シリアライズされたデータ値の第1のセットを格納し、
1つ以上の連続クエリのセットに対して前記第1の属性に対応する前記シリアライズされたデータ値の第1のセットを処理することにより、出力イベントの第1のセットを生成し、
前記出力イベントの第1のセットをユーザに送信するように、構成される、分散イベント処理システム。
【請求項17】
前記プロセッサはさらに、前記複数の命令を実行することにより、
前記シリアライズされたデータ値の第1のセットに少なくとも一部基づいて、前記第1の属性に対応するデシリアライズされたデータ値の第1のセットを生成することと、
前記1つ以上の連続クエリのセットに対して前記第1の属性に対応する前記デシリアライズされたデータ値の第1のセットを処理することにより、前記出力イベントの第1のセットを生成することとによって、
前記シリアライズされたデータ値の第1のセットを処理するように構成される、請求項16に記載のシステム。
【請求項18】
前記プロセッサはさらに、前記複数の命令を実行することにより、
前記イベントのバッチにおける各イベントの前記1つ以上の属性のうちの第2の属性の第2のデータタイプを特定し、前記第2のデータタイプは前記第1のデータタイプと異なっており、さらに、
前記イベントのバッチにおけるイベントの前記第2の属性によって表されるデータ値に
対して実行する第2のタイプのデータ圧縮を決定し、前記第2のタイプのデータ圧縮は前記第1のタイプのデータ圧縮と異なっており、さらに、
前記決定をさせる命令に少なくとも一部基づいて、前記第2の属性によって表されるシリアライズされたデータ値の第2のセットを生成し、
前記第2の属性によって表される前記シリアライズされたデータ値の第2のセットを格納するように、構成される、請求項16または17に記載のシステム。
【請求項19】
前記第2のタイプのデータ圧縮は、前記第2の属性の前記第2のデータタイプに少なくとも一部基づいて決定される、請求項18に記載のシステム。
【請求項20】
前記プロセッサはさらに、前記複数の命令を実行することにより、
前記1つ以上の連続クエリのセットに基づいて前記イベントのバッチにおける各イベントに対して実行する1つ以上の動作のセットを特定することと、
前記1つ以上の動作のセットを、変換の連続クエリ言語(CQL)レジリエント分散データセット(RDD)有向非巡回グラフ(DAG)として表すことと、
CQL変換に対して前記第1の属性に対応するシリアライズされたデータ値の第1のセットを処理することにより、出力イベントの第1のセットを生成することとによって、前記シリアライズされたデータ値の第1のセットを処理するように、構成される、請求項16~19のいずれか1項に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
関連出願の相互参照
本願は、米国特許法第119条(e)に従い、2016年9月15日に出願され「FAST
SERIALIZATION OF TUPLE BATCHES」と題された米国仮出願第62/395,216号お
よび2017年9月11日に出願され「DATA SERIALIZATION IN A DISTRIBUTED EVENT PROCESSING SYSTEM」と題された米国非仮出願第15/700,784号に基づく利益およ
び優先権を主張し、各々の内容全体をあらゆる目的のために本明細書に引用により援用する。
【0002】
本願はまた、2017年9月11日に出願され「GRAPH GENERATION FOR A DISTRIBUTED
EVENT PROCESSING SYSTEM」と題された代理人整理番号088325-1043335(177610US)の出願第15/700862号、2017年9月11日に出願され「CLUSTERING EVENT PROCESSING ENGINES」と題された代理人整理番号088325-10
43336(177620US)の出願第15/700914号、および2017年9月11日に出願され「DATA PARTITIONING AND PARALLELISM IN A DISTRIBUTED EVENT PROCESSING SYSTEM」と題された代理人整理番号088325-1043337(177630US)の出願第15/701019号に関連する。米国特許法第120条に基づき、各出願の内容全体を、本明細書に完全に記載されているかのごとく、本明細書に引用により援用する。
【背景技術】
【0003】
背景
従来のデータベースシステムにおいて、データは、通常はテーブルの形態である1つ以上のデータベースに記憶される。そして、記憶されるデータは、構造化照会言語(SQL)などのデータ管理言語を使用して照会および操作される。たとえば、SQLクエリは、データベースに記憶されるデータから関連するデータを識別するために定義および実行され得る。したがって、SQLクエリは、データベースに記憶されるデータの有限集合に対して実行される。さらに、SQLクエリが実行される時、それはひとたび有限データ集合に対して実行され、有限の静的結果(finite static result)を作成する。したがって、データベースは、有限の記憶されるデータ集合に対してクエリを実行するように最良に実装される。
【0004】
しかしながら、いくつかの最新のアプリケーションおよびシステムは、有限のデータ集合の代わりに、連続的なデータまたはイベントのストリームの形態のデータを生成する。このようなアプリケーションの例としては、限定されるものではないが、センサデータアプリケーション、株式相場表示装置、ネットワーク性能測定ツール(たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション)、クリックストリーム分析ツール、自動車トラフィックモニタリングなどが含まれる。このようなアプリケーションは、データストリームを処理することができる新しい種類のアプリケーションの必要を生じさせた。たとえば、温度センサは、温度測定値を発信するように構成され得る。
【0005】
これらのタイプのイベントストリームベースのアプリケーションについてのデータの管理および処理では、厳密な時間によるフォーカスを使用してデータ管理およびクエリ機能が作成される。連続的なデータの非有界集合に対する長期実行クエリ(long-running queries)を含む、異なる種類の照会メカニズムが必要である。現在、一部のベンダーはイベントストリーム処理を目的とした製品スーツを提供しているが、提供されるこれらの製品は、今日のイベント処理の需要に対処するために必要な処理の柔軟性に依然として欠けて
いる。
【発明の概要】
【課題を解決するための手段】
【0006】
簡単な概要
イベントの連続ストリームを介して受信したイベントデータをシリアライズするための技術(たとえば、方法、システム、1つ以上のプロセッサによって実行可能なコードまたは命令を格納する非一時的なコンピュータ可読媒体)が提供される。一実施形態において、連続データストリームを介してイベントのバッチを受信しイベントのバッチにおけるデータのシリアライズを実行するように構成された分散イベント処理システムが開示される。分散イベント処理システムは、連続クエリのセットに対してイベントデータを処理することによって出力イベントのセットを生成するように構成し得る。分散イベント処理システムはさらに、出力イベントのセットを分散イベント処理システムのユーザに送信するように構成し得る。
【0007】
一実施形態において、複数のコンピューティングデバイスを含む分散イベント処理システムが開示される。複数のコンピューティングデバイスのうちのコンピューティングデバイスは、イベントストリームからイベントのバッチを受信するように構成される。イベントストリームは対応付けられたスキーマを有する。スキーマはイベントストリームを介して受信する各イベントの1つ以上の属性を特定する。コンピューティングデバイスは分散イベント処理システムのコンピューティングノードのクラスタに含まれ、コンピューティングノードのクラスタは、分散イベント処理システムの複数のコンピューティングデバイスの少なくともサブセットを含む。
【0008】
特定の実施形態において、コンピューティングデバイスは、イベントのバッチにおける各イベントの1つ以上の属性のうちの第1の属性の第1のデータタイプを特定し、第1の属性によって表されるデータ値に対して実行する第1のタイプのデータ圧縮を決定するように構成される。特定の例において、第1のタイプのデータ圧縮は、第1の属性の第1のデータタイプに基づいて決定される。コンピューティングデバイスは次に、第1の属性に対するシリアライズされたデータ値の第1のセットを生成し、第1の属性によって表されるシリアライズされたデータ値の第1のセットを格納するように構成される。
【0009】
特定の実施形態において、コンピューティングデバイスはさらに、1つ以上の連続クエリのセットに対して第1の属性に対応するシリアライズされたデータ値の第1のセットを処理することにより、出力イベントの第1のセットを生成するように構成される。コンピューティングデバイスは次に、出力イベントの第1のセットをユーザに送信するように構成される。
【0010】
いくつかの実施形態において、コンピューティングデバイスは、シリアライズされたデータ値の第1のセットに基づいて、第1の属性に対応するデシリアライズされたデータ値の第1のセットを生成し、1つ以上の連続クエリのセットに対して第1の属性に対応するデシリアライズされたデータ値の第1のセットを処理することにより、出力イベントの第1のセットを生成するように構成される。
【0011】
いくつかの実施形態において、コンピューティングデバイスは、第1の属性によって表されるデータ値に対して実行する第1のタイプのデータ圧縮を特定することと、第1のタイプのデータ圧縮に従い、第1の属性によって表されるシリアライズされたデータ値の第1のセットをデシリアライズすることとによって、第1の属性に対応するデシリアライズされたデータ値の第1のセットを生成するように、構成される。
【0012】
いくつかの実施形態において、コンピューティングデバイスは、イベントのバッチにおける各イベントの第2の属性の第2のデータタイプを特定するように構成される。一例において、第2のデータタイプは第1のデータタイプと異なっている。コンピューティングデバイスは、イベントのバッチにおけるイベントの第2の属性によって表されるデータ値に対して実行する第2のタイプのデータ圧縮を決定するように構成される。一例において、第2のタイプのデータ圧縮は第1のタイプのデータ圧縮と異なっている。コンピューティングデバイスは、第2のタイプのデータ圧縮の決定に基づいて、第2の属性によって表されるシリアライズされたデータ値の第2のセットを生成し、第2の属性によって表されるシリアライズされたデータ値の第2のセットを格納するように、構成される。いくつかの例において、第2のタイプのデータ圧縮は、第2の属性の第2のデータタイプに基づいて決定される。
【0013】
いくつかの実施形態において、コンピューティングデバイスは、シリアライズされたデータ値の第2のセットに基づいて第2の属性に対応するデシリアライズされたデータ値の第2のセットを生成し、1つ以上の連続クエリのセットに対して第2の属性に対応するデシリアライズされたデータ値の第2のセットを処理することにより、出力イベントの第1のセットを生成するように、構成される。
【0014】
いくつかの例において、第1のタイプのデータ圧縮または第2のタイプのデータ圧縮は、ベース圧縮技術、値インデックス圧縮技術、または、精度低減値インデックス圧縮技術のうちの少なくとも1つを含む。
【0015】
特定の実施形態において、コンピューティングデバイスは、1つ以上の連続クエリのセットに基づいてイベントのバッチにおける各イベントに対して実行する1つ以上の動作のセットを特定することと、1つ以上の動作のセットを、変換の連続クエリ言語(CQL)レジリエント分散データセット(RDD)有向非巡回グラフ(DAG)として表すことと、変換のCQL RDD DAGに対して第1の属性に対応するシリアライズされたデータ値の第1のセットを処理することにより、出力イベントの第1のセットを生成することとによって、第1の属性に対応するシリアライズされたデータ値の第1のセットを処理するように、構成される。
【0016】
いくつかの例において、第1の属性の第1のデータタイプは、数値データタイプであり、第2の属性の第2のデータタイプは、非数値データタイプである。
【0017】
上記および下記の技術は、多くの方法で、および多くの状況で実施することができる。以下でより詳細に説明するように、いくつかの例示的な実現例および状況が、以下の図を参照して提供される。しかしながら、以下の実現例および状況は多くのもののうちのほんの一部である。
【図面の簡単な説明】
【0018】
図1】本開示の実施形態に係る、異なる実行環境でイベント処理アプリケーションを処理できる環境を提供するイベント処理システムアーキテクチャの一例の局面を示す図である。
図2】本開示の実施形態に係る、イベント処理アプリケーションのためのイベント処理ネットワーク(EPN)を図示する図である。
図3】本開示の実施形態に係る、アプリケーション処理エンジンのコンポーネントを示す簡略化されたブロック図である。
図4】本開示の実施形態に係る、共通アプリケーションモデルジェネレータによって生成された「共通アプリケーションランタイムモデル」を表現したものの一例を示す図である。
図5】本開示の実施形態に係る、DAGジェネレータが生成したコンポーネントのランタイム有向非巡回グラフ(DAG)の一例を示す図である。
図6】本開示の実施形態を組み込むことが可能なイベント処理システムの簡略化されたハイレベル図である。
図7】本開示の実施形態に係る、分散イベント処理システムのコンポーネントを示すブロック図である。
図8】本開示の一実施形態に係る、アプリケーションの共通アプリケーションランタイムモデルを生成するためにイベント処理アプリケーションを処理するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図9】本開示の別の実施形態に係る、アプリケーションの共通アプリケーションランタイムモデルを生成するためにイベント処理アプリケーションを処理するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図10】本開示の実施形態に係る、分散イベント処理システムのコンポーネントを示す簡略化されたブロック図である。
図11】本開示の実施形態に係る、レジリエント分散データセット(RDD)オブジェクトにおけるデータのシリアライズおよびデシリアライズを実行するためのプロセスのハイレベルデータフローを示す図である。
図12】本開示の実施形態に係る、イベントのバッチに含まれるデータをシリアライズできる一組の動作を説明するプロセスのフロー図の一例を示す図である。
図13A】本開示の実施形態に係る、イベントの数値属性のシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図13B】本開示の実施形態に係る、精度低減圧縮技術を用いてイベントの数値属性のシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図13C】本開示の実施形態に係る、通常の圧縮技術を用いてイベントの数値属性のシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図13D】本開示の実施形態に係る、精度低減値インデックス圧縮技術を用いてイベントの数値属性のシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図14】本開示の実施形態に係る、イベントの非数値属性のシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図15】本開示の実施形態に係る、イベントストリームにおけるイベントの属性のデータタイプの判断に基づいてイベントストリームデータをシリアライズできる手法の一例を示す図である。
図16】本開示の実施形態に係る、イベントのバッチに含まれるデータをデシリアライズできる一組の動作を説明するプロセスのフロー図の一例を示す図である。
図17】本開示の実施形態に係る、イベントのバッチにおけるイベントの1つ以上の属性のデシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図18】本開示の実施形態に係る、値インデックス圧縮を用いてイベントのバッチにおけるイベントの数値属性または非数値属性に対応する、デシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図19】本開示の実施形態に係る、精度低減圧縮技術を用いてイベントのバッチにおけるイベントの数値属性に対応する、デシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図20】本開示の実施形態に係る、イベントのバッチにおけるイベントの数値属性に対応する、デシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図21】本開示の実施形態に係る、イベントのバッチにおけるイベントの数値属性に対応する、デシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図22】本開示の実施形態に係る、複数のCEPエンジンをスケジューリングし管理するために構成された分散イベント処理システムのコンポーネントを示す簡略化されたブロック図である。
図23】本開示の実施形態に係る、複数のCEPエンジンをスケジューリングし管理するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図24】本開示の実施形態に係る、データのパーティショニングおよびパラレル処理のために構成された分散イベント処理システムのコンポーネントを示す簡略化されたブロック図である。
図25】本開示の実施形態に係る、クエリ句およびオブジェクトIDを用いてデータを自動的にパーティショニングおよびパラレル処理するための一組の動作を説明するプロセスのフロー図の一例を示す図である。
図26】本開示の実施形態を実装するための分散システムの簡略化されたブロック図を示す。
図27】本開示の実施形態に係る、実施形態のシステムの1つ以上のコンポーネントが提供するサービスをクラウドサービスとして提供することを可能にするシステム環境の1つ以上のコンポーネントの簡略化されたブロック図である。
図28】本開示の実施形態を実装するために使用することが可能なコンピュータシステムの一例を示す図である。
【発明を実施するための形態】
【0019】
詳細な説明
以下の説明では、さまざまな実施形態について説明する。説明のために、具体的な構成および詳細は、実施形態の完全な理解を提供するために記載される。しかしながら、実施形態が具体的な詳細なしに実施されてもよいことも、当業者には明らかであろう。さらに、周知の特徴は、説明される実施形態を不明瞭にしないために省略または簡略化されてもよい。
【0020】
複合イベント処理(CEP)の概要
複合イベント処理(Complex Event Processing)(CEP)は、イベント駆動型アーキテクチャに基づいてアプリケーションを構築するためのモジュール式プラットフォームを提供する。CEPプラットフォームの中心には、アプリケーションが宣言型SQL状言語を使用してデータのストリームに対してパターンマッチング操作をフィルタリング、照会および実行できるようにする連続問い合わせ言語(Continuous Query Language)(CQ
L)がある。開発者はアプリケーションを書くためにCQLを軽量なJava(登録商標)プログラミングモデルと組み合わせて使用できる。他のプラットフォームモジュールには、機能豊富なIDE、管理コンソール、クラスタ化、分散キャッシュ化、イベントリポジトリ、およびモニタリングなどがある。
【0021】
イベント駆動型アーキテクチャおよび複合イベント処理はエンタープライズコンピューティング環境の顕著な機能となっているため、CEP技術を使用してミッションクリティカルなアプリケーションを構築し始めている企業が増えている。今日、ミッションクリティカルなCEPアプリケーションは、さまざまな業界で見出され得る。たとえば、CEP技術は、電力産業においては、電気需要の変化に瞬時に反応できるようにすることにより、ユーティリティをより効率的にするために使用されている。CEP技術は、クレジットカード業界では、潜在的に不正な取引がリアルタイムで発生した場合にそのような取引を
検出するために使用されている。ミッションクリティカルなCEPアプリケーションのリストは増加を続けている。ミッションクリティカルなアプリケーションを構築するためにCEP技術を使用することにより、CEPアプリケーションの高可用性とフォールトトレラント化が求められるに至った。
【0022】
今日の情報技術(IT)環境は、金融市場およびネットワークパフォーマンスのモニタリングから、ビジネスプロセスの実行およびRFTDタグ付き資産のトラッキングまで、あらゆることに対して連続したデータのストリームを生成する。CEPは、ビジネス処理の有効性を向上させるためにイベント処理アプリケーションを開発するための豊富で宣言的な環境を提供する。CEPは、複数のイベントストリームを処理してパターンおよび傾向をリアルタイムで検出して、企業に対して、新たな機会を活用したり開発リスクを軽減したりするために必要な可視性を提供する。
【0023】
連続したデータのストリーム(イベントストリームとも呼ばれる)は、明示的な終了のない事実上連続的または非有界であってもよいデータまたはイベントのストリームを含むことができる。論理的に、イベントまたはデータストリームは、データ要素(イベントともいわれる)のシーケンスであり得て、各データ要素は、関連付けられたタイムスタンプを有する。連続イベントストリームは、要素のバッグまたはセット(s,T)として論理的に表わされ得て、ここで「s」はデータ部分を表わし、「T」は時間ドメインに属する。「s」部分は、概してタプルまたはイベントといわれる。したがって、イベントストリームは、タイムスタンプを持つタプルまたはイベントのシーケンスであり得る。
【0024】
一部の局面において、ストリームにおけるイベントに関連付けられるタイムスタンプは、クロックタイムと同等とされ得る。しかしながら、他の例において、イベントストリームにおけるイベントに関連付けられる時間は、アプリケーションドメインによって定義され得て、クロックタイムに対応しない場合があるが、たとえば、代わりにシーケンス番号によって表わされ得る。このため、イベントストリームにおけるイベントに関連付けられる時間情報は、数字、タイムスタンプ、または時間の概念を表わす他の情報によって表され得る。入力イベントストリームを受信するシステムについては、イベントは、タイムスタンプの増加順でシステムに到達する。同じタイムスタンプを有する2つ以上のイベントがあり得る。
【0025】
一部の例において、イベントストリームにおけるイベントは、いくぶん世俗的なイベント(たとえば、温度センサが値を新しい値に変更した場合や、株式表示記号の価格が変化した場合など)の発生を表わし得て、イベントに関連付けられる時間情報は、データストリームイベントによって表わされる世俗的なイベントが発生した場合を示し得る。
【0026】
イベントストリームを介して受信したイベントについては、イベントストリームにおけるイベントが確実にタイムスタンプ値の増加順で到達するように、イベントに関連付けられる時間情報が使用され得る。これにより、イベントストリームにおいて受信されたイベントを、それらに関連付けられる時間情報に基づいて順序付けることができる。この順序付けを可能にするために、後に生成されるイベントが前に生成されるイベントよりも後のタイムスタンプを有するように、タイムスタンプがイベントストリームにおけるイベントに対して非減少の態様で関連付けられ得る。他の例として、シーケンス番号が時間情報として使用されている場合、後に生成されるイベントに関連付けられるシーケンス番号は、前に生成されるイベントに関連付けられるシーケンス番号よりも大きくなり得る。一部の例において、たとえばデータストリームイベントによって表される世俗的なイベントが同時に発生した場合に、複数のイベントが、同じタイムスタンプまたは同じシーケンス番号に関連付けられ得る。同じイベントストリームに属するイベントは、概して、関連付けられる時間情報によってイベントに対して加えられる順序で処理され得て、前のイベントは
後のイベントの前に処理される。
【0027】
イベントストリームにおけるイベントに関連付けられる時間情報(たとえば、タイムスタンプ)は、ストリームのソースによって設定され得る、または代替的にストリームを受信するシステムによって設定され得る。たとえば、特定の実施形態において、イベントストリームを受信するシステムに対してハートビートが維持され得て、イベントに関連付けられる時間は、ハートビートによって測定されるようにシステムへのイベントの到達の時間に基づき得る。イベントストリームにおける2つのイベントが同じ時間情報を有することは可能である。なお、タイムスタンプ順序付け要件は1つのイベントストリームに対して特定のものであるが、異なるストリームのイベントが適宜インターリーブされ得る。
【0028】
イベントストリームは、関連付けられるスキーマ「S」を有し、スキーマは、時間情報と、1つ以上の指定される名前付き属性の集合とを含む。特定のイベントストリームに属するすべてのイベントは、その特定のイベントストリームに関連付けられるスキーマに準拠する。このため、イベントストリーム(s,T)については、イベントストリームは、スキーマ「S」を(<time_stamp>,<attribute(s)>)として有し得て、ここで<attributes>
は、スキーマのデータ部分を表わし、1つ以上の属性を含み得る。たとえば、株式相場表示装置イベントストリームについてのスキーマは、<stock symbol>および<stock price>
の属性を含み得る。このようなストリームを介して受信される各イベントは、タイムスタンプと2つの属性とを有する。たとえば、株式相場表示装置イベントストリームは、以下のイベントおよび関連付けられるタイムスタンプを受け取り得る。
【0029】

(<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」である。したがって、
連続イベントストリームはイベントのフローであり、各イベントは同じ一連の属性を有する。
【0030】
記載したように、ストリームはCQLクエリが作用し得るデータの主要なソースであり得る。ストリームSは、要素(s,T)のバッグ(「マルチセットともいわれる)であり得て、ここで「s」はSのスキーマに属し、「T」は時間ドメインに属する。加えて、ス
トリーム要素は、タプルとタイムスタンプのペアであり得て、タイムスタンプを持つタプル挿入のシーケンスとして表わされ得る。言い換えると、ストリームは、タイムスタンプを持つタプルのシーケンスであり得る。一部の場合において、同じタイムスタンプを有する2つ以上のタプルがあり得る。加えて、入力ストリームのタプルは、タイムスタンプの増加順でシステムに到達する必要があり得る。代替的に、リレーション(「時間で変化するリレーション」ともいわれ、リレーショナルデータベースからのデータを含み得る「リレーショナルデータ」と混同されない)は、時間ドメインからスキーマRのタプルの非有界バッグへのマッピングであり得る。一部の例において、リレーションは、順序付けされていない、時間で変化するタプルのバッグ(すなわち、瞬間的なリレーション)であり得る。一部の場合において、時間の各瞬間では、リレーションは有界集合であり得る。これは、挿入、消去、および/または更新を含んでリレーションの変化する状態を捕捉し得る
、タイムスタンプを持つタプルのシーケンスとしても表わされ得る。ストリームと同様に、リレーションは、リレーションの各タプルが準拠し得る固定スキーマを有し得る。さらに、本願明細書で使用される連続クエリは、概してストリームおよび/またはリレーションのデータを処理する(すなわち、照会する)ことが可能であり得る。加えて、リレーションは、ストリームのデータを参照し得る。
【0031】
イベント処理アプリケーション
ローインフラストラクチャおよびビジネスイベントの両方の量ならびに速度は、IT環境で急激に増加している。それは、金融サービスのために株式データをストリーミングするのであれ、軍事用に衛星データをストリーミングするのであれ、運輸および物流ビジネスのためにリアルタイムの車両位置データをストリーミングするのであれ、複数の業界の企業が大量の複雑なデータをリアルタイムで処理しなければならない。さらに、モバイル機器の急増および高速接続の普及は、モバイルデータの急増を助長する。同時に、ビジネスプロセスの俊敏性および実行に対する需要も高まっている。これら2つの傾向は、組織に対して、組織の、実装のイベント駆動型アーキテクチャパターンをサポートする能力を高めるよう、圧力をかけている。リアルタイムのイベント処理では、インフラストラクチャおよびアプリケーション開発環境の両方がイベント処理要件を実行する必要がある。これらの要件には、おそらくは秒単位ではなくマイクロ秒単位の応答時間で測定されるレイテンシで日常のユースケースから非常に高速のデータおよびイベントのスループットへ基準化するニーズが含まれることがよくある。さらに、イベント処理アプリケーションは、これらのイベントの流れの中で複雑なパターンを検出しなければならないことがよくある。
【0032】
Oracle Stream Analyticsプラットフォームは、多くの業界と機能分野をターゲットと
している。以下は、いくつかのユースケースである。
【0033】
電気通信:リアルタイム呼詳細(CDR)レコードモニタリングおよび分散型サービス妨害攻撃検出を実行する能力。
【0034】
金融サービス:ミリ秒またはマイクロ秒のウィンドウ内に存在する裁定機会を利用する能力。金融証券取引のリアルタイムのリスク分析、モニタリングおよび報告を実行し、外国為替価格を計算する能力。
【0035】
運輸:地方または目的地の都市の天候、地上業務員のオペレーション、空港のセキュリティなどによる飛行の不具合が発生した場合に、旅客警報を発令して手荷物の場所を検出する能力。
【0036】
公共部門/軍:分散した地理上の敵の情報を検出し、それを抽象化し、高確率の敵の攻
撃を解読する能力。緊急事態に対応するために最も適切なリソースに警告する能力。
【0037】
保険:潜在的に不正な請求を学習し、検出する能力。
ITシステム:故障したアプリケーションやサーバをリアルタイムで検出し、是正措置をトリガする能力。
【0038】
サプライチェーンおよび物流:リアルタイムで出荷を追跡し、潜在的な到着の遅れを検出して報告する能力。
【0039】
リアルタイムストリーミングおよびイベント処理分析
接続デバイス数の増加によるデータの爆発的増加に伴い、大量の動的に変化するデータが増加しており、データは組織内だけでなく、ファイアウォールの外側にも移動する。高
速データは、特に変わり易いビジネスプロセスに高い価値をもたらす。しかしながら、このデータの一部は短い時間枠でその運用上の価値を失う。ビッグデータは、有効な洞察のための処理において時間的な余裕がある。一方、ファストデータでは、非常に動的で戦略的なデータから最大値を抽出する必要がある。それははるかに速く処理することを必要とし、生成されたデータのできるだけ近くでタイムリーなアクションをとることを容易にする。Oracle Stream Analyticsプラットフォームは、即応性のあるファストデータを実現
する。Oracle Edge Analyticsは、リアルタイムで実践的な洞察を得るために、ネットワ
ークエッジに対するデータの処理、相関付け、フィルタリング、および分析をプッシュする。
【0040】
Oracle Stream Analyticsプラットフォームは、着信ストリーミングイベントを永続デ
ータと結合する機能を提供し、それによってコンテキストを意識したフィルタリング、相関付け、集約およびパターンマッチングを実現する。それは、一般的なイベントソースのために、軽量で、そのまま使用できるアダプタを提供する。それは、カスタムアダプタ開発用の使いやすいアダプタフレームワークも提供する。このプラットフォームで、組織は、機会と、一見無関係のイベントによって表される脅威とを識別し、予測することができる。その増分処理パラダイムは、最小量のリソースを使用してイベントを処理することができ、極端に低いレイテンシの処理を可能にする。それはまた、それが、非常にタイムリーな警報を発令し、次のような紛失イベントや遅延イベントを即座に検出することを可能にする。
【0041】
相関付けられたイベント:イベントAが発生した場合、イベントBはほぼ常にそれの後2秒以内に発生する。
【0042】
紛失イベントまたはシーケンス外イベント:イベントA、B、Cは順番に発生するべきである。CはAの直後に、Bなしで見られる。
【0043】
原因となるイベント:製造品目の重量がゆっくりと低下する傾向にあるか、または読み取り値が許容基準外である。これは潜在的な問題または将来のメンテナンスの必要性を示している。
【0044】
リアルタイムのイベントソーシングに加えて、Oracle Stream Analyticsプラットフォ
ーム設計環境およびランタイム実行は、イベントストリームとデータベースや高性能データグリッドなどの永続データストアとの両方にわたる標準ベースの連続クエリ実行をサポートする。これにより、プラットフォームは、他の態様では気付かれないであろうパターンおよび傾向を識別するためにマイクロ秒単位または分単位で回答を必要とするシステムに対するインテリジェンスの中心として機能することができる。イベント処理のユースケースでは、標準データベースSQLの数学的精度および信頼性を備えたインメモリ処理の速度が必要である。このプラットフォームクエリは、着信イベントストリームをリスニングし、クエリ最適化のための高度な自動化されたアルゴリズムを利用して、登録されたクエリを各イベントについてインメモリで継続的に実行する。インメモリ実行モデルに基づいているが、このプラットフォームはクエリ開発に標準のANSI SQL構文を利用しているため、クエリ構築の正確性および拡張性が保証される。このプラットフォームは、ANSI SQL’99規格に完全に準拠しており、リアルタイムの連続クエリパターンマッチングのために標準SQLに対するANSI SQLレビュー拡張をサポートするべく業界で利用可能な最初の製品の1つである。CQLエンジンはプロセッサ内のクエリの実行を最適化し、開発者は最適化よりもビジネスロジックに集中するようになる。
【0045】
Oracle Stream Analyticsプラットフォームでは、SQLおよびJavaコードの両方
を組み合わせて、堅牢なイベント処理アプリケーションを提供できる。標準の業界用語を
利用してイベントソース、プロセッサ、およびイベント出力またはシンクを記述して、このプラットフォームは、アプリケーション内でイベントを定義および操作するためにメタデータ駆動型のアプローチを提供する。その開発者は、アプリケーションの設計に視覚的な有向グラフのキャンバスおよびパレットを用いて、イベントの流れおよびイベントとデータソースとの両方にわたる処理を迅速に概説する。ドラッグアンドドロップモデリングおよび設定ウィザードを介してフローを開発して、開発者は、次いで、適切なメタデータ定義を入力して設計を実装に結び付けることができる。必要または好まれる場合には、次いで、ワンクリックで、開発者は、カスタムJavaコード開発に立ち寄ること、またはSpring(登録商標)フレームワークを直接使用して高度な概念を彼らのアプリケーションにコーディングすることができる。
【0046】
イベント駆動型アプリケーションは、非常に高速のストリーミング入力データを処理しながら、低くかつ決定論的なレイテンシを与えることに対するニーズによって特徴付けられることがよくある。Oracle Stream Analyticsプラットフォームの基盤は、OSGi(
登録商標)バックプレーンに基づく軽量のJavaコンテナである。それは、セキュリティ、ロギング、および作業管理アルゴリズムなど、WebLogic JEEアプリケーションサーバからの成熟したコンポーネントが含むが、リアルタイムのイベント処理環境でそれらのサービスを利用する。統合されたリアルタイムカーネルは、独自のサービスを提供して、JMXフレームワークによってサポートされるスレッドおよびメモリ管理を最適化し、パフォーマンスおよび構成のためにコンテナとの対話を可能にする。Web2.0リッチインターネットアプリケーションはHTTPパブリッシュおよびサブスクライブサービスを用いてプラットフォームと通信でき、これにより、それらは、アプリケーションチャネルにサブスクライブし、イベントをクライアントにプッシュされることができる。フットプリントが小さいため、このプラットフォームは軽量のJavaベースのコンテナであり、製品化までの時間がより速くなり、総オーナーシップコストが削減される。
【0047】
Oracle Stream Analyticsプラットフォームには、標準の商品ハードウェア上でマイク
ロ秒の処理レイテンシで、またはOracle Exalogicおよびその他の工学システムのそのポ
ートフォリオで最適に、毎秒数百万のイベントを処理する機能がある。これは、高性能イベント処理のユースケースに設計重点を置いただけでなく、エンタープライズクラスのリアルタイム処理インフラストラクチャコンポーネントとの緊密な統合で、完全な「トップダウン」の階層化されたソリューションを通して達成される。パフォーマンス指向のサーバクラスタのプラットフォームアーキテクチャは、Oracle Coherence技術への緊密な統合で、信頼性、故障許容、および非常に高い柔軟性に重点を置き、企業はデータグリッド全体に渡ってミッションクリティカルなアプリケーションを予測可能に基準化でき、継続的なデータの可用性およびトランザクションの保全性を確保できる。
【0048】
さらに、このプラットフォームでは決定論的処理が可能であり、つまり、同じイベントを異なるレートで複数のサーバまたは同じサーバに供給して、毎回同じ結果を得ることができる。これにより、稼働中のサーバのシステムクロックにのみ依存するシステムに対して驚くべき利点が得られる。
【0049】
上記および下記の技術は、いくつかの方法およびいくつかの状況において実施され得る。以下においてより詳細に記載されるように、いくつかの例示的な実施および状況が以下の図面を参照して提供される。しかしながら、以下の実施および状況は多くのうちの一部である。
【0050】
分散イベント処理
特定の状況において、企業のユーザは、企業内で生じる重要なイベントを素早く特定しそれに反応することで、このようなイベントを特定すると直ちに対応策を取ることができ
るようにすることを望む場合がある。たとえば、ユーザは、企業内の限界値を超えた販売注文に関連する重要なイベントを特定することを望む場合がある。このようなシナリオにおいて、ユーザは、データストア/データウェアハウスに対して1つ以上のクエリを提出し、数分または数時間ではなく数秒以内にクエリの結果を閲覧し、異常が検出された場合は直ちに対応策を取ることができるようにすることを望む場合がある。企業は、リアルタイムのデータ処理およびデータ解析を用いることにより、より多くの意思決定を行うためにリアルタイムでイベントストリームを処理し、数秒または数分で行動を起こすことが重要なときは直ちに対応策を取ることができるようにする場合がある。
【0051】
本開示の実施形態に従い、CEPと分散イベントストリーム処理との組み合わせを用いて比較的素早くかつリアルタイムで非常に多くの量のデータを処理またはクエリすることができる分散イベント処理システムが開示される。分散イベント処理システムは、連続して受信したデータストリーム(たとえばライブフィード)に対してクエリ(たとえばCQLクエリ)を実行することにより、データストリームをリアルタイムで処理することができる。分散イベント処理システムは、1つ以上の連続データストリームを受信し、データストリームに対する連続クエリを登録し、ストリーム内に新たなデータが現れるとクエリを連続的に実行することができる。この種の連続クエリは実行時間が長いので、分散イベント処理システムは、ユーザに対して結果の連続ストリームを提供することができる。
【0052】
特定の実施形態において、開示されている分散イベント処理システムは、このシステム内のマシンのクラスタにアプリケーションの実行を分散させることにより、アプリケーション(たとえばイベント処理アプリケーション)をデプロイし実行するように構成し得る。本明細書に記載のイベント処理アプリケーションは、入力ストリームを処理するために使用される連続クエリの形態で表現することが可能な一組のルールを含み得る。連続クエリは、受信したイベントに対して実行すべき処理を特定する命令(たとえばロジック)を含み得る。これは、注目すべきイベントとしてどのようなイベントを選択しクエリ処理の結果として出力すべきかを含む。連続クエリは一般的に、フィルタリングおよびアグリゲーション機能を実行することにより、入力イベントストリームから注目すべきイベントを発見して抽出することが可能である。アプリケーションは、1つ以上の入力イベントストリームをリッスンし、1つ以上の入力イベントストリームから1つ以上の注目すべきイベントを選択するためにロジック(たとえばクエリ)を実行し、1つ以上の出力イベントストリームを介して、選択した注目すべきイベントを出力するように構成することができる。
【0053】
たとえば、イベント処理アプリケーションは、一組の入力テキストの中の特定のワードに対するリファレンスの量をカウントするワードカウントアプリケーションを含み得る。このようなアプリケーションは、たとえば、一組のテキストを読み取り、各テキスト内に各ワードが現れる回数をカウントする連続クエリを含み得る。入力テキストは、たとえば、Facebook(登録商標)またはTwitter(登録商標)等のオンラインアプリケーションか
らのストリームにおいて受信したショートメッセージを含み得る。上述のように、連続クエリはCQL言語を用いて構成することが可能である。たとえば、ワードカウントストリーミングアプリケーションにおいて実行すべきワードカウントタスク/動作を指定するために、ユーザは、FROM location GROUP BY word SELECT countといった形態を取ることができるCQLクエリを書き込むことができる。このようなクエリは、指定された場所からすべてのセンテンスを集め、これらのセンテンスから得た固有のワードを異なるグループに分けてから、各グループ内のワードの量をカウントすることができる。
【0054】
アプリケ-ションの実行をマシンのクラスタに分散させることにより、開示されている
分散イベント処理システムを、アプリケーションの実行に関連する結果をユーザに対して素早くかつリアルタイムで提供するように構成することが可能である。分散イベント処理
システムは、アプリケーションに関連するデータを別々のコンピューティングノードにパーティションするように構成することが可能であり、各コンピューティングノードは、別のコンピュータマシン上において別のファイルとして維持することができる。このような各マシンは、アプリケーション内のクエリを、その他のマシンと並列に、上記マシン上において維持されるデータに対し、実行するように構成することができる。
【0055】
分散イベント処理システムのための効率的なDAGの生成
本開示の特定の実施形態において、アプリケーション(たとえばイベント処理アプリケーション)に関する情報を処理するためのアプリケーション処理エンジンが開示される。アプリケーション処理エンジンは、イベント処理アプリケーションを特定する情報を受信するように構成される。特定の例において、イベント処理アプリケーションは、コンポーネントのイベント処理ネットワーク(Event Processing Network)(EPN)として表現され、イベント処理アプリケーション情報を特定する情報は、イベント処理アプリケーションの各種コンポーネント(たとえば、アダプタ、プロセッサ、ストリーム、またはイベントビーン(bean))に関する情報を含む。たとえば、イベント処理アプリケーションを特定する情報は、イベントに関する、構成情報、クエリ情報、およびその他の種類の情報を含み得る。
【0056】
特定の実施形態において、アプリケーション処理エンジンは、アプリケーションを特定する情報を処理しこのアプリケーションの「共通アプリケーションランタイムモデル」を生成するように構成し得る。本明細書に記載のように、アプリケーションの「共通アプリケーションランタイムモデル」は、1つ以上の構成ブロックのセットとしてアプリケーションを表現したものであり、各構成ブロックは処理ステージを表し、対応するメタデータがアプリケーションを記述する。アプリケーション処理エンジンは、アプリケーションの「共通アプリケーションランタイムモデル」を、アプリケーションの1つ以上のジェネリック表現に変換するように構成し得る。そうすると、アプリケーション処理エンジンは、異なるターゲットイベント処理システムがサポートする異なる実行(ランタイム)環境においてアプリケーションの1つ以上のジェネリック表現を実行させるように構成することができる。
【0057】
本開示の実施形態に従って「共通アプリケーションランタイムモデル」を生成することにより、ターゲットエンジンにおけるその実行に先立ってターゲットエンジンの特定の物理実行(ランタイム)環境に適するようにアプリケーションコードをアプリケーションの開発者(たとえばユーザ)が再度書き込まなくても、異なる物理実行(ランタイム)環境においてアプリケーションのジェネリック表現を実行することができる。
【0058】
上記技術はいくつかのやり方でいくつかのコンテキストにおいて実装することが可能である。以下では、イベント処理アプリケーションのデプロイ、処理、および実行に関する動作を開示される分散イベント処理システムが実行し得る手法のさらに他の詳細を記載している図1図9を参照しながら、実装およびコンテキストのいくつかの例を提供する。
【0059】
図1は、本開示の実施形態に係る、異なる実行環境でイベント処理アプリケーションを処理できる環境を提供する、一例としてのイベント処理システムアーキテクチャ100の局面を示す。ある実施形態において、このアーキテクチャ(イベント処理システム)100は、ネットワーク108を介して1つ以上のユーザデバイス102に通信可能に接続されたアプリケーション処理エンジン110を含む。
【0060】
ネットワーク108は、ユーザデバイス102とアプリケーション処理エンジンとの間におけるデータの通信およびやりとりを容易にすることが可能である。ネットワーク108は、TCP/IP、SNA、IPX、AppleTalk(登録商標)等を含むがこれらに限定
されないさまざまな商用プロトコルのうちのいずれかを用いてデータ通信をサポートできる、当業者によく知られたいずれかのタイプのネットワークであればよい。ほんの一例として、ネットワーク108は、イーサネット(登録商標)ネットワークやトークンリングネットワークおよび/または同様のネットワーク等の、ローカルエリアネットワーク(LAN)であってもよく、ワイドエリアネットワークであってもよく、仮想プライベートネットワーク(VPN)を含むがこれに限定されない仮想ネットワークであってもよく、インターネット、イントラネット、エクストラネット、公衆交換電話網(PSTN)、赤外線ネットワーク、無線ネットワーク(たとえば、IEEE802.1Xプロトコルスイート、当該技術において周知のBluetooth(登録商標)、および/またはその他任意の無線
プロトコル)、および/またはこれらおよび/またはその他のネットワークの任意の組み合わせであってもよい。
【0061】
ユーザデバイス102は、汎用パーソナルコンピュータ(一例として、各種バージョンのMicrosoft Windows(登録商標)および/またはApple Macintosh(登録商標)のオペレーティングシステムを実行するパーソナルコンピュータおよび/またはラップトップコンピュータを含む)、携帯電話もしくはPDA(Microsoft Windows Mobile等のソフトウェアを実行し、インターネット、電子メール、SMS、Blackberry(登録商標)もしくはその他の通信プロトコルに対応する)、各種商用UNIX(登録商標)もしくはUNIX系オペレーティングシステム(各種GNU/Linux(登録商標)オペレーティングシステムを含むがこれらに限定されない)を実行するワークステーションコンピュータ、または、その他任意のコンピューティングデバイスであってもよい。たとえば、ユーザデバイス102は、ネットワーク(たとえばネットワーク108)を介して通信可能な、シンクライアントコンピュータ、インターネット対応ゲームシステム、および/またはパーソナルメッセージングデバイス等の、その他任意の電子デバイスであってもよい。一例としてのシステム環境100は1つのユーザデバイスとともに示されているが、その他の実施形態では任意の数のユーザおよび/またはクライアントコンピューティングデバイスをサポートすることが可能である。
【0062】
特定の実施形態において、アプリケーション処理エンジン110は、異なるランタイム環境における実行のためにイベント処理アプリケーションを処理するように構成し得る。特定の例において、イベント処理アプリケーションは、ユーザデバイス102のユーザによって生成されてもよい。たとえば、ユーザ102は、クライアントアプリケーション104が提供するアプリケーション設計ユーザインターフェイス106を用いて、ユーザデバイス内にクライアントアプリケーション104(たとえばブラウザ)を用いるアプリケーション(たとえばイベント処理アプリケーション)を構築することができる。上述のように、イベント処理アプリケーションは、イベントソースからのデータの入力ストリームを処理するために使用される一組のルール(たとえば連続クエリの形態で表現される)を含み得る。イベントソースは、モニタリングデバイス、金融サービス企業、または自動車両等の各種データソースを含み得る。このデータを用いて、イベント処理アプリケーションは、パターンを特定してこのパターンに反応する、異常なイベントを探してその他のアプリケーションに警告する、または、急速に変化するデータに基づいて即時の処置を必要とするその他何らかの作業を実行することができる。
【0063】
アプリケーション処理エンジン110は、1つ以上のコンピュータおよび/またはサーバを含み得る。これは、汎用コンピュータ、専用サーバコンピュータ(例として、PCサーバ、UNIXサーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバ等を含む)、サーバファーム、サーバクラスタ、または、その他任意の適切な構成および/または組み合わせであってもよい。アプリケーション処理エンジン110を構成するコンピューティングデバイスは、オペレーティングシステムまたは各種その他のサーバアプリケーションおよび/またはミッドティアアプリケーションのうちのいずれか
を実行し得る。これは、HTTPサーバ、FTPサーバ、CGIサーバ、Javaサーバ、データベースサーバ等を含む。データベースサーバの例は、Oracle、Microsoft、Sybase、IBM等から市販されているものを含むが、これらに限定されない。
【0064】
特定の実施形態において、アプリケーション処理エンジン110は、先に述べたようなアプリケーション(たとえばイベント処理アプリケーション)をユーザデバイス102から受信し、このアプリケーションにおける情報を処理することにより、このアプリケーションの「共通アプリケーションランタイムモデル」を生成するように構成し得る。上述のように、アプリケーションの「共通アプリケーションランタイムモデル」は、1つ以上の構成ブロックのセットとしてアプリケーションを表現したものであり、各構成ブロックはイベントビーンを表し、対応するメタデータがアプリケーションを記述する。アプリケーション処理エンジン110は、アプリケーションの「共通アプリケーションランタイムモデル」を、アプリケーションの1つ以上のジェネリック表現に変換するように構成し得る。特定の実施形態において、そうすると、アプリケーション処理エンジン110は、異なるターゲットイベント処理システムがサポートする異なる実行(ランタイム)環境においてアプリケーションのジェネリック表現を実行させるように構成することができる。
【0065】
特定の実施形態において、アプリケーション処理エンジン110は、共通アプリケーションランタイムモデルジェネレータ112と、共通アプリケーションランタイムモデルオプティマイザ114と、ターゲットDAGジェネレータ116とを含み得る。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせにおいて実現し得る。共通アプリケーションランタイムモデルジェネレータ112は、アプリケーションに対応付けられた情報に基づいてアプリケーションのための「共通アプリケーションランタイムモデル」を生成するように構成し得る。共通アプリケーションランタイムモデルオプティマイザ114は、「共通アプリケーションランタイムモデル」を最適化することにより、アプリケーションのための最適化された共通アプリケーションランタイムモデルを生成するように構成し得る。ターゲットDAGジェネレータ116は、最適化された共通アプリケーションランタイムモデルを、ターゲットイベントストリーム処理エンジン(システム)のうちの1つによって実行できるアプリケーションの1つ以上のジェネリック表現に変換するように構成し得る。アプリケーション処理エンジン110のコンポーネント112、114、および116が実行する動作は、以下において図2との関連で詳細に説明する。
【0066】
特定の実施形態において、ターゲットイベント処理エンジン118は、アプリケーション処理エンジン110から共通アプリケーションランタイムモデルを受信し、共通アプリケーションランタイムモデルにおける情報を、ターゲットイベントストリームエンジン118が提供するランタイム(実行)環境において実行可能なアプリケーション(すなわちターゲットイベント処理アプリケーション120)のプラットフォーム固有の実装に変換するように構成し得る。そうすると、ターゲットイベントストリーム処理エンジン118は、ストリームに新たなデータが現れるとターゲットイベント処理アプリケーション120を連続的に実行し結果の連続ストリームをユーザに提供するように構成し得る。ターゲットイベントストリーム処理エンジン118は、連続的に受信したデータストリーム(たとえばライブフィード)に対しターゲットイベント処理アプリケーション120において定められた1つ以上の動作(たとえばCQLクエリ)を実行することにより、データストリームのリアルタイム処理を実行することができる。たとえば、ターゲットイベントストリーム処理エンジン118は、1つ以上の連続データストリームを受信し、データストリームに対するターゲットイベント処理アプリケーション120を登録し、ストリーム内に新たなデータが現れると、ターゲットイベント処理アプリケーション120において定められた1つ以上のクエリを連続的に実行することができる。この種の連続クエリは実行時間が長いので、ターゲットイベントストリーム処理エンジンは、結果の連続ストリームを
ユーザに提供することができる。ターゲットイベントストリーム処理エンジン118が実行するその他の動作は、図3との関連で詳細に説明する。
【0067】
特定の実施形態において、各ターゲットイベントストリーム処理エンジン118は、ターゲットイベント処理アプリケーションを実行するための特定の物理実行環境を表し得る。たとえば、第1のターゲットイベントストリーム処理エンジンは、第1の物理実行(ランタイム)環境においてターゲットイベント処理アプリケーションを実行するように構成された第1のイベントストリーミングプラットフォーム、第2の物理実行(ランタイム)環境においてアプリケーションを実行するように構成された第2のイベントストリーミングプラットフォーム、第3の物理実行(ランタイム)環境においてアプリケーションを実行するように構成された第3のイベントストリーミングプラットフォームなどを含み得る。第1、第2、および第3のイベントストリーミングプラットフォームは互いに異なり得る。たとえば、第1のイベントストリーミングプラットフォームは、Oracle(登録商標)が管理するオラクルイベントプロセッサ(Oracle Event Processor)(OEP)システムを表し得る。第2のイベントストリーミングプラットフォームは、Spark(登録商標)シ
ステムが管理するSpark(登録商標)フレームワーク等の第1のタイプの分散イベント処
理プラットフォームを表し得る。第3のイベントストリーミングプラットフォームは、Flink(登録商標)システムが管理するFlink(登録商標)フレームワーク等の第3のタイプの分散イベント処理プラットフォームを表し得る。
【0068】
図2は、本開示の実施形態に係る、イベント処理アプリケーションのためのイベント処理ネットワーク(EPN)200を図示する。特定の例において、イベント処理アプリケーションは、コンポーネントのネットワークとして表すことができる。このようなコンポーネントのネットワークは通常、イベント処理ネットワーク(event processing network)(EPN)200と呼ばれる。EPN200は、イベント処理アプリケーションのコンポーネント間におけるイベントベースのインタラクションおよびイベント処理仕様を表現するための概念的モデルである。イベント処理アプリケーションのコンポーネントは、アダプタ、ストリーム、プロセッサ、ビジネスロジックプレーンオールドJavaオブジェクト(Plain Old Java Object)(POJO)、およびビーンを含み得る。EPN200
における各コンポーネントは、イベントストリームを介して受信したデータの処理において、ある役割を果たす。上述のように、イベント処理ネットワーク(EPN)200は、これらの各種コンポーネント、これらのコンポーネントがどのようにしてともに接続されるか、アプリケーションが処理するイベントタイプ、アプリケーションが使用するイベントの選択のための連続クエリまたはロジック、アプリケーションにおいて定められたビジネスルールなどを記述する、情報を、含み得る。
【0069】
特定の実施形態において、ユーザデバイス102のユーザは、ユーザデバイスにおいてクライアントアプリケーション(たとえば104)が提供するアプリケーション設計ユーザインターフェイス(たとえば106)を用いてイベント処理アプリケーションのためのEPN200を生成することができる。その他の実施形態において、ユーザは、アプリケーション設計ユーザインターフェイスを介してアプリケーションを特定する情報を提供することができる。このような情報は、たとえば、アプリケーションにおいて定められた1つ以上の連続クエリ、アプリケーションのデプロイのタイプを指定するアプリケーションパラメータ、アプリケーションのランタイム構成(たとえば、使用するエグゼキュータ(executor)の数、パラレル処理パラメータ、メモリのサイズ、高可用性パラメータ)などを含み得る。クライアントアプリケーションは、この情報に基づいて、イベント処理アプリケーションのためにEPN200を構築および/または生成することができる。
【0070】
特定の実施形態において、図2に示されるように、イベント処理アプリケーションのためのEPN200は、以下のコンポーネントタイプで構成することができる。
【0071】
(1)入力および出力ストリームならびにリレーションソースおよびシンクに直接インターフェイスする1つ以上のアダプタ(202,204)。アダプタは、入力および出力ストリームプロトコルを理解するように構成され、イベントデータを、アプリケーションプロセッサによってクエリ可能な正規化された形態に変換する役割を担う。アダプタは、正規化されたイベントデータをチャネルまたは出力ストリームおよびリレーションシンクに転送し得る。イベントアダプタは、さまざまなデータソースおよびシンクについて定義され得る。図2に示す実施形態において、アダプタは、ストリームまたはリレーションソース1アダプタ202およびストリームまたはリレーションソース2アダプタ204を含む。
【0072】
(2)イベント処理終点の役割を果たす1つ以上のチャネル(206,208,210)。とりわけ、チャネルは、イベント処理エージェントがイベントデータに対して作用することができるまでイベントデータを待ち行列に入れる役割を担う。
【0073】
(2)1つ以上のアプリケーションプロセッサ(または、イベント処理エージェント)212は、正規化されたイベントデータをチャネルから消費し、クエリを使用してそれを処理して注目すべきイベントを選択し、選択された注目すべきイベントを出力チャネル210に転送(または、コピー)するように構成される。
【0074】
(4)1つ以上のビーン214,216,および218は、出力チャネル220をリッスンするように構成され、出力チャネル220への新たなイベントの挿入によってトリガされる。いくつかの実施形態では、このユーザコードは、プレーンオールドJavaオブジェクト(POJO)である。ユーザアプリケーションは、JMS、ウェブサービスおよびファイルライタ等の外部サービス一式を活用して、生成されたイベントを外部イベントシンクに転送することができる。
【0075】
(5)イベントビーン214,216,および218は、出力チャネル220をリッスンするように登録されてもよく、出力チャネルへの新たなイベントの挿入によってトリガされてもよい。いくつかの実施形態では、このユーザコードは、ビーンがOracleのCEPによって管理できるようにOracleのCEPイベントビーンAPIを使用し得る。
【0076】
一実施形態では、イベントアダプタ(202,204)は、イベントデータを入力チャネル(206,208)に提供する。入力チャネル(206、208)は、入力チャネル(206,208)によって提供されるイベントに対して動作する1つ以上のCQLクエリに関連付けられたCQLプロセッサ(212)に接続される。CQLプロセッサ(212)は、クエリ結果が書き込まれる出力チャネル(220)に接続される。
【0077】
いくつかの実施形態では、イベント処理アプリケーションのさまざまなコンポーネント、コンポーネントがどのようにしてともに接続されるか、および、アプリケーションが処理するイベントタイプを記述するアセンブリファイルを、イベント処理アプリケーションに対して提供することができる。イベントの選択のための連続クエリまたはロジックを指定するために別々の構成ファイルが提供されてもよい。特定の実施形態において、イベント処理アプリケーションにおける情報を、Spring(登録商標)XMLフレームワークを用いてアセンブルしてもよい。以下でより詳細に説明するように、この手法により、アプリケーションを、既存のSpring(登録商標)ビーン、および、依存性注入(dependency injection)メカニズムに基づくその他の軽量プログラミングフレームワークと、簡単に統合することが可能である。たとえば、イベントサーバが制御の反転(Inversion of Control)(IoC)コンテナ全体を強化することによりEPNのアセンブリ内のSpring(登録商標)ビーンをユーザがシームレスに使用できるよう、アセンブリファイルは、Spring(登
録商標)フレームワークコンテキストXML構成ファイルのカスタム拡張であってもよい。
【0078】
図3は、本開示の実施形態に係る、アプリケーション処理エンジンのコンポーネントを示す簡略化されたブロック図300である。特定の実施形態において、アプリケーション処理エンジン314は、ユーザデバイス302のユーザから、イベント処理アプリケーション(たとえば304)を特定する情報を受信し、この情報に基づいて共通ランタイムアプリケーションモデルを生成するように構成し得る。上述のように、イベント処理アプリケーション304は、ユーザデバイス302のユーザが、ユーザデバイスにおいて、クライアントアプリケーション(たとえば104)が提供するアプリケーション設計ユーザインターフェイス306を用いて生成することができる。
【0079】
いくつかの例において、アプリケーションを特定する情報は、アプリケーションの各種コンポーネント(たとえば、アダプタ、プロセッサ、ストリーム、またはイベントビーン)を記述する情報を含み得る。この情報は、たとえば、構成情報、クエリ情報、および、その他の種類の情報を含み得る。構成情報は、たとえば、イベント処理アプリケーションの各種コンポーネント、コンポーネントがどのようにしてともに接続されるか、および、アプリケーションが処理するイベントタイプを記述する情報を、含み得る。たとえば、構成情報は、コンポーネントのネットワーク(すなわちEPN200)としてイベント処理アプリケーションを記述する情報を含み得る。クエリ情報は、アプリケーションによるイベントの選択のための連続クエリまたはロジックを指定する情報を含み得る。その他の種類の情報は、プレーンオールドJavaオブジェクト(POJO)およびアプリケーションにおいて定められたビジネスルールを含み得る。
【0080】
特定の例において、アプリケーションを特定する情報は、構成ファイルにおいて指定することができる。たとえば、イベント処理アプリケーション304のEPN200における各コンポーネントは、対応付けられた構成ファイルを有することができる。その他の例において、アプリケーション304における情報は、アプリケーションにおけるすべてのコンポーネントについての情報を含む単一の構成ファイルで表すことができる。一実装例において、構成ファイルは、その構造が、共通ランタイムモデルによって定められる構成スキーマに基づく標準XMLスキーマを用いて定められる、通常のXMLドキュメントとして表現することができる。
【0081】
特定の例において、アプリケーションを特定する情報は、EPN構成ファイル、クエリ構成ファイル、およびその他のファイル等の、各種構成ファイルを用いて、指定することができる。イベント処理アプリケーションのためのEPN構成ファイルおよびクエリ構成ファイルの一例を以下に示す。示されている例において、イベント処理アプリケーションは、イベントの連続ストリームを受信して処理するように構成されたオーダーイベント処理アプリケーション304であり、各イベントは、ある企業が販売する商品に対するオーダーを表す。オーダーイベントストリームにおける各オーダーは、商品に関する、オーダー識別子、オーダーステータス、およびオーダー量等の属性を含み得る。イベント処理アプリケーション304のためのEPN構成ファイル308の一例を以下に示す。EPN構成ファイル308はサブエレメントのシーケンスを含み、各サブエレメントは、イベント処理アプリケーションにおけるイベント処理コンポーネントについての構成情報を含む。
【0082】
【数1】
【0083】
イベント処理アプリケーション304のための、一例としてのクエリ構成ファイル310を以下に示す。クエリ構成ファイル310は、イベント処理アプリケーションにおけるイベントの選択のための1つ以上の連続クエリまたはロジックを指定する。
【0084】
【数2】
【0085】
特定の実施形態において、アプリケーション処理エンジン314は、EPN構成ファイ
ル308、クエリ構成ファイル310、およびその他のファイル312において指定された、構成情報、クエリ情報、およびその他の情報に基づいて、アプリケーション(たとえば304)のための「共通アプリケーションランタイムモデル」を生成するように構成し得る。次に、ターゲットDAGジェネレータ320が、「共通アプリケーションランタイムモデル」を、異なるターゲットイベントストリーム処理エンジン226、228、および230がサポートする異なる物理実行(ランタイム)環境における実行のために、アプリケーションの1つ以上のジェネリック表現に変換することができる。「共通アプリケーションランタイムモデル」を生成することにより、ターゲットエンジンにおけるその実行に先立ってターゲットエンジンの特定の物理実行(ランタイム)環境に適するようにアプリケーションコードをアプリケーションの開発者(たとえばユーザ)が再度書き込まなくても、異なる物理実行(ランタイム)環境においてアプリケーションのジェネリック表現を実行することができる。共通アプリケーションランタイムモデルは、物理実行環境から独立している。プラットフォーム独立抽象化により、システムは、物理実行環境のためのDAGおよびコードを容易に生成することができる。
【0086】
特定の実施形態において、アプリケーション処理エンジン314が「共通アプリケーションランタイムモデル」を生成することは、対応付けられた構成情報を用いて1つ以上のイベントビーンのセットとしてアプリケーションを表すことを含み得る。アプリケーション処理エンジン314がイベントビーンのセットとして「共通アプリケーションランタイムモデル」を表すことができる手法のさらに他の詳細については以下で説明する。
【0087】
特定の実施形態において、アプリケーション処理エンジン314は、共通アプリケーションランタイムモデルジェネレータ316と、共通アプリケーションランタイムモデルオプティマイザ318と、ターゲットDAGジェネレータ320とを含む。共通アプリケーションランタイムモデルジェネレータ316は、EPN構成ファイル308、クエリ構成ファイル310、およびその他のファイル312において指定されたアプリケーションを特定する情報に基づいて、アプリケーションのための「共通アプリケーションランタイムモデル」を生成するように構成される。特定の実施形態において、共通アプリケーションランタイムモデルジェネレータ316が「共通アプリケーションランタイムモデル」を生成することは、EPN構成ファイル308、クエリ構成ファイル310、およびその他のファイル312を、Spring(登録商標)アプリケーションフレームワークを用いて実装されたEPNローダを用いてメモリにロードすることを含む。その結果は、制御注入(control injection)のSpring(登録商標)の反転によって接続されたSpring(登録商標)ビ
ーンのセットである。そうすると、共通アプリケーションランタイムモデルジェネレータ316は、JAXB(Java Architecture for XML Binding(XMLバインディングのた
めのJavaアーキテクチャ))等のXMLパーサを用いてEPN構成ファイル308をパースし、パースされた構成ファイルを、EPNネットワークにおける対応付けられた各ビーンにセットするように、構成される。特定の例において、パースされた各構成ブロックまたはファイルは、このブロックまたはファイルがイベントビーンを発見し構成ブロックまたはファイルをそのイベントビーンにセットすることができるよう、識別子を有するであろう。よって、ある実施形態において、アプリケーションのための「共通アプリケーションランタイムモデル」を生成することは、1つ以上の構成ブロックのセットとしてアプリケーションを表すことを含み、各構成ブロックは、メタデータが対応付けられているSpring(登録商標)イベントビーンを表す。「共通アプリケーションランタイムモデル」の表現の一例を図4に示す。特定の例において、「共通アプリケーションランタイムモデル」は、その中に何ら処理ロジックを伴うことなく、イベント処理アプリケーションのコンポーネントに関するメタデータを維持する。
【0088】
図4は、本開示の実施形態に係る、共通アプリケーションモデルジェネレータ316によって生成された「共通アプリケーションランタイムモデル」400を表現したものの一
例を示す。ある実施形態において、「共通アプリケーションランタイムモデル」400は、(たとえばEPN構成ファイル308、クエリ構成ファイル310、およびその他のファイル312からの)アプリケーションを特定する情報に基づいて生成することができ、1つ以上の構成ブロックのセットとして表すことができ、各構成ブロックは、メタデータが対応付けられているSpring(登録商標)イベントビーンを表す。ある実施形態において、共通ランタイムアプリケーションモデル400における構成ブロック402,404、406、408、および410は以下の情報を含み得る。
【0089】
【数3】
【0090】
たとえば、構成ブロック402において、ソケットインバウンドはEPNにおける「socketAdapter」アダプタを表し、構成ブロック404において、チャネル1はEPNにお
ける「orders」チャネルを表し、構成ブロック406において、CQLプロセッサはEPNにおける「orderProcessor」プロセッサを表し、構成ブロック408において、チャネル2はEPNにおける「outputChannel」チャネルを表し、構成ブロック410において
、ソケットアウトバウンド410はEPNにおける「outputAdapter」アダプタを表す。
【0091】
上述のように、イベント処理アプリケーションを「共通アプリケーションランタイムモデル」400として表すことにより、ターゲットエンジンにおけるその実行に先立ってターゲットエンジンの特定の物理実行(ランタイム)環境に適するようにアプリケーションコードをユーザが再度書き込まなくても、異なるターゲットイベントストリーム処理エンジン(たとえば326、328、または330)においてアプリケーションを実行することができる。
【0092】
図3の説明に戻ると、特定の実施形態において、共通アプリケーションランタイムモデルジェネレータ316が生成した共通アプリケーションランタイムモデルはさらに、共通アプリケーションランタイムモデルオプティマイザ318により、最適化することができる。共通アプリケーションランタイムモデル(たとえば400)の最適化は、たとえば、ある構成ブロック内の複数の段を組み合わせて1つの段にすること(たとえば複数の連続クエリを組み合わせて1つの最適化された連続クエリにすること)または、1つの段を並
列処理のために複数の段に分割すること(たとえば、連続クエリを、マッピングを実行し動作を減じることができる複数の連続クエリに分割すること)を含み得る。たとえば、再度のパーティショニングなしの連続クエリを組み合わせて、1つのCQLプロセスを有する1つのCQL段にすることができる。たとえば、「select * from orders where orderStatus='open'」および「select count(*) from orders group by orderId」という2つ
の段を組み合わせて、「select count(*) from orders group by orderId where orderStatus=''open''」という1つのCQL段にすることができる。オプティマイザは、スケー
ラビリティを最大にするために1つの段を複数の段に分割することもできる。たとえば、「select count(*) from orders」という十分にステートフルなクエリ段を、パーティシ
ョニングを用いて、「select count(*) from order group by orderId」および「select sum(*) from counts」という2つの段に分割することができる。これにより、パーティショニングを用いてイベントのグローバルカウントを部分カウントで処理することができ、その後、部分カウントを合計してグローバルカウントにすることができる。
【0093】
特定の実施形態において、ターゲットDAGジェネレータ320は、最適化された共通アプリケーションランタイムモデルを、ターゲットイベントストリーム処理エンジンのうちの1つ(326、328、または330)が実行できるアプリケーションの1つ以上のジェネリック表現に変換するように構成し得る。たとえば、ターゲットDAGジェネレータ320は、アプリケーションが実行されるであろうターゲットイベントストリーム処理エンジンに応じて、最適化された共通アプリケーションランタイムモデルを、ランタイムDAG322またはアプリケーションのターゲット表現324に変換するように、構成し得る。たとえば、ターゲットイベントストリーム処理エンジン(たとえば326)が、Oracle(登録商標)が管理するオラクルイベントプロセッサ(Oracle Event Processor)(OEP)である場合、ターゲットDAGジェネレータ320は、共通アプリケーションランタイムモデル(または最適化された共通アプリケーションランタイムモデル)における構成ブロックを、ターゲットイベントストリーム処理エンジン326が実行するアプリケーションのターゲット表現324に変換するように、構成し得る。特定の実施形態において、この変換は、ターゲットDAGジェネレータ320が、実際の処理ロジックを有する適切なビーンを用いて共通アプリケーションランタイムモデルにおけるオブジェクトを複製することを含み得る。たとえば、共通アプリケーションランタイムモデルにおけるCQLプロセッサビーンのメタデータを、CQLエンジンを実行するイベント処理コンポーネント(たとえばCQLプロセッサ)の新たなインスタンスにコピーして、所与のクエリ(たとえば共通ランタイムアプリケーションモデルにおけるCQLプロセッサからコピーしたもの)を用いて入力イベントを処理してもよい。
【0094】
たとえば、ターゲットイベントストリーム処理エンジン(たとえば328)が、Spark
(登録商標)分散システムが管理する分散イベント処理プラットフォームである場合、ターゲットDAGジェネレータ320を、共通アプリケーションランタイムモデル(または最適化された共通アプリケーションランタイムモデル)におけるオブジェクト(構成ブロック)を、アプリケーションを表すコンポーネントのランタイムDAG322に変換するように、構成し得る。ターゲットDAGジェネレータが生成するコンポーネントのランタイムDAG322の一例を、図5に示す。次に、コンポーネントのランタイムDAG322を、ターゲットイベントストリーム処理エンジン328が、ターゲットアプリケーション(Spark(登録商標)CQLアプリケーション)に変換する。ターゲットイベントスト
リーム処理エンジン328が、オーダーイベント処理アプリケーションのためのオーダーステータスによってグループ分けされたオーダーの数を計算するために生成するターゲットアプリケーションの一例を以下に示す。
【0095】
【数4】
【0096】
図5は、本開示の実施形態に係る、ターゲットDAGジェネレータが生成した、一例としての、コンポーネントのランタイム有向非巡回グラフ(DAG)500を示す。特定の実施形態において、上述のように、ターゲットDAGジェネレータ320を、ターゲットアプリケーションの実行(ランタイム)環境が分散イベント処理システム(たとえばSpark(登録商標)分散イベント処理システム)であるときに、共通アプリケーションランタ
イムモデル(たとえば400)におけるオブジェクト(402、404、406、408、および410)を、アプリケーションを表すコンポーネントのランタイムDAG500
に変換するように、構成することができる。
【0097】
ある実施形態において、コンポーネントのランタイムDAGは、以下のコンポーネント、すなわち、SocketText502、Map-1 504、Map-2 506、PartitionBy508、
CQL510、Map-3 512、およびPrint514を含む。SocketInbout402(図4に示す)は、SocketText502、Map-1 504、およびMap506に変換される。SocketText502コンポーネントは、上記ターゲットアプリケーションの例におけるライン7を含み、これは、ソケットからストリングをロードする。Map-1 504コンポーネントは、
ターゲットアプリケーションの例におけるライン8を含み、これは、ストリングを、カンマで分離された値に変換する。Map-2 506コンポーネントは、ターゲットアプリケー
ションの例におけるライン9を含み、これは、カンマで分離された値をタプルに変換する。CQLプロセッサ406およびChannel-1 404は、PartitionBy508およびCQL510に変換される。PartitionBy508コンポーネントは、ターゲットアプリケーショ
ンの例におけるライン10を含み、これは、CQLにおけるgroup by基準に基づいてパーティショニングを生成する。CQL510コンポーネントは、ターゲットアプリケーションの例におけるライン11を含み、これは、主要なCQL処理段である。Channel-2 4
08およびStdoutOutbound410は、Map-3 512およびPrint51に変換される。Map-3 512コンポーネントは、ターゲットアプリケーションの例におけるライン12を含
み、これは、タプルを、カンマで分離されたストリングに変換し、Print514コンポー
ネントは、ターゲットアプリケーションの例におけるライン13を含み、これは、出力ストリングをstdoutコンソールにプリントする。
【0098】
図6は、本開示の実施形態を組み込むことが可能なイベント処理システム600の簡略化されたハイレベル図である。ある実施形態において、イベント処理システム600は、Oracle(登録商標)が管理するオラクルイベントプロセッサ(OEP)システムを表していてもよい。イベント処理システム600は、1つ以上のイベントソース(604、606、608)と、イベントストリームを処理するための環境を提供するように構成されたイベント処理サービス(EPS)602(CQサービス602とも呼ばれる)と、1つ以上のイベントシンク(610、612)とを含み得る。イベントソースは、EPS602が受信するイベントストリームを生成する。EPS602は、1つ以上のイベントソースから1つ以上のイベントストリームを受信することができる。
【0099】
たとえば、図6に示すように、EPS602は、イベントソース604から第1の入力イベントストリーム614を受信し、イベントソース606から第2の入力イベントストリーム616を受信し、イベントソース608から第3のイベントストリーム618を受信する。1つ以上のイベント処理アプリケーション(614、616、および618)を、EPS602上にデプロイしEPS602によって実行することができる。EPS602が実行するイベント処理アプリケーションは、1つ以上の入力イベントストリームをリッスンし、入力イベントストリームから1つ以上のイベントを注目すべきイベントとして選択する処理ロジックに基づいて、1つ以上のイベントストリームを介して受信したイベントを処理するように、構成し得る。次に、注目すべきイベントを、1つ以上の出力イベントストリームの形態で1つ以上のイベントシンク(610、612)に送信することができる。たとえば、図6において、EPS602は、第1の出力イベントストリーム620をイベントシンク610に出力し、第2の出力イベントストリーム622をイベントシンク612に出力する。特定の実施形態において、イベントソース、イベント処理アプリケーション、およびイベントシンクは、これらのコンポーネントのうちのいずれかを、その他のコンポーネントに変更を加えることなく追加または削除できるよう、互いに分離されている。
【0100】
一実施形態において、EPS602は、共有されるサービスとともに、Equinox OSGiに
基づくもののような、軽量Javaアプリケーションコンテナを含む、Javaサーバとして実装してもよい。いくつかの実施形態において、EPS602は、たとえば、JRockit Real Timeを使用することによりイベントを処理するために超高スループットおよびマ
イクロ秒レイテンシをサポートし得る。EPS602は、イベント処理アプリケーションを開発するためのツール(たとえばOracle CEP VisualizerおよびOracle CEP IDE)を含
む開発プラットフォーム(たとえば完全なリアルタイム・エンドツーエンドJavaイベント駆動型アーキテクチャ(EDA)開発プラットフォーム)を提供することもできる。
【0101】
イベント処理アプリケーションは、1つ以上の入力イベントストリームをリッスンし、1つ以上の入力イベントストリームから1つ以上の注目すべきイベントを選択するためにロジック(例えばクエリ)を実行し、選択した注目すべきイベントを1つ以上の出力イベントストリームを介して1つ以上のイベントソースに出力するように、構成される。図6は、このようなあるイベント処理アプリケーション614に対するドリルダウンを提供する。図6に示すように、イベント処理アプリケーション614は、入力イベントストリーム618をリッスンし、入力イベント618から1つ以上の注目すべきイベントを選択するためのロジックを含む連続クエリ630を実行し、出力イベントストリーム622を介してイベントシンク612に選択した注目すべきイベントを出力するように、構成される。イベントソースの例は、アダプタ(たとえばJMS、HTTP、およびファイル)、チャネル、プロセッサ、テーブル、キャッシュなどを含むが、これらに限定されない。イベントシンクの例は、アダプタ(JMS、HTTP、およびファイル)、チャネル、プロセッサ、キャッシュなどを含むが、これらに限定されない。
【0102】
図6のイベント処理アプリケーション614は、1つの入力ストリームをリッスンし選択したイベントを1つの出力ストリームを介して出力するものとして示されているが、これは限定を意図したものではない。代替の実施形態において、イベント処理アプリケーションは、1つ以上のイベントソースから受信した複数の入力ストリームをリッスンし、モニタリングされたストリームからイベントを選択し、選択したイベントを、1つ以上の出力イベントストリームを介して1つ以上のイベントシンクに出力するように、構成することができる。同一のクエリを、2つ以上のイベントシンクと、異なる種類のイベントシンクとに、対応付けることができる。
【0103】
その無制限という性質のため、イベントストリームを介して受信するデータの量は大抵、非常に多い。結果として、クエリするという目的のためにすべてのデータを格納またはアーカイブすることは通常は非実用的であり望ましくない。イベントストリームを処理するには、受信したイベントデータをすべて格納する必要を伴うことなく、EPS602がイベントを受信するとイベントをリアルタイムで処理することが必要である。このように、EPS602は、受信したイベントすべてを格納する必要を伴うことなく、EPS602がイベントを受信するとイベントの処理を実行できるようにする特別なクエリ機構を提供する。
【0104】
イベント駆動型アプリケーションはルール駆動型であり、これらのルールは、入力ストリームを処理するのに用いられる連続クエリの形態で表現することができる。連続クエリは、受信したイベントに対して実行すべき処理を特定する命令(たとえばロジック)を含み得る。これは、注目すべきイベントとしてどのようなイベントを選択しクエリ処理の結果として出力すべきかを含む。連続クエリは、データストアにパーシストされイベントの入力ストリームを処理しイベントの出力ストリームを生成するために使用されてもよい。連続クエリは一般的に、フィルタリングおよびアグリゲーション機能を実行することにより、入力イベントストリームから注目すべきイベントを発見して抽出する。その結果、出力イベントストリームにおけるアウトバウンドイベントの数は通常、イベントの選択元である入力イベントストリームにおけるイベントの数よりも遙かに少ない。
【0105】
有限データセットに対して一度実行されるSQLクエリとは異なり、特定のイベントストリームに対しEPS602にアプリケーションによって登録された連続クエリは、そのイベントストリームにイベントを受け入れるたびに実行することができる。連続クエリ実行の一部として、EPS602は、連続クエリによって指定された命令に基づいて受信イベントを評価することにより、1つ以上のイベントを注目すべきイベントとして選択し連続クエリの実行結果として出力するするか否かを判断する。
【0106】
連続クエリは異なる言語を用いてプログラミングしてもよい。特定の実施形態において、連続クエリを、Oracle社によって提供されOracleの複合イベント処理(CEP)製品によって使用されるCQLを用いて構成してもよい。OracleのCQLは、イベントストリームに対して実行できるクエリ(CQLクエリと呼ぶ)をプログラミングするのに使用することができる宣言型言語である。特定の実施形態において、CQLは、ストリーミングイベントデータの処理をサポートする構成が追加されたSQLに基づく。
【0107】
図6に示されるシステム600は、図6に示されているコンポーネント以外のコンポーネントを有し得ることが理解されるべきである。さらに、図6に示される実施形態は、本開示の実施形態を組み込むことができるシステムの一例に過ぎない。いくつかの他の実施形態では、システム600は、図6に示されるコンポーネントよりも多くのコンポーネントもしくは少ないコンポーネントを有していてもよく、2つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有していてもよい。システム600は、サービスプロバイダコンピュータ、パーソナルコンピュータ、ポータブルデバイス(たとえば、携帯電話もしくはデバイス)、ワークステーション、ネットワークコンピュータ、メインフレーム、キオスク、サーバ、またはその他のデータ処理システムを含むさまざまなタイプのシステムであってもよい。
【0108】
図7は、本開示の実施形態に係る、分散イベント処理システム710のコンポーネントを示す簡略化されたブロック図700である。図7に示す実施形態は、本開示の実施形態を組み込むことができる分散イベント処理システムの一例である。その他いくつかの実施形態において、システム710は、図7に示すコンポーネントよりも多いコンポーネントもしくは少ないコンポーネントを有していてもよく、2つ以上のコンポーネントを組み合わせてもよく、または、コンポーネントの異なる構成もしくは配置を有していてもよい。システム710は、モバイル、デスクトップ、シンクライアント、および/またはクラウドコンピューティングデバイス、サーバ、またはその他任意のデータ処理システム等であるがこれらに限定されない、いずれかの種類のコンピューティングデバイスであればよい。
【0109】
いくつかの例において、分散イベント処理システム710は、ソフトウェアリソース、ハードウェアリソース、ネットワーキングリソース、およびその他のリソースの、予め組み込まれ最適化された組み合わせで構成することができる。ハードウェアリソースは、サーバ、データストレージデバイス、サーバ、プリンタ等を含み得るが、これらに限定されない。ソフトウェアリソースは、コンピューティングプログラム、アプリケーション(たとえばクラウドベースのアプリケーション、企業アプリケーション、またはその他任意のアプリケーション)、コンピュータプログラムプロダクト(たとえばソフトウェア)、サービス(たとえばクラウドベースのサービス)等を含み得るが、これらに限定されない。データリソースは、ファイル(たとえばネットワーク化されたファイルまたはディレクトリ情報)、データベース等の、アクセス可能な任意のデータオブジェクトを含み得るが、これらに限定されない。
【0110】
特定の実施形態において、分散イベント処理システム710は、受信機704とコンピ
ューティングノードのクラスタ708とを含み得る。受信機704は、連続入力イベントストリーム702を受信し、このイベントストリームを、分散イベント処理システム710におけるコンピューティングノードのクラスタ708による後続の処理のために特定期間(たとえばX秒)1つ以上のイベントのバッチ706に、離散化(discretize)(分割)するように、構成し得る。イベントの各バッチを本明細書ではDストリーム(Dstream
)と呼ぶ。いくつかの例において、各Dストリームは内部では受信機704によってレジリエント分散データセット(Resilient Distributed Dataset)(RDD)として表され
る。これは、特定期間中に(たとえばあるイベントバッチにおいて)インジェストされたデータ(イベント)の入力ストリームすべてのスナップショットである。よって、いくつかの実施形態において、入力データストリーム702は、Dストリームのシーケンスとして表され、各Dストリームは内部ではRDDとして表され、各RDDは、特定のバッチ間隔中に受信したイベント(タプル)を含む。特定の例において、各RDDは、不変のパーティションされたエレメントのコレクションを表し、これは、キャッシュメモリに格納し分散イベント処理システムにおいて並列に実行することができる。
【0111】
特定の実施形態において、コンピューティングノードのクラスタ704は、コンピューティングノードのクラスタにわたり各RDDに含まれるデータをパーティションし、このデータに対し、アプリケーションにおいて定められた一組のクエリに対して並列に動作を実行し、分散イベント処理システムのユーザに処理結果を与えるように、構成することができる。よって、コンピューティングノードのクラスタ708は、RDDにおけるイベントデータの処理を、コンピューティングノードのクラスタ708にわたって分散させ、イベントデータに対するアプリケーションの実行に関連する結果を素早くリアルタイムでユーザに提供するように、構成することができる。ある実施形態において、分散イベント処理システム710は、Apache(登録商標)Spark Streamingフレームワークを用いて構成
することにより、データの連続ストリームの分散リアルタイム処理およびイベント処理アプリケーションのデプロイを実行するように、構成することができる。
【0112】
図8は、本開示の一実施形態に係る、アプリケーションの共通アプリケーションランタイムモデルを生成するためにイベント処理アプリケーションを処理するための一組の動作を説明する、プロセス800のフロー図の一例である。特定の実施形態において、プロセス800は、図3に記載のアプリケーション処理エンジン(314)における1つ以上のコンポーネント(たとえば316、318、および320)によって実行されてもよい。プロセス800は、802においてアプリケーションを特定する情報を受信することで始まる。この情報は、たとえば、構成情報、クエリ情報、およびその他の種類の情報等の、アプリケーションの各種コンポーネント(たとえばアダプタ、プロセッサ、ストリーム、またはイベントビーン)を記述する情報を含み得る。上述のように、この情報は、図3に示される構成ファイル(308、310、および312)において表現することができる。
【0113】
804において、プロセスは、アプリケーションを特定する情報に基づいてアプリケーションの「共通アプリケーションランタイムモデル」を生成することを含む。ある実施形態において、アプリケーションのための「共通アプリケーションランタイムモデル」を生成することは、アプリケーションを、1つ以上の構成ブロックのセットとして表すことを含み得る。ここで、各構成ブロックは、対応するメタデータを有するイベントビーンを表す。構成ブロックは、図4を参照しながら説明したように、インバウンドソケットイベントビーン、アウトバウンドソケットイベントビーン、連続クエリ言語(CQL)プロセッサイベントビーン、または、図4に関連して説明した1つ以上のチャネルイベントビーンを含み得る。
【0114】
806において、このプロセスは、アプリケーションの「共通アプリケーションランタ
イムモデル」を、このアプリケーションの第1のジェネリック表現に変換することを含む。アプリケーションの第1のジェネリック表現は、複数のターゲットイベント処理システムのうちの第1のターゲットイベント処理システムにおいて実行されるように構成し得る。一例において、アプリケーションの「共通アプリケーションランタイムモデル」をアプリケーションの第1のジェネリック表現に変換することは、共通アプリケーションランタイムモデルにおける構成ブロックを、アプリケーションのコンポーネントのランタイムDAGに変換することを含み得る。アプリケーションのために生成されるコンポーネントのランタイムDAGの一例を図5に示す。
【0115】
いくつかの実施形態では、808において、このプロセスは、アプリケーションの第1のジェネリック表現を、第1のターゲットイベント処理システムによる実行のために第1のターゲットイベント処理システムに送信することを含む。一例において、第1のターゲットイベント処理システムは、分散イベント処理システムである。
【0116】
図9は、本開示の別の実施形態に係る、アプリケーションの共通アプリケーションランタイムモデルを生成するためにイベント処理アプリケーションを処理するための一組の動作を説明する、プロセス900のフロー図の一例である。特定の実施形態において、プロセス900は、図3に記載のアプリケーション処理エンジン(314)における1つ以上のコンポーネント(たとえば316、318、および320)によって実行されてもよい。プロセス900は、902においてアプリケーションを特定する情報を受信することで始まる。上述のように、この情報は、アプリケーションの各種コンポーネントを記述する、構成情報、クエリ情報、およびその他の種類の情報を含み得る。
【0117】
904において、このプロセスは、アプリケーションを特定する情報に基づいてアプリケーションの「共通アプリケーションランタイムモデル」を生成することを含む。ある実施形態において、アプリケーションのための「共通アプリケーションランタイムモデル」を生成することは、アプリケーションを、1つ以上の構成ブロックのセットとして表すことを含み得る。ここで、各構成ブロックは、対応するメタデータを有するイベントビーンを表す。構成ブロックは、図4を参照しながら説明したように、インバウンドソケットイベントビーン、アウトバウンドソケットイベントビーン、連続クエリ言語(CQL)プロセッサイベントビーン、または、図4に関連して説明した1つ以上のチャネルイベントビーンを含み得る。
【0118】
906において、このプロセスは、アプリケーションの「共通アプリケーションランタイムモデル」を、このアプリケーションの第2のジェネリック表現に変換することを含む。アプリケーションの第2のジェネリック表現は、複数のターゲットイベント処理システムのうちの第2のターゲットイベント処理システムにおいて実行されるように構成し得る。いくつかの例において、アプリケーションの「共通アプリケーションランタイムモデル」をアプリケーションの第2のジェネリック表現に変換することは、共通アプリケーションランタイムモデルにおける構成ブロックを、アプリケーションのターゲット表現に変換することを含み得る。
【0119】
いくつかの実施形態では、908において、プロセスは、アプリケーションの第2のジェネリック表現を、第2のターゲットイベント処理システムによる実行のために、第2のターゲットイベント処理システムに送信することを含む。一例において、第2のターゲットイベント処理システムは、Oracle(登録商標)イベントプロセッサ(OEP)システムである。
【0120】
イベントデータのシリアライズおよびデシリアライズ
特定の実施形態において、開示する分散イベント処理システムは、連続イベントストリ
ームを介して受信したイベントデータのシリアライズおよびデシリアライズを実行するように構成し得る。イベントデータのシリアライズおよびデシリアライズにより、メモリにおける複合データオブジェクトを、分散イベント処理システムのコンピューティングノードに転送することができるビットのシーケンスに変換することができる。イベントデータのシリアライズおよびデシリアライズにより、分散イベント処理システムによるイベントデータの処理の前に、分散イベント処理システムにおける処理ノードによってデータを効率的に格納し表現することができる。加えて、イベントデータのシリアライズおよびデシリアライズにより、分散イベント処理システムにおける処理ノード間の入力イベントおよび出力イベントのやり取りにおけるレイテンシを低減し、分散イベント処理システムの全体的な性能を改善する。
【0121】
上記技術はいくつかのやり方でいくつかのコンテキストにおいて実装することが可能である。以下では、イベント処理アプリケーションのデプロイ、処理、および実行に関連する動作を開示する分散イベント処理システムが実行し得る手法のさらに他の詳細を記述する図1図10を参照しながら、いくつかの実装およびコンテキストの例を提供する。
【0122】
図10は、本開示の実施形態に係る、分散イベント処理システムのコンポーネントを示す簡略化されたブロック図1000である。分散イベント処理システム1000は、図1に記載の分散イベント処理システム110と同一または同様であってもよい。図10に示す実施形態は、本開示の実施形態を組み込むことができる分散イベント処理システムの一例である。その他の実施形態において、分散イベント処理エンジンは、図10に示すコンポーネントよりも多いコンポーネントもしくは少ないコンポーネントを有していてもよく、2つ以上のコンポーネントを組み合わせてもよく、または、コンポーネントの異なる構成もしくは配置を有していてもよい。これらのコンポーネントは、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせにおいて実現し得る。いくつかの実施形態において、ソフトウェアは、メモリ(たとえば非一時的なコンピュータ可読媒体)に、メモリデバイスに、または、その他何らかの物理メモリに格納されてもよく、1つ以上の処理ユニット(たとえば1つ以上のプロセッサ、1つ以上のプロセッサコア、1つ以上のGPUなど)によって実行されてもよい。図10に示す実施形態はしたがって、ある実施形態のシステムを実現するための分散イベント処理エンジンの一例であって、限定を意図したものではない。
【0123】
特定の実施形態において、分散イベント処理システム1002は、受信機1004と、アプリケーションデプロイモジュール1008と、コンピューティングノードのクラスタ1012とを含み得る。受信機1006は、図2に記載のように(たとえばイベントソース204、206、または208から)データの入力ストリーム1004を受信することが可能であってもよく、入力データストリームを、本明細書ではDストリームと呼ぶイベントの1つ以上のバッチ1010に分割することができる。上述のように、各Dストリーム(すなわちイベントバッチ)は、特定期間中にインジェストされたデータ(イベント)の入力ストリームすべてを含み、内部では受信機1006によってRDDオブジェクトとして表すことができる。これは、分散イベント処理システム1002におけるコンピューティングノードのクラスタ1012において並列に実行できるエレメントの不変のパーティションされたコレクションである。
【0124】
アプリケーションデプロイモジュール1006は、コンピューティングノードのクラスタ1012におけるコンピューティングノードによる処理および実行のためにアプリケーション(たとえばイベント処理アプリケーション)をデプロイするように構成し得る。本明細書に記載のアプリケーションは、分散イベント処理システムのコンピュータプログラム(たとえばユーザが構築したもの)を言う場合がある。たとえば、アプリケーションは、一組の入力テキスト内の特定のワードに対するリファレンスの量をカウントするワード
カウントアプリケーションを含み得る。このようなアプリケーションは、たとえば、一組のテキストを読み取り、各テキスト内に各ワードが現れる回数をカウントする1つ以上の連続クエリを用いて構築することができる。入力テキストは、たとえば、Facebook(登録商標)またはTwitter(登録商標)等のオンラインアプリケーションからのストリームに
おいて受信したショートメッセージを含み得る。上述のように、連続クエリはCQL言語を用いて構成することが可能である。たとえば、ワードカウントストリーミングアプリケーションにおいて実行すべきワードカウントタスク/動作を指定するために、ユーザは、SELECT count FROM location GROUP BY wordといった形態を取ることができるCQLクエリを書き込むことができる。このようなクエリは、指定された場所からすべてのセンテンスを集め、これらのセンテンスから得た固有のワードを異なるグループに分けてから、各グループ内のワードの量をカウントすることができる。
【0125】
特定の実施形態において、アプリケーションデプロイモジュール1008は、分散イベント処理システムのユーザからアプリケーションを特定する情報を受信するように構成し得る。たとえば、アプリケーションデプロイモジュール1008は、アプリケーションデプロイモジュール1008においてアプリケーション設計ユーザインターフェイスを介してアプリケーションを特定する情報を受信するように構成し得る。アプリケーションを特定する情報は、アプリケーションにおいて定められた1つ以上の連続クエリのセットを含み得る。アプリケーションを特定する情報はまた、アプリケーションに対応付けられたアプリケーションパラメータを含み得る。アプリケーションパラメータは、たとえば、ノードのクラスタ1012におけるアプリケーションのデプロイのタイプ(たとえば「クラスタモード」)を指定するデプロイタイプパラメータを含み得る。その他のアプリケーションパラメータは、アプリケーションのランタイム構成に関するパラメータ(たとえば、使用するエグゼキュータの数、パラレル処理パラメータ、メモリのサイズ、高可用性パラメータなど)を含み得る。
【0126】
特定の実施形態において、アプリケーションデプロイモジュール1008は、アプリケーションに関連する情報を受信すると、クラスタにおけるコンピューティングノード上にアプリケーションをデプロイするためにコンピューティングノードのクラスタ1012に対して命令を送信するように構成し得る。特定の例において、コンピューティングノードのクラスタ1012は、コンピューティングノードのクラスタ1012上のマスタコンピューティングノード1014にアプリケーションをデプロイするように構成してもよい。マスタコンピューティングノード1014は、アプリケーションの「アプリケーションコンテキスト」を格納するように構成し得る。「アプリケーションコンテキスト」は、たとえば、アプリケーションのトポロジ、スケジューリング情報、アプリケーションパラメータ等といったアプリケーションの内容を含み得る。
【0127】
特定の実施形態において、マスタコンピューティングノード1014を、アプリケーションを走らせる/実行する「ドライバプログラム」またはアプリケーションマスタと呼ぶ場合がある。ドライバプログラムは、アプリケーションのメイン()機能を実行しアプリケーションの「アプリケーションコンテキスト」を生成するプロセスとして定義することができる。ドライバプログラムは、アプリケーションを駆動する役割と、リソースマネージャ1016のリソースを要求する役割との両方を有し得る。リソースマネージャ1016は、コンピューティングノードのクラスタ1012上のコンピューティングノードのためのリソースを取得してアプリケーションを実行するサービスであってもよい。クラスタ上でアプリケーションを走らせる/実行するために、マスタコンピューティングノード1014はリソースマネージャ1016に接続する。すると、これは、アプリケーションのリソースを割り当てる。接続されると、マスタコンピューティングノード1014は、クラスタ内の1つ以上のコンピューティングノード(ワーカーノード1018としても知られている)上の1つ以上のエグゼキュータを取得する。エグゼキュータは、計算を実行し
アプリケーション用のデータを格納するプロセスである。マスタコンピューティングノード1014は、アプリケーションコード(たとえばJARファイルによって定められる)をエグゼキュータに送信する。アプリケーションにおいて定められた変換およびアクションに基づいて、マスタコンピューティングノード1014はタスク1020をエグゼキュータに送信することができる。
【0128】
特定の実施形態において、マスタコンピューティングノード1014は、DAGジェネレータ1022と、DAGスケジューラ1024と、タスクスケジューラ1026と、アプリケーションコンテキスト情報1028とを含み得る。上述のように、アプリケーションコンテキスト情報1028は、アプリケーションのトポロジ、スケジューリング情報、アプリケ-ションパラメータ等のアプリケーションに関する情報を含み得る。DAGジェ
ネレータ1022は、受信機から受信したRDDオブジェクトに基づいてRDDオブジェクトの有向非巡回グラフ(DAG)を規定および/または作成するように構成し得る。いくつかの例において、DAGジェネレータ1022は、特定期間中に受信したすべてのRDDのRDDリネージグラフ(lineage graph)を表していてもよい。RDDリネージグ
ラフにおける各RDDオブジェクトは、1つ以上の親に対するポインタを、その親に対してどのような種類の関係を有しているかに関するメタデータとともに、維持する。また、RDDリネージグラフは、各RDDオブジェクトに対して実行すべき変換のDAGを特定する。マスタコンピューティングノード1014がアプリケーションにおけるジョブを実行することを要求されたとき、DAGジェネレータ1022は変換のDAGを実行する。この変換は、RDDオブジェクトに対して実行すべき1つ以上の動作を特定し、RDDオブジェクトにおけるデータをある形態から別の形態に変換することができる。これらの動作は、たとえば、アプリケーションデプロイモジュール1008によってアプリケーション生成プロセスの一部として定められてもよい。RDDオブジェクトに動作が適用されると、変換後のデータとともに新たなRDDオブジェクトが得られる。RDDオブジェクトに対して実行される動作の例は、たとえば、map、filter、flatMap、reduce、union、groupByKey、distinct、join、collect、count等を含み得る。CQL言語を要する変換のD
AGを本明細書ではCQL変換と呼ぶ場合がある。
【0129】
DAGスケジューラ1024は、DAGジェネレータが生成したRDDオブジェクトリネージグラフに基づいて物理実行プランを生成するように構成される。一実施形態において、DAGスケジューラ1024は、RDDリネージグラフを複数の段に分割することによって物理実行プランを生成し、各段は、各RDDオブジェクトにおけるデータに対して実行する必要がある変換に基づいて特定される。たとえば、RDDオブジェクトに対して実行すべき変換がmap変換およびreduce変換を含む場合、map変換は、ある段にグループ化してもよく、reduce変換は、別の段にグループ化してもよい。次に、DAGスケジューラ1024は、これらの段をタスクスケジューラ1026にサブミットする。
【0130】
タスクスケジューラ1026は、アプリケーション(ジョブ)を複数の段に分割する。各段は1つ以上のタスクからなる。一実施形態において、特定の段のタスクの数は、RDDオブジェクトにおける入力データのパーティションの数に基づいて決まる。たとえば、上述のように、DAGスケジューラ1024は、すべてのmap動作を1つの段にスケジュ
ーリングしてもよい。次に、これらの段はタスクスケジューラ1026に送られ、タスクスケジューラ1026はリソースマネージャを介してタスクを開始する。次に、タスクがエグゼキュータノード1018によって実行される。タスクスケジューラ1026は、各RDDオブジェクト(すなわち処理中のイベントの各バッチ)に対するアプリケーション(ジョブ)において定められている動作を実行するコンピューティングノードのクラスタ1012におけるノードを特定する。
【0131】
特定の実施形態において、エグゼキュータノード1018は、RDDオブジェクトを受
信すると、コンピューティングノードのクラスタにおける他のエグゼキュータ(ワーカー)ノードにRDDオブジェクトを送信する必要がある場合は、RDDオブジェクトにおけるデータのシリアライズおよびデシリアライズを実行する。上述のように、RDDオブジェクトにおけるデータの処理は、アプリケーションにおいて定められている1つ以上の連続クエリの実行を必要とする場合がある。ある実施形態において、タスクスケジューラ1026が特定したエグゼキュータノード(たとえば1018)は、CQLエンジン(CQLプロセッサ230等)を呼び出してRDDオブジェクトにおけるデータの処理を実行し、この処理の結果をマスタコンピューティングノード1014に返す。エグゼキュータノード1018がその処理に先立ってRDDオブジェクト内のデータのシリアライズおよびデシリアライズを実行し得る手法は、以下において図11との関連で詳細に説明する。
【0132】
図11は、本開示の実施形態に係る、RDDオブジェクトにおけるデータのシリアライズおよびデシリアライズを実行するためのプロセスのハイレベルデータフローを示す。特定の例において、図10における1つ以上の動作は、コンピューティングノードのクラスタにおけるノード(たとえばマスタノードまたはエグゼキュータノード)が、処理のために受信機からRDDオブジェクトを受けたときに、実行することができる。一組の動作において、受信機1102は、入力データストリームを受信し、入力データストリームを、特定期間(たとえばX秒)のイベント(タプル)の1つ以上のバッチに分割する。ある実施形態において、図10との関連で述べたように、イベント(タプル)の各バッチは、内部で受信機によってRDDオブジェクトとして表すことができる。DAGジェネレータ1104は、RDDオブジェクトを受信し、RDDオブジェクトのDAG1106を生成する。図10に記載のように、特定の例において、RDDオブジェクトのDAG1106は、各RDDオブジェクトに対して実行すべきCQL変換1108を含む。マスタコンピューティングノード(たとえば図10に示す1014)は、アプリケーションにおいてジョブを実行することを要求され、DAGジェネレータ1104は、CQL変換1108を実行し、RDDオブジェクトによって表される入力タプルのセットを処理する。いくつかの例において、処理すべき入力タプルのセットは、CQL変換1108の親(parent)変換から得られる。次に、CQL変換の子(child)変換は、CQL変換1108において表
される入力タプルのセットに対して実行すべき特定の動作を呼び出す。
【0133】
特定の例において、CQL変換1108は、RDDオブジェクトにおける入力タプルのセットに対するバッチシリアライザプロセス1112を呼び出してRDDオブジェクトにおけるデータのシリアライズを実行する。ある実施形態において、バッチシリアライザプロセス1112は、RDDオブジェクトを処理しているコンピューティングノードのクラスタにおけるノード(たとえばエグゼキュータノード)によって実行されてもよい。上述のように、RDDオブジェクトにおけるデータは、イベントストリームを介して受信した入力タプル(イベント)のバッチを表す。バッチシリアライザプロセス1112は、RDDオブジェクトにおけるデータをシリアライズし、バッチシリアライザプロセスから得られた結果のシリアライズされたブロックは、入力タプルのセットを処理するためにネットワークを通してCQLエンジン1116に送られる。特定の実施形態において、RDDオブジェクトを処理しているノードは、CQLエンジン1116を呼び出してRDDオブジェクトにおける入力タプルのセットを処理する。CQLエンジン1116は、たとえば、エグゼキュータノード上にデプロイされたイベント処理エンジン(たとえば図6に記載の630)であってもよい。CQLエンジン1116は、入力タプルのセットを受信し、アプリケーションにおいて定められた処理ロジック(動作/変換)に基づいて入力タプルのセットを処理し、この処理の結果として出力タプルのセットを生成するように構成し得る。
【0134】
特定の実施形態において、CQLエンジン1116は、RDDオブジェクトにおけるデータの処理に先立って、バッチシリアライザプロセス1112から受けたデータのシリア
ライズされたブロックに対するバッチデシリアライザプロセス1114を呼び出すことができる。シリアライズされたブロックはネットワークを通して転送するのに適したバイナリフォーマットまたはワイヤフォーマットであり、CQLエンジン1116が処理できるようにするためにはJAVAオブジェクトとしてデシリアライズされる必要があるからである。CQLエンジン1116は、入力タプルのセットを処理し、この処理に基づいて出力タプルのセットを生成する。特定の例において、CQLエンジン1116は、出力タプルのセットをシリアライズするために別のバッチシリアライザプロセス1118を呼び出し、シリアライズの結果は出力タプルのシリアライズされたブロックである。DAGジェネレータがシリアライズされた出力タプルのセットを受けると、CQL変換1108は、受けた出力タプルのシリアライズされたブロックに対する別のバッチデシリアライザプロセス1120を呼び出す。バッチデシリアライザプロセス1120の結果は、デシリアライズされた出力タプルのセットである。CQL変換1108は、出力タプルのセットをCQL変換における子変換に戻し、RDDオブジェクトにおけるデータに対して次の一組の処理動作を実行する。いくつかの実施形態において、その後、出力タプルのセット1110は分散イベント処理システムのユーザに送信される。
【0135】
特定の実施形態において、上述のバッチシリアライザプロセスおよびバッチデシリアライザプロセスは、RDDオブジェクトを処理している分散イベント処理システムにおけるノードのクラスタのうちのノード(たとえばエグゼキュータノード)によって実行される、ソフトウェアモジュールまたは命令によって実施されてもよい。バッチシリアライザプロセスおよびバッチデシリアライザプロセスによって実行される動作のその他の詳細は、以下において図12図15との関連で詳しく説明する。
【0136】
図12は、本開示の実施形態に係る、イベントのバッチに含まれるデータをシリアライズできる一組の動作を説明する、プロセス1200のフロー図の一例である。特定の実施形態おいて、プロセス1200は、分散イベント処理システムにおけるバッチシリアライザプロセス(1112)によって実行されてもよい。上述のように、いくつかの実施形態において、バッチシリアライザプロセスは、アプリケーションにおいて定められたジョブ/動作を実行することを、マスタコンピューティングノード(たとえば図10に示される1014)が要求されたときに、マスタコンピューティングノードによって呼び出されてもよい。先に述べたように、マスタコンピューティングノードは、分散コンピューティングシステム1002におけるコンピューティングノードのクラスタ1012の中のノード(たとえばエグゼキュータノード1018)を特定し、アプリケーションにおいて定められたジョブ/動作に対するイベントのバッチを処理し、この処理の結果として出力イベントのセットを生成する。特定の実施形態において、イベントのバッチを処理することは、イベントのバッチにおけるデータのシリアライズを含み得る。図12のプロセスは、イベントのバッチにおけるデータをシリアライズできる1つの技術を説明する。図12に示す特定の一連の処理ステップは、限定を意図したものではない。代替の実施形態は、各種配置および組み合わせにおいて図12に示すステップよりも多くのまたは少ないステップを有し得る。
【0137】
特定の実施形態において、図12に記載の処理は、タスク1020(図10に示される)を介してイベントのバッチを受信するたびに、分散コンピューティングシステム1002におけるコンピューティングノードのクラスタ1012の中のノードによって実行されてもよい。このプロセスは、1204においてCQL変換1108からイベントのバッチを受信したときに1202で開始される。特定の例において、イベントのバッチにおける各イベントはタプルと呼ぶ場合があり、イベントのバッチは、入力タプルのバッチまたは入力タプルのセットと呼ぶ場合がある。上述のように、イベントストリームを介して受信する各イベントは、イベントストリームに対応付けられたスキーマに従っており、このスキーマは、イベントストリームを介して受信した各イベントの1つ以上の属性を特定する
【0138】
たとえば、連続イベントストリームは、ある企業が販売する製品に関する製品関連情報を表していてもよく、このイベントストリームにおける各イベントは、商品に対するオーダーを表していてもよい。このような連続イベントストリームは、商品に関する、オーダー識別子(order identifier)、オーダーステータス(order status)、およびオーダー量(order amount)等の属性を含み得る。このような入力ストリームに対するスキーマは、S(timestamp, <orderId>, <orderStatus>, <orderAmount>)として表すことができる。
このようなストリームを介して受信した各イベントはしたがって、タイムスタンプと3つの属性とによって特定されるであろう。特定の実施形態において、イベントの1つ以上の属性を、入力タプルのセット(イベントのバッチ)における1つ以上のカラムで表すことができる。したがって、いくつかの例において、属性は、入力タプルのセットにおけるあるタプル(イベント)のデータ値を格納するカラムを指していてもよい。
【0139】
1206において、プロセスは、イベントのバッチにおけるイベントの属性(たとえば第1の属性)を特定することを含む。1208において、プロセスは、属性のデータタイプを特定することを含む。たとえば、上記オーダー処理ストリームの例ごとに、1206および1208のプロセスは、属性がイベントの「orderId」に対応すること、および、
属性のデータタイプが数値データタイプであることを確認してもよい。1210において、プロセスは、属性のデータタイプが数値データタイプか否かを判断することを含む。特定された属性のデータタイプが数値データタイプである場合、特定の実施形態において、プロセスは1212に進んで属性が表すデータ値に対して第1のタイプのデータ圧縮を実行すると判断する。たとえば、1212において、プロセスは、属性が表すデータ値に対し、数値圧縮技術(たとえば、ベース値圧縮、精度低減圧縮、または精度低減値インデックス)を適用すると判断する。1214において、プロセスは、属性によって格納されたデータ値に対して数値圧縮技術を適用した結果として、属性のシリアライズされたデータ値のセットを生成することを含む。イベントの数値属性に対してシリアライズされたデータ値のセットを生成するプロセスは、図13A図13B図13C、および図13Dに記載される。1216において、プロセスは、属性が表すシリアライズされたデータ値のセットを格納することを含む。
【0140】
特定の実施形態では、1218において、プロセスは、処理する必要があるイベントのその他の属性があるか否かを判断することを含む。処理すべきその他の属性がある場合、プロセスは、1206にループバックしてイベントバッチにおけるイベントの次の属性(たとえば第2の属性)を特定し、1208~516のプロセスを次の属性に対して実行する。
【0141】
特定の実施形態において、1210で属性の特定されたデータタイプが数値データタイプであると判断されなかった場合、特定の実施形態において、プロセスは1220に進み、属性が表すデータ値に対して第2のタイプのデータ圧縮を実行すると判断する。たとえば、上記オーダー処理ストリームの例において、1206および1208におけるプロセスは、イベントの第2の属性が「orderStatus」属性に対応すること、および、この属性
のデータタイプは非数値データタイプであることとを確認してもよい。この場合、プロセスは、1220に進んで、属性が格納するデータ値に対して第2のタイプのデータ圧縮を実施すると判断する。ある実施形態において、第2のタイプのデータ圧縮は、第1のタイプのデータ圧縮とは異なっていてもよい。たとえば、1220におけるプロセスは、属性が格納するデータ値に対し、非数値圧縮技術(たとえば値インデックス圧縮)を適用すべきであると判断してもよい。1214において、プロセスは、属性が格納するデータ値に対して非数値圧縮技術を適用した結果として、属性が表すシリアライズされたデータ値のセットを生成することを含む。イベントの非数値属性に対してシリアライズされたデータ
値のセットを生成し得るプロセスは図14に記載されている。1216で、プロセスは、属性が表すシリアライズされたデータ値のセットを格納することを含む。
【0142】
特定の実施形態において、プロセスは続いて1218に進み、特定し処理すべきイベントの他の属性があるか否かを判断する。より多くの属性がある場合、プロセスは1206にループバックしてイベントのバッチにおけるイベントの第3の属性を特定する。次に、このプロセスは1208において第3の属性のデータタイプを特定してもよく、このプロセスは、1210において、第3の属性のデータタイプに基づいて第3の属性が格納するデータ値に対して実行する第3のタイプのデータ圧縮を決定することを含み得る。たとえば、上記オーダー処理イベントストリームの例の場合、第3のタイプのデータ圧縮は、属性のデータタイプに基づいて「orderAmount」が格納するデータ値に対して実行してもよ
い。特定の例において、イベントのすべての属性が特定および処理されると、プロセスは1222で終了する。
【0143】
図13Aは、本開示の実施形態に係る、イベントの数値属性のシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセス1300のフロー図の一例である。ある実施形態において、プロセス1300は、図12の1214におけるプロセスによって実行される動作のさらに他の詳細を説明する。特定の例において、プロセス1300は、1302において、そのデータ値が処理されているカラムの現在のカラム番号(たとえば第1の属性)に対する現在のバッファオフセットを格納することで、開始される。1304で、プロセスは、属性のデータタイプ(カラムタイプ)を取得することを含む。たとえば、この場合の属性のデータタイプは、数値属性であると判断することができる。1306において、プロセスは、入力タプルのセットをスキャンすることにより、最小値、最大値、および属性によって表される一組の固有値を取得することを含む。1308において、プロセスは、範囲(最大~最小)からの属性によって表されるデータ値を格納するのに必要なビット数を計算することを含む。1309において、プロセスは、必要なビット数は属性のデータタイプのビット数の2分の1よりも大きいか否か、および、一組の固有値のサイズは入力タプルの数/値_インデックス_しきい値(value_index_threshold)よりも小さいか否かを判断することを含み、値_インデックス_しきい値は設定
可能である。一例において、値_インデックス_しきい値は、デフォルト値としての11という値に設定することができる。大きい場合、プロセスは1350に進み、精度低減インデックス値圧縮技術を実行する。1310において、プロセスは、必要なビット数はカラムの元のデータタイプのビット数よりも小さいか否かを判断する。1310での検査は、シリアライズされたブロックのサイズが元のブロックから増大していないことを確認するために実行される。その理由は次の通りである。もし値の範囲をカバーするのに必要なビットが元のデータに必要なビットよりも多ければ、結果として値インデックス技術を用いて生成されたブロックは元のブロックサイズよりも大きい可能性があるからである。
【0144】
必要なビット数がカラムの元のデータタイプのビット数よりも少ない場合、プロセスは1312に進み、一組の固有値のサイズが入力タプル数/2よりも小さいか否かを判断する。この判断は、圧縮レートが十分に大きいことを確実にするために実行される。特定の例において、固有値が多すぎる場合、値と値に対するインデックスとを使用する代わりに値そのものを使用する。必要なビット数がカラムの元のデータタイプよりも少なくかつ一組の固有値のサイズが入力タプル数/2よりも少ない場合、1314-626に記載のプロセスが実行される。
【0145】
たとえば、1314において、プロセスは、データ圧縮の精度低減値インデックスタイプとして属性によって表されるデータ値に対して実行すべき第1のタイプのデータ圧縮を格納することを含む。精度低減技術は、値の範囲を発見することによって使用される値からの値を表すビットを低減する。1316において、プロセスは、属性の最小データ値を
格納することを含む。1318において、プロセスは、最小値ごとにビット数を格納することを含む。1320において、プロセスは、そのデータ値が現在処理値であるカラム(たとえば属性)の各データ値に対して1322および1324における動作を実行することを含む。たとえば、1322において、プロセスは、一組の固有データ値からインデックスを取得することを含む。1324において、プロセスは、インデックスをバッファに格納することを含む。カラムのすべてのデータ値が処理された後、プロセスは、1326において、タプルのセットにおける固有値ごとに(固有値-最小値)を格納することを含む。これらの値は、ステップ1324で格納されたインデックスからインデックスされた実際の値を表す。
【0146】
特定の実施形態において、プロセスが1312において一組の固有値のサイズが入力タプル数/2よりも小さくないと判断した場合、いくつかの実施形態において、以下で説明する図13Bのプロセス1332-638が実行される。特定の実施形態において、プロセスが1310において必要なビット数がカラムの元のデータタイプよりも小さくないと判断した場合、一実施形態において、図13Cに記載の1342-646に記載のプロセスが実行される。特定の実施形態において、プロセスは、1328において、属性のシリアライズされたデータ値のセット(すなわちデータのシリアライズされたブロック)を、イベントストリームを介して受信したタプルのセット(すなわちイベントのバッチ)を処理するために、CQLエンジンに返すことにより、終了する。
【0147】
図13Bは、本開示の実施形態に係る、精度低減圧縮技術を用いてイベントの数値属性のシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセス1350のフロー図の一例である。ある実施形態において、プロセス1350は、図13Aのプロセス1330によって実行される動作のその他の詳細を説明する。特定の例において、プロセス1350は、1332において、精度低減圧縮として、属性によって表されるデータ値に対して実行すべきデータ圧縮のタイプを格納することにより、開始される。1334において、プロセスは、属性の最小データ値を格納することを含む。1336において、プロセスは、属性のデータ値当たりのビット数を格納することを含む。1338において、プロセスは、カラムのデータ値ごとに、必要なビットについてのみ、ビットコピー(値-最小)を実行することを含む。たとえば、一組の入力値(10,11,12)は、(10-10(最小値))の結果である値0に対するビット00、(11-10)の結果である値1に対するビット01、および、(12-10)の結果である値2に対するビット02とともに、格納される。ビット値00、01、および02のシーケンスは、バイト(8ビット)00010200に格納し、16進数値の154として格納することができる。
【0148】
図13Cは、本開示の実施形態に係る、通常の圧縮技術を用いてイベントの数値属性のシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセス1360のフロー図の一例である。ある実施形態において、プロセス1360は、図13Aの1340におけるプロセスによって実行される動作のその他の詳細を説明する。特定の例において、プロセス1360は、1342において、一般圧縮タイプとして、属性によって表されるデータ値に対して実行される第1のタイプのデータ圧縮を格納することにより、開始される。1344において、プロセスは、zipまたはgzip等の標準圧縮技術を用
いてカラム値のアレイを圧縮することを含む。1346において、プロセスは、属性が表すデータ値の圧縮されたバイトを格納することを含む。
【0149】
図13Dは、本開示の実施形態に係る、精度低減値インデックス圧縮技術を用いてイベントの数値属性のシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセス1370のフロー図の一例である。ある実施形態において、プロセス1370は、図13Aの1350におけるプロセスによって実行される動作のその他の詳細を
説明する。特定の例において、プロセス1370は、1372において、精度低減インデックス値圧縮として、属性によって表されるデータ値に対して実行すべきデータ圧縮のタイプを格納することにより、開始される。1374において、差分値セット(たとえば値-最小値)が計算される。1376において、プロセスは、差分値セットにおけるすべての値をスキャンすることにより列挙された値のセットを取得することを含む。1378において、プロセスは、差分値セットによって表される各データ値についてインデックスのセットを計算することを含む。1380において、プロセスは、インデックスのセットから最大および最小値を計算することを含む。1382において、プロセスは、属性の最小データ値を格納することを含む。1384において、プロセスは、インデックス値のデータ値当たりのビット数を格納することを含む。1386において、プロセスは、カラムの各データ値について、必要ビットに対してビットコピーのみを実行することを含む。1388において、プロセスは、列挙された差分値のセットを格納することを含む。
【0150】
図14は、本開示の実施形態に係る、イベントの非数値属性のシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセス1400のフロー図の一例である。ある実施形態において、プロセス1400は、属性(たとえば非数値属性)によって表されるデータ値に対して第2のタイプのデータ圧縮を実行すべきと判断された場合に図12のプロセス1214によって実行される動作のその他の詳細を説明する。プロセス1400は、1402において、そのデータ値が処理中であるカラム(たとえば属性)の現在のカラム番号に対する現在のバッファオフセットを格納することにより、開始される。1404において、属性のデータタイプ(カラムタイプ)を取得する。たとえば、この場合、属性のデータタイプは非数値属性であると判断される。1406において、プロセスは、値インデックス圧縮として、属性によって表されるデータ値に対して実行すべきデータ圧縮のタイプを格納する。この場合、入力のバッチ内の可能なすべての値が列挙され、値を複数回コピーするのではなく、場所のインデックスを使用する。
【0151】
1408において、プロセスは、カラムの列挙された値のセットを取得するためにすべての入力タプルをスキャンすることを含む。1410において、プロセスは、カラムによって表される各データ値についてインデックスのセットを計算することを含む。1412において、プロセスは、カラムに格納されている各データ値について、以下で1414-716で説明する動作を実行することを含む。1414において、プロセスは、列挙された値のセットからインデックスを取得することを含む。1416において、プロセスは、インデックスをバッファに格納することを含む。1418において、プロセスは、列挙された値のセットを格納することを含む。1420において、プロセスは、イベントストリームを介して受信したタプルのセット(すなわちイベントのバッチ)を処理するために、CQLエンジンに、属性についてのデータ値のセット(すなわちデータのシリアライズされたブロック)を返すことにより、終了する。
【0152】
図15は、本開示の実施形態に係る、イベントストリームにおけるイベントの属性のデータタイプの判断に基づいてイベントストリームデータをシリアライズできる手法の一例である。以下に示す例において、イベントストリームは、ある企業が販売する製品に関する製品関連情報を表す。イベントストリーム内の各イベントは、商品に対するオーダーを表していてもよく、商品に関する、オーダー識別子、オーダーステータス、およびオーダー量等の属性を含み得る。このようなオーダーイベントストリームに対するスキーマは、S(timestamp, <orderId>, <orderStatus>, <orderAmount>)として表すことができる。こ
のようなストリームを介して受信した各イベントはしたがって、タイムスタンプと3つの属性とによって特定できる。一例として、オーダーイベントストリームを介して受信するイベントのバッチは、以下のイベントと、対応付けられたタイムスタンプとを含み得る。
【0153】
【数5】
【0154】
上述のように、特定の実施形態において、イベントの1つ以上の属性は、イベントのバッチを表す入力タプルのセットにおける1つ以上のカラムとして表すことができる。よって、いくつかの例において、属性は、入力タプルのセットにおけるタプル(イベント)のデータ値を格納するカラムを指す場合がある。オーダーイベントストリームを介して受信するイベントのバッチに対応する入力タプルのセットの一例を以下の表1に示す。
【0155】
【表1】
【0156】
特定の実施形態において、イベントバッチにおけるイベントは、イベントの各属性のデータタイプを特定し、属性のデータタイプに基づいて各属性が表すデータ値に適用すべき特定種類の圧縮技術を判断することにより、シリアライズされる。たとえば、第1の圧縮技術を、第1の属性は数値属性であるという判断に基づいてイベントの第1の属性(たと
えばオーダーid属性)に適用してもよく、第2の圧縮技術を、第2の属性が非数値属性であるという判断に基づいてイベントの第2の属性(たとえばオーダーステータス属性)に適用してもよく、第3の圧縮技術を、第3の属性は数値属性であるという判断に基づいてイベントの第3の属性(たとえばオーダー量属性)に適用してもよい。特定の例において、第1のタイプの圧縮技術、第2のタイプの圧縮技術、および第3のタイプの圧縮技術は、互いに異なっていてもよい。
【0157】
ある実施形態において、カラムストレージを用いて、カラム内の値が同一データタイプになるように、同一のデータタイプを有する属性(カラム)を格納することができる。特定の実施形態において、数値タイプのカラムに格納された値は、ベース値圧縮技術または精度低減圧縮技術を用いて圧縮することができる。精度低減は、値の範囲を発見することにより、使用値からの値を表すビットを低減する。必要なビットは値の範囲に応じて決まる。ベース値圧縮は、ベース値として最小値を使用し、その他の値からのベース値からの差分を格納する。たとえば、イベントバッチ(10,11,10,10,11,10,11,11)における各イベントの「オーダーid」を表す一組の入力値を、(10,1)、2進数01001011、または16進数0×4Bに圧縮できる。これは、32ビットから2ビットに減じられたビットを用いて値(0,1,0,0,1,0,1,1)を表す。なぜなら、最小値は10、範囲は2であるからである。別の例として、「オーダー量」を表す一組の入力値は、精度低減および値インデックス技術を用いて圧縮できる。この場合、オーダー量を表す一組の入力値(100,5000,100,100,5000,100,5000,5000)は、精度低減技術および値インデックス技術双方を用いて(100,2,0×10,0×4F)および(0,4900)に圧縮できる。入力セットは、100をベース値とする(0,4900,0,0,4900,0,4900,4900)で表すことができる。結果セットの値は、2進数で00010000,01001111、16進数で10および4Fである。これは、ベース値テーブル(0,4900)に対するインデックスを有する(0,1,0,0,1,0,1,1)を表す(たとえば、0は、0を指し、さらにベース値を100とするの100を指し、1は、4900を指し、さらにベース値を100とする5000を指す)。
【0158】
特定の実施形態において、「値インデックス圧縮」技術を用いて、ストリング値等の非数値を格納するカラムの値を処理してもよい。この場合において、入力のバッチ内の可能なすべての値を列挙し、値を複数回コピーする代わりに、場所のインデックスを用いる。たとえば、「オーダーステータス」属性(カラム)の値が、(open, open, processing, shipped, processing, closed, shipped, closed)である場合、対応する列挙された固有値は、(open, processing, shipped, closed)であろう。カラムの値が線形バッファに
連続的に格納される場合、各値のインデックスは(0,5,17,25)であろう。なぜなら、このバッファは、open/0processing/0shipped/0closed/0を有するであろうからで
ある。/0は、ストリングマーカの最後を示す。値の線形バッファを用いた場合の最終圧縮結果は、(0,0,5,17,5,25,17,25)である。
【0159】
図16は、本開示の実施形態に係る、イベントのバッチに含まれるデータをデシリアライズできる一組の動作を説明するプロセス1600のフロー図の一例である。特定の実施形態において、プロセス1600は、分散イベント処理システムにおけるバッチデシリアライザプロセス(420)によって実行することができる。上述のように、バッチデシリアライザプロセスは、特定の実施形態において、アプリケーションにおいて定められたジョブ/動作を実行することをマスタコンピューティングノード(たとえば図3に示す314)が要求されたときに、マスタコンピューティングノードが呼び出してもよい。上述のように、マスタコンピューティングノードは、分散コンピューティングシステム302におけるコンピューティングノードのクラスタ312のノード(たとえばエグゼキュータノード318)を特定し、アプリケーションにおいて定められたジョブ/動作に対してイベ
ントのバッチを処理し、処理の結果として出力イベントのセットを生成する。特定の実施形態において、イベントのバッチを処理することは、イベントのバッチにおけるデータのシリアライズとその後のデシリアライズとを含み得る。図16のプロセスは、イベントのバッチにおけるデータをデシリアライズできる技術を説明する。図16に示す特定の一連の処理ステップは、限定を意図したものではない。代替の実施形態は、各種配置および組み合わせにおいて図16に示すステップよりも多くのまたは少ないステップを有し得る。
【0160】
特定の実施形態において、プロセス1600は、1602において、イベントのバッチ(入力タプルのセット)におけるイベントの1つ以上の属性に対応するシリアライズされたデータ値のセットを受信することで開始される。1604において、プロセスは、イベントのバッチにおけるイベントの1つ以上の属性に対応するシリアライズされたデータ値のセットを処理することにより、出力イベントのセットを生成する。特定の例において、1604におけるプロセスは、1606における、シリアライズされたデータ値のセットに基づいて属性に対応するデシリアライズされたデータ値のセットを生成することと、1608における、1つ以上の連続クエリのセットに対して属性に対応するデシリアライズされたデータ値のセットを処理することにより、出力イベントの第1のセットを生成することとを含み得る。1610において、プロセスは、出力イベントのセットを分散イベント処理システムのユーザに送信することを含む。
【0161】
イベントのバッチにおけるイベントの属性に対応するデシリアライズされたデータ値のセットを生成するプロセス1604を、以下で図17図14との関連で詳細に説明する。具体的には、図17は、イベントのバッチにおけるイベントの1つ以上の属性に対応するデシリアライズされたデータ値のセットを生成できるプロセスを説明している。図18は、イベントの非数値属性に対応するデシリアライズされたデータ値のセットを生成できるプロセスを説明している。図19図14は、イベントの数値属性に対応するデシリアライズされたデータ値のセットを生成できるプロセスを説明している。
【0162】
図17は、本開示の実施形態に係る、イベントのバッチにおけるイベントの1つ以上の属性のデシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセス1700のフロー図の一例である。ある実施形態において、プロセス1700は、図16の1604におけるプロセスの動作のその他の詳細を説明する。特定の例において、プロセス1700は、1702においてタプルのアレイを生成することによって開始される。1704において、プロセスは、イベントの第1のカラム(第1の属性)を特定することを含む。1706において、プロセスは、そのデータ値が処理されているカラム(たとえば第1の属性)の現在のカラム番号のバッファオフセットを取得することを含む。1708において、プロセスは、属性の圧縮タイプを読み取ることを含む。これは、たとえば、属性のデータ値をシリアライズするためにバッチシリアライザプロセスによって実行されたデータ圧縮のタイプを読み取ることを含む。1710において、プロセスは、属性に適用されるデータ圧縮のタイプが値インデックス圧縮であるか否かを判断することを含む。属性に適用される圧縮タイプが値インデックス圧縮である場合、プロセスは、1724に進み、図18に記載のプロセスを実行する。
【0163】
1712において、プロセスは、属性に適用されるデータ圧縮のタイプが精度低減圧縮であるか否かを判断することを含む。属性に適用される圧縮タイプが精度低減圧縮である場合、プロセスは、1726に進み、図19に記載のプロセスを実行する。
【0164】
特定の実施形態では、1714において、プロセスは、属性に適用されるデータ圧縮タイプのタイプが精度低減値インデックス圧縮であるか否かを判断することを含む。属性に適用される圧縮タイプが精度低減値インデックス圧縮である場合、プロセスは、1728に進み、図20に記載のプロセスを実行する。
【0165】
特定の実施形態において、プロセスが、属性に適用される圧縮タイプは、値インデックス圧縮、精度低減圧縮、および精度低減値インデックス圧縮のうちのいずれでもないと判断した場合、プロセスは、1716に進み、属性に適用される圧縮タイプは一般的な圧縮であると判断する。1716において、プロセスは、図21に記載のプロセスを実行することを含む。
【0166】
1718において、プロセスは、処理すべき他の属性があるか否かを判断することを含む。処理すべき他の属性がある場合、プロセスは、1704にループバックしてイベントの次の属性を特定し処理する。処理すべき属性がない場合、いくつかの実施形態において、プロセスは、1720においてさらに処理するためにタプルのアレイをCQLエンジンに返す。特定の実施形態において、プロセスは1722で終了する。
【0167】
図18は、本開示の実施形態に係る、値インデックス圧縮を用いてイベントのバッチにおけるイベントの数値属性または非数値属性に対応する、デシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセス1800のフロー図の一例である。ある実施形態において、プロセス1810は、図17のプロセス1724のその他の詳細を説明し、属性に適用されるデータ圧縮のタイプが「値インデックス」圧縮であると判断された場合(たとえば図17の1710)に実行される。一例として、プロセス1800は、オーダーイベントストリームにおける「オーダーステータス」属性(非数値属性)に対して実行することができる。
【0168】
値インデックス圧縮技術を用いる例は、図8、カラム2に示される。圧縮された値は、2セットのデータとして、(0,0,5,17,5,25,17,25)と、(‘open’,’processing’,’shipped’,’closed’)とを有する。第2のセットは、実際の値を有するので、value_arraysと呼ぶ。第1のセットは、value_arraysに格納される実際の値に対するインデックス値を含むので、index_valuesと呼ぶ。value_indexは、index_values
における個々のインデックス値各々を指す。
【0169】
特定の実施形態において、プロセス1800は、1802において、インデックス値をindex_valuesに読み込むことによって開始される。1804において、プロセスは、値アレイをvalue_arrayに読み込むことを含む。1806において、プロセスは、入力タプル
のセットにおける属性に対応する各データ値に対し、1808、1810、および1812の動作を実行することを含む。たとえば、1808において、プロセスは、index_values[value_index]からインデックスを取得することを含む。1810において、プロセス
は、value_array[index]から値を取得することを含む。1812において、プロセスは、tuples[value_index]のタプルカラムに値をセットすることを含む。
【0170】
図19は、本開示の実施形態に係る、精度低減圧縮技術を用いてイベントのバッチにおけるイベントの数値属性に対応する、デシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセス1900のフロー図の一例である。ある実施形態において、プロセス1900は、図17のプロセス1726のその他の詳細を説明し、属性に適用されるデータ圧縮のタイプが「精度低減」圧縮であると判断されたときに(たとえば図17の1712)実行される。一例として、プロセス1900は、オーダーイベントストリームにおける「オーダーid」または「オーダー量」属性(数値属性)に対して実行することができ、圧縮結果が図8、カラム1に示され、(10,2,0×4B)である。一例として、下記一組の動作において、用語「最小値」は、値の範囲の最小値である値17を有し、用語「ビット数」は、値の範囲を表すビット数である値2を有する。
【0171】
特定の実施形態において、プロセス1900は、1902において、最小値をbase_val
ueに読み込むことによって開始される。1904において、プロセスは、ビット数を読み取ることを含む。1906において、プロセスは、入力タプルのセットにおける属性に対応する各データ値について1908および1910のプロセスを実行することを含む。たとえば、1908において、プロセスは、値ビットをvalue_bitsに読み込むことを含む。1910において、プロセスは、base_value+value_bitsを、tuples[value_index]のタプルカラムにセットすることを含む。
【0172】
図20は、本開示の実施形態に係る、精度低減値インデックスを用いて、イベントのバッチにおけるイベントの数値属性に対応する、デシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセス2000のフロー図の一例である。ある実施形態において、プロセス2000は、図17のプロセス1728のその他の詳細を説明し、属性に適用されるデータ圧縮のタイプが「精度低減値インデックス」圧縮であると判断されたときに(たとえば図17の1712)実行される。一例として、プロセス2000は、オーダーイベントストリームにおける「オーダーid」または「オーダー量」属性(数値属性)に対して実行することができる。図8は、カラム3において、「オーダー量属性」についての結果の一例を示し、結果は(100,2,0×10,0×4F)および(0,4900)である。
【0173】
下記一組の動作において、用語「ベース値」は、カラム値のベース値の値170を指し、用語「ビット数」は、インデックス値のビット数の値2を指し、用語「index_values」は、インデックス値の値(0×10,0×4F)を指し、用語「value_array」は、一組
の異なる値を表す(0,4900)を指す。
【0174】
特定の実施形態において、プロセス2000は、2002において、最小値をbase_valueに読み込むことによって開始される。2004において、プロセスは、ビット数を読み取ることを含む。2006において、プロセスは、インデックス値をindex_valuesに読み込むことを含む。2008において、プロセスは、値アレイをvalue_arrayに読み込むこ
とを含む。2010において、プロセスは、j←0 to value_array.lengthの各値に対し、value_array[j]をvalue_array[j] + base_valueにセットすることを含む。2012にお
いて、プロセスは、入力タプルのセットにおける属性に対応する各データ値に対し、2014、2016、および2018のプロセスを実行することを含む。たとえば、2014において、プロセスは、index_values[value_index]からインデックスを取得することを
含む。2016において、プロセスは、value_array[index]から値を取得することを含む。2018において、プロセスは、tuples[value_index]のタプルカラムに値をセットす
ることを含む。
【0175】
図21は、本開示の実施形態に係る、イベントのバッチにおけるイベントの数値属性または非数値属性に対応する、デシリアライズされたデータ値のセットを生成するための一組の動作を説明するプロセス2100のフロー図の一例である。ある実施形態において、プロセス2100は図17のプロセス1716のその他の詳細を説明し、属性に適用されるデータ圧縮のタイプが「一般的な圧縮」技術であると判断されたときに(たとえば図18の1716)実行される。一例として、プロセス2100は、オーダーイベントストリームにおける「オーダーid」または「オーダー量」(数値属性)に対して実行することができる。下記一組の動作において、用語「値」は復元された値を指す。
【0176】
特定の実施形態において、プロセス2100は、2102において、ブロックを値のアレイに復元することによって開始される。2104において、プロセスは、入力タプルのセットにおける属性に対応する各データ値について、アレイにおける値をタプルのタプルカラムにセットすることを含む。
【0177】
マイクロバッチベースのイベント処理システム内の複数のCEPエンジンのスケジューリングおよび管理
近年、場合によっては無制限であるリアルタイムデータストリームにわたって連続的にクエリを実行できるデータストリーム管理システム(data stream management system)
(DSM)が開発された。新たなDSMのうち、これらのシステムは、1つのフレームワークからバッチ処理とストリーム処理との組み合わせを提供するために、マイクロバッチ方式ベースのストリーム処理を採用する。このようなシステムの一例は、Spark(登録商
標)プラットフォーム上で実行するSpark(登録商標) Streamingアプリケーションであ
る。
【0178】
マイクロバッチ方式のストリーム処理は、ステートフルな処理が一般的に複雑であるというシステム設計の性質を原因とするいくつかの欠点を有する。このような欠点の1つは、「パターンマッチング」動作を実行できないことである。パターンマッチングは、ストリーム処理システムがサポートすべき、望ましい重要な特徴であり、パターンマッチングは、ステートマシンを実行して無制限のイベントストリームからパターンを検出するために非常にステートフルな処理を必要とする。
【0179】
十分にステートフルなクエリ処理をサポートするために、開示される技術は、マイクロバッチ方式のストリーム処理にCQLクエリエンジンを追加する。クラスタ内には2つ以上のCQLエンジンが存在するので、スケジューリング、トラッキング、および局所性に関する問題に対処しなければならない。
【0180】
図22は、CQLエンジントラッカーにおけるスケジューリングプロセスを実現できるシステムまたはアーキテクチャの一例である。一実施形態において、以下の図22に示すように、CQLエンジン2212とCQLレジリエント分散データセット(RDD)2218との間において遠隔通信可能なドライバ(マスタ)2206内のCQLエンジントラッカー(CQL Engine Tracker)2202というコンポーネントが開示されている。起動およびスケジューリングのために、CQLEngineTracker2202は、2ステップのスケジューリングポリシーを用いることにより、異なるシステム環境を区別する。一実施形態において、局所性を最大にするために、CQLEngineTracker2202は以下のアフィニティアルゴリズムを使用する。
1.すべてのCQLEngine2212、2214、2216を、ドライバ2206のCQLEngineTracker2202によって起動する。好ましい場所に対するCQLEngineの対応付けは設定されない。
2.最初のCQLRDD2218は好ましい場所の情報を有しない。
3.スケジューラ2204は、親RDDを親RDDの好ましい場所を用いて配置できるホストに、ともに位置しようと試みる。
4.CQLRDD2218の最初の実行は、CQLEngine2212を同一のホスト2208に対応
付ける。
5.次のCQLRDD2220は、ステップ4からの対応付け情報セットから得た好ましい場所情報を設定する。
6.スケジューラ2204は、それが設定された好ましい場所にCQLRDDを走らせようと試みる。
【0181】
開示される技術により、マイクロバッチ方式のストリーム処理内で十分にステートフルなCQLEngine2212、2214、2216を有することができ、CQLEngineとCQLRDDとの間で局所性を保つことができ、CQLEngineを起動および再起動するためのマルチステップ
スケジューリングアルゴリズムが可能である。加えて、開示するローカルアフィニティアルゴリズムは、その他のイベントごとのストリーム処理システムと比較して最大の性能を提供する。
【0182】
特定の実施形態において、開示するCQLエンジントラッカー2202は、クラスタ内のCQLEngineをスケジューリングし、トラッキングし、再始動する役割を果たす。CQL
エンジンは、クラスタ内において長時間実行タスクとして実行され、通常のストリーミングジョブとして起動することができる。CQLエンジントラッカー2202は、障害という事態に遭遇したときを除いてリターンしない。
【0183】
いくつかの実施形態において、CQLエンジントラッカー2202による以下のトラッキング情報を維持することができる。
・state: CQLEngineState - INACTIVE, SCHEDULED, ACTIVE
-これは、CQLEngine2212、2214、2216のライフサイクルにわたり、INACTIVE -> SCHEDULED -> ACTIVE -> INACTIVEのように変化する。
・scheduleLocation : TaskLocation
-スケジュールされた最初の場所
・runningExecutor : ExecutorCacheTaskLocation
-CQLEngineが実際に実行されるエグゼキュータ2208の場所
・name : String
-CQLEngine2212、2214、2216の名称
・endpoint : RpcEndpointRef
-遠隔アクセスするためのCQLEngine2212、2214、2216の遠隔プロセスコ
ール(Remote Process Call)(RPC)
・errorInfo : CQLEngineErrorInfo
-最後に知られたエラー情報
ある実施形態において、CQLエンジン2212、2214、2216の起動フローは次のように説明できる。
・起動するCQLEngine2212、2214、2216の数を判断
・エグゼキュータ2208、2210、2212のリストを取得
・エグゼキュータ2208、2210、2212のリストにCQLEngine2212、221
4、2216をスケジューリングするためにラウンドロビンスケジューラを実行
・TaskScheduler2204が実際の長時間実行タスクを起動
・新たに起動したCQLEngineがCQLEngineTracker(たとえばCQLエンジントラッカー2
202)に対する「登録」RPCコールを呼び出す
特定の実施形態において、CQLEngine局所性アフィニティアルゴリズムは以下のプロセ
スによって説明することができる。
1.すべてのCQLEngineは、ドライバのCQLEngineTracker2202によって起動される。
好ましい場所に対するCQLEngineの対応付けは設定されない。
2.第1のCQLRDDは好ましい場所情報を有しない。
3.スケジューラは、親RDDを親RDDの好ましい場所を用いて配置できるホストに、ともに位置しようと試みる。
4.CQLRDDの最初の実行は、CQLEngineを同一のホストに対応付ける。
5.次のCQLRDDは、ステップ4からの対応付け情報セットから得た好ましい場所情報を設定する。
6.スケジューラは、それが設定された好ましい場所にCQLRDDを走らせようと試みる。
【0184】
ある実施形態において、CQLEngine再始動スケジューリングプロセスは次のように説明
することができる。
・2つのケース(リジェクト(Rejected)、クラッシュ(Crashed))を扱う
・リジェクト-スケジュール場所と実際の場所とが異なる場合(スケジュール通りに始動していない)
・schedulePolicy.rescheduleCQLEngineで、古いスケジューリングされたエグゼキュータ
(アクティブでないものを除く)または新しいスケジューリングされたエグゼキュータのいずれかを用いて、スケジューリングされたエグゼキュータを得る
-スケジューリングされた場所のリストにおいてまだ生きているエグゼキュータを選択・スケジューリングされたエグゼキュータでCQLEngineを始動
以下のフローは、上記アーキテクデャのデータフローを示す。
1.ドライバ2206におけるCQLEngineTracker2202は、CQLEngineごとに、長時間
実行タスクを起動する。CQLEngineTracker2202は、そのRPCEndpointを、長時間実行
タスクにエクスポーズする。
2.TaskScheduler2204は、クラスタ内のエグゼキュータ2208、2210、22
12に対する長時間実行タスクを実行する。
3.長時間実行タスクの一部として、CQLEngineはエグゼキュータ2208、2210、
2212から実行する。
4.CQLEngineは自身をCQLEngineのRPCEndpointとともにドライバ2206におけるCQLEngineTracker2202に登録する。
5.ストリーミングDAGの一部として、CEP処理を担当するCQLRDDがある。CQLRDDは、ローカルCQLEngineまたは遠隔CQLEngineいずれかにより、CQLEngineTrackerにコンサルティングすることによって処理される。遠隔CQLEngineはRPCを通して呼
び出される。
【0185】
CQLEngineの始動
CQLEngineは、クラスタ内の長時間実行タスクとして実行される。CQLEngineは、CQLEngineTrackerによって通常ジョブとして始動されるが、リターンすることはなく、障害またはクラッシュの場合を除いて実行を続ける。CQLEngineTrackerは、以下に記載のアルゴリズムに従い、クラスタ内のCQLEngineを起動する。
1.起動するCQLEngineの数を判断する
2.エグゼキュータのリストを取得する
3.ラウンドロビンスケジューラを実行し、エグゼキュータのリストに対してCQLEngine
をスケジューリングする
4.TaskSchedulerが実際の長時間実行タスクを起動する
5.新たに起動されたCQLEngineは、CQLEngineTrackerに対するRPCコール「登録」を
呼び出す
6.長時間実行タスクは、CQLEngineがクラッシュしたときまたはその他の障害の場合に
のみ、リターンする
ステップ1において、クラスタ内の起動するCQLEngineの数を判断する。クラスタ内のCQLEngineのデフォルト数は、クラスタ内のエグゼキュータの数と同一である。結果として、1つのCQLEngineが各エグゼキュータから実行される。CQLEngineの最大数を設定することができる。
【0186】
ステップ2において、エグゼキュータリスト情報(エグゼキュータホストおよびエグゼキュータid)をクラスタから取り出す。
【0187】
ステップ3において、ラウンドロビンスケジューラはCQLEngineにエグゼキュータを割
り当てる。
【0188】
ステップ4において、CQLEngineごとに長時間実行タスクを起動する。TaskSchedulerは、スケジューリングされたエグゼキュータ情報(エグゼキュータホストおよびid)を用いてスケジューリングされたエグゼキュータにおいてCQLEngineを始動する。
【0189】
ステップ5において、新たに起動されたCQLEngineは、CQLEngineTrackerに対するRP
Cコール「登録」を呼び出す。このステップは、以下に示すCQLEngineTrackerからトラッ
キングプロセスを開始する。
【0190】
ステップ6において、CQLEngineの故障またはクラッシュが、以下に示すCQLEngineTrackerからリカバリプロセスをトリガする。
【0191】
CQLEngineのトラッキング
いくつかの実施形態において、CQLエンジントラッカーによる以下のトラッキング情報は、CQLEngineごとに維持することができる。
state: CQLEngineState
scheduleLocation : TaskLocation
runningExecutor : ExecutorCacheTaskLocation
name : String
endpoint : RpcEndpointRef
errorInfo : CQLEngineErrorInfo
「state」は、CQLEngineの状態を保つ。これは、CQLEngineのライフサイクルを通して
、INACTIVE -> SCHEDULED -> ACTIVE -> INACTIVEのように変化する。INACTIVEは、CQLEngineTrackerによってCQLEngineがトラッキングされる前の初期状態である。SCHEDULEDは
、CQLEngineをエグゼキュータにおいて実行することがスケジューリングされたときの状
態である。ACTIVEは、CQLEngineが実際にエグゼキュータから実行されているときの状態
である。
【0192】
「scheduledLocation」は、CQLEngineを実行するとスケジューリングされた場所をキープする。
【0193】
「runningExecutor」は、CQLEngineが実際に実行されるエグゼキュータの場所をキープする。
【0194】
「name」は、識別子としてのCQLEngineの名称である。
「endpoint」は、通信対象のRPCEndpointである。
【0195】
「errorInfo」は、最後に知られたCQLEngineのエラー情報である。
CQLEngineのリカバリ
長時間実行タスクは、CQLEngineがクラッシュしたときまたはその他の障害の場合にの
み、コントロールをCQLEngineTrackerにリターンする。CQLEngineTrackerは、CQLEngine
を再始動するために、以下のCQLEngine再始動スケジューリングプロセスを用いる。再始
動スケジューリングプロセスは、リジェクトおよびクラッシュという2つのケースから呼び出される。
【0196】
クラッシュは、実行されているCQLEngineがクラッシュしたときまたは長時間実行タス
クが何らかの故障でリターンしたときのケースである。リジェクトは、スケジューリングされた場所と実際の場所とが異なっているときのケースである(たとえば、スケジューリングされたエグゼキュータから始動されずTaskSchedulerによって異なるエグゼキュータ
から始動される)。これは、クラスタからのリソースの問題を原因として起こり得る。
【0197】
ある実施形態において、CQLEngine再始動スケジューリングプロセスは以下のように説
明できる。
1.古いスケジューリングされたエグゼキュータ(アクティブでないものを除く)とクラスタ内の新たなエグゼキュータを用いて候補エグゼキュータのリストを取得
2.候補エグゼキュータのリストのにおいてまだ生きているエグゼキュータを選択
3.スケジューリングされたエグゼキュータを用いてCQLEngineを始動する長時間実行タ
スクを起動
局所性アフィニティアルゴリズム
水平スケーラビリティをサポートするために、入力データセットはパーティションされパラレル化分散データ処理によって処理される。CQLEngineは、CQLEngineに対する(queryId、partitionId)の対応付けまたはアフィニティを用いて複数のパーティションを処理することができる。エグゼキュータ間でデータを送信するためにネットワークトラフィックを最小にして変換を最適化するために、このアフィニティを局所性を最大にして生成する必要がある。局所性を最大にするために、一実施形態において、CQLEngineTrackerは以下のアフィニティアルゴリズムを使用する。
1.すべてのCQLEngineを、ドライバからのCQLEngineTrackerによって起動する。好まし
い場所に対するCQLEngineの対応付けは設定されない。
2.最初のCQLRDDは好ましい場所の情報を有しない。
3.Spark(登録商標)スケジューラは、親RDDを親RDDの好ましい場所を用いて配
置できるエグゼキュータに、ともに位置しようと試みる。
4.CQLRDDは、CQLEngineTrackerに対して「getCQLEngine」RPCを呼び出す。
5.CQLRDDのパーティションの最初の計算は、(partitionId, queryId)をCQLRDDの同一のエグゼキュータに対するCQLEngineに対応付ける。
6.CQLEngineに対する(PartitionId, queryId)の好ましい場所のマッピングをCQLEngineTrackerにおいて維持する。
7.対応付けからのCQLEngineはCQLRDDにリターンし、RDDをCQLEngineによって処理する。
8.次のCQLRDDは、ステップ5で設定された対応付け情報から好ましい位置情報を設定する。
9.Spark(登録商標)スケジューラは、設定した好ましい場所にCQLRDDを走らせようと
試みる。
10.CQLRDDはCQLEngineTrackerに対し「getCQLEngine」RPCを呼び出し、(partitionId, queryId)は既に同一のエグゼキュータであるはずである。
【0198】
図23は、本開示の実施形態に係る、マイクロバッチベースのイベント処理システムにおいて複数のCEPエンジンをスケジューリングし管理するための一組の動作を説明するプロセス2300のフロー図の一例である。ある実施形態において、プロセス2300は、図22に記載の動作のその他の詳細を説明する。特定の例において、プロセス2300は、CQLエンジンのクラスタにおける第1のCQLエンジンを起動することによって開始される。第1のCQLエンジンおよびその他のCQLエンジンは、CQLエンジントラッキングエンジンを用いて起動することができる。2304において、CQLエンジントラッキングエンジンはまた、アプリケーションに関連する入力イベントの連続ストリームのバッチを処理するために第1のCQLエンジンをスケジューリングすることができる。2306において、CQLエンジントラッキングエンジンはまた、実行のためにスケジューリングすべき第1のCQLエンジンをトラッキングすることができる。2308において、CQLエンジントラッキングエンジンはまた、第1のCQLエンジンを実行して入力イベントの連続ストリームのバッチを処理することにより、アプリケーションに関連する出力イベントのセットを生成することができる。
【0199】
Group ByおよびオブジェクトIDフィールドを用いた自動データパーティショニングおよびパラレル処理
近年、場合によっては無制限であるリアルタイムデータストリームにわたって連続的にクエリを実行できるデータストリーム管理システム(DSM)が開発された。たとえば、典型的なDSMは、1つ以上のデータストリームを受信し、データストリームに対するクエリを登録し、ストリーム内に新たなデータが現れるとクエリを連続的に実行することができる。この種の連続クエリは実行時間が長いので、DSMは、更新された結果の連続ス
トリームをクライアントに提供することができる。
【0200】
DSMにおける典型的なアプリケーションは、動作または変換の有向非巡回グラフ(DAG)の形態の「トポロジ」として設計される。このトポロジはデータ変換パイプラインとして作用する。
【0201】
Apache Storm、Spark Streaming、およびFlinkを含む多くのストリーム処理システムは、アプリケーション開発者が、Java、Scala、またはClojure等の異なるプログラミング言語を用いてトポロジを構築するための、アプリケーションプログラミングインターフェイス(Application Programming Interface)(API)を提供する。
【0202】
APIは、プログラマーがストリーム処理アプリケーションを構築するのに公的であるが、コード生成レイヤが複雑なので、Stream Analytics等のユーザのためのストリーム処理アプリケーションを生成するコード生成システムにとっては比較的複雑である。
【0203】
図24は、一例としてのアーキテクチャ2400であり、このアーキテクチャにおいて、データ変換の入力パイプラインを、パイプラインアナライザ2402に入力し段分類モジュール2404によって分類することができる。いくつかの例において、Stream Analyticsのコード生成レイヤは、パイプライン段を解析することによって自動的にデータ変換パイプラインにおけるパラレル処理を判断するという役割を担う。データ変換パイプラインは各種段で構成され、各段は段の定義に従って特定の変換を実行する。アグリゲータ段は、入来するストリームデータに対するリアルタイムアグリゲートを計算する。データ変換パイプライン処理は、パイプラインの段をノードのクラスタ上で実行できる場合、最適化することができる。
【0204】
ノードのクラスタ上の段を計算するためには、自動的に段の動作のパラレル処理の特徴を判断しその後変換のDAGを生成することが望ましい。変換の計算は、一組のクラスタノードについて、パラレル処理を最大にすることによって完了することができる。
【0205】
一実施形態において、ユーザが設計したデータ変換パイプラインを解析するデータストリーム管理システム(Data Stream Management System)(DSMS)が構築され、各種
段のパーティショニング基準を取り出し、変換の最適化されたDAGを生成する。各段は一組のクラスタノード上で実行することができる。
【0206】
特定の実施形態において、以下の段を、Stream Analyticsプラットフォームによって設計されたパイプラインに含めることができる。
1)クエリ
2)ビジネスルール
3)空間
4)パターン
パイプラインは、上記タイプの1つ以上の段で構成することができる。
【0207】
サンプルパイプラインの一例は以下の通りである。
入力 -> クエリ -> クエリ-> 空間 -> 出力
いくつかの例において、ユーザはパイプラインを作製することにより所望のビジネスロジックを得る。パイプラインを設計している間、ユーザは、パイプラインに対してすべての段を選択しパイプラインの段属性を構成する場合がある。いくつかの例において、段の構成属性は段のメタデータとなる。
【0208】
開示する技術は、段の種類がクエリである場合、段の自動データパーティショニングを
判断する。ユーザが作成したパイプラインをネイティブランタイム変換のDAGに変換するために、Stream Analyticsプラットフォームは以下のステップを実行することができる。
1)ソースからシンクまでパイプラインをトラバース
2)各段について、
i)段の種類を判断
ii)段の種類が「クエリ」であれば、プラットフォームは、この段について変換を分散方式で計算できるか否かをマークする
a)クエリ段に対応付けられたCQLクエリを判断
b)CQLクエリをトークンにパース
c)パースされたクエリのCQLクエリの意味解析を実行
d)各種ルールを用いてクエリ分類を判断
これらのルールは、連続クエリを、ステートレス、セミステートフル、フルステートフルというカテゴリに、分類
e)クエリがステートレスであれば、パーティショニング属性(基準)なしで、パーティショニングすべき段をマーク2406。このようにして、段は親の段のパーティショニング基準に依存する。
【0209】
f)クエリがステートフルであれば、パーティションしない段をマーク2408。このようにして、段は、単一のノードクラスタ上でのみ、実行できる。
【0210】
g)クエリがセミステートフルであれば、パーティショニング属性を用いてパーティションすべき段をマーク2410。パーティショニング属性は、ステップ2.ii.dの結果から取得する。このようにして、段の計算を、自動的に判断したパーティショニング属性でパーティションすることができる。
3)各段についげ、データ変換パイプラインのDAGにおける変換を生成する。
【0211】
i)段が、パーティショニング属性なしでパーティションされたとマークされた場合2406、DAGにおけるこの段に対する変換を、再パーティショニング変換なしで生成する。段のパーティションの数は、前の段のパーティションの数から求められる。
【0212】
ii)段が、パーティショニング属性でパーティションされたト判断された場合2410、再パーティショニング変換を用いてDAGにおけるこの段の変換を生成する。再パーティショニング変換に対する入力は、パーティショニング属性およびパーティションの数であろう。再パーティショニング変換は、入来するイベントストリームを、新たなパーティショニング基準で再度パーティションする。
【0213】
iii)段がパーティションされていないとマークされる場合2408、段の変換が後に続く再パーティショニング変換でDAG内の段に対する変換を生成する。再パーティショニング変換に対する入力は、パーティショニング属性およびパーティションの数であり、これは1であろう。再パーティショニング変換は、既にパーティションされている/パーティションされていないストリームを1つのパーティションに再度パーティションする。
【0214】
特定のパイプラインにおいて、システムが十分なメタデータを持っていない場合、または、クエリ解析によってパーティショニングを判断できない場合、システムは、オブジェクトidをパーティショニング属性としてマークする2412。
【0215】
段の種類が空間でありDSMSが移動するオブジェクトのジオロケーション(geo-location)イベントを処理しており各オブジェクトが固有のアイデンティティを有する場合、
Stream Analyticsプラットフォームは、オブジェクトidを段のパーティショニング属性としてマークし、DAGのこの段の変換を、パーティショニング変換、次に段変換によって、マークする。
【0216】
開示される技術の実施形態は以下の特徴を提供する。
-パイプライン段のメタデータスキャンを実行しCQLクエリ分類に基づいて段を分類する。
-連続クエリ言語に基づいてクエリの意味解析を実行することによりパーティショニング属性を自動的に判断する。
-パーティショニングを用いて変換のDAGを生成する。
【0217】
以前の技術は、ユーザがパイプライン段のパラレル処理の特徴を明確に基底するために、パイプラインデータ変換を使用することを含んでいた。指定されなければ、システムは、計算リソース全体を使用することなくパイプライン段を処理できる。
【0218】
開示される技術は、パイプライン化されたストリーム処理システムの段を解析することにより、データパーティショニングの基準を判断する。これにより、Stream Analyticsプラットフォームのデータ処理パイプラインの設計の複雑度が大幅に減じられる。
【0219】
図25は、分散イベント処理システムにおけるデータパーティショニングおよびパラレル処理のための一組の動作を説明するプロセス2500のフロー図の一例である。ある実施形態において、プロセス2500は、図24に記載の動作のその他の詳細を説明する。特定の例において、プロセス2500は、2502において、イベント処理システムによって処理されている連続クエリ言語(CQL)クエリの段を判断することによって開始される。2504に進んで、システムは、段に対応付けられた段の種類をハンドなするように構成し得る。いくつかの例において、プロセス2500は、2506において、段の種類に少なくとも一部基づいて段に対して計算すべき変換を判断する。プロセス2500はまた、2508において、複数のルールに少なくとも一部基づいて、CQLクエリの分類を判断することを含み得る。いくつかの例において、プロセス2500は、2510において、パーティショニング基準を段に適用することにより、パーティションされた段またはパーティションされていない段として段をマークすることを含み得る。加えて、いくつかの例において、プロセス2500は、2512において、段のパーティショニング基準に少なくとも一部基づいて、段のデータ変換パイプラインの有向非巡回グラフ(DAG)における変換を生成してもよい。2514において、プロセス2500は、変換に少なくとも一部基づいて段のパーティショニングを判断してもよい。プロセス2500はまた、判断したパーティショニングに少なくとも一部基づいてCQLクエリを処理してもよい。
【0220】
例示的システム
図26図12は、さまざまな実施形態による本開示の態様を実施するための例示的環境の態様を示す。図26は、本開示の一実施形態を実施するための分散型システム2600の簡略図を示す。図示の実施形態では、分散型システム2600は、1つ以上のネットワーク2610でウェブブラウザ、所有権を主張できるクライアント(たとえばOracle Forms)などのクライアントアプリケーションを実行し動作させるように構成された1つ以上のクライアントコンピューティングデバイス2602,2604,2606および2608を含む。サーバ2612は、ネットワーク2610を介してリモートクライアントコンピューティングデバイス2602,2604,2606および2608と通信可能に結合されてもよい。
【0221】
さまざまな実施形態では、サーバ2612は、イベント処理サービスを提供するサービスおよびアプリケーションなどの1つ以上のサービスまたはソフトウェアアプリケーショ
ンを実行するように適合されてもよい。特定の実施形態では、サーバ2612は、非仮想および仮想環境を含むことができる他のサービスまたはソフトウェアアプリケーションも提供できる。いくつかの実施形態では、これらのサービスは、ウェブベースのサービスもしくはクラウドサービスとして、またはソフトウェア・アズ・ア・サービス(SaaS)モデルの下で、クライアントコンピューティングデバイス2602,2604,2606および/または2608のユーザに対して提供されてもよい。クライアントコンピューテ
ィングデバイス2602,2604,2606および/または2608を動作させるユー
ザは、次いで、1つ以上のクライアントアプリケーションを利用してサーバ2612と対話して、これらのコンポーネントによって提供されるサービスを利用してもよい。
【0222】
図26に示される構成では、システム2600のソフトウェアコンポーネント2618,2620および2622は、サーバ2612上で実現されるものとして示されている。他の実施形態では、システム2600のコンポーネントのうちの1つ以上および/またはこれらのコンポーネントによって提供されるサービスは、クライアントコンピューティングデバイス2602,2604,2606および/または2608のうちの1つ以上によって実現されてもよい。クライアントコンピューティングデバイスを動作させるユーザは、次いで、1つ以上のクライアントアプリケーションを利用して、これらのコンポーネントによって提供されるサービスを用いてもよい。これらのコンポーネントはハードウェア、ファームウェア、ソフトウェア、またはそれらの組合せにおいて実現されてもよい。分散型システム2600とは異なってもよいさまざまな異なるシステム構成が可能であることが理解されるべきである。図26に示される実施形態は、したがって、実施形態のシステムを実現するための分散型システムの一例であり、限定的であるよう意図されるものではない。
【0223】
クライアントコンピューティングデバイス2602,2604,2606、および/または2608は、さまざまなタイプのコンピューティングシステムを含むことができる。たとえば、クライアントデバイスは、携帯可能な手持ち式のデバイス(たとえば、iPhone(登録商標)、セルラー電話、iPad(登録商標)、コンピューティングタブレット、携帯情報端末(PDA))またはウェアラブルデバイス(たとえばGoogle Glass(登録商標)頭部装着型ディスプレイ)であってもよく、Microsoft
Windows(登録商標) Mobile(登録商標)などのソフトウェア、および/もしくは、iOS、Windows Phone、Android、BlackBerry26、Palm OSなどのさまざまなモバイルオペレーティングシステムを動作させる。クライアントデバイスは、インターネット関連アプリケーション、電子メール、ショートメッセージサービス(SMS)アプリケーションのようなさまざまなアプリケーションをサポートしてもよく、さまざまな他の通信プロトコルを使用してもよい。クライアントコンピューティングデバイスは、汎用パーソナルコンピュータであってもよく、一例として、Microsoft Windows(登録商標)、Apple Macintosh(登録商標)および/またはLinux(登録商標)オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび/またはラップトップコンピュータも含んでもよい。クライアントコンピューティングデバイスは、たとえばGoogle Chrome OSなどのさまざまなGNU/Linuxオペレーティングシステムを限定を伴うことなく含む、さまざまな市場で入手可能なUNIX(登録商標)またはUNIXのようなオペレーティングシステムのいずれかを実行するワークステーションコンピュータであり得る。クライアントコンピューティングデバイスは、また、ネットワーク2610を介して通信することができる、シンクライアントコンピュータ、インターネットにより可能化されるゲームシステム(たとえば、Kinect(登録商標)ジェスチャ入力デバイスを伴うかまたは伴わないMicrosoft Xboxゲームコンソール)および/または個人メッセージ伝達デバイスなどの電子デバイスを含んでもよい。
【0224】
図26の分散型システム2600は、4つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを伴うデバイスなど、他のデバイスがサーバ2612と対話してもよい。
【0225】
分散型システム2600におけるネットワーク2610は、TCP/IP(伝送制御プロトコル/インターネットプロトコル)、SNA(システムネットワークアーキテクチャ)、IPX(インターネットパケット交換)、AppleTalkなどを限定を伴うことなく含む、さまざまな入手可能なプロトコルのうちのいずれかを用いてデータ通信をサポートすることができる、当業者が精通している任意のタイプのネットワークであってもよい。単なる例として、ネットワーク2610は、ローカルエリアネットワーク(LAN)、イーサネット(登録商標)に基づくネットワーク、トークンリング、ワイドエリアネットワーク、インターネット(登録商標)、仮想ネットワーク、仮想プライベートネットワーク(VPN)、イントラネット、エクストラネット、公衆交換電話網(PSTN)、赤外線ネットワーク、無線ネットワーク(たとえば電気電子学会(IEEE)2602.11プロトコルのいずれかの下で動作するネットワーク、ブルートゥース(登録商標)および/もしくは任意の他の無線プロトコル)、ならびに/またはこれらおよび/もしくは他のネットワークの任意の組み合わせを含むことができる。
【0226】
サーバ2612は、1つ以上の汎用コンピュータ、専用のサーバコンピュータ(一例としてPC(パーソナルコンピュータ)サーバ、UNIX(登録商標)サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウント型サーバなどを含む)、サーバファーム、サーバクラスタ、またはその他の適切な構成および/または組み合わせで構成されてもよい。サーバ2612は、仮想オペレーティングシステムを実行する1つ以上の仮想マシン、または仮想化を伴う他のコンピューティングアーキテクチャを含み得る。論理ストレージデバイスの1つ以上の柔軟なプールを仮想化してサーバのために仮想ストレージデバイスを維持することができる。仮想ネットワークを、サーバ2612によって、ソフトウェア定義のネットワーク接続を用いて制御することができる。さまざまな実施形態において、サーバ2612は、前述の開示に記載される1つ以上のサービスまたはソフトウェアアプリケーションを実行するように適合されてもよい。たとえば、サーバ2612は、本開示の実施形態に従って上記の処理を実行するためのサーバに対応してもよい。
【0227】
サーバ2612は、上記のもののうちのいずれかを含むオペレーティングシステム、および任意の市場で入手可能なサーバオペレーティングシステムを実行してもよい。サーバ2612は、HTTP(ハイパーテキスト転送プロトコル)サーバ、FTP(ファイル転送プロトコル)サーバ、CGI(コモンゲートウェイインターフェイス)サーバ、JAVA(登録商標)サーバ、データベースサーバなどを含むさまざまなさらに他のサーバアプリケーションおよび/または中間層アプリケーションのうちのいずれかも実行してもよい。例示的なデータベースサーバは、オラクル、マイクロソフト、サイベース、IBM(インターナショナルビジネスマシンズ)などから市場で入手可能なものを含むが、それらに限定されるものではない。
【0228】
いくつかの実現例では、サーバ2612は、クライアントコンピューティングデバイス2602,2604,2606および2608のユーザから受信されるデータフィードおよび/またはイベント更新情報を解析および整理統合するための1つ以上のアプリケーションを含んでもよい。一例として、データフィードおよび/またはイベント更新情報は、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール(たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション)、クリックストリーム解析ツール、自動車交通モニタリングなどに関連するリアルタイムのイベントを含んでもよい、1つ以上の第三者情報源および連続データストリームから受信される
、Twitter(登録商標)フィード、Facebook(登録商標)更新情報またはリアルタイムの更新情報を含んでもよいが、それらに限定されるものではない。サーバ2612は、データフィードおよび/またはリアルタイムのイベントをクライアントコンピューティングデバイス2602,2604,2606および2608の1つ以上の表示デバイスを介して表示するための1つ以上のアプリケーションも含んでもよい。
【0229】
分散型システム2600は、1つ以上のデータベース2614および2616も含んでもよい。これらのデータベースは、ユーザ識別情報、および本開示の実施形態によって使用される他の情報などの情報を格納するためのメカニズムを提供することができる。データベース2614および2616は、さまざまな位置にあってもよい。一例として、データベース2614および2616のうちの1つ以上は、サーバ2612に局在する(および/またはサーバ2612に常駐する)非一時的な記憶媒体にあってもよい。代替的に、データベース2614および2616は、サーバ2612から遠隔にあり、ネットワークベースまたは専用の接続を介してサーバ2612と通信してもよい。一組の実施形態では、データベース2614および2616は、記憶域ネットワーク(SAN)にあってもよい。同様に、サーバ2612に帰する機能を実行するための任意の必要なファイルが、適宜、サーバ2612上においてローカルに、および/または遠隔で格納されてもよい。一組の実施形態では、データベース2614および2616は、SQLフォーマットされたコマンドに応答してデータを格納、更新および検索取得するように適合される、オラクルによって提供されるデータベースなどのリレーショナルデータベースを含んでもよい。
【0230】
いくつかの図面に示されたシステムは、さまざまな構成で提供されてもよい。いくつかの実施形態では、システムは、システムの1つ以上のコンポーネントが1つ以上のクラウドインフラストラクチャシステムの1つ以上のネットワークに分散された分散型システムとして構成することができる。
【0231】
クラウドインフラストラクチャシステムは、1つ以上のサーバコンピューティングデバイス、ネットワークデバイス、および/またはストレージデバイスの集合である。これらのリソースは、クラウドサービスプロバイダによって分割され、何らかの方法で顧客に割り当てられてもよい。たとえば、カリフォルニア州レッドウッドショアーズのオラクルコーポレーションのようなクラウドサービスプロバイダは、さまざまなタイプのクラウドサービスを提供し得、それらは、サービスとしてのソフトウェア(SaaS)カテゴリで提供される1つ以上のサービス、サービスとしてのプラットフォーム(PaaS)カテゴリで提供されるサービス、サービスとしてのインフラストラクチャ(laaS)カテゴリで提供されるサービス、またはハイブリッドサービスを含む他のカテゴリのサービスを含むが、それらに限定はされない。SaaSサービスの例としては、Oracle Fusionアプリケ
ーションなどのオンデマンドアプリケーションの一式を構築して提供する機能があるが、これに限定されない。SaaSサービスは、顧客が、クラウドインフラストラクチャシステム上で実行されているアプリケーションのためのソフトウェアを購入する必要なく、そのようなアプリケーションを利用することを可能にする。PaaSサービスの例としては、組織(オラクルなど)が共有された共通アーキテクチャー上で既存のアプリケーションを統合できるようにするサービスや、Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS)などのプラットフォームによって提供される共有サービスを活
用する新たなアプリケーションを構築する能力を含むが、それらに限定はされない。IaaSサービスは、通常、SaaSプラットフォームおよびPaaSプラットフォームによって提供されるサービスを利用する顧客のためのストレージ、ネットワーク、およびその他の基本的な計算資源などの基盤となる計算資源の管理および制御を容易にする。
【0232】
図27は、本開示の実施形態に従って、実施形態のシステムの1つ以上のコンポーネントによって提供されるサービスがクラウドサービスとして提供されてもよいシステム環境
2700の1つ以上のコンポーネントの簡略ブロック図である。示される実施形態において、システム環境2700は、クラウドサービスを提供するクラウドインフラストラクチャシステム2702と対話するようユーザによって用いられてもよい1つ以上のクライアントコンピューティングデバイス2704,2706および2708を含む。クライアントコンピューティングデバイスは、クラウドインフラストラクチャシステム2702と対話して、クラウドインフラストラクチャシステム2702によって提供されるサービスを用いるよう、クライアントコンピューティングデバイスのユーザによって用いられてもよい、ウェブブラウザ、所有権付きクライアントアプリケーション(たとえばOracle Forms)または何らかの他のアプリケーションなどのようなクライアントアプリケーションを動作させるよう構成されてもよい。
【0233】
図に示されるクラウドインフラストラクチャシステム2702は図示されるもの以外のコンポーネントを有してもよいことが理解されるべきである。さらに、図に示される実施形態は、本開示の実施形態を組み込んでもよいクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施形態において、クラウドインフラストラクチャシステム2702は、図に示されるよりも多いかもしくは少ないコンポーネントを有してもよく、2つ以上のコンポーネントを組み合わせてもよく、またはコンポーネントの異なる構成もしくは配置を有してもよい。
【0234】
クライアントコンピューティングデバイス2704,2706および2708は、502,504,506および508に対して上記されたものと同様のデバイスであってもよい。
【0235】
例示的なシステム環境2700は3つのクライアントコンピューティングデバイスとともに示されているが、任意の数のクライアントコンピューティングデバイスがサポートされてもよい。センサを伴うデバイスなどのような他のデバイスがクラウドインフラストラクチャシステム2702と対話してもよい。
【0236】
ネットワーク2710はクライアント2704,2706および2708とクラウドインフラストラクチャシステム2702との間におけるデータの通信および交換を容易にし得る。各ネットワークは、ネットワーク2710に対して上記されたものを含む、さまざまな市場で入手可能なプロトコルの任意のものを用いてデータ通信をサポートすることができる、当業者が精通している任意のタイプのネットワークであってもよい。
【0237】
クラウドインフラストラクチャシステム2702は、サーバ2712に対して上記されたものを含んでもよい1つ以上のコンピュータおよび/またはサーバを備えてもよい。
【0238】
特定の実施形態において、クラウドインフラストラクチャシステムによって提供されるサービスは、オンラインデータストレージおよびバックアップソリューション、ウェブに基づくeメールサービス、運営管理されるオフィススイートおよびドキュメントコラボレーションサービス、データベース処理、管理される技術サポートサービスなどのような、オンデマンドでクラウドインフラストラクチャシステムのユーザに利用可能にされるサービスのホストを含んでもよい。クラウドインフラストラクチャシステムによって提供されるサービスは動的にスケーリングしてそのユーザのニーズを満たすことができる。クラウドインフラストラクチャシステムによって提供されるあるサービスのある具体的なインスタンス化は本明細書では「サービスインスタンス」と呼ばれる。一般的に、クラウドサービスプロバイダのシステムからインターネットなどのような通信ネットワークを介してユーザに利用可能にされる任意のサービスは「クラウドサービス」と呼ばれる。典型的には、パブリックなクラウド環境においては、クラウドサービスプロバイダのシステムを形成するサーバおよびシステムは顧客自身のオンプレミスのサーバおよびシステムとは異なる
。たとえば、クラウドサービスプロバイダのシステムはアプリケーションを運営管理してもよく、ユーザは、インターネットなどのような通信ネットワークを介して、オンデマンドで、アプリケーションをオーダーし使用してもよい。
【0239】
いくつかの例では、コンピュータネットワーククラウドインフラストラクチャにおけるサービスは、ストレージ、運営管理されるデータベース、運営管理されるウェブサーバ、ソフトウェアアプリケーション、またはクラウドベンダーによってユーザに提供されるかもしくは他の態様で当該技術分野において公知であるような他のサービスに対する保護されたコンピュータネットワークアクセスを含んでもよい。たとえば、サービスは、クラウド上の遠隔ストレージに対するインターネットを介してのパスワード保護されたアクセスを含むことができる。別の例として、サービスは、ネットワーク接続された開発者による個人的な使用のために、ウェブサービスに基づく運営管理されたリレーショナルデータベースおよびスクリプト言語ミドルウェアエンジンを含むことができる。別の例として、サービスは、クラウドベンダーのウェブサイトにおいて運営管理されるeメールソフトウェアアプリケーションに対するアクセスを含むことができる。
【0240】
特定の実施形態において、クラウドインフラストラクチャシステム2702は、セルフサービスの、サブスクリプションに基づく、順応性を持ってスケーラブルで、信頼性があり、非常に利用可能性があり、およびセキュリティ上安全な態様で顧客に対して配送されるアプリケーションの組、ミドルウェア、データベースサービス提供を含んでもよい。そのようなクラウドインフラストラクチャシステムの一例は本譲受人によって提供されるOracle Public Cloudである。
【0241】
さまざまな実施形態において、クラウドインフラストラクチャシステム2702は、クラウドインフラストラクチャシステム2702によって提供されるサービスに対する顧客のサブスクリプションを自動的にプロビジョニング、管理、およびトラッキングするように構成されてもよい。クラウドインフラストラクチャシステム2702はクラウドサービスを異なる開発モデルを介して提供してもよい。たとえば、サービスは、クラウドインフラストラクチャシステム2702が(たとえばOracleによって所有される)クラウドサービスを販売する組織によって所有され、サービスが一般大衆または異なる業界エンタープライズに対して利用可能にされるパブリッククラウドモデルの下で提供されてもよい。別の例として、サービスは、クラウドインフラストラクチャシステム1102が単一の組織に対してのみ動作され、その組織内における1つ以上のエンティティに対してサービスを提供してもよい、プライベートクラウドモデルの下で提供されてもよい。クラウドサービスは、さらに、クラウドインフラストラクチャシステム2702およびクラウドインフラストラクチャシステム2702によって提供されるサービスが関係付けられるコミュニティにおけるいくつかの組織によって共有されるコミュニティクラウドモデルの下で提供されてもよい。クラウドサービスは、さらに、2つ以上の異なるモデルの組合せであるハイブリッドクラウドモデルの下で提供されてもよい。
【0242】
いくつかの実施形態において、クラウドインフラストラクチャシステム2702によって提供されるサービスは、Software as a Service(SaaS)カテゴリ、Platform as a Service(PaaS)カテゴリ、Infrastructure as a Service(IaaS)カテゴリ、またはハイブリッドサービスを含む他のサービスのカテゴリの下で提供される、1つ以上のサービスを含んでもよい。顧客は、サブスクリプションオーダーを介して、クラウドインフラストラクチャシステム2702によって提供される1つ以上のサービスをオーダーしてもよい。クラウドインフラストラクチャシステム2702は、次いで、処理を実行して、顧客のサブスクリプションオーダーにおけるサービスを提供する。
【0243】
いくつかの実施形態において、クラウドインフラストラクチャシステム2702によって提供されるサービスは、限定を伴わずに、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含んでもよい。いくつかの例では、アプリケーションサービスはクラウドインフラストラクチャシステムによってSaaSプラットフォームを介して提供されてもよい。SaaSプラットフォームは、SaaSカテゴリに入るクラウドサービスを提供するよう構成されてもよい。たとえば、SaaSプラットフォームは、一式のオンデマンドアプリケーションを統合された開発およびデプロイプラットフォーム上で構築し配送する能力を提供してもよい。SaaSプラットフォームは、SaaSサービスを提供するための基底のソフトウェアおよびインフラストラクチャを管理および制御してもよい。SaaSプラットフォームによって提供されるサービスを利用することによって、顧客はクラウドインフラストラクチャシステムにおいて実行されるアプリケーションを利用することができる。顧客は、別のライセンスおよびサポートを購入する必要なくアプリケーションサービスを獲得することができる。さまざまな異なるSaaSサービスが提供されてもよい。その例は、限定を伴うことなく、大きな組織に対する売上実績管理、エンタープライズ統合、および事業柔軟性に対するソリューションを提供するサービスを含む。
【0244】
いくつかの実施形態において、プラットフォームサービスはクラウドインフラストラクチャシステムによってPaaSプラットフォームを介して提供されてもよい。PaaSプラットフォームはPaaSカテゴリの下におけるクラウドサービスを提供するよう構成されてもよい。プラットフォームサービスの例は、限定を伴わずに、(Oracleなどのような)組織が既存のアプリケーションを共有される共通のアーキテクチャにおいて整理統合することができるサービス、およびプラットフォームによって提供される共有されるサービスをてこ入れする新たなアプリケーションを構築する能力を含んでもよい。PaaSプラットフォームはPaaSサービスを提供するための基底のソフトウェアおよびインフラストラクチャを管理および制御してもよい。顧客は、クラウドインフラストラクチャシステムによって提供されるPaaSサービスを、別のライセンスおよびサポートを購入する必要なく獲得することができる。プラットフォームサービスの例は、限定を伴わずに、Oracle Java Cloud Service(JCS)、Oracle Database Cloud Service(DBCS)などを含む。
【0245】
PaaSプラットフォームによって提供されるサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムによってサポートされるプログラミング言語およびツールを使用することができ、デプロイされたサービスを制御することもできる。いくつかの実施形態において、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス(たとえばOracle Fusion(登録商標) Middlewareサービス)、およびJavaクラウドサービスを含んでもよい。一実施形態において、データベースクラウドサービスは、組織がデータベース資源をプールし、顧客にDatabase as a Serviceをデータベースクラウドの形式で提供することを可能にする、共有されるサービスデプロイモデルをサポートしてもよい。ミドルウェアクラウドサービスは、顧客のためのプラットフォームを提供してさまざまなビジネスアプリケーションを開発およびデプロイしてもよく、Javaクラウドサービスは顧客のためのプラットフォームを提供してJavaアプリケーションをクラウドインフラストラクチャシステムにおいてデプロイしてもよい。
【0246】
さまざまな異なるインフラストラクチャサービスがIaaSプラットフォームによってクラウドインフラストラクチャシステムにおいて提供されてもよい。インフラストラクチャサービスは、SaaSプラットフォームおよびPaaSプラットフォームによって提供されるサービスを利用する顧客に対するストレージ、ネットワーク、他の基礎的計算資源
などのような基底の計算資源の管理および制御を容易にする。
【0247】
特定の実施形態において、クラウドインフラストラクチャシステム2702は、さらに、クラウドインフラストラクチャシステムの顧客に対してさまざまなサービスを提供するよう用いられる資源を提供するためのインフラストラクチャ資源2730を含んでもよい。一実施形態において、インフラストラクチャ資源2730は、PaaSプラットフォームおよびSaaSプラットフォームによって提供されるサービスを実行するよう、サーバ、ストレージおよびネットワーク接続資源などのような、ハードウェアの予め統合され最適化された組合せを含んでもよい。
【0248】
いくつかの実施形態において、クラウドインフラストラクチャシステム2702における資源は、複数のユーザによって共有され、要望に付き動的に再割当てされてもよい。加えて、資源はユーザに対して異なる時間ゾーンで割当てられてもよい。たとえば、クラウドインフラストラクチャシステム2730は、第1の時間ゾーンにおける第1の組のユーザがクラウドインフラストラクチャシステムの資源をある特定化された時間数の間利用することを可能にし、次いで、異なる時間ゾーンに位置する別の組のユーザに対する同じ資源の再割当てを可能にし、それによって、資源の利用を最大限にしてもよい。
【0249】
特定の実施形態において、クラウドインフラストラクチャシステム2702の異なるコンポーネントまたはモジュール、およびクラウドインフラストラクチャシステム2702によって提供されるサービスによって共有される、ある数の内部の共有されるサービス2732が提供されてもよい。これらの内部の共有されるサービスは、限定を伴うことなく、セキュリティおよびアイデンティティサービス、統合サービス、エンタープライズリポジトリサービス、エンタープライズマネージャサービス、ウイルススキャンおよびホワイトリストサービス、高可用性、バックアップおよびリカバリサービス、クラウドサポートを可能にするためのサービス、eメールサービス、通知サービス、ファイル転送サービスなどを含んでもよい。
【0250】
特定の実施形態において、クラウドインフラストラクチャシステム2702は、クラウドインフラストラクチャシステムにおいてクラウドサービス(たとえばSaaS、PaaS、およびIaaSサービス)の包括的な管理を提供してもよい。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム2702によって受信される顧客のサブスクリプションをプロビジョニングし、管理し、およびトラッキングする能力などを含んでもよい。
【0251】
一実施形態において、図に示されるように、クラウド管理機能は、オーダー管理モジュール2720、オーダーオーケストレーションモジュール2722、オーダープロビジョニングモジュール2724、オーダー管理およびモニタリングモジュール2726、ならびにアイデンティティ管理モジュール2728などのような1つ以上のモジュールによって提供されてもよい。これらのモジュールは、1つ以上のコンピュータおよび/またはサーバを含むかもしくはそれらを用いて提供されてもよく、それらは汎用コンピュータ、特殊化されたサーバコンピュータ、サーバファーム、サーバクラスタ、または任意の他の適切な構成および/もしくは組合せであってもよい。
【0252】
例示的な動作2734においては、クライアントデバイス2704、2706または2708などのようなクライアントデバイスを用いる顧客は、クラウドインフラストラクチャシステム2702によって提供される1つ以上のサービスを要求すること、およびクラウドインフラストラクチャシステム2702によって提供される1つ以上のサービスに対するサブスクリプションに対するオーダーを行うことによって、クラウドインフラストラクチャシステム2702と対話してもよい。特定の実施形態において、顧客は、クラウド
ユーザインターフェイス(UI)、クラウドUI2712、クラウドUI2714および/またはクラウドUI2716にアクセスし、サブスクリプションオーダーをこれらのUIを介して行ってもよい。顧客がオーダーを行うことに応答してクラウドインフラストラクチャシステム2702によって受取られるオーダー情報は、顧客を識別する情報、およびクラウドインフラストラクチャシステム2702によって提供される、その顧客が利用することを意図する1つ以上のサービスを含んでもよい。
【0253】
オーダーが顧客によってなされた後、オーダー情報はクラウドUI2712、2714および/または2716を介して受取られてもよい。
【0254】
動作2736において、オーダーはオーダーデータベース2718に格納される。オーダーデータベース2718は、クラウドインフラストラクチャシステム2718によって動作されるいくつかのデータベースの1つであり得、他のシステム要素との関連において動作され得る。
【0255】
動作2738で、オーダー情報はオーダー管理モジュール2720に転送される。いくつかの例では、オーダー管理モジュール2720は、オーダーを検証すること、および検証でそのオーダーを予約することなど、オーダーに関係付けられる請求および課金機能を実行するよう構成されてもよい。
【0256】
動作2740で、オーダーに関する情報がオーダーオーケストレーションモジュール2722に通信される。オーダーオーケストレーションモジュール2722は、オーダー情報を利用して、顧客によってなされたオーダーに対してサービスおよび資源のプロビジョニングをオーケストレーションしてもよい。いくつかの例では、オーダーオーケストレーションモジュール2722は、資源のプロビジョニングをオーケストレーションして、利用されるサービスを、オーダープロビジョニングモジュール2724のサービスを用いてサポートしてもよい。
【0257】
特定の実施形態において、オーダーオーケストレーションモジュール2722は、各オーダーに関連付けられるビジネスプロセスの管理を可能にし、ビジネスロジックを適用して、オーダーがプロビジョニングに進むべきかどうかを判断する。動作2742で、新たなサブスクリプションに対するオーダーが受取られると、オーダーオーケストレーションモジュール2722は、オーダープロビジョニングモジュール2724に対して、資源を割当て、サブスクリプションオーダーを満たすよう必要とされる資源を構成するよう、要求を送る。オーダープロビジョニングモジュール2724は、顧客によってオーダーされたサービスに対する資源の割当てを可能にする。オーダープロビジョニングモジュール2724は、クラウドインフラストラクチャシステム2700によって提供されるクラウドサービスと、要求されたサービスを提供するための資源をプロビジョニングするよう用いられる物理的インプリメンテーション層との間におけるある抽象レベルを与える。オーダーオーケストレーションモジュール2722は、したがって、サービスおよび資源がオンザフライで実際にプロビジョニングされるか、または予めプロビジョニングされ、要求でのみ割当て/分配されるかどうかなど、インプリメンテーション詳細から隔離されてもよい。
【0258】
動作2744で、サービスおよび資源がプロビジョニングされると、提供されるサービスの通知が、クラウドインフラストラクチャシステム302のオーダープロビジョニングモジュール2724によってクライアントデバイス2704、2706および/または2708における顧客に送信されてもよい。動作2746で、顧客のサブスクリプションオーダーはオーダー管理およびモニタリングモジュール2726によって管理およびトラッキングされてもよい。いくつかの例では、オーダー管理およびモニタリングモジュール2
726は、用いられるストレージの量、転送されるデータ量、ユーザの数、システムアップ時間およびシステムダウン時間の量などのような、サブスクリプションオーダーにおけるサービスに対する使用統計を収集するよう構成されてもよい。
【0259】
特定の実施形態において、クラウドインフラストラクチャシステム2700はアイデンティティ管理モジュール2728を含んでもよい。アイデンティティ管理モジュール2728は、クラウドインフラストラクチャシステム2700におけるアクセス管理および承認サービスなどのようなアイデンティティサービスを提供するよう構成されてもよい。いくつかの実施形態において、アイデンティティ管理モジュール2728は、クラウドインフラストラクチャシステム2702によって提供されるサービスを利用することを望む顧客についての情報を制御してもよい。そのような情報は、そのような顧客のアイデンティティを認証する情報、およびそれらの顧客がさまざまなシステム資源(たとえばファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど)に対してどのアクションを実行するよう承認されるかを記述する情報を含むことができる。アイデンティティ管理モジュール2728は、さらに、各顧客についての記述的情報およびどのように誰によってその記述的情報がアクセスおよび修正され得るかの管理を含んでもよい。
【0260】
図28は、本開示の実施形態を実施するために使用され得る例示的なコンピュータシステム2800を示す。いくつかの実施形態では、コンピュータシステム2800を使用して、上述したさまざまなサーバおよびコンピュータシステムのいずれかを実装することができる。図28に示すように、コンピュータシステム2800は、バスサブシステム2802を介して複数の周辺サブシステムと通信する処理サブシステム2804を含むさまざまなサブシステムを含む。これらの周辺サブシステムは、処理加速ユニット2806、I/Oサブシステム2808、ストレージサブシステム2818および通信サブシステム2824を含んでもよい。ストレージサブシステム2818は、有形のコンピュータ可読記憶媒体2822およびシステムメモリ2810を含む。
【0261】
バスサブシステム2802は、コンピュータシステム2800のさまざまなコンポーネントおよびサブシステムに意図されるように互いに通信させるための機構を提供する。バスサブシステム2802は単一のバスとして概略的に示されているが、バスサブシステムの代替的実施例は、複数のバスを利用してもよい。バスサブシステム2802は、さまざまなバスアーキテクチャのうちのいずれかを用いるメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスを含むいくつかのタイプのバス構造のうちのいずれかであってもよい。たとえば、そのようなアーキテクチャは、業界標準アーキテクチャ(Industry Standard Architecture:ISA)バス、マイクロチャネルアーキテクチャ(Micro Channel Architecture:MCA)バス、エンハンストISA(Enhanced ISA:EISA)バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション(Video Electronics Standards Association:VESA)ローカルバス、およびIEEE P1386.1規格に従って製造される中二階バスとして実現され得る周辺コンポーネントインターコネクト(Peripheral Component Interconnect:PCI)バスなどを含んでもよい。
【0262】
処理サブシステム2804は、コンピュータシステム2800の動作を制御し、1つ以上の処理ユニット2832,2834などを含むことができる。処理ユニットは、単一コアまたはマルチコアプロセッサを含む1つ以上のプロセッサ、1つ以上のプロセッサコア、またはそれらの組み合わせであってもよい。いくつかの実施形態では、処理サブシステム2804は、グラフィックスプロセッサ、デジタル信号プロセッサ(DSP)などのような1つ以上の専用コプロセッサを含むことができる。いくつかの実施形態では、処理サブシステム2804の処理ユニットの一部または全部は、特定用途向け集積回路(ASI
C)またはフィールドプログラマブルゲートアレイ(FPGA)などのカスタマイズされた回路を使用して実装することができる。
【0263】
いくつかの実施形態では、処理サブシステム2804内の処理ユニットは、システムメモリ2810またはコンピュータ可読記憶媒体2822に格納された命令を実行することができる。さまざまな実施形態では、処理ユニットはさまざまなプログラムまたはコード命令を実行し、複数の同時に実行するプログラムまたはプロセスを維持できる。任意の所与の時点で、実行されるべきプログラムコードの一部または全部は、システムメモリ2810および/または潜在的に1つ以上の記憶装置を含むコンピュータ可読記憶媒体2810に常駐することができる。適切なプログラミングを介して、処理サブシステム2804は、使用パターンに応答して文書(たとえばウェブページ)を動的に修正するために上記のさまざまな機能を提供することができる。
【0264】
特定の実施形態では、コンピュータシステム2800によって実行される全体的な処理を加速するよう、カスタマイズされた処理を実行するために、または処理サブシステム2804によって実行される処理の一部をオフロードするために、処理加速ユニット2806を設けることができる。
【0265】
I/Oサブシステム2808は、コンピュータシステム2800に情報を入力するための、および/またはコンピュータシステム2800から、もしくはコンピュータシステム2800を介して、情報を出力するための、デバイスおよび機構を含むことができる。一般に、「入力デバイス」という語の使用は、コンピュータシステム2800に情報を入力するための全ての考えられ得るタイプのデバイスおよび機構を含むよう意図される。ユーザインターフェイス入力デバイスは、たとえば、キーボード、マウスまたはトラックボールなどのポインティングデバイス、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイアル、ボタン、スイッチ、キーパッド、音声コマンド認識システムを伴う音声入力デバイス、マイクロフォン、および他のタイプの入力デバイスを含んでもよい。ユーザインタフェース入力デバイスは、ユーザが入力デバイスを制御しそれと対話することを可能にするMicrosoft Kinect(登録商標)モーションセンサ、Microsoft Xbox(登録商標)360ゲームコントローラ、ジェスチャーおよび音声コマンドを用いる入力を受信するためのインタフェースを提供するデバイスなど、モーションセンシングおよび/またはジェスチャ認識デバイスも含んでもよい。ユーザインターフェイス入力デバイスは、ユーザから目の動き(たとえば、写真を撮っている間および/またはメニュー選択を行なっている間の「まばたき」)を検出し、アイジェスチャを入力デバイス(たとえばGoogle Glass(登録商標))への入力として変換するGoogle Glass(登録商標)瞬き検出器などのアイジェスチャ認識デバイスも含んでもよい。また、ユーザインターフェイス入力デバイスは、ユーザが音声コマンドを介して音声認識システム(たとえばSiri(登録商標)ナビゲータ)と対話することを可能にする音声認識感知デバイスを含んでもよい。
【0266】
ユーザインターフェイス入力デバイスの他の例は、三次元(3D)マウス、ジョイスティックまたはポインティングスティック、ゲームパッドおよびグラフィックタブレット、ならびにスピーカ、デジタルカメラ、デジタルカムコーダ、ポータブルメディアプレーヤ、ウェブカム、画像スキャナ、指紋スキャナ、バーコードリーダ3Dスキャナ、3Dプリンタ、レーザレンジファインダ、および視線追跡デバイスなどの聴覚/視覚デバイスも含んでもよいが、それらに限定されるものではない。また、ユーザインターフェイス入力デバイスは、たとえば、コンピュータ断層撮影、磁気共鳴撮像、ポジションエミッショントモグラフィー、医療用超音波検査デバイスなどの医療用画像化入力デバイスを含んでもよい。ユーザインターフェイス入力デバイスは、たとえば、MIDIキーボード、デジタル
楽器などの音声入力デバイスも含んでもよい。
【0267】
ユーザインターフェイス出力デバイスは、ディスプレイサブシステム、インジケータライト、または音声出力デバイスなどの非ビジュアルディスプレイなどを含んでもよい。ディスプレイサブシステムは、陰極線管(CRT)、液晶ディスプレイ(LCD)またはプラズマディスプレイを使うものなどのフラットパネルデバイス、投影デバイス、タッチスクリーンなどであってもよい。一般に、「出力デバイス」という語の使用は、コンピュータシステム2800からユーザまたは他のコンピュータに情報を出力するための全ての考えられ得るタイプのデバイスおよび機構を含むよう意図される。たとえば、ユーザインターフェイス出力デバイスは、モニタ、プリンタ、スピーカ、ヘッドフォン、自動車ナビゲーションシステム、プロッタ、音声出力デバイスおよびモデムなどの、テキスト、グラフィックスおよび音声/映像情報を視覚的に伝えるさまざまな表示デバイスを含んでもよいが、それらに限定されるものではない。
【0268】
ストレージサブシステム2818は、コンピュータシステム2800によって使用される情報を格納するためのリポジトリまたはデータストアを提供する。ストレージサブシステム2818は、いくつかの実施形態の機能を提供する基本的なプログラミングおよびデータ構成を記憶するための有形の非一時的なコンピュータ可読記憶媒体を提供する。処理サブシステム2804によって実行されると、上述の機能を提供するソフトウェア(プログラム、コードモジュール、命令)が、ストレージサブシステム2818に格納されてもよい。ソフトウェアは、処理サブシステム2804の1つ以上の処理ユニットによって実行されてもよい。ストレージサブシステム2818はまた、本開示に従って使用されるデータを格納するためのリポジトリを提供してもよい。
【0269】
ストレージサブシステム2818は、揮発性および不揮発性メモリデバイスを含む1つ以上の非一時的メモリデバイスを含むことができる。図28に示すように、ストレージサブシステム2818は、システムメモリ2810およびコンピュータ可読記憶媒体2822を含む。システムメモリ2810は、プログラム実行中に命令およびデータを記憶するための揮発性主ランダムアクセスメモリ(RAM)と、固定命令が記憶される不揮発性読み出し専用メモリ(ROM)またはフラッシュメモリとを含む、いくつかのメモリを含むことができる。いくつかの実現例では、起動中などにコンピュータシステム2800内の要素間における情報の転送を助ける基本的なルーチンを含むベーシックインプット/アウトプットシステム(basic input/output system:BIOS)は、典型的には、ROMに記憶されてもよい。RAMは、通常、処理サブシステム2804によって現在動作され実行されているデータおよび/またはプログラムモジュールを含む。いくつかの実現例では、システムメモリ2810は、スタティックランダムアクセスメモリ(SRAM)またはダイナミックランダムアクセスメモリ(DRAM)などの複数の異なるタイプのメモリを含んでもよい。
【0270】
一例として、限定を伴うことなく、図28に示されるように、システムメモリ2810は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、リレーショナルデータベース管理システム(RDBMS)などを含んでもよいアプリケーションプログラム2812、プログラムデータ2814およびオペレーティングシステム2816を記憶してもよい。一例として、オペレーティングシステム2816は、Microsoft Windows(登録商標)、Apple Macintosh(登録商標)および/もしくはLinuxオペレーティングシステム、さまざまな市場で入手可能なUNIX(登録商標)またはUNIXのようなオペレーティングシステム(さまざまなGNU/Linuxオペレーティングシステム、Google Chrome(登録商標)OSなどを含むがそれらに限定されない)、ならびに/または、iOS、Windows(登録商標) Phone、Android(登録商標) OS、BlackBerry(登
録商標)26 OS、およびPalm(登録商標) OSオペレーティングシステムなどのモバイルオペレーティングシステムのさまざまなバージョンを含んでもよい。
【0271】
コンピュータ可読記憶媒体2822は、いくつかの実施形態の機能性を提供するプログラミングおよびデータ構成を格納することができる。処理サブシステム2804によって実行されると、プロセッサが上記の機能を提供するソフトウェア(プログラム、コードモジュール、命令)は、ストレージサブシステム2818に格納されてもよい。一例として、コンピュータ可読記憶媒体2822は、ハードディスクドライブ、磁気ディスクドライブ、CD ROM、DVD、Blu-Ray(登録商標)ディスクなどの光ディスクドライブ、またはその他の光学媒体のような不揮発性メモリを含むことができる。コンピュータ可読記憶媒体2822は、Zip(登録商標)ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス(USB)フラッシュドライブ、セキュアデジタル(SD)カード、DVDディスク、デジタルビデオテープなどを含んでもよいが、それらに限定されるものではない。コンピュータ可読記憶媒体2822は、フラッシュメモリベースのSSD、エンタープライズフラッシュドライブ、ソリッドステートROMなどの不揮発性メモリに基づくソリッドステートドライブ(SSD)、ソリッドステートRAM、ダイナミックRAM、スタティックRAMなどの揮発性メモリに基づくSSD、DRAMベースのSSD、磁気抵抗RAM(MRAM)SSD、およびDRAMとフラッシュメモリベースのSSDとの組み合わせを使用するハイブリッドSSDも含んでもよい。コンピュータ可読媒体2822は、コンピュータシステム2800のためのコンピュータ可読命令、データ構造、プログラムモジュール、および他のデータのストレージを提供することができる。
【0272】
ある実施形態では、ストレージサブシステム2800は、コンピュータ可読記憶媒体2822にさらに接続可能なコンピュータ可読記憶媒体リーダ2820も含んでもよい。システムメモリ2810とともに、およびオプションとしてシステムメモリ2810との組み合わせで、コンピュータ可読記憶媒体2822は、コンピュータ可読情報を記憶するためにリモート、ローカル、固定および/またはリムーバブル記憶装置に記憶媒体を加えたものを包括的に表してもよい。
【0273】
特定の実施形態では、コンピュータシステム2800は、1つ以上の仮想マシンを実行するためのサポートを提供することができる。コンピュータシステム2800は、仮想マシンの構成および管理を容易にするためのハイパーバイザなどのプログラムを実行することができる。各仮想マシンは、メモリ、計算(たとえばプロセッサ、コア)、I/O、およびネットワーキングリソースを割り当てられてもよい。各仮想マシンは、通常、コンピュータシステム2800によって実行される他の仮想マシンによって実行されるオペレーティングシステムと同じでも異なってもよい、それ自体のオペレーティングシステムを実行する。したがって、複数のオペレーティングシステムが潜在的にコンピュータシステム2800によって同時に実行され得る。各仮想マシンは、通常、他の仮想マシンとは独立して動作する。
【0274】
通信サブシステム2824は、他のコンピュータシステムおよびネットワークに対するインターフェイスを提供する。通信サブシステム2824は、他のシステムとコンピュータシステム2800との間のデータの送受のためのインターフェイスとして働く。たとえば、通信サブシステム2824は、コンピュータシステム2800が、1つ以上のクライアントデバイスとの間で情報を送受信するために、インターネットを介して1つ以上のクライアントデバイスへの通信チャネルを確立することを可能にすることができる。さらに、通信サブシステム2824を使用して、成功したログインの通知、または特権アカウントマネージャから要求側ユーザへのパスワードの再入力の通知を伝達することができる。
【0275】
通信サブシステム2824は、有線および/または無線通信プロトコルの両方をサポー
トすることができる。たとえば、ある実施形態では、通信サブシステム2824は、(たとえば、セルラー電話技術、3G、4GもしくはEDGE(グローバル進化のための高速データレート)などの先進データネットワーク技術、WiFi(IEEE802.11ファミリー規格、もしくは他のモバイル通信技術、またはそれらのいずれかの組み合わせを用いて)無線音声および/またはデータネットワークにアクセスするための無線周波数(RF)送受信機コンポーネント、グローバルポジショニングシステム(GPS)受信機コンポーネント、ならびに/または他のコンポーネントを含んでもよい。いくつかの実施形態では、通信サブシステム2824は、無線インターフェイスに加えて、またはその代わりに、有線ネットワーク接続(たとえば、イーサネット)を提供することができる。
【0276】
通信サブシステム2824は、さまざまな形式でデータを受信し、送信することができる。たとえば、いくつかの実施形態では、通信サブシステム2824は、構造化データフィードおよび/または非構造化データフィード2826、イベントストリーム2828、イベント更新2830などの形式で入力通信を受信することができる。たとえば、通信サブシステム2824は、ソーシャルメディアネットワークおよび/またはTwitter(登録商標)フィード、Facebook(登録商標)更新情報、Rich Site Summary(RSS)フィードなどのウェブフィード、および/もしくは1つ以上の第三者情報源からのリアルタイム更新情報などの他の通信サービスのユーザからリアルタイムでデータフィード2826を受信(または送信)するように構成されてもよい。
【0277】
ある実施形態では、通信サブシステム2824は、連続データストリームの形式でデータを受信するように構成されてもよく、当該連続データストリームは、明確な終端を持たない、本来は連続的または無限であり得るリアルタイムイベントのイベントストリーム2828および/またはイベント更新情報2830を含んでもよい。連続データを生成するアプリケーションの例としては、たとえば、センサデータアプリケーション、金融株式相場表示板、ネットワーク性能測定ツール(たとえば、ネットワークモニタリングおよびトラフィック管理アプリケーション)、クリックストリーム解析ツール、自動車交通モニタリングなどを挙げることができる。
【0278】
また、通信サブシステム2824は、構造化されたおよび/または構造化されていないデータフィード2826、イベントストリーム2828、イベント更新情報2830などを、コンピュータシステム2800に結合される1つ以上のストリーミングデータソースコンピュータと通信し得る1つ以上のデータベースに出力するよう構成されてもよい。
【0279】
コンピュータシステム2800は、手持ち式の携帯デバイス(たとえば、iPhone(登録商標)携帯電話、iPad(登録商標)コンピューティングタブレット、PDA)、ウェアラブルデバイス(たとえば、Google Glass(登録商標)頭部装着型ディスプレイ)、パソコン、ワークステーション、メインフレーム、キオスク、サーバラック、またはその他のデータ処理システムを含む、さまざまなタイプのもののうちの1つであり得る。
【0280】
常に変化するコンピュータおよびネットワークの性質のため、図28に示されるコンピュータシステム2800の記載は、単に具体的な例として意図される。図28に示されるシステムよりも多くのコンポーネントまたは少ないコンポーネントを有する多くの他の構成が可能である。本明細書における開示および教示に基づいて、当業者は、さまざまな実施形態を実現するための他の態様および/または方法を理解するであろう。
【0281】
本開示の特定の実施形態について説明したが、本開示の範囲内で、さまざまな修正、変更、代替構成、および同等物も包含される。本開示の実施形態は、ある特定のデータ処理環境内の動作に限定されず、複数のデータ処理環境内で自由に動作することができる。さ
らに、本開示の実施形態は特定の一連のトランザクションおよびステップを使用して記載されたが、本開示の範囲は記載された一連のトランザクションおよびステップに限定されないことは当業者には明らかである。上述した実施形態のさまざまな特徴および態様は、個別にまたはともに使用されてもよい。
【0282】
さらに、本開示の実施形態をハードウェアとソフトウェアとの特定の組み合わせを用いて記載したが、ハードウェアとソフトウェアとの他の組み合わせも本開示の範囲内であることを認識すべきである。本開示の実施形態は、ハードウェアでのみ、またはソフトウェアでのみ、またはそれらの組み合わせを用いて実施されてもよい。本明細書に記載されたさまざまなプロセスは、同じプロセッサまたは任意の組み合わせの異なるプロセッサ上で実現できる。したがって、構成要素またはモジュールが特定の動作を実行するように構成されるとして記載されている場合、そのような構成は、たとえば、動作を実行する電子回路を設計すること、プログラミング可能な電子回路(マイクロプロセッサなど)をプログラミングして動作を実行すること、またはそれらの任意の組み合わせによって達成され得る。プロセスは、プロセス間通信のための従来の技術を含むがこれに限定されないさまざまな技術を使用して通信することができ、異なる対のプロセスは異なる技術を使用してもよく、同じ対のプロセスは異なる時間に異なる技術を使用してもよい。
【0283】
したがって、明細書および図面は、限定的な意味ではなく例示的であると見なされるべきである。しかしながら、特許請求の範囲に記載されたより広範な精神および範囲から逸脱することなく、追加、削減、削除、ならびに他の修正および変更がなされ得ることは明らかであろう。このように、特定の開示の実施形態を説明したが、これらは限定することを意図するものではない。さまざまな修正および均等物は、特許請求の範囲内にある。修正および変形は、開示された特徴の関連の組み合わせを含む。
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13A
図13B
図13C
図13D
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28
【手続補正書】
【提出日】2022-02-03
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
連続クエリ言語(CQL)エンジンを管理するための方法であって、
CQLエンジントラッキングエンジンを用いて、CQLエンジンのクラスタ内の第1のCQLエンジンを起動することと、
前記CQLエンジントラッキングエンジンを用いて、アプリケーションに関連する入力イベントの連続ストリームのバッチを処理するために前記第1のCQLエンジンをスケジューリングすることと、
前記CQLエンジントラッキングエンジンを用いて、実行のためにスケジューリングすべき前記第1のCQLエンジンをトラッキングすることと、
前記CQLエンジントラッキングエンジンを用いて、前記第1のCQLエンジンを実行して前記入力イベントの連続ストリームのバッチを処理することにより、前記アプリケーションに関連する出力イベントのセットを生成することとを含む、連続クエリ言語(CQL)エンジンを管理するための方法。
【請求項2】
前記第1のCQLエンジンの状態は、非アクティブ状態、スケジューリングされた状態、またはアクティブ状態のうちの少なくとも1つを含む、請求項1に記載の方法。
【請求項3】
前記クラスタ内で起動するCQLエンジンの総数を判断することをさらに含む、請求項1または2に記載の方法。
【請求項4】
前記第1のCQLエンジンは、前記クラスタ内の前記CQLエンジンの1つである、請求項3に記載の方法。
【請求項5】
前記クラスタ内の前記CQLエンジンの各CQLエンジンについて、タスクスケジューラに長時間実行タスクを与えることをさらに含む、請求項3または4に記載の方法。
【請求項6】
前記タスクスケジューラに命令して、エグゼキュータに対する前記長時間実行タスクの各々を実行させることをさらに含み、前記エグゼキュータの各エグゼキュータは、前記クラスタ内の前記CQLエンジンの各々を実現する、請求項5に記載の方法。
【請求項7】
前記CQLエンジントラッキングエンジンはドライバによって実現され、前記第1のCQLエンジンは前記エグゼキュータによって実現される、請求項6に記載の方法。
【請求項8】
請求項1~7のいずれかに記載の方法をコンピュータに実行させるためのプログラム。
【請求項9】
請求項8に記載のプログラムを記憶するためのメモリと、
前記プログラムを実行するためのプロセッサとを備える、システム。
【外国語明細書】