資料處理 ETL Development (3)

基本介紹

教學目標

初步了解 ETL 批次程式如何委外廠商進行開發。

重點概念

ETL 批次程式開發是能夠進行委外廠商進行開發,前提是要有特殊且可被完整定義的轉換,每個 ETL 專案計劃皆可分成八個階段,分別為:

  1. 建立開發環境
  2. 分析業務需求
  3. 設計邏輯資料對應
  4. 管理資料品質
  5. 建立 ETL 處理
  6. 測試 ETL 流程
  7. 進行 ETL 部署
  8. 維護 ETL 批次

建立開發環境主要會請 DBA 團隊建立一個獨立的開發環境保證資料分析和 ETL 不會受到交易系統的影響,並且在專案開始的階段要記錄建立開環境所需的工具的安全步驟,透過標準文化可以最大化降低未來錯誤的機會和最小化後續增加系統時所帶來的風險。接著儘管在資料建模透過分析已經有很詳細的業務規則,但是 ETL 架構師的職責是分析業務需求實作這些規則,基本上 ETL 架構師和系統分析師會審閱所有的文件,並且和資料建模專家一起討遇到的問題。因此相關人員必須對來源系統和系統內的資料有全面的了解,一定不要縮短業務分析的完成時間,並且在沒有對所有來源系統進行徹底的分析之前,不要開始創建邏輯資料的對應。此外我們可以透過下表記錄業務規則並且分別進行追蹤資料清理或 ETL 的細節處理,不僅是為了程式開發,更多原因是相關文件將會是單元測試、系統測試、QA 測試和使用者接受測試的案例基礎。

編號 業務邏輯 處理方式 來源資料清理 ETL 處理 審核報告 報告傳送
1 員工 ID 必須唯一 ETL處理 N/A - 沒有發現不唯一的員工編號 將會檢查不唯一的員工 ID,若發現相關記錄則會進行處理 報告包括名字、顧用日期和部門等相關員工資訊 員工系統管理團隊

理論上重要的資訊皆要被記載,並且要即時更新保持最新狀態,透過文件可以確保了解資料關係,避免在 ETL 批次處理中找錯誤更有效率,並且要先在文件中定義範圍,其中包括決定 ETL 處理階段分別包括什麼內容,以及相關的業務邏輯、轉換和清理的策略。可是需求一直在變動,因此針對範圍的改變必須透過談判和區分優先等級再進行處理。若分析業務需求階段有缺少細節資訊,則 ETL 架構帥就要針對來源系統進行手工分析,當所有問題都已經解決之後就能設計邏輯資料對應。

接著資料倉儲除了能夠方便的進行查詢之外,其資料是否一致和可信賴,因此定義資料品質評估標準非常重要,主要是分析由 ETL 主管和資料品質專家負責定義資料品質規劃,主要任務為分析來源系統的品質,並且記錄所有確認資料遺漏值,以利確保最大效用的資料經由清理載入至資料倉儲中,一般來說資料的清理可分為二種,第一種是在來源系統中清理資料,第二種是在 ETL 中轉換資料,可是受限於資源所以一般會採用第二種方式進行資料的清理,此時 ETL 處理要能夠提供審核報告列出有問題資料的報表有助於追蹤資料和來源的差異。

再來 ETL 架構師會與 ETL 開發人員一起預演整個邏輯資料對應確保 ETL 開發人員在開發之前就能夠理解完整的需求,接著進行 ETL 批次程式的開發,此時不論是寫 SQL 或專門的 ETL 工具皆必須經過開發和測試,並且在轉移之前所有最終資料必須進行驗證成功。
此外若要同時交付 ETL 批次程式給開發人員時,ETL 架構師通常需要準備 ETL 的建立順序文件作為開發指南,其中包括資料表名稱、ETL 處理順序和相關描述,此時理應就能外包給廠商進行開發。然而 ETL 專案開發每個階段分應用進行三種測試,分別為單元測試 (UT)、品質保證測試 (QA) 和使用者接受測試 (UAT),當在測試新的 ETL 處理過程的時候,需要確保對已知資料問題和來源系統異常的情況進行使用者接受測試,以利提高使用者滿意度。

最後將 ETL 批次程式部署至正式環境中,並且進行維護 ETL 批次定義透過 E-mail 將審核報告傳送給相關系統人員,此外 ETL 主管則需要有能夠追蹤需求改進、Bug 修改或確認範圍修改的處理流程,因此 ETL 管理工具最好提供下述資訊提供 ETL 主管參考以利進行批次程式追蹤管理。

  • 主題範圍
  • 請求日期
  • 變更描述
  • 優先權
  • 變更類型
  • 需求狀態
  • 開啟狀態
  • 交付人
  • 負責人
  • 問題版本
  • 修正後版本
  • 關閉日期
  • 功能描述
  • 技術性描述

總結若能夠以專案方式提供特殊且可被完整定義的轉換文件理應就能請委外廠商進行 ETL 批次程式的開發、測試與監督。

相關資源