編輯導語：管控治理類數(shù)據(jù)產(chǎn)品是更高能力要求的一個細分工種，它需要我們具備數(shù)據(jù)分析以及工具建設能力的同時，還需要我們擁有團隊統(tǒng)籌等多方面的能力。作者分享了他的數(shù)據(jù)治理策略，我們一起來看下吧。

一、前言

為什么想開這個話題，一是因為目前業(yè)內數(shù)據(jù)產(chǎn)品也基本完成了從0-1的建設工作，但主要集中在數(shù)據(jù)生產(chǎn)加工和數(shù)據(jù)應用分析兩側，對于數(shù)據(jù)管治方向的建設多分散在了包括安全、指標元數(shù)據(jù)、SLA等在內的各個環(huán)節(jié)，缺乏統(tǒng)一的規(guī)劃統(tǒng)籌。

筆者認為，數(shù)據(jù)產(chǎn)品可以分為工具類數(shù)據(jù)產(chǎn)品、業(yè)務分析類數(shù)據(jù)產(chǎn)品和管控治理類數(shù)據(jù)產(chǎn)品三類，而工具類數(shù)據(jù)產(chǎn)品和業(yè)務分析數(shù)據(jù)產(chǎn)品市面上也開始趨近飽和，但管控治理類數(shù)據(jù)產(chǎn)品其實是更高能力要求的一個細分工種，既需要懂工具建設也需要懂數(shù)據(jù)分析，還需要具備跨多團隊橫向協(xié)調的項目推動能力和策略運營能力。

二呢，筆者曾經(jīng)就做過一次失敗的大治理工作，也做過一次相對成功的安全治理工作，也參與過指標監(jiān)控、安全工具等的建設，所以也想把這其中那的成功和失敗的經(jīng)驗分享出來供大家參考。

二、概念定義

根據(jù)筆者的研究，目前業(yè)內數(shù)據(jù)治理總結起來一共分為兩類，一類是狹義的數(shù)據(jù)治理，是指數(shù)據(jù)指標口徑一致性的治理，此類數(shù)據(jù)治理主要是解決指標口徑的一致性，解決數(shù)據(jù)“不準”的問題，也由此引申出一些智能數(shù)倉、指標元數(shù)據(jù)工具，比如美團的起源、快手的蓋亞、阿里的dataphin等等。

另一類是指廣義的數(shù)據(jù)治理，是指包括數(shù)據(jù)指標口徑治理、數(shù)據(jù)安全治理、數(shù)據(jù)資源成本治理、數(shù)據(jù)資產(chǎn)元數(shù)據(jù)治理、數(shù)據(jù)產(chǎn)出治理等在內的大治理，此類數(shù)據(jù)治理是需要綜合解決數(shù)據(jù)從采集加工到應用分析再到銷毀全生命周期內的口徑、成本、安全、合規(guī)和產(chǎn)出問題。

在工具建設上，目前筆者看到的多是分散在數(shù)據(jù)安全、資產(chǎn)中心、SLA中心等不同的產(chǎn)品領域。

三、結論先行

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

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

數(shù)據(jù)治理主要面對三個問題，一是用戶心智培養(yǎng)問題，二是組織保障問題，三是系統(tǒng)提效問題。

所以，單純從組織保障層面發(fā)力會面臨效率和質量不高成本卻奇高的問題，單純從運營機制建設層面發(fā)力會面臨缺乏組織和工具來落地策略的問題，單純從建設工具發(fā)力會面臨缺乏組織抓手且找不到核心使用用戶，需求無法進入正向循環(huán)的問題。

以上問題一句話總結就是靠組織無法長期有效，靠運營無法落地實施，靠工具又缺乏用戶和需求持續(xù)跟進，因此，數(shù)據(jù)治理是一個需要組織保障、運營實施和工具建設三位一體跟進的工作。

第二，數(shù)據(jù)治理又是一個抓大放小的工程。

世界本質是一個熵增的過程，即任何事物本質是一個自發(fā)的由有序向無序發(fā)展的過程，這個既是人性也是客觀規(guī)律，而數(shù)據(jù)治理本質是減熵的過程，是建立秩序，因此任何的治理本身是逆人性和逆客觀規(guī)律的，需要源源不斷投入能量（資源）才能維持熵值平衡。

但問題就在于，人性天然有建設性和破壞性兩面，想要秩序的存在并維持下去，本身就是需要投入非常大的建設精力和成本的，而且這個成本還不是一成不變的，它是隨著公司資產(chǎn)的累加而增加的，也是會隨著公司戰(zhàn)略、制度和文化的革新變化而變化的。

因此，數(shù)據(jù)治理工程中追求完美主義是不可取的，我們要學會分類分級，學會判斷優(yōu)先級，學會抓大放小，允許有序和無序的并存。

四、問題分析

數(shù)據(jù)治理到底解決什么問題？或者說什么問題的存在才需要數(shù)據(jù)治理？首先，我們來場景化模擬下數(shù)據(jù)從誕生到銷毀的一生中遇到的主要問題。

場景1：小明是A視頻公司的策略產(chǎn)品經(jīng)理，工作職責之一就是分析用戶的特點和行為習慣，從而幫助算法工程師優(yōu)化視頻推薦策略，從而提高用戶對視頻APP的使用黏性。

這天，小明抽樣了部分用戶瀏覽行為數(shù)據(jù)，發(fā)現(xiàn)部分用戶單位時間內視頻切換速率較高，停留時長較短，且點贊和關注數(shù)都較少，小明猜測是算法推薦的質量有問題，小明找了算法RD，算法RD卻回復最近視頻推薦的準召率（準確率和召回率）沒有問題，并沒有出現(xiàn)下降，肯定不是算法的問題，是視頻內容質量的問題，或者是抽樣數(shù)據(jù)的問題。

小明很苦惱，為什么數(shù)據(jù)分析下來，小明覺得用戶對視頻的喜好度是不夠高的，但研發(fā)說準召率卻沒問題，那問題出在哪？

場景2：小紅是B咨詢公司的新來的數(shù)據(jù)分析師，最近她接到一個任務，需要為客戶的一個市場咨詢報告提供數(shù)據(jù)分析支持。

因此小紅從業(yè)務經(jīng)理那里了解完需求后，開始從公司數(shù)據(jù)庫和第三方數(shù)據(jù)庫獲取數(shù)據(jù)，但事情卻一波三折，就單單在業(yè)務數(shù)據(jù)分析的定義上就來回溝通了好幾次，業(yè)務經(jīng)理告訴小紅她想知道a指標的數(shù)據(jù)，小紅翻閱了前人關于a指標的統(tǒng)計口徑記錄發(fā)現(xiàn)，a指標居然有不下10個統(tǒng)計口徑，諸如a1字段在x1維度下的聚合、a2字段在x2維度下的聚合等等，到底應該遵循哪個規(guī)范？

結果咨詢一堆同學，發(fā)現(xiàn)每一個口徑都有特定的需求背景和定制化規(guī)則，這一通忙活。

場景3：小東是C公司的數(shù)據(jù)RD，最近他經(jīng)常半夜被各種數(shù)據(jù)跑批任務延遲和失敗告警給吵醒。

原來是公司最近要迎接618，活動量的爆炸式增長導致業(yè)務數(shù)據(jù)量的爆炸式增長，而業(yè)務報表的數(shù)據(jù)統(tǒng)計邏輯和背后的數(shù)據(jù)源卻沒有及時優(yōu)化，導致集群計算資源不足以支撐暴漲的需求而出現(xiàn)任務延遲或者失敗的情況，這個情況又影響了業(yè)務報表的數(shù)據(jù)及時展示，影響了公司各業(yè)務KP郵件報表的及時性。

場景4：小陽是D公司的安全運營，最近公司上線了一個新業(yè)務，和已經(jīng)上線的幾家公司形成了假正經(jīng)關系，然后他最近經(jīng)常收到市場情報反饋，競品公司能迅速感知到公司的投放數(shù)據(jù)和增長數(shù)據(jù)，到底是哪個環(huán)節(jié)出了問題，為什么競品公司能這么快知道公司核心數(shù)據(jù)機密，這讓他最近壓力倍增？

分析以上問題，場景1其實是數(shù)據(jù)指標準確性的問題，場景2的問題主要是數(shù)據(jù)指標規(guī)范性和唯一性的問題，場景3主要是數(shù)據(jù)產(chǎn)出及時性的問題，而場景4是數(shù)據(jù)安全性的問題，以上，筆者認為都屬于數(shù)據(jù)治理需要解決的問題。

五、治理目標

綜上，數(shù)據(jù)治理的目標主要是解決以下四方面的問題：

1. 規(guī)范治理：解決數(shù)據(jù)完整性、規(guī)范性和唯一性問題
2. SLA治理：解決數(shù)據(jù)產(chǎn)出及時性問題
3. 口徑治理：解決數(shù)據(jù)指標準確性和口徑一致性問題
4. 安全治理：解決數(shù)據(jù)采集生產(chǎn)應用各環(huán)節(jié)中賬號注冊認證、權限管理、安全審計和隱私保護等安全治理問題

六、策略概述

1. 成立數(shù)據(jù)治理委員會，提供立法和組織保障

• 成立治理制度執(zhí)委會，負責研究和出臺相關治理制度和規(guī)范標準，目標是促成公司內各個業(yè)務團隊達成共識，形成統(tǒng)一規(guī)范，避免信息孤島。
• 成立治理產(chǎn)品執(zhí)委會，負責梳理數(shù)據(jù)各環(huán)節(jié)的需求處理流程和業(yè)務流轉流程，負責各環(huán)節(jié)的治理工具建設，形成可執(zhí)行方案，然后報制度執(zhí)委會推行。
• 成立治理技術執(zhí)委會，負責數(shù)據(jù)各環(huán)節(jié)的技術定義、模型設計和口徑維護，對數(shù)據(jù)資產(chǎn)的落庫規(guī)范性和唯一性等負責。
• 成立第三方治理審計監(jiān)察組，負責治理效果的評估、badcase的運營跟進和事后追溯審計。

2. 建設數(shù)據(jù)治理套件，提供工具保障

• 建設資產(chǎn)治理中心，目標是為解決數(shù)據(jù)元信息的完整性、規(guī)范性、唯一性提供技術支持。
• 建設SAL治理中心，目標是為解決數(shù)據(jù)生產(chǎn)加工任務產(chǎn)出的及時性和任務調度的運維提供技術支持。
• 建設指標治理中心，目標是統(tǒng)一指標定義、指標生產(chǎn)和服務，解決指標口徑一致性和服務的效率問題。
• 建設安全治理之心，目標是為數(shù)據(jù)安全5A領域）（賬號、認證、授權、審計、隱私保護）的問題提供技術支持。

七、策略詳述

1. 流程保障策略

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

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

機制：如上圖所示，數(shù)據(jù)治理流程保障規(guī)劃整體解決機制上分為三個部分，分別是事前預防，事中監(jiān)控和事后處理。

• 第一部分的目標是盡量將潛在問題在未爆發(fā)前就消滅掉；
• 第二部分的目標是盡量將問題都找出來，減少影響范圍；
• 第三部分的目標是對暴露出的問題進行快速響應和解決，并總結經(jīng)驗。

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

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

（1）定義理想態(tài)

① 發(fā)現(xiàn)問題

• 召回率（覆蓋率）100%
• 準確率100%

指標釋義：

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

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

注意：理論上最理想的狀態(tài)就是一次監(jiān)控任務中，所有問題都被發(fā)現(xiàn)，且所有報警的數(shù)據(jù)中沒有摻雜虛報情況，也就是召回率達到100%，準確率為100%。

但是實際場景中，這樣的理想情況幾乎是不存在的！過度追求高召回率，監(jiān)控規(guī)則一定會設置的異常簡單，那往往會有很多正常的波動會被系統(tǒng)判定為“異常”。

同理，過度追求高準確率，監(jiān)控規(guī)則一定會設置的異?？量?，那自然被報警的數(shù)據(jù)都是存在異常的，準確率100%，但是這樣往往很多異常數(shù)據(jù)會被監(jiān)控系統(tǒng)給漏掉，漏報率就會異常的高！

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

② 解決問題

• 響應時長：24小時內響應問題
• 定位問題：3天內完成問題的定位
• 解決問題：2周內徹底解決問題

③ 數(shù)據(jù)通道質量

• 丟失率<0.1%
• 重復率<0.1%
• 延遲率<0.5%

（2）規(guī)范建設

① 唯一性

• 指標、緯度、模型、庫表、數(shù)據(jù)、報表的唯一
• ID唯一
• 名稱唯一
• 定義唯一
• 加工邏輯唯一
• 產(chǎn)出渠道唯一
• 相似的指標、緯度、模型、庫表、報表做減法，減少冗余

② 規(guī)范性

• 流程規(guī)范
• 需求→評估→處理→測試→上線→驗收環(huán)節(jié)嚴格執(zhí)行
• 數(shù)據(jù)和流程double check
• 測試、試驗驗證數(shù)據(jù)質量和流程執(zhí)行情況
• 日志、庫表、模型、報表、代碼有統(tǒng)一的設計和輸出規(guī)范，信息齊全、分層合理、資源使用合理

③ 完整性

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

（3）發(fā)現(xiàn)問題：監(jiān)控體系建設

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

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

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

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

• 日志
• 丟失率
• 庫表
• 丟失率
• 分區(qū)缺失
• 信息缺失（0、空值、NULL）

② 準確性

• 業(yè)務側
• 相同指標不同報表間建立交叉驗證
• 相同報表不同指標間建立邏輯驗證
• 相同報表相同指標建立波動驗證
• 技術側
• 埋點間的交叉驗證
• 多層庫表間相同指標交叉驗證
• 明細層和統(tǒng)計層建立數(shù)據(jù)量、行數(shù)、計算結果的比對驗證

③ 及時性

• 日志上報
• 有效上傳率
• 延遲率
• 資源使用
• 當前占用占比
• 剩余資源占比
• 任務調度
• 完成率
• 失敗率
• 延遲率

（4）問題分級

① 監(jiān)控分級

• 對業(yè)務的影響度
• 模型、庫表、報表使用熱度
• 作業(yè)耗時熱度
• 故障分級

② 預警分級

• 藍色預警
• 黃色預警
• 紅色預警

③ 報警方式

• 電話
• 郵件
• 短信
• 企業(yè)微信

（5）事后處理

① 問題跟蹤處理

• 問題分發(fā)（按業(yè)務、主題、部門等劃分問題歸屬）
• 問題跟蹤
• 問題原因追溯
• 問題解決排期
• 問題解決反饋

② 問題驗收

• 業(yè)務驗收
• 監(jiān)控系統(tǒng)驗收

③ 定責存檔

• 事故等級劃分
• 事故存檔

2. 組織保障策略

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

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

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

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

（1）成立數(shù)據(jù)治理委員會，提供立法和組織保障

• 成立治理制度執(zhí)委會，負責研究和出臺相關治理制度和規(guī)范標準，目標是促成公司內各個業(yè)務團隊達成共識，形成統(tǒng)一規(guī)范，避免信息孤島。
• 成立治理產(chǎn)品執(zhí)委會，負責梳理數(shù)據(jù)各環(huán)節(jié)的需求處理流程和業(yè)務流轉流程，負責各環(huán)節(jié)的治理工具建設，形成可執(zhí)行方案，然后報制度執(zhí)委會推行。
• 成立治理技術執(zhí)委會，負責數(shù)據(jù)各環(huán)節(jié)的技術定義、模型設計和口徑維護，對數(shù)據(jù)資產(chǎn)的落庫規(guī)范性和唯一性等負責。
• 成立第三方治理審計監(jiān)察組，負責治理效果的評估、badcase的運營跟進和事后追溯審計。

（2）項目落地實施劃分一系列項目小組

• 成立需求規(guī)劃小組，對所有業(yè)務需求的接待和規(guī)范負責
• 成立模型工程小組，對接數(shù)據(jù)應用PM，對數(shù)據(jù)從業(yè)務關聯(lián)到技術側的文檔和規(guī)范負責
• 成立質檢監(jiān)控小組，對數(shù)據(jù)業(yè)務測試和技術測試的實施負責，對數(shù)據(jù)上報的質量篩查負責，對數(shù)據(jù)質量的監(jiān)控負責
• 成立審計評估小組，對上報的問題評估定級負責，對問題的合理分發(fā)和處理進展負責
• 成立數(shù)倉工程小組，對數(shù)倉的規(guī)范建設負責，對問題的修復負責
• 成立應急響應小組，對緊急高優(yōu)先級的需求快速高質量負責

3. 運營思路

數(shù)據(jù)治理項目規(guī)劃地圖橫向一共分為機制、流程保障、細則、責任劃分、工具平臺和各個子項目模塊（包括日志埋點模塊、通道傳輸模塊、內容規(guī)范模塊、加工過程模塊、語義定義模塊）數(shù)據(jù)治理項目機制劃分為：事前預防——事中監(jiān)控——事后處理。

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

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

八、結語

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

作者：明明，美團數(shù)據(jù)安全與易用性工作組PM，在線教育行業(yè)雙師直播模式的第一批參與者，立志成為一名受人尊敬的產(chǎn)品經(jīng)理。

本文由@一個數(shù)據(jù)人的自留地 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議