大資料下的質量體系建設

一、背景

      大資料、人工智慧是當前也是未來幾年IT部門的重點建設方向，新的技術可以為業務突破盈利瓶頸，帶來新的增長點，同時我們也發現資料中臺也頻頻在最近的企業財報予以體現，相關的技術崗位需求也是供不應求，與之形成對比的是，我們發現在招聘網站上很少有專職的資料測試崗位。
      我們相信技術始終是為業務創造價值的，大資料也要輸出他的產品（資料），產品必須要有質量的管控才可信，測試人員可以藉助這個契機進行賽道的轉換，在資料測試中形成自己的一套方法論參與到這個新技術引領的浪潮中。

二、資料開發在做什麼

2.1 資料開發過程

我們可以通過上面這個圖先來簡單的去理解資料開發主要做什麼

1. 根據需求找業務開發獲取源資料；
2. 通過相關的工具把源資料同步到資料平臺的表中；
3. 按照模型進行資料的清洗；
4. 將清洗結果寫入到結果資料表中。

2.2 資料開發與應用開發的區別

1. 資料量大，這是他的首要特徵，量大一個是消耗資源多，一個是效能問題，能否按時完成作業
2. 演算法、模型運用較多，涉及到比如使用者標籤，營銷預測，風控等需求開發，往往就是需要一些演算法和模型的使用
3. 最終產出是資料，這個與應用開發交付的是程式碼不一樣，應用開發的程式碼上線後，正常就是正常，但是資料開發的程式碼上線後，還需要把資料跑出來才算交付
4. 開發語言偏重於SQL、python、java，資料開發使用最多的就是sql了,另外就是python和java會做一些資料轉換處理的函式開發，這塊對測試人員來說相對比較好接入
5. 業務能力強且廣，資料開發會涉及到公司的各個業務應用的資料，所以對業務的熟悉是開發的前提

三、測試需要關注什麼

3.1 資料測試的出發點

在瞭解資料開發的過程和相關技術運用後，我們發現測試人員要接入資料開發測試流程，需要做好如下幾點準備

1. 資料的持續關注，也就是要關注資料的完整流向，從哪裡獲取，各種條件下的清洗規則，資料最終又流向了哪裡，這個在4.1部分中會有相應的解決方案，就是後設資料管理和模型設計文件
2. 業務的熟悉，在業務應用的測試中，往往是每個測試人員負責幾塊業務內容，但是在資料測試中，測試人員需要對公司某個領域所包含的的業務需求瞭解透徹，比如做使用者畫像的開發，會涉及到賬戶體系、訂單模組
3. SQL、python、java能夠使用，在資料測試過程中，由於不像應用開發通過介面操作進行測試，往往是通過構造輸入資料，執行相關的sql和函式，確認輸出資料，所以有相關語言的基礎會更方便我們的測試進行

3.2 資料測試關注什麼

1. 準確性

• 完整性，就是資料通過每一次流轉後，首先我們要看資料是否如預期的完整，不多不少
• 準確性，資料經過採集或者清洗流轉後，是符合業務需求的；或者通過演算法模型做預測，資料是符合一般性規律的，比如28定律、正太分佈等

2. 及時性
   資料能夠在預期的時間完成清洗產出
3. 效能

• 資源使用，主要關注對資源的消耗
• 資料介面效能，提供的API效能是否滿足需求

四、資料開發測試流程

4.1 文件規範很重要

我們在做業務測試的時候，需要需求文件、設計文件，同樣在做資料測試時，也需要有文件上的規範性要求

1. 產品需求文件
2. 模型設計文件，ETL的規則要有清晰的說明，這樣測試才能更好的進入設計測試用例
3. 排程設計文件，每個節點的排程週期、執行順序、上下游依賴、是否定時執行，執行預期時間都需要說明，方便去理解上下游關係和線上監控配置
4. 釋出文件，告知是否需要重跑資料，重跑哪個時間段的資料，測試在執行生產釋出的時候需要依據該文件進行相關操作
5. 公司級的資料庫設計規約，單獨提這個文件，是因為資料開發的資料來源都是從業務系統採集過來，業務應用資料庫設計、變更這些對資料開發來說都是有一定的影響的，所以我們需要一份規約，來統一資料庫的設計，庫表變更的同步流程等
6. 業務變更的同步，當業務端需求變化可能會導致取數的邏輯發生變化，也是需要同步到資料端做相應的評估

4.2 開發和生產環境的獨立

開發人員在需求開發的過程中，也需要通過反覆的除錯來完成程式碼的開發，為了不影響生產環境的正常使用，我們也需要像業務應用開發那樣，有多套獨立的環境來進行正常的開發和生產。
由於資料環境的相對複雜性和硬體資源的需求比較大，在資料部門組建初期，可以先只設立開發和生產兩套獨立的環境。
多套環境相應的就有許可權的控制，不同角色崗操作的環境、資料許可權都要有相應的管控

4.3 資料開發測試流程

1 完整流程

2資料開發流程

關鍵產出文件：

• ETL文件，資料的清洗規則需要有相應的文件輸出，測試可以根據該文件瞭解開發的模型設計，並輔助進行相應的測試用例設計
• 排程設計文件，作業的設定也是交付的一部分，需要有相應的排程設計文件來讓我們知道生產的作業設定情況
• 釋出操作文件，在釋出程式碼到生產的時候需要該文件的支撐

3 測試階段

產出物：測試用例、缺陷

4 釋出階段

產出物:上線郵件

5 線上缺陷修復流程

資料開發與業務開發有一點不一樣的地方在於，資料開發交付的是資料，所以如果生產一旦出現異常，回滾程式碼是解決不了問題的，需要將資料同步進行修復

五、全流程的資料質量監控預警體系

我們通過開發測試流程保證了程式碼的可靠性，也通過本地環境的資料構造完成相關測試點執行，程式碼釋出到生產之後，由於生產環境的資料與本地在量級和各種覆蓋度上還是存在差異，就像我們對應用程式在生產建立監控預警來保證生產的穩定性一樣，也需要建立一套完備的大資料監控體系來保證我們資料的及時性和準確性。

5.1 計算資源的監控

無論在做資料採集還是資料清洗，都是一件十分消耗計算資源的事情，當前生產的資源配置是否能夠滿足我們的業務場景，當資源出現瓶頸趨勢能否提前通知相關人員，這個就需要我們進行計算資源的監控，我們可以從如下維度進行監控

1. CPU的使用量，比如當前的算力是100cu,使用了80cu我們就觸發報警
2. 記憶體的使用量，資料儲存是特別耗資源的一個事情，對記憶體也要最好提前量的監控
3. 等待作業數，當前時間點存在多少個作業在等待資源
4. 流量監控，對於資料的上傳下載，需要設定流量頻寬的監控

5.2 作業執行監控

我們的資料程式碼釋出到生產後，會由排程平臺按照節點執行的時間點設定成一個個的排程作業，作業是否及時、成功的執行，關係到資料的及時性和準確性

1. 作業的狀態進行監控
   執行狀態錯誤，作業執行失敗了
   執行的效率，在預期的時間長度（30分鐘）未執行完成
   執行的及時性，這份作業需要在1:00必須執行完成，結果超過1:00狀態還不是成功
2. 作業日誌進行監控
   對每一個節點，當執行完成後，我們寫入一條日誌資料儲存，然後通過一個作業去輪詢這個日誌表的資料，如果某個時間點資料沒有生成，觸發報警

5.3 表、欄位維度的資料監控

在做資料採集或者資料清洗，存在大量表的資料讀寫，過程中需要對資料的完整性、一致性和準確性進行監控，資料是否正常寫入了，是否存在血緣關係表的資料的不一致，是否清洗過後出現資料異常等等都需要及時知道並進行干預，避免錯誤資料暴露給使用者。我們可以通過在作業執行中加入表、欄位的監控來實現

1. 監控等級
   根據資料的重要性，可以將監控設定為強、弱兩種型別，如果是強監控性質的，一旦觸發，作業立即停止執行，防止異常資料寫入下游節點；如果是弱型別的，作業繼續執行，資料繼續寫入，獲取報警資訊後人來確定是否進行干預。
2. 監控維度
   表中資料條數，表中資料不能少於某個值，或者在某個範圍
   表中資料的週期波動率，在某個時間週期，比如3天，資料行數的波動範圍
   欄位資料，針對單個欄位的監控，是否為空，是否唯一等

5.4 質量、效率與成本的平衡

因為資料量大，資料清洗對算力的要求高，高的算力能夠幫我們規避或者延遲一些問題的暴露，比如作業等待。無限制的去擴容帶來的是成本的無限增長，我們需要在質量、效率和成本中去尋找平衡。

1. 資料資產評級
   是不是所有的表、欄位、作業都需要做監控呢？哪些作業需要優先執行呢？我們需要有科學的判斷--對資料資產進行評級，特別重要的定義為A級，所有跟A級依賴的也採取同等級定義；不是很重要的定義為B級等等
2. 排程平臺根據級別進行作業執行優先順序設定
   根據上面的資料資產評級，我們在設定作業執行的順序時，除去上下游的依賴關係，當兩個作業在同一時間點誰先執行，就有了清晰的定義
3. 報警方式根據級別進行渠道定義
   報警的觸發方式，可以是語音電話、簡訊、郵件、釘釘訊息等，不同的渠道成本是不一樣的，我們也可以根據資料資產的評級來進行選擇，比如特別重要的預警通過語音電話直接觸發，相對重要的平時工作時間通過釘釘，非工作時間通過簡訊觸發等。
4. 資料生命週期管理
   資料儲存因為資料量級的關係，特別消耗儲存空間，我們需要對資料的生命週期有相應的管理策略，什麼時候相關表的資料可以銷燬，避免殭屍資料長期佔用資源的情況

六、後記

任何技術通過小馬快跑發展到一定階段後，最終還是落地到是否能穩定的為業務提供服務，我們要做的就是抓住這個機遇和挑戰，不斷的在實踐中豐富和完善整個質量體系的建立，流程、規範、執行、監控是我們在業務開發中採取的策略，同樣適用於我們的資料開發，只不過是使用的工具不一樣罷了。
你們也有資料測試實踐嗎，歡迎一起來探討～

福祿ICH·質量保證部 福小龍