レベル: 初級 Editorial staff, editorial staff, IBM
2006年 1月 10日 連載：DB2 DB2 先進のBIフロントエンド、DB2 Alphabloxの第3回です。
はじめに
DWH（データウェアハウス）の環境は、データ量が多く、データも複雑で、さらにクエリーも複雑になりやすいのが一般的です。そのような環境の中で、エンド・ユーザーは、クエリー実行時間などでストレスを感じることなくデータを活用しなければなりません。つまり、環境を構築する側であるDBAの役割が非常に重要となるのです。
ここでご紹介したいのがDB2 Cube Viewsですが、DB2のサマリー表（MQT：Materialized
Query Table）を効果的に利用することによりOLAPクエリーのパフォーマンスを高速化することができる製品です。わかりやすいGUIのインターフェースをもち、DB2
Cube Viewsで定義するOLAPメタデータはDB2 AlphabloxをはじめとするBI分析ツール間で共有することができます。また、そのOLAPメタデータはDB2の中で一元管理されます。
ちなみに、サマリー表とは、事前の計算結果を取り込むことができ、クエリーの結果も考慮することのできる特別なテーブルですが、扱い方は一般的なテーブルと同じです。
DB2 Cube Views V8.2.2の最適化アドバイザーの進化
DB2 Cube Viewsの導入により、「最適化アドバイザー」ウィザードを利用することができます。この機能は、(1)どんな分析をするのか？ということを考えながら定義されたメタデータ情報、(2)DB2のテーブルスペースやクエリーのタイプ、(3)カタログテーブルの統計情報、(4)ベーステーブルのデータ・サンプリング、といった情報に基づき、その環境で最適なサマリー表作成SQLを提供するものです。
最新バージョンV8.2.2では、最適化アドバイザーの照会およびリフレッシュのパフォーマンスがさらに向上しました。最適化アドバイザーによって推奨されるサマリー表は、より良好な照会範囲およびより速いリフレッシュ・パフォーマンスを提供します。推奨されるサマリー表は、キューブ・モデルに対するより良好な範囲を提供し、以前のリリースの場合と比較してより多くの照会でのパフォーマンスを向上させることができます。推奨されるリフレッシュ・スクリプトは、可能なときにカーソル・ロード機能を使用して、サマリー表のデータをリフレッシュするための時間を短縮します。
また、最適化アドバイザーは機能従属関係と制約など、データ間のリレーションシップについての情報を使用して、DB2
オプティマイザー*が照会に効率的に応答するために必要な、集約されたメジャーおよびレベル属性を含むサマリー表を推奨します。
*DB2オプティマイザーは、照会フラグメントを処理するためのローカルとリモートのアクセス・プランを、リソースのコストに基づいて生成します。それから、DB2
UDB は最小のリソース・コストで照会を処理すると思われるプランを選択します。
最適化アドバイザーによるサマリー表の作成
実際に最適化アドバイザーを実行してサマリー表を作成する過程をご紹介します。
以下の図は、OLAPセンターの画面です。（図1）
DB2 Cube Viewsで最適化アドバイザーを実施する前提条件として、スタースキーマーかスノーフレークスキーマー構造である必要があります。今回はスタースキーマー構造のパターンです。
売上というファクトに対して、サイズ、月、週、商品、色、店舗、年月日、という7つのディメンションが定義されています。DB2
Cube Viewsでは、OLAPセンターを利用して、GUI操作でメタデータの定義を行うことができます。実際にDB2のテーブルには持たない列を追加したり、エンド・ユーザーが分析時に使用する場合のわかりやすいビジネス名をつけたり、そして分析時に有効になってくるドリルダウンの順番を決める階層などを定義していきます。
今回は、1つのディメンションを定義するにあたり1つのDB2のテーブルを参照していますが、DB2の複数のテーブルを参照して1つのディメンションと定義することもできます。
図1：OLAPセンターにおけるキューブ・モデル
拡大図
DB2のテーブルを元にファクト、ディメンションを定義して、最終的にキューブを定義していきます。
図1で定義したキューブ・モデルを元に定義したキューブを定義します。（図2）
図2：OLAPセンターにおけるキューブ
拡大図
これまでのメタデータの定義を元に最適化アドバイザーでサマリー表を作成していきます。
キューブ・モデルを右クリックし最適化アドバイザーを起動します。（図3）
最適化アドバイザーでは、1つまたは複数のサマリー表を作成するのに必要なSQLスクリプトを提供します。
このとき、スタースキーマーもしくはスノーフレークスキーマーでなければ最適化アドバイザーウィザードは起動しません。
図3：最適化アドバイザーの起動
拡大図
次に照会のタイプを選択します。（図4）
照会タイプは、このキューブ・モデルのどの部分が最も頻繁に照会されるかを最適化アドバイザーに認識させるために指定します。
-
ドリルダウン
キューブ・モデルの親レベルに集中されたデータのサブセットにアクセスする際に指定します。
一般的な多次元分析を行う場合には、これに該当します。
-
レポート
キューブ・モデルのあらゆる部分に一様にアクセスする際に指定します。
-
MOLAP抽出
多次元データベース（MOLAP）用のデータストアへロードする際に指定します。
また、上記3パターンの照会タイプの他に、最も頻繁に照会すると予想されるキューブ領域を任意で設定できる、「最適化スライス」ウィザードが新機能として追加されました。（図5）
各次元の照会領域がまちまちの場合には、このウィザードを利用することで、より最適な情報を最適化アドバイザーに与えることができます。
図4：照会タイプ
拡大図
図5：最適化スライス
拡大図
次に、リフレッシュオプションを指定します。（図6）
キューブ・モデル内のDB2データが更新された場合には、サマリー表も更新する必要があります。そのとき、どのタイミングでサマリー表をリフレッシュするかを指定します。
-
即時
基本表（キューブ・モデル）との密接な同期を保持します。基本表の変更部分に対応するサマリー表の対応部分のみを変更することで、サマリー表を差分（増分）更新できるように、基本表に対する変更箇所をトラッキングします。
ただし、頻繁に基本表に散在した変更が入る場合にはお薦めしません。
-
保留
手動で基本表をサマリー表の同期をとる必要があります。サマリー表はある時点でのスナップショットになります。
また、「即時」と違い、差分更新を行うためのトラッキングは行いません。
※どちらの場合も、サマリー表のリフレッシュ用SQLスクリプトを実行する必要があります。
図6：リフレッシュオプション
拡大図
次に、いくつか制限を指定します。（図7）
最適なサマリー表を作成するために、ディスク・スペース、時間、データ・サンプリングについて制限を指定することができます。
-
ディスク・スペース
サマリー表に使用できるディスク・スペースの概算量を指定できます。
最適化アドバイザーは指定されたディスク・スペース量にできるだけ近い、最適なサマリー表を推奨します。（多い場合も少ない場合もあります）
-
時間制限
サマリー表の決定に使用できる最大時間を指定できます。
より多くの時間を与えるほど、良い最適な結果を得ることができます。
-
データ・サンプリング
キューブ・モデル内のデータを検証します。これを行うことにより、最適化アドバイザーにより多くの情報を提供できるので、より効果的なサマリー表を作成できます。
仮にデータ・サンプリングを行わない場合、最適化アドバイザーに与える情報は、キューブ・モデルとDB2統計のみになります。
図7：制限の指定
拡大図
以上の情報から、最適なサマリー表作成のためのSQLが作成されます。その状況は随時確認することができます。（図8）
図8：進捗モニター
拡大図
最適なサマリー表作成SQLが得られると、そのSQLを保存する画面が出てきます。（図9）
サマリー表作成SQL、サマリー表更新SQLをそれぞれ保存します。
また、実際にできたSQLを確認することができます。（図10）
サマリー表の数は1つとは限りません。いろいろな条件により、1つの場合も1つ以上の場合もあります。
図9：SQLスクリプトの保管
拡大図
図10：サマリー表作成SQLスクリプト
拡大図
おわりに
今回は、DB2 Cube Viewsの主な機能である最適化アドバイザーの機能をV8.2.2の新機能も含めてご紹介しました。サマリー表は、もちろん手動で作成することもできます。ただし、それにはかなりの経験とスキルが必要になります。最適化アドバイザーを利用することにより、短時間で最適なサマリー表を作成することができるので、最終的にエンド・ユーザーが快適に分析などを行うことができるようになります。
今後は、もう少し具体的な内容を取り上げていく予定です。
参考文献
著者について  | | | developerWorks Information Management team |
記事の評価
| 
