Enterprise Data Qualityの主要概念について

EDQ用語の理解

EDQで使用される最も重要な用語は次のとおりです。

プロジェクト

共有される参照データを使用する、データの共通セットで動作する関連プロセスのグループ。

データ・ストア

データがデータベースに格納されているか、1つまたは複数のファイルに格納されているかにかかわらず、データのストアへの接続。データ・ストアはプロセス用のデータのソースとして使用することができ、プロセスの書き込まれたステージング済データ結果をデータ・ストアにエクスポートすることも、またはその両方をすることもできます。

プロセス

特定のデータに対して実行するアクションのセットを示します。これは一連のプロセッサで構成され、プロセッサのそれぞれでデータの処理方法、および適用されるルールが指定されています。プロセスでは次のものが生成されることがあります。

ステージング済データ: 入力データを処理することによって、および結果データベースへの出力データの書込みを選択することによって生成されるデータまたはメトリック。
結果データ: プロセスの結果をまとめたメトリック情報。たとえば、簡単な検証プロセスで、不合格のレコード数、および合格したレコード数を記録できます。

プロセッサ

データに対し操作を実行する論理要素。プロセッサは、統計分析、監査チェック、変換、照合などの操作を実行できます。複数のプロセッサが連鎖することによって、プロセスを形成します。

公開されたプロセッサ

Extension Pack (Customer Dataパックなど)からインストールされた、またはEDQユーザーによりサーバーに公開された、追加のプロセッサです(プロセッサ・ライブラリ内のプロセッサに追加)。他のオブジェクトのようにパッケージ化できるようにプロジェクト・ブラウザに含まれます。公開されたプロセッサには、テンプレート、参照、およびロックされた参照の3つのタイプがあります。

参照データ

プロセッサがチェック、照合、変換などの実行に使用できるリストおよびマップで構成されます。参照データは、EDQの一部として、またはサード・パーティによって提供されることも、ユーザーが定義することも可能です。

ステージング済データ

データ・スナップショットおよびプロセスによって書き込まれたデータで構成され、Resultsスキーマ内に格納されます。

スナップショット

EDQリポジトリに格納された外部データのキャプチャされたコピーです。

ジョブ

EDQまたは外部によって実行される可能性のある、構成され、順序付けられた一連のタスクです。タスクの例としては、ファイル・ダウンロード、スナップショット、プロセスおよびエクスポートの実行があります。

イメージ

プロセッサに関連するアイコンをカスタマイズします。

エクスポート

エクスポートには次の2つのタイプがあります。

保存された構成を使用する準備されたエクスポート(ステージング済データのエクスポートまたは結果ブック・エクスポート)。
結果ブラウザからExcelファイルへの現在の結果の非定型エクスポート。

Webサービス

デプロイ・プロセスに使用され(ディレクタでの構成のとおり)、リアルタイムのデータ監査、クレンジング、照合(リアルタイムの重複防止など)のための、ソース・システムとの容易な統合を提供します

実行プロファイル

デフォルトのジョブ実行設定をオーバーライドするために使用できる構成設定を指定するオプションのテンプレートです。

問題

ユーザーがデータの分析時の主要な発見を記録することができ、複数のユーザー間で割当ておよび追跡されるプロジェクトでの作業方法も提供します。

プロジェクト・メモ

プロジェクトと関連するすべての情報のための明示的なリポジトリとして、ディレクタを使用することができます。プロジェクトの進行全体で、プロジェクトで作業中のすべてのユーザーに使用可能にする必要のあるあらゆる情報を、メモとして追加することができます。

データ・キャプチャについて

データ・キャプチャ・プロセスは、外部データ・ソースからキャプチャされるデータの取得で始まります。データは、データベース、テキスト・ファイル、XMLファイルなどからキャプチャできます。可能なデータ・ソース・タイプのすべてのリストについては、オンライン・ヘルプのコンセプトに関する項で、データ・ストアのトピックを参照してください。

データ・ソースのタイプによっては、データ・キャプチャで次の操作が行われる場合があります。

ソース・システムでの単一のSQL問合せの実行。
区切り文字付きファイル、または固定形式ファイルの順次処理。
データのストリームを生成するための、XMLファイルの処理。

データが取得されると、単一のスレッドで処理されます。これには次が含まれます。

各入力レコードに内部的な順序番号が割り当てられます。通常、これは各行に対して単調に増分される番号です。
行を作業ユニットにバッチングします。作業ユニットが一杯になると、結果データベースの作業キューに渡されます。

データベースの作業キューは、データベースで実行される作業リクエストで構成され、そのほとんどはデータ挿入または索引付けリクエストです。キューはスレッドのプールによって処理されます(キューから作業ユニットが取得され、適切なデータベースへのデータベース接続が取得され、作業が実行されます)。スナップショットの場合、作業の内容は、レコードのグループを表にロードするためのJDBCバッチAPIを使用することです。

すべてのデータが1つの表に挿入されると、スナップショット・プロセスは1つ以上の索引付けリクエストを作成し、それらをデータベース作業キューに追加します。一意の行識別子に索引を付けるために、表ごとに1つ以上の索引付けリクエストが作成されますが、スナップショット内のデータ量およびスナップショット・プロセスの構成によっては、キャプチャされたデータ内の他の列もスナップショット・データへの索引生成に使用されます。

図2-1 データ・キャプチャ・プロセス

「図2-1 データ・キャプチャ・プロセス」の説明

ネットワーク通信とCPU負荷について

スナップショットでは、次のことが予想されます。

データの読取り中に、データ・ソースをホストするマシンでI/OおよびCPU負荷が生成される
スナップショット・プロセスがデータの読取りを行い、挿入用にそのデータのグループ化を行うことによって、Webアプリケーション・サーバーで、CPU負荷が生成される
データベース作業ユニットのエグゼキュータ・スレッドによって、Webアプリケーション・サーバーで、I/OおよびCPU負荷が生成される
データが新しい表に挿入されるときに、EDQ結果データベースをホストするマシンで、相当量のI/Oが生成される
データに索引付けされるときに、結果データベースをホストするマシンで、相当量のI/OとCPU負荷が生成される

たとえば、4コア・サーバーでのデフォルトのEDQインストールの場合に、10列にわたって10,000行のデータのスナップショットを作成する場合、次の形式のSQLが生成されます。

DROP TABLE DN_1;
CREATE TABLE DN_1 (record-id, column1, column2, ..., column10);

100の一括挿入文は次のようになります。

INSERT INTO DN_1 (record_id, column1, column2, ..., column10) VALUES ( ?, ?, ..., ? )

それぞれ100個の一連のパラメータをとります。一括挿入は、4つのデータベース接続(CPUコアごとに1つ)でパラレルに実行されます。

ANALYZE TABLE DN_1 ESTIMATE STATISTICS SAMPLE 10 PERCENT

また、最後に、11個のCREATE INDEX...文によって、新しい表の各列に索引付けされます(元の10個の列に追加のrecord_id列)。CREATE INDEX文も4つのデータベース接続でパラレルに実行されます。

一般的なデータ処理について

データがキャプチャされると、処理の準備ができます。リーダー・プロセッサは、ダウンストリーム・プロセッサにデータへの管理されたアクセスを提供し、ダウンストリーム・プロセッサは結果データを生成します。ライター・プロセッサが存在する場合、処理の結果をステージング済データ・リポジトリに書き戻します。

プロセスを実行すると、Webアプリケーション・サーバーは多数のプロセス実行スレッドを開始します。EDQのデフォルト構成では、EDQアプリケーション・サーバー・マシンに存在するコア数と同数のスレッドを開始します。

ストリーミングについて

スナップショット内のデータをキャプチャし、結果データベースに格納するかわりに(照合中の一時的なもの以外で)、ソースからプルして、ストリームとしてターゲットにプッシュできます。

作業の分担について

各プロセスの実行スレッドには、処理するデータのサブセットが割り当てられます。プロセスの入力データが、スナップショット、ステージング済データなどの既知のサイズのデータ・セットの場合、各スレッドはデータのサブセットを取得する問合せを実行します(データのサブセットの識別は、スナップショット作成中に割り当てられた一意の行IDで行われます)。この問合せは、次の形式になります。

SELECT record_id, column1, column2, … , column10

FROM DN_1

WHERE record_id > 0 AND record_id <= 2500;

プロセスの実行対象が既知のサイズのデータ・セットではない場合(データ・ソースに対して直接実行するようにスケジュールされているジョブなど)、すべてのレコードを1つのキューに読み取ることでプロセス実行スレッド間でレコードが共有され、複数のプロセス実行スレッドによって消費されます。

各プロセス実行スレッドは、プロセスを構成するプロセッサのシーケンスを認識するようにもなっています。このプロセス実行スレッドは、それぞれの適切なプロセッサを通じてレコードを渡します。プロセッサが動作すると、Resultsスキーマに格納する必要がある結果を蓄積しますが、ライター・プロセッサの場合は、ステージング済データに書き込む必要があるデータも蓄積することがあります。このデータはすべて挿入グループに蓄積され、データベースの作業ユニットに追加され、4.1項「データ・キャプチャ」の説明どおりに処理されます。

実行スレッドが割り当てられたすべてのレコードを処理すると、他のすべてのプロセス実行スレッドが完了するまで待機します。その後、プロセス実行スレッドは照合フェーズに入り、その間にプロセスの複数のコピーからのサマリー・データが蓄積され、データベースの作業キューによって結果データベースに書き込まれます。

バッチ処理中は、次の動作が予想されます。

キャプチャされたデータが読み取られる際に、Resultsスキーマでの読取り負荷。
データが処理される際に、Webアプリケーション・サーバーでのCPU負荷。
結果およびステージング済データがスキーマに書き込まれる際に、Resultsスキーマでの著しい書込み負荷。
照合フェーズに入った際のCPU負荷の減少。
未処理のデータベース作業ユニットが処理され、蓄積された結果が書き込まれた際の、それ以降の少量のデータベース作業。
必要に応じて、照合フェーズの最後でのResultsスキーマでのさらなる書込み負荷(結果およびステージング済データ表に索引を付けるためのリクエストの形式で)。索引付けリクエストのサイズと数は、データ量とシステム構成に応じて変わります。

クリーニングおよび検証操作を中心として重厚に構築されたプロセスは、データベースのI/O容量によって制限される傾向があります。一部のプロセッサは著しくCPUリソースを消費しますが、通常、処理速度を決めるのは、Resultsスキーマからのデータの提供速度、Resultsスキーマへの書込み速度です。

レコード・セット全体の処理について

レコード重複プロファイラ・プロセッサや重複チェック・プロセッサなど、機能するためにはレコード・セット全体にアクセスする必要のあるプロセッサが多数あります。これらのプロセッサがデータのサブセットにしかアクセスできない場合、重複レコードを正確に検出することはできなくなります。これらのプロセスは、複数のスレッドを使用して入力レコードを取り込み、一時表を構築します。すべてのレコードの検証が完了すると、レコードを様々なプロセス実行スレッド間で配分することによって、再放出します。レコードを取り込んだときと同じプロセス実行スレッドで放出されるとはかぎりません。

実行ラベルについて

プロジェクトの設計フェーズでは、通常、プロセスとジョブはディレクタを使用して対話的に実行されます。ジョブをディレクタ内で実行すると、通常は、ユーザーによる調査用に結果が書き込まれ、範囲内のデータで最適に動作するようにプロセスおよびジョブの構成を繰り返すことができるようになっています。書き込むデータ量は、ディレクタで制御できます。

ただし、ジョブを本番環境にデプロイした場合、通常はこのような詳細な結果は必要なく、ジョブは実行ラベル付きでサーバー・コンソールまたはコマンドラインから実行されます。実行ラベル付きで実行されると、ユーザーがジョブでステージングされるように構成したステージング済データと結果のビューのみがジョブによって書き込まれるため、パフォーマンス効率が向上します。

注:

ジョブは、データの特定のソースまたはターゲットとは独立して設計することができます。このようなジョブは、通常は、一連のコマンドライン・パラメータとともに、または同じパラメータを設定する格納済の実行プロファイルとともに実行されます(これによって、読み取るデータの物理ソース、主要な処理オプション、書き込むデータの物理ソースなど、主要な構成オプションが動的に変更されます)。このようなジョブは実行ラベル付きで実行して、書き込まれるデータおよび結果が、同じジョブを異なるデータで実行した場合とは明確に分離されるようにする必要があります。サーバー・コンソールでは、ユーザーが実行ラベル別に結果を調査できます。

照合処理について

EDQ照合プロセッサは、これよりも単純なプロセッサとは大幅に異なる方法で処理されます。照合プロセッサで実行される作業の性質上、データを通して複数回のパスが必要になります。

照合プロセッサは、一連のサブプロセスとして取り扱うことで実行されます。たとえば、顧客のデータ・スナップショットを、禁止人物のリストと照合するように設計されたプロセスを考えます。このプロセスには、顧客参照番号と関連する禁止人物の識別子のリストを生成するように構成された照合プロセッサが含まれています。照合プロセッサに入力される(または出力される)各データ・ストリームは、照合プロセッサのサブプロセスとみなされます。そのため、この例には3つのサブプロセスがあります(顧客データ入力ストリーム、禁止人物入力ストリームおよび照合プロセッサの出力データ・ストリームを表します)。照合プロセッサ自体は4つ目のサブプロセスを形成し、効率的にデータの入力と出力を対にします。各サブプロセスにはプロセス実行スレッドの通常の割当て量が割り当てられるため、4コア・マシンでは、各サブプロセスが4つのプロセス実行スレッドを持つことになります。

図2-2 照合プロセス・スレッド

「図2-2 照合プロセス・スレッド」の説明

照合プロセッサの実行が開始されると、入力データ・サブプロセッサが最初に実行され、入力データを処理します。この時点では、照合または照合出力サブプロセスの作業はなく、休止状態のままです。入力データ・サブプロセスはデータ・ストリームのクラスタ値を生成し、通常のデータベース作業ユニット・メカニズムを使用して、クラスタ値および受信レコードをResultsスキーマに格納します。

入力データ・サブプロセスがすべての使用可能なレコードを処理すると、そのサブプロセスは終了し、サブプロセスの結果の照合を開始します。その一方で、照合サブプロセスがアクティブになります。照合サブプロセスは一連のステージを通過し、各プロセス実行スレッドは、他のすべてのプロセス実行スレッドが各ステージを完了するまで待機してから、次に進みます。新しいステージが開始されるたびに、作業はそのステージに適した形でプロセッサ・エグゼキュータ・スレッド間でさらに分割されます。処理ステージは次のとおりです。

フェーズ	説明
比較フェーズ	顧客データと禁止人物データが取得され、クラスタ値で並べ替えられます。データは、クラスタ値が等しいグループに集められ、キューに入れられ、レコードを比較するための照合プロセス・スレッドに渡されます。レコード間に関係が検出された場合、その関係情報がResultsスキーマに書き込まれます。
暫定グループ化フェーズ	比較フェーズで検出された関係情報は、チャンクで取得され、関連するレコードの暫定グループが形成されます。関係チャンクは、照合プロセッサ・スレッドによってパラレルに処理されます。これらの暫定グループは、結果データベースに書き戻されます。
最終グループ化フェーズ	単一のスレッドが暫定グループ表を検査して、チャンクの境界によって人為的に分割されたグループを確認します。チャンクを横断するグループが検出された場合は、1つのグループにマージされます。
マージ済出力フェーズ	照合プロセッサ・スレッドのそれぞれが、照合グループの独立したサブセットを取得し、マージした出力を作成します(複数のレコードが1つの出力レコードにマージされます)。

これで照合サブプロセスは完了し、照合プロセッサ実行スレッドは照合フェーズへと移行します。

この時点で、照合データの出力に関連付けられるサブプロセスがアクティブになります。出力データは出力サブプロセスのプロセス実行スレッド間で分割され、照合プロセッサからのプロセッサ・ダウン・ストリームに渡されます。この後、データは通常のバッチ処理の方法で処理されます。

ベンチマークおよび本番での経験から、照合プロセッサの比較フェーズは、CPUバウンドになる可能性がある数少ないEDQ操作の1つであることがわかっています。非常に簡単な比較操作以外のものを実行した場合、CPUが比較負荷を処理する能力によって、プロセスが制限されます。比較操作の規模は適切に拡大縮小され、EDQ Webアプリケーション・サーバーで使用可能なすべてのCPUサイクルを完全に使用できます。

ヒント:

オンライン・ヘルプの照合コンセプトに関する内容をよく理解することをお薦めします。

リアルタイム処理について

EDQは、メッセージをリアルタイムに処理できます。現在、EDQでサポートされているメッセージングの手段は次のとおりです。

Webサービス
JMS対応メッセージング・ソフトウェア

リアルタイム・メッセージ処理用に構成すると、サーバーはメッセージの受信時にメッセージを処理するために、複数のプロセス実行スレッドを開始します。受信メッセージは、空いているプロセス実行スレッドに渡されるか、キューに入れられて次のプロセス実行スレッドが空くのを待機します。メッセージが処理されるとステージング済データはすべて結果データベースに書き込まれ、プロセス実行スレッドは、キューから次のメッセージを取り出すか(存在する場合)、または次の受信メッセージに使用可能になります。

データをリアルタイムに処理する場合、プロセスは間隔モードで実行できます。間隔モードでは、プロセスが設定された間隔で結果を保存可能になり、その結果をユーザーが確認し、EDQダッシュボードに公開できるようになります。間隔は、処理されるレコード数、または時間制限によって決定できます。間隔の上限に達すると、EDQはそのプロセスに対して新しいプロセス実行スレッドのセットを開始します。新しいプロセス実行スレッドすべてが必要な初期化を完了すると、新しい受信メッセージはこの新しいスレッドに渡されます。古いプロセス実行スレッドのセットが未処理のメッセージの処理を完了すると、システムはこれらのスレッドに照合フェーズに移行して、すべての結果を保存するように指示します。その後に古いプロセス実行スレッドは終了され、データは参照可能になります。