6 ロード戦略

ロード戦略はデータを戦略領域にロードするために使用します。これらの戦略はロード・ナレッジ・モジュールに実装されます。

この章の内容は次のとおりです。

ロード・プロセス

ロード・プロセスは、ソース・データを戦略領域にロードする必要がある場合に必要になります。このロードは、ステージング領域で変換が行われ、ソース・スキーマがステージング領域と同じサーバーに配置されない場合に必要になります。ステージング領域は、ロード・フェーズのターゲットです。

ロード・プロセスの概要

一般的なロード・プロセスは、次のように機能します。

  1. 一時的なロード表が削除され(存在する場合)、ステージング領域に作成されます。
  2. データは、ロード・メソッドloading methodを使用して、ソースからこのロード表にロードされます。

    アクション1と2が、ステージング領域に移動する必要があるすべてのソース・データに対して繰り返されます。

    データは統合フェーズで使用され、統合表にロードされます。

  3. 統合フェーズの後で、マッピングが完了する前に、一時的なロード表が削除されます。

ロード表の構造

ロード・プロセスはステージング領域にロード表を作成します。このロード表は一般的には接頭辞C$が付けられます。

ロード表はソース・データストアではなく実行ユニットを表しています。ソース・データストアとロード表との間には直接のマッピングはありません。実行ユニットはマッピング・エディタの物理ダイアグラムに表示されます。

次のケースは、実行ユニットの概念を示しています。

  • ソースのCUSTOMER表に、マッピングに使用されるCUST_NAMEとCUST_IDの2つの属性のみがあり、ステージング領域に結合がある場合、ロード表にはこれらの2つの属性のイメージのみが含まれます。統合フローに必要ない残りの属性は、ロード表には表示されません。

  • CUSTOMER表がソース上でCUST_AGEでフィルタされると、CUST_AGEはその後使用されず、ロード表にはCUST_AGEは含まれません。ロード・プロセスはフィルタ処理をソース・データ・サーバーで行い、ロード表にはフィルタされたレコードを含めません。

  • CUSTOMERとSALES_REPSの2つの表を、ソース上で結合を使用して結合すると、結果として作成される実行ユニットがステージング領域で行われる変換に使用されます。ロード表にはCUSTOMERとSALES_REPSから結合された属性が含まれます。

  • ソース・データストアのすべての属性がマップされ、このデータストアがソース上で結合されない場合、実行ユニットがソース・データストア全体になります。この場合、ロード表はソース・データストアの正確なイメージです。これはファイルなどの転送機能のないソース・テクノロジの場合です。

ロード・メソッド

ロード・メソッドは、データをソースからステージング領域にロードする際に最適なパフォーマンスを得るために重要です。複数のロード・メソッドがあり、次のカテゴリに分類できます。

エージェントを使用したロード

実行エージェントは、ソース・サーバー上でJDBCを使用して結果セットを読み取り、JDBCを使用してこの結果セットをステージング領域のロード表に書き込むことができます。このメソッドを使用するには、ナレッジ・モジュールに、ソース上にSELECTとターゲット上に対応するINSERTのコマンドが含まれている必要があります。

このメソッドでは、配列フェッチ機能を使用してデータが配列の行ごとに読み取られ、バッチ更新機能を使用して行ごとに書き込まれるため、大量のデータには適していません。

ローダーを使用したファイルのロード

マッピングにフラット・ファイルがソースとして含まれている場合、ファイルに組込みのODIドライバを使用する標準のLKM File to SQLではなく、ステージング領域のテクノロジに最も効率的なロード・ユーティリティを利用する戦略を使用できます。ほとんどのRDBMSには、OracleのSQL*Loader、 Microsoft SQL Serverのbcp、TeradataのFastLoad、MultiLoadなど、フラット・ファイルを表にロードするための高速なロード・ユーティリティが装備されています。

LKMでは、ソース・ファイルはステージング領域にロードされ、その後すべての変換がステージング領域で実行されます。

ロード・ユーティリティを使用する一般的なLKMでは、次のステップが行われます。

  1. ステージング領域でロード表を削除し、作成します。

  2. ロード表にファイルをロードするために、ローディング・ユーティリティによって要求されるスクリプトを生成します。

  3. 適切なオペレーティング・システム・コマンドを実行してロードを開始し、リターン・コードをチェックします。

  4. ユーティリティによってログ・ファイルが作成された場合は、このファイルをエラー処理のために分析します。

  5. 統合フェーズが終了したら、ロード表を削除します。

アンロード/ロードを使用したロード

ソースの結果セットがリモート・データベース・サーバー上にある場合、エージェントを使用してデータを転送するかわりに、データをファイルにアンロードしてからそのファイルをステージング領域にロードする方法があります。

通常、様々なテクノロジに渡る大量のデータを処理する場合には、この方法が最も効率的です。たとえば、Microsoft SQL Serverソースからbcpを使用してデータをアンロードし、そのデータをSQL*Loaderを使用してOracleのステージング領域にロードできます。

この戦略に従うLKMのステップは、次のようになります。

  1. ステージング領域でロード表を削除し、作成します。

  2. ソース・データベース・アンロード・ユーティリティ(Microsoft SQL ServerのbcpやDB2アンロードなど)または組込みのOdiSqlUnloadツールを使用して、ソースから 一時フラット・ファイルへデータをアンロードします。

  3. ロード表に一時ファイルをロードするために、ロード・ユーティリティによって要求されるスクリプトを生成します。

  4. 適切なオペレーティング・システム・コマンドを実行してロードを開始し、リターン・コードをチェックします。

  5. ユーティリティによってログ・ファイルが作成された場合は、このファイルをエラー処理のために分析します。

  6. 統合KMが終了したらロード表を削除し、一時ファイルを削除します。

アンロード/ロード戦略を使用する場合、データを2度ステージングする必要があります。1度目は一時ファイル、2度目はロード表でのステージングです。そのため、ディスク領域が余分に使用され、能率上の問題が発生する可能性があります。より効率的な代替方法は、アンロードおよびロードのユーティリティ間でパイプラインを使用することです。あいにく、一部のオペレーティング・システムではファイルベースのパイプライン(FIFO)がサポートされていません。

RDBMS固有の戦略を使用したロード

一部のRDBMSには、サーバー間でデータを転送するためのメカニズムが装備されています。次に例を示します。

  • Oracle: データベース・リンク

  • Microsoft SQL Server: リンク・サーバー

  • IBM DB2 400: DRDAファイル転送

その他のデータベースには、Oracleの外部表機能など、ファイルを表にロードするための特別なメカニズムが実装されています。

これらのロード戦略は、適切なオブジェクト(ビュー、データベース・リンクなど)を作成し、その機能を使用するための適切なコマンドを実装する特定のKMに実装されています。

ケース・スタディ

この項では、ロード戦略の例を示します。

LKM SQL to SQL

LKM SQL to SQLは、エージェントを使用したロード・フェーズの一般的な例です。

後述のコマンドはこのKMからの抜粋で、例として示します。このナレッジ・モジュールのコードは、Oracle Data Integrator Studioで編集して確認できます。

作業表の削除

このタスクは、ロード表を削除します。このコマンドは常に実行され、「エラーの無視」フラグは有効化されます。ロード表が見つからない場合でもLKMは停止されません。

ターゲットに対するコマンド

drop table <%=snpRef.getTable("L", "COLL_NAME", "A")%>
作業表の作成

このタスクは、ロード表を削除します。このコマンドは常に実行されます。

ロード表の名前を返すgetTableメソッドのCOLL_NAMEプロパティを使用することに注意してください。

ターゲットに対するコマンド

create table <%=snpRef.getTable("L", "COLL_NAME", "A")%>(	<%=snpRef.getColList("", "[CX_COL_NAME]\t[DEST_WRI_DT] " + snpRef.getInfo("DEST_DDL_NULL"), ",\n\t", "","")%>)
データのロード

このタスクはソース接続にデータを読み込み、それをロード表にロードします。このコマンドは常に実行されます。

注意:

ODI一時表には回復不可能なデータは含まれていないため、ロード・フェーズでは常に自動コミットが使用されます。

ソースに対するコマンド

getFiltergetJoingetFromなどのメソッドの使用に注目してください。これらのメソッドは内容に応じた式を返すショートカットです。たとえば、getFilterはソース上で実行されるすべてのフィルタ式を返します。また、getColListEXPRESSIONプロパティを使用することにも注意してください。これはソース属性とソース上で実行される式を返します。これらの式およびソース属性は、ロード表内の対応する属性名であるCX_COL_NAMEに応じた別名です。

このselect文は、ソース・エンジンにより正しい変換(マッピング、結合、フィルタなど)が行われるようにします。

select	<%=snpRef.getPop("DISTINCT_ROWS")%>	<%=snpRef.getColList("", "[EXPRESSION]\t[ALIAS_SEP] [CX_COL_NAME]", ",\n\t", "", "")%>from	<%=snpRef.getFrom()%>where	(1=1)<%=snpRef.getFilter()%><%=snpRef.getJrnFilter()%><%=snpRef.getJoin()%><%=snpRef.getGrpBy()%><%=snpRef.getHaving()%>

ターゲットに対するコマンド

ここでは:[CX_COL_NAME]を使用するバインディングに注目してください。CX_COL_NAMEでバインドされた値は、ソース属性の別名に一致します。

insert into <%=snpRef.getTable("L", "COLL_NAME", "A")%>(	<%=snpRef.getColList("", "[CX_COL_NAME]", ",\n\t", "","")%>)values(	<%=snpRef.getColList("", ":[CX_COL_NAME]", ",\n\t", "","")%>)
作業表の削除

このタスクは、ロード表を削除します。このコマンドは、DELETE_TEMPORARY_OBJECTSナレッジ・モジュール・オプションが選択されている場合に実行されます。このオプションは、ロード表をデバッグ用に保存しておけるようにします。

ターゲットに対するコマンド

drop table <%=snpRef.getTable("L", "COLL_NAME", "A")%>