ETL 全名是 Extract, Transform, Load, 是指資料搬移過程中，從來源資料庫擷取 (Extract)、經過資料轉換 (Transform)，再載入 (Load) 到目標資料庫的過程。通常會用商業智慧資料分析的資料準備階段，資料從前端的交易性資料庫，透過 ETL 軟體導到資料倉儲，再交給 OLAP、報表或資料探勘工具做進一步分析。
而 ESB 全名是 Enterprise service bus，這是一種企業應用程式的中間層軟體，可以讓不同的應用程式系統，透過 ESB 所提供的開放式介面，彼此介接，達成訊息與應用整合的目標。ESB 是 SOA 服務導向架構在企業部署應用中，比較容易上手的解決方案。打個廣告，個人在 2006 年曾為 ITHome 撰寫的三篇 SOA 專欄文章：
雖然已經有點過時，不過裡面所談到的 ESB 跟 SOA 的觀念，還是具有參考價值。我再找個時間來更新這部分的資料好了!
好了，談到這裡，那 ETL 與 ESB 有任何關係嗎? 也許有些人會覺得我是不是聯想力太豐富了，才會覺得這兩者有關。嘿! 它們還真的有點關係呢!
前面所說，ESB 是一種企業應用程式的中間層軟體，用來整合應用，或交換訊息。而事實上，我們也可以把 ETL 看成是另一種中介軟體，但它所介接的兩端，不是應用系統，而是資料來源與目的端。這裡我用中介軟體，而沒講它是 Middleware, 是因 Middleware 有比較嚴謹的定義。可是實際上，如果從 Middleware 定義："Middleware makes it easier for software developers to perform communication and input/output, so they can focus on the specific purpose of their application." 來講，ETL 軟體也的確具有這樣的功能。
也就是說，基本上各種中間層軟體，都具有能讓介接兩端的系統，透過中間層軟體介面，達到彼此間獨立演進，又能統合在一起，彼此協作。ESB 是這樣的系統，ETL 其實也有這樣的特色。
再來談談不同的部分。首先，ETL 通常具有主動性，透過排程，去資料來源抓取資料。但 ESB 通常是被動的，等待應用程式呼叫，才進行訊息的傳輸與 routing. 不過這一點並不絕對，現在的 ETL, 有些也採取 Event Trigger 的方式來設計。例如，當檔案內容發生改變時，觸發 ETL 作業過程。這種作業方式跟 MOM (Message-oriented middleware) 在收到訊息時進行資料傳輸的行為模式很類似。
第二點，ETL 所傳輸的資料，通常包含多筆記錄，是屬於 table 或 collection based 的方式在傳輸資料。而 ESB 所傳輸的資料，通常是一個 remote procedure call 或是一個訊息等；是屬於 message 或 document based 的。這點也沒有絕對，因為 ETL 事實上也可以只傳一筆資料，而 ESB 事實上也可以一次傳輸多筆資料。不過就效能上來講，當然 ETL 在傳輸大是資料時，速度應該會較快。這跟架構有關，就先點到為止。
第三點，是關於服務執行一次轉換或呼叫的時間，英文可稱為 session 吧。通常 ETL 因為一次會傳輸與轉換的量資料，所以執行一次轉換的時間會較久。而 ESB 單一訊息通常資料量不大，因此呼叫時間較短。
最後則是呼叫或資料傳輸的方式，因為傳統上與 ETL 介接的都是資料庫系統，資料被取出之後，來源資料庫並不會等整個 ETL 過程結束等待回應，再去進行什麼操作。但 ESB 視其中介的性質，可能有不同的呼叫或等待回應方式，例如 SCA 裡面就定義了底下幾種方式：
- Request response interaction
- One-way interaction
- Conversational interaction
- Callback interaction
前一陣去一某家公司拜訪，他們要導入某大廠的 ESB 系統，做跨事業部門的系統整合。除了各獨立的應用程式要能整合應用外，另一個需求就是以前不同事業單位，分散在各地的區域性資料庫，之後要能進行資料匯整，放到一個中央控管的整合資料庫。這時，若能在規劃中，加入 ETL 的應用，必然會使整個系統的開發更為順利。
以上情境，當然 ESB 與 ETL 是可以分別採用不同的系統。不過筆者在想的是，住後以雲端為主的應用時代來臨，這兩者都必須要能朝雲端架構演進，甚至統整成為同一個系統，因為以後的應用情境很有很可是前端資料讀取的介面，採用 ESB 的訊息接收模式，而後端則採用 ETL 直接將訊息進行拆解，轉化，載入到 data warehouse 或 hadoop 分析平台之中。因此這兩種應用若能更密切的整合，系統開發跟維護心力就可大幅降低。
而甚至資料傳輸樣式也超出傳統 ETL 或 ESB 的 message 或 collection based 的方式，而是如新一代的，streaming based 的資料串流，資料從不間斷的產生，永不止息(如 twitter)。如果有一套系統，只要透過組態或圖形化介面方式，就能設計出足以處理這種新的訊息型態的資料流程，那無異是即時訊息處理上的一把神兵利器。且讓我們拭目以待吧!
