端的に言うと、ロード計画はシナリオを本番環境で編成したり実行したりするための非常に強力なオブジェクトで、シナリオを正しい順序で開始するための多くのスクリプトや、他のシナリオを段階的に開始するために使うパッケージをなくすことができるのです。
ロード計画の作成
ロード計画はデザイナおよびオペレータナビゲータにあります。開発リポジトリ、本番リポジトリでバージョンをつけることができます。シナリオフォルダに入れることもできます。
ロード計画を作成するのは非常に簡単です。上図のようにアイコンをクリックして「新規ロード計画」を選択し、名前をつけるだけです。ロード計画がシナリオを実行する際には、これらのシナリオをどのレベルでロギングするかを指定できます（ログセッション、ログセッションステップ、その他オプション）。
ロード計画での実際の作業は［ステップ］タブで実施します。ここではステップの階層を設定できます。階層の末端では、直列、並列、もしくは変数の値に基づいてシナリオを起動します。以下の例（データウェアハウスロード計画）では次のような直列のステップが含まれています。
- Initialization ステップ (INITIALIZATIONというシナリオを起動)
- 並列してディメンジョンをリフレッシュ（以下に詳細あり）
- IS_LOAD_FACT という変数の値をこのロード計画のパラメータとして渡す。
- IS_LOAD_FACT=1ならば、 LOAD_SALES シナリオを実行してからFINALIZE_FACT_LOADING シナリオを実行
- IS_LOAD_FACT=2ならば、 LOAD_SALES シナリオのみを実行
- a、bのいずれでもない場合は、FINALIZE_FACT_LOADING シナリオを実行
並列してディメンジョンをリフレッシュすることで、2個のアクションを同時に実施しています。
- Products をロード(LOAD_PRODUCTS シナリオを実行)
- Geographies をロード(国／地域／都市のテーブルをロードするパッケージを実行）し、Customers をロード(2番目のパッケージ)
ステップを追加するために、ウィザード（ツールバー中の"＋"ボタンで起動します）を使うか、シナリオやインターフェース、プロシージャなどをデザイナツリーから直接ステップの階層にドラッグアンドドロップすると、自動的にこれらのコンポーネントのシナリオを作成し、ロード計画として組み込むことができます。
トップダウンで開発するほうがお好みなら、ロード計画を作成して、ウィザードを使って何もないところからシナリオを追加することもできます。以下のサンプルでは、ウィザードを使って何もないところからシナリオを追加しています。バージョン番号-1を使って、単にこのシナリオの最新バージョンを実行するためのロード計画であることを示しています。
さらに、ロード計画のステップから、シナリオの作成元や、シナリオの再作成元のオブジェクトにアクセスすることもできます。ロード計画の再構成も、ドラッグアンドドロップで簡単にできます。
ロード計画の実行
ロード計画を保存してから、ツールバー上の実行ボタンを押すとロード計画を実行できます。実行中のロード計画は、オペレータの［ロード計画実行］画面から確認できます。ロード計画実行の［ステップ］タブを見ると、実行したステップとそのステータス、統計情報がわかります。このタブ全体が実行状況を反映し、実行状況が変わる都度画面がリフレッシュします。
ロード計画が開始したセッションはまだセッションリストに存在しますが、［ステップ］タブはすべてのセッションの実行状況を監視する上で非常にわかりやすい思います。セッションIDの（青字の）リンクをクリックすると、セッションエディタが開いてセッションの状況をドリルダウンできるのです。
シナリオのように、ロード計画をコマンドラインやWebサービスから起動することができます。もちろん外部スケジュールサービスや組み込みのスケジューラから起動可能です。
［注意］
ロード計画を実行するためにはJava EEもしくはスタンドアロンエージェントが必要です。ODI Studioのローカルエージェントでは動作しません。これはロード計画実行フローが、ロード計画から開始されたセッションを起動するエージェントを介して配信されるからです。このアーキテクチャを使うと、複数のエージェントで実行されてもSPOFがないため、ロード計画の実行停止を避けることができます。
例外処理
例外処理および再開はロード計画の優れた機能の一つです。例外は失敗時に実行できる単なるステップの集まりです。小さなロード計画のようなものです。
上記の例では、2個の例外処理を作成しています (Minor Exception と Major Exception)。これは管理者にメールを配信するシナリオを開始しますが、Major Exceptionではステップで失敗が発生した場合にログを出力します。
すべてのステップには失敗時にどの例外を発生させるか、親ステップに伝える例外はどれかを設定するプロパティがあります。例外を上げると、失敗したことを親ステップに伝えて、ロード計画全体を失敗にします。失敗を無視する場合にはこのステップの失敗は小さなエラーとしてフラグが立ちます。
以下のサンプルでは、ディメンジョンをリフレッシュする並行ステップのどちらからでエラーが発生した場合（Max Error Child Count=0）に、ディメンジョンのリフレッシュは失敗したと見なします。このような失敗であっても私ならMinor Exceptionを走らせてロードを続行させるでしょう。すべてのディメンジョンがリフレッシュされていなくても、正しくリフレッシュされてなかったディメンジョンを参照するファクトを分離するために、ODIデータ整合性フレームワークを使用していることもあり、それでもファクトをロードすることができるのです。
この例ではステップの再開を説明しています。このロード計画を再開する場合、再開タイプを選択して失敗した子ステップだけを再開することができます。
［注意］
既存のロード計画を再開する場合には、ODIは最初に実行されたロードプランを上書きせず、複製を作って複製を使って再開します。各ロード計画はエラーの特定とトラッキングのための保存されるのです。
ロードプラン vs パッケージ
ODIについてご存知の方なら「ロードプランは新しいパッケージなのか？」と思うかもしれません。まぁ、類似点もありますが、同じ目的を持っているわけではありません。
- パッケージ：データ統合開発者によって主として作成されるテクニカルなワークフローで、強いトランザクションの性質を持つ
- ロードプラン：本番環境の機能設計と管理を容易にすることを目指したもので、本番ユーザーとデータの統合プロジェクトリード/アーキテクトが作成する。
| 機能 | ロードプラン | パッケージ | 備考 |
|---|---|---|---|
| バージョン | 設計時および実行時 | 設計時。 パッケージは実行時にシナリオにコンパイル。 | 本番環境で実行フローを変更する必要がある場合、ロードプランを使うことが望ましい。 |
| 開始・監視 | UI、コマンドライン、Webサービス、スケジューリング | UI、コマンドライン、Webサービス、スケジューリング | どちらの機能も同じ。 |
| トランザクション | ロードプランの各ステップには各々のトランザクションを含む。 | パッケージのステップはトランザクションを共有することがある。 | いくつかのステップで発生するトランザクションがワークフローで必要な場合は、パッケージを使用すること。 |
| 並行度 | ○ パラレルステップを使えば可能。Operatorに従えば簡単に並行実行可能。 | 他の開始しているシナリオによる。 並行実行はオペレータで追跡することが困難。 | パラレルステップ実行が本当に必要なときに限りロードプランを使用することが望ましい。 |
| 再開 | ○ 以前の実行時のステータスを保持 | ○ 以前の実行時のステータスを上書き。データベーストランザクションは継続されないため、パッケージ全体の再実行が必要になることが多い。 | トランザクションの性質と実行結果が新しい実行によって上書きされるという事実のために、多くの場合、アトミックな作業単位としてパッケージを再起動する。 ロードプランが再起動に関するより良い柔軟性を提供する。 |
| 分岐・ループ | 分岐はCase、Whenをサポート ループは非サポート | 分岐、ループともサポート | ワークフローでループが必要な場合にはパッケージを利用することが望ましい。 |
11.1.1.5の新機能に関する説明はまた次回。
原文はこちら。
http://blogs.oracle.com/dataintegration/entry/what_s_new_with_oracle
0 件のコメント:
コメントを投稿