Development

資料處理 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 批次程式的開發、測試與監督。

相關資源

資料處理 ETL Development (1)

基本介紹

教學目標

初步了解 ETL 批次程式開發流程和相關面臨的問題。

重點概念

在 1970 年美國為了國防和航太計劃產生瀑布式模型 (Waterfall Model) 之開發流程主要有五個階段,分別為需求 (Requirements)、設計 (Design)、實作 (Implementatino)、驗證 (Verification) 和維護 (Maintenance),主要著重於安全的開發方式、要求詳細的準備文件、適合大型專案開發,可惜開發時間較長和當需求有變動就會導致後面階段進行修改。接著有許多開發流程針對瀑布式進行改良,統一軟體開發過程 (Rational Unified Process,RUP),主要有四個階段,分別為起始階段 (Initial Phase)、精細規劃階段 (Elaboration Phase)、建構階段 (Construction Phase) 和移轉階段 (Transition Phase)。

其中針對 ETL 批次程式開發我們花費比較多的時間在於「起始階段」和「精細規劃階段」。「起始階段」主要會進行可行性分析,定義批次程式的影響範圍,了解實際解決的問題和預期達成的成效,以及評估所需人天。接著「精細規劃階段」主要是針對批次程式進行架構的分析與設計。再來進行「建構階段」主要透過 IBM Rational ClearQuest 進行批次程式實作與測試,主要會針對需求填寫相關說明,包括設計與實作資訊、測試和過版資訊、上線資訊、使用者確認信、資訊安全測試報告等相關資訊。接著進行確認執行變更作業,就能夠透過 IBM Rational ClearCase,選擇與此需求相關批次程式進行簽出(Check Out) 作業,在開發環境進行批次程式的修改和單元測試 (Unit Test,UT),待確認無誤之後,將相關批次程式進行簽入 (Check In) 作業,完成版本控管的任務,最後返回 IBM Rational ClearQuest 進行完成變更作業。等待相關批次程式自動和手動搬移至測試環境之後,在測試環境進行使用者接受度測試 (User Acceptance Test,UAT),又稱整合測試。最後「移轉階段」主要進行批次程式的上線,並且透過批次管理工具進行排程和監控等相關設定。

然而「建構階段」會面臨資料驗證和效能處理等問題,一般來說為了資訊安全的考量開發環境會與測試/正式環境分隔,以及測試環境只能讀取加密處理的檢視表,而非正式環境原始的資料表,因此將會需要透過自動化程式達成將正式環境中資料表快速拷貝一份至開發環境,可是因為有個資外洩的疑慮所以無法長久保留所以每次使用完畢皆要刪除,導致非常不方便,再著透過自動化程式達成 ETL 批次程式中資料庫名稱自動切換和加密欄位自動處理等應用,可是當面臨上千行以上的 SQL 陳述式時,導致非常不方便。此外開發環境與正式環境的設備不一定相同等級,資料量當然也是,因此需要在測試環境才能進行效能測試,此時就算通過單元測試在整合測試階段也會面臨效能問題,為了解決此效能問題就必須再簡化和折解 SQL 陳述式,導致非常不方便。所以若能夠更有效的解決上述所面臨的三個問題,理應就能簡化建構階段加速 ETL 批次程式開發。

最後技術債 (Technical Debt) 將會是上千個 ETL 批次程式開發之後會面臨最大的問題,簡單來說當因為時間緊迫導致走捷徑時,技術債就會發生,導致日後必須整理令人費解的批次程式、複雜的資料模型和不注意細節設計等問題,所以當在進行 ETL 批次程式開發時儘可能花時間思考如何有效避免不必要的技術債。此外最好能避免有相關 ETL 批次程式實作之後,就很難更改的錯誤概念,而導致預先做大量設計 (Big Design Up Front,BDUF) 的問題,會在前期加入了許多不需要的資料轉換,而忽略必要的資料轉換,造成更多問題發生,但是若能夠簡化建構階段的流程也就能夠快速實踐足夠可用的 ETL 批次程式。

相關資源