ETLの必要性とリアルタイム性
データウェアハウスやデータマートは、業務系システムで発生したデータをコピーして作成します。必要なデータは存在しているのに、なぜ別のデータベースにわざわざコピーするのかと言えば、企業内に散在しているデータを統合して横串（部門横断的）に見たいという要求があること、業務系システムでは保持できない長期間のデータに対する分析要求があること、さらに業務系システムにおける更新系処理と参照系処理の競合を回避し使用目的に適合したデータベースを構築するのが合理的であることなどがその理由として挙げられると思います。いずれにせよ、業務系システムとは別のデータベースにコピーするというのが大前提になっています。
では、どうやってコピーするかということでETLプロセスが登場します。したがって、ETLの方式に関して議論の余地は多々あると思いますが、ETLプロセス自体は必須です。ただし、Transformの必要性については個々のシステムに依存すると思っています。たとえば、水平分散している業務システムのデータを単純に一箇所に集めてデータウェアハウスを作成するような場合、Transformは必要ないかもしれませんので、システム提案の段階で調査しておく必要があります。
また、E-T-LかE-L-Tかという点については、適材適所で考えればよいと思います。私は、非RDB形式のデータをRDB形式へ変換したりホストの文字セットをデータウェアハウスの文字セットに変換するなど、データウェアハウスへのロード前に行わなければならない作業はETLツールを使用し、導出データを追加したり同音異義や異音同義を修正するなどの作業はロード後にSQLで一括して処理するという方式を好んで採用しています。
データウェアハウスのリアルタイム性
次に、リアルタイム性について少々お話します。
ETLツールの使用が前提になっているプロジェクトでは、初めからETLツールを使用したバッチ処理を念頭にETLプロセスの設計が進みます。しかしそうでない場合、どうやってデータを収集するのか、ただ持ってきて入れるだけでよいのか、どこまでリアルタイムにできるのかなど、いろいろな疑問が飛び交うことになります。
特にリアルタイムの要求がある場合、ETLプロセスはバッチ処理だと言っても、バッチ起動間隔の合理的な説明ができないため、2フェイズコミット方式やレプリケーション、あるいは業務系システムの更新トリガでリモートのデータベースを更新するといった分散システムにおける同期技術を使用してデータウェアハウスを作成するという方向に話が進むこともあります。
リアルタイムを要求されるようになる以前、私はデータウェアハウスへのデータロードは1日に1回、夜間バッチで行うべきだと考えていました。データウェアハウスは参照ユーザ専用のデータベースであるべきで、そのためには更新処理によるハードウェア・リソース（CPU、メモリ、ディスク）の競合、およびRDBMSの排他制御（論理ロック）は発生させてはならないと考えていたからです。そこで、もしリアルタイム性を要求された場合は、当日分のデータは業務系システムを参照し（このためにODSを作成するという方法もあるでしょう）、データウェアハウスの前日以前のデータと合算する仕組みがあればよいと考えていたのです。
