ETL 概念、應用及工具簡介

企業裡面常有資料處理、轉換或整合的需求。好的資料管理工具雖然不一定能讓你上天堂，不好的工具卻肯定會讓你住病房。「ETL 資料轉換作業」是「資料管理」中最基礎的應用，本篇就來說說 ETL 的基本概念，它有何應用，以及市場上常見的工具。

ETL 是什麼

• ETL 代表資料由資料來源端擷取 (Extract) 出來，經過轉換 (Transform)，再載入 (Load)到目的端的資料傳輸過程。
• Extract -- 從各種不同的資料來源中，將資料擷取出來。傳統上資料來源是來自於交易型資料庫。
• Transform -- 對資料進行適當的轉換，如型態轉換、字串相連、彙總運算等等。這個步驟在 ETL 中不一定要執行。
•  Load -- 將資料載入目的端；目的端通常是為了報表產製及商業智慧分析而最佳化的資料倉儲。

 

 ETL 的應用情境

• 同步不同資料庫的資料。
• 資料清理，移除錯誤資料。
• 將資料載入資料倉儲以便後續分析, 如進行 OLAP 或 Data Mining 之應用。

 

使用 ETL 工具的優勢

使用 ETL 工具最大的優勢，在於可把傳統上需要透過手工方式開發的資料轉換程式碼，轉為由 ETL 工具去進行設定或設計，如此可大量減低資料轉換作業的建置時間及成本。

目前大部分開發人員還是使用自行開發的指令，來處理資料的整合作業。要透過這種方式來建立商業智慧系統，需要開發人員需具備一定的專業能力，還要費時費力的進行開發及除錯。

對於資料庫管理人員而言，若不使用外部工具，要連通不同種類的資料來源並不簡單。況且一旦外部資料來源改變，或者要加入新的資料來源，那這種勞心勞力自行開發的工作又要整個重來一次。使用 ETL 工具，將能簡化這種繁複瑣碎的工作。而良好的資料轉換流程之圖形介面設計工具，甚至可將這類操作變成樂趣。

 

ETL 工具簡介

以下來說說一些業界比較常用的 ETL 工具：

Informatica PowerCenter

• Informatica 公司所提供的同名商業化套裝資料整合軟體。
• 建立於 1993 年，主要業務即為資料整合。
• 依據 Gartner Dataquest 的報告，它在資料整合領域具有最高的市占率。
• 它提供了大量的套件供企業進行系統整合，並能連接到大量的新一代或既有的資料來源。
• 提供良好的作業設計及監控介面，功能強大，但人員必須經過訓練才能上手。
• 單價昂貴，顧問服務費用高。
• 無縫整合著名的「下推優化」ELT 方法，使用資料庫的服務資源來進行資料轉換作業，效能優良，可以應用於大規模的系統。

Pentaho Kettle (PDI)

• Pentaho 是一家商業化的公司，約始於 2001 年，他們基於 Java 開發了一套開源 BI 套件，使用者社群人數眾多。 其中包含了一個 ETL 軟體，稱為 Kettle (或稱為 Pentaho Data Integration/PDI)。
• 透過中介資料趨動 (metadata-driven) 的方式來設計資料轉換流程，而其使用介面功能完善且易於操作。不需像 Informatica 那樣大的前期投入。
• 其作業設計及轉換使用了兩種腳本文件：Transformation 和 Job。Transformation 進行資料的轉換作業，以 Javascript 撰寫，Job 則用來控制整個作業流程。
• 具有作業分派的功能 (需要一個像 cron 的分派器)，可以透過分散式部署建立 Pentaho 群集，並能運行部署在 slave servers 上的遠程任務。
• 擁有資料品質管理功能，可以撰寫自定義的 SQL 查詢，Javascript，和正則表達式。 
• 從 4.3 版開始，改採 Apache 授權。參考 Pentaho changes ETL license for big data push -- Kettle 4.3, available under the Apache License Version 2.0, can ingest, output, manipulate and report on data from Apache Cassandra, Hadoop HDFS, Hadoop MapReduce, Apache Hive, Apache HBase, MongoDB and Hadapt’s Adaptive Analytical Platform.

Talend

• Talend 是一個開源碼的資料整合軟體, 大概啟始於 2006 年 10 月。
• 採用程式碼產生器的方式來建立資料轉換作業，它將產生的 Java 或 Perl 程式碼佈署於伺服器執行。
• 其 GUI 操作介面是建立在 Eclipse RCP 平台之上。
• 使用者社群人數沒有 Pentaho 多，但在國外有許多商業公司進行支援。像著名的 Jaspersoft (Jasper Report 開發者) ETL 工具就是採用 Talend ETL。

Trinity

• Netpro 公司所出產的商業化資料管理整合軟體。
• 包含 Data Management (即 ETL)、JCS (作業控制系統，用來排程及分派作業)，以及 Metadata (管理資料源與資料轉換作業會用到的資料庫、資料表及欄位資訊) 三個部分。
• 其最新版支援 BigData Management, 能連接到 Hadoop HDFS, Hbase 等 BigData 資料儲存體，亦能執行 Pig 與 HiveQL 操作。
• 提供以 Web 為基礎的操作介面，資料流程設計工具及作業執行監控工具都能透過 Java Web Start 即時自網頁上即時啟動，整體配套措施相當完善。
• 採分散式多 Agent 架構，可以簡易的 scale-out.
• 還包含 Data Profile, Impact Analysis, Data Protection 等各種資料管理軟體，實用性相當高。

ETL 與 ESB 之異同與整合應用

因為自己開發 ETL 相關產品，加上之前對 ESB 與 SOA 也有接觸，那就來聊聊這兩個東西有什麼關連吧!

ETL 全名是 Extract, Transform, Load, 是指資料搬移過程中，從來源資料庫擷取 (Extract)、經過資料轉換 (Transform)，再載入 (Load) 到目標資料庫的過程。通常會用商業智慧資料分析的資料準備階段，資料從前端的交易性資料庫，透過 ETL 軟體導到資料倉儲，再交給 OLAP、報表或資料探勘工具做進一步分析。

而 ESB 全名是 Enterprise service bus，這是一種企業應用程式的中間層軟體，可以讓不同的應用程式系統，透過 ESB 所提供的開放式介面，彼此介接，達成訊息與應用整合的目標。ESB 是 SOA 服務導向架構在企業部署應用中，比較容易上手的解決方案。打個廣告，個人在 2006 年曾為 ITHome 撰寫的三篇 SOA 專欄文章：

• SOA的開源大勢(1)開放源碼SOA專案低調進入應用階段
• SOA的開源大勢(2)開源SOA專案的遷徙與合併
• SOA的開源大勢(終)開放源碼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 是可以分別採用不同的系統。不過筆者在想的是，住後以雲端為主的應用時代來臨，這兩者都必須要能朝雲端架構演進，甚至統整成為同一個系統，因為以後的應用情境很有很可是前端資料讀取的介面，採用 ESB 的訊息接收模式，而後端則採用 ETL 直接將訊息進行拆解，轉化，載入到 data warehouse 或 hadoop 分析平台之中。因此這兩種應用若能更密切的整合，系統開發跟維護心力就可大幅降低。

而甚至資料傳輸樣式也超出傳統 ETL 或 ESB 的 message 或 collection based 的方式，而是如新一代的，streaming based 的資料串流，資料從不間斷的產生，永不止息(如 twitter)。如果有一套系統，只要透過組態或圖形化介面方式，就能設計出足以處理這種新的訊息型態的資料流程，那無異是即時訊息處理上的一把神兵利器。且讓我們拭目以待吧!