詳細な説明
以下の記載において、説明の目的で、本発明の様々な実施形態を完全に理解できるようにするために、多くの具体的な詳細を記載する。しかしながら、これらの具体的な詳細がなくても本発明を実施できることは、当業者には明らかであろう。場合によって、一部の周知の構造および装置は、ブロック図で示される。
以下の記載は、例示的な実施形態を提供するもののみであり、本開示の範囲、適用性または構成を限定するものではない。むしろ、例示的な実施形態の以下の記載は、例示的な実施形態を実施可能な説明を当業者に提供する。理解すべきことは、添付の特許請求の範囲に記載された発明の精神および範囲から逸脱することなく、要素の機能および要素の配置にさまざまな変更を加えることができることである。
本発明の実施形態を完全に理解するために、以下の記載において、具体的な詳細を説明した。しかしながら、当業者には、これらの具体的な詳細がなくても、本発明の実施形態を実施できることが理解されるであろう。例えば、不必要な詳細で実施形態を不明瞭にしないように、回路、システム、ネットワーク、プロセスおよび他の構成要素をブロック要素として示してもよい。他の例において、実施形態を不明瞭にしないように、不必要な詳細なしで、周知の回路、プロセス、アルゴリズム、構造および技術を示してもよい。 また、留意すべきことは、各々の実施形態は、フローチャート、フロー図、データフロー図、構造図、またはブロック図として示された処理として説明されていることである。フローチャートは、操作を順次処理として説明しているが、多くの操作は、並行でまたは同時に実行することができる。さらに、操作の順序を再配置してもよい。処理は、その操作が完了した時点で終了するが、図に示されていない追加のステップを含んでもよい。処理は、メソッド、関数、プロシージャ、サブルーチン、サブプログラムなどに対応することができる。処理が関数に対応する場合、その終了は、呼び出し関数またはメイン関数の戻りに対応することができる。
「コンピュータ読取可能な媒体」という用語は、命令および/またはデータを記憶、格納または搬送することができる非一時的媒体、例えば、可搬型または固定型記憶装置、光記憶装置、およびさまざまな他の媒体を含むが、これらに限定されない。コードセグメントまたはコンピュータ実行可能な命令は、プロシージャ、関数、サブプログラム、プログラム、ルーチン、サブルーチン、モジュール、ソフトウェアパッケージ、クラス、もしくは命令、データ構造またはプログラム文の任意の組合せを表すことができる。コードセグメントは、情報、データ、引数、パラメータ、またはメモリ内容を転送および/または受信することによって、別のコードセグメントまたはハードウェア回路に結合されてもよい。情報、引数、パラメータおよびデータなどは、メモリ共有、メッセージ転送、トークン転送、ネットワーク送信などの任意の適切な手段を介して、伝達され、転送され、または送信されてもよい。
さらに、実施形態は、ハードウェア、ソフトウェア、ファームウェア、ミドルウェア、マイクロコード、ハードウェア記述言語、またはそれらの任意の組み合わせによって実施されてもよい。ソフトウェア、ファームウェア、ミドルウェアまたはマイクロコードに実施される場合、必要な作業を実行するプログラムコードまたはコードセグメントは、コンピュータ読取可能な媒体に格納されてもよい。プロセッサは、必要な作業を実行することができる。
本明細書は、ビッグデータおよび関連技術を用いて、低価値データから高価値データを取得および抽出することによって、大量の複雑な高速データを管理および処理するための様々な技術(例えば、方法、システムおよび1つ以上のプロセッサによって実行可能な複数の命令を格納する非一時的なコンピュータ読取可能な記憶メモリ)を記載する。本明細書に記載された例示的なデータベースシステムは、高価値データを抽出または生成すると共に、データを収集および処理することができる。高価値データは、多時間性、出所、フラッシュバックおよび登録クエリなどの機能を提供するデータベースに利用されてもよい。いくつかの例において、コンピューティングモデルおよびシステムを実装することによって、データ駆動状況を認識するコンピューティングシステム内のほぼリアルタイムのデータ処理フレームワークに、知識およびプロセス管理特徴を組み入れることができる。
本明細書に記載の技術は、多時間データベースを保存および更新し、多時間データベース上のフィルタクエリを評価し、フィルタクエリの評価に基づいてデータ変換処理を呼び出すことができる。データストリーム、ビッグデータおよび他の生入力データからの入力データを受信して、多時間データベースに格納することができる。式フィルタ、登録クエリ、トリガ、連続クエリ通知などのデータベース構成物を含むフィルタクエリは、更新された多時間データに基づいて、特定されてもよい。フィルタクエリおよび/またはデータトランザクションプロセスは、現在のデータ状態および1つ以上の過去のデータ状態に基づいて実行されてもよく、複数の実行の間の差は、評価されてもよい。異なるフィルタクエリおよび/または異なる時間およびデータ状態に対応するデータトランザクションプロセスの結果間の差を用いて、追加のデータトランザクションプロセスおよび/またはループアプリケーションインスタンスを呼び出すことができる。
図1を参照して、図1は、データ駆動型変換ループアプリケーションの実行モデルを示すブロック図である。実行モデル100は、データベースシステムまたは他のコンピューティングシステム内の実行エンジンによって実装されてもよい。以下で説明するように、このような実行エンジンは、実行モデル100内の様々な要素をインスタンス化し、追跡および制御するためのデータ駆動型プロセスを実装するように構成された専用ハードウェア、ソフトウェアおよび/またはネットワーク要素を含むことができる。
この例において、実行モデル100は、3つの異なるカテゴリのオブジェクト、すなわち、データオブジェクト、変換オブジェクトおよびフィルタを含む。データオブジェクトは、ファクト、イベントストリーム、関係、XML(Extensible Markup Language)文書、テキストなどの構造化コンテンツ、半構造化コンテンツおよび非構造化の未処理コンテンツを表すことができる。また、データオブジェクトは、カテゴリ、タグ、関係およびコンテナなどのメタデータを表すことができ、および/または、ユーザインターフェイスフォーム、処方箋フォームおよび通知テンプレートなどの取得プロセスによって取り込まれたコンテンツを表すことができる。変換オブジェクトは、アルゴリズム、スクリプト、プロセス、クエリ、RDF(Resource Description Framework)公理、生産ルール、決定木、サポートベクトルマシン、神経ネットワーク、ベイジアンネットワーク、隠れマルコフモデル、ホップフィールドモデル、人間の暗黙知識、および種々の変換データを表すことができる。また、変換オブジェクトは、データオブジェクトを追加、変更または削除するために、これらのデータオブジェクトに適用できるデータを含む。フィルタは、1つ以上のデータオブジェクトおよび変換オブジェクトの環境に評価され得る経路式(path expression)および/またはブール演算式(Boolean expression)に対応する。例えば、フィルタは、データオブジェクトおよび/または変換オブジェクトの変更インスタンスを検出するデータベースシステムに登録された1つ以上のクエリを含むことができる。このようなフィルタは、データベーストリガ、リアルタイムジャーナル解析および/または多時間または双時間データベースシステム上に登録されたクエリを用いて、実装することができる。
図1に示すように、例示的な実行モデル100は、データ変換ループアプリケーションに対応し得る。このデータ変換ループアプリケーションは、潜在的に反復するループプロセスおよび/または不定のループプロセスであってもよい。この例および他の関連する実施形態において、異なるタイプのデータオブジェクトの各々は、異なる属性または特性を有する異なるデータを表すことができ、異なるタイプの変換オブジェクトの各々は、1つのタイプのデータオブジェクトを別のタイプのデータオブジェクトに変換する異なるアルゴリズムまたはシステムの実装であってもよい。例示的な実行モデル100は、4つのタイプのデータオブジェクトおよび4つのタイプの変換オブジェクトを含むが、理解すべきことは、異なる実装例において、異なる数のデータオブジェクトおよび変換オブジェクト(例えば、2つのデータオブジェクトおよび2つの変換オブジェクト、3つのデータオブジェクトおよび3つの変換オブジェクト、...、5つのデータオブジェクトおよび5つの変換オブジェクト)を使用することができることである。また、理解すべきことは、異なる実施形態においてより多くのフィルタオブジェクトまたはより少ないフィルタオブジェクトを実装してもよく、特定の実施形態において一部のフィルタまたは全てのフィルタを実装しなくてもよいことである。
実行モデル100において、第1タイプのデータオブジェクト103、104および120は、計算システムに入力された生の入力を表すことができる。これらの入力は、例えば、Java(登録商標)仮想マシン(JVM)内のガベージコレクタからのデータストリーム、定期的なスレッドダンプからのスタックトレース、メモリヒープダンプ、データベースAWRレポートなどを含んでもよい。第1タイプのデータオブジェクト103、104および120は、非構造化会話、フォーム入力、装置から収集された定量的な測定値、イベントストリームデータ、XML文書またはテキスト文書などであってもよい。第2タイプのデータオブジェクト107、108および110は、第1タイプのデータオブジェクトに基づいて推定された観測結果または予測結果の定性的な説明を表すことができる。いくつかの実施形態において、第2タイプのデータオブジェクト107、108および110は、4つの異なるサブタイプのデータオブジェクト、すなわち、観測オブジェクト、予測オブジェクト、ノルムオブジェクトおよび目的オブジェクトのうち、1つ以上を含むことができる。観測オブジェクトは、ファクトを離散値に個別化することができる。例えば、データベースの接続をブロックするためのスレッドの強度(数字)というファクトを、正常、保護、厳格または重要などの定性値を有する観測オブジェクトに個別化することができる。予測オブジェクトは、変化する条件から予測された定性値を表すことができる。予測オブジェクトは、例えばシミュレーションを介して、観察モデルによって内挿または外挿された定性値を表すことができる。ノルムオブジェクトは、歴史的なベースラインの定性値を表すことができる。目的オブジェクトは、全体的な目的および解決を達成するために、観察オブジェクトおよび予測オブジェクトを求めるための目標定性値を表すことができる。第3タイプのデータオブジェクト112および114は、第2タイプのデータオブジェクト(例えば、観察オブジェクトおよび/または予測オブジェクト)に基づいて推定された診断または原因を表すことができる。例えば、ロードバランサの故障によって、2つのサーバクラスタのうち、第1サーバにおいてスレッドクラスのスレッド強度を高血圧状態(標準よりも有意に高い強度)に分類し、第2サーバにおいて当該スレッドのスレッド強度を低血圧状態(標準よりも有意に低い強度)に分類することは、第3タイプのデータオブジェクト112または114のドメイン特有例であってもよい。第4タイプのデータオブジェクト116および118は、第3タイプのデータオブジェクトに基づいて推定された行う予定の行動セットを表すことができる。例えば、ヒープダンプを捕捉するまたはメモリ管理ポリシーを構成するための一連の命令は、第4タイプのデータオブジェクト116または118のドメイン特有例であってもよい。
各変換オブジェクトは、ハードウェアおよびソフトウェアからなるコンピュータシステム上で実行される自動化ソフトウェアプログラム、アルゴリズム、技術、プロセス、または方法として具現化された抽象化知識を表すことができる。データオブジェクトと同様に、変換オブジェクトは、データベースシステム、ファイルに基づく記憶システム、または任意のデータストアに格納されてもよい。格納された変換オブジェクトを検索し、様々なデータオブジェクトに適用することによって、実行モデル内で様々なタイプのデータを計算することができる。
例えば、実行モデル100において、第1タイプの変換オブジェクト105および106は、例えば、第1タイプのデータオブジェクトに対応するプールまたは生データストリームから取り出した重要なデータを示すコンパクト表現を生成することによって、第1タイプのデータオブジェクトに基づいて、第2タイプのデータオブジェクトを計算するための技術を具体化することができる。第2タイプの変換オブジェクト111は、第2タイプのデータオブジェクトに基づいて、第3タイプのデータオブジェクトを計算するための技術を具体化することができる。第3タイプの変換オブジェクト115は、第3タイプのデータオブジェクトに基づいて、第4タイプのデータオブジェクトを計算するための技術を具体化することができる。例えば、第3タイプの変換オブジェクト115は、基準から逸脱する観測結果または予測結果の度合に基づいて、指令を開発するための技術を含むことができる。第4タイプの変換オブジェクト119は、第4タイプのデータオブジェクトに基づいて、第1タイプのデータオブジェクトを計算するための技術を具体化することができる。例えば、第4タイプの変換オブジェクト119は、仮説(例えば、第3タイプのデータオブジェクト)に応答し且つ追加の生入力(例えば、第1タイプのデータオブジェクト)を捕捉するように設計されてもよい。
実行モデル100内の様々なフィルタオブジェクト101、102、109、113および117は、データオブジェクトと同様に、例えばデータベースまたは他の記憶システムに格納されたデータとして、または変換オブジェクトと同様に、例えば自動化ソフトウェアプログラム、アルゴリズムまたは技術などとして、またはデータとプログラムの組み合わせとして実装されてもよい。場合によって、フィルタオブジェクト101、102、109、113および117は、データオブジェクトのどの程度の変化が変換オブジェクトを呼び出すのに十分であるかを決定するための最小データ変更閾値を実装することができる。追加的または代替的に、フィルタオブジェクト101、102、109、113および117は、データオブジェクトのどの特性が変換オブジェクトを呼び出すのに十分であるかを決定するための条件、極性またはデータの組み合わせによって、最小信頼レベルを実装することができる。上述したように、フィルタは、データベーストリガ、リアルタイムジャーナル解析および/または多時間または双時間データベースシステム上に登録されたクエリを含むことができる。
データオブジェクトおよび変換オブジェクトは、例えば、データオブジェクトからノイズを除去し、異常値データを検出および抽出し、周期性動向を検出および修正するためのメカニズムを実装することができる。例えば、周期性動向トランスフォーマは、持続性データオブジェクトのデータ変化の周期性増加動向を検出し、平滑化強度および平滑化強度増加率を更新して、強度の増加動向を予測することができる。この例において、予測された強度の正規化残差をトランスフォーマとして用いて、測定される強度が予期強度から逸脱していることを表す異常値を検出することができる。さらに、複数の独立のトランスフォーマは、データの推定を追跡することと並列して、異なる時間スケールで、処理を実行することができる。時間スケールに応じて、これらの並列トランスフォーマは、周期性動向、長期容量需要、短期エンドポイント(メモリ不足エラー)などを予測するための複数のポリシーとして機能することができる。
データオブジェクトと同様に、変換オブジェクトは、データ駆動型監視制御ループの実行中に動的に変化することができる。いくつかの実施形態において、監視制御ループは、様々な技術(例えば、非線形回帰)を実行することによって、システム内のJava(登録商標)仮想マシン例の変換パラメータおよび周期ファクタを推定することができる。このような例において、監視制御ループは、(例えば、HotspotまたはJRockit計測器と共にMBeanを使用する)各Java仮想マシンに埋め込まれた1つ以上の変換基準/変換プログラムを更新するために、変換パラメータおよび周期ファクタを変換オブジェクトに組み込むことができる。
1つ以上の実行エンジンを用いて、実行モデル100によって具体化されるアプリケーションなどのデータ駆動型ループアプリケーションを開始、追跡および制御することができる。データオブジェクト、トランスフォーメーションオブジェクトまたはフィルターオブジェクトが動的に更新されるたびに、実行エンジンは、例えば、図示の実行モデル100内の各オブジェクトをインスタンス化し、次いで各オブジェクトによって実行される様々なプロセスを実行および監視すると共に、実行プロセスを制御することができる。実行エンジンは、(例えば、オブジェクト指向クラスを介して)様々なオブジェクトをインスタンス化した後、実行モデル100内のデータオブジェクトのうち1つのデータオブジェクトの新しいデータおよび/または更新されたデータを検出することができる。新しいデータまたは更新されたデータを検出した後、実行エンジンは、適切なフィルタオブジェクトを呼び出すまたはフィルタ(例えば、式フィルタまたは反復クエリ)を自動的に実行することによって、データを分析および/または修正することができ、後続の変換オブジェクトを呼び出すべきか否かを決定することができる。必要に応じて、実行エンジンは、変換オブジェクトを呼び出すことによって、ループ内の次のダウンストリームデータオブジェクトを更新する、例えば第1タイプのデータオブジェクトに対する更新に基づいて、第2タイプのデータオブジェクトを更新することができる。したがって、フィルタまたは変換オブジェクトが後続のデータオブジェクトを更新すべきでないと判断するまで、ループアプリケーションを継続することができる。
また、多時間データベースのリポジトリ121は、低価値データおよび高価値データの両方を含むことができる。例えば、リポジトリ121は、(FSD∪特徴)に対応するデータを含むことができる。(ガードとも呼ばれる)フィルタ101、102、109、113および117は、データベース内のフィルタ基準またはプロセスを実行し、異なる時間状態のフィルタ基準/プロセス間の差を評価するために、リポジトリ121内のデータに対してクエリを行うことによって、現在のデータ状態および/または過去のデータ状態を検索することができる。
また、データ駆動型ループアプリケーションの実行中に、任意の時点で任意のデータオブジェクトに対して追加のデータ更新を行うことができる。例えば、変換オブジェクト115がデータオブジェクト116を更新する実行の最中に、別のデータオブジェクト103が異なるプロセスのデータベーストランザクションまたは新しいデータストリームデータの到着などによって動的に更新されることができる。この例において、実行エンジンは、変換オブジェクト115の実行を完了した後、フィルタリング101および/または変換オブジェクト105を呼び出すことによって、事実上、ループアプリケーションの命令ポインタを実行モデル100の完全に異なる部分に変更することができる。別の例において、実行エンジンは、変換オブジェクト115の実行完了を待たずに、フィルタ101および/または変換オブジェクト105を呼び出すことによって、事実上、ループアプリケーションの複数の命令ポインタを実行モデル100の異なる部分で非同期に動作させることができる。任意の時点で任意のデータオブジェクトに対して追加のデータ更新を行うことができるが、実行モデル100内のデータオブジェクト103、104、110、114および118は、一貫した状態を表すことができる。
実行モデル100の様々な実装において、異なるデータオブジェクト、異なる変換オブジェクトおよび/または異なるフィルタオブジェクトをデータベースまたは他のデータストアに格納することができ、様々なデータベース技術を用いて、実行モデル100および本明細書に開示された他の技術を実装することができる。例えば、実行モデル100内の一部または全部カテゴリのオブジェクトに対して、オブジェクト指向クラス、例えば、データオブジェクトクラスおよび変換オブジェクトクラスを確立することができる。実装された各親クラスから、タイプ特有のサブクラス、例えば、第1タイプのデータオブジェクトサブクラス、第2タイプのデータオブジェクトサブクラス、第3タイプのデータオブジェクトサブクラスおよび第4タイプのデータオブジェクトサブクラス、並びに、第1タイプの変換オブジェクトサブクラス、第2タイプの変換オブジェクトサブクラス、第3タイプの変換オブジェクトサブクラスおよび第4タイプの変換オブジェクトサブクラスを導出することができる。各クラスおよびサブクラスの実装には、適用可能なオブジェクトのカテゴリおよびタイプに適したラベルおよび属性を与えることができる。例えば、実行エンジンは、第1タイプのデータオブジェクトをインスタンス化し、そのデータオブジェクトに関連する属性値を格納することができる。同様に、第1タイプの変換オブジェクトをインスタンス化し、その変換オブジェクトに関連する属性値を格納することができる。以下同様。これらのオブジェクトの各々の定義およびこれらのオブジェクトの全てのインスタンスは、1つ以上のアプリケーションに関連するデータストアに格納されてもよい。例えば、データ駆動型変換ループアプリケーションの実行エンジンは、様々なデータベース技術を用いて、データオブジェクト、変換オブジェクトおよびフィルタオブジェクトの定義およびインスタンスを格納することができる。各インスタンスの履歴を取り出すことができるように、双方向および/または多時間データベースを用いて、各オブジェクトの各インスタンスの複数のバージョンを維持することができる。さらに、いくつかの実施形態において、実行エンジンは、オブジェクトのマッピング(クラス、サブクラスなどのインスタンス化)を生成し、格納することができる。
いくつかの実施形態において、エージェントオブジェクト(またはアクターオブジェクト)は、実行モデル100に含まれてもよく、および/または実行エンジンによって生成および制御されてもよい。エージェントオブジェクトは、自動化エージェントに対応してもよく、個体、個体群または組織を表してもよい。エージェントオブジェクトは、オブジェクト指向プログラミングオブジェクトとしてインスタンス化することができ、プロファイルおよび出所環境などの属性を有することができる。自動化エージェントの例示として、アルゴリズムプロセスをカプセル化するソフトウェア、例えば、ワークフロー、シミュレーション、サポートベクトルマシン、神経ネットワーク、ベイジアンネットワークなどを挙げることができる。自動化エージェントは、エージェントの能力を示すプロファイルを有することができる。エージェントオブジェクトは、組織環境、スキルプロファイル、知識プロファイル、関心プロファイル、嗜好プロファイルなどの属性を有することができる。知識プロファイルは、エージェントオブジェクトに関連付けられ、システムが一般にエンコードしない暗黙知識を表すことができる。エージェントオブジェクトが個体を表す場合、エージェントオブジェクトは、そのオブジェクトによって表される個体のリアルタイム存在および/またはリアルタイム活動を特定することができる。実行エンジンは、エージェントオブジェクトの属性に基づいて、エージェントオブジェクトを実行保留中の特定の変換オブジェクトに割り当てることができる。
以下でさらに説明するように、実行モデル100は、特殊のアルゴリズムを進化させることができる。これらの特殊のアルゴリズムを用いて、分類(classification)、評価(assessment)、解決(resolution)および実施(enactment)のような変換を実行することによって、環境のデータまたは状態を変換することができる。変換オブジェクトは、直接に同時に動作する必要のない特殊のアルゴリズムを表すことがある。データ駆動型プロセスの実行エンジンは、変換オブジェクトの多様なアルゴリズムを別々に開発し、これらのアルゴリズムを、標準化データモデルを介して相間作用する様々なタイプの変換オブジェクト(例えば、第1タイプから第4タイプの変換オブジェクト)としてカプセル化することによって、共通アプリケーションとして進化できる単一のシステムに統合することができる。システム内の様々なアルゴリズムは、相互に補完し、強化することができる。また、実行モデル100内の一部の構成要素は、エージェントオブジェクトのインスタンスと情報を交換するユーザインターフェイスおよびメッセージ通信システムを含むことができる。実行モデル100は、データオブジェクトインスタンスの変化を連続的に照会し、従属の変換オブジェクトの実行を開始することによって、情報交換を駆動する。さらに、変換オブジェクトのアップグレード(例えば、アルゴリズムの更新、新しいバージョンのソフトウェアのリリースなど)は、その変換オブジェクトによる変換を既に適用したデータオブジェクトインスタンスの遡及処理をトリガすることができる。この場合、新しい変換オブジェクト/更新された変換オブジェクトを展開した直後、変換オブジェクトによる変換を適用することができる。
図2を参照して、データ駆動型アプリケーションを実行するコンピュータシステムを示すブロック図が示される。例示のシステム200は、クラウドベースシステムのコンピュータ高次構成を表すことができる。このシステムを用いて、ビッグデータの解析問題を処理するように設計されたデータ駆動型アプリケーションの実装および実行の管理を行うことができる。そのような問題は、非常に巨大なデータ量、高いデータ速度、複雑なデータタイプを含み、ほぼリアルタイムで複雑なイベントを処理する能力を必要とする。この例において、システム200は、HADOOPソフトウェアフレームワークを用いて、データ駆動型アプリケーションを起動および管理するためのシステムに対応する。理解すべきことは、他の例において、HADOOPの代わりに、他のソフトウェアフレームワークを使用することができることである。例示的なシステム200に示された様々な構成要素、例えば、双時間データベース210、オーケストレーションエンジン220、リソースマネージャ230および計算クラスタ240は、ハードウェア要素とソフトウェア要素とネットワーク要素との特殊な組み合わせを含む個別コンピュータシステムまたは共有コンピュータシステムに実装されてもよい。
この例において、双時間データベース210は、本明細書に記載のハードウェア要素、ソフトウェア要素およびネットワーク要素を含む様々なデータベースサーバおよび技術に実装することができる。双時間(または他の多時間)データベーススキーマを使用するデータベース210の場合、データベース210内に格納された様々な異なるオブジェクト(例えば、データオブジェクト、変換オブジェクトおよびフィルタクエリなど)は、データが永続的になるまたは回復可能になるまたは他の回復可能なトランザクションに可視になるときのトランザクション時間を用いて、タイムスタンプを付けることができる。その後、有効時間およびトランザクション時間からなる双時間クエリを用いて、これらのオブジェクトを呼び出すことができる。双時間データベース210におけるこれらの物象化関係に基づいて、データに明示された任意のイベント、例えば、データオブジェクト、変換オブジェクトまたはフィルタの更新に対して、変更を引き起こした原因を判断することができる。例えば、双時間データベース210内の関係は、特定の時間間隔内に第1タイプのデータのインスタンスが1種類の問題として分類され、問題を解決するために、特定の修正がビッグデータシステム内で制定されたことを示すことができる。この例において、双時間データベース210は、データの変更が発生した理由を判断するために、各修正を決定および制定した時間順に、制定された複数の異なる修正をオーケストレーションエンジン220または他のシステム要素に提供することができる。他の実施形態において、他の多時間データベース、例えば、決定タイムに対応するデータ項目の追加タイムラインまたは時間データを含む多時間データベースを使用することができる。
専用のハードウェア要素、ソフトウェア要素およびネットワーク要素の組み合わせを用いて、オーケストレーションエンジン220を実装することによって、ビッグデータ解析システム用のアプリケーションを作成および管理することができる。オーケストレーションエンジン(または実行エンジン)220は、双時間データベース210と共に同一のデータベースシステムに実装されてもよく、別個の制御サーバとして実装されてもよい。いずれの場合でも、オーケストレーションエンジン220は、複雑な時間で登録されたフラッシュバッククエリおよび式フィルタのような、双時間データベース210に関連するデータベース技術を活用するように設計することができる。オーケストレーションエンジン220は、データ変換ループアプリケーションをHADOOPリソースマネージャ230(例えば、HADOOP YARNリソースマネージャ)などのリソースマネージャに割り当てることができる。その割り当てに応答して、HADOOPリソースマネージャ230は、HADOOPクラスタ240を備える計算ノードを選択し、選択したHADOOPクラスタ240内のデータ変換ループアプリケーションのために、アプリケーションマスタ(AM)241を起動することができる。場合によって、アプリケーションマスタ241は、HADOOPリソースマネージャ230と交渉することによって、ループアプリケーションのデータ変換を実行するためのコンテナを得ることができる。ビッグデータ解析の場合、このようなデータ変換行動は、例えば、機械学習行動、大量の生データを使用する分類行動、ベイジアン信念ネットワーク(BBN)エンジン、非線形回帰プロセス、周期性動向プロセスを含んでもよい。いくつかの実施形態において、データ変換ループアプリケーションのアプリケーションマスタ241は、長時間実行するプロセスであってもよい。しかしながら、アプリケーションのループ処理(例えば、実行モデル100)の実行を停止または中断したときに、HADOOPクラスタ240内のコンテナを再使用することができる。オーケストレーションエンジン220は、各データ変換ループアプリケーションの各アプリケーションマスタ241の状態を管理することができ、各アプリケーションマスタ241は、関連するデータ変換インスタンス242の状態を管理することができる。アプリケーションマスタ241およびデータ変換インスタンス242は、1つ以上の高価値データオブジェクトを双時間データベース210内の対応するデータに同期させることができる。
特定の例において、システム200は、クラウドベースSaaSシステム用のビッグデータ解析アプリケーションに対応することができる。例えば、パブリッククラウド内の各テナント型アプリケーションSaaSシステムは、1つ以上の仮想化技術を使用するポッドまたは仮想マシンとデータベースインスタンスとの集合体として実装することができる。アプリケーションSaaSのポッド規模のモデルは、マシンデータの論理的なクラスタリングを可能にし、同一ポッド内のデータストリームを結合および相関させるためのデータ局所性を利用することができるという解析利点を有する。この環境において、各ポッドのデータストリーム(各センサが1つのデータストリームを提供する)の数は、ポッドの数が連続的に増加することにつれて、増加する。データストリームは、例えば、WebLogicサーバログ、Java仮想マシン(JVM)ガベージコレクタログ、JVMスレッドダンプログ、HTTPアクセスログ、オペレーティングシステム監視ログ、ネットワークデバイスログ、データベースログなどを含むことができる。データストリームは、例えば、一組のHBaseテーブルおよびHDFSフォルダに格納することができる。いくつかの例において、横行キーのプレフィックスにおけるポッド名の32桁のMD5摘要を用いて、HBaseテーブル内の領域を分割することによって、各ポッドの全てのデータストリームを同一HBase領域サーバに併置することができる。縦列セル内のデータストリームは、閾値より大きくなると、HDFSファイルにオフロードされてもよい。抽出変換ロード(ETL)操作は、MapReduceのマッパーによって実行され、マッパーとHBase領域サーバとの間のデータローカル類似性によって、同一ポッドのHDFSファイルとHBase領域を同一のデータノードまたはHBase領域サーバの同一場所に配置することができる。この例で説明するデータ編成は、ループアプリケーション、データ変換操作、HBase領域およびHDFSデータノード用のアプリケーションマスタ241の間のデータローカルおよび比較的小さい比率のラックローカル計算を可能にすることができる。さらに、このような例において、オーケストレーションエンジン220およびアプリケーションマスタ241は、動的実体モデルを用いて、HADOOPクラスタ240を有する計算ノードを選択して、データローカルアプリケーションマスタ241およびコンテナを起動することができる。
上記の例におけるアプリケーションSaaSの動的実体モデルは、顧客ポッドと、仮想マシンに配置されたアプリケーションと、サーバのクラスタ内の物理計算ノードに配置された仮想マシンと、サーバ内の物理データノードに配置されたデータベースと、スレッドセグメント、スレッドクラスおよび/またはスレッドクラス間の依存関係に従って定期的なスレッドダンプ内の高強度スタックトレースの動的分類によって発見された実体との間の関係を表すことができる。依存関係は、スレッド間のスレッド間およびプロセス間の交信を取り込むことができる。したがって、スタックトレース分類モデルを実体モデルに追加することができる。上述したように、動的実体モデルは、時間データベース(例えば、双時間データベースまたは他の多時間データベース)によって管理されてもよい。
図3を参照して、多時間データベース内のフィルタクエリに基づいて、データオブジェクト変換処理を呼び出すためのプロセスを示すフローチャートが示される。以下で説明するように、このプロセスにおけるステップは、システム200内の1つ以上の構成要素、例えば、双時間データベース210、オーケストレーションエンジン220およびリソースマネージャ230などによって実行されてもよい。しかしながら、理解すべきことは、多時間データベースの維持および更新、多時間データベース上のフィルタクエリの評価およびフィルタクエリ評価に基づく変換処理の呼び出しを含む本明細書に記載の技術は、上述した特定のシステムおよびハードウェア実装に限定される必要がなく、ハードウェア要素、ソフトウェア要素およびネットワーク要素の他の組み合わせを含む他のハードウェアおよびシステム環境内に行うこともできることである。さらに、例示では、データベースデータの更新に基づいてプロセス300を実行するが、変換オブジェクトおよび/またはフィルタオブジェクトに対する更新に応答して、同様のプロセスおよび技術を実行することもできる。
ステップ301において、例えば、データ駆動型アプリケーションに関連するデータストアおよび/またはデータ管理装置から、データベースの更新を受信することができる。例えば、1つ以上のデータ更新を含むデータベーストランザクションは、双時間データベース210上で開始されてもよく、オーケストレーションエンジン220、HADOOPクラスタ240または他のデータソースを介して受信されてもよい。ステップ301で受信した更新データは、図1のデータオブジェクトを参照して上述した様々なデータタイプ(例えば、非構造化対話、フォーム入力、装置から収集された量的な測定値、イベントストリームデータ、XML、またはテキストドキュメント)のいずれかに対応する構造化、非構造化および/または半構造化データを含むことができる。様々な実施形態において、受信したデータは、例えば、Java仮想マシンのガベージコレクタからのデータストリーム、定期的なスレッドダンプからのスタックトレース、メモリヒープダンプ、およびデータベースAWRレポートなどを表すことができる。
ステップ302において、ステップ301で受信したデータ更新を反映するように、1つ以上の多時間データベースを更新することができる。例えば、双時間データベース210において、更新データは、更新データのトランザクション時間および/または有効時間を含む適切なデータベース構造に書き込むことができる。受信データに関連するトランザクション時間は、データが真であると考えられる1つ以上の時間範囲に対応することができる。有効時間は、受信データがモデル化されたシステムに対して実際に真である時間範囲に対応することができる。例えば、トランザクション時間および有効時間の一方または両方は、ステップ301で受信したデータに含まれてもよい。代替的には、トランザクション時間および/または有効時間は、例えば、オーケストレーションエンジン220によって、受信データに対して動的に決定されてもよい。場合によって、受信データの有効時間は、データに関連するオブジェクトのライフサイクルまたはデータベースのライフサイクルによって、定められてもよい。さらに、特定のオブジェクトは、複数の有効時間を含むことができる。例えば、特徴ベクトルは、異なっており且つ潜在的に重畳する有効時間を有する複数の特徴を含むことができる。この場合、特徴ベクトルの有効時間は、全ての関連特徴の有効時間の共通部分であってもよい。
いくつかの実施形態において、本明細書に記載のシステム、ソフトウェアフレームワークおよび/または実行モデルは、各データオブジェクト(例えば、図1に示す全ての第1タイプから第4タイプのデータオブジェクト)の有効時間、およびデータが永続的になるまたは回復可能になるまたは他の回復可能なトランザクションに可視になるときのトランザクション時間を追跡することができる。これらのシステムは、有効時間およびトランザクションの両方を追跡することによって、異なる時間でデータオブジェクトインスタンスのデータ値を決定することができ、データオブジェクトインスタンスに行われた過去変更の理由を決定することができる。例えば、第4タイプのデータオブジェクト(例えば、指令タイプのデータオブジェクト)の場合、第4タイプのデータオブジェクトの基礎となっている異なる第1タイプ〜第3タイプのデータオブジェクトは、形式上、第4タイプのデータオブジェクトに関連する可能性がある。したがって、オーケストレーションエンジン220または他のシステム要素は、第4タイプのデータオブジェクトの現在のバージョンを生成した時点で、第4タイプのデータオブジェクトに関連する利用可能な第1タイプ〜第3タイプデータオブジェクトを遡及的に決定することができる。時間経過と共に、新しいデータは、実行モデル内の様々な第1タイプ〜第4タイプのデータオブジェクトに対する更新の形で、潜在的にはループアプリケーション内に以前に生成された指令および類似データの結果として利用可能である。この新しいデータは、新しいデータが利用可能になる(例えば、回復可能になるまたは他の回復可能なトランザクションに可視になる)ときの異なるトランザクション時間における過去の有効時間で、異なるオブジェクト/データ状態に遡及的に適用することができる。
したがって、過去データに基づいて後続の変換処理を実行した後にデータに生じた任意の変更/更新は、非因果的なものとして分離することができ、変換処理に形式上関連する有効時間でデータ変更を遡及的に適用できるとしても、データ変更のトランザクション時間を用いて記述することができる。後に取得され、データ変換処理の能力に影響を与える可能性のあるデータ更新は、取得する前に既に存在した場合、データ変換処理の非因果的ものとして明確に特定することができる。これらの後に取得されたデータ更新は、様々なデータビュー、レポートまたは解析から除去され、データ変換処理結果の基礎となる基礎データに混乱を招くことはない。システムは、任意の時点で、特定のデータ変換処理を開始した理由、および結果(例えば、更新した第2タイプのデータオブジェクトインスタンス)を生成するためにデータ変換処理(例えば、1つ以上の第1タイプのデータオブジェクトインスタンス)に利用可能な基礎データを推定することができる。これらの遡及解析は、後のトランザクション時間でデータを修正する前に、先のトランザクション時間で様々なデータをコールすることによって、行うことができる。特定の実施形態において、双時間出所性能は、特定の規制要件を満たすために使用され得る。
ステップ303において、ステップ302で多時間データベースに対して行われた更新に基づいて、1つ以上のフィルタクエリを特定する。フィルタクエリは、多時間データベース内のデータ変更状態を追跡および管理するために使用される任意の技術およびメカニズムを含むことができる。例えば、フィルタクエリは、双時間データベース210内の式フィルタ、登録クエリ、トリガおよび連続クエリ通知などのデータベース構成を含むことができる。また、フィルタクエリは、オーケストレーションエンジン220および/または他のシステム要素内に実装された前方連鎖データおよび/または後方連鎖データの抽出ルールを含むことができる。これらの前方連鎖データおよび/または後方連鎖データは、複数の推論エンジンおよび/または時系列アルゴリズムを統合することができる。一部のフィルタクエリ、例えば、式フィルタおよび登録クエリは、1つ以上のデータベースシステム内に完全に実装されてもよく、他のフィルタクエリ、例えば、オーケストレーションエンジン220または他のシステム要素の内部に実行するデータベースアクセスソフトウェアは、データベースの外部に部分的または全体的に実装されてもよい。
この例において、多時間データベースにおける一組の基礎データの変更に応答して、通知を提供しおよび/または特定の処理を実行するように、フィルタクエリを設計および実装することができる。場合によって、フィルタクエリは、関係データベーステーブルの1つ以上の列に関連する条件式に対応してもよい。例えば、フィルタクエリは、目標の行を特定するために、ステップ303のデータ更新による入来データと、データベースの列に格納された式とをマッチングすることができる。場合によって、フィルタクエリは、単純化SQLクエリの基礎データがデータベース内で変化するたびに、通知を提供するまたは機能を実行する単純化SQLクエリに対応してもよい。例えば、SQLクエリの結果がデータベース内の4つの別々の基礎データ要素に依存する場合、フィルタクエリは、いずれかの基礎データ要素がデータベース内で変化するたびに、通知を生成しまたはプロセスを実行することができる。場合によって、フィルタクエリは、SQLクエリまたは他のデータ駆動型プロセスの結果が変化したことを確実に判定するのでなく、結果の基礎となるデータの変化により、SQLクエリまたは他のデータ駆動型プロセスが潜在的に変化し得ることを判定することができる。別の場合において、次回に更新データを用いてSQLクエリまたは他のデータ駆動型プロセスを実行するときに、フィルタクエリは、SQLクエリまたは他のデータ駆動型プロセスの結果が確実に変化することを判定することができる。
ステップ304において、多時間データベース内の更新データに関連する1つ以上のフィルタクエリを特定した後、現在時間状態の多時間データを用いて、フィルタクエリを実行することができる。したがって、ステップ301で受信した更新データおよび現在データ状態の他の多時間データベースに基づいて、フィルタクエリを実行することができる。
ステップ305において、過去時間状態の多時間データを用いて、ステップ304に実行された同様の1つ以上のフィルタクエリを実行してもよい。場合によって、過去時間状態は、関連する変換動作(または処理)を過去に実行した過去時間に対応してもよい。上述したように、フィルタクエリは、変換動作または他の自動化処理に関連付けられてもよい。例えば、例示的な実行モデル100において、フィルタクエリ101および102は、変換オブジェクト105および106を各々呼び出す時間を判断するためのガードとして機能することができる。同様に、フィルタクエリ109は、変換オブジェクト111を呼び出す時間を判断することができる。したがって、データ変換オブジェクトのインスタンスに関連付けられたフィルタクエリの場合、ステップ305で決定された過去時間状態は、データ変換オブジェクトを実行した最新時間である。ステップ305でフィルタクエリの実行に対応する過去時間状態を決定した後、データベースに記憶された双時間データ(例えば、トランザクション時間および有効時間)を用いて、過去時間のデータベースの正確なデータ状態を生成することができる。場合によって、ステップ305においてフィルタクエリを実行せず、過去時間に決定されたフィルタクエリの過去実行結果を読み出し、ステップ305に使用してもよい。
ステップ306において、現在時間状態のデータを用いて実行した1つ以上のフィルタクエリの結果(ステップ304)と、過去時間状態のデータを用いて実行した同様のフィルタクエリの結果(ステップ305)とを比較し、結果間の差を所定の閾値と比較する。特定の実施形態において、ファクト、知覚、仮説または指令の変更は、所定の閾値条件、方向性、特性または値を用いて、定性化または定量化することができる。閾値条件は、変換の結果を変更することができる変換オブジェクトの変更、例えば、アルゴリズムの新バージョン、バグ修正、モデルパラメータの個別化を含むことができる。フィルタクエリの実行結果の間の差が閾値に等しいまたは閾値を超える場合(306:Yes)、ステップ307でデータ変換処理を呼び出すことができる。このデータ変換処理は、図1の変換オブジェクトを参照して上記に説明したものと同様である。例えば、ステップ307で呼び出されたデータ変換処理は、例示的な実行モデル100の第1タイプ〜第4タイプの変換オブジェクトのインスタンスに対応してもよい。
したがって、各フィルタクエリは、関連する変換処理を実行する時間を判断するために使用されるファクト、認知結果、仮説または指令の変化の1つ以上の閾値条件、方向性、特性または値を有することができる。閾値条件、方向性、特性または値の変化が高いほど、基礎となる時間データにおける変更がより多くなり、関連する変換処理をより少なめに実行する。フィルタクエリに関連する閾値条件、方向性、特性または値は、特定の実施形態において、例えば、頻繁なデータ更新または連続的なデータ更新を受信するビッグデータ解析および他のビッグデータ駆動型アプリケーションにおいて有利であり得る。例えば、WebLogicサーバログ、Java仮想マシン(JVM)ガベージコレクタログ、JVMスレッドダンプログ、HTTPアクセスログ、オペレーティングシステム監視ログ、ネットワークデバイスログ、およびデータベースログなどの大規模なデータストリームを受信し且つ解析するように実装されたループアプリケーションにおいて、システムに受信した全ての更新データに対して変換処理を実行することは、非効率的である。この場合、フィルタクエリおよび関連する閾値条件、方向性、特性または値は、ループアプリケーション内に実行されるデータ変換処理を制限するガードとして機能することができる。その結果、基礎データがダウンストリームデータオブジェクトの著しく変更を引き起こす可能性のある程度まで変化した場合に限り、データ変換処理を行うことができる。
いくつかの実施形態において、例示のプロセス300の様々なステップは、異なるデータベーストランザクションにおよび/または非同期的に実行されてもよい。例えば、大量のストリーミングデータまたは他の頻繁なデータ更新を受信し且つ解析するデータ駆動型アプリケーションにおいて、一方のトランザクションで、ステップ302の多時間データベースを更新し、他方のトランザクションで、ステップ307のデータ変換処理を実施することが有利であり得る。以下で説明するように、ステップ307のデータ変換処理は、追加の反復的なループデータ更新および/または追加の変換処理を実行させる可能性がある。したがって、外部から受信したデータを用いてデータベースを更新するトランザクション(例えば、ステップ301〜302)またはアプリケーションループインスタンスを開始した他のイベントを実行するトランザクションとは別個の1つ以上のトランザクション内に、データ変換および更新を行うアプリケーションループ(例えば、ステップ307および/または後続のステップ401〜416)を実行することによって、一部のシステムの性能および安定性を強化することができる。したがって、いくつかの実装例において、プロセス300のステップ301および302は、1つの専用データベーストランザクションに実行されてもよく、ステップ303〜307(およびこれらのステップに基づいて行われる後続のプロセス401〜416)は、1つ以上の別個のトランザクションに実行されてもよい。さらに、いくつかの実施形態において、(例えば、データベースエンジンの非同期実行モードにおいて)潜在的に低速または長時間実行するループアプリケーションを非同期的に実行することができる。
図4を参照して、ループデータ変換アプリケーションの実行を示すフローチャートが示される。プロセス400内のステップは、システム200内の1つ以上の構成要素、例えば、双時間データベース210、オーケストレーションエンジン220およびリソースマネージャ230によって実行されてもよい。しかしながら、理解すべきことは、本明細書に記載の技術は、上述した特定のシステムおよびハードウェア実装に限定される必要がなく、ハードウェア要素、ソフトウェア要素およびネットワーク要素の他の組み合わせを含む他のハードウェアおよびシステム環境内に行うこともできることである。
図4に示す例示的なプロセス400は、オーケストレーションエンジン220または他のシステム要素によって実装された実行モデルであって、上述した図1の実行モデル100と同様である。この例において、例示のループプロセス400は、実行モデル100と同様に、意図しない不確定なループの発生を回避するために、各データ変換処理を行う前にフィルタおよび閾値を実行するが、潜在的に反復するデータ変換ループおよび/または不確定なデータ変換ループであってもよい。例示的なプロセス400に使用された異なるデータオブジェクト(例えば、第1タイプの〜第4タイプのデータオブジェクト)は、異なる属性または特性を有する異なるタイプのデータオブジェクトに対応してもよく、異なる変換オブジェクト(例えば第1タイプ〜第4タイプの変換オブジェクト)は、1つのタイプのデータオブジェクトを別のタイプのデータオブジェクトに変換するための異なるアルゴリズムまたはシステムの実装に対応してもよい。さらに、例示的なプロセス400は、4つのタイプのデータオブジェクトおよび4つのタイプの変換オブジェクトを含むが、理解すべきことは、異なる実装例において、異なる数のデータオブジェクトおよび変換オブジェクト(例えば、2つのデータオブジェクトおよび2つの変換オブジェクト、3つのデータオブジェクトおよび3つの変換オブジェクト、...、5つのデータオブジェクトおよび5つの変換オブジェクト)を使用することができることである。
プロセス400は、ステップ401で開始することができる。ステップ401は、上述した変換処理を呼び出すステップ307に対応することができる。しかしながら、他の例において、プロセス400は、ステップ401で開始する必要がなく、データ変換を呼び出すステップのいずれか(例えば、ステップ401、405、409または413)、データを生成および記憶するステップのいずれか(例えば、ステップ402、406、410または414)、またはフィルタを実行するステップのいずれか(例えば、ステップ403、407、411または415)で開始することができる。上述したように、データ駆動型ループアプリケーション処理は、多時間データベース210内のデータ状態の変更、変換オブジェクトの変更(例えば、アルゴリズムの更新、新しいバージョンのソフトウェアのリリースなど)、またはフィルタオブジェクトの変更(例えば、式フィルタクエリの更新など)に基づいて開始されてもよい。データ変換オブジェクトおよび/またはフィルタクエリの更新は、古いバージョンの変換オブジェクトおよび/またはフィルタを用いて過去に計算したデータの再計算をトリガすることができる。したがって、システムデータ、変換処理またはフィルタのうち1つ以上に対する更新は、アプリケーションループ処理400の実行を開始することができる。また、場合によって、フィルタおよび/または変換オブジェクトに関連する閾値を動的に更新することができる。更新された閾値に応答して、閾値決定(例えば、ステップ404、408、412および416)のうち1つを動的に再実行することによって、アプリケーションループ処理400を起動することができる。
図5を参照して、いくつかの例示的なデータ項目の有効時間を特定するグラフが示される。グラフ500のx軸は、時間に対応する。グラフ500に標記された時間(t1〜t8)の各々は、システムに発生したイベント、例えば、(例えば、変換オブジェクトインスタンスを介した)データ変換処理の実行、(例えば、データオブジェクトインスタンスを介した)データベースデータの更新、もしくは変換処理またはフィルタの更新に対応する。グラフ500のy軸は、多時間データベースにおける別個のデータ項目、例えば、上述した1つ以上のデータオブジェクトタイプのインスタンスに対応する。グラフ500の線分は、各データ項目の有効時間の範囲を示す。例えば、データD1は、時間t3とt5との間の有効データに対応し、データD2は、時間t1とt2との間の有効データに対応し、以下も同様である。この例のデータが双時間データであるため、複数の異なるデータ項目D1〜D8は、異なる時間における同一のデータ(例えば、同一のデータオブジェクトインスタンス)を表すことができる。例えば、データ項目D1は、時間t3から時間t5までのデータオブジェクトインスタンスを表し、データ項目D8は、時間t5から時間t8までの同一のデータオブジェクトインスタンスを表すことができる。
グラフ500に示された有効時間データを用いて、例えば、上述したステップ305の遡及解析を実行することができる。データ変換処理の再呼び出しまたは再実行を行うためにおよび/またはデータ駆動型ループアプリケーションに使用されるデータ、プロセスまたはフィルタを遡及的に変更するために、多時間データベース内の有効時間データを用いて、マルチデータベースの任意の過去データ状態を検索することができる。例えば、データ駆動型ループアプリケーションは、多時間データベース210内のデータ状態および/または現在時間(例えば、t8)における変換処理またはフィルタの結果および過去時間(例えば、t6)における同様のデータまたは処理を比較することができる。この例において、現在時間(t8)のデータ状態は、データ項目D3、D5、D7およびD8で構成され、過去の有効時間(t6)のデータ状態は、データ項目D3、D4、D5、D6およびD8で構成される。したがって、対応するフィルタクエリおよびデータ変換処理などは、現在時間および過去時間に実行された変換処理および処理を駆動した基礎データの状態を正確に反映することができる。
図6を参照して、本発明の様々な実施形態を実現することができる例示的な分散システムの構成要素を示すブロック図が示される。図示の実施形態において、分散システム600は、1つ以上のネットワーク610を介して、ウェブブラウザまたは専用クライアント(例えば、Oracle(登録商標)フォーム)などのようなクライアントアプリケーションを実行および作動するように構成された1つ以上のクライアントコンピューティング装置602、604、606および608を含む。サーバ612は、ネットワーク610を介して、リモートクライアントコンピューティング装置602、604、606および608と通信可能に接続されてもよい。
さまざまな実施形態において、サーバ612は、システムの1つ以上のコンポーネントによって提供される1つ以上のサービスまたは1つ以上のソフトウェアアプリケーションを実行するように構成されることができる。いくつかの実施形態において、これらのサービスは、ウェブサービスまたはクラウドサービスとして、またはSaaS(Software as a Service)モデルに基づいて、クライアントコンピューティング装置602、604、606および/または608のユーザに提供されてもよい。よって、クライアントコンピューティング装置602、604、606および/または608を操作するユーザは、1つ以上のクライアントアプリケーションを用いて、サーバ612と情報を交換することによって、これらのコンポーネントによって提供されたサービスを利用することができる。
図示の構成において、システム600のソフトウェア要素618、620および622は、サーバ612上に実装されている。他の実施形態において、システム600の1つ以上の構成要素および/またはこれらのコンポーネントによって提供されたサービスは、1つ以上のクライアントコンピューティング装置602、604、606および/または608によって実現されてもよい。クライアントコンピューティング装置を操作するユーザは、1つ以上のクライアントアプリケーションを用いて、これらのコンポーネントによって提供されたサービスを利用することができる。これらの構成要素は、ハードウェア、ファームウェア、ソフトウェア、またはこれらの組み合わせで実現されてもよい。理解すべきことは、分散システム600と異なるさまざまなシステム構成が可能であることである。したがって、図示された実施形態は、実施形態のシステムを実現するための分散システムの一例であり、限定することを意図していない。
クライアントコンピューティング装置602、604、606および/または608は、例えば、Microsoft Windows Mobile(登録商標)のようなソフトウェア、および/またはiOS、Windows(登録商標)フォン、アンドロイド(登録商標)、ブラックベリー(登録商標)10およびパームOSなどのさまざまなモバイルオペレーティングシステムを実行することができ、インターネット、電子メール、ショートメッセージサービス(SMS)、ブラックベリー(登録商標)または他の通信プロトコルが有効化された手持ち式携帯装置(例えば、iPhone(登録商標)、携帯電話、Ipad(登録商標)、タブレット、携帯情報端末(PDA)または着用できる装置(Google Glass(登録商標)ヘッドマウントディスプレイ)であってもよい。クライアントコンピューティング装置は、例示として、Microsoft Windows(登録商標)オペレーティングシステム、Apple Macintosh(登録商標)オペレーティングシステムおよび/またはLinux(登録商標)オペレーティングシステムのさまざまなバージョンを実行するパーソナルコンピュータおよび/またはラップトップコンピュータを含む汎用のパーソナルコンピュータであってもよい。クライアントコンピューティング装置は、例えば、さまざまなGNU/Linuxオペレーティングシステム、例えば、Google(登録商標)Chrome OSを含むがこれに限定されない市販のUNIX(登録商標)またはUNIXに類似するさまざまなオペレーティングシステムを動かすワークステーションコンピュータであってもよい。代替的にまたは追加的には、クライアントコンピューティング装置602、604、606および608は、ネットワーク610を介して通信可能なシンクライアントコンピュータ、インターネット対応のゲームシステム(例えば、Kinect(登録商標)ジェスチャ入力装置を備えるまたは備えないMicrosoft Xboxゲームコンソール)、および/またはパーソナルメッセージング装置などの他の電子機器であってもよい。
例示の分散システム600は、4つのクライアントコンピューティング装置を備えると示されているが、任意の数のクライアントコンピューティング装置をサポートすることができる。他の装置、例えばセンサを有する装置は、サーバ612と情報を交換することができる。
分散システム600のネットワーク610は、TCP/IP(伝送制御プロトコル/インターネットプロトコル)、SNA(システムネットワークアーキテクチャ)、IPX(インターネットパケット交換)、Apple Talkなどを含むがこれらに限定されないさまざまな市販プロトコルのいずれかを使用してデータ通信をサポートすることができ、当業者に熟知される任意種類のネットワークであってもよい。単なる例示として、ネットワーク610は、イーサネット(登録商標)、トークンリングおよび/またはその他に基づくローカルエリアネットワーク(LAN)であってもよい。ネットワーク610は、広域ネットワークまたはインターネットであってもよい。ネットワーク610は、仮想プライベートネットワーク(VPN)を含むがこれに限定されない仮想ネットワーク、イントラネット、エクストラネット、公衆交換電話ネットワーク(PSTN)、赤外線ネットワーク、無線ネットワーク(例えば、IEEE(Institute of Electrical and Electronic Engineers)802.11プロトコルスイート、Bluetooth(登録商標)、および/または任意の他の無線プロトコルの下で動作するネットワーク)および/またはこれらのネットワークと他のネットワークの組み合わせを含むことができる。
サーバ612は、1つ以上の汎用コンピュータ、専用サーバコンピュータ(例示として、PC(パーソナルコンピュータ)サーバ、UNIX(登録商標)サーバ、ミッドレンジサーバ、メインフレームコンピュータ、ラックマウントサーバを含む)、サーバファーム、サーバクラスタ、または任意の他の適切な構成および/または組み合わせから構成されてもよい。さまざまな実施形態において、サーバ612は、前述の開示に記載された1つ以上のサービスまたはソフトウェアアプリケーションを動かすように構成することができる。例えば、サーバ612は、本開示の実施形態に従って上記に説明した処理を実行するためのサーバに対応することができる。
サーバ612は、上述したものいずれかを含むオペレーティングシステム、および任意の市販サーバオペレーティングシステムを動かすことができる。また、サーバ612は、HTTP(ハイパーテキスト転送プロトコル)サーバ、FTP(ファイル転送プロトコル)サーバ、CGI(共通ゲートウェイインターフェイス)サーバ、Java(登録商標)サーバ、データベースサーバなどを含むさまざまな追加サーバアプリケーションおよび/または中間層アプリケーションのいずれかを動かすことができる。例示的なデータベースサーバは、Oracle(登録商標)、Microsoft(登録商標)、Sybase(登録商標)、IBM(登録商標)などの会社から市販されているものを含むがこれらに限定されない。
いくつかの実現例において、サーバ612は、クライアントコンピューティング装置602、604,606および608のユーザから受信したデータフィードおよび/またはイベント更新を分析および統合する1つ以上のアプリケーションを含んでもよい。例示として、データフィードおよび/またはイベント更新は、Twitter(登録商標)フィード、Facebook(登録商標)更新または1つ以上の第3情報源および連続データストリームから受信したリアルタイム更新を含むがこれらに限定されない。リアルタイム更新は、センサデータアプリケーション、金融相場表示機、ネットワーク性能測定ツール(例えば、ネットワーク監視およびトラフィック管理アプリケーション)、ページ遷移(Clickstream)解析ツール、自動車交通監視装置などに関連するリアルタイムイベントを含むことができる。また、サーバ612は、クライアントコンピューティング装置602、604、606および608の1つ以上の表示装置を介して、データフィードおよび/またはリアルタイムイベントを表示するための1つ以上のアプリケーションを含むこともできる。
また、分散システム600は、1つ以上のデータベース614および616を含むこともできる。データベース614および616は、さまざまな場所に常駐することができる。例示として、1つ以上のデータベース614および616は、サーバ612の近く(および/またはその中)の非一時記憶媒体に常駐することができる。代替的には、データベース614および616は、リモートサーバ612から離れており、ネットワークに基づく接続または専用接続を介して、サーバ612と通信している。一組の実施形態において、データベース614および616は、記憶領域ネットワーク(SAN)に常駐することができる。同様に、サーバ612に寄与する機能を実行するための任意の必要なファイルは、必要に応じて、サーバ612上に/またはサーバ612から離れた場所に保存されてもよい。一組の実施形態において、データベース614および616は、例えば、Oracleにより提供されたデータベースなどの関係データベースを含むことができる。これらの関係データベースは、SQLフォーマット命令に応じて、データを取得、保存および更新するように構成されている。
図7を参照して、サービスをクラウドサービスとして提供することができるシステム環境の構成要素を示すブロック図が示される。図示の実施形態において、システム環境700は、1つ以上のクライアントコンピューティング装置704、706および708を含む。ユーザは、クライアントコンピューティング装置を用いて、クラウドサービスを提供するクラウドインフラストラクチャシステム702と情報を交換することができる。クライアントコンピューティング装置は、ウェブブラウザ、専用クライアントアプリケーション(例えば、Oracleフォーム)または他のアプリケーションなどのクライアントアプリケーションを作動するように構成されることができる。ユーザは、クライアントアプリケーションを用いてクラウドインフラストラクチャシステム702と情報を交換することによって、クラウドインフラストラクチャシステム702により提供されたサービスを利用することができる。
理解すべきことは、図示のクラウドインフラストラクチャシステム702は、図示された構成要素以外の構成要素を備えてもよいことである。さらに、図示の実施形態は、本発明の実施形態を組み込むことができるクラウドインフラストラクチャシステムの一例に過ぎない。いくつかの他の実施形態において、クラウドインフラストラクチャシステム702は、図示よりも多いまたは少ない構成要素を有してもよく、2つ以上の構成要素を組み合わせてもよく、または異なる構成または配置の構成要素を有してもよい。
クライアントコンピューティング装置704、706および708は、上述したクライアントコンピューティング装置602、604、606および608と同様であってもよい。
例示的なシステム環境700は、3つのクライアントコンピューティング装置を備えると示されているが、任意の数のクライアントコンピューティング装置をサポートすることができる。他の装置、例えば、センサを有する装置は、クラウドインフラストラクチャシステム702と情報を交換することができる。
ネットワーク710は、クライアント704、706および708とクラウドインフラストラクチャシステム702との間のデータの通信および交換を促進することができる。各ネットワークは、上記でネットワーク1310に関して説明したプロトコルをさまざまな市販プロトコルのいずれかを用いてデータ通信をサポートすることができ、当業者に熟知する任意種類のネットワークであってもよい。
クラウドインフラストラクチャシステム702は、上記でサーバ1312に関して説明した構成要素を含み得る1つ以上のコンピュータおよび/またはサーバを含むことができる。
特定の実施形態において、クラウドインフラストラクチャシステムによって提供されたサービスは、需要に応じて、クラウドインフラストラクチャシステムからユーザに提供できるオンラインデータの記憶およびバックアップ、ウェブベースの電子メールサービス、ホストされたオフィススイートおよび文章連携サービス、データベース処理、管理できる技術サポートサービスなどの多くのサービスを含んでよい。クラウドインフラストラクチャシステムによって提供されるサービスは、ユーザのニーズを満たすように動的に拡張できる。クラウドインフラストラクチャシステムによって提供されたサービスの特定の例示は、本明細書において、「サービスインスタンス」と呼ばれる。一般的には、インターネットなどの通信ネットワークを介して、クラウドサービスプロバイダのシステムからユーザに提供できる任意のサービスは、「クラウドサービス」と呼ばれる。典型的には、パブリッククラウド環境において、クラウドサービスプロバイダのシステムを構成するサーバおよびシステムは、顧客のオンプレミスサーバおよびシステムとは異なる。たとえば、クラウドサービスプロバイダのシステムは、アプリケーションをホストすることができ、ユーザは、必要に応じて、インターネットなどの通信ネットワークを介して、アプリケーションを注文し、使用することができる。
いくつかの例において、コンピュータネットワーククラウドインフラストラクチャ内のサービスは、保護されたコンピュータネットワークのストレージアクセス、ホストされたデータベース、ホストされたウェブサーバ、ソフトウェアアプリケーション、またはクラウドベンダによってユーザに提供された他のサービス、または当該技術分野に知られている他のサービスを含むことができる。たとえば、サービスは、インターネットを介して、クラウド上のリモートストレージに対して、パスワードにより保護されたアクセスを含むことができる。別の例として、サービスは、ウェブサービスにホストされている関係データベースおよびネットワーク上の開発者により私的使用のためのスクリプト言語ミドルウェアエンジンを含むことができる。別の例として、サービスは、クラウドベンダのウェブサイト上でホストされている電子メールソフトウェアアプリケーションに対するアクセスを含むことができる。
特定の実施形態において、クラウドインフラストラクチャシステム702は、セルフサービスのサブスクリプションに基づく、柔軟なスケーラビリティ、信頼性、高可用性および安全性を有する方法で、顧客に提供できる一連のアプリケーション、ミドルウェアおよびデータベースサービスを含むことができる。このようなクラウドインフラストラクチャシステムの例示として、本願譲受人により提供されたOracleパブリッククラウドが挙げられる。
さまざまな実施形態において、クラウドインフラストラクチャシステム702は、顧客から申込んだクラウドインフラストラクチャシステム702のサービスを自動的に提供、管理および追跡するように構成されることができる。クラウドインフラストラクチャシステム702は、さまざまな展開モデルを介して、クラウドサービスを提供することができる。たとえば、サービスは、クラウドサービスを販売する組織に所有された(たとえば、Oracleに所有された)クラウドインフラストラクチャシステム702を有するパブリッククラウドモデルで提供され、一般人または異なる業界の企業に利用されることができる。別の例として、サービスは、単一の組織に専用されたクラウドインフラストラクチャシステム702を有するプライベートクラウドモデルで提供され、組織内の1つ以上の実体に利用されることができる。また、クラウドサービスは、集団クラウドモデルで提供されてもよい。よって、クラウドインフラストラクチャシステム702およびクラウドインフラストラクチャシステム702により提供されたサービスは、関連する集団内の複数の組織によって共有される。また、クラウドサービスは、2つ以上の異なるモデルの組み合わせからなるハイブリッドクラウドモデルで提供されてもよい。
いくつかの実施形態において、クラウドインフラストラクチャシステム702によって提供されたサービスは、SaaS(Software as a Service)カテゴリ、PaaS(Platform as a Service)カテゴリ、IaaS(Infrastructure as a Service)カテゴリ、またはハイブリッドサービスを含む他のカテゴリのサービスに準拠して提供された1つ以上のサービスを含むことができる。顧客は、サブスクリプションの申込みによって、クラウドインフラストラクチャシステム702によって提供された1つ以上のサービスを注文することができる。これに応じて、クラウドインフラストラクチャシステム702は、顧客のサブスクリプション申込書に含まれたサービスを提供する処理を行う。
いくつかの実施形態において、クラウドインフラストラクチャシステム702によって提供されたサービスは、アプリケーションサービス、プラットフォームサービスおよびインフラストラクチャサービスを含むがこれらに限定されない。いくつかの例において、アプリケーションサービスは、SaaSプラットフォームを介して、クラウドインフラストラクチャシステムによって提供されてもよい。SaaSプラットフォームは、SaaSカテゴリに準拠するクラウドサービスを提供するように構成されてもよい。たとえば、SaaSプラットフォームは、統合の開発および展開プラットフォーム上でオンデマンドアプリケーションのスイートを構築し、提供するように、機能することができる。SaaSプラットフォームは、SaaSサービスを提供するために、基礎のソフトウェアおよびインフラストラクチャを管理し、制御することができる。SaaSプラットフォームにより提供されたサービスを利用することによって、顧客は、クラウドインフラストラクチャシステム上で動作するアプリケーションを利用することができる。顧客は、別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得することができる。さまざまな異なるSaaSサービスを提供することができる。例示としては、販売実績管理、企業統合、および大規模組織のビジネス柔軟性に対する解決策を提供するサービスを含むがこれらに限定されない。
いくつかの実施形態において、プラットフォームサービスは、PaaSプラットフォームを介してクラウドインフラストラクチャシステムによって提供されてもよい。PaaSプラットフォームは、PaaSカテゴリに準拠するクラウドサービスを提供するように構成されてもよい。プラットフォームサービスの例としては、共有されている共通アーキテクチャ上で既存のアプリケーションを統合する能力、およびプラットフォームにより提供された共有サービスを活用する新規アプリケーションを構築する能力を組織(たとえば、Oracle)に与えるサービスを含むがこれに限定されない。PaaSプラットフォームは、PaaSサービスを提供するために、基礎のソフトウェアおよびインフラストラクチャを管理し、制御することができる。顧客は、クラウドインフラストラクチャシステム上で動作するアプリケーションを利用することができる。顧客は、別々のライセンスおよびサポートを購入する必要なく、アプリケーションサービスを取得することができる。さまざまな異なるSaaSサービスを提供することができる。プラットフォームサービスの例としては、Oracle Javaクラウドサービス(JCS)、Oracleデータベースクラウドサービス(DBCS)およびその他を含むがこれらに限定されない。
PaaSプラットフォームにより提供されたサービスを利用することによって、顧客は、クラウドインフラストラクチャシステムにサポートされているプログラミング言語およびツールを利用することができ、展開されたサービスを制御することができる。いくつかの実施形態において、クラウドインフラストラクチャシステムによって提供されるプラットフォームサービスは、データベースクラウドサービス、ミドルウェアクラウドサービス(たとえば、Oracle Fusionミドルウェアサービス)、およびJavaクラウドサービスを含むことができる。一実施形態において、データベースクラウドサービスは、データベースリソースを蓄積する能力を組織に与えることができる共有サービス展開モデルをサポートすることができ、DBaaS(Database as a Service)をクラウドデータベースとして顧客に提供することができる。ミドルウェアクラウドサービスは、クラウドインフラストラクチャシステム上でさまざまなビジネスアプリケーションを開発および展開するためのプラットフォームを顧客に提供することができ、Javaクラウドサービスは、クラウドインフラストラクチャシステム上でJavaアプリケーションを展開するためのプラットフォームを顧客に提供することができる。
種々の異なるインフラストラクチャサービスは、IaaSプラットフォームによって、クラウドインフラストラクチャシステムに提供されてもよい。これらのインフラストラクチャサービスは、SaaSプラットフォームおよびPaaSプラットフォームにより提供されたサービスを利用する顧客のために、ストレージ、ネットワークおよびその他の基本的なコンピューティングリソースとしての基礎コンピューティングリソースの管理と制御を容易にする。
特定の実施形態において、クラウドインフラストラクチャシステム702はまた、クラウドインフラストラクチャシステムを利用する顧客に、さまざまなサービスを提供するために使用されるリソースを提供するためのインフラストラクチャリソース730を含むことができる。一実施形態において、インフラストラクチャリソース730は、PaaSプラットフォームおよびSaaSプラットフォームによって提供されたサービスを実行するために、事前に統合され且つ最適化されたサーバリソース、ストレージリソースおよびネットワークリソースなどのハードウェアの組み合わせを含んでもよい。
いくつかの実施形態において、クラウドインフラストラクチャシステム702内のリソースは、複数のユーザに共有されることができ、各々の需要に応じて動的に再割当てることができる。また、リソースは、異なるタイムゾーンでユーザに割当てることができる。たとえば、クラウドインフラストラクチャシステム730は、指定時間内でクラウドインフラストラクチャシステムのリソースを第一時間帯における第一グループのユーザに利用させ、その後、同様のリソースを異なる時間帯における別のグループのユーザに再配分することができ、リソースを最大に利用する。
特定の実施形態において、複数の内部共有サービス732は、提供され、クラウドインフラストラクチャシステム702の異なる構成要素またはモジュールに共有されおよびクラウドインフラストラクチャシステム702によって提供されたサービスに共有されることができる。これらの内部共有サービスは、安全性および識別サービス、統合サービス、企業リポジトリサービス、企業管理サービス、ウイルススキャンおよびホワイトリストサービス、高可用性のバックアップおよびリカバリサービス、クラウドサポートを可能にするサービス、メールサービス、通知サービス、およびファイル転送サービスなどを含むがこれらに限定されない。
特定の実施形態において、クラウドインフラストラクチャシステム702は、クラウドインフラストラクチャシステム内のクラウドサービス(たとえば、SaaSサービス、PaaSサービスおよびIaaSサービス)を包括的に管理する機能を提供することができる。一実施形態において、クラウド管理機能は、クラウドインフラストラクチャシステム702などによって受信した顧客のサブスクリプションを提供、管理、および追跡する機能を含んでもよい。
一実施形態において、図示のように、クラウド管理機能は、1つ以上のモジュール、たとえば、オーダー管理モジュール720、オーダーオーケストレーションモジュール722、オーダー支給モジュール724、オーダー管理および監視モジュール726、およびID管理モジュール728によって提供される。これらのモジュールは、1つ以上のコンピュータおよび/またはサーバを含んでもよく、これらを用いて形成されてもよい。これらのコンピュータおよび/またはサーバは、汎用コンピュータ、専用サーバコンピュータ、サーバファーム、サーバクラスタ、または任意の他の適切な配置および/またはこれらの組み合わせであってもよい。
例示的な操作734において、顧客は、クライアント装置、たとえば、クライアント装置704、706または708を使用して、クラウドインフラストラクチャシステム702により提供された1つ以上のサービスをリクエストし、クラウドインフラストラクチャシステム702によって提供された1つ以上のサービスをオーダーすることによって、クラウドインフラストラクチャシステム702と情報を交換することができる。特定の実施形態において、顧客は、クラウドユーザインターフェイス(UI)、クラウドUI712、クラウドUI714および/またはクラウドUI716にアクセスし、これらのUIを介して、サブスクリプションをオーダーすることができる。クラウドインフラストラクチャシステム702が顧客のオーダーに応答して受信したオーダー情報は、顧客と、クラウドインフラストラクチャシステム702により提供され、顧客が購読しようとする1つ以上のサービスとを識別する情報を含むことができる。
顧客がオーダーした後、オーダー情報は、クラウドUI712、714および/または716を介して受信される。
操作736において、オーダーは、オーダーデータベース718に保存される。オーダーデータベース718は、クラウドインフラストラクチャシステム718によって操作され、または他のシステム要素と連動して操作されるいくつかのデータベースのうち1つであってもよい。
操作738において、オーダー情報は、オーダー管理モジュール720に転送される。いくつかの例において、オーダー管理モジュール720は、オーダーに関連する請求および会計機能、たとえば、オーダーの確認、および確認後オーダーの記入を実行するように構成されてもよい。
操作740において、オーダーに関する情報は、オーダーオーケストレーションモジュール722に伝達される。オーダーオーケストレーションモジュール722は、オーダー情報を利用して、顧客がオーダーしたサービスおよびリソースの提供を用意する。いくつかの例において、オーダーオーケストレーションモジュール722は、オーダー支給モジュール724のサービスを用いて、オーダーしたサービスをサポートするように、リソースの提供を用意することができる。
特定の実施形態において、オーダーオーケストレーションモジュール722は、各オーダーに関連したビジネスプロセスを管理することができ、ビジネスロジックを適用することによって、オーダーに対して支給をするか否かを判断することができる。操作742において、新規サブスクリプションのオーダーを受信すると、オーダーオーケストレーションモジュール722は、リソースを割当て、サブスクリプションオーダーを満たすために必要なリソースを構成するように、リクエストをオーダー支給モジュール724に送信する。オーダー支給モジュール724は、顧客がオーダーしたサービス用のリソースを割当てることができる。オーダー支給モジュール724は、クラウドインフラストラクチャシステム700により提供されたクラウドサービスと、リクエストされたサービスを提供するためのリソースを供給するために使用される物理的な実装層との間の抽象化レベルを形成する。このように、オーダーオーケストレーションモジュール722は、たとえば、サービスおよびリソースをその場で支給するかまたは事前に支給するか、リクエストに応じて割当てる/与えるかなどの実装詳細から単離することができる。
操作744において、サービスおよびリソースを支給した後、クラウドインフラストラクチャシステム702のオーダー支給モジュール724は、提供されるサービスの通知をクライアント装置704、706および/または708の顧客に送信することができる。
操作746において、オーダー管理および監視モジュール726は、顧客のサブスクリプションオーダーを管理および追跡することができる。いくつかの例において、オーダー管理および監視モジュール726は、サブスクリプションオーダー内のサービスの利用統計、たとえば、ストレージの使用量、データの転送量、ユーザの数、システムの起動時間およびシステムの停止時間を収集するように構成されることができる。
特定の実施形態において、クラウドインフラストラクチャシステム700は、ID管理モジュール728を含むことができる。ID管理モジュール728は、クラウドインフラストラクチャシステム700に、識別サービス、たとえば、アクセス管理および認可サービスを提供するように構成することができる。いくつかの実施形態において、ID管理モジュール728は、クラウドインフラストラクチャシステム702によって提供されたサービスを利用したい顧客に関する情報を制御することができる。このような情報は、顧客のIDを承認する情報、およびさまざまなシステムリソース(たとえば、ファイル、ディレクトリ、アプリケーション、通信ポート、メモリセグメントなど)に対して許可された顧客の実行権限を記載する情報を含むことができる。ID管理モジュール728は、各顧客に関する記述情報、記述情報にアクセスおよび変更する方法、および記述情報にアクセスおよび変更した顧客に対する管理を含むことができる。
図8を参照して、本発明の実施形態を実施することができる例示的なコンピュータシステムを示すブロック図が示される。コンピュータシステム800を用いて、上述したコンピュータシステムのいずれかを実現することができる。図示のように、コンピュータシステム800は、バスサブシステム802を介して、複数の周辺サブシステムと連通する処理ユニット804を含む。周辺サブシステムは、処理加速ユニット806と、I/Oサブシステム808と、記憶サブシステム818と、通信サブシステム824とを含むことができる。記憶サブシステム818は、有形コンピュータ可読記憶媒体822と、システムメモリ810とを含む。
バスサブシステム802は、コンピュータシステム800のさまざまな構成要素およびサブシステムが必要に応じて相互通信させるための機構を形成する。バスサブシステム802を単一のバスとして概略的に示しているが、代替的な実施形態において、バスサブシステムは、複数のバスを利用してもよい。バスサブシステム802は、メモリバスまたはメモリコントローラ、周辺バス、およびさまざまなバスアーキテクチャのいずれかを使用するローカルバスを備えるいくつかの種類のバス構造のいずれかを有してもよい。たとえば、このようなアーキテクチャは、業界標準アーキテクチャ(ISA)バス、マイクロチャネルアーキテクチャ(MCA)バス、拡張ISA(EISA)バス、ビデオエレクトロニクス規格協会(VESA)ローカルバス、および周辺構成要素相互接続(PCI)バスを含むことができる。これらのバスは、IEEE P1386.1規格に準拠した製造されたメザニンバスとして実装することができる。
1つ以上の集積回路(たとえば、従来のマイクロプロセッサまたはマイクロコントローラ)として実装することができる処理ユニット804は、コンピュータシステム800の操作を制御する。処理ユニット804は、1つ以上のプロセッサを含むことができる。これらのプロセッサは、シングルコアプロセッサであってもよく、マルチコアプロセッサであってもよい。特定の実施形態において、処理ユニット804は、各々シングルコアプロセッサまたはマルチコアプロセッサを備える1つ以上の独立した処理ユニット832および/または834として実装されてもよい。他の実施形態において、処理ユニット804は、2つのデュアルコア(dual-core)プロセッサを単一のチップに集積することにより形成されたクアッドコア(Quad-core)処理ユニットとして実装されてもよい。
さまざまな実施形態において、処理ユニット804は、プログラムコードに応じてさまざまなプログラムを実行することができ、複数のプログラムまたはプロセスを同時に実行することができる。任意の時点で、実行されるプログラムコードの一部または全てをプロセッサ804および/または記憶サブシステム818に常駐することができる。適切なプログラミングによって、プロセッサ804は、上述したさまざまな機能を提供することができる。コンピュータシステム800は、デジタルシグナルプロセッサ(DSP)および専用プロセッサなどを含むことができる処理加速ユニット806をさらに備えてもよい。
I/Oサブシステム808は、ユーザインターフェイス入力装置と、ユーザインターフェイス出力装置とを含むことができる。ユーザインターフェイス入力装置は、キーボード、マウスまたはトラックボールなどのポインティング装置、ディスプレイに組み込まれたタッチパッドまたはタッチスクリーン、スクロールホイール、クリックホイール、ダイヤル、ボタン、スイッチ、キーパッド、音声命令認識システムを備える音声入力装置、マイクロフォン、および他の種類の入力装置を含んでもよい。また、ユーザインターフェイス入力装置は、たとえば、Microsoft Kinect(登録商標)モーションセンサのようなモーション検知および/またはジェスチャ認識装置を含んでもよい。Microsoft Kinect(登録商標)モーションセンサは、ジェスチャおよび音声命令を利用する自然ユーザインターフェース(NUI)を介して、Microsoft Xbox(登録商標)360ゲームコントローラなどの入力装置を制御することができ、それと対話することができる。また、ユーザインターフェイス入力装置は、Google Glass(登録商標)瞬き検出器のような眼球ジェスチャ認識装置を含むことができる。Google Glass(登録商標)瞬き検出器は、ユーザの眼球活動(たとえば、写真を撮るときおよび/またはメニューを選択するときの「瞬き」)を検出し、眼球活動を入力装置(たとえば、Google Glass(登録商標))に入力する入力に変換する。さらに、ユーザインターフェイス入力装置は、音声命令を介してユーザと音声認識システム(たとえば、Siri(登録商標)ナビゲータ)との対話を可能にする音声認識検出装置を含んでもよい。
また、ユーザインターフェイス入力装置は、三次元(3D)マウス、ジョイスティックまたはポインティングスティック、ゲームパッド、グラフィックタブレット、スピーカなどのオーディオ/ビジュアル装置、デジタルカメラ、デジタルビデオカメラ、ポータブルメディアプレーヤ、ウェブカメラ、イメージスキャナ、指紋スキャナ、バーコードリーダ、3Dスキャナ、3Dプリンタ、レーザ距離計、および視線追跡装置を含むがこれらに限定されない。さらに、ユーザインターフェイス入力装置は、たとえば、コンピュータ断層撮影装置、磁気共鳴像装置、超音波放射断層撮影装置、および医療用超音波装置などのような医用画像入力装置を含んでもよい。また、ユーザインターフェイス入力装置は、たとえば、MIDIキーボードおよび電子楽器などの音声入力装置を含んでもよい。
ユーザインターフェイス出力装置は、ディスプレイサブシステム、インジケータライト、またはオーディオ出力装置などの非視覚ディスプレイを含んでもよい。ディスプレイサブシステムは、たとえば、陰極線管(CRT)、液晶ディスプレイ(LCD)またはプラズマディスプレイを使用するフラットパネル装置、投射装置またはタッチスクリーンであってもよい。一般に、「出力装置」という用語を使用する場合、コンピュータシステム800から情報をユーザまたは他のコンピュータに出力するためのすべての可能な種類の装置および機構を含むことを意図している。たとえば、ユーザインターフェイス出力装置は、文字、画像およびオーディオ/ビデオ情報を視覚的に伝達するさまざまな表示装置、たとえば、モニタ、プリンタ、スピーカ、ヘッドフォン、カーナビゲーションシステム、プロッタ、音声出力装置、およびモデムを含むがこれらに限定されない。
コンピュータシステム800は、記憶サブシステム818を含むことができる。記憶サブシステム818は、ソフトウェア要素を備え、図示では、これらのソフトウェア要素は、システムメモリ1510内に配置されている。システムメモリ810は、処理ユニット804にロード可能且つ実行可能なプログラム命令、およびこれらのプログラムの実行により生成されたデータを記憶することができる。
コンピュータシステム800の構成および種類に応じて、システムメモリ810は、揮発性メモリ(たとえば、ランダムアクセスメモリ(random access memory:RAM))であってもよく、および/または、不揮発性メモリ(たとえば、読取り専用メモリ(read-only memory:ROM)、フラッシュメモリ)であってもよい。一般に、RAMは、処理ユニット804がすぐにアクセス可能なデータおよび/またはプログラムモジュール、および/または、処理ユニット804によって現在操作および実行されているデータおよび/またはプログラムモジュールを収容する。いくつかの実現例では、システムメモリ810は、スタティックランダムアクセスメモリ(static random access memory:SRAM)またはダイナミックランダムアクセスメモリ(dynamic random access memory:DRAM)などの複数の異なる種類のメモリを含み得る。いくつかの実現例では、始動中などにコンピュータシステム800内の要素間で情報を転送することを助ける基本ルーチンを含む基本入力/出力システム(basic input/output system:BIOS)が、一般にROMに格納され得る。一例としておよび非限定的に、システムメモリ810は、クライアントアプリケーション、ウェブブラウザ、中間層アプリケーション、関係データベース管理システム(relational database management system:RDBMS)などを含み得るアプリケーションプログラム812、プログラムデータ814およびオペレーティングシステム816も示す。一例として、オペレーティングシステム816は、マイクロソフトウィンドウズ(登録商標)、Apple Macintosh(登録商標)および/もしくはLinux(登録商標)オペレーティングシステムのさまざまなバージョン、さまざまな市販のUNIX(登録商標)もしくはUNIXライクオペレーティングシステム(さまざまなGNU/Linuxオペレーティングシステム、Google Chrome(登録商標)OSなどを含むが、これらに限定されるものではない)、ならびに/または、iOS、Windows(登録商標)Phone、Android(登録商標)OS、BlackBerry(登録商標)10 OSおよびパーム(登録商標)OSオペレーティングシステムなどのモバイルオペレーティングシステムを含み得る。
また、記憶サブシステム818は、いくつかの実施例の機能を提供する基本的なプログラミングおよびデータ構造を格納するための有形のコンピュータ可読記憶媒体を提供し得る。プロセッサによって実行されたときに上記の機能を提供するソフトウェア(プログラム、コードモジュール、命令)が記憶サブシステム818に格納され得る。これらのソフトウェアモジュールまたは命令は、処理ユニット804によって実行され得る。また、記憶サブシステム818は、本発明に従って使用されるデータを格納するためのリポジトリを提供し得る。
また、記憶サブシステム810は、コンピュータ可読記憶媒体822にさらに接続可能なコンピュータ可読記憶媒体リーダ820を含み得る。コンピュータ可読記憶媒体822は、システムメモリ810と共に、または必要に応じてシステムメモリ810と組み合わせて、コンピュータ可読情報を一時的および/または永久に収容、格納、送信および検索するための記憶媒体に加えて、リモート記憶装置、ローカル記憶装置、固定的な記憶装置および/または取外し可能な記憶装置を包括的に表すことができる。
また、コードまたはコードの一部を含むコンピュータ可読記憶媒体822は、当該技術分野において公知のまたは使用される任意の適切な媒体を含み得て、当該媒体は、情報の格納および/または送信のための任意の方法または技術において実現される揮発性および不揮発性の、取外し可能および取外し不可能な媒体などであるが、これらに限定されるものではない記憶媒体および通信媒体を含む。これは、RAM、ROM、電子的消去書き込み可能なROM(electronically erasable programmable ROM:EEPROM)、フラッシュメモリもしくは他のメモリ技術、CD−ROM、デジタル多用途ディスク(digital versatile disk:DVD)、または他の光学式記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置もしくは他の磁気記憶装置、または他の有形のコンピュータ可読媒体などの非一時的な有形のコンピュータ可読記憶媒体を含み得る。また、これは、データ信号、データ送信などの無形のコンピュータ可読媒体、または、所望の情報を送信するために使用可能であり且つコンピュータシステム800によってアクセス可能なその他の媒体を含み得る。
一例として、コンピュータ可読記憶媒体822は、取外し不可能な不揮発性磁気媒体から読取るまたは当該媒体に書込むハードディスクドライブ、取外し可能な不揮発性磁気ディスクから読取るまたは当該ディスクに書込む磁気ディスクドライブ、ならびに、CD ROM、DVDおよびブルーレイ(登録商標)ディスクまたは他の光学式媒体などの取外し可能な不揮発性光学ディスクから読取るまたは当該ディスクに書込む光学式ディスクドライブを含み得る。コンピュータ可読記憶媒体822は、ジップ(登録商標)ドライブ、フラッシュメモリカード、ユニバーサルシリアルバス(universal serial bus:USB)フラッシュドライブ、セキュアデジタル(secure digital:SD)カード、DVDディスク、デジタルビデオテープなどを含み得るが、これらに限定されるものではない。また、コンピュータ可読記憶媒体822は、フラッシュメモリベースのSSD、企業向けフラッシュドライブ、ソリッドステートROMなどの不揮発性メモリに基づくソリッドステートドライブ(solid-state drive:SSD)、ソリッドステートRAM、ダイナミックRAM、スタティックRAMなどの揮発性メモリに基づくSSD、DRAMベースのSSD、磁気抵抗RAM(magnetoresistive RAM:MRAM)SSD、およびDRAMとフラッシュメモリベースのSSDとの組み合わせを使用するハイブリッドSSDを含み得る。ディスクドライブおよびそれらの関連のコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュールおよび他のデータの不揮発性記憶装置をコンピュータシステム800に提供し得る。
通信サブシステム824は、他のコンピュータシステムおよびネットワークとのインターフェイスを提供する。通信サブシステム824は、他のシステムからデータを受信したり、コンピュータシステム800から他のシステムにデータを送信するためのインターフェイスの役割を果たす。たとえば、通信サブシステム824は、コンピュータシステム800がインターネットを介して1つ以上の装置に接続することを可能にし得る。いくつかの実施例では、通信サブシステム824は、(たとえば3G、4GまたはEDGE(enhanced data rates for global evolution)などの携帯電話技術、高度データネットワーク技術を用いて)無線音声および/またはデータネットワークにアクセスするための無線周波数(radio frequency:RF)トランシーバ構成要素、WiFi(IEEE1602.11ファミリ標準または他のモバイル通信技術またはそれらの任意の組み合わせ)、全地球測位システム(global positioning system:GPS)レシーバ構成要素、および/または、他の構成要素を含み得る。いくつかの実施例では、通信サブシステム824は、無線インターフェイスに加えて、または無線インターフェイスの代わりに、有線ネットワーク接続(たとえばイーサネット)を提供し得る。
また、いくつかの実施例において、通信サブシステム824は、コンピュータシステム800を使用し得る1人以上のユーザを代表して、構造化されたおよび/または構造化されていないデータフィード826、イベントストリーム828、イベント更新830などの形態で入力通信を受信し得る。
一例として、通信サブシステム824は、ツイッター(登録商標)フィード、フェースブック(登録商標)更新、リッチ・サイト・サマリ(Rich Site Summary:RSS)フィードなどのウェブフィードなどのデータフィード826をリアルタイムでソーシャルネットワークおよび/または他の通信サービスのユーザから受信し、および/または、1つ以上の第三者情報源からリアルタイム更新を受信するように構成され得る。
また、通信サブシステム824は、連続的なデータストリームの形態でデータを受信するように構成され得て、当該データは、連続的である場合もあれば本質的に明確な端部を持たない状態で境界がない場合もあるリアルタイムイベントのイベントストリーム828および/またはイベント更新830を含み得る。連続的なデータを生成するアプリケーションの例としては、たとえばセンサデータアプリケーション、金融ティッカ、ネットワーク性能測定ツール(たとえばネットワークモニタリングおよびトラフィック管理アプリケーション)、クリックストリーム分析ツール、自動車交通モニタリングなどを含み得る。
また、通信サブシステム824は、構造化されたおよび/または構造化されていないデータフィード826、イベントストリーム828、イベント更新830などを、コンピュータシステム800に結合された1つ以上のストリーミングデータソースコンピュータと通信し得る1つ以上のデータベースに出力するように構成され得る。
コンピュータシステム800は、手持ち式携帯機器(たとえばiPhone(登録商標)携帯電話、Ipad(登録商標)計算タブレット、PDA)、ウェアラブル装置(たとえばGoogle Glass(登録商標)ヘッドマウントディスプレイ)、PC、ワークステーション、メインフレーム、キオスク、サーバラックまたはその他のデータ処理システムを含むさまざまな種類のうち、1つであってもよい。
コンピュータおよびネットワークが絶え間なく進化し続けるため、図示されているコンピュータシステム800の説明は、特定の例として意図されているにすぎない。図に示されているシステムよりも多くのまたは少ない数の構成要素を有する多くの他の構成が可能である。例えば、ハードウェア、ファームウェア、(アプレットを含む)ソフトウェア、または組み合わせにおいて、カスタマイズされたハードウェアも使用されてもよく、および/または、特定の要素が実装されてもよい。さらに、ネットワーク入力/出力装置などの他の計算装置への接続が利用されてもよい。本明細書で提供される開示および教示に基づいて、当業者は、さまざまな実施例を実現するための他の手段および/または方法を理解するであろう。
上記の説明において、例示の目的のために、特定の順序で方法を記載した。代替の実施形態において、記載された順序と異なる順序で方法を実行してもよい。また、上述した方法は、ハードウェア構成要素によって実行されてもよく、または一連の機械実行可能な命令で具体化されてもよい。機械実行可能な命令を用いて、汎用または専用プロセッサもしくは命令でプログラムされたロジック回路に指示して、方法を実行することができる。これらの機械実行可能な命令は、1つ以上の機械可読媒体またはメモリ素子、例えば、CD−ROMまたは他の種類の光ディスク、フロッピー(登録商標)ディスク、ROM、RAM、EPROM、EEPROM、磁気または光カード、フラッシュメモリ、または電子命令の記憶に適した他の種類の機械可読媒体またはメモリ素子を含む。代替的に、これらの方法は、ハードウェアおよびソフトウェアの組み合わせによって実行されてもよい。
本明細書において本発明の例示的且つ現在好適な実施形態を詳細に説明してきたが、理解すべきことは、本発明の概念は、様々な形で具体化され使用されてもよく、添付の特許請求の範囲は、先行技術によって制限されるものを除き、これらの変形例を含むことを意図していることである。
例示的な実施形態
図9を参照して、図9は、相乗的な一貫性且つ体系化である方法で、データ、知識およびプロセスを管理するための知識集約型データベースシステム(Knowledge-Intensive Database System:KIDS)モデルの例を示している。以下で説明するように、このモデルは、定量ファクトを捕捉し、ファクトを分類することによってコンパクトな定性情報を導出し、導出した情報を評価することによって1つ以上の仮説を確立し、およびこれらの仮説を使用することによって指令を策定する(または禁止指令を決定する)。得られた指令を実施することによって、新しいファクトを作成することができる。以下同様。
知識の観点から図9のKIDSモデルを見ると、CAREループ(分類(Classification)、評価(Assessment)、解決(Resolution)および実施(Enactment))は、4つの異なるカテゴリの知識からなる。これらの4つの異なるカテゴリの知識は、特定カテゴリのデータに作用し、特定カテゴリのデータを生成する。CAREループは、正規化ワークフローを表す。データの観点から同様のモデルを見ると、FPHDループ(ファクト(Fact)、認知結果(Perception)、仮説(Hypothesis)および指令(Directive))は、4つのタイプのデータを表す。データは、区別することなく、最新のデータベースシステムに保存されているものを記述する。形式知識は、知識を最も使用する時間および相互作用を区別することなく、記事、書籍、アプリケーションコード、ワークフロー、事件管理システムまたは判定支援システムに保存される。この欠点を補うために、CARE/FPHDループは、アプリケーションに非常に必要とされるデータ、知識、プロセス間の相互作用構造を形成する。
この実施形態において、KIDSは、KIDSモデル自体、KIDSツールおよびKIDSインフラストラクチャを含むことができる。このKIDSインフラストラクチャは、4つのカテゴリのデータ、4つのカテゴリの知識、および正規化処理構造に基づいた知識およびデータの起動を管理するように設計される。現実世界で見られるように、KIDSモデルは、データ、知識およびプロセスを相互に結び付けることができる。KIDSモデルは、知識およびプロセスが互いに且つデータから離れて別々の世界に存在する現在モデルと異なる。KIDSツールを使用することによって、ユーザは、KIDSモデルに基づいて、アプリケーションを開発することができる。これらのツールは、様々な構成要素で利用可能な既存のツールを活用し、KIDSモデルに準拠するためにサポート(制約)を追加する。KIDSインフラストラクチャは、ルール、記憶クエリ、モデル、データ変換手順および知識の使用を制御するワークフローの形で、アプリケーションの実行、データおよび知識を管理するための既存技術、特に最新のデータベースおよびアプリケーションサーバを活用する。
KIDSは、データの管理時に、進化する2つのビッグデータ技術およびCEP技術を結び付けることができる。(アドホック/バッチ環境では)ビッグデータ技術または(リアルタイム環境では)CEP技術を用いて、CAREループの分類を実装することができるが、KIDSは、これらのデータおよび知識表現を分類し、これらの技術を最新のアプリケーション構造に組み込むことによって、ビッグデータ技術およびCEP技術のうちのいずれよりも進歩している。すなわち、ビッグデータおよびCEPは、FSD(フレキシブルスキーマデータ)、多時間データベース、出所、ILM(Information Life Cycle Management:情報ライフサイクル管理)、登録クエリおよびOLAPデータキューブなどを含むKIDSの重要な技術の中で2つの重要な基本要素である。
様々な実施形態において、KIDSは、以下のもの、すなわち、
・データ、知識、プロセスをより良く管理するように、アプリケーションを構造化するためのモデル、
・各対が相互作用構造に特定の目的を果たす4対の相補的カテゴリを導入することによって、データ、知識および相互作用の正規化、
・ビッグデータおよびCEPの包括的な環境、
・全ての構成要素の宣言仕様、
・状態追跡、時間変遷、および出所機能、
・インフラストラクチャの改良、ユーザ規格の進化およびデータからの知識発見を介して、アプリケーションを継続的に進化させるためのモデルを提供する。
使用事例−クラウド運用
クラウド運用にとって、SLA(Service Level Agreement)の準拠が重要な要件であり得る。SLA違反を回避する操作を可能にするまたは違反が発生した場合に問題の解決案をより迅速に提供するように、SLAの準拠は、重要な性能基準の連続監視および切迫してくるSLA違反を検出する予測診断機能を必要とする。典型的なクラウド運用は、理者側および/または顧客側のプライベートクラウド、パブリッククラウドおよびハイブリッドクラウドに位置するデータセンタ、ネットワーク、サーバマシン、仮想マシン、オペレーティングシステム、データベース、ミドルウェアおよびアプリケーションなどの数百万個のハードウェア要素およびソフトウェア要素を監視、診断および管理する必要がある。従来のIT運用のの反応性異常検出および手動診断技術は、大変な労働集約的ものであり、広範囲分野の専門知識を必要とし、応答が非常に遅いため、異常を生じた構成要素を分離および特定するではなく、システム内の大量の部品の再起動を含む不適切な応答を引き起こし、クラウドに適切に拡張できないことがある。クラウド運用は、周期サイクル、負荷傾向、負荷急増、システム応答特性および一時的グリッチのダイナミクス、劣化および老化の早期警告、および環境内の数百万個の構成要素の性能変遷を得るために、図9に示すCARE/FPHDループのようなKIDSループの快速な反復によって成長できる分野である。このようなシステムは、コンピュータ化KIDSループを介して、重要な生命徴候の連続測定、時系列分析、多変量システム状態モデル、システム応答モデル、予知異常検出、機械学習に基づく分類、自動診断および予後、判定支援、および制御能力を必要とする。
クラウドコンピューティングの基本的な前提は、物理リソースの統合およびプール化による規模効果、および、動的リソース管理によって実質的に無制限のリソースを提供することである。制御システムは、動的リソース管理のほかに、動的実体モデルを管理することによって、新しいソフトウェアの頻繁なリリース、バグを修正するためのパッチ、ハードウェアのアップグレード、容量の拡張によって変化するシステムの正確な認識を提供する必要がある。
この部分では、システム正常性を示す重要な生命徴候を含む大量のマシンデータと共に、実体モデルの複雑性を説明する。ビッグデータ解析およびリアルタイムCEP技術は、この分野の問題を解決するために、大きな注目を集めている。各技術自体は、この分野の問題を解決するのに不十分であるが、殆どの場合、2つの技術は、切り離されている。2つの技術を統合し且つ大規模な状態管理を行うための他の必須技術を追加するためのフレームワーク、例えばKIDSが必要とされる。必須技術の例として、例えば、双時間データベース、式フィルタ、登録クエリ、およびRETE、BBN、MSET、SVM、神経ネットワーク、OWLおよび種々の時系列アルゴリズムなどの多くの推論エンジンを統合するための前方連鎖オーケストレーションエンジンおよび後方連鎖オーケストレーションエンジンが挙げられる。
図10を参照して、実体モデルが示される。この実体モデルは、顧客ポッドを含むOracle FusionアプリケーションSaaSに使用されるモデルである。このFusionアプリケーションは、仮想マシンに配置される。仮想マシンは、エクサロジック(Exalogic)ラックの物理計算ノードに配置され、データベースは、エクサデータ(Exadata)ラックの物理データベースノードに配置されている。この実体モデルは、スレッドセグメント、スレッドクラスおよびスレッドクラス間の依存関係による周期的なスレッドダンプ内の高強度スタックトレースの動的分類によって発見された実体で拡張される。依存関係は、スレッド間の通信およびプロセス間の通信を取得する。実体モデルにスタックトレース分類モデルを追加することは、システム生物学において、ヒトゲノム情報学を人体解剖モデルに追加することと非常に類似する。
スレッド強度は、システム機能の性能ホットスポットの「ホット性」(hotness)を測る統計的尺度を提供する。コードブロック(code block)のホット性は、コードブロックの呼び出し回数にコードブロックの実行時間を乗算することによって、定量化することができる。同様の尺度は、様々な性能解析ツール、例えば、Oracle Sun Studio 12 Performance Analyzer、Intel(登録商標)VTune Amplifier、AMD(登録商標)CodeAnalyst、Oracle Database Active Session History (ASH)、Oracle JRockit Flight Recorder、およびUNIX gprof commandに適用されている。
スレッドクラスは、セグメントクラスの有序集合である。例えば、CRMドメイン販売サーバADFアプリケーションスレッドは、1組のセグメントクラス(CRMドメイン、販売サーバ、ADFアプリケーション、およびADFウェブサービス呼び出し)によって表される。例示的なスレッド依存関係は、[(ADFウェブサービス呼び出し)→(ADFウェブサービス、ADF−BC)]である。[(ADFウェブサービス呼び出し)→(ADFウェブサービス、ADF−BC)]は、サブクラス[(CRMドメイン、販売サーバ、ADFアプリケーション、およびADFウェブサービス呼び出し)→(CRMドメイン、注文取得サーバ、ADFウェブサービス、ADF−BC、データベース運用)]を有する。クラス(ADFウェブサービス、ADF−BC)は、高強度クラス(CRMドメイン、注文取得サーバ、ADFウェブサービス、ADF−BC、データベース運用)にドリルダウンされてもよく、スレッド依存関係を介して、データベーススレッド(データベース、Fusionアプリケーションスキーマ)にドリルして、その後、データベース内のコールグラフ、コールツリーまたは(SQL実行プランと実行トレースを含む)コールスタックモデルを(データベース、Fusionアプリケーションスキーマ)スレッドの高強度サブクラスにドリルダウンされてもよい。
呼び出し連鎖に沿って伝達された実行環境ID(ECID)を用いて、ミドルウェアおよびデータベース層の間で例外トレースを相関させることによって、個々の実行環境における問題の根本原因の解析を支援することができる。生命徴候を用いて、一定の時間間隔で採取された一連のスレッドダンプサンプルからの様々なクラスのスレッドおよびスレッドセグメントの強度統計値の測定値に基づいて、システム問題を診断することができる。スレッドのクラス間の依存関係情報を用いて、ミドルウェアおよびデータベース階層の間の発生率を相関させることによって、根本原因の解析を支援することができる。スレッド強度の統計は、分類階層をドリルダウンする能力を向上させ、スレッド階層の特定のサブクラスの強度を観察することができる。スレッド強度の統計は、スレッド間の通信チャネルまたはリソースプールのキューのトラフィック強度の可観測性、およびSLA問題の主要指標である小さな性能グリッチの感度を向上させる。
データキューブは、ロールアップ(roll-up)、ドリルダウン(drill-down)、スライスおよびダイス(slice and dice)、ピボット(pivot)、ドリルアクロス(drill-across)、およびドリルスルー(drill-through)などのOLAP操作をサポートするように、実体モデル内の関係の「一部」を反映する寸法および概念束を用いて、定義される。予測診断ソリューションは、システム機能の生命徴候を構成する様々なシステム統計値の測定値を含むシステムの状態空間モデルを必要する。多変量状態推定技術(MSET:Multivariate State Estimation Technique)は、関連する実体の集合から、時系列データを情報融合するのに特に有効である。逐次確率比試験(SPRT:Sequential Probability Ratio Test)と組み合わせたMSETは、機械学習を予測異常検出に適用するロバストな分類モデルである。統計的尺度は、ビッグデータシステムのログから抽出され、データキューブに整理される。統計的尺度は、時系列フィルタによって導出された傾向情報および周期性情報を含む。Brown指数フィルタ、Holt二重指数フィルタ、Winters三重指数フィルタ、不規則な時間間隔に対応するWright拡張、短時間間隔のHanzak調整因子、および/または異常値の検出およびCauchy分布問題、特にJVM完全GC統計値の時系列解析におけるCauchy分布問題を克服するために異常値の切り捨ての適応性スケーリングを有する切取に基づいて、特定の時系列フィルタを実装することができる。レベル急増、レベル変遷、分散変化、異常値およびエンドポイント予測などの傾向を時系列データから抽出し、この定量傾向を低、正常または高などの定性値に変換することができる。
JVM完全GC統計値および定期的なスレッドダンプを含むファクトデータを変換することによって、より高次の分類情報を抽出することができる。スレッドセグメントおよびスレッドは、トラフィック強度に応じて、増加するように分類される。スタックトレースは、高強度のスレッドセグメントおよびスレッドと、スレッドクラス間の依存関係およびセグメントクラスへのスレッドクラスのドリルダウンを含むより高次情報とに分類される。定期的なスレッドダンプの時系列データは、各スレッドクラスおよびセグメントクラスの強度に関する傾向情報、例えば、周期サイクル、線形傾向、分散変化、レベル急増、レベル変遷、異常値、飽和またはエンドポイント予測などを含む。観測時間に亘ってイベントの数を実質的な傾向変化の数に比例するによって、傾向情報は、大量の時系列データをより簡潔な一連のイベントに減らす。システム状態は、傾向情報を表す特徴ベクトルによって特定することができる。システム状態の遷移は、実質的な傾向変化を表すイベントによって定めることができる。
したがって、KIDSモデルは、異なる分類知識によって推論された観察結果、目的、予測結果、シミュレーション結果および周期予測などの様々な特定タイプの情報の融合および関連する実体間の情報の融合を行うことができる。また、KIDSモデルは、効果的なKIDSループをサポートすることによって、異常を検出し、根本原因を診断しおよび大規模なクラウド運用時のリソースを動的に管理するために必要とされる複雑性および異質性で、情報融合および状況認識を行うことができる。
使用事例−ソフトウェアおよびハードウェア製品のサポート
この使用事例は、システムの利用不可を最小限に抑えるために、サポートおよび顧客を対応する技術者による協調的および反復的な問題解決行動によって特徴付けることができる。これらの目標を達成するには、既知の問題を解決するために既存の(暗黙または明示)知識を検索および適用するために必要とされる時間、または新しい問題の改善策を見付けるために必要とされる時間を最小限に抑えることが重要である。既知の問題を処理する自動化程度を増加または最大化することによって、サポートおよび顧客を対応する技術者は、解放され、大量の人間経験および知識を必要とする新しく発生する問題に集中することができる。したがって、この分野に開発されたアプリケーションは、絶え間なく自動化要求によって、常に変化し得る。自動化要求によって、3つの課題、すなわち、1)経済的な自動化の実現、2)自動化の迅速な展開を可能にするアプリケーションの設計、3)解決された問題の正確な表現および出所を取得する方法という最大の非技術的な課題が生じる。経済的な自動化を実現するために、正確な表現および出所で、(バグデータベース、サポートチケット内の)製品ライフサイクルの全体に発生した製品問題に関するデータおよび知識を確実に取得することが不可欠である。これらのデータおよび知識は、正確な定義、正確且つ有効な因果関係、システム構成および技術者の貢献と一致した用語を含む。このような表現および出所は、問題再発の可能性および自動的にまたは半自動的に問題を認識して解決する際の複雑度に関する正確な統計を可能にする。次に、収集された出所データに基づいて、問題を診断するためのプロセスを標準化することができる。このような標準化の目的は、データの標準化収集、データの標準化解析および解釈、標準化診断、標準化修復法、および問題解決プロセス全体の標準化を確立することである。
自動化の迅速な展開を可能にするロバストなアプリケーションアーキテクチャを達成するために、自動化問題空間を整合的なモジュール要素に分割することができる。このような分割を達成するためには、空間の自動化複雑性は、均一ではなくてもよい。データ収集の自動化は、データ解析の自動化ほど複雑ではない。また、データ解析の自動化は、診断自動化ほど複雑ではない。また、修復の自動化は、より複雑で異なる。このような自動化複雑性のレベル変化は、問題空間を分割するための自然な境界を提供し得る。
使用事例−患者介護
患者介護は、各々の量および複雑性が絶えずに増加する捕捉データ、観察結果、知識および手順によって決められる要求の厳しいタスクであり得る。医療センサが主流になると、データおよび知識の量がさらに速く増加すると予想される。センサを使用することによって、患者が医師のオフィスにいるか否かに関わらず、医師は、常に患者を診断することができる。測定値、画像(および読取値)、観察結果、診断および治療を記述するデータの組み合わせであるEMR(電子医療記録:Electronic Medical Records)の収集が非常に重要であるが、これらの記録だけではまだ不十分である。EMRは、データを意味のあるカテゴリに編成せず、誰がいつでどのデータを見たのか、どの理由でどの診断を下したのか、どのコンピュータ化知識およびどのバージョンを用いてどの結論を出したのかを記載していない。また、医療費が膨大になり、医師の過失もしくは患者または弁護士の利欲によって引き起された誤診訴訟が絶え間なく続いている。
医師は、多くの方法を用いて、患者を介護する。頻繁に使用される用語の一部は、症例に基づく医療、介護基準、分別診断および個別/精密医療を含む。無数のアプリケーションを使用して、医師をサポートできるが、これらのアプリケーションは、一部の仕事しか行えず、さらに、これらのアプリケーションは、専有的で不明瞭であるため、実質的に大きな拡張、個別化および高速進化を行うことが不可能である。網羅的ではないが、全ての治療段階で医師を支援し、医師が医師の言語でシステムと通信し、測定値をコンパクトな形に変換し、厳密な出所を提供し、異常を警告し、大きな拡張および個別化を可能にし、永続的に進化するシステムが必要とされる。
患者介護は、ファクトおよび観察結果の形で取得される証拠の収集から始まる。ファクトは、生命徴候、血液化学および画像などの測定結果を含む。測定ファクトは、定量的である。分類を用いて、ファクトは、測定結果が基準から偏差する度合および画像の解釈などの認知結果に変換される。ファクトは、認知結果として扱われる観察結果によって補完される。認知結果を評価することによって、観察される病気の根本原因および関連する信頼性を判定する1つ以上の診断(仮説)に得ることができる。次のステップでは、介護基準に基づいて、指令をもたらす治療計画、例えば、特定の治療および/またはより多くの検査を行うことができる。指令の実施によって、より多くのファクトを生み出す。この循環は、目標が既に達成したかもしくはそれ以上何もすることがないまたはそれ以上何もできないという仮説が出るまで継続する。これは、分別診断の一例である。これらのステップの殆どは、コンピュータによりサポートされまたは次第にコンピュータによりサポートされるため、一定のファクトストリームに基づいて患者を永続的に監視することができる。新しいコンピュータ化知識は、検証およびリリースされると、すぐに使用されなければならない。サポートは、個別化に行う必要がある。個人またはチームの嗜好に基づいて、知識を適用する必要がある。ソーシャルネットワーキングおよび暗黙知識プロファイリングは、タスクに最も適任である人またはチームの特定に支援することができる。
この使用事例は、ファクトを認知結果に変換する必要性を強調している。患者は、約10個の生命徴候を有する。これらの生命徴候は、患者の状況に依存して、様々な規模および範囲を有する。したがって、通知条件を指定することは、非常に困難である。医師は、多くのタイプのファクトに対して同一分類子を使用し、ファクトを分類することによって、通知条件を指定する。全ての生命徴候の可能な修飾子は、正常、監視、深刻および危篤である。実際の目的は、物事を直観的に表すために、少ない修飾子を使用することである。修飾子を使用して、少なくとも1つの危篤な生命徴候または2つの深刻な生命徴候を持つ全ての患者を教えてくださいというクエリを正規化および単純化することができる。医師は、時間と共に、進行値に悪化/改善などの注釈を追加する。変化速度を用いて、遅い悪化または速い悪化を議論することができる。明らかに、患者の生命徴候が安定しているか安定していないかなどの安定性値を議論することができる。認知結果は、直観的でコンパクトな言葉を使用するため、医師に好まれる。認知結果の曖昧さは、厳密な出所によって補償されなければならない。
単一値を分類する利点に加えて、一組の値または画像を分類するというより大きな必要がある。一例として、心停止のリスクは、数時間前の血液検査から判断することができる。残念なことに、この判断は、少なくとも10個の数値の間の複雑な相互関係を理解する必要がある。これは、最も優秀な専門家にとっても不可能なことであるが、コンピュータならうまく行える。したがって、リアルタイムで大量のモデルを評価する必要がある。これによって、医師は、経験したことがないまたは知ったこともない潜在的なリスクを認識することができる。同様に、医師は、分類を閲覧するために、厳密な出所が必要である。
認知結果は、患者の現在状況の重要な特徴を時間に記述する必要がある。その理由として、医師は、現在何が起こっているのか、この状況がどのように進化したか、これからどのように進化するのかを知りたいからである。また、過去の状況も容易に利用可能にしなければならない。分類と併せて予測を使用することによって、医師は、患者の状況が期待通り進化しない場合、通知してくださいという非常に包括的な要求を明確に述べることができる。この要求は、特定の状況において特定の意味を有する。
KIDSモデル−概念
KIDSは、データ、知識およびプロセス管理に集中するアプリケーションを構造化するモデルを提供する(例えば、図9を参照)。データの管理は、現在、急速に進化している比較的成熟した技術である。KIDSは、以下の4つの異なるデータカテゴリを定義して管理することによって、この進化に加えている。
・ファクト
ファクトは、世界で測定可能なデータである。人間の認知システムは、ファクトの数、速度および量的性質を直接に認知することが困難である。CEPおよびビッグデータなどの技術は、これらのデータを取得および処理する。
・認知結果
認知結果は、ファクト(および観察結果)のコンパクトで時間的且つ定性的な表現である。認知結果は、人間の認知システムによる使用のために最適化されている。認知結果は、ファクトから認識できる進化状況の最も重要な特徴を表している。認知結果は、情報を利用する利用者の視点に依存する。
・仮説
仮説は、ファクトおよび認知結果を説明する可能な根本原因を記述する。
・指令
指令は、特定のファクト、認知結果および仮説に応じて、取るべき措置を記述する。指令は、しばしばワークフローまたはプロセスの形で行動計画を指定する。明らかに、指令は、ファクトの進化に最も大きな影響を与えるだろう。
これらのカテゴリのデータのいずれかは、広範囲のデータタイプ/構造、拡張性、データタイプ/構造間の宣言型アクセス、時間の変遷、進化するデータ構造の柔軟性(構造化データをサポートすること、および、最初にデータをサポートし、その後構造をサポートするまたはサポートしないこと)、OLTPおよび解析などを必要とする。また、(ファイングレイン)セキュリティ、出所およびILMなどの拡張機能が必要になる場合もある。重要な運用特徴は、災害復旧、高可用性、信頼性、拡張性、性能、および迅速な開発ツールを含み得る。場合によって、データの管理は、成熟して広く使用されているデータベースで利用可能な幅広い機能サポートおよび運用サポートを必要とする。ファクトの収集および管理は、古典的な取引モデルを必要とせず、データの限られた損失を許容することができる。成熟したデータベースは、ファクトの管理を最適化し、リソース消費を大幅に削減ようにサポートを提供することができる。
特定の実施形態において、4つのデータカテゴリを補完するように、知識を4つのカテゴリに、すなわち、分類(Classification)、評価(Assessment)、解決(Resolution)および実施(Enactment)に分けることができる。この4つのカテゴリは、各データカテゴリを処理するために必要な推論モードに基づいている。適切な計算モデルによって、知識の各カテゴリの実質的なサブセットを自動化することができる。
・(データを認知結果に変換する)分類知識は、主に演繹推論モードで表される。予測またはノルムを生成する一部の分類知識は、帰納推論を含み得る。分類を行うための計算モデルは、サポートベクトルマシン、ナイーブベイズネットワーク、神経ネットワーク、クラスタリング、関連ルール、決定木、多変量状態推定技術、認知演算などを含む。
・(認識結果を仮説に変換する)評価知識は、典型的に、認知結果から仮説を導出する発想推論によって実現される。評価を行うための計算モデルは、ベイジアン信念ネットワーク、逆問題に対する解の最小二乗最適化または回帰を含む。
・(仮説を指令に変換する)解決知識は、異なる結果の優劣および関連するペイオフ/コストを考慮して、結果の不確実性の下で判断を行う。解決を行うための計算モデルは、決定ノードおよびペイオフ/コストノードを用いて拡張され、影響図、デンプスター・シェイファー理論、決定木および残存有効寿命の予後として知られたベイジアン信念ネットワークを含む。
・(指令を行動(および新しいファクト)に変換する)実施知識は、スクリプト、計画、予定、BPELワークフロー、およびBPMNビジネスプロセスにコード化された制御構造を含む。
知識は、CAREループによって指定された適切な順序で適用されてもよい。場合によって、CAREループの全てのステップを実行する必要がない。(各バージョンを含む)知識をデータベースに保存することによって、完全な出所を提供し、洗練されたクエリ利用を可能にすることができる。知識は、アドホック且つリアルタイムで適用可能である。1つの使用事例として、新しい知識を用いて、データ(特にファクトおよび認知結果)を再訪することによって、欠落したものおよび過大評価されたものを発見することができる。
ビッグデータ/CEPをKIDSの環境に使用することによって、より包括的且つ体系的な手法を作り出すことができる。
・クエリ/モデルは、個々の要素ではなく知識として取り扱われる。知識を照会することができ、進化することができる。
・データおよび知識(クエリ、ルールおよびモデル)は、特定の性質を有する4つのカテゴリで互いに関連する。
・ファクトを認知結果に変換することは、状況に応じて、行動によって補完される。
・出所サポートは、どのバージョンの知識を適用して、どのバージョンのデータを導出したかを明確に記述する。
さらに、各カテゴリの形式知識は、人間の暗黙知識によって補完されてもよい。アプリケーションは、システム内の行為者の暗黙知識および社会的な嗜好をプロファイルできるソーシャルネットワーキングサービスを必要とする場合がある。したがって、最近の行動に基づいて暗黙知識プロファイルを調整することによって、タスクに最も適任である人またはチームを特定することができる。これによって、プロファイルができるだけ最新であることを保証することができる。
いくつかの実施形態において、アプリケーションは、継続改善を含むことができる。アプリケーションの継続改善は、知識を継続的に改善することによって達成することができる。継続改善を可能にする技術は、1)ユーザおよび分野専門家の識見を活用して、ルール、クエリ、モデルおよびコードを改善する技術、および、2)追加のデータまたは新しいアルゴリズムを用いて、モデルを再評価および再実行する技術を含む。
分野の専門家は、知識を交換することができる。この交換は、できるだけ正式に行われる。論文は、使用されたモデルまたは形式論を直感的に理解するのに役立つベン図(Venn Diagram)と同等なものであると考えられる。通常、新しい知識を使用する前に慎重に見直す必要がある。KIDSは、進化する知識および既存の知識を同時に使用することができ、両方の結果を示すことができる。また、KIDSは、新しい知識で既存のデータを見直することができ、以前に過大評価されたリスクおよび機会だけでなく、新たなリスクおよび機会を示すことができる。
KIDSの形式モデル
KIDSは、人間行為者、人間行為者に代わって行動するコンピュータプログラムまたはハードウェア素子(エージェント)、および/または観察、診断および処置される実体の間の相互作用を推進するエンジンを含むことができる。KIDSの形式モデルは、システム内の行為者、エージェントおよび実体の間の相互作用を駆動するプロセス管理アプリケーションの実装を通知することによって、システム内の情報変更を能動的に管理することができる。
KIDSの形式モデルは、多時間データベースシステム内に表されてもよい。モデル内のデータは、トランザクション時間(Txn時間)を有すると考えられるが、トランザクション時間は、モデルに明示的に表されなくてもよい。このルールの1つの例外は、フラッシュバックのクエリおよび出所をサポートするように、トランザクション時間を明示的に表す行動環境である。
有効時間(Valid Time)は、正式な定義における基本的なデータ構造のうちの2つであるFSDデータおよび特徴データにおいて、明示的に示されてもよい。
FSD⊆実体×値×有効時間×FSDタイプ
特徴⊆実体×値×有効時間×特徴タイプ
ベクトル={特徴n|n=1、2、...、N}
ビッグベクトル={FSDn|n=1、2、...、N}∪ベクトル
FSD(フレキシブルスキーマデータ)は、テキスト、オーディオ、ビデオ、空間、グラフ、XML、RDFおよびJSONを含む、データベース内の任意の拡張性データであってもよい。したがって、FSDは、ファイルを表すことができる。関連するFSDのタイプに応じて、ファイルは、患者介護ドメインにおいて、心電図、X線、CTスキャン、MRIスキャンなどを含むことができ、クラウド運用ドメイン並びにソフトウェアおよびハードウェア製品サポートドメインにおいて、スレッドダンプ、ヒープダンプ、データベースAWRスナップショット、データベーストレースなどを含むことができる。特徴は、症状または疾患の観察値範囲内で、低、正常および高などのカテゴリ値を表すことができる。関連する特徴のタイプに応じて、症状または疾患は、患者介護ドメインにおいて、呼吸器感染、急性気管支炎、喘息などを表すことができ、クラウド運用ドメイン並びにソフトウェアおよびハードウェア製品サポートドメインにおいて、高血圧、低血圧、インピーダンス不整合、コンボイ効果などを表すことができる。
有効時間およびTxn時間は、時間間隔である。時間間隔[t1,t2)は、集合{t|t>=t1、t<t2、且つt1<t2、t、t1、t2∈日付時間}を表す。瞬時t1は、[t1,NA)で表すことができる。2つの有効時間[t1,t2)および[t2,t3)を1つの有効時間[t1,t3)に合併することができる。
・有効時間=[日付時間,日付時間∪{∞.NA})
・Txn時間=[日付時間,日付時間∪{∞.NA})
KIDSシステムは、7−タプル(行為者、エージェント、実体、CARE、メタデータ、環境、プロファイル)であってもよい。行為者とは、人間行為者の集合であり、エージェントとは、人間行為者の代わりに動作するコンピュータプログラムまたはハードウェア要素の集合である。実体は、観察、診断および処理される実体の集合である。
・CARE=(データ、知識)
・データ=(ファクト、認知結果、仮説、指令)
・知識=(分類、評価、解決、実施)
・データは、2つの基本的なデータ構造FSDおよび特徴で示される。
・ファクト⊆ガード×行動×実体×ビッグベクトル×有効時間
・認知結果⊆ガード×行動×実体×ベクトル×有効時間×FoM
・仮説⊆ガード×行動×実体×ベクトル×有効時間×FoM
・指令⊆ガード×行動×実体×ベクトル×有効時間×FoM
・状況=ファクト∪認知結果∪仮説∪指令
状況は、ファクト、認知結果、仮説および指令の概括であってもよい。状況インスタンスは、CAREループインスタンス内の特定の行動インスタンスに関連付けられ、行動インスタンスに関連付けられたKFun関数の入力または出力を表す。状況インスタンスは、実体に関連付けられてもよく、関連する実体の状態の一部であり得るFSDまたは特徴のベクトルを含む。すなわち、状況の実体は、有効なJPQL経路式によって、状況内の各FSDまたは特徴の実体に関連付けることができる。FoMは、信頼水準、信頼区間、確率、スコア、二乗平均平方根誤差、ペイオフ/コストなどを表す性能指数の定量値または定性値である。
・Kfunは、分類、評価、解決、実施および症状解決の概括である。
・メタデータ=(CAREループタイプ、行動タイプ、FSDタイプ、特徴タイプ、Kfun定義)。
・CAREループタイプ⊆名前
・行動タイプ⊆名前
・FSDタイプ⊆名前×実体タイプ×暗号化×言語
・特徴タイプ⊆名前×実体タイプ×許容値
・Kfun定義=(事前条件、事後条件)
・事前条件⊆フィルタ定義n×Kfun
・事後条件⊆Kfun×フィルタ定義n
・フィルタ定義⊆(FSDタイプ∪特徴タイプ)×フィルタ×受任者
事前条件メタデータおよび事後条件メタデータは、Kfun関数間の影響関係を捕捉することによって、(関連する実体セットの)FSDおよび特徴セットが同時に有効になり、Kfun関数を呼び出すために必要な状況を満たす時間を検出する。フィルタは、JPQL経路式(path expression)で定義された述語である。必須物は、Kfun関数を呼び出すために、入力または出力状況の一部でなければならない対応するFSDタイプまたは特徴タイプを指定するブール演算式(Boolean expression)である。
環境は、5−タプル(CAREループ、分類、評価、解決、実施)である。
・CAREループ=CAREループタイプ×実体×行為者×カウンタ×(分類×評価×解決×実施)n
CAREループインスタンスは、一連の行動の閉包(closure)であって、各行動インスタンスと共に、CARE定義によって定義されたフィルタを評価するための環境を表す。カウンタは、CAREループインスタンスの状態の一部である0〜n内のループカウンタである。
・分類⊆行動タイプ×ファクト×(分類)n×認知結果×行為者×Txn時間×有効時間
・評価⊆行動タイプ×認知結果×(評価)n×仮説×行為者×Txn時間×有効時間
・解決⊆行動タイプ×仮説×(解決)×指令×行為者×Txn時間×有効時間
・実施⊆行動タイプ×指令×(実施)n×ファクト×行為者×Txn時間×有効時間
分類、評価、解決、または実施インスタンスは、分類、評価、解決、または実施機能の各々の実行環境を表すことができる。
・行動=分類∪評価∪解決∪実施
・行動=行動タイプ×状況×(KFun)n×状況×行為者×Txn時間×有効時間
行動は、分類、評価、解決および実施の概括であってもよい。(それぞれが一対の入力/出力状況インスタンスを有する)多くの行動インスタンスを同一のKFun関数に関連付けることができる。ガードは、CAREループインスタンスまたは行動インスタンスの環境で評価される、JPQL経路式および必須のブール演算式で指定されたフィルタのセットから構成されたクエリである。
・プロファイルは、(行為者プロファイル、知識プロファイル、行動代理者、個人化)のトリプルである。
・行為者プロファイル⊆行為者→実体×特徴×有効時間×FoM
・知識プロファイル⊆Kfun→実体×特徴×有効時間×FoM
・行動代理者⊆{f|f:行動→行為者}×有効時間
・個別化:Kfun×行為者→Kfun
・個別化は、カレー演算子の観点から解釈できる。
・個別化(Kfun、行為者)≡カレー(Kfun)(行為者プロファイル(行為者))
KIDS実行モデル
この部分では、KIDS実行モデルの1つ以上の実施形態を説明する。CAREループインスタンスは、一連の行動(分類、評価、解決および実施)の閉包(closure)であってもよい。CAREループインスタンスは、過去に起きた行動、現在の行動または現在進行中の行動および将来起き得る行動からなる歴史的および意図的な環境を提供することができる。KIDSは、各CAREループインスタンスのループカウンタを維持することができる。行動インスタンスは、現在のループカウンタの下で実行される場合、現在の行動インスタンスと見なされてもよい。現在の行動インスタンスは、行動インスタンスの入力状況が実質的に変更されたときに実行されると想定される。ループカウンタは、現在のループカウンタの下で全ての現在の解決行動インスタンスが実行されたときに、増加する。
CAREループインスタンスは、インスタンスタイプおよびインスタンス所有者を有することができる。インスタンスタイプは、類似するCAREループインスタンスをグループ化する。インスタンスタイプを用いて、CAREループインスタンス内で実行される行動インスタンスをカスタマイズまたは制約することができる。CAREループタイプを初めて指定するときに、行為者(そのタイプの最初のインスタンスをインスタンス化した行為者またはこの行為者が指定した別の行為者)は、所有者としてそのタイプに関連付けられる。CAREループインスタンスの各行動インスタンスには、行動インスタンスの実行に適格な代理行為者がいる。行動インスタンスには代理人が存在しない場合、CAREループインスタンスの所有者は、行動インスタンスの代理人になる。また、CAREループインスタンスの明示的に指定された所有者がいない場合、タイプ所有者は、デフォルトでインスタンス所有者になる。インスタンス所有者または行動インスタンスの代理人は、指定された関数によって行動代理者から計算することができる。このような関数は、CAREループインスタンスの環境またはCAREループインスタンス内の行動インスタンスで評価された経路式によって定義される。
CAREループインスタンスタイプの所有者は、ある種の全てのインスタンスの挙動を制約することができる。CAREループインスタンスの所有者は、タイプ所有者によって指定された制約内で、インスタンスの挙動をさらにカスタマイズすることもできる。CAREループインスタンスの所有者は、初期の行動インスタンスおよび任意の後続の行動インスタンスを作成することによって、実行中にCAREループインスタンスの新しい行動インスタンスを定義することができる。また、CAREループインスタンスまたはタイプ所有者は、行動インスタンスの状況インスタンスのFSDまたは特徴を作成する前に、新しいFSDタイプまたは特徴タイプを作成することによって、CARE定義メタデータを作成することもできる。行動インスタンスは、CARE定義メタデータによって定義され、エンコードされた知識関数(SVM、MSET、BBNなどのマシン)によって実装することができる。CARE定義のいくつかの例は、図11A〜11Eに示されている。
インデックス(例えば、CAREループ[i].分類、CAREループ[i].評価、CAREループ[i].解決およびCAREループ[i].実施のインデックスi(i=0...n))を用いて、CAREループインスタンスから、行動インスタンスを一意的に特定することができる。CAREループインスタンスの状態は、CAREループインスタンス内の行動インスタンスに関連付けられた状況インスタンス内のFSDおよび特徴の集成、すなわち、経路式によって利用可能なFSDおよび特徴の集成、例えば、CAREループ[2].分類.認知結果.特徴[平均メモリ使用量].実体を含む。多くの行動インスタンスをKfun関数およびKfun関数のCARE定義メタデータに関連付けることができる。KIDSは、現在のループカウンタの下で実行される現在の行動インスタンスを選択することができる。現在の行動インスタンスの実行は、各行動インスタンスに指定されたガードを用いて制御される。ガードは、経路式および必須ブール演算式で指定された一連のフィルタ述語を含む。経路式、例えば、CAREループ[1].解決.指示.特徴[より多くのメモリの割当].値または認知結果.特徴[メモリ使用量の急増].値は、CAREループインスタンスまたはCAREループインスタンス内の行動インスタンスの環境で評価される。行動インスタンスが最新になると、KIDSは、対応するガードを用いて、SQLクエリ文を作成する。このようなクエリの結果は、状況(ファクト、認知結果、仮説または指令)インスタンスである。オブジェクトの変更を検出するたびに、クエリを登録するこができる。FSDまたは特徴を更新または挿入する場合、KIDSは、対応する行動インスタンスのTxn時間によって記録された最後のトランザクション時間で、登録した各クエリ文のフラッシュバッククエリを実行する。また、KIDSは、現在のトランザクション時間でクエリを実行する。状況インスタンスが2つのトランザクション間で実質的に変化する場合、KIDSは、更新された状況を用いて、行動インスタンスを起動することができる。これは、行動インスタンスに関連付けられたKfun関数の呼び出しである。Kfun関数の呼び出しおよび入出力状況インスタンスを実行した後、KIDSは、新しいトランザクション時間(Txn時間)を行動インスタンスに保存する。全ての必須FSDおよび特徴が入力状況の一部になるまで、KIDSは、Kfun関数の呼び出しを延期する。したがって、KIDSは、CAREループ行動インスタンスの実行を調整し、CAREループのカウンタを増やす。
状況定義は、状況内のFSDまたは特徴のFSDタイプおよび特徴タイプを指定するフィルタ定義のリストを含むことができる。また、各フィルタ定義は、YAK−Dom0.12−OVM.222=特徴.実体.オラクルVMおよび特徴.名前=ESSプロセス急増などのフィルタ述語も指定する。フィルタ定義によって指定されたフィルタ述語を用いて、Oracleデータベース式フィルタ表に式を登録することによって、現在のトランザクション内の新規FSDまたは特徴もしくは更新FSDまたは特徴によって影響され得る登録済のクエリ文を選択することができる。KIDSは、影響されたクエリ文のみに対してフラッシュバッククエリを実行することによって、状況インスタンスの変更を検出する。フィルタに経路式を使用することによって、関連する実体セットのFSDおよび特徴を状況インスタンスに集約することができる。経路式は、指定された実体モデルに対して有効にしなければならない。
KIDSは、現在のループカウンタで2つ以上の現在行動の入力状況インスタンスに対する変化を検出した場合、分類<評価<解決<実施という優先順位に従って、1つの行動を選択し、実行することができる。1つ以上の現在解決行動インスタンスの実行がループカウンタに達し、一連の新しい行動インスタンスがアクティブになるまで、現在行動の入力状況インスタンスが変化すると、現在行動を反復的に実行することができる。また、新しいバージョンのKfun関数を用いて、状況インスタンスを再評価し、行動インスタンスを再実行するために、ループカウンタを低い数値にリセットすることもできる。
したがって、大規模な状態管理、リッチデータモデルおよびデータタイプ、式フィルタ、フラッシュバッククエリおよび登録クエリの成熟したデータベース技術を用いて、KIDSエンジンを実装することができる。
KIDS−クラウド運用の体験
KIDSエンジンは、上述したBBN、RETE、MSET、SVN等の様々な推論エンジンの相互作用を編成することができる。KIDSデータベースは、図12に示すように、ファクトデータ内のFPHDおよびCAREデータを注釈することによって、出所データのKIDSループを実現することができる。KIDSモデルは、IT運用時に、ログ解析システムおよびリアルタイム企業管理システム用のビッグデータシステムを統合することができる。この2つのシステムは、自動化島によって切断され、包囲されているビッグデータおよびCEPを表す。KIDSモデルは、動的実体モデル、ログ解析およびリアルタイム監視からの情報融合を行うことによって、リアルタイムでより高速なOODAループを可能にすることができる。
KIDSモデルは、異なる分類知識によって推論された様々な特殊種類の認知結果、例えば、観察結果、目的、予測結果およびシミュレーション結果などの情報融合を可能にし、関連する実体間の情報融合を可能にする。図13に示す情報融合の例示的なシナリオにおいて、情報を収束する関連実体のセットは、Oracle VM、JAVA(登録商標) VM、Dom0ホスト、Dom0ホストに位置する他のOracle VMおよびJava VMを含む。動的実体モデルは、時間データベースによって管理される。
図11A〜11Cに示す例示的なシナリオにおいて、「メモリ使用量の急増」および「企業スケジューラサービスプロセスの急増」特徴は、OSメモリおよびOSプロセスの測定における異常な傾向の分類の一部であり得る。図11Aおよび11Cにおける「メモリ不足予測」特徴は、時系列フィルタによって生成された認知結果の一部である。「他のOracle VM内のJVMのヒープを圧縮できる」および「他のOracle VMからメモリを再利用できる」などの追加機能は、Dom0内の全てのOracle VMに位置する全てのJava VMの平均負荷および周期性動向データを含むデータキューブに対するロールアップ操作によって予測された認知結果の一部である。KIDS実体モデルは、「Dom0に動作しているOracle VMの目録」、「各Oracle VMに動作しているJava VMの目録」、並びに「他のOracle VM内のJVMのヒープを圧縮できる」および「他のOracle VMからメモリを再利用できる」に関する認知結果に基づいて、状況認識を行うことができる。これらの認知結果の全ては、状況インスタンス内の共通有効時間間隔で一致する必要がある。
KIDSモデルは、様々な推論エンジンに実装された知識関数の相互作用構造を取得することができる。図14に示すCAREループは、事実上、一連のネットワークであり、相互作用は、(行動インスタンスおよびガードインスタンスは、遷移を表し、状況インスタンスは、場所を表し、FSDおよび特徴は、トークンを表す)ペトリネット(Petri-Net)に類似する。評価関数の行動インスタンスは、図15に示すベイジアン信念ネットワークによって実現される。相互作用モデルを使用することによって、KIDSは、様々な推論エンジンに関与するモデルの実行を調整することができる。
図15のBBNによって示された評価知識「Oracle VMメモリの診断」は、与えられた認知結果を診断し、「Dom0は、OVMに割り当てるメモリを有する」および「Oracle VMにより多くのメモリを割り当てる必要がある」という仮説を導出することができる。同様のネットワークは、Dom0の指令に到達する仮説を「Dom0からのメモリをOVM2に割り当てる」に組み合わせる解決知識「Oracle VMメモリの解決」を含む。評価知識は、ESSジョブを処理した後、「OVMからメモリを再利用する必要がある」という仮説に到達することができる。影響図によって示された解決知識は、「Oracle VMからメモリを再利用する」というDom0の指令に到達する。「Dom0からのメモリをOracle VMに割り当てる」という指令は、同一のDom0に位置する他のOracle VMに動作しているJava VMの完全なガベージコレクション(GC)およびヒープ圧縮をトリガする実施関数によって実施される。Java VMのヒープ圧縮を行った後、実施関数は、Dom0に指示して、バルーン内のメモリを再利用するように、他のOracle VMのメモリバルーン(起動メカニズムの一部)を拡張することができる。これによって、Dom0は、ESSによって生成されたプロセスをサポートするように、弾性メモリをOracle VMに割り当てることができる。ESSプロセスが周期性を示すスケジュール行動であるため、実施機能によるKIDSの反応的且つ予測的な対応は、周期性行動の一部となる。
KIDSの体験−ソフトウェアおよびハードウェア製品
以下は、KIDS設計の知識抽出および自動化体験の要約を説明する。この要約は、モジュラー製品サポートのトラブル対応行動をCAREループにマッピングし、関与する人員の個人生産性と知識および出所の正確な結合とのバランスをとる方法を示している。知識および出所の正確な結合は、経済用語およびプロセスの標準化をもたらし、最終的には知識の自動化および迅速なアプリケーションの進化につながる。この方法は、協力的且つ生産性の高い実践共同体の育成に大きく貢献することができる。
以下のシナリオにおいて、自動インシデントまたは顧客による手動行為のいずれかは、ループインデックスi=0で始まる新しいCAREループインスタンスをインスタンス化する。この処理は、4つの段階、すなわち、問題の特定、問題の検証、原因の特定および解決策の提供から構成される。
・問題特定段階(II−i)
指令(II−i)は、顧客の担当者からの問題に関するデータを引き出すまたはテレメトリデータを収集し、問題またはメトリック値の収集に対する回答として、ファクト(II−i)を生成する行動計画である。
ファクト(II−i)を分類することによって、観察結果として知られる認知結果(II)を得る。
認知結果(II−i)を評価することによって、潜在的な問題として知られる仮説(II−i)を得る。
仮説(II−i)を解決することによって、初期データ収集の行動計画として知られる指令(IV−i+1)を得る。
・問題検証ループ(IV−i)
指令(IV−i)を実施することによって、一連のログファイルおよびトレースファイルであるファクト(IV−i)を生成する。
ファクト(IV−i)を解析(分類)することによって、一連の観察結果である認知結果(IV−i)を得る。
認知結果(IV−i)を評価することによって、検証されたまたは検証されていない問題である仮説(IV−i)を得る。
問題が検証された場合、原因決定に進み、指令(CD−i+1)を作成することによって原因(故障状態)を決定する。そうでない場合、指令(II−i+1)を作成することによって問題特定に戻る。
・原因決定ループ(CD−i)
指令(CD−i)を実施することによって、追加のログファイル、トレースファイルおよび構成データの形で、ファクト(CD−i)を生成する。
ファクト(CD−i)を解析することによって、追加の観察結果である認知結果(CD−1)を得る。
認知結果(CD−i)を評価することによって、故障状態として知られる仮説(CD−i)を生成する。
高い信頼度をもって仮説(CD−i)を発見した場合、指令(SP−i+1)(解決行動計画)を作成する。そうでない場合、更なるデータを収集するための指令(CD−i+1)を生成することによって、潜在的な原因をさらに究明する。
・解決案計画ループ(SP−i)
指令(SP−i)は、仮説の原因によって引き起こされた問題を修正し、解決策を検証するために追加データを収集する一連の行動である。これらの行動は、実施されると、ファクト(SP−i)を生成する。
ファクト(SP−i)を解析することによって、解決策の観察結果である認知結果(SP−i)を得る。
認知結果(SP−i)を評価することによって、解決策が問題を解決できるか否かを検証する仮説(SP−i)を生成する。
仮説(SP−i)が解決策を検証した場合、CAREループを終止させる指令(NO-OP-END)を提供する。そうでない場合、指示(CD−i+1)を作成することによって原因決定に戻り、または指示(SP−i+1)を作成することによって新たな解決案を試みる。
上述した特定のCAREループ内のいずれかの行動は、プロセスの成熟度およびループを所有する支援チームの明示的知識ならびにドメインの複雑性に応じて、手動、部分自動化または完全自動化で実行されてもよい。KIDS解析サービスを利用して、部分自動化または完全自動化の準備が整った手動行動を適格にする。そのような行動は、十分な成熟度に達し、自動化するための経済的に妥当なROIを有しなければならない。データ収集の自動化は、製品に組み込まれた診断可能なフレームワークを介して達成され、重大な問題の最初の失敗データの取得およびより深い識見を得るためのオンデマンド計測を実現した。迅速な展開を実現するために、自動化要素は、宣言的な方法で指定され、検出は、完全に自動化され、自動化の迅速なターンアラウンドを保証する。KIDSプラグインフレームワークを利用して、ドメイン特有サービスおよび知識、例えば、ドメイン特有オントロジーリポジトリ、解析モジュールの自動検出フレームワークをサポートするXMLに基づく診断データ解析フレームワークを含むことができる。データ解析の自動化は、収集したデータをXML正準表現に変換し、XPATHルール内のデータ解析ルールを指定することによって達成される。XPATHにおいて簡単に指定できない複雑なパターンについて、Javaで再利用可能なデータ解析パターンのライブラリを開発することができる。診断を自動化するために、手動モデリングは、自動化のために実行可能な唯一の方法ある。また、KIDSプラグインフレームワークを利用して、ベイジアン信念ネットワークに基づくモデリング、自動検出および自動化フレームワークを含むことができる。実際に、KIDS CAREループを利用して、これらのモデルの構築および検査を行うこともできる。ベイジアン信念ネットワーク(BBN)を用いて、診断をモデル化することができる。BBNは、機械学習を妨げる問題空間の散生性質によって、理想的なパラダイムを提供した。BBNを構築することによって、診断結果の説明および不完全且つ異常な入力データの処理に役立つ。
また、手動行動の個人生産性をサポートするために、ガイド付きタグ付け、ハッシュタグ拡張およびインライン行動計画仕様の形のKIDSを個人生産性サービスに使用することができる。詳しくは、用語の標準化を可能にするために、ガイド付きタグ付けを利用することができる。パーソナル用語を定義するために、ハッシュタグ拡張を利用することができる。KIDSを用いて、行動計画の取得および共有を行うために、インライン行動計画仕様を検討することができ、データ解析ルールセットの取得および共有を行うために、セルフサービス式個人データ解析の自動化を検討することができる。これらの様々な例は、一方では個人的な権限委譲を提供することができ、他方ではコミュニティの共有および合作を可能にする。例えば、タグ付けは、個人知識の組織化および検索を可能にする。ガイド付きタグ付けは、標準化タグセットに対するコミュニティの集中を可能にする。また、ハッシュタグ拡張ユーザ体験サービスは、テキスト文例集または用語定義を一度指定した後、個人レベルで複数回に再利用することを支援し、コミュニティがこれらの定義を共有できるようにすることを目的としている。最後に、インライン行動計画によって、個人レベルで再利用可能な行動計画を作成することができ、行動計画の行為者がチェックリストとして行動計画を活用することができる。行動計画は、コミュニティレベルで共有および交換することができる。全てのこのようなユーザ体験サービスは、個人的な権限委譲をサポートすると共に、行動コミュニティが最良行動および共通用語に集中することを支援する。
KIDSの体験−患者介護
患者介護KIDSプロジェクトの目的は、分類および出所にある。出所をサポートするために、全ての患者記録は、トランザクション時間データベースに管理される。登録クエリおよびモデルを用いて、分類を管理する。誤報を減らすために、医師は、分類を個体患者のレベルまで調整することができる。生命徴候について、正常、監視、深刻および危篤の分類を使用した。これらの分類を使用するように、登録クエリを表現することができる。その結果、医師は、自分の言語で、例えば、患者Xの少なくとも1つの生命徴候が2分以上に危篤になった場合、私に通知するという規則を定義することができる。このような規則は、分類の詳細とは独立しているため、少量でも十分であり、安定である。
さらに、非仮説駆動モデルを用いて、数時間後に心臓が停止する可能性を予測することができる。驚くべき結果は、生命徴候、特に最新のデータが利用可能な生命徴候は、「長期」予測には重要ではないことである。KIDS技術は、そのようなイベントまたは良好ではないエンドユーザの抽象化を示すことができる。インシデントオブジェクトという用語を使用できる。アイデアは、状況(状態)モデルに進化することができる。いくつかの実施形態は、単に、ファクト、分類および認知結果の管理に関与する。プロジェクトが完了した後、CAREループの他の要素を追加することができる。
KIDSデータベースの仕様
いくつかの実施形態において、KIDSモデルを実装するために使用されたデータベースは、特定の要件または仕様を満たす必要がある。場合によって、KIDSデータベースは、ユーザがCAREループインスタンスを照会できるように宣言型照会言語を提供することができる。SQLを使用して、宣言型言語モデルを提供することができる。しかしながら、SQLは、アトミックデータ(atomic data)しか照会できない。KIDSを照会するために、CAREループインスタンスのセットを照会するようにSQLを拡張する必要がある。SQLは、一次キー/外部キーを用いてデータ間のリンクを照会できるが、再帰グラフ走査(recursive graph traversal)に関与するCAREループインスタンスおよび行動インスタンスの照会に制限される。SQLにおけるグラフ走査の宣言構成の最も近いサポートは、再帰クエリである。しかしながら、再帰クエリは、元の再帰構造から得られた結果ではなく、表形式で最終結果を提供する。したがって、KIDS照会言語によって、ユーザは、CAREループパスを照会および走査して、行動インスタンスが状況インスタンスにどのように依存しているかおよびKfun知識関数がどのように適用されているかを確認することができる。
また、KIDSデータベースは、KIDS要素を操作するための宣言型操作言語を提供することができる。CAREループは、何が起こったのかを追跡することができる。しかしながら、ユーザは、ある種類の方法で、知識、例えば「what ifクエリ」を変更した場合、DMLを用いて、何が起こったのかまたは何が起きるかを断言することができる。したがって、ユーザは、新しい知識を用いて履歴データを評価することによって、履歴データから新しい識見を得ることができる。このことは、過去への時間トラバーサルと同様である。さらに、ユーザは、異なるバージョンの知識を用いて、複数のCAREループをフォークすることによって、将来のデータを断言することができる。このことは、過去への時間トラバーサルと同様である。
KIDSツールの仕様
KIDSのツールセットは、KIDSアプリケーションを構築する際にユーザを支援できると共に、基礎となるインフラストラクチャの様々な制御、すなわち、ユーザフィードバックに基づく知識の進化および新しいデータによる知識の再度特徴付けを指定することもできる。
KIDSアプリケーションサーバ
KIDSアプリケーションサーバは、データベースに格納されたKIDSデータ、知識およびプロセスモデルを用いて、KIDSアプリケーションの実行をサポートすることができる。KIDSアプリケーションサーバは、明白な出所を表す情報を伝達し、状態管理およびイベント処理をデータベースに委譲することができる。
KIDSの最適化
KIDSデータベースは、トランザクションのACID特性をサポートするように設計されてもよい。ファクトの収集は、完全の耐久性または低下した耐久性を必要とするため、データモデルおよびタイプと共に、セキュリティ、圧縮、圧縮、タイムトラベルおよび出所などを全てサポートするデータベースサービスが必要である。耐久性は、ユーザの要求、例えば、データの全て>x%または出所の質問を回答できる十分高い精度によって制御されなければならない。また、このサービスは、高性能分類をサポートしなければならない。ACID要件を緩和することによって、リソース消費を大幅に削減することができる。この目的のために、特別なデータベースを検討することができるが、全ての要件に対応できる機能を有する必要がある。したがって、一部の手法は、進化するパターンに応じて、既存のデータベースを最適化し、ハードウェアアクセラレーションを活用することを含む。
分散処理のためのKIDSサポート
いくつかの実施形態において、KIDSは、基礎となるインフラストラクチャを活用するように、分散環境で動作することができる。
ソーシャルネットワーキングおよび個別化の統合
いくつかの実施形態において、ソーシャルネットワーキングは、KIDSの不可欠な部分である。個別化は、特定分野に関わり、グループまたは個人の好みに基づいて知識を個別化することができる。例えば、患者介護の使用事例は、個別化の重要性を示している。
KIDSの移行
移行サポートに関して、既存の機能を維持するために、既存のアプリケーションを続けて動作させることができるが、KIDSモデルに基づいて、「シャドー」アプリケーションを作成することもできる。場合によって、「シャドー」アプリケーションは、クローリングすることによって、既存のシステムのデータを監視する。しかしながら、既存の技術の一部と共に、新しい機能をKIDSに実装することもできる。