Technical Debt

資料處理 Technical Debt (1)

教學目標

初步了解導入機器學習系統進行後續維護作業所會面臨哪些技術債的問題。

重點概念

首先機器學習提供很強大的工具集透過很快速且便宜的方式建立實用且複雜的預測系統,但是當我們維護機器學習系統時,就會面臨軟體工程框架中技術債的問題,所謂技術債主要是在 1992 年 Ward Chunningham 提出,主要是協助我們理解由於在軟體工程中快速移成長而產生的長期成本,就像財政債務一樣,因此需要有合理的戰略承擔技術債,我們可以透過重構原始碼、改進單元測試、刪除無效程式碼、減少相依關係、重新評估 API、改善文件檔案、…等方式進行改善,請注意目標不是增加新的功能,而是為了減少錯誤的發生和提高可維護性,若是我們針對技術債視而不見,就會導致更危險的隱藏技術債發生產生維護上更嚴重的問題,尤其是資料處理時如何與資料進行整合,同時確保資料品質,若是我們忽略技術債將會導致資料品質不佳,資料不正確、遺失值過多,以致於造成機器學習系統的預測結果無法有效的應用於決策分析。

技術債

接著機器學習系統所產生技術債的問題通常很難被發現,因為它主要在於資料會影響機器學習系統行為無效。當我們導入機器學習系統時,資料輸入將會來自於其它系統,此時若是其它系統的資料品質不佳,就會立即影響機器學習的預測結果。一般來說,我們在軟體工程中會使用封裝和模組化的方式設計抽象方法,將有助於確保資訊輸入和輸出的內容和邏輯一致性,但是透過抽像方法很難應用於機器學習系統,因為當所需要的輸入資料無法透過外部資料和軟體邏輯被有效地的表達時,才會需要使用機器學習的方式,所以我們很難針對機器學習系統實施嚴格抽像介面確保資料輸入的品質。

相依債

再來機器學習系統除了產生技術債問題之外,還會產生相依債的問題,所謂依賴債主要是軟體工程中程式碼複雜性和技術債的關鍵因素。然而機器學習系統中資料的相依關係更為複雜,並且更難被發現。一般來說,我們在軟體工程中會使用編譯器和鏈結器的靜態分析工具識別程式碼相依關係,但是我們很難透過任何工具分析資料的相依關係。

分析債

此外機器學習系統除了技術債和相依債問題之外,還會產生分析債的問題,尤其是即時的機器學習系統其關鍵特性主要是隨時間更新影響分析行為,此時將會導致分析債,因為我們很難預測模型在發佈之前隨著時間的推移而逐漸發生的行為。

設定債

最後機器學習系統除了技術債、相依債和分析債之外,還會產生設定債的問題。任何大型機器學習系統皆有廣泛可設定的選項,包括使用哪些功能,如何選擇資料,不同演算法特定的學習設定、預先資料處理、後續資料處理、驗證方法、…等。一般來說,研究人員和工程師通常會認為驗證或測試的設定不是非常重要,但是任何設定若是發生錯誤,將會導致機器學習系統無法正常執行。

總結機器學習系統導入進行後續維護作業時將會面臨許多債需要償還,其中個人認為有四個債非常重要,分別為:

  1. 技術債
  2. 相依債
  3. 分析債
  4. 設定債

簡而言之,通常我們會以最快速且便宜的方式導入機器學習系統,此時就會產生技術債的問題、針對資料匯整若沒有分析專家或領域知識專家的合作將會面臨相依債的問題,並且若是進行採用多個機器學習模型進行即時分析將會面臨分析債的問題,以及企業導入機器學習系統需要與其它系統進行整合,此時就會面臨設定債的問題。因此若我們要導入機器學習系統時,可以考慮套裝軟體或雲端服務的解決方案,而非開放源碼的解決方案,避免在後續維護機器學習系統時發生更多的問題。

相關資源

資料處理 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 批次程式。

相關資源