目次


システム連携 素朴な疑問集・なにがちがうの?

第2回 ETLとEAIはどうちがうのか?

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: システム連携 素朴な疑問集・なにがちがうの?

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:システム連携 素朴な疑問集・なにがちがうの?

このシリーズの続きに乞うご期待。

ETLとEAIの比較?

ETLとEAI…それぞれ異なるジャンルとして確立し、別のものを指す製品・技術です。名前と簡単な概要だけ知っているという方なら、全然違うこの2つをなぜ並べるのか?と思われるかもしれません。でも両方についてある程度詳しくなり、それぞれの機能を見ていくと、だんだん違いが見えにくくなってきます。ここではETLとEAI、それぞれの概要についてお話した後に2つの違い、使い分けをご理解頂くという流れで進めていきます。

そもそもETLとは?

ETL(Extract/Transform/Load)は、多種多様なデータソースからデータを抽出(Extract)して変換(Transform)し、ロード(Load)するための製品・技術を指します。
OLTP系のデータベースからデータウェアハウスを構築したり、データマートにデータを移行したりするための機能を提供するツールとして発展してきました。複数レコードに跨る複雑なデータ変換や高速大容量の一括データ処理などを得意としています。情報統合製品群の一環としてデータの品質管理(クレンジング)や複数データソースの仮想化(フェデレーション)といった製品と合わせて提供されています。
IBMが提供するETLツールとして、WebSphere DataStageがあります。

そもそもEAIとは?

EAI(Enterprise Application Integration)は、アプリケーションの統合・連携を行うための製品・技術を指します。
EAIという用語は非常に幅広い意味で捉えられることがあります。ここではデータ連携に的を絞った「狭義のEAI」、アプリケーションから別のアプリケーションへデータを渡す処理を担う部分について考え、プロセスの自動化(複数アプリケーションの実行順序制御や人が介する承認フローなどのシステム化)を実現するためのビジネスプロセス連携の概念であるBPM(Business Process Management)とは切り離して考えます。ただしEAIのような連携基盤が確立していれば、プロセスの自動化・IT化を進めるにあたってアプリケーション連携という課題は既に解決していることになります。実質的なBPMの前提条件と言えるかもしれません。
データの送達保証やリアルタイム性が重視されることもあり、ファイル転送のような(Non-transactionalでバッチ的な)処理ではなく、MQのようなメッセージング技術をベースに発展してきました。近年ではSOAの概念を取り入れたESB(Enterprise Service Bus)の呼び名が普及し、EAIに取って代わりつつあります。ここでは便宜上、ESBとEAIの違いには踏み込まず、呼称をEAIに統一します。
IBMが提供するEAIツールとしては、WebSphere Message Brokerがあります。

従来からの違い

GUIが整備されておりDrag&Dropベースの視覚的な開発が可能、データソース(DBやファイル、MQ、ERPパッケージ製品など)からのデータの取得・変換・書き出しの機能を持ちハンドコーディングでの負荷を大幅に削減…これらはETLとEAIどちらにも当てはまる表現です。実は同じところの多いこれらの技術、機能的にはどのあたりが違うのでしょうか?いくつかの具体例を挙げてみましょう。

まず、処理を誰が開始するか?起動の仕組みを見ていきましょう。ETLではスケジューラーや人などの外部トリガーにより、一度に大量のデータ処理を開始するというパターンが一般的であり、逐次リアルタイム処理を行うことはあまりありません。EAIではアプリケーションが処理フローを開始(MQメッセージのPUTなど)し、即時に一件ずつ処理するパターンが一般的です。つまりバッチとリアルタイムの違いとなります。例えば不正なフォーマットのレコードが含まれていた場合、ETLであればリジェクトデータとしてファイルに溜め込んでおき、処理終了後に内容を確認するといった対応を取ります。EAIの場合は該当レコードを見つけるとエラー処理用フローを走らせ、一件ごとに送信元へのエラーメッセージ返答やEメール通知などを行う形になります。

次にアプリケーション側の改修の問題があります。ETLツールはDBやファイルなどのデータソースからデータを抽出します。アプリケーションはDBやファイルへのデータの書き出しを完了しているため、ETLが導入されてもアプリケーションを改修する必要がありません。一方、EAIツールを導入する際にはEAIにデータを「渡す」ことをアプリケーションが意識します。それがWebサービスの呼び出しであれ、MQメッセージのPUTであれ、他との連携を考えていないアプリケーションにとっては(大抵のレガシーシステムはそうかもしれません)インターフェースの改修という作業が発生し、導入の阻害要因となってしまうケースも見受けられます。

扱うデータについても見てみましょう。ETLはファイル内のデータとパッケージ製品が持つデータをマージして別のDBに格納する、といった複数レコードを同時に処理する機能を備えています。集計やソート、比較などを製品機能として実現できる「データセット志向」のツールであるといえます。EAIはリアルタイム性が重視されることからも分かるように、全レコードを読み終わらないと作業ができないような処理は得意としていません。単一レコードの数値・文字列演算などを基本にした「メッセージ志向」のツールであるといえます。

また、接続形態にも違いがあります。ETLはN個のデータソースから1つのデータウェアハウスへ、一方向にデータを流してデータを溜め込んでいくといった使い方が一般的です。EAIでは問い合わせのための要求応答処理、データ更新のための非同期一方向処理、不特定多数の送受信者が混在するpublish/subscribe処理などの多様な連携処理を得意としていますが、N個の入力を1つにまとめるN:1連携の機能は得意としていません。

連携手法の観点から

少し視点を変えてみましょう。ETL、EAIともにさまざまなシステムとの連携が発生するため、多くのインターフェースをサポートしています。システム連携を行うためのインターフェースにはどのようなものが存在するのでしょうか?
当然ながら全てをカバーするものではありませんが、大別すると以下のようになります。

  • プログラム間通信
    プログラム(PC/UNIXでいうところのプロセス)が直接、相手とのデータ交換を行う方法です。アプリケーションにはネットワークエラーやタイムアウトなど、通信処理を意識したロジックが求められます。ソケット通信やEJB、Webサービスなどがここに含まれます。
  • リモートデータベースアクセス
    アプリケーションからデータベースに対してアクセスする手段を提供します。上記プログラム間通信はアプリケーション to アプリケーションですが、こちらはアプリケーション to DBです。JDBCやODBCといった通信手段があります。
  • ストアードプロシージャー
    リモートデータベースアクセスの一種として分類できますが、SQLの一文ではなくDBアクセスを含んだプログラムを呼び出すイメージとなります。純粋なDB連携手段というだけではなくアプリケーションロジックを含みます。
  • メッセージキューイング(MOM)
    WebSphere MQをはじめとしたメッセージキューイング製品を使った非同期通信手段であり、JMSもこの領域に含まれます。一度キューに届いたメッセージはネットワークエラーやプロセスダウンその他の障害が起こっても確実に相手に届けることができます。アプリケーションはキューにデータを書き出すロジックを実装することになります。
  • ファイル転送
    FTPが該当します。MOMとは違って通信エラーにより不完全なデータが相手に届いてしまう危険性はありますが、一般的なデータ連携の方法として広く用いられています。ファイルにデータを書き出すアプリケーションと、データの転送や再送制御を行うためのアプリケーションまたはミドルウェアが必要です。
  • データベースレプリケーション
    あるサイトにあるDBの内容を別のDBにコピーする手段を提供します。タイミングはデータが更新されたとき、一定の間隔ごとなどがあります。レプリケーションを行うために内部的にMQを用いる構成を取ることもあります。

ここでは特定の業務パッケージ製品(ERP、CRM、SCMなど)のインターフェースについての記述は省いています。ツール側でそうした固有のインターフェースをサポートすることはもちろん、パッケージ側でもWebサービスなどのオープン・スタンダードなインターフェースを提供して接続性を高めるという両方の動きがあります。
下記の図は、横軸にバッチ・リアルタイム処理、縦軸にアプリケーション間連携・データベース連携を取ってこれらの連携手法を分類したものです。ETLはバッチ・データベース連携、EAIはリアルタイム・アプリケーション間連携を主な守備範囲と考えると、以下のような分布図ができあがります。

図:ETLとEAIの適用領域
図:ETLとEAIの適用領域
図:ETLとEAIの適用領域

進化系…機能的な違いはあまりない?

なるほど納得…といきたいところですが、ことはそう簡単ではありません。近年のトレンドを踏まえた機能強化により、ETLとEAIはお互いの長所を次々と取り込みつつあるのです。
ETLツールはMQをはじめとした多様なアダプターを備えてリアルタイム性を高め、データインテグレーションハブとしてシステム構成上はまるでEAIのような使い方ができるようになっています。また、EAIツールはSOA/ESBの流れを踏まえてサービス連携機能を強化するだけではなく、サービス化されていないレガシー・システムとの連携も強化しています。例えば大量データを処理するバッチ系システムを動かすフローにWebサービスインターフェースを備えて「バッチ処理のサービス化」を実現する、アダプターを併用してファイルの到着やDB書き込みを検知して処理を開始する仕組みを備えアプリケーション側の改修を不要にする、といった使い方ができるようになっています。複雑なデータ処理やN:1/N:N通信も一般的なEAI・アダプター製品の組み合わせでは難しいですが、IBMではWebSphere Transformation Extenderという製品をラインナップに加えることで問題なく実現できるようになりました。

WebSphere Transformation Extender(US)

本質的な違いは?

ここまでETLとEAIを機能的な観点で比較してきました。では結局、本質的に何が違うのでしょうか?機能的には重複するところもある両者ですが、ここは原点に立ち返って考えてみましょう。ETLはその名の通り、抽出・変換・ロードするための製品であり、目的は単一のDBに高品質なデータを「集約」すること、つまりデータウェアハウス(DWH)の構築です。さらに言えばDWHに集約したデータを用いてデータマイニングや多次元分析処理を行うこと、つまりビジネスインテリジェンス(BI)の実現が最終目的ということになります。
一方、EAIはどこかにデータを集約するということは考えず、複数のアプリケーションがデータのやり取りを行えるための基盤を提供します。人事や会計、営業などの異なるシステムが一つのシステムに「集約」されることはありえません。EAIの存在意義は、これら異なるシステムを「統合」して有機的につなぐところにあるのです。
- ETL…データセントリック
- EAI…アプリケーションセントリック
とでも言えばよいでしょうか。ETLはデータの同期化、一元化、集約といった作業を行いたいときに用います。バッチ的な使い方を基本とし、少々のタイムラグ(例えば1日など)を前提に、BIに必要なデータの鮮度と品質を保つために使用します。
一方、EAIはデータ交換のためのインフラ整備を行い、多様なアプリケーションが存在したままでそれぞれのデータを別のアプリケーションがスムーズに利用したいときに用います。ETLよりも短期間(数秒~数分程度)で対応が必要であり逐次処理が求められる業務処理、例えば在庫照会や契約処理などを実現するために用います。場合によっては、これらを組み合わせて使用することもあるでしょう。

いずれにしても、こうしたツールを活用することで手作りスクラッチ開発、重複開発、プログラム品質向上などにかかるコストを削減でき、高品質なデータ管理、システム連携が可能となります。特性を見極めたうえで最適な選択をしてください。

以上、今回はETLとEAIの本質的な違いを追ってみました。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=325878
ArticleTitle=システム連携 素朴な疑問集・なにがちがうの?: 第2回 ETLとEAIはどうちがうのか?
publish-date=08292007