パフォーマンスと拡張性を兼ね備えるオラクルの新たなデータウェアハウス：BI革命を起こす日本オラクルの新プラットフォーム 【連載第3回】

ビジネス・インテリジェンスにおける重要な構成要素の1つがETL（Extract, Transform and Load）である。さまざまなデータソースから必要なデータを収集し、データウェアハウスに格納する機能を担うETLは、そのパフォーマンスや動作の正確性によってシステム全体の質に大きな影響を及ぼす。今回、オラクルはこのETL機能を飛躍的に進化させたという。

[ITmedia]

PR

関連リンク

日本オラクル株式会社

Oracle Business Intelligence

Oracle Database 10g

Oracle Grid Computing

　ビジネス・インテリジェンス（BI）では、ユーザーインタフェースや、分析機能そのものに話題が集中する傾向がある。もちろんそれらは重要な構成要素だが、ほかにもBIシステムの正否に大きく影響する機能がある。それがETL（Extract, Transform and Load）機能である。ETLは、データウェアハウスにさまざまなデータソースから必要なデータを収集し格納する。そもそも、この機能が正確かつ時間内に終了しなければ、分析を実行することができない。

　従来このETLの機能は独自開発されることも多く、標準的なツールで簡単に処理できるものではなかった。というのも、メインフレームを含め、企業におけるデータソースにはさまざまな種類があるため、個別に対応するしか解決の手段が見つからないことも多いからだ。ETLの機能すべてが自動処理されることはなく、運用管理者の人手による作業が介在することが多々あった。

大きく進化したオラクルのETLツール

　昨今のIT技術の進化により、ユーザーがデータウェアハウスに格納したいと考えるデータ量が爆発的に増加していることから、ETLの重要性が改めて強調されるようになってきた。データウェアハウスはそこで、限られた時間内に大量のデータを効率よく収集、格納できなければならない。単に情報ソースからデータを取得して、データベースに入れるだけではだめだ。Transformの部分、すなわち必要な変換処理を施してデータの品質を向上させる必要もある。

　そこで、オラクルは、Oracle Warehouse Builder 10g Release 2でETLの機能を大幅に強化した。その特徴の1つとして、ETLの実行エンジンがOracle Databaseで稼働することが挙げられる。Oracle Warehouse Builder 10g Release 2ではOracle Databaseの中でこの機能が実行されるため、専用のサーバーは必要ない。これによって、ハードウェアのリソースを最大限に活用できるという大きな利点が出てくる。一方で、他社のツールでは、ETL専用のサーバーでいったんクレンジング処理を行ってから、データを取り込む必要がある。

　もちろん、ばらつきを修正してデータの品質を向上させたり、データソースに変更が生じた際に分析にどこまで影響がでるかを予測したりするような、他のETLツールにも搭載されている機能もカバーされている。さらに、Oracle Business Intelligence Suiteとの親和性も高い。たとえば、OLAPのキューブを構築することも可能だ。

　また、処理プロセスに人手が介在すればするほど、データの信頼性が失われるため、内部統制を確保するのが難しくなる。その意味でも、自動化はキーワードだ。定義されたルールに沿ってシステムで自動化できる機能は、コンプライアンスの面からも極めて有効と言っていい。

Warehouse Gridで実現する柔軟で拡張性のあるデータウェアハウス

　もちろん、データウェアハウスそのものも統合的なBIプラットフォームの実現には重要だ。オラクルでは、この部分に実績のあるグリッド技術を取り込んでいる。データウェアハウスにおいては、物理的にサーバーの数を増やすだけでシステムの能力を高めることができる拡張性の高さが大きく貢献する。データウェアハウスは、ERPのように一度構築したら数年間は同じ形で運用するといったシステムではなく、随時システム規模を大きくしていく必要があるからである。データウェアハウス構築のコツは、小さく初めて大きく育てること。グリッドならば検索におけるパフォーマンスを上げる必要があればCPUを、データ量が増加すればディスクを増設することで対応できる。低コストで柔軟にシステム統合できることが、Warehouse Gridの要件なのである。

　さらに、Warehouse Gridがリソース配分を動的に構成できるのも有効だ。たとえば、4ノード構成であれば、夜間はそれらの処理に3ノードを割り当て、昼間の検索要求が高いときには今度は検索に3ノード割り当てるといったことが動的に実施できる。これにより、昼夜それぞれの処理のピークに合わせて無駄なシステム投資をすることなく、ハードウェアのリソースを最大限に活用できるのである。

　統合BIプラットフォームのメリットとしては、データの一元的な管理によるリアルタイム性の確保、管理コストの低減、コンプライアンスにおける要求にも対応できるデータの正確性の確保と統制されたビジネスプロセスの実現といったことが挙げられる。オラクルの統合BIプラットフォームのシナリオでは、最終的にはこのWarehouse Gridにすべてを統合することが理想的だ。

統合BIプラットフォーム提案シナリオにおけるゴール

　とはいえ、一足飛びにこの理想型に行き着けるわけではない。まずは、可能なところから統合していけばいい。場合によってはOracle Warehouse Builder 10g Release 2を使って、疎結合のアプローチによる既存資産との統合でもいいだろう。システムの切り替えタイミングや、新たな規制への対応など、大きなシステム変更が発生するタイミングで既存のデータマートを段階的にWarehouse Gridに加えてもいいだろう。