系統思考資料品質
|0x00 品質标準體系
在談一件事情的品質時，我們通常會想起ISO的标準，例如ISO9000，如果一件商品被打上了ISO的标簽，對于自己産品的品質，是一件最有說服力的證據。
那麼在資料領域有這種标準嗎？有，比如ISO8000、ISO9126、或者是GB/T36344-2018，但這些标準一來顯得太過于“重”，二來了解和尋找資料也是困難重重，三是按照這些規範來落地也不太現實。是以把其中精華的部分抽取出來，總結成幾項大的原則，再根據公司的實際情況，補充細節部分，對于資料領域的從業者而言，更為切合實際一些。
以ISO9126軟體品質模型為例，包含了6個大的特性和27個子特性，其中大部分移植到資料領域，通常也是适合的。
ISO9126品質體系如下圖所示：
|0x01 從資料視角思考7個一級特性
我們把ISO9126的一級特性拿出來，按照資料領域的了解，一條條過一下。
【功能性】
功能性提供了軟體/資料産品所需要的功能，包括适合、準确、互操作和保密安全。如果用通俗的語言解釋，就是資料要有、資料要準、資料要全、資料是安全的。能夠按照傳遞标準産出資料，資料是準确的，并且能夠滿足使用者的訴求，同時安全性要得到保證。
這些特性在很多文章中都有提到過，隻不過沒有提升到資料品質體系的高度來進行闡述。例如對于資料的一緻性而言，有很多地方都可以用到這個概念，比如CAP理論，比如資料庫的外鍵，比如逆向接口開發，等等。但資料一緻性所影響的，依舊是資料的準确性，那麼資料一緻性就應該是準确性的一種解讀，而不是一個子項。
【可靠性】
指産品在規定的條件下，在規定的時間内完成規定功能的能力。映射到資料系統中，便是資料使用者，在使用時，資料能夠按時産出。對應的要求，就是資料鍊路的可靠性，例如上遊資料是否按時産出、Job的排程是否正确，等等。
【易用性】
在指定使用條件下，産品被了解、 學習、使用和吸引使用者的能力。這一條是絕大多數資料從業者所忽視的一條，也就是自己做出來的報表，能否讓使用者讀懂，而不僅僅是做出了報表産出了資料。例如我們對于資料名額的定義，使用者是否接受，或者是我們所提供的數字，是否能夠真的反映了商業的變化，而不僅僅是為了統計而統計。對于使用者而言，資料的結果是否能夠被了解、是否滿足了自己的訴求，通常跟産品需求和項目規劃有關。
【效率】
在規定的條件下，相對于所用資源的數量，軟體産品可提供适當性能的能力。例如最近大火的實時數倉，例如老生常談的資料傾斜，就是效率的一種解讀。這些能力最終影響的，是軟體所提供的價值能力，因為提供的資料越實時、計算的問題越複雜，理論上可以帶來更多的價值增量。
【維護性】
在規定條件下，規定的時間内，使用規定的工具或方法修複成功的能力。對于網際網路這一類高速增長的業務而言，如果僅僅是為了滿足需求，采取了煙囪式的開發手段，那麼維護起來就一定是個災難。是以，提供資料的複用能力，就是展現維護性的重點。通常來說提升資料的維護性有兩個方面，一個是軟體本身，提供Cube這種預計算的能力，一種是開發過程，提高資料的模型品質，降低了解和維護成本。
【可移植性】
從一種環境遷移到另一種環境的能力。這個能力考驗的是資料架構或者工具的能力，例如當對于資料的要求從離線轉向實時，過去寫好的SQL代碼是否能夠完好遷移。或者是當開發架構從A遷移至B（Hadoop -> Spark / Storm -> Flink），所付出的成本有多少。
|0x02 資料品質定義的拆分
這些特點可以直接拿來用嗎？從概念上講，是可以的，但是卻并沒有延伸到我們的日常工作中，也就是停留在概念階段，那麼如何将我們的日常工作與這些标準結合起來，就是下一步要思考的問題。
從結果上來看，如果“使用者體感”不佳，也就是功能性出現了問題，都可以歸因為資料品質有問題，因為最終傳遞的是品質結果。而要解決這個問題，就需要思考資料開發的整個鍊路，也就是開發過程的可靠性。雖然開發過程中可能出現許許多多的意外，導緻了資料對不上/沒有準時産出/結果出現波動等情況，但它們的結果卻是相同的，就是“資料品質”不好。
是以，我們應該把資料品質進一步切分，分為“使用者可見”的資料品質，和“研發可見”的資料品質。解決“使用者可見”是“治标”，通過快速恢複結果的兜底方案，來解決使用者側的問題，解決一時的困境；而解決“研發可見”是“治本”，對研發過程中平台可靠、模組化清晰、資料安全等根本問題進行考量，解決長期的困境。
|0xFF “治本”，就要轉換觀念
大一點的公司都會配有資料測試團隊，但大部分的資料開發同學對測試沒有太強的感覺，因為不會像後端團隊那樣，被各種測試的流程卡住，總體上還是處于比較早期的階段：講效率、重産出、輕規範。
這個其實涉及到資料團隊的定位問題，因為我們更多的将自己定位成業務人員，是站在與産品/營運同一角度，來解決業務問題的，而不是像工程團隊那樣，以穩定性為第一要務，那麼要徹底解決資料品質的問題，首先就要将自己的身份定位轉換過來，以研發過程的規範為抓手，來統籌整個品質體系的建設。
那麼很多人要問了，我們考核的标準，不應該是價值的産出嗎？如果站在業務團隊的角度出發，是的，但如果站在工程團隊的角度出發，就不是。道理很簡單，對于工程團隊，資料品質和傳遞效率才是第一要求，至于業務的價值，占比就不應該太重。
如果我們将重心放在産出上，那麼對于資料出現的問題，往往傾向于用“治标”的方式來解決，例如動不動就降級、看不懂就不管、出了問題再解決。而隻有把重心轉向研發過程的管控，也就是考慮平台的性能是否滿足需求、排程系統設計的不合理如何解決、資料模型如何更加合理、資料事故如何有效複盤，才能真正的“治本”。
當然，這是一個一線工程師無法自己決定的決策，但不論如何，我們應該有這樣的意識，即當未來社會的發展向數字化邁進的時候，資料從業者也會産生分化，一部分人需要更多的考慮業務問題，而另一部分人需要更多的考慮品質問題。
但眼下，我們需要與測試的同學進行協作，先解決目前的問題，也就是資料測試流程的規範化，可以檢視淺談資料倉庫品質管理規範。
福利時刻
01. 背景回複「資料」,即可領取大資料經典資料。
02. 背景回複「轉型」,即可傳統資料倉庫轉型大資料必學資料。