ETL（Extract-Transform-Load，提取轉換載入）是建置資料倉儲（Data Warehouse）或進行系統轉換時，對於所需之數據進行資料擷取、轉換、載入的過程。其中也包含資料的正規化，將其轉為特定格式的文字檔或資料庫資料表，再透過檔案傳輸服務，傳送到目標系統。
「資料移轉」在系統轉換或異質系統整合佔有重要的地位，但因為它介於兩個系統之間，所以常常被忽略掉。大部分的人都認為只要資料有轉換過去就好，並不會花太多時間做完整的規劃。以至於發生問題時，常常無法釐清問題在哪裡，或事前提出一個確保資料完整轉換的驗證方法。
目前市面上很少有書籍或文章探討 ETL 規劃設計的實務。因此，我們將以過去執行專案的經驗，規劃一系列的文章，來探討資料移轉與異質系統資料整合相關問題，包括「資料轉換規劃的原則、中繼資料表的規劃、資料品質的驗證及常用的 ETL 工具」。
ETL 資料轉置三步驟
- 資料擷取（Extract）：
由資料來源處擷取所需數據資料移轉到中繼資料庫。此步驟最重要的原則是在移轉過程中，只作媒體轉換，盡量不作內容或格式轉換，以方便後續作資料的驗證。 - 資料轉換（Transform）：
針對所擷取出之數據資料，依照商業邏輯的需求，將數據資料作適當的轉換，例如：資料型別、欄位的分割合併、資料的加工…等作業。 - 資料載入（Load）：
最後將已作適當轉換過的數據資料載入到目的地。在載入目的之前，亦須保留一份對應至目的檔案或資料庫的內容，同樣的亦是只有媒體不同，但格式與內容需與輸出的目的端相同。
ETL 兩大應用面
歷史資料移轉（Initial load）
- 歷史資料的移轉，通常是用在應用系統平台的轉換或將資料導入另一個應用系統。
- 歷史資料移轉依照作業需求決定轉換的資料量。若是作系統轉換，通常是將舊系統的資料全部作移轉；若是異質系統的整合，則只轉換必要的資料。以反洗錢系統而言，則須包含所有客戶與帳戶及最近兩年的交易資料為原則。
- 轉換的原則為盡量保有原始資料，移轉至新系統的中繼資料表。除非必要否則不做清理，以確保資料轉入與轉出內容一致，便於後續處理。
日常作業（Daily Operation）
- 日常作業的 ETL，主要目的是用於異質系統的整合，作為每日或定期的資料交換使用。轉換過程中，必須作嚴謹的資料檢核與驗證，對不合規格的資料必須退回前端系統修正。
- 同時須將執行的時效性納入考量，不能因為單一系統的問題影響日常作業。
ETL 資料移轉，首重「資料正確性」
除了資料正確之外，也需考慮以下因素：
- 資料轉換過程中若有不符規定的資料，以致無法轉入時，應列出錯誤清單與錯誤原因，以利前端系統做資料修正。
- 錯誤資料修正後，應能重新執行匯入。
- 輸入資料筆數、異常資料筆數、輸出資料筆數，應於執行批次轉檔後主動通知系統負責人。
- 單一檔案若為多系統提供時，應考慮可分批執行、且不可因單一系統的問題造成全部系統無法執行。
- 資料轉換過程中，重要步驟的執行花費時間，應予記錄，必要時可針對較花費時間的步驟做調教。
- ETL 執行失敗需以自動化的方式通知系統負責人，通知的方式可以考慮如郵件、檔案回饋。
- ETL 程序執行前與完成後，應將相關資料做備份，以作為問題追蹤或重現的依據。
ETL 流程整合進階考量
- 來源資料與輸出資料跨系統傳輸亦需納入整合設計，讓整個流程可以無縫接軌的執行。
- 流程的啟動方式須納入規劃，例如：使用作業系統排程／批次排程系統，如 BMC Control M / IBM TWS。
- 正式環境（PROD）／備援環境（DR）的切換與 ETL 排程關聯（A/A、A/S）。
- 各種環境考量，例如：開發環境（DEV）、整合測試環境（SIT）、使用者測試環境（UAT）、正式環境（PROD）、備援環境（DR）的佈署方式與環境參數管理，才能讓一套系統可以在不同環境執行。
- 如何建立開發階段的測試個案，亦須納入考量。ETL 通常是由前端系統提供資料，本身沒有資料的輸入介面，因此如何產生開發階段的測試資料，也是一個常被忽略的環節。
結語
以上是關於 ETL 資料轉換的應用及規劃原則說明，後續我們將針對各項執行細節作更詳細的探討，敬請期待！
資通電腦具備 40 多年系統整合開發經驗，提供各項應用程式開發、整合維護、API 介接、資料庫移轉、檔案交換…等服務，協助政府機關與企業因應業務拓展、作業流程改造、資料管理等問題，為企業資訊化提供最有效率的系統服務。
