Extract/Transform/Load

**Extract/Transform/Load**（略称：**ETL**）とは、以下のようなデータフローを指す。

* **Extract** - 情報源からデータを'''抽出'''
* **Transform** - 抽出したデータをビジネスでの必要に応じて'''変換・加工'''
* **Load** - 変換・加工済みのデータをターゲットシステムやファイルとして**ロード**

ETLという用語はデータウェアハウスでのデータのロードだけでなく、任意のデータベースでのロード工程を指すこともある。ETLはレガシーシステムとモダンシステムのデータ統合にも使われる。通常のETL実装は、処理についての監査証跡を記録する。

近年のETLは、従来型のデータウェアハウス前処理としてだけでなく、ビッグデータ時代のデータ統合手法としても整理されている。また、クラウド環境では、データを先に読み込んでから変換する ELT が有力な選択肢として扱われており、ETL はその対比の中で理解されることも多い。

さらに、即時性が求められる場面では、ETL は日次のバッチ処理だけでなく、複数ソースからのストリームデータを対象とするリアルタイム処理へ拡張されている。この種の設計では、データ量と到着頻度の増大に対応しつつ、変換時の結合や同期を分散環境でどう処理するかが主要課題となる。

## 抽出 (Extract)
ETL工程の第1の部分は、情報源となるシステムからデータを抽出することである。たいていのデータウェアハウス構築では、複数の情報源からデータを集積する。個々の情報源はデータの構成やフォーマットが他とは異なる可能性がある。典型的な情報源のデータフォーマットとしては関係データベースやフラットファイルがあるが、IMSのような非関係データベース構造や、VSAM や ISAM といった他のデータ構造もある。抽出においては、次の変換・加工工程に適したフォーマットに変換する。

抽出の本質は、抽出したデータの構文解析であり、それによってデータが期待したパターンや構造に適合しているかどうかを調べる。適合していない場合、データは抽出対象から除外することもできる。

## 変換・加工 (Transform)
変換・加工工程では、情報源から抽出したデータに一連の規則や関数を適用し、ターゲットにロードできるデータにする。データによってはほとんど変換・加工を必要としないこともある。それ以外の場合、以下のような変換を1つ以上加えることで、最終ターゲットが必要とする形にする。

* 特定のカラム（列）だけを選択する（ロードしない場合はNullカラムを選択）。
* 符号値の変換（例えば、ある情報源で男性を"1"、女性を"2"としていて、データウェアハウスでは男性を"M"、女性を"F"としている場合など）を自動データクレンジングと呼ぶ。ETLにおいては、手動でのクレンジングは発生しない。
* 個人情報の秘匿 (例えば住所・氏名・電話番号など "*" などに変換する)
* 自由形式の値を符号化（例えば、"男性" を "1" に、"Mr" を "M" にマッピングするなど）
* 新たに計算した値を導出（例えば、「売上高 = 販売数 * 単価」といった計算）
* 複数の情報源のデータの統合（マージなど）
* 複数行のデータの集約（例えば、販売店ごとの総売り上げ、地域ごとの総売り上げなど）
* 代替キー値生成
* 転置または回転（行と列の入れ替え）
* カラムを複数のカラムに分割する（例えば、CSV形式で1つのカラムに複数の要素がある場合、それを分割して複数のカラムにする）。
* 単純または複合データの妥当性検証を任意の形式で適用する。規則設計と例外処理によって、そのデータを次のステップに渡すかどうかを決定する。上述の変換・加工の多くは、例外処理の一部として実行される（例えば、ある位置のデータが期待した符号で解釈できない場合など）。

## ロード (Load)
ロード工程は、データをデータウェアハウス (DWH) ）などの最終ターゲットにロードする。その組織の設定した条件によって、この工程は大きく変化する。累積データを週単位で上書きするDWHもあれば、履歴構造のあるデータに新たなデータを時間単位で書き加えるDWHもある（1つのDWHでこれらが混在する場合もある）。上書きと追記のタイミングや範囲は設計戦略の一部であり、時間とビジネスでの必要性に依存する。より複雑なシステムでは、全てのデータロード時の変更について履歴と監査証跡を保持する。

ロード工程ではデータベースとやり取りするため、データロードで起動したトリガーだけでなく、データベーススキーマで定義された制約（例えば、唯一性、参照の完全性、義務的フィールドなど）が適用される。それらはまた、ETL工程全体のデータ品質向上に寄与する。

## 課題
ETLは非常に複雑であり、不適切に設計されたETLシステムでは運用上の大きな問題が発生しうる。

設計者が検証・変換規則を指定した時点では想定していなかったデータ値の範囲や品質が運用時に見つかることがある。分析工程で情報源のデータプロファイリングを行い、データの状況を把握することで、変換規則を指定するのに役立てるのが望ましい。

DWは一般に、複数の用途の異なる情報源から非同期にデータを供給される。ETLは異質で非同期の情報源から同質の環境を抽出するための鍵となる工程である。

ETLシステムのスケーラビリティは分析時点で考慮しておく必要がある。これには、サービス水準合意 (SLA) の範囲内で処理すべきデータの量を把握しておくことも含まれる。情報源からのデータ抽出にかけられる時間は運用していく中で変化する可能性があり、時間が短くなっていく可能性がある。ETLシステムによっては、数十テラバイトのデータウェアハウスの更新のためにテラバイトレベルのデータを処理する必要があるものもある。処理すべきデータ量が増大すれば、日々のバッチ処理では追いつかなくなり、一日に何度もバッチ処理する「マイクロバッチ」に移行したり、さらにはメッセージキューと統合したり、リアルタイムのデータ変更把握が必要となる可能性もある。

## 並列処理
ETLソフトウェアでの最近の開発は主に並列処理の実装である。並列処理によって大量データを扱うETL工程の性能が全体として向上する。

ETLアプリケーションの並列性は以下の3種類に分類される。

; データ
: 単一の逐次ファイルを複数のデータファイルに分割することで、並列アクセスが可能になる。

; パイプライン
: 複数のコンポーネントを直列接続して、同時に実行する。

; コンポーネント
: 同じことを行う複数のプロセスをそれぞれ別のデータストリームに対して実行する。例えば、複数のファイルについて、ソートを行うプロセスと重複データの削除を行うプロセスを同時に実行する。

これらの並列性は単一のジョブとして実施されることが多い。

さらなる困難さは、ロードされるデータの相対的一貫性の保証にある。情報源となるデータベースはそれぞれ固有の更新周期があるため（数分で更新されるものもあれば、日単位や週単位で更新されるものもある）、ETLシステムは全情報源が同期するまでデータを保持しておく必要がある。同様にデータウェアハウスは情報源システムや帳簿と一致させる必要があるため、同期の確立が必要となる。

## ツール
ETLシステムはほとんどどんなプログラミング言語でも作成できるが、一から作るのは非常に大変である。このためETLツールを購入する企業が増えている。

確立されたETLフレームワークを使うことで、コネクティビティとスケーラビリティが向上する。よいETLツールは様々な関係データベースを扱え、様々なファイルフォーマットを扱える。ETLツールは、企業アプリケーション統合やエンタープライズ・サービス・バスに統合され始めており、システムは全体として Extract/Transform/Load 以上の機能をカバーするようになりつつある。ETL製品は、データプロファイリング、データ品質、メタデータ機能などを含むようになっている。

**製品リスト**
* ASTERIA WARP
* CData Sync
* Talend Data Integration
* DataCoordinator
* JasperReports ETL
* DataSpider Servista
* Syncsort DMExpress
* DataStage
* PowerCenter
* Waha! Transformer
* Simple Data Integrator

## オープンソースのETLフレームワーク
* Talend Open Studio
* JasperReports ETL
* Clover.ETL
* Enhydra Octopus （Java Web Start によりウェブブラウザから起動）
* Pentaho Data Integration

## 参考文献

* 
* 
* 

## 脚注

### 出典

## 関連項目
* Apache Cocoon
* ビジネスインテリジェンス
* データ統合
* データマート
* データマイグレーション
* 企業アプリケーション統合
* OLAP
* データウェアハウス

## 外部リンク
*