為什么想開這個話題，一是因為目前業(yè)內數據產品也基本完成了從0-1的建設工作，但主要集中在數據生產加工和數據應用分析兩側，對于數據管治方向的建設多分散在了包括安全、指標元數據、SLA等在內的各個環(huán)節(jié)，缺乏統(tǒng)一的規(guī)劃統(tǒng)籌，筆者認為，數據產品可以分為工具類數據產品、業(yè)務分析類數據產品和管控治理類數據產品三類，而工具類數據產品和業(yè)務分析數據產品市面上也開始趨近飽和，但管控治理類數據產品其實是更高能力要求的一個細分工種，既需要懂工具建設也需要懂數據分析，還需要具備跨多團隊橫向協(xié)調的項目推動能力和策略運營能力；二呢，筆者曾經就做過一次失敗的大治理工作，也做過一次相對成功的安全治理工作，也參與過指標監(jiān)控、安全工具等的建設，所以也想把這其中那的成功和失敗的經驗分享出來供大家參考。

根據筆者的研究，目前業(yè)內數據治理總結起來一共分為兩類，一類是狹義的數據治理，是指數據指標口徑一致性的治理，此類數據治理主要是解決指標口徑的一致性，解決數據“不準”的問題，也由此引申出一些智能數倉、指標元數據工具，比如美團的起源、快手的蓋亞、阿里的dataphin等等；另一類是指廣義的數據治理，是指包括數據指標口徑治理、數據安全治理、數據資源成本治理、數據資產元數據治理、數據產出治理等在內的大治理，此類數據治理是需要綜合解決數據從采集加工到應用分析再到銷毀全生命周期內的口徑、成本、安全、合規(guī)和產出問題，在工具建設上，目前筆者看到的多是分散在數據安全、資產中心、SLA中心等不同的產品領域。

這次筆者就不賣關子了，直接拋觀點，筆者認為，數據治理戰(zhàn)略層面的設計總結就兩點：

第一，數據治理是一個系統(tǒng)性工程。

數據治理主要面對三個問題，一是用戶心智培養(yǎng)問題，二是組織保障問題，三是系統(tǒng)提效問題，所以，單純從組織保障層面發(fā)力會面臨效率和質量不高成本卻奇高的問題，單純從運營機制建設層面發(fā)力會面臨缺乏組織和工具來落地策略的問題，單純從建設工具發(fā)力會面臨缺乏組織抓手且找不到核心使用用戶，需求無法進入正向循環(huán)的問題。以上問題一句話總結就是靠組織無法長期有效，靠運營無法落地實施，靠工具又缺乏用戶和需求持續(xù)跟進，因此，數據治理是一個需要組織保障、運營實施和工具建設三位一體跟進的工作。

第二，數據治理又是一個抓大放小的工程。

世界本質是一個熵增的過程，即任何事物本質是一個自發(fā)的由有序向無序發(fā)展的過程，這個既是人性也是客觀規(guī)律，而數據治理本質是減熵的過程，是建立秩序，因此任何的治理本身是逆人性和逆客觀規(guī)律的，需要源源不斷投入能量（資源）才能維持熵值平衡。但問題就在于，人性天然有建設性和破壞性兩面，想要秩序的存在并維持下去，本身就是需要投入非常大的建設精力和成本的，而且這個成本還不是一成不變的，它是隨著公司資產的累加而增加的，也是會隨著公司戰(zhàn)略、制度和文化的革新變化而變化的，因此，數據治理工程中追求完美主義是不可取的，我們要學會分類分級，學會判斷優(yōu)先級，學會抓大放小，允許有序和無序的并存。

圖1：數據治理流程保障規(guī)劃示意圖

思路：如上圖所示，數據治理流程保障規(guī)劃整體思路參考PDCA循環(huán)，即制定詳細規(guī)范方案，然后去驗證并解決問題，接著檢查問題是否真實被根本解決，最后根據反饋再繼續(xù)爹迭代方案，進入下一個循環(huán)。

機制：如上圖所示，數據治理流程保障規(guī)劃整體解決機制上分為三個部分，分別是事前預防，事中監(jiān)控和事后處理。第一部分的目標是盡量將潛在問題在未爆發(fā)前就消滅掉；第二部分的目標是盡量將問題都找出來，減少影響范圍；第三部分的目標是對暴露出的問題進行快速響應和解決，并總結經驗。

整體流程：如上圖所示，數據治理流程保障規(guī)劃整體流程上將以解決數據質量六性問題（唯一性、規(guī)范性、完整性、準確性、及時性、安全性）為目標，按照“規(guī)范建設-質檢審查-發(fā)現問題-評估問題-解決問題-驗收問題”的閉環(huán)流程，貫穿整個事前、事中和事后的環(huán)節(jié)。

具體實施：如上圖所示，數據治理流程保障規(guī)劃的具體實施細則上，會重點依托易龍的“數據治理五大項目模塊”，然后每個模塊都按照“規(guī)范建設-質檢審查-發(fā)現問題-評估問題-解決問題-驗收問題”的閉環(huán)流程進行梳理和規(guī)劃。

① 發(fā)現問題

召回率（覆蓋率）100%

準確率100%

指標釋義：

召回率（覆蓋率）：召回率又叫覆蓋率，是指所有真實存在的問題中，系統(tǒng)或者人工檢測出的問題占比。例如一共100條數據，其中20條存在異常，系統(tǒng)報警顯示有30條存在問題，事后被驗證30條報警中真實存在問題的有10條，則召回率（覆蓋率）=10/20*100%=50%。

準確率：是指所有被系統(tǒng)或者人工檢測出的問題中，真實存在問題的占比。例如一共100條數據，其中20條存在異常，系統(tǒng)報警顯示有30條存在問題，事后被驗證30條報警中真實存在問題的有10條，則準確率=10/30*100%=33.3%。

注意： 理論上最理想的狀態(tài)就是一次監(jiān)控任務中，所有問題都被發(fā)現，且所有報警的數據中沒有摻雜虛報情況，也就是召回率達到100%，準確率為100%。但是實際場景中，這樣的理想情況幾乎是不存在的！ 過度追求高召回率，監(jiān)控規(guī)則一定會設置的異常簡單，那往往會有很多正常的波動會被系統(tǒng)判定為“異?！?；同理，過度追求高準確率，監(jiān)控規(guī)則一定會設置的異?？量蹋亲匀槐粓缶臄祿际谴嬖诋惓５?，準確率100%，但是這樣往往很多異常數據會被監(jiān)控系統(tǒng)給漏掉，漏報率就會異常的高！

因此，優(yōu)秀的監(jiān)控系統(tǒng)都是根據實際場景一直在找尋召回率和準確率間的平衡點。

② 解決問題

響應時長：24小時內響應問題

定位問題：3天內完成問題的定位

解決問題：2周內徹底解決問題

③ 數據通道質量

丟失率<0.1%

重復率<0.1%

延遲率<0.5%

① 唯一性

指標、緯度、模型、庫表、數據、報表的唯一

ID唯一

名稱唯一

定義唯一

加工邏輯唯一

產出渠道唯一

相似的指標、緯度、模型、庫表、報表做減法，減少冗余

② 規(guī)范性

流程規(guī)范

需求→評估→處理→測試→上線→驗收環(huán)節(jié)嚴格執(zhí)行

數據和流程double check

測試、試驗驗證數據質量和流程執(zhí)行情況

日志、庫表、模型、報表、代碼有統(tǒng)一的設計和輸出規(guī)范，信息齊全、分層合理、資源使用合理

③ 完整性

日志、庫表的元信息完善，灰度測試階段只有空值率、異常值占比、分區(qū)缺失等指標合格后方可上線發(fā)布

如圖2和圖3所示，對于重要級別的日志、指標、庫表數據，除了粗粒度的質檢外，還需要每天進行更加嚴格和科學的監(jiān)控，以提前發(fā)現問題并推動解決：

圖2：數據埋點質量監(jiān)控報表

圖3：數據指標準確性監(jiān)控報表

① 完整性（是否缺失或不可用）

日志

丟失率

庫表

丟失率

分區(qū)缺失

信息缺失（0、空值、NULL）

② 準確性

業(yè)務側

相同指標不同報表間建立交叉驗證

相同報表不同指標間建立邏輯驗證

相同報表相同指標建立波動驗證

技術側

埋點間的交叉驗證

多層庫表間相同指標交叉驗證

明細層和統(tǒng)計層建立數據量、行數、計算結果的比對驗證

③ 及時性

日志上報

有效上傳率

延遲率

資源使用

當前占用占比

剩余資源占比

任務調度

完成率

失敗率

延遲率

① 監(jiān)控分級

對業(yè)務的影響度

模型、庫表、報表使用熱度

作業(yè)耗時熱度

故障分級

② 預警分級

藍色預警

黃色預警

紅色預警

③ 報警方式

電話

郵件

短信

企業(yè)微信

① 問題跟蹤處理

問題分發(fā)（按業(yè)務、主題、部門等劃分問題歸屬）

問題跟蹤

問題原因追溯

問題解決排期

問題解決反饋

② 問題驗收

業(yè)務驗收

監(jiān)控系統(tǒng)驗收

③ 定責存檔

事故等級劃分

事故存檔

圖4：數據治理組織保障規(guī)劃示意圖

責任劃分：以“規(guī)范建設-質檢審查-發(fā)現問題-評估問題-解決問題-驗收問題”的閉環(huán)流程為切入點，將“需求規(guī)劃組、模型工程組、質檢監(jiān)控組、審計評估組、數倉工程組、應急響應組”分別配屬到對應的環(huán)節(jié)中去，以提供流程執(zhí)行的組織人力保障。

平臺支持：重點建設埋點管理平臺、元數據管理平臺、質檢監(jiān)控平臺、工單管理平臺，為各流程環(huán)節(jié)中的組織人效提供幫助和支持。

具體實施：如上圖所示，數據應用PM、數據平臺PM和模型工程師將對整個數據治理組織和平臺的健康高效運轉負責，并對其向數據治理委員會匯報。

成立治理制度執(zhí)委會，負責研究和出臺相關治理制度和規(guī)范標準，目標是促成公司內各個業(yè)務團隊達成共識，形成統(tǒng)一規(guī)范，避免信息孤島

成立治理產品執(zhí)委會，負責梳理數據各環(huán)節(jié)的需求處理流程和業(yè)務流轉流程，負責各環(huán)節(jié)的治理工具建設，形成可執(zhí)行方案，然后報制度執(zhí)委會推行

成立治理技術執(zhí)委會，負責數據各環(huán)節(jié)的技術定義、模型設計和口徑維護，對數據資產的落庫規(guī)范性和唯一性等負責

成立第三方治理審計監(jiān)察組，負責治理效果的評估、badcase的運營跟進和事后追溯審計

成立需求規(guī)劃小組，對所有業(yè)務需求的接待和規(guī)范負責

成立模型工程小組，對接數據應用PM，對數據從業(yè)務關聯到技術側的文檔和規(guī)范負責

成立質檢監(jiān)控小組，對數據業(yè)務測試和技術測試的實施負責，對數據上報的質量篩查負責，對數據質量的監(jiān)控負責

成立審計評估小組，對上報的問題評估定級負責，對問題的合理分發(fā)和處理進展負責

成立數倉工程小組，對數倉的規(guī)范建設負責，對問題的修復負責

成立應急響應小組，對緊急高優(yōu)先級的需求快速高質量負責

數據治理項目規(guī)劃地圖橫向一共分為機制、流程保障、細則、責任劃分、工具平臺和各個子項目模塊（包括日志埋點模塊、通道傳輸模塊、內容規(guī)范模塊、加工過程模塊、語義定義模塊）

數據治理項目機制劃分為：事前預防——事中監(jiān)控——事后處理

數據治理項目流程保障劃分為：規(guī)范建設→質檢審查→發(fā)現問題→評估問題→解決問題→驗收問題

圖5：數據治理項目規(guī)劃地圖

本期主要從數據治理的問題分析、治理目標和治理策略進行了闡述，下期起將重點介紹數據治理涉及的相關工具和平臺建設，包括資產治理中心、SLA治理中心、安全治理中心和指標治理中心等，歡迎關注~