説明
本明細書に記載のシステムは、計算グラフ又はデータ処理グラフとも呼ばれるデータフローグラフのコンポーネント上の専用監査ポートを提供する。概して、データフローグラフはグラフ形式のコンピュータプログラムであり、計算を表し、計算の第1のプロセスを表す第1の頂点と、計算の第2のプロセスを表す第2の頂点と、第1の頂点を第2の頂点に接続し、第1のプロセスと第2のプロセスとの間のデータフローを表すリンクとを有し、第1の頂点及び第2の頂点は自らに関連する状態をそれぞれ有し、リンクは自らに関連する通信方法を有し、第1の頂点とリンクとの間の接続はその接続に関連する第1のアクセス方法を有し、第2の頂点とリンクとの間の接続はその接続に関連する第2のアクセス方法を有する。グラフの頂点はコンポーネントと呼ぶこともできる。コンポーネントは概して、データに適用される実行可能ロジックの一部を含む又は参照することによって実行可能であり、データを受信し、(実行可能ロジックの一部をデータに適用することによって)処理し、出力するための入力ポート及び出力ポート並びにログポート及びエラーポート、及び監査ポートを有する。コンポーネントがエラーに遭遇した場合、回復性がないのでログポート及びエラーポート上のデータが失われる。対照的に、監査ポート上のデータは重要であり、行われたトランザクションを表す。完了したトランザクションの数又は顧客が受諾したオファーの数等、有意味のメトリックが監査データから導出される。そのため監査ポートは、監査データ自体の回復性を与えるための回復性を実装する。監査ポートは直交データフローを提供するので、別個の監査ポートを有することにより、監査ポートは出力ポートの性能に影響を及ぼすことなしに監査データを回復可能な方法で出力することができる。
図1を参照し、ロギングのためのシステム10は、そのそれぞれがデータを様々な記憶形式の何れか(例えばデータベーステーブル、スプレッドシートファイル、フラットテキストファイル、又はメインフレームによって使用されるネイティブ形式)で記憶することができる記憶装置又はオンラインデータストリームへの接続等、1つ又は複数のデータソースを含み得るデータソース12を含む。実行環境14(例えばデータ処理システム)は、実行モジュール16及び性能モニタリングモジュール18を含む。実行環境14は、UNIX(登録商標)オペレーティングシステム等の適切なオペレーティングシステムの制御下で1つ又は複数のコンピュータ上にホストされ得る。例えば実行環境14は、ローカルの(例えばSMPコンピュータ等のマルチプロセッサシステム)、又はローカルに分散された(例えばクラスタ又はMPPとして結合される複数のプロセッサ)、又は遠隔的、又は遠隔的に分散された(例えばLAN又はWANネットワークによって結合される複数のプロセッサ)、又はそれらのものの任意の組み合わせである複数の処理ユニット(例えば中央処理装置、CPU)を使用するコンピュータシステムの構成を含むマルチノードの並列計算環境を含み得る。
実行モジュール16は、データレコード又はデータ項目を処理する際に実行される実行可能ロジックの1つ又は複数の部分に関する詳細、及び/又はコンピュータプログラム(例えば参照によりそのそれぞれの全内容を本明細書に援用する「Executing Computations Expressed as Graphs」と題された米国特許第5,966,072号明細書に記載の又は米国特許出願公開第2016/0342396号明細書に記載のデータフローグラフ等のチャート)を通るデータの状態及びデータがたどる経路に関する詳細を与えるロギング(例えばチャートロギング、データフローグラフロギング等)を実装する。本願では、「実行可能ロジックの一部」という用語は実行可能ロジックのサブセット、例えば実行可能ロジックの100%未満を意味し得る。一部の例では、例えば1つ又は複数のフィールドを有するデータレコードであって、各フィールドが実行可能ロジックの特定の部分を用いて特定のデータ項目を処理することの特性又は属性を表す値を記憶する、データレコードを含む監査レコードを生成することによって実行モジュール16がこのロギングを実装する。以下でより詳細に説明するように、下記では監査レコードをログレコード又は監査データと呼ぶ場合もある。一部の例では、そのデータレコード(本明細書では「データ項目」とも呼ぶ)がコンピュータプログラムによって処理される固有のキー(例えば識別子(ID))ごとに実行モジュール16がロギングを実装する。一部の例では、参照によりその全内容を本明細書に援用する米国特許出願公開第2009/0327196号明細書に記載されているようなグラフベースの計算として表されるコンピュータプログラムのためのデータロギングを実行モジュール16が実装する。本願では、「データフローグラフ」又は「チャート」という用語は「コンピュータプログラム」の例として又は他の言葉として使用する。一部の例では便宜上「データフローグラフ」又は「チャート」という用語を本明細書の中で交換可能に及び区別なく使用する。一部の例では、固有のキーはレコードがチャートによって処理される各顧客の顧客IDを表す。メトリック(例えばチャートのどの部分が横断されたのかを示すメトリック及びチャートの一定の部分がレコード群によって横断された回数を示す集約メトリック)等のロギング情報をユーザインタフェースが表示する。本明細書の全体を通して記載するメトリックは動的に、例えば実行可能ロジックの実行中に決定することができる。換言すれば、これらのメトリックは静的ではなく動的に変化することができ、リアルタイムで継続的に更新することができる。本明細書の全体を通して記載するメトリックは、データ項目を処理する際に実行される実行可能ロジックの1つ又は複数の部分の計算性能属性に関する情報を提供し得る。この例では、チャート(例えばデータフローグラフ)がデータ記憶域26(本明細書ではメモリ26とも呼ぶ)内に記憶され得る。データソース12を提供する記憶装置は実行環境14にとってローカルとする、例えば実行環境14を実行するコンピュータに接続される記憶媒体(例えばハードドライブ17)上に記憶することができ、又は実行環境14にとって遠隔的とする、例えば実行環境14を実行するコンピュータとローカルデータネットワーク又は広域データネットワーク上で通信する遠隔システム(例えばメインフレーム20)上にホストすることができる。
実行環境14は、1つ又は複数のユーザインタフェースを表示するために使用されるデータを記憶するデータ記憶域26と通信する。データ記憶域26は、(実行中のチャート内で)実行モジュール16によってアクセスされ、ユーザインタフェースを表示するために使用される、データ記憶域26内に記憶されるユーザインタフェース及び(ロギング機能を有する)チャートを開発するための開発環境28(例えば任意選択的であり得る)にとってもアクセス可能である。
一部の例では、チャート又はデータフローグラフは1つ又は複数のデータソースからのデータを処理するデータフローグラフ実行環境内で実行されるコンピュータプログラムである。データソースからのデータはコンピュータプログラムに従って操作及び処理され、1つ又は複数のデータシンクにエクスポートされる。データソース及びシンクは、例えばファイル、データベース、データストリーム、又は待ち行列を含み得る。データフローグラフは、少なくとも1つのデータ入力からのデータを処理し、少なくとも1つのデータ出力にデータを提供するためのプログラムコード(例えば実行可能ロジック)をそれぞれ含むデータ処理コンポーネントを表すノードと、データソース及び/又はシンクにアクセスするためのデータセットオブジェクトを表すノードとを含む有向グラフとして表される。ノードは、データソースから発生しデータシンクで終了するコンポーネント間のデータフローを表す有向リンクによって接続される。上流コンポーネントのデータ出力ポートは、下流コンポーネントのデータ入力ポートに接続される。データフローグラフは、データセットオブジェクトによって表される様々なデータソース及び様々なデータシンクについて再利用することができる。データフローグラフを実装するために使用されるデータ構造及びプログラムコードは、例えば様々なソース及びシンクを容易に置換できるようにするためにパラメータ化することによって複数の異なる構成をサポートすることができる。更に一部の構成では、コンポーネントの1つ又は一連のコンポーネントをバイパスすることができるように、パラメータを使用することによってデータフローグラフ内のデータフローを変えることができる。概してパラメータは、値を用いて構成することができ、その値を変更することができるデータフローグラフのコンポーネントの特性を表す。例えばかかる特性はデータフローグラフの用途間で変更することができ、変更の結果データフローグラフは操作を異なるように実行することができる。
この例では、データフローグラフがグラフィカル層及びデータ処理層を含む。グラフィカル層は、グラフィカルユーザインタフェース内の可視要素(例えばノード、データ処理コンポーネント、ポート、及び矢印又はリンク)を含む。便宜上及び制限なしに、本明細書ではデータ処理コンポーネント及びそのデータ処理コンポーネントによって表される基礎を成すプログラムコード(例えば実行可能ロジック)をまとめて「データ処理コンポーネント」と呼ぶ場合がある。同様に、便宜上及び制限なしに、本明細書ではポート(例えばコンピュータポート又はインタフェースの可視要素)及びそのポートによって表される基礎を成すプログラムコード(例えば実行可能ロジック)をまとめて「ポート」と呼ぶ場合がある。一部の例では、ポートはシステムへのインタフェース、ソフトウェアプログラム若しくは実行可能ロジックへのインタフェース、又はシステム、ソフトウェアプログラム、若しくは実行可能ロジックへの通信経路である。便宜上及び制限なしに、本明細書ではデータフローグラフ及びそのデータフローグラフによって表される基礎を成すプログラムコード(例えば実行可能ロジック)をまとめて「データフローグラフ」と呼ぶ場合がある。便宜上及び制限なしに、本明細書ではチャート及びそのチャートによって表される基礎を成すプログラムコード(例えば実行可能ロジック)をまとめて「チャート」と呼ぶ場合がある。実行される実行可能ロジックはデータ処理層の一部であるのに対し、表示されるノード、コンポーネント、及び矢印はグラフィカル層の一部であり、データフローグラフによって表される実行可能ロジックを実行する方法に関する情報をカプセル化する。
一部の事例では、データフローグラフの構築は実際に極めて技術的であり得る。特定のビジネスの目的を達成するために書かれるが、グラフの基礎を成す構造及び構築は技術的検討に基づいて決定される。例えばグラフコンポーネントは、再利用可能性を最大化するように又は並列処理をサポートするように選択することができる。かかるパラメータ化されたデータフローグラフに関連するパラメータの一部は、その実装の背後にある技術的な複雑さをビジネスユーザが理解することを必要とせずに、ユーザがデータフローグラフをカスタマイズできるようにするために使用することができる。パラメータ化されたデータフローグラフはカスタマイズを簡単にし、再利用を促進する。
換言すれば、図1に示すコンピュータシステム10は、データ記憶域26に結合される任意選択的な開発環境28であって、開発環境28はデータ処理コンポーネントのチャート又はグラフにより1つ又は複数の入力データセットから1つ又は複数の出力データセットに流れるデータに対して実行される計算を実装するチャート又はデータフローグラフに関連するコンピュータプログラムを構築するように構成され、チャート又はデータフローグラフはデータ記憶域26内のデータ構造によって指定され、データ構造によって指定され且つ1つ又は複数のリンクによって接続されるデータ処理コンポーネントを表す複数のノードを有し、リンクはデータ構造によって指定され、データ処理コンポーネント間のデータフローを表す、任意選択的な開発環境28と、データ記憶域26に結合され1つ又は複数のコンピュータ上にホストされる実行環境14であって、実行環境14はチャート又はデータフローグラフを指定する記憶済みのデータ構造を読み出すように、及び実行モジュール16によってチャート又はデータフローグラフに割り当てられるデータ処理コンポーネントの計算を実行するための計算資源を割り当てて構成するように構成される実行モジュール16を含み、本明細書に記載の方法又はプロセスの何れか1つが実行されるように実行モジュール16はデータ処理コンポーネントの割り当て済みの計算の実行をスケジューリングし制御するように構成される、実行環境14とを含み得る。実行モジュール16は、データソース12からデータを読み出し、チャート又はデータフローグラフ形式で表される実行可能コンピュータプログラムを使用してデータを処理するように構成される。
この例では、監査レコード(又は「ログレコード」とも呼ぶ)が、データレコード又はイベントを処理する際に横断されるノード(及び/又は実行されるデータ処理コンポーネント)を指定するデータ項目(例えば構造化データ項目)、及びデータレコード又はイベントを処理することの1つ又は複数の属性を含む。一部の例では、ログレコードは、特定のキー値に関する仕様の状態を表すデータを記憶するための第1のフィールドを有する構造化データレコードである。概して仕様は、例えばデータ項目を処理する際に実行される実行可能ロジックの視覚的表現である。そのため仕様はチャート、データフローグラフ等とすることができ、又はそれらを含み得る。以下でより詳細に説明するように、仕様はグラフィカル層の一部である。概して、実行可能ロジックはソースコード及び他のコンピュータ命令を含む。ログレコードは、その特定のキー値について実行可能ロジックの実行を開始した時点から現時点まで、仕様によって表される実行可能ロジックのどの部分が実行されているのか(及び/又は複数の分散されたマシンの中のどのマシン上でそのロジックが実行されたのか)を指定するデータを記憶するための第2のフィールドを含み得る。概して及びこの例では、(例えば特定のキーについて)データレコードを処理すると、システムはその特定のキー値について実行可能ロジックの実行を開始した時点から現時点まで、監査レコード(又は1つ若しくは複数の監査レコード)を生成し、特定のキー値に関する仕様の状態を表すデータを第1のフィールド内に記憶し、仕様によって表される実行可能ロジックのどの部分が実行されているのかを指定するデータを第2のフィールド内に記憶する。更に他の例ではログレコードは、仕様によって表される実行可能ロジックのどの部分が特定のキー値について現時点において実行されているのかを指定するデータを記憶するためのフィールドを有する構造化データレコードである。この例では、ログレコードを生成すると、システムは仕様によって表される実行可能ロジックのどの部分が特定のキー値について現時点において実行されているのかを指定するデータを用いてログレコードのフィールドにデータ投入する。更に他の例では、仕様がチャートであり、1つ又は複数のログレコードが、特定のキー値に関連する1つ又は複数のデータレコードを処理する際に実行可能ロジックのどの部分が実行されるのかを表すチャートを通る経路を指定する。この例ではシステムが、特定のキー値に関連する1つ又は複数のデータレコードを処理する際に実行可能ロジックのどの部分が実行されるのかを表すチャートを通る経路を指定するログレコードを生成する。更に他の例では、システムが1つ又はデータ項目を処理することに基づいて1つ又は複数の出力レコードを生成する。この例では、1つ又は複数の出力レコードのそれぞれがログレコード内に含まれないデータを含む。
以下でより詳細に説明するように、様々な種類の監査レコードが様々なフィールドと共に予め定められ、それぞれのフィールドの種類はデータレコード又はイベントを処理することの1つ又は複数の属性を指定する。概してイベントは、特定の発生又は発生の欠如を表す(例えば既定の形式の)データレコードを含む。
この例では、性能モニタリングモジュール18が監査レコード及び実行モジュール16の性能に関する他の性能メトリックを収集する。性能モニタリングモジュール18は、実行モジュール16から監査レコードを収集する監査ログモジュール24(本明細書では「集約エンジン」とも呼ぶ)を含み、実行モジュール16は更には各データ処理コンポーネントから監査レコードをそれぞれ作成する複数の別個のチャートを実行している場合がある。監査ログモジュール24は、例えば本明細書に記載の通りに監査ログを分類する分類器24aを含む。監査ログモジュール24は、監査レコードのコンテンツを「マスタ」ログ(例えば指定の期間にわたって受信される監査レコードのコンテンツを含むログレコード)へと結合することによって(例えば指定の時間間隔において)受信済みの監査レコードを集約する。これらの集約済みのログレコードは、例えばその後のアクセスのためにデータ記憶域26内に記憶され、及び/又は集約済みの監査レコードからメトリックを生成するメトリック生成モジュール25に伝送するためにデータストア40内に記憶される。概してメトリックは、例えば読み出されたレコード数、読み出されたバイト数、書き込まれたレコード数、書き込まれたバイト数、使用されたプロセッサ時間、及び経過時間のうちの一部又は全てを含む集約レベルにおける詳細データを含む。メトリックはイベント(例えばデータレコード)ごとの、従ってイベントの種類ごとのシステムによる計算レイテンシも指定し得る。集約済みの監査レコードから生成される他の種類のレイテンシメトリックは、レイテンシメトリック(例えばデータレコードがソースにおいて作成されたときから現時点、つまり「今の」時点までの時間)、データレコードがソースにおいて作成されたときからデータレコードがシステムによって最初に認められたときまでのレイテンシを指定する外部レイテンシメトリック、データレコードがシステムによって最初に認められたときから今の時点までのレイテンシを指定する内部レイテンシメトリック、及び論理時間から今の時点までのレイテンシを指定する論理遅延メトリックを含む。システムは、コンピュータプログラムの個々のプロセス(データフローグラフ内の個々のコンポーネント等)の実行時間、プログラム又はグラフの総実行時間、特定のプログラム又はグラフに関するプログラム又はグラフの平均実行時間等、数多くの他の種類のメトリックを計算することもできる。メトリック生成モジュール25は生成したメトリックをデータストア42に出力する。
性能モニタリングモジュール18は、メトリック生成モジュール25から生成される1つ又は複数のメトリックを含む、及び/又は収集済みの監査レコードからの未処理の(及び/又は集約済みのデータ)を含む出力データセットを(例えばデータストア40、42の1つ又は複数から取得されるデータから)生成する。この例では、環境14(例えばデータ処理システム)が出力データセットの1つ又は複数の部分をユーザインタフェース内に表示する。
図2Aを参照し、実行モジュール16が第1の時点T1においてデータフローグラフ23を記憶する(又はそれにアクセスする)。この例では、データフローグラフ23がデータソース23a、コンポーネント23b、23c、23e、23j、23l、23m、及びデータシンク23z、23nを含む。
この例では、データフローグラフ23は単方向リンクによって結合される幾つかの頂点(即ちソース23a、コンポーネント23b、23c、23e、23j、23l、23m、及びデータシンク23z、23n)を含む計算グラフの一例である。計算グラフ23は、トランザクション処理システムに関連する計算グラフに従って処理される個々のトランザクション等、一連の作業要素で構成されるワークフローを処理する。トランザクションは複数の作業要素で構成され得る。各コンポーネントは、全体的な計算グラフによって定められる計算の一部に関連する。この例では、コンポーネント23aが1つ又は複数のトランザクションに関連する最初の一連の作業要素のための記憶域へのアクセスを提供し、その一連を自らの出力リンク上で伝える。コンポーネントのそれぞれに関連する計算を実装するプロセスは作業要素を順に処理し、典型的にはその頂点の出力リンクの1つ又は複数の上に作業要素をもたらす。
この例ではコンポーネント23eが、入力レコードを受信するための入力ポート23d、出力レコードを出力するための出力ポート23f、エラーログを出力するためのエラーログポート23g、及び監査データを出力するための監査ポート23hを含む。この例では、監査ポート23hが監査データをデータシンク23nに、例えば監査データを収集するための専用データソースに出力するように構成される。同様にコンポーネント23jは、(出力レコードをデータシンク23zに出力するための)出力ポート23o、(エラーログをエラーハンドラコンポーネント23lに出力するための)エラーログポート23p、及び監査データをデータシンク23nに出力するための監査ポート23qを有する。
この例ではデータフローグラフ23が、例えばコンポーネント(例えば23r、23j)による処理中にエラーが発生した場合にエラーメッセージを受信するエラーハンドラコンポーネント23lを含む。データフローグラフ23は、エラーの前の状態にデータフローグラフを戻し又はロールバックするロールバックコンポーネント23mも含む。概してロールバックは、フェイルオーバが時点まで処理済みデータを巻き戻すこと、従って処理済みを前の無矛盾の時点まで「巻き戻すこと」を可能にする。具体的には、コンポーネント23jからの入力データは、グラフ23がトランザクションの処理を開始する前に事柄(例えばデータ又はコンポーネント)の状態が何だったのか、具体的にはコンポーネント23eが実行を開始する前にグラフ23の状態が何だったのかをエラーハンドラコンポーネント23lに伝える。以下でより詳細に説明するように、エラーハンドラコンポーネント23lはそれをロールバックコンポーネント23mに出力し、ロールバックコンポーネント23mはそれを使用して、他のコンポーネントによって修正された任意のデータをトランザクションの実行前の状態に回復する。
図2Bを参照し、データ処理システムが第2の時点T2においてデータフローグラフを実行する。この例では、ソースコンポーネント23aが入力レコード23rをコンポーネント23bに伝送し、コンポーネント23bは入力レコード23rを処理してレコード23sを出力する。次いでレコード23sがコンポーネント23cに入力され、コンポーネント23cはレコード23sを処理し、その処理に基づいてレコード23tを出力する。コンポーネント23cはレコード23tをコンポーネント23eに伝送し、コンポーネント23eはレコード23tである入力レコードを入力ポート23dにおいて受信する。それを受けてコンポーネント23eが入力レコード23tを処理し、出力レコード23vを出力ポート23f上で出力する。コンポーネント23eは、どのレコード(即ちレコード23t)がコンポーネント23eによって処理されるのかをチェックポイントするチェックポイント操作も実装することができる。チェックポイント操作は、データフローグラフ23の現在の状態が、コンポーネント23eが成功裏に実行しレコード23tを処理した状態であることを指定するチェックポイントメッセージ23uを生成する。コンポーネント23eは更に、チェックポイントメッセージ23uを出力ポート23f上で出力する。この例では、コンポーネント23eが自らの入力レコードを成功裏に処理するので、エラーログポート23g上では何も出力されない。コンポーネント23eは、入力レコード23rによって表されるトランザクションの1つ又は複数の部分を表す監査データ23wを監査ポート23h上で出力する。
図2Cを参照し、第3の時点T3においてデータフローグラフ23の実行がコンポーネント23jに進み、コンポーネント23jは出力ポート23o、エラーログポート23p、及び監査ポート23qを含む。この例では、コンポーネント23jがレコード23v及びチェックポイントメッセージ23uを入力として受信する。コンポーネント23jは入力レコード23vを処理する際にエラーに遭遇する。この時点において、コンポーネント23jがエラーに遭遇し入力レコード23vの処理を完了し処理に由来する監査データを出力することができなかったので、コンポーネント23jにおいて入力レコード23vを処理することによる監査データが失われる。そのため、コンポーネント23jはエラーログ27aをエラーログポート23p上で出力し、エラーログ27aは最後の成功裏に実行されたコンポーネントの状態を含み、どの入力レコード(即ちレコード23t)がそのコンポーネントによって最後に成功裏に処理されたのかも指定する。この時点において、コンポーネント23jは目下有効にされているエラーハンドラコンポーネント23lにエラーログ27aを出力する。エラーハンドラコンポーネント23lは、最後の成功裏に実行されたコンポーネントであるコンポーネント23eの状態(即ち状態C3)及びそのコンポーネントによってどのレコードが処理されたのかを指定するメッセージ27bを(同じく目下有効にされている)ロールバックコンポーネント23mに伝送する。メッセージ27bを使用し、ロールバックコンポーネント23mは図2Dに示すようにコンポーネント23eが実行されておりレコード23tが処理されている状態へとデータフローグラフ23の状態を戻し、従ってコンポーネント23jに関する監査データの回復性を有効にする。
図2Eを参照し、コンポーネント23eが実行し入力レコード23dを処理する状態へとデータフローグラフ23の状態が戻される。この例では、コンポーネント23jが入力レコード23vを成功裏に処理し、データシンク23z内に保存される出力レコード27dを出力ポート23o上で出力することができる。この例ではエラーログポート23p上でエラーログが出力されず、データシンク23n内に保存される監査データ27cを監査ポート23qが出力する。この例では監査データ27cが回復済みの監査データである。本明細書に記載の通り、収集されデータシンク23n内に保存される監査データ23w、27cは集約され結合され得る。
図3Aを参照し、環境10は含み、実行モジュール16によって実行されるグラフ等のプログラムから監査レコードを収集する(及びそれらの収集済みの監査レコードからメトリックを生成する)。
実行モジュール16はグラフ30等のコンピュータプログラムを実行する。一部の実装形態では、グラフ30が事前にコンパイルされていてもよい。この例では、実行モジュールはコンピュータシステムによって実行されるプロセス又は1組のプロセスであり得る。グラフは、データ記憶域26(図1)等の非一時的コンピュータ可読記憶装置内に記憶され得る1組のコンピュータ可読命令であり得る。グラフ30はデータストア、例えば図1のデータ記憶域26からロードされ得る。
この例では、グラフ30が、入力ポート32a、出力ポート32b、及び監査ポート32cを含むコンポーネント32を含む。本明細書では監査ポートを「ログポート」又は「インタフェース」と呼ぶ場合もある。概して、監査ポートは監査レコード(本明細書では「ログ」又は「ログレコード」とも呼ぶ)を出力するためのポートである。一部の例では、監査ポートが監査レコード又はログレコードを出力するためのインタフェースを含み、監査ポートは監査レコードを出力するためだけの専用ポートであり得る。この例では、監査ポートが入力ポート及び出力ポートのそれぞれと分かれている。この例では、コンポーネント32がデータソース34からデータを読み出し、その読み出しデータを入力ポート32a経由で受信する。この例では、コンポーネント32(又はコンポーネント32によって表される実行可能ロジック)が1つ又は複数の監査レコードを生成し、それらの監査レコードをポート32c上で出力する。コンポーネント32はリンク38によって別のコンポーネント36に接続される。コンポーネント36は、入力ポート36a、出力ポート36b、及び監査ポート36cを含む。コンポーネント32の出力ポート32bからのデータレコードがコンポーネント36の入力ポート36a内に伝えられる。概してポートは、データフローグラフのコンポーネントがデータを受信し又は提供することができる任意の機構を指す。ポートは、例えば伝送制御プロトコル(TCP)/インターネットプロトコル(IP)ポート、ネットワークソケット、又はソフトウェアパイプであり得る。ポートは、例えば共用メモリへの読み書き等、コンポーネント間の他の通信方法を指す場合もある。
コンポーネント36は出力レコード51a~51b(図3B)を出力ポート36b上に作成し、それらの出力レコードはデータストア38内に記憶され得る。この例では、コンポーネント36がコンポーネント(32又は36)の性能特性をモニタし記録し、それらのモニタリング及び/又は性能特性を含む監査レコードを生成する。例えばコンポーネント36は、使用されたプロセッサ時間、経過時間、読み出しバイト数、読み出しレコード数、書き込みバイト数、書き込みレコード数、実行回数、実行に失敗した回数、総持続時間、平均レコード処理速度(レコード/秒)、平均バイト処理速度(バイト/秒)等の何れか1つ又は組み合わせ等の性能メトリックを収集し、それらの収集済みのメトリックを監査レコード内に含めることができる。
監査レコードは、コンポーネント36の監査ポート36c上に(例えばコンポーネント36によって、又はコンポーネント36によって表される基礎を成す実行可能ロジックによって)作成することができる。例えば監査レコードは、コンポーネント36の性能に関する情報及び先に記載した他の情報を含む1つ又は複数のレコードであり得る。
この例では、ポート32c、36c上で出力される監査レコードが監査ログモジュール24によって収集される。この例では、以下でより詳細に説明するように監査ログモジュール24が監査レコードを後処理する。監査ログモジュール24は更に、収集済みの監査レコード内のデータを指定の時間間隔において(例えば1時間ごとに)結合し及び/又はロールアップする。概して「結合」操作は2つ以上の別個のファイル又はデータレコードからのデータを組み合わせることを指す。概して「ロールアップ」操作は、1つ又は複数のファイル又はデータレコードからデータを集約し、その集約済みのデータを出力することを指す。例えばロールアップ操作は、1つ又は複数のデータレコード内のフィールド内の値に基づいて和、最小、最大を計算することができる。この例では、監査ログモジュール24が指定の時間間隔において集約済みの監査レコード(例えばその特定の時間間隔の間に収集される個々の監査レコードに対して結合及び/又はロールアップ操作を行うことによって生成される監査レコード)を作成する。監査ログモジュール24は、集約済みの監査レコードを性能モニタリングモジュール18内のデータストア40に伝送する。一部の実装形態では、監査レコードを書き込む性能上の影響を最小化するようにデータストア40が選択される。例えば、データストア40に監査レコードを書き込むことによって生じるレイテンシを減らすことが有利であり得る。一部の実装形態では、データストア40が共用メモリ40内に位置し得る。共用メモリ40はランダムアクセスメモリ(RAM)等の高速メモリであり得る。共用(例えば半導体)メモリに書き込む操作は概して少ないオーバヘッドを生ぜしめ、その結果低速メモリ、つまり磁気ディスク(例えばハードディスク)等の永続データ記憶域に書き込む同様の操作よりも高速である。この例では、例えば集約済みの監査レコードと共に収集済みの監査レコードを指定の時間間隔において記憶することにより、監査ログモジュール24が収集済みの監査レコードをデータストア40内に一括で記憶する。
断続的に、例えば5分、10分、又は30分ごとに、メトリック生成モジュール25は集約済みの監査ログをデータストア40から読み出し、集約済みの監査ログから性能メトリックを生成する。メトリック生成モジュール25は集約済みの監査ログ(及び/又は保存されている場合は個々の監査ログ)をデータストア40から読み出すことができ、そのデータを更に処理し集約することができる。例えばメトリック生成モジュール25は、単一のトランザクションを一緒に構成する複数のプログラム又はデータフローグラフに関連する性能メトリックを監査ログ内に含まれるデータに基づいて組み合わせることができる。性能モニタリングモジュール18は、出力データセット内にそれらのメトリックを含めることにより、性能メトリックをユーザにグラフィカルに提示し或いは出力することができる。メトリック生成モジュール25は性能メトリックをデータストア42に書き込む。一部の実装形態では、データストア42が永続データストア内に位置し得る。次いでデータストア42は、生成済みのメトリックの少なくとも一部を出力データセットとして出力する。この例では、コンポーネント32及び36がコンピュータプログラムの実行可能ロジックの2つの異なる部分の2つの説明的な例を表す。
図3Bは、データフローが示されている図3Aの改変形態である。この例では、コンポーネント32がデータソース34からデータレコード44a~44dを(入力ポート32a上で)受信する。コンポーネントは、受信データレコード44a~44dのそれぞれを処理する。この例では、コンポーネント32が処理されるデータレコードのそれぞれについて監査レコードを生成する。そのためコンポーネント32は、データレコード44a~44dのそれぞれについて監査レコード50a~50dを生成する。この例では、コンポーネント32が監査レコード50a~50dのそれぞれをポート32c上で出力し、監査レコード50a~50dをポート32c経由で監査ログモジュール24に伝送する。この例ではポート32cが、監査ログを生成するためだけの及びそれらの監査ログを監査ログモジュール24に送信するためだけの専用インタフェースである。
この例では、レコード44a~44dのそれぞれを処理した後、コンポーネント32がレコード46a~46cを出力ポート32b上で出力し、レコード46a~46cはコンポーネント36の入力ポート36aに伝送される。この例では、コンポーネント32によるレコード44a~44dの処理が3つの出力レコード46a~46cだけをもたらす。コンポーネント36はレコード46a~46cを処理し、レコード46a~46cのそれぞれについて監査レコード48a~48cを生成し、それらのレコードは出力ポート36c上で出力され、監査ログモジュール24に伝送される。この例では、監査ログモジュール24が監査レコード48a~48c及び50a~50dを収集し、それらの監査レコード48a~48c及び50a~50dに対してロールアップ及び/又は結合操作を実行して集約済みの監査レコードを作成する。監査ログモジュール24は集約済みの監査レコードをデータストア40(例えば共用RAM)に伝送する。メトリック生成モジュール25は集約済みの監査レコードを読み出し、それを受けて本明細書に記載の様々なメトリックを表すメトリックデータ(又はデータレコード)を生成する。メトリック生成モジュール25は、記憶するために及びメトリックデータの少なくとも一部を出力データセットに出力するために、メトリックデータをデータストア42に伝送する。
図4Aを参照し、環境10の改変形態を示す。この改変形態では、実行モジュール16がデータ処理システム62(本明細書では第1の処理システム62とも呼ぶ)及びデータ処理システム64(第2の処理システム64とも呼ぶ)という2つの別個のシステムを含む。処理システム62はメモリ62a及び実行サブシステム62bを含む。処理システム64はメモリ64a及び実行システム64bを含む。処理システム62、64のそれぞれは、例えばデータフローグラフ、チャート等を表す実行可能ロジックを含むコンピュータプログラムの様々な種類の実行可能ロジックを実行するように構成される。この例では、監査ログモジュール24がシステム62、64のそれぞれから出力(例えば監査又はログレコード)を受信する。システム62、64は分散型の処理システムである。
図4Bを参照し、環境60は(実行モジュール16内に含まれる)データ処理システム62、64、及び性能モニタリングモジュール18をやはり含む実行環境14を含む。この例では、データ処理システム62がコンポーネント74a、75a、76a、78a、80a、82a、84a、及びデータストア86a、88aを有する(特定のデータフローグラフのバージョンである)データフローグラフ66aを表す実行可能ロジックを実行する。以下、データフローグラフ及び/又はチャートの実行は、データフローグラフ又はチャートをそれぞれ表す実行可能ロジックの実行を指す。この例ではコンポーネントは、データ処理エンティティ間のデータフローを表す1つ又は複数のリンクによって接続される複数のデータ処理エンティティ(例えば1つ又は複数のCPU)を表し得る。データ処理システム64は、データ処理システム62によって実行される特定のデータフローグラフの別のバージョンであるデータフローグラフ66bを表す実行可能ロジックを実行する。この例では、データ処理システム62、64が入力される受信データレコード(例えば1つのデータストリームから又は複数のデータストリームから受信されるデータレコード)を並列処理するための分散型システムである。改変形態では、データ処理システム62、64のそれぞれが別個のデータフローグラフを実行している場合もある。
この例では、データフローグラフ66a、66bのそれぞれが、リアルタイム入力データストリーム内に含まれるデータ項目に対するプロセスを実行する。この例では、データ処理システム62、64のそれぞれが、データレコード(例えば全ての記録され及び/又は受信されるイベントのワイドレコード)を生成し、その生成済みのレコードをデータストア86a、86bに(それぞれ)発行する際にデータフローグラフ66a、66bを(それぞれ)実行する。
データフローグラフ66aは、ソースデータリーダ又は複数のソースデータリーダをサブスクライブする(例えばそこからデータを受信する)サブスクライブコンポーネント75aを含む。サブスクライブコンポーネント75aにより、データフローグラフ66aはリアルタイムデータストリーム内に含まれるデータ項目にリアルタイムでアクセスする。この例では、サブスクライブコンポーネント75aが(例えば数千ものレコードを含む)リアルタイム入力データストリームを(例えばその可読性を保証するためにデータストリームに対して幾らかの初期処理を行い得る)データ待ち行列から受信する。データはサブスクライブコンポーネント75aから分割コンポーネント74aに流れ、分割コンポーネント74aはデータフロー内で受信される(イベントを含む)データ項目をイベントの種類ごとに分割し又は分ける。この例では、分割コンポーネント74aが様々な種類のデータレコード又はイベントを検出するように構成され、特定の種類のイベントを処理するように構成される他のコンポーネントに対して様々な種類のイベントを分割する。この例では、コンポーネント76a、78a、80a、82aのそれぞれが特定の種類のイベントを処理するように構成される。
この例では、データフローグラフ66bが結合操作を実装する結合コンポーネント84aを含む。結合操作は様々な種類のデータ、例えばコンポーネント76a、78a、80a、82aからのイベントを結合する。この例では、データがコンポーネント76a、78a、80a、82aから結合コンポーネント84aに流れ、結合コンポーネント84aはそれらのイベントをワイドレコード(例えば様々な処理済みのレコード内に含まれる値を記録するためのフィールドを有するデータレコード)内で結合する。この例では、イベントコンポーネント76a、78a、80a、82aのそれぞれが、エンティティのためのユーザID等、イベントに関連するエンティティを一意に識別するデータに関連してイベントを結合コンポーネント84aに送信する。結合コンポーネント84aの出力は、どの特定の既定のイベント及びそれらのイベントに関連するユーザIDがを指定するデータを有するデータレコードである。しかし改変形態では、結合コンポーネント84aの出力は、コンポーネント76a、78a、80a、82aによる受信データレコードの処理を表すコンテンツを有するデータレコードであり得る。この例では、データ(例えばデータレコード)が結合コンポーネント84aからデータストア86aに流れ、結合コンポーネントから出力されるデータレコードが出力される。
この例では、(データ処理システム62上で実行される)コンポーネント74a、75a、76a、78a、80a、82a、84aのそれぞれが監査ポート74c、75c、76c、78c、80c、82c、84cを有し、それらの監査ポートは個々のコンポーネントによって1つ又は複数のデータレコードを処理することの1つ又は複数の属性を表す1つ又は複数の監査レコードをそれぞれ出力する。例えば監査ポート74cは、コンポーネント75aから受信されるデータレコードに対して分割操作を行うことを示す監査レコードを出力する。データ処理システム62上で実行されるデータストア88aが、監査ポート74c、75c、76c、78c、80c、82c、84c上で出力される監査レコードを受信し、本明細書に記載の更なる処理のためにそれらの監査レコードを(例えば1時間ごと等の指定の時間において)監査ログモジュール24に伝送する。この例では、コンポーネント74a、76a、78a、80a、82a、及び84aがコンピュータプログラムの実行可能ロジック(ここではデータフローグラフ66a)の様々な部分の説明的な例を表す。
データフローグラフ66bは、ソースデータリーダ又は複数のソースデータリーダをサブスクライブする(例えばそこからデータを受信する)サブスクライブコンポーネント75bを含む。サブスクライブコンポーネント75bにより、データフローグラフ66bはリアルタイムデータストリーム内に含まれるデータ項目にリアルタイムでアクセスする。この例では、サブスクライブコンポーネント75bが(例えば数千ものレコードを含む)リアルタイム入力データストリームを(例えばその可読性を保証するためにデータストリームに対して幾らかの初期処理を行い得る)データ待ち行列から受信する。データはサブスクライブコンポーネント75bから分割コンポーネント74bに流れ、分割コンポーネント74bはデータフロー内で受信される(イベントを含む)データ項目をイベントの種類ごとに分割し又は分ける。この例では、分割コンポーネント74bが様々な種類のデータレコード又はイベントを検出するように構成され、特定の種類のイベントを処理するように構成される他のコンポーネントに対して様々な種類のイベントを分割する。この例では、コンポーネント76b、78b、80b、82bのそれぞれが特定の種類のイベント(例えばレコード)を処理するように構成される。
この例では、データフローグラフ66bが結合操作を実装する結合コンポーネント84bを含む。結合操作は様々な種類のデータ、例えばコンポーネント76b、78b、80b、82bからのイベントを結合する。この例では、データがコンポーネント76b、78b、80b、82bから結合コンポーネント84bに流れ、結合コンポーネント84bはそれらのイベントをワイドレコード(例えば様々な処理済みのレコード内に含まれる値を記録するためのフィールドを有するデータレコード)内で結合する。この例では、イベントコンポーネント76b、78b、80b、82bのそれぞれが、エンティティのためのユーザID等、イベントに関連するエンティティを一意に識別するデータに関連してイベントを結合コンポーネント84bに送信する。結合コンポーネント84bの出力は、どの特定の既定のイベント及びそれらのイベントに関連するユーザIDがを指定するデータを有するデータレコードである。しかし改変形態では、結合コンポーネント84bの出力は、コンポーネント76b、78b、80b、82bによる受信データレコードの処理を表すコンテンツを有するデータレコードであり得る。この例では、データ(例えばデータレコード)が結合コンポーネント84bからデータストア86bに流れ、結合コンポーネントから出力されるデータレコードが出力される。
この例では、(データ処理システム64上で実行される)コンポーネント74b、75b、76b、78b、80b、82b、84bのそれぞれが監査ポート74d、75d、76d、78d、80d、82d、84dを有し、それらの監査ポートは個々のコンポーネントによって1つ又は複数のデータレコードを処理することの1つ又は複数の属性を表す1つ又は複数の監査レコードをそれぞれ出力する。例えば監査ポート74dは、コンポーネント75bから受信されるデータレコードに対して分割操作を行うことを示す監査レコードを出力する。データ処理システム64上で実行されるデータストア88bが、監査ポート74d、75d、76d、78d、80d、82d、84d上で出力される監査レコードを受信し、本明細書に記載の更なる処理のためにそれらの監査レコードを(例えば1時間ごと等の指定の時間において)監査ログモジュール24に伝送する。この例では、コンポーネント74b、76b、78b、80b、82b、及び84bがコンピュータプログラムの実行可能ロジック(ここではデータフローグラフ66b)の様々な部分の説明的な例を表す。
この例では、監査ログモジュール24が分散型システム、例えばデータ処理システム62、64から監査レコードを受信し、それらの分散型システムのそれぞれはコンポーネント75a、75bからそれぞれ受信されるデータレコードの処理を分割している。事実上、監査ログモジュール24は、データレコードを分割し多くの異なるシステムにわたって分散式に実行されているデータフローグラフから監査レコードを受信する。この例では、コンポーネント74a~b、75a~b、76a~b、78a~b、80a~b、82a~b、84a~bのそれぞれが監査ポートを有する。一部の改変形態では、データフローグラフ内に含まれるコンポーネントのサブセットだけが監査ポートを有し得る。
この例では、分散型データ処理システム62、64のそれぞれが、実行環境14及び環境10(図1)のそれぞれと別個である。各データ処理システム62、64から、監査ログモジュール24はその分散型データ処理システムに由来する1つ又は複数のログレコードを受信し、分散型データ処理システム62、64のそれぞれから受信されるログレコードのコンテンツを結合する。この例では、データ処理システム62、64のそれぞれがデータストリームの1つ又は複数のデータ項目を入力装置又はポート(例えばコンポーネント75a、75bのそれぞれ)上で断続的に受信する。受信される1つ又は複数のデータ項目の少なくとも1つについて、グラフ66a、66bをそれぞれ表す実行可能ロジックの第1の部分をそのデータ項目に対して実行することを含め、データ処理システム62、64のそれぞれがデータ項目を処理する。例えば第1の部分は、分割コンポーネント、例えばコンポーネント74a、74bの1つを表す実行可能ロジックを含み得る。この例ではシステム62、64のそれぞれが、実行可能ロジックをひいては表すデータフローグラフ66a、66bに関する仕様に(例えば図1内のデータ記憶域26から)アクセスする。この実行に応答し、システム62、64のそれぞれは、その分散型データ処理システム上でそのデータ項目を処理する際に実行される実行可能ロジックの第1の部分を第1のログレコードが指定した状態で第1のログレコードを生成し、例えば第1のログレコードを監査ログモジュール24に(例えばリアルタイムで、指定の時間において、及び/又は一括で)伝送するデータストア88a(例えば共用RAM)に第1のログレコードをまず伝送することにより、第1のログレコードをインタフェース(例えば監査ポート74c、74dのそれぞれ)によって監査ログモジュール24に出力する。ログレコードは、特定のコンポーネントによってデータレコード又はイベントを処理することの属性の値を含む。例えば(コンポーネントがデータレコードを処理し始めてからコンポーネントがデータレコードの処理を完了するまでの経過時間を指定する)レイテンシ属性、(処理されるデータレコード内に含まれるキーを指定する)キー属性、(コンポーネントによって処理されているデータレコードのコンテンツを指定する)コンテンツ属性、(コンポーネントが処理を開始する時間を指定する)開始時間属性等を含む様々な種類の属性がある。この例では、監査ログモジュール24が受信済みの監査ログのコンテンツを結合し、それをメモリ(例えばデータストア40)内に記憶する。このメモリはRAM又はハードディスクとすることができる。次いで、メトリック生成モジュール25が結合済みのコンテンツにメモリからアクセスし、結合済みのコンテンツから1つ又は複数のメトリックを生成する。
図4Bの例では、データフローグラフ66a、66b内の各コンポーネントが、より正確且つより粒度の細かい監査ロギングを可能にするための監査ポートを含む。加えて、監査ログモジュール24は複数のシステム62、64から監査レコードを収集し、システム62、64のそれぞれによって処理されるレコードは例えば分割コンポーネント74a、74bによる処理において分割される。そのため、監査ログモジュールは複数の分割されたシステムから監査レコードを収集することができる。システム62、64のそれぞれが自らの監査レコードを個々に収集するのではなく監査ログモジュールが複数の分割されたシステムから監査レコードを収集する利点は、監査ログモジュール24がマルチシステムエラー(例えば両方のシステム62、64にわたって生じるエラー)及び実行モジュール自体の中のエラーを検出できることである。かかるエラーを検出するための手段、及び最終的にそれらの検出済みのエラーを訂正するための手段も前々から提供することは、システム性能を改善しレイテンシを減らす手段をもたらす。一例では、例えばグラフ66a、66b内のコンポーネント78a、78bによって表される特定のコンポーネントがデータを再フォーマットするためのコンポーネントである。この例では、入力される一定のデータの種類についてのみ特定のコンポーネントが再フォーマットを適切に行うことができない。データフローグラフが複数のシステム(例えば100個のシステム)にわたって実行される場合、特定のコンポーネントは100個の別個のシステム上で実行されている。コンポーネント78a、78bが100個等の複数のシステム(100個のシステムのそれぞれは異なる種類のデータ又は異なるデータ形式を処理している)にわたって実行されるとき、監査ログモジュール24はコンポーネント78a、78bに関する監査レコードを(コンポーネント78a上の専用出力ポートを介して)収集しているので、監査ログモジュール24は特定のコンポーネントが再フォーマットを正しく行うことができない一定のデータの種類又は形式を識別することができる。監査ログモジュール24内で全ての監査レコードを中心的に収集することにより、監査ログモジュール24は集合的なエラーデータ(コンポーネント78a、78bが再フォーマットすることができない様々な異なる種類のデータの種類又は形式)を識別することができる。そのため、最終的により時間がかかり新たなデータの種類について問題を解決できない場合さえある個々のマシン上での個別の修正ではなく、(例えばコンポーネント78a、78bのための中央ライブラリ又はリポジトリ内に記憶される実行可能ロジックを編集することにより)特定のコンポーネントに関する問題をシステム全般にわたって訂正するためにこの集合的なエラーデータが実行環境14によって使用され得る。従って、基礎を成すデータ処理システムの計算性能が改善される。
加えて、監査ログモジュール24が全ての又は複数のマシンにわたって監査レコードを中心的に収集しているので、実行環境14(例えばデータ処理システム)はリアルタイムの監査レコード及びメトリックを大規模に生成する(例えば1日当たり数十億のイベントについて監査レコードを生成し処理する)。かかる生成の理由は、監査レコードをシステム上でローカルにしか記憶せず、それらのレコードを指定の時間において監査ログモジュールにプッシュするのではなく、チャート又はデータフローグラフ66a、66b等のコンピュータプログラムを実行している各システム(例えばシステム62、64)が監査ログモジュール24に向けて監査レコードをリアルタイムで、即ちプログラム/チャート/データフローグラフが目下実行されている間に自動的にプッシュし、そのためプログラム/チャート/データフローグラフの実行中に且つこの実行が完了する前に既に監査レコードが監査ログモジュール24にとってアクセス可能になるからである。監査レコードは、対応するシステム62、64上で監査レコードをローカルに一切記憶することなしにログモジュール24に直接プッシュすることができ、又はプログラム/チャート/データフローグラフの実行中にログモジュール24にとって既にアクセス可能なデータストア88a、88b内にローカルに記憶することができる。データストア88a、88bは、レコードをローカルに記憶する場合でもレイテンシを減らすのに依然として有益な共用メモリ(例えばRAM)とすることができる。加えて、各コンポーネントは専用監査ポートを有し、専用監査ポートはそのコンポーネントがデータレコード又はイベントを処理するときに関して監査ログモジュールが監査レコードをリアルタイムで受信することを更に可能にする。これにより監査レコードを受信する際のレイテンシが減る。例えば監査レコードがチャート又はデータフローグラフの完了時にしか生成されない場合、システムがチャート又はデータフローグラフの実行を完了するのを待つことによるレイテンシが生じ、そのことはひいては(監査レコード内で表される)エラーを訂正する際の及び/又はメトリックを生成する際のレイテンシを増やす。各コンポーネントが専用監査ポートを有し、そのコンポーネントが実行を終えるや否や(例えばそのコンポーネントによって表される実行可能ロジックが実行を終えるや否や)監査レコードを監査ログモジュールに(例えばレコードをローカルに記憶することなしに直接、又は共用メモリを介して)自動的にプッシュすることにより、監査レコードをreceicingする際の及びそれらの監査レコードからメトリックを計算する際のレイテンシが、チャートの完了時にのみ監査レコードを受信する際のレイテンシと比較して減る。
更に、(複数のマシン上で実行される)グラフの分散型の性質及び各グラフがレコードの処理を分割することは、イベント又はデータレコードがグラフ内の各コンポーネントによって処理される場合と比較し、監査レコードが監査ログモジュールによってリアルタイムで及び/又はほぼリアルタイム(例えばライブ時間)で受信されることを可能にし、そのことはひいてはリアルタイムのメトリックを生成できるようにし、それによりそのメトリックに基づいてエラーをリアルタイムで識別することを可能にする。受信済みのレコードを処理するためにそれらのレコードをそれぞれ分割する複数のシステムにわたって(各コンポーネントがデータレコード又はイベントを処理するとき)監査レコードが並列に生成されるので、実行環境14は監査レコードを大規模に処理することができる。つまり、データレコードが受信されればされるほど、又はより多くの待ち行列がサブスクライブされると(従ってそれらのクエリによってより多くのデータレコードが受信されると、各コンポーネントの実行時に監査レコードを大規模に且つリアルタイムで生成することを可能にする(グラフ及び/又はチャートの各コンポーネントが専用監査ポートを含みながら適切なグラフ及び/又はチャートを実行する)更に多くのシステムを追加してデータレコードの増加を処理することにより及び大規模に処理を行うことにより、実行環境14はそれらのデータレコードを大規模に処理することができる。監査レコードの生成(及び監査レコードを生成する結果として生じるフロー)がデータストリームを処理するデータフローと別個なので、実行環境14はそれらのレコードを大規模に処理することもできる。つまり、監査レコードを生成するための専用ポートを有することにより、監査レコードの生成が(データ処理に由来する)データフローに対して直交し、そのため監査レコードを生成することはデータフローに影響を及ぼさない。つまりデータ処理システムは、データ処理システムの複数のサブシステムによって処理されるデータ項目を含むデータストリームと別個のデータストリーム内にログデータを出力できるようにする専用ログポートをそれぞれ含む複数の処理システム(又はサブシステム)を含み、それによりログデータを出力することがデータの処理にレイテンシを生じさせることがない。具体的には、出力(例えば監査レコード)はデータフローに対して非同期だと考えることができる。データフローグラフによるデータ処理はデータ処理の第1の層である。監査ポートは第2の層である。そのため第2の層の性能が第1の層に影響を与えることはない。この第2の(非同期)層において監査レコードを生成することにより、レコードの生成が影響を受けることはない。このことは監査レコード及び(監査レコードから生成される)メトリックを大規模に生成することを可能にする。
加えて、上記のようにシステムが(例えば適切なデータフローグラフ及び/又はチャートを実行する追加のシステムを実装することにより)データレコードを大規模に処理することができるので、実行環境14はメトリックを大規模に生成することができる。加えて、監査レコードがリアルタイムで又はほぼリアルタイムで受信され処理されることに応答して、及び受信され処理されるときにメトリックが生成されるので、(全ての実行中のシステムにわたる各コンポーネントが実行を終了するとき)メトリックがリアルタイムで又はほぼリアルタイムで生成される。
全てのメトリックを中心的に収集することにより(例えば全ての監査レコードを中心的に収集し、中心的に収集した監査レコードからメトリックを生成することにより)、実行環境14はより正確で粒度が細かく集約的なメトリックをリアルタイムで生成し表示することができる。例えば個々のコンポーネント、例えばコンポーネント78aの処理速度をそのコンポーネントの実行時にほぼリアルタイムで計算することができる。例えばコンポーネント78aが100台の異なるマシンにわたって実行されており、(コンポーネント78aのための専用ポートによって)コンポーネント78aに関して作成される各監査レコードが、コンポーネント78aがdata recirdの処理を開始したとき及びコンポーネント78aがデータレコードの処理を完了したときを指定するレイテンシメトリックを含む場合、メトリック生成モジュールはコンポーネント78aがデータレコードの処理を開始するときからデータレコードの処理を完了するときまでの平均レイテンシ(例えば処理時間)を(コンポーネント78aの実行(又はコンポーネント78aを表す実行可能ロジックの実行)と比較して)ほぼリアルタイムで計算することができる。(グラフレベルとは対照的に)コンポーネントレベルでメトリックを計算できることにより、メトリック生成モジュールは、グラフレベルのメトリックからはマスクされ又は容易に明らかでない場合があるコンポーネントレベルのエラー及びレイテンシの問題を識別できるようにする。コンポーネントごとに監査レコードを(専用監査ポートによって)受信することは、メトリック生成モジュールがそれらのコンポーネント固有メトリックを生成することを可能にする。例えば監査レコードがグラフ全体にわたってしか生成されない場合、レイテンシメトリックはグラフ全体のレイテンシを示すに過ぎない。この例では、5ミリ秒未満のレイテンシメトリックを有するグラフを許容可能と見なす。この例では、コンポーネント78aを実行しているグラフの平均レイテンシ時間が4ミリ秒である。そのためグラフが許容可能な性能を有するとシステムは判定する。しかし、メトリック生成モジュールがコンポーネント78a自体の平均レイテンシ時間を計算する場合、そのレイテンシ時間は15ミリ秒である。コンポーネント78aの実行と比較してほぼリアルタイムで監査レコードを生成する専用監査ポートをシステムのそれぞれの上で実行されるコンポーネント78aのそれぞれが有し、それらの監査レコードが監査ログモジュールによって収集され、次いで粒度の細かいリアルタイムのメトリックを生成するためにメトリック生成モジュールによって処理されるので、メトリック生成モジュールは(複数の異なるシステムにわたってコンポーネント78aを実行することに基づく)この平均レイテンシ時間を計算することができる。個々のコンポーネントについてリアルタイムのメトリックを集約レベルで生成するメトリック生成モジュールの能力により、システムは個々のコンポーネントのレイテンシ又は性能の問題を識別し、(例えばそのコンポーネントを表す実行可能ロジックを修正することによって)それらのレイテンシの問題に対処し或いはかかる問題を修復し、それにより個々のコンポーネントの性能の問題を識別しない場合のグラフ実行のレイテンシと比較してグラフ実行のレイテンシを減らし、システム全体の性能を改善することができる。
この例では、処理システム62がログデータの出力を記憶するためのデータストア88aを含む。この例では、処理システム62がデータ項目を処理するための実行可能ロジック(例えばデータフローグラフ又はチャートのための実行可能ロジック)を記憶するメモリ62a(図4A)を含む。(データフローグラフ66aによって表す)実行可能ロジックの(例えばコンポーネント82aによって表す)第1の部分は、データストア88aにログデータを出力するための第1の専用出力ポート(例えば出力ポート82c)を含み、第1の専用出力ポートは実行可能ロジックの第1の部分によるデータ項目の処理を示すログデータを出力する。この例では、実行可能ロジックの(例えばコンポーネント80aによって表す)第2の部分がデータストア88aにログデータを出力するための第2の専用出力ポート(例えば出力ポート80c)を含み、第2の専用出力ポートは実行可能ロジックの第2の部分によるデータ項目の処理を示すログデータを出力する。この例ではシステム62は、受信されるデータ項目の最初のものについて、実行可能ロジックの第1の部分を用いてその第1のデータ項目を処理する実行システム62b(図4A)を含む。この例では、データ項目を処理するための第2の処理システム(例えばシステム64)が環境14内に含まれる。第2の処理システムは、データ項目を処理するための(データフローグラフ66bによって表す)実行可能ロジックを記憶するデータストア88b及びメモリ(例えば図4A内の64a)を含む。第2の処理システム内の実行システム(例えば図4A内の実行システム64b)は実行可能ロジックを実行し、データストア内に記憶されるログデータをもたらすように構成される。モニタリングシステム(例えば性能モニタリングモジュール18)は、第1の処理システム62のデータストア88aから記憶済みのログデータを得る、取得する、又は受信するための、及び第2の処理システム64のデータストア88bから第2の処理システムに由来するログデータを得る、取得する、又は受信するための入力ポート(例えば監査ログモジュール24上の入力ポート24a)を含む。
第1の処理システム62及び第2の処理システム64のそれぞれについて、個々の実行システム(例えば図4A内の62b、64bのそれぞれ)又は実行可能ロジックが複数の受信済みのデータ項目を分割し、それによりデータ項目の2つ以上が実行可能ロジックの分割コンポーネント(例えばコンポーネント74a又は74b)に割り当てられ、各分割コンポーネントは出力ポート(例えば74c、74d)及び入力ポート(例えば74e、74fのそれぞれ)を含み、実行システムは、分割コンポーネントごとに及び分割コンポーネントの入力ポートにおいて受信されるデータ項目ごとに、その分割コンポーネントに割り当てられるそのデータ項目を処理すること、及び分割コンポーネントによるそのデータ項目の処理を指定するログデータを分割コンポーネントの出力ポート上で出力することを含む操作を実行し、その処理システムのためのデータストアはその処理システムのための分割コンポーネントの出力ポートから出力されるログデータを受信する。この例では、モニタリングシステム18が第1の処理システム62及び第2の処理システム64の個々のデータストア88a、88bから出力されるログデータを受信し、受信されるログデータは第1の処理システム62及び第2の処理システム64の個々の分割コンポーネント74a、74bの個々の出力ポート74c、74dから出力される。
図4Cを参照し、環境100は監査ログモジュール24内に含まれるコンポーネントを示す。この例では監査ログモジュール24が、ソースデータリーダ、複数のソースデータリーダ、及び/又はデータベース(例えば図4B内のデータストア88a)をサブスクライブする(例えばそこからデータを得る、取得する、又は受信する)サブスクライブコンポーネント104を含む。サブスクライブコンポーネント104は監査ログレコードを受信するためのポート104aを含む。監査ログモジュール24は、ソースデータリーダ、複数のソースデータリーダ、及び/又はデータベース(例えば図4B内のデータストア88b)をサブスクライブする(例えばそこからデータを受信する)サブスクライブコンポーネント106も含む。サブスクライブコンポーネント106は監査レコードを受信するためのポート106aを含む。この例では、監査ログモジュール24が結合コンポーネント112及び分類器コンポーネント116も含む。
この例では、サブスクライブコンポーネント104が監査レコード101a~101dに(例えば図4B内のデータストア88aから)リアルタイムでアクセスする。サブスクライブコンポーネント104は(例えば全てのフィールドの値が指定の形式にあることを確実にするために)監査レコード101a~101dの幾らかのフォーマッティングを行うことができ、又は(例えば別のデータストア(不図示)にアクセスし、監査レコード内で指定される特定の加入者について取得データを追加する、及びその取得データを拡張として監査レコードに追加することによって)幾らかの拡張データを追加することができる。サブスクライブコンポーネント104は、監査レコード108a~108dを結合コンポーネント112に出力する。監査レコード108a~108dは、監査レコード101a~101dと同じとすることができ、又は例えば監査レコード101a~101dの1つ又は複数が再フォーマットされ及び/又は拡張される場合は異なる場合がある。
この例では、サブスクライブコンポーネント106が監査レコード102a~102dに(例えば図4B内のデータストア88bから)リアルタイムでアクセスする。サブスクライブコンポーネント106は(例えば全てのフィールドの値が指定の形式にあることを確実にするために)監査レコード102a~102dの幾らかのフォーマッティングを行うことができ、又は(例えば別のデータストア(不図示)にアクセスし、監査レコード内で指定される特定の加入者について取得データを追加する、及びその取得データを拡張として監査レコードに追加することによって)幾らかの拡張データを追加することができる。サブスクライブコンポーネント106は、監査レコード110a~110dを結合コンポーネント112に出力する。監査レコード110a~110dは、監査レコード102a~102dと同じとすることができ、又は例えば監査レコード102a~102dの1つ又は複数が再フォーマットされ及び/又は拡張される場合は異なる場合がある。
結合コンポーネント112は、監査レコード108a~108dを監査レコード110a~110dと1時間ごと等の指定の時間間隔において結合する。一部の例では、コンテンツをマージし結合済みの監査レコード114を作成することによって監査レコード108a~108dが監査レコード110a~110dと結合される。他の例では、監査レコード108a~108dが監査レコード110a~110dとキーによって結合される。例えば監査レコードの1つ又は複数が特定のキー値及びそのキーに関連するフィールドを含む場合、そのキーに関する監査レコードをもたらすためにその特定のキー値に関する監査レコード(又は監査レコード内に含まれるフィールド)を結合する。結合コンポーネント112は結合済みの監査レコードを分類器コンポーネント116に出力し、分類器コンポーネント116は例えばキーによって決定される監査レコードの種類ごとに監査レコードを分類する。この例では、分類器116が3つの異なるレコードの種類116a~116cを識別し、それらはソートコンポーネント117によってソート(例えば時間ソート)される。ソートされ分類された監査レコードがデータストア40に出力され、データストア40(例えばRAM)内に記憶される。
図5Aを参照し、監査レコードの分類済みの一例を示す。この例では、(図4C内の分類器116と同じでも異なってもよい)分類器24aが様々な監査レコードをキー値によって分類する。この例では、監査レコード101a、102cが「Ops」の同じキー値をそれぞれ有し、従って「オペレーション分類」の特定のレコードの種類に分類される。監査レコード101b、102bは「履行」の同じキー値をそれぞれ有し、従って「履行」分類の特定のレコードの種類に分類される。監査レコード101d、102aは「消費者」の同じキー値をそれぞれ有し、従って「消費者」分類の特定のレコードの種類に分類される。図5Bを参照し、レコードの種類116a、116b、116cのそれぞれがソートコンポーネント117によってソートされている。この例では、監査レコード101a、102cがレコードの種類116a内に含まれる。監査レコード101b、102bはレコードの種類116b内に含まれる。監査レコード101d、102aはレコードの種類116c内に含まれる。この例では、ソートコンポーネント117がタイムスタンプによってソートするように構成される。そのため、オペレーション分類内の監査レコード102c、101aはタイムスタンプによってソートされる。履行分類内の監査レコード101b、102bはタイムスタンプによってソートされる。消費者分類内の監査レコード102a、101dはタイムスタンプによってソートされる。監査ログモジュール24は、ソート済みの監査ログを記憶するためにデータシンク40に出力する。それを受けてメトリック生成モジュール25は、例えば特定のユーザに関する、特定の期間にわたる、特定のキー等に関するメトリックを生成するためにデータシンクをクエリすることができる。この例では、メトリック生成モジュールがメトリック103を生成する。
改変形態では、監査ログモジュール24が、ログレコードを受信するための単一の入力ポート、例えば104aを有する単一のサブスクライブコンポーネントを含み得る。以下でより詳細に説明するように、図4A~図4Dは(参照によりその全内容を本明細書に援用する米国特許出願公開第2017-0344672号明細書に記載の)フローチャートによる経過を示し、フローチャートの様々な状態において様々なノードが実行されることを示す。図6A~図6Dは、様々な状態において生成される様々な監査レコードを示す。
図6Aを参照し、図129aはシステム62を示す、データ処理コンポーネントを表すノード132a~132gを有する(仕様130によって指定される)フローチャート132実行する。この例では、ノード132a、132c、132eのそれぞれが、個々のノードの実行に関係するデータ(例えばメタデータ)を含む1つ又は複数の監査レコードを出力するための監査ポート132j、132k、132qをそれぞれ有する。この例では、仕様が実行可能ロジックを表し様々な状態を指定し、仕様の状態は、前のデータ項目に対して実行可能ロジックを実行することによって到達する状態に基づく、その状態において実行可能な実行可能ロジックの1つ又は複数の部分を指定する。この例では、データ処理コンポーネントの1つ又は複数が実行可能ロジックの特定のグループ又は部分を指す。概して、チャートはデータレコードを処理するためのテンプレートを含む。このテンプレートは、入力データレコードに反応して出力データレコード、例えば仕様に含まれるロジックに基づいて生成されるデータレコードを作成するためのロジックのグラフィックユニットを含む。チャートは仕様の一例である。概して、ロジックのグラフィックユニットは、例えばテンプレート(不図示)からチャートを構築するためのウィンドウに様々なノードをドラッグアンドドロップすることによって少なくとも部分的にグラフィカルに生成されるロジックを含む。一例ではノードが、入力データレコードをどのように処理するのか、実行可能ロジックによって使用される変数の値をどのように設定するのか、例えばロジックによって指定される条件を満たしたときどの出力データレコードを生成するのか等を指定するロジック(不図示)を含む。一例では、ノードのロジック内で使用されるパラメータ及び/又は変数の値をユーザが入力することによってノードがプログラム可能である。
ノード内のロジックが実行可能ロジックにコンパイルされ、各ノードがその実行可能ロジックの1つ又は複数の部分に対応するときチャート自体が実行可能である。例えばシステムは、ノード内のロジックを実行可能ロジックにコンパイルすることによって仕様(及び/又は仕様内のチャート)を変換する。チャート自体が実行可能なので、チャート自体がデータレコードを処理することができ、チャート自体を停止、開始、及び一時停止することができる。システムは、例えばノード132a~132gのどれが目下実行されているのかを追跡することによってフローチャート132の状態も保つ。フローチャート132の状態は、フローチャート132によって表される実行可能ロジックの状態に対応する。例えばフローチャート132内の各ノードは、実行可能ロジックの特定の状態を表す(実行可能ロジックの1つ又は複数の部分がその状態において実行可能である)。以下でより詳細に説明するように、フローチャート132が様々なキー値について実行されている場合、システムは例えばインスタンスごとに状態を保つことによりキー値ごとにフローチャート132の状態を保つ。概して仕様のインスタンスは、例えば仕様内で表される実行可能ロジックを実行し実行可能ロジックの状態を固有のキー値ごとに保つことによる、固有のキー値に関する仕様の具体的実現を含む。この例では、フローチャート132が状態遷移図を含み、各入力データレコードがノード間の遷移を駆動し、データレコードは前のデータレコードを処理することによって到達する状態に基づいて評価される。フローチャート132内のノード間のリンクは時間的なロジックフローを表す。
仕様130はキー132hも含み、キー132hはフローチャート132がキー132hを含む又はキー132hに関連するデータレコードを処理することを識別する。この例ではカスタム識別子(ID)がキーとして使用されている。キー132hは、例えばsubscriber_IDフィールド、customer_IDフィールド、session_IDフィールド等のデータレコードのフィールドの1つに対応し得る。この例では、customer_IDフィールドがキーフィールドである。特定のデータレコードについて、システムはそのデータレコードのキーフィールドの値を識別することによってそのデータレコードのキー値を決定する。改変形態では、仕様がキーに関連しなくてもよく、フローチャートがキーと独立に実行され得る。
この例では、フローチャート132が(例えば指定の種類のものであり、フローチャート232の構成時に指定される)データレコードをサブスクライブする。この例では、フローチャート132がキー32hを含むデータレコードをサブスクライブする。この例では、フローチャート132及びデータレコードがキーを共有する。概してフローチャートは、フローチャートのキーを含むデータレコードを処理するためのロジックを含むことにより、それらのデータレコードの種類をサブスクライブする。データレコードの処理が始まると、システムは例えば新たなキー値ごとに(フローチャート内で表される)実行可能ロジックの状態を保つことにより、そのフローチャートに関する新たなキー値ごとの新たなフローチャートのインスタンスを開始する。概してフローチャートのインスタンスは、例えば仕様内で表される実行可能ロジックを実行し実行可能ロジックの状態を固有のキー値ごとに保つことによる、固有のキー値に関するフローチャートの具体的実現を含む。システムは、特定のキー値についてデータレコードに応答するようにフローチャートのインスタンス(従って基礎を成す実行可能ロジック)を構成することによってデータレコードの処理を行う。一例では、フローチャートが顧客のショートメッセージサービス(SMS)データレコードをサブスクライブする。特定の顧客IDのためのフローチャートのインスタンスが、その顧客に関するデータレコードを管理する。入力データレコード内で遭遇する顧客IDと同じだけのフローチャートのインスタンスがあり得る。
この例では、図129aがフローチャート132の実行の開始を示す。この例では、ノード132aが実行可能ロジックの開始を表し、(例えばノードa32aを囲む太線によって示すように)目下実行されている。この例では、フローチャート132はノード132aが実行されている状態にある。
この例では、開始ノード132aの実行時に監査レコード132iが生成される。この例で示すように、具体的には開始ノード132aは、例えば開始ノード132aが実行されている状態にフローチャート132がある場合に監査レコード132iを監査ポート132j上で生成するように構成されるデータ処理コンポーネントを表す。この例では、監査レコードを生成すると、システムは仕様によって表される実行可能ロジックのどの部分が特定のキー値について現時点において実行されているのかを指定するデータを用いて監査レコードのフィールドにデータ投入する。この例では監査レコード132iが、(フローチャート132によって目下処理されているレコードのキー値を指定する「32425」の値を有する)キーフィールド、(フローチャート132の識別子を指定する「42424」の値を用いてデータ投入されている)chart_IDフィールド、及び(ノード132aを表す「開始」の値を用いてデータ投入されている)コンポーネント(「Comp」)フィールドの3つのフィールドを有する。この例では、監査レコード132iが監査レコードを収集するデータストア134に監査ポート132j上で出力される。指定の時間間隔において(例えば1時間ごとに)、データストア134は収集した監査レコードを監査ログモジュール24(図4B)に伝送するように構成される。
更に他の例では、仕様がチャートであり、1つ又は複数のログレコードが、特定のキー値に関連する1つ又は複数のデータレコードを処理する際に実行可能ロジックのどの部分が実行されるのかを表すチャートを通る経路を指定する。この例ではシステムが、特定のキー値に関連する1つ又は複数のデータレコードを処理する際に実行可能ロジックのどの部分が実行されるのかを表すチャートを通る経路を指定するログレコードを生成する。更に他の例では、システムが1つ又はデータ項目を処理することに基づいて1つ又は複数の出力レコードを生成する。この例では、1つ又は複数の出力レコードのそれぞれがログレコード内に含まれないデータを含む。
様々な種類の監査レコードが様々なフィールドと共に予め定められ、それぞれのフィールドの種類はデータレコード又はイベントを処理することの1つ又は複数の属性を指定する。概してイベントは、特定の発生又は発生の欠如を表す(例えば既定の形式の)データレコードを含む。この例では、ノード132aは例えばノード132a上でクリックすることによって編集可能であり、そのようにクリックすることはノードを構成する際に、そのため更にはノードによって表されるデータ処理コンポーネントを構成する際に使用することができる構成画面を表示させる。構成の一部は、監査(又は「ロギング」とも呼ぶ)をオンにすること、及びそのノードの横断時に生成される監査レコードの1つ又は複数の種類を指定することを含み得る。別の例では、本明細書に記載のシステムが、様々な種類の監査レコードの視覚的表現を表示する及び様々な種類の監査レコードをオン/オフするためのコントロールを提供するユーザインタフェース用のデータを生成する。この例では、システムは特定の種類のノード又はデータ処理コンポーネントに対応する又は関連する種類の監査レコードを(例えばその種類の監査レコードのロギングが有効にされている場合)生成する。例えば監査レコード132iは、チャートの開始を指定するデータをロギングするためのチャート開始監査レコードである。そのためチャート開始監査レコードが有効だとユーザが指定する場合、本明細書に記載のシステムは開始ノードがチャートを開始しチャート開始監査レコードがチャートの開始をログすることに基づいてチャート開始監査レコードと開始ノード(例えばノード132a)との間の対応を識別し、チャート開始監査レコードを生成する。
図6Bを参照し、図129fはノード132aの完了後のフローチャート132の状態を示す。この例では、フローチャート132の状態が実行可能ロジックの1つ又は複数の他の部分を表すノード132bに遷移する。ノード132bは待機ノード(以下、待機ノード132b)を含む。待機ノード132bは、1つ又は複数の条件を満たす入力データレコードを(待機ノード132bに対応する)実行可能ロジックの一部が待つ待機状態を表す。一例では、待機状態はフローチャート32の別の状態、例えばシステムが(待機状態を実装するために)待機ノードを実行し、次いで1つ又は複数の他のノードを実行する状態の一部であり得る。待機ノード132bによって表される実行可能ロジックの一部の完了後、システムは待機状態を抜け、決定を下すための実行可能ロジックを表すノード132cを実行する。この例では、ノード132cが決定ノードを含む。以下、ノード132cを決定ノード132cと呼ぶ。概して、決定ノードは決定を実行するためのロジック(例えばブール値について評価するロジック)を含むノードを含む。
フローチャート132のこの第2の状態では、監査レコード132rが(例えば図1内の実行モジュール16によって)生成され、ノード132cの監査ポート132k上でデータストア134に出力され、データストア134は監査レコード132rを収集し記憶する。具体的には、決定ノード132cによって表されるデータ処理コンポーネントは、この例で示すように例えば決定ノード132cが実行されている状態にフローチャート132がある場合に監査レコード132rを生成するように構成される。(この例では待機ノード132bもこの状態で実行されている。しかし待機ノード132bは監査レコードを生成するように構成されていない。)
この例では、例えばはいのリンク132lが横断されているか又はいいえのリンク132mが横断されているかを指定することにより、監査レコード132rが決定ノード132cの結果を指定する。この例では、はいのリンク132lが横断されていることを指定するデータを「Var決定」の変数内に監査レコード132が記憶する。改変形態では、例えば決定ノード132cによって表されるデータ処理コンポーネントの実行時に、読み出され又は設定される変数を監査レコードが指定することもできる。この例では監査レコード132rがキーフィールドを含む必要がなく、それは監査レコード132rが指定のパルス(例えば時間又は既定の時間間隔)において処理システム(例えば監査レコードを処理する内部の又は外部の計算システム)に伝送され、監査レコードがグループ、ブロック内で、又はファイルの一部として伝送されることをもたらすからである。
例えばシステムは監査レコードをキーごとにまとめ、第1のキーに関連する第1の監査レコードは第1のグループにまとめられ、第2のキーに関連する第2の監査レコードは第2のグループにまとめられる。この例では、監査レコードがシステム(例えば図1内のシステム14)のメモリ内にまとめられる。システムはスペース効率を得るために監査レコードをメモリ内にまとめ、そのためシステムは、例えば各監査レコード内にキーを含めることで逐次的に関係する監査レコードにわたってデータを複製する必要がない。各監査レコードは、データ項目を処理することの1つ又は複数の属性を示す1つ又は複数のフィールドを含む。少なくとも1つの監査レコードについて、フィールドはデータ項目に関連するキーの値を指定するキーフィールドである。監査レコードがキーごとにまとめられるので、特定のキーに関連する監査レコードのサブセットはキーフィールドを含まない。一部の例では、特定のキーに関するグループ内に含まれる監査レコードの1つだけがキーフィールドを含む。この例では、システムが特定のキーに関連する特定のグループ内の監査レコードを既定の時間間隔(例えばパルス)の終わりにファイルに書き込む。
例えばシステムは、第1の監査レコード又はチャート開始監査レコードのコンテンツを構文解析することによって(ブロック又はファイルとして表され得る)グループ内の監査レコードのためのキーを識別する。全ての監査レコードがキーフィールド(及び監査レコード132iと同じパルス内に含まれる他の監査レコードによってチャート開始監査レコード内で同じく探索され得るchart_IDフィールド等の他のフィールド)を含む必要はないので、本明細書に記載のシステムは、イベントのキー付きロギングを有効にするために各監査レコードがキーフィールドを含まなければならない場合のシステム資源に対する影響と比較し、システム資源(メモリ及び処理能力等)に対する最小限の影響を伴って監査レコードを処理することができる。加えて、各監査レコードがキーフィールドを含む必要がないことで監査レコードのサイズが小さくなるので、本明細書に記載のシステムはそれぞれがキーフィールドを有する監査レコードを処理するレイテンシと比較し、レイテンシを減らしながらこれらの監査レコードを処理する。加えて本システムは特定のキーに割り当てられる(メモリ内の)パーティション内に監査レコードを記憶するように構成され、各監査レコードがキーフィールドを含む必要性を更に減らす。新たなパルスの開始時に、本明細書に記載のシステムはそのパルスのその最初の監査レコード内にキーフィールドを含めるように構成される。
図6Cを参照し、図129fはノード132cによって表される決定の結果に基づくフローチャート132の状態を示す。具体的には、ノード132cによって表される決定の結果に基づき、フローチャート132の状態が別の待機ノードであるノード132dに遷移する。(改変形態ではフローチャート132の状態は(ノード132aに状態を再び遷移させる)ノード132gに遷移することができる)。待機ノード132dによって表される実行可能ロジックの一部の完了後、フローチャート132の状態が送信ノードを含むノード132eに遷移する。概して、送信ノードは別のシステムへのデータ伝送を引き起こすための実行可能ロジックを表すノードを含む。ノード312eによって表される実行可能ロジックの一部を実行し終えた後、フローチャート32の状態は完了ノードを含むノード132fに遷移する。概して、完了ノードは実行可能ロジックの実行が完了したことを表す。
フローチャート132のこの第3の状態において、例えば送信コンポーネント132eによって表される実行可能ロジックによって監査レコード132sが生成される。この例では、監査レコード132sは送信ノード132eによって表されるデータ処理コンポーネントによって実装されたアクションを指定する。監査レコード132sは送信コンポーネント132eの監査ポート132q上で出力され、データストア134によって収集される。この例では、監査レコード132sが変数(「Varアクション」)を含み、その値は送信コンポーネント132eによって開始されるアクションを指定する。この例では、送信コンポーネント132eがSMSサービスを更新するためのオファーを送信するアクションを開始する。そのため「Varアクション」の値が「SMS更新のオファー」に設定される。監査レコード132r、132sが監査レコード132gを含む同じパルスの一部として伝送されるので、監査レコード132g及び132rと同様に監査レコード132sもキーフィールドを含む必要がない。監査レコードの他のものはアクションが送信された時間、読み出された変数の値、設定された変数の値等を指定することができる。この例では、データストア134が監査レコード132i、132r、132sを収集し及び伝送する、次いで例えば本明細書に記載の技法を用いた更なる処理のために(例えば指定の時間において)性能モニタリングモジュールに。
図6Dを参照し、図140はシステム64が(仕様141によって指定される)チャート144を実行することを示し、ノード140a~140gはデータ処理コンポーネントを表す。この例では仕様141がキーと独立しており、特定のキーに関連するデータレコードだけを処理するわけではない。この例では、ノード140a、140b、140c、140eが監査レコードを出力するための監査ポート140j、140k、140l、140mをそれぞれ含む。この例では、チャート144の実行が開始されるとノード140aが実行され、ノード140aの実行は「53422」及び「開始」の値をそれぞれ有する「chart_ID」フィールド及び「Var Comp」フィールドを指定する監査レコード140nを監査ポート140j上で出力する。この例では、データストア142が監査レコード140nを受信し記憶する。次いでチャート144はノード140bに進み、ノード140bの実行はアップグレードするためのオファーをシステムのユーザに送信する(例えば電話サービス)。ノード140bが実行されると(例えばノード140bによって表される実行可能ロジックが実行されると)、システムは出力ポート140k上で出力されデータストア142に伝送される監査レコード140oを生成する。
ノード140bの実行後にノード140cが実行される。ノード140cは決定ノードである。決定ノード140cの実行は「はい」のリンク140rが横断されることをもたらし、ひいては監査レコード140pをシステムに生成させる。この例では、監査レコード140は「Var決定」と名付けられた変数の値を記憶する。「Var決定」変数は、ノード140cの「はい」のリンクが横断されたのか「いいえ」のリンクが横断されたのかを指定する。この例でははいのリンクが横断されたので、「Var決定」変数の値が「はい」に設定される。監査レコード140pが監査ポート140l上で出力される。データストア142が監査レコード140pを収集し、それを記憶する。
ノード140cの実行後にチャート144はノード140d~140fを実行する。この例では、ノード140eの実行が、140mの部分上で出力される監査レコード140qを生成する。この例では、監査レコード140qは、ノード140eによって表される実行可能ロジックの実行によりどのアクションが実行され又は開始されたのかを指定する変数(即ち「Varアクション」変数)の値を記憶する。この例では、「Varアクション」変数の値は、SMSサービスを更新するためのオファーがユーザに送信されたことを指定するための「SMS更新のオファー」である。データストア142がデータレコード140qを収集する。指定の時間において、データストア142は監査レコード140n、140o、140p、140qを一括し、それらを監査ログモジュールに伝送する。
図6Eを参照し、環境150は環境100の改変形態である。この例では、サブスクライブコンポーネント104がデータストア134から監査レコード132i、132r、132sを読み出し、それらを結合コンポーネント112に伝送する。サブスクライブコンポーネント104はデータストア142から監査レコード140n~140qを読み出し、それらを結合コンポーネント112に伝送する。この例では、結合コンポーネント112は監査レコード132i、132r、132s及び監査レコード140n~140qのコンテンツを結合済みの監査レコード152へと結合する。結合コンポーネント112は結合済みの監査レコード152をロールアップコンポーネント116に出力し、ロールアップコンポーネント116は結合済みの監査レコード152内の1つ又は複数の個々のフィールドの1つ又は複数の値に対してロールアップ操作を実行してロールアップ済みのレコード154を生成する。この例では、ロールアップ済みのレコード154が集約フィールド、即ち「Count SMS更新のオファー」を含む。このフィールドは「SMS更新のオファー」の値を有する変数の数を指定する。この例では、結合済みのレコード152が「SMS更新のオファー」の値を有する(どちらも「Varアクション」と名付けられた)2つの変数を含む。そのため、集約フィールド「Count SMS更新のオファー」の値は「2」である。ロールアップコンポーネント116は、本明細書に記載の更なる処理のために、例えばメトリックを生成するためにロールアップ済みのレコード154をデータストア40に伝送する。
図7を参照し、環境160は監査ロギングのためのアーキテクチャを示す。環境160は、データレコード(及び/又は他の構造化データ項目)を処理するように構成される実行モジュール164を有するシステム162(例えばデータ処理システム)を含む。この例では、実行モジュール164が規則セットログ168、チャート選択モジュール170、及びチャート172を含む。システム162は、監査ログモジュール166及びメトリック生成モジュール167も含む。この例では、規則セットログ168がログ(例えばどの規則が実行されるのか、その規則が何時実行されるのか、パラメータの値、及び/又は実行中に設定される値等を示すロギングデータ又は規則ケーストレース情報(本明細書ではトレーシング情報とも呼ぶ))を含み、参照によりその全内容を本明細書に援用する米国特許第7,877,350号明細書に記載のビジネス規則環境(BRE)内の規則の生成された実行。参照番号198によって示すように、規則セットログ168から出力されるこのロギング情報はデータストア174内に入力される。この例では、(例えばチャート決定ブロック内ではなく規則セットによって処理したビジネスロジックに対処するために)実行モジュール164がビジネス規則環境から規則ケーストレース情報を収集してその情報を監査レコード内に任意選択的に含める。一例では、グラフコンポーネント上のポートに自らのログを書き込み、そのログをポートからファイルに書き込むことによってBREがロギングデータストリームを実装する。この例では、実行モジュール164が現在のイベントに関する監査レコード(及び他の監査情報)を収集しているイベントエンジンの内部データ構造の中にトレーシング情報を記憶する関数呼び出しでBRE内のトレーシング情報を書き出す関数呼び出しを置換することにより、実行モジュール164がそのロギングデータストリームをインタセプトする。一部の例では、BREが使用しているロギング関数(例えばwrite_to_log)の代替的実装を提供することにより、実行モジュール164がロギングデータストリームをインタセプトする。他の例では、様々な関数を使用するための選択肢をBREがサポートする。
この例では、チャート選択モジュール170が、1つ又は複数のデータフローグラフ(例えばチャート172の1つ)を実行するように構成され、又は実行モジュール164内に含まれる様々なシステム上で実行されるチャート若しくはデータフローグラフを選択するように構成される。この例では、チャート172がデータフローグラフ66a、66b(図4B)、及びチャート132(図6A)、144(図6D)を含む。この例では、チャート選択モジュール170が図4Bに示すシステム62、64のそれぞれの上で実行するためのデータフローグラフ66a、66b(図4B)をチャート172から選択する。異なる前の時点又は後の時点において、チャート選択モジュール170は更に図5A~図5Dに示すシステム62、64のそれぞれの上で実行するためのチャート132、144(図6A~図6D)をチャート172から選択する。この例ではチャート132、144(図6A~図6D)の選択が図示されており、システム62、64のそれぞれの上でのそれらのチャート132、144(図6A~図6D)の実行が図示されている。この例では、参照番号196、197のそれぞれによって示すようにシステム62、64の出力(例えばログレコード)がデータストア174に伝送される。
この例では、チャート172の1つが、クラスタメトリックを生成しそれらをデータベース173内のファイル内に直接書き込むイベントエンジングラフである。概して、イベントエンジングラフは実行モジュール144の性能をモニタするためのグラフである。概してクラスタメトリックは性能の詳細、例えばデータフローグラフのどの部分が横断されるのかを示すメトリック及びデータフローグラフの一定の部分がレコード群によって横断される回数を示す集約メトリック等、システム及び/又は実行モジュール164の集約レベルにおける詳細を指す。一部の例では、このファイルが全てのパルス(例えばデータプッシュ)上で(例えば過去に記憶された他のファイル又は更新される)付加され、新たなファイルが毎日開かれる。
この例では、(例えばチャートを実行するチャート選択モジュール170の実行に基づいて)チャート選択モジュール170から別のデータ経路が生じる。チャートが実行されるとき、チャート選択モジュール170はチャートによってたどられる経路、例えば終了した待機ブロック、横断したフロー、及び送信されたアクション等を記録する監査レコードのストリームを生成する。この例では監査レコードが、監査ファイル内(即ちデータベース174内)に記憶されるログ済み活動、又はデータベース175内に記憶されるインデックス付き圧縮フラットファイル(ICFF)内に記憶されるログ済み活動を含む。概して、監査ファイルは様々な監査レコードを記憶するためのファイルを含む。この例では、監査レコードが全てのパルスの終わりにファイルに書き込まれる。この例では、データベース174がパルスごとに1つの新たなファイルを受信する。
環境160は、未処理の情報(即ちデータベース174内に記憶される監査ファイル)を処理し、その未処理の情報をICFF用の形式に再フォーマットするグラフを含む監査ファイルプロセッサモジュール176を含む。この例では、データベース174が監査ファイルを再フォーマットのために監査ファイルプロセッサモジュール176に伝送する。それを受けて監査ファイルプロセッサモジュール176は、再フォーマット済みのファイルをデータベース175に伝送し、データベース175は、1つ又は複数のキーフィールド(例えばハッシュ値、対象者ID又はキー)によって(インデックス180内で)インデックス付けされ、時間によって(例えば1時間ごと又は1日ごとに)まとめられるICFFレコード178内に再フォーマット済みのファイルを書き込む。この例では、インデックス180が「ハッシュ値」カラム及び「アドレス」カラムを含む。ハッシュ値カラムは、インデックス付けされているICFFレコード内のキー(又は他のデータ)のハッシュ値を含む。アドレスカラムは、ハッシュ値によって参照されるデータブロックのデータベースアドレスを含む。この例では、ICFFレコード178がデータブロック182を(例えばポインタ又は別の参照データ構造によって)参照する。この例では、未処理の情報の一部がICFFレコード178のために再フォーマットされる(後にインデックス180内でインデックス付けされる)が、未処理の情報の他の部分はデータブロック182内に記憶され、データブロック182はICFFレコード178によって参照され、そのためICFFレコード178によって識別可能且つアクセス可能である。
この例では、監査ログモジュール166が監査レコード132i、132r、132s(図6E)、及び監査レコード140n~140q(図6E)を受信してロールアップ済みのレコード154を作成し、ロールアップ済みのレコード154はロールアップ済みのデータレコード(図6E)内の未処理の情報を処理するために監査ファイルプロセッサモジュール176に伝送される。具体的には、監査ファイルプロセッサモジュール176は、ロールアップ済みのレコード154内の未処理の情報をICFF、例えばICFFレコード178用の形式に再フォーマットする。この例では、ICFFレコード178がキーフィールドとしてchart_IDフィールド(即ち監査レコード132i、140qに由来する)を含む。ICFFレコード178内に含まれない監査レコード132i、132r、132s(図6E)、及び監査レコード140n~140q(図6E)のコンテンツはデータブロック182内に含まれる。システムは、ICFFレコード178及びデータブロック182をデータベース175内に記憶する。この例では、データベース175がインデックス180を記憶し、ICFFレコード178はICFFレコード178内のキー(即ちキー:42424及びキー:53422)のハッシュ値によってインデックス180内でインデックス付けされる。この例では「42424」及び「53422」の値を、インデックス180のロー180a内で示すようにそのハッシュ値が「0110」である「4242453422」の文字列に連結することによってシステム162がキー:42424及びキー:53422のハッシュ値を生成する。インデックス180は、例えば異なる時点における及び/又は異なるチャートを実行することによる、例えば他の監査レコードのための他のICFFレコードをインデックス付けするロー180a~180bも含む。この例ではICFFレコード178が、インデックス180内のロー180a内で示す「0x82829」の値を有するアドレスフィールドによって(矢印183によって概念的に示すように)データブロック182を参照する。改変形態では、ICFFレコード178が参照データ構造(例えばポインタ)によってデータブロック182を参照する。更に別の改変形態では、ICFFレコード178及びデータブロック182が、インデックス付けされるICFFデータブロック(又はデータブロック)へと組み合わせられる。
一部の例では、監査レコードを指定の粒度(例えば1つのチャートに関する1人の加入者の1つのイベント)で一括し、ICFFレコード上で記憶されるキーフィールド(例えばイベントの種類、加入者ID、タイムスタンプ、チャートインスタンスID等のためのフィールド)を計算し、次いで残りの監査レコードを集合にまとめることにより、監査レコード及び/又は監査ファイルが下記の通りICFFのために再フォーマットされる。
一例では、実行モジュール164が(例えばクエリ効率について最適化されているのではなく)スペース効率について最適化された監査レコードを生成する。この例では、例えば全ての監査レコードにtimestamp、subscriber_ID等を含めないことにより、監査レコードがスペース効率について最適化される。これらの監査レコードをICFF内に配置するために、本明細書に記載のシステムは(例えば全ての監査レコードに関するタイムスタンプ及び対象者IDを含む)より完全なレコードを使用する必要があり、それにより本明細書に記載のシステムは(例えば監査レコードのコンテンツに基づく)個々のレコードを効率的に検索することができる。
データベース175を実装する目標はイベントのシーケンスをクエリできるようになることなので、一部の例ではデータベース175がICFFデータベースではなくリレーショナルデータベースを含む。かかるクエリを行うために、システムは監査レコードのストリームを1つ又は複数のレコード(例えばICFFレコード)に変換する。各レコードは、1つ又は複数のインデックス可能/検索可能キーフィールド及び監査イベントの残りの部分を表すデータ集合を含む。
一部の例では、レコードの粒度レベルが、1つのチャートに関する1人の加入者(例えばユーザ)の1つのイベントである。そのため本明細書に記載のシステムは、1つのチャートに関する1人の加入者の1つのイベントに対応する監査レコードのシーケンスを(例えばデータベース174内の監査ファイルから)抽出する。この例、イベントが逐次的に発生する。加えて、イベントごとの監査レコードはデータベース174内に(例えばデータベース174内のファイル内に)逐次的に記憶される。抽出した監査レコードを使用し、システムは例えばイベントの種類フィールド、加入者IDフィールド、タイムスタンプフィールド、チャートインスタンスIDフィールド等を含む複数のキーフィールドを有するレコードを生成する。一部の例では、シーケンス内の第1の監査レコードがそれらの複数のキーフィールドの値を含む。システムは新たなレコードを生成する際にそれらの含まれた値を使用する。加えて、システムはそのシーケンスの残りの監査レコードに対応するデータブロックを構築する。システムは、生成される新たなレコードの一部として又は(例えば生成される新たなレコードにデータ集合又はblobを参照させることにより)生成される新たなレコードに関連して、そのデータブロックをデータ集合として(例えばバイナリラージオブジェクト(BLOB)として)データベース175内に記憶する。
生成されるレコード及び/又はデータ集合を使用し、システムはICFF(又はデータベース175に対して、例えば「加入者12345が6月8日にイベント7を得たとき何が起きたか?」等の様々な情報をクエリし、イベントエンジン内で取られる決定のシーケンス及びそのイベントについての関連する規則セットを表示することができる。別の例では、システムが「加入者12345が6月8日にメッセージを送信したとき何が起きたか?」というクエリでICFF(又はデータベース175)をクエリする。この例では、このクエリに回答するために、メッセージのアクションがトリガされた(又はされなかった)ことを識別するための別のキーフィールドを生成される新たなレコードが含む。そのため、サポートしようとするクエリの範囲に基づき、システムはレコード内にどのキーフィールドを含めるのかを選択する。
この例では、データベース175が未処理のメトリックをICFF内に記憶する。この例では、環境100がメトリックにアクセスするためのインタフェースを有するメトリックデータベース184も含む。システム162は、実行モジュール164内のメモリを読み出すのではなくICFFからの監査レコードを後処理することによってメトリックデータベース184を作成する。ICFF175はパージされないので、様々な集約期間を使用することを含め任意の時点においてメトリックデータベース184を再作成することができる。
従ってメトリック生成モジュール167は、未処理のメトリックを集約し、それらをメトリックデータベース184内に書き込むためのバッチグラフを(例えば10分ごとに)実行するバッチグラフモジュール186を含む。メトリック生成モジュール167は、例えばユーザインタフェース190内に表示するためのメトリック(システム162内で見られる1つ又は複数の状態等)を計算するために「必要に応じて」実行されるメトリック計算モジュール188も含む。この例では、バッチグラフモジュール186がメトリックデータベース184及び/又はデータベース175からのメトリックにアクセスし、(この例では出力データセット192である)アクセスしたそれらのメトリックをユーザインタフェース190内で表示するために処理する。この例では、バッチグラフモジュール186によって生成され又は実行されるグラフが永続的な状態を有さず、メトリックの状態がメトリックデータベース184内で永続する。そのためバッチグラフモジュール186は、ユーザインタフェース190内で表示するためのメトリックをメトリックデータベース184にクエリする。一例では、例えばそのそれぞれを以下に記載するメトリックの動的表示、メトリックに関するレポート、及び調査インタフェースを含む様々な種類のユーザインタフェースが表示される。
メトリックの動的表示では、コンソールがメトリック(例えば集約カウント)を表示し、表示内でそれらのメトリックをほぼリアルタイムで更新する。システムは、このデータ及びメトリックについてメトリックデータベース184をクエリする。この例ではコンソールが、(例えばタイマに基づいて又は指定の時間において)サーバからデータをプルすることしかできないポーリングインタフェースを含むウェブユーザインタフェース(UI)である。そのためUI(例えばウェブページ)は、表示するための更新済みのカウントを求めて断続的にサーバをクエリする。更新済みのカウントはメトリックデータベース184内に記憶される。この例では、例えばブラウザとデータベースとの間に置かれるJavaアプリケーションサーバを含む、UI(ウェブページ)とメトリックデータベース184との間でインタフェースするためのサーバ側ロジックがある。
別の例では、ユーザインタフェース190が、メトリックデータベース184からクエリされるメトリックに関するレポートを表示する。この例では、ユーザがレポート及びダッシュボード内でメトリックを見ることができる。メトリックは、各キャンペーンに参加する人数、(例えばチャートの)各分岐を横断した人数、オファーを得た人数、オファーを受諾した人数等を指定する。ユーザインタフェースは、このレポート内の更なる詳細を「ドリルダウン」するためのコントロールを含む。ドリルダウンするために(例えば「トリガイベントを見たがオファーを得なかったそれらの10人の対象者に何が起きたか」のクエリに回答するために)、システムはデータベース175内のICFF内のレコードにアクセスする。それらのレポートを実装するために、システムはドリルダウンがあるときにメトリックデータベース184及びデータベース175にアクセスすることができるサービス側モジュール(この例ではバッチグラフモジュール186)を実装する。
更に別の例では、「加入者12345が6月8日にイベント7を得たとき何が起きたか?」等の質問をユーザが尋ねることができる調査インタフェースをユーザインタフェース190が含む。これらの質問に回答するために、システムはユーザインタフェース124とデータベース175内のICFFとの間のサーバ側モジュール(例えばJava、グラフ等)を使用して(例えばデータベース175内の)ICFFをクエリする。
実行モジュール164は、データベース175内のICFF内に記憶するための複数の異なる種類の監査レコードを作成する。以下の表1は、様々な種類の監査レコードをその対応するフィールドと共に指定する。以下の監査レコードの種類の一部はロギングのレベルに応じて任意選択的である。この例では、例えば上記で説明したICFFレコードのキーフィールドを生成する際に使用するための、以下の表1に示すフィールドに対応するフィールドの一覧をICFFが記憶する。以下の表1の中でイタリック体で示すフィールドの値は実行モジュール164によって生成されるのではなく、ICFF内にデータが書き込まれるとき監査ストリームを振り返ることによって本明細書に記載のシステムによって推論される。このことは、実行モジュール164が著しく少ないデータを生成しなければならないことを意味する。以下の表1では、「?」カラムは監査レコードが任意選択的かどうかを示す。「+」の記号は、監査レコードが実行モジュール164によって生成されることを意味する。文字は、監査レコードが任意選択的に生成され、1組の関係する制御ポイントによって制御されることを意味し、アスタリスクはレコードの種類がデフォルトで有効にされていることを示す。
一例では、データベース174が監査レコードを(例えばキーによって)対象者ごとに(例えば継続的に又は断続的に)まとめる。つまり監査レコードが対象者又はキーによって自動的にまとめられる。その結果、実行モジュール164は(例えばパルスごとに)監査ファイル内の各監査レコード内でtimestamp、subject_id、又はinstance_idを複製する必要がない。むしろデータベース174は、グループ内のこれらのフィールドの過去に発生した値に基づいてこれらのフィールドの値を得ることができる。この例では、パルス間で状態を保つ必要がない。つまり、例えばブロック開始監査レコードは何パルスも前である可能性があるので、ブロック終了監査レコードはblock_nameを有さなければならない。データベース174内で、監査レコードが上記の表1の中で示した関連フィールドと共に完成する。
一例では、システムがチャートに関する対象者(例えばユーザ又は加入者)のイベントの発生を検出する。そのため、実行モジュール164は「イベント認識」監査レコード、次いで「イベントディスパッチ」監査レコード、次いで「ブロック終了-イベント」監査レコードを生成する。これらの監査レコードから、システム(又は例えば監査ファイルプロセッサモジュール176)はevent_type、timestamp、及びinstance_iのフィールド用の値を得る。この例では、システムがこれらの監査レコードを1つのblob内に集め、認識されたデータから(例えば監査レコードから)(例えばevent_type、timestamp、及びinstance_idの)キーフィールドがシステムによって別のレコード(例えばICFFレコード)内で設定される。
別の例では、チャートに関する対象者についてタイムアウトが発生する。この例では実行モジュール164が、アラームの種類の「イベント認識」監査レコード、次いで「アラームディスパッチ」監査レコード、次いで「ブロック終了-アラーム」監査レコードを生成する。これらの監査レコードから、システムはevent_type、timestamp、及びinstance_idのキーフィールドの値を決定する。この例では、システムはinstance_idフィールドの値を、例えばそのフィールドの値を推論するのではなく、ブロック終了-アラーム監査レコードから決定する。この例では、システムがこれらの監査レコードをblob内に集め、認識されたデータ(例えば監査レコード)からキーフィールド(例えばevent_type、timestamp、及びinstance_id等)がシステムによって設定される。
更に別の例では、チャートを開始するイベントが対象者について発生する。この例では、実行モジュール164が(チャート開始の種類とすることができ又は別の種類のものであり得る)「イベント認識」監査レコード、次いで「イベントディスパッチ」監査レコード、次いで「チャート開始」監査レコードを生成する。これらの監査レコードから、システムはevent_type、timestamp、及びinstance_idのキーフィールドの値を得る。システムは監査レコードをblob内に集め、認識されたデータ(例えば監査レコード)から(event_type、timestamp、instance_id等の)キーフィールドが設定される。
監査レコードはキーごとにまとめられるので、特定のキーに関連する監査レコードのサブセットはキーフィールドを含まない。例えば、データベース174又は又は監査ファイルプロセッサモジュール176は、イベント認識監査レコード、イベントディスパッチ監査レコード、ブロック終了-イベント監査レコードという監査レコードのシーケンスを受信することができる。この例では、データベース174又は又は監査ファイルプロセッサモジュール176がイベント認識監査レコードから対象者のID(例えばキー)を得る。そのため、実行モジュール164はイベントディスパッチ監査レコード及びブロック終了監査レコード内でキーを複製する必要がなく、それはこれらの監査レコードがイベント認識監査レコードの後にメモリ内で(例えばデータベース174又は他のシステムメモリ内で)シーケンシャルになるからである。同様に、イベントディスパッチ監査レコードはインスタンスIDフィールドを含む。そのためイベントエンジンは、ブロック終了監査レコード内にこのフィールドを含めるの複製する必要がない。システムが監査レコードメモリ(及びディスク上の)をまとめるので、システムはグループ内の全ての監査レコードにわたってキーを複製する必要がなく、それによりシステム資源をコンバースし、メモリ消費量を減らす。
過度なデータ量の生成を回避するために、ユーザはイベントエンジンが監査レコードを生成するとき及びどの監査レコードを生成するのかを管理する。監査(従ってメトリック)は完全にオフにすることができるが、監査をオンにする場合、(先の表においてプラスの記号で印付けした)監査レコードのコアセットは無効にされない。監査レコードのコアセットは、イベントエンジンの入力(イベント及びアラーム)、出力(アクション)、エラー、並びにチャート及び待機ブロックの活動を追跡する。概してアラームは、予め計算された将来の時間に到達する(例えばチャートが自らに送信する)既定の種類のデータレコードを含む。他の監査レコードの種類は選択的に有効に及び無効にすることができる。任意選択的な監査レコードを有効にすることについて2つの側面があり、2つの側面とは何を有効にすべきか及びそれを何時有効にすべきかである。何を有効にすべきかについては、選択的に有効/無効にすることができる幾つかの別個の監査レコード群がある。それらは以下を含む:
・A:アラームの設定(デフォルトでオン)
・D:行われた決定(デフォルトでオン)
・P:モニタリングポイント(デフォルトでオン)
・R:規則セットの呼び出し及び規則セットイベント
・S:変数の設定
・V:変数の読み出し
・L:ルックアップアクセス及びルックアップ変数
何時有効にすべきかについては、これらの監査イベントのロギングを全てのものについて有効にすることができ、又は以下の1つ若しくは複数に基づいて限定することができる:
・1組の指定の対象者id(例えばキー)だけ
・1組の指定の命名されたチャート及び/又はモニタリング名だけ
・1組の指定のイベントの種類(例えばレコードの種類)だけ
一例では、実行モジュール164がこれらの監査レコードのロギングを制御ポイントによって構成する。概して制御ポイントは、(チャートを生成している)ユーザによって定められ、1つ又は複数のチャート(又はチャートインスタンス)の実行時における挙動を変更するために使用されるランタイムパラメータを含む。この例では、相互関係のある4つの制御ポイントの組によって監査レコードが(例えばイベントエンジンによって)制御される。5つの制御ポイントは以下の通りである:
・監査の種類-これは上記の表1で示した文字を使用してオンにされる監査レコードの種類のリストである。
・監査エンティティ-これは対象者idのリストである。空白でない場合、イベントエンジンはこのリスト内に含まれる対象者idについてのみ監査の種類リスト内の監査レコードの種類を生成する。(さもなければ全ての対象者idが監査される)。
・監査イベント-これはイベントの種類のリストである(例えば数字はイベントの種類に対応し又はイベントの種類を表す)。空白でない場合、イベントエンジンはこのリスト内に含まれるイベントの種類についてのみ監査の種類リスト内の監査レコードの種類を生成する。(さもなければ全てのイベントが監査される)。例えばSMSメッセージが送信されたことを指定するイベント、ユーザがモバイルプランを新しくしたことを指定するイベント等を含む様々な種類のイベントがある。
・監査チャート-これはチャート名及びモニタリング名のリストである。空白でない場合、イベントエンジンはチャート名又はモニタリング名がこのリスト内に含まれるチャートについて監査の種類内の監査レコードの種類を生成する。(さもなければ全てのチャートが監査される)。
・監査変数-これは変数名のコンマ区切りのリストを含む。空白でなくイベントエンジンが変数(例えば設定される変数又は読み出される変数)に関する監査レコードの種類を生成するように構成される場合、イベントエンジンは変数名がこのリスト内にある場合にのみ監査レコードを生成する。
一部の例では、実行モジュール164が異なる監査レコード群に異なる規則を適用する。この例では、第1の1組の規則(例えば監査の種類1、監査エンティティ1、監査イベント1、監査チャート1、及び監査変数1)を有する第1の監査レコード群(例えば第1の監査グループ)、及び第2の1組の規則(例えば監査の種類2、監査エンティティ2、監査イベント2、監査チャート2、及び監査変数2)を有する第2の監査レコード群(例えば第2の監査グループ)等がある。
この例では、監査の種類、監査エンティティ、監査イベント、監査チャート、及び監査変数のそれぞれが一種のフィルタを含む。これらのフィルタの何れか又は全てが設定される場合、イベントのサブセットだけが追加の監査(例えば任意選択的な形式の監査を含む監査)を有する。
一例では、以下のように第1の監査グループを実装することによってシステムが最小限の監査について構成される:
監査の種類1=“”(任意選択的なものは有効にしない)
監査エンティティ1=“”(全ての対象者ID)
監査イベント1=“”(全てのイベントの種類)
監査チャート1=“”(全てのチャート)
監査変数1=“”(全ての変数だが、任意選択的な変数のロギングをオフにするようにシステムが構成されるのでこれは無視される)
次に別の例では、subject_ID 12345がオファーを送信するための全ての基準を満たしているにも関わらず、この対象者番号へのオファーが送信されない理由を評価するようにシステムが構成される。このオファーを実装するチャートは「My Offer Chart」であり、トリガイベントは6番である。オファーが送信されない理由に関するこの特定の対象者IDについて全ての更に多くの詳細を得るために、システムは以下のように第2の監査グループを用いて構成される:
監査の種類2=“ADPRSVL”(全ての監査の種類を有効にする)
監査エンティティ2=“12345”(この対象者IDだけ)
監査イベント2=“6”(このイベントの種類だけ)
監査チャート2=“My Offer Chart”(このチャートだけ)
監査変数2=“”(全ての変数)
この例では、イベントが発生すると、対象者IDが監査イベント2のリスト内にあるか、及びイベントの種類が監査イベント2のリスト内にあるか、及びチャートが監査チャート2のリスト内にあるかをシステムがまず確認する。これらの属性(例えばフィルタ)の全てが真に評価される場合、システムは監査の種類2内で指定されるように全ての監査レコードの種類を実装し、そのことはそのイベントの持続時間にわたる任意選択的なロギングを開始する。そうではない場合、システムはデフォルトだけをログする監査の種類1を実装する。この例では、システムは高位番号のグループを最初に確認し、一致するグループが見つかるまで後方に進むように構成される。一致するグループが見つからない場合、システムはデフォルトを実装し使用する。改変形態では、更に多くの任意選択的なロギングを追加する、一致する全てのグループのユニオンを取るようにシステムを構成することができる。
この例では、実行モジュール164が(例えばモニタリングポイント監査レコードの実装により)条件監査ロギングを実装し、その実行性能を最適化する。この性能を最適化するために、実行モジュール164は条件付きの監査の決定を行うためのデータ構造を予め計算する(例えば予め生成する)。概して条件付きの監査の決定は、監査レコードが生成されること、条件がどの指定の値(例えば真又は偽)に評価されるのかを指定する。この例では、イベントエンジンがイベント又はアラームに関するイベント処理の開始時に条件付きの監査の計算を行う。例えばイベントエンジンは、イベント又はアラームを検出するたびに(例えば上記の監査グループ内で)計算を行うが、(例えば全ての監査レコードに対してではなく)各イベント又はアラームの処理の開始時にのみ行う。イベントエンジンは、条件付きであり得る監査関数のそれぞれの中の大域変数及びクエリのパッケージ内に条件付きの監査の計算を保存する。
監査レコードの種類ごとに、実行モジュール164はその監査レコードの種類の監査レコードが生成されているかどうかを指定する単一のフラグを実装する。実行モジュール164は単一のフラグを実装する際に監査エンティティ及び監査イベントのリストのコンテンツを分析し、それはイベントの処理が開始するときこれらのリストの両方が指定され又は生成されるからである。1つのイベントが多くのチャートによって処理され得るので、イベントエンジンは監査関数(例えば監査レコードの種類)が実装されているかどうかをチャートごとに判定する。監査チャートが空白でない場合、イベントエンジンは監査チャートのコンテンツを(それぞれチャートを識別する)インスタンスidのリストに変換して、実装されているチャートのid及びどのチャートが監査レコードを生成しているのか(及びどの種類の監査レコードを生成しているのか)を指定するインスタンスid間の比較を単純化する。
一例では、実行モジュール164が(例えば実行モジュール164内の又は実行モジュール164を含むシステム内の)メモリの中のアレイ内の監査レコードを収集し、イベント又はイベントストリームの処理の終了時に監査レコードを1つのブロック内で監査ファイルに書き出す。この例では、様々なイベント(即ち様々なキー又はユーザIDに関連するイベント)の監査レコードがメモリ内で混合されない。むしろメモリはパーティションに分割され、それぞれのパーティションが独自の監査ファイルを有する。そのため実行モジュール164は、監査レコードをキーによって自動的にまとめるように構成される。
この例では、監査ファイルがバージョン付きである。パルスごとに監査ファイルの1つのインスタンスがある。監査ファイルはディスク上に蓄積し、監査ファイル処理グラフ(によって実行される又は監査ファイルプロセッサモジュール176)がパルスの終了時に各監査ファイルを(各パーティションから)入手し、監査レコードを後処理し、それらをICFF内に書き込む。
この例では、例えば実行モジュール164内のメモリから監査レコードを読み出すのではなく、システムが(データベース175内の)ICFFの監査レコードを後処理することによってメトリックデータベース184を生成する。この例ではICFFがパージされない。そのため、様々な集約期間を使用することを含め任意の時点においてメトリックデータベース184を再作成することができる。この例では、メトリックデータベース184内のテーブルがcluster_nameカラムを有し、そのため1つのデータベースを複数のクラスタに使用することができる。概して、クラスタはイベントエンジンのインスタンスを含む。概してイベントエンジンのインスタンスは、固有のキー値に関する1つ又は複数の仕様(実行モジュール164によって1つ又は複数のチャートが実行される)の具体的実現を含む。つまり各対象者IDは、厳密に1つのイベントエンジンのインスタンスによって処理される。そのため固有のキー(例えば対象者ID)ごとに、そのチャートの全てを有する厳密に1つのイベントエンジンのインスタンスがある。同じクラスタに関する監査レコードは、同じcluster_nameの値を有する。
この例では、(例えばイベント認識監査レコードに基づく)実行モジュール164によって処理されるイベントの総数、(例えばエラーディスパッチ監査レコードに基づく)エラーを招いたイベントの数、(例えばアクション送信監査レコードに基づく)キャンペーンをトリガするイベントの数、(例えばブロック開始監査レコードに基づく)どの加入者が特定のキャンペーンの或るステージから別のステージに移るのか、(例えばチャート開始及びチャート完了監査レコードに基づく)特定の日にちにイベントエンジンにおいてキャンセルされ又は追加された加入者の数、(例えばチャート開始監査レコードに基づく)イベントエンジン内で実行されており、イベントエンジンによってイベントが処理されているときの実行モジュール164の状態を追跡する全体的なチャートの数等、実行モジュール164の状態を示すメトリックについてメトリックデータベース184をクエリすることができる。
加えて、(例えば加入者ごとの)特定のキーについてメッセージが送信されなかった理由を指定するデータを取得するためにメトリックデータベース184が(例えばクライアント装置又は本明細書に記載のシステムによって)クエリされ得る。それを行うために、イベントエンジンは(例えばどのコンポーネント及び/又はリンクが実行されるのかを指定する監査レコードを作成することにより)実行モジュール164によってたどられたリンク(及び/又はチャート内で実行されるコンポーネント)及びアクセスされ実装される規則セットの事例をログするように構成される。次いでシステムは、チャートを通る全ての潜在的な経路に対して(例えば監査レコードによって指定される)チャートによってたどられる経路を比較して、(例えば監査レコードによって指定されるように代替経路を横断したためメッセージの送信に対応する経路が横断されなかったという理由で)特定のメッセージが送信されなかった理由を明らかにするように構成することができる。
図8を参照し、トランザクションを表す1つ又は複数のデータレコードを処理するデータフローグラフを実行するためのための1つ又は複数のデータ処理システム(又は処理システム)によってプロセス200が実装され、データフローグラフは複数のコンポーネント及びリンクを含み、コンポーネントは1つ又は複数の入力レコードを処理するために1つ又は複数の入力レコードに適用される計算を表し、入力レコードはトランザクションを表す1つ又は複数のデータレコードへの指定の関係を有し、リンクはコンポーネントを接続しコンポーネント間のデータフローを表す。操作、システムは複数のコンポーネント及びリンクを含むデータフローグラフを実行し実行し(202)、複数のうちの所与のコンポーネントは入力ポート、監査ポート、及び出力ポートを含む。入力ポートは、トランザクションを表す1つ又は複数のデータレコードへの指定の関係を有する1つ又は複数の入力レコードを受信するためのものである。監査ポートは、トランザクションの少なくとも一部を表す監査データを提供するためのものである。出力ポートは、1つ又は複数の出力レコードを提供するためのものである。コンポーネントの少なくとも1つ(例えば図2A内のコンポーネント23e)が所与のコンポーネント(例えば図2A内のコンポーネント23j)の実行よりも前に実行するように構成される。システムは、トランザクションを表す1つ又は複数のデータレコードをコンポーネント及びリンクを有するデータフローグラフによって処理し(204)、コンポーネントの少なくとも1つによって処理される1つ又は複数の入力レコードを指定する状態をコンポーネントの少なくとも1つが保存する。所与のコンポーネントによる1つ又は複数の入力レコードの処理中にエラーが発生した場合、システムはコンポーネントの少なくとも1つの状態を保存済みの状態に回復する(206)。回復した状態に基づいて、システムはデータフローグラフの所与のコンポーネントに関する監査データの少なくとも一部を回復する(208)。システムは、トランザクションの少なくとも一部を表す回復済みの監査データの少なくとも一部を監査ポート上で提供する(210)。システムは、1つ又は複数の出力レコードを出力ポート上で提供する(212)。
上記の技法はコンピュータ上で実行するためのソフトウェアを使用して実装することができる。例えばソフトウェアは、(分散、クライアント/サーバ、又はグリッド等の様々なアーキテクチャのものとすることができる)1つ又は複数のプログラムされた又はプログラム可能なコンピュータシステム上で実行される1つ又は複数のコンピュータプログラムによって手続きを形成し、かかるコンピュータシステムは、少なくとも1個のプロセッサ、少なくとも1つのデータ記憶システム(揮発性及び不揮発性のメモリ及び/又は記憶素子を含む)、少なくとも1つの入力装置又はポート、及び少なくとも1つの出力装置又はポートをそれぞれ含む。ソフトウェアは、例えばチャート及びフローチャートの設計及び構成に関係する他のサービスを提供するより大きいプログラムの1つ又は複数のモジュールを形成し得る。チャートのノード、リンク、及び要素は、コンピュータ可読媒体内に記憶されるデータ構造又はデータリポジトリ内に記憶されるデータモデルに準拠する他の編成済みデータとして実装することができる。
本明細書に記載した技法はデジタル電子回路、又はコンピュータハードウェア、ファームウェア、ソフトウェア、若しくはその組み合わせによって実装することができる。機器はプログラム可能なプロセッサによって実行するために機械可読記憶装置(例えば非一時的機械可読記憶装置、機械可読ハードウェア記憶装置等)の中に有形に具体化され又は記憶されるコンピュータプログラム製品によって実装することができ、方法のアクションは、入力データに作用して出力を生成することによって機能を実行するために命令のプログラムを実行するプログラム可能なプロセッサによって実行され得る。本明細書に記載した実施形態及び特許請求の範囲に記載の他の実施形態並びに本明細書に記載した技法は、データ及び命令をデータ記憶システムとの間でやり取りするために結合される少なくとも1個のプログラム可能なプロセッサと、少なくとも1つの入力装置と、少なくとも1つの出力装置とを含むプログラム可能なシステム上で実行可能な1つ又は複数のコンピュータプログラムによって有利に実装することができる。各コンピュータプログラムは高水準手続き型プログラミング言語若しくはオブジェクト指向プログラミング言語、又は所望の場合はアセンブリ言語若しくは機械言語によって実装することができ、何れにしても言語はコンパイラ型言語又はインタープリタ型言語とすることができる。
コンピュータプログラムを実行するのに適したプロセッサは、汎用マイクロプロセッサ及び専用マイクロプロセッサの両方、並びに任意の種類のデジタルコンピュータの1個又は複数個の任意のプロセッサを例として含む。概して、プロセッサは読取専用メモリ若しくはランダムアクセスメモリ又はその両方から命令及びデータを受信する。コンピュータの必須要素は、命令を実行するためのプロセッサ並びに命令及びデータを記憶するための1つ又は複数のメモリ装置である。概してコンピュータはデータを記憶するための1つ又は複数の大容量記憶装置、例えば磁気ディスク、光磁気ディスク、若しくは光ディスクも含み、又はそこからデータを受信するために、そこにデータを転送するために、若しくはその両方を行うためにそれらに動作可能に結合される。コンピュータプログラム命令及びデータを具体化するためのコンピュータ可読媒体は、半導体メモリ装置、例えばEPROM、EEPROM、及びフラッシュメモリ装置、磁気ディスク、例えば内蔵ハードディスク又はリムーバブルディスク、光磁気ディスク、並びにCD ROMディスク及びDVD-ROMディスクを例として含むあらゆる形式の不揮発性メモリを含む。プロセッサ及びメモリは専用論理回路によって補うことができ又は専用論理回路に組み込むことができる。上記のものの何れもASIC(特定用途向け集積回路)によって補うことができ又はASICに組み込むことができる。
ユーザとの対話を可能にするために、ユーザに情報を表示するためのディスプレイ装置、例えばLCD(液晶ディスプレイ)モニタ、並びにユーザがそれによりコンピュータに入力を与えることができるキーボード及びポインティングデバイス、例えばマウス又はトラックボールを有するコンピュータ上で実施形態を実装することができる。ユーザとの対話を可能にするために他の種類の装置も使用することができ、例えばユーザに与えられるフィードバックは任意の形式の感覚フィードバック、例えば視覚フィードバック、聴覚フィードバック、又は触覚フィードバックとすることができ、ユーザからの入力は音響入力、音声入力、又は触覚入力を含む任意の形式で受信することができる。
実施形態は、例えばデータサーバとしてバックエンドコンポーネントを含む計算システムによって、ミドルウェアコンポーネント、例えばアプリケーションサーバを含む計算システムによって、又はフロントエンドコンポーネント、例えばユーザがそれにより実施形態の実装と対話することができるグラフィカルユーザインタフェース又はウェブブラウザを有するクライアントコンピュータを含む計算システムによって、又はかかるバックエンドコンポーネント、ミドルウェアコンポーネント、若しくはフロントエンドコンポーネントの任意の組み合わせを含む計算システムによって実装することができる。システムのコンポーネントは、デジタルデータ通信の任意の形式又は媒体、例えば通信ネットワークによって相互接続され得る。通信ネットワークの例はローカルエリアネットワーク(LAN)及び広域ネットワーク(WAN)、例えばインターネットを含む。
システム及び方法又はその一部は、ハイパーテキスト転送プロトコル(HTTP)を利用するインターネット上のサーバの集合である「ワールドワイドウェブ」(ウェブ又はWWW)を使用し得る。HTTPは、テキスト、グラフィックス、画像、音声、ビデオ、ハイパーテキストマーク付け言語(HTML)、並びにプログラム等の様々な形式の情報であり得る資源へのアクセスをユーザに提供する既知のアプリケーションプロトコルである。ユーザによってリンクが指定されると、クライアントコンピュータがウェブサーバにTCP/IPリクエストを行い、HTMLに従ってフォーマットされた別のウェブページであり得る情報を受信する。ユーザは画面上の指示に従うことによって、特定のデータを入力することによって、又は選択されたアイコンをクリックすることによって同じサーバ又は他のサーバ上の他のページにアクセスすることもできる。所与のコンポーネントに関する選択肢をユーザが選択できるようにするために、ウェブページを使用する実施形態にはチェックボックス、ドロップダウンボックス等の当業者に知られている任意の種類の選択デバイスを使用できることにも留意すべきである。UNIX(登録商標)マシンを含めサーバは様々なプラットフォーム上で実行されるが、Windows 2000/2003、Windows NT、Sun、Linux(登録商標)、及びMacintosh等の他のプラットフォームも使用され得る。コンピュータのユーザはFirefox、Netscape Navigator、Microsoft Internet Explorer、又はMosaicブラウザ等のブラウジングソフトウェアを使用することによってウェブ上のサーバ又はネットワーク上で入手可能な情報を閲覧することができる。計算システムはクライアント及びサーバを含み得る。クライアントとサーバとは概して互いに離れており、典型的には通信ネットワークを介して対話する。クライアントとサーバとの関係は、それぞれのコンピュータ上で実行され互いにクライアント-サーバ間の関係を有するコンピュータプログラムによって生じる。
他の実施形態も本明細書及び特許請求の範囲に記載の範囲及び趣旨に含まれる。例えばソフトウェアの性質により、上記の機能はソフトウェア、ハードウェア、ファームウェア、ハードワイヤリング、又はそれらのものの何れかの組み合わせを使用して実装することができる。機能の一部が様々な物理的位置に実装されるように、機能を実装する特徴は分散させることを含め様々な位置に物理的に配置することもできる。本明細書及び本願の全体を通して「a」という語を使用することは限定的な意味で使用するのではなく、従って「a」という語について複数の意味又は「1つ又は複数」の意味を排除することは意図しない。加えて、仮特許出願に対して優先権が主張される限りにおいて、仮特許出願は限定ではなく本明細書に記載した技法をどのように実装し得るのかについての例を含むことを理解すべきである。
本発明の幾つかの実施形態を説明してきた。それでもなお、特許請求の範囲及び本明細書に記載した技法の趣旨及び範囲から逸脱することなしに様々な修正を加えることができることを当業者なら理解されよう。