ETL 簡介

ETL ( Extract-Transform-Load ) 是建置或更新資料倉儲 ( Data Warehouse ) 中的內容時,對於所需之數據進行資料擷取、轉換、載入的過程,由字面上即能得知它是由下述三個環環相扣的步驟所組成:

  • Extract — 資料擷取:從資料來源處擷取所需之數據資料。
  • Transform — 資料轉換:針對所擷取出之數據資料,依照商業邏楫的需求,針對數據資料作適當的轉換。
  • Load — 資料載入:最後將已作適當轉換過的數據資料載入到目的地。

以下分別說明。   
                              

Extract

大多數的資料倉儲專案,包含著必須從各個不同的資料來源系統來擷取所需之數據資料,來源系統可能位於不同的組織、部門,以各自不同的架構、格式、方法儲存數據資料。不論是自行撰寫程式,或購買工具來執行資料擷取的工作,都必須注意到程式或工具對於擷取介面的可擴充性及多樣性。一般常見的資料來源為文字檔案格式和關聯式資料庫系統,而非關聯式資料庫系統和特殊資料格式內容的系統或檔案格式,如:VSAM、ISAM、Excel、Http Web Page、XML、PDF、binary data ...等也極有可能是資料來源。這些來源資料具有下列特性:通常為距現在時間較近、較即時的交易性資料;因為需要能夠將資料較快速地反應給前端的使用者,通常都已經針對資料結構進行過最佳化的微調;資料可能己進行過正規化或反正規化的過程。    
                              
在這個階段通常還會針對資料做二件事:

  • 資料格式轉換 ( convert data type )
     由於可能有各式各樣的資料來源和不同的資料格式,在利用程式語言開發或使用現有工具時,有必要把來源資料轉換成共同資料格式,例如一個程式語言內部使用的資料格式( 在 Java 中的UTF-8 資料格式 ) 或者現有ETL工具內部使用的資料格式 ( 在Informatica PowerCenter中的UCS-2資料格式 )。藉由共同資料格式,在下一個步驟“資料轉換”中,資料彼此之間就可以作相對應的轉換和比較。
  • 初步資料核驗 ( parsing )
    針對所擷取出來的資料,比對其格式和結構是否符合所需,例如:是固定欄位長度內容的資料、還是用區隔符號定義的資料,亦或區隔符號是否為所定義的。如果不符合,則依照相對應的遊戲規則以決定該採取何種反應,如:停止整個ETL流程;或者將有問題的部份資料另外紀錄起來並發出警告,但整個ETL流程仍持續進行。

Transform

不論是因資料散落在各個不同的部門,對於相同商業意涵的資料,以各自不同的格式、方法儲存數據資料,故而需要整合;還是基於商業邏楫上的需求,必須依照應用程式資料的特性來分類、匯歸、轉換資料型態;亦或是把經年累月所聚積的歷史資料來作合併、統計、分折及計算;前述這些需求都必須經由“資料轉換”的動作。由於可能有各式各樣千奇百怪的轉換需求,因此ETL工具中關於資料轉換的組成元件通常是最多元、最豐富的,往往也是決定ETL產品的重要考量之一。原則上資料轉換就是將所擷取出之數據資料 ( 流 ),交給這些資料轉換元件,一個一個的、循序地依照所設計好的規則去做資料的轉換,通常會包含下列動作:

  • 過濾出某些想要的資料,清除掉某些筆不需要的資料,或是按照設定的邏楫規則去驗證資料;
  • 轉換或設定部份欄位的資料值,或是經由各式各樣的文字或數值運算產出新欄位的資料值;
  • 針對資料的某些欄位作排序、分組,或是資料分組後作加總之類的資料運算以產出新欄位的資料值;
  • 同質或異質資料來源的資料作關連 ( Join ) 或合併 ( Union ) 之資料運算;
  • 利用元件去產出序列值 ( Sequence number ) 或是獨特的辨識值 ( Unique ID );
  • 依照部份欄位的資料值來分割資料流,或將多個資料流統合成單一資料流;
  • 呼叫使用外部的函數或元件 ( 呼叫 Stored Procedure, Web Services, ... );
  • 資料的倒置 ( Transpose or Pivot )

等等。 

Load

相同於“資料擷取”階段,程式或工具對於載入介面的可擴充性及多樣性,也是一個要考慮的重點。在這個階段,資料最後載入的目的地通常是資料倉儲或是資料市集 ( Data Mart )。但常常因為資料的安全性、商業邏輯流程上的考量,希望資料永不遺失,或是在任何ETL過程 ( process ) 出錯時,能夠在其中某一階段重新開始執行部份流程,而不需要全部重新開始,故通常會把資料先載入到暫存 ( Temp ) 或階段區 ( Stage )。之後可能等到所有所需的資料都己到位,或是所排定的行程 ( Schedule ) 觸發後,才由另外的ETL過程,來把資料載入到資料倉儲或是資料市集中。這些被載入資料具有下列特性:通常為距現在時間較遠、歷史性的資料,而常常都是依照某一個時間區間的歷史資料,所計算加總後出來的資料值,也因此相對的影響到ETL過程,將資料更新或載入到目的地的頻率及時間。
      

ETL工具的選擇考量

在自行開發或購買商用ETL工具時,基本上需考量系列因素:

  • 成本及時效性
    技術人員的能力,專案的成本及時程,後續維護及監控管理的難易與人力,未來擴充的成本。
  • 工具的支援能力
    是否支援現有的軟硬體平台,可否讀取現有的資料庫系統及檔案格式,是否有搭配的程式開發套件 ( SDK ),未來擴充的能力。
  • 資料轉換的複雜性 資料轉換的內容愈複雜,愈適合購買一套ETL工具。
  • 資清理的需要性
    在載入資料倉儲或是資料市集前,是否需要繁複的資料清理 ( Cleaning )?
  • 數據資料量的大小
    現有的商業ETL工具,都有各自特殊的技術來提昇搬移大量資料的效能。 

由此作出正確的選擇,以銜接資料來源與資料倉儲系統,充分支援商業智慧的應用。