B站的資料質量管理——理論大綱與實踐

「需求方經常說我們做的報表看起來資料不準，有什麼辦法嗎？」

為了解釋這個問題，我以我們團隊在資料質量管理中積累下來的方法，為他寫下四行字：

• 資料質量期望——業務需求想要把資料質量保障到什麼樣的標準

• 資料質量測量——怎麼評估資料質量水平的高低、是否達到標準

• 資料質量保障——為提升質量水平，達到質量期望，具體的保障實施動作和內容

• 資料質量運營——如何透過資料化運營，提高保障的成果與效率

這四行字，概括了我們在資料質量管理執行中的理論大綱。

「你在需求溝通時，瞭解對方的資料質量期望麼？」

資料質量是由需求定義的。它沒有絕對的對與錯，只有定性、定量的標準。我們需要事先了解需求方的質量期望，才能與需求方就「質量達標」的標準達成細節上的共識。

我舉個例子，我們經常遇到一種情況：我們明知這份資料存在問題，但依然選擇使用它。只要我們把這份資料的問題點丟擲，下游消費者理解並接受它的問題、並做好兜底方案即可。這種方式，是透過主動降低質量期望來避免資料事故。

要如何知曉對方的質量期望？

最好不要直接詢問：「你需要怎樣的保障，怎樣的監控？」因為需求方不一定是專業的開發人士，他們可能會遺漏，或者，他們無法用運維語言來表達。

於是我們設計了以下三組問題，在日常的資料需求溝通中，主動向需求方提問確認：

第一組：獲得質量期望

第二組：評估可能存在的風險

當然，對於風險的評估，上述問題只是冰山一角。

第三組：與需求方溝通一下業務知識認知

這些問題很容易想當然，同時，也是相當致命的。比如說，需求方需要影片稿件的CTR，恰巧我們早已做好了CTR指標，便直接提供給他使用了。但如果這位需求方理解的CTR和我們的統計口徑不一致呢？他得到了他期望的資料嗎？

質量期望的溝通，在什麼時機最合適？

從實踐中我們得出，獲得質量期望的最佳時機，是在需求溝通階段。這個階段還沒有大量資源、人力的投入，發生需求變故的成本最小。

所以我們將質量期望的資訊收集安排在需求預審環節。把上述三類問題組織成一個預審溝通模板，要求每一位參與需求預審的資料開發人員養成詢問質量期望的習慣。

經此溝通，能夠讓需求方有準確的業務認知，能夠建立我們與需求方、上游業務研發、下游消費者之間的質量期望與風險知曉的共識，能夠引導需求方降低質量期望，或引導業務研發消除當前的風險。

「你知道怎麼評估資料質量水平的高低，判斷質量是否達標嗎？」

既然資料質量沒有絕對的對與錯，只有可定性、定量的標準。那麼表達資料質量水平的方法，就是與標準所包含的規則做測量對比。可以稱之為資料質量測量。

既然要測量，我們首先要先設計測量規則。

規則的設計，決定了我們在質量測量過程中——能夠發現哪些問題、不能發現哪些問題。我們首先要明確哪些問題的暴露是需要的，哪些是不需要的。我們將規則拆分為基礎規則與個性化規則。

基礎規則：指可對大部分資料通用的規則。如，條數為0監控、主鍵重複監控等，這類異常在大部分場景都應當被暴露。

基礎規則通常無須自行設計，平臺會提供統一的配置，來保障基礎規則的覆蓋。

個性化規則：指每一份資料根據實際用數情況，做針對性設計的規則。

個性化規則要從質量期望中去提煉。我們用一個真實（經脫敏修飾）的質量期望案例來說明這個提煉過程。

我們有一份源自客戶端上報的【業務物件曝光與點選日誌】，它的下游消費者眾多，我們從消費者的質量期望中合併出一份最高期望（取規則的並集，且每個規則取要求最高的一項）。

【業務物件曝光與點選日誌】質量期望與規則提煉例項：

總得來說，質量期望一般來源於（1）場景和物件的特殊性、（2）業務流程和資料生產邏輯、（3）資料標準、（4）資料自身特點、（5）某時某地的業務背景。所以我們的測量規則也基於這些提煉。

規則又可以拆解為兩個部分：規則指標、規則判定。

比如【傳輸丟失率<某閾值】這條規則中，【傳輸丟失率】為規則指標，【<某閾值】為規則判定。

規則指標分類及舉例：

規則判定分類：

設計好規則，還要明確在什麼時機做質量測量。

我們把測量的時機分成三種，對應三種測量形式：初始化測量、驗收測量、生產測量。

為了讓這三種時機融入到團隊的開發工作中，我們將這三個時機與資料需求管理的流轉步驟掛鉤，要求需求流轉的交付內容中包含三次測量的執行報告。

• 初始化測量：

  發生在資料需求的預審期、或開發前期。以一次性資料探查的形式，探查一份新資料、或老資料的新屬性存在的潛在風險。這些風險可能是業務邏輯中的缺陷、或者未做標準化定義的隱患等，所以我們除了關注資料自身的測量結果，還要關注文件等上游資訊輸入。

  初始化測量，幫助我們規避低質量資料輸入到我們的生產鏈路。

• 驗收測量：

  發生在資料需求的驗收期。不但全新的資料需要全方位驗收，變更需求同樣需要。根據我們的事故經驗，超過90%的資料質量事故，是由變更釋出帶來的。

  驗收測量，幫助我們規避變更釋出帶來的資料異常。

• 生產測量：

  生產測量的配置和首次執行發生在需求交付前觀察期，日常執行發生在交付後的日常生產過程中。穩定的生產鏈路理論上有穩定的質量，但不可忽視偶發性的不穩定問題，比如底層元件異常、排程服務異常等。

  生產測量，幫助我們規避外界偶發性問題影響資料的產出。

有了質量測量，我們可以隨時透過規則的統計與判定，來長期監控質量水平、及時發現異常問題。

「如果質量測量的結果不理想，要做哪些事才能提升質量水平？」

資料質量水平的提升，是經由資料質量保障的實施才能實現的。這個「保障」具體要保障什麼？做哪些事來保障？

質量測量的規則是根據質量期望來設計，那麼相應的，測量報告中的指標異常，也要能告訴大家哪一條期望沒有達標。我們應當先針對未達標的期望來做保障的實施。

我們延續上一小節的【業務物件曝光與點選日誌】，來說明發現問題後保障實施的過程。

在質量期望中，對f5這個屬性有這樣一條期望描述：

而在真實的資料中，測量報告表明f5屬性的質量並沒有達到期望。即，f5這個屬性存在大量空值。

由於這是資料來源日誌，尚未經過ETL處理，可認為f5屬性異常發生在資料上報和資料整合接收的環節，再加上其他判斷條件，我們基本認定這個異常發生在上報環節。透過對異常資料的統計分析，進一步定位到這個異常只發生在某幾個頁面，其餘頁面都是正常的。接下來，我們就要做兩項實施來修復異常且使它不再發生：

1. 根據埋點異常修復流程，由客戶端修復這個上報異常。

2. 在測試環節補充這條測試用例，在後續的變更中，可透過該測試用例阻截異常。

在這個case中：

首先，我們有質量測量來監控資料的質量水平；

其次，我們有異常修復流程來修復它，解決本次問題，也有變更流程來測試它，避免同樣的問題再次發生；

接著，我們有明確的責任制度，在上述流程中，各個責任方知曉自己的執行責任；

最後，我們的各個責任方，有撥冗相應的人力工時資源，來將這個埋點的監控、修復、測試工作落地。

我習慣將質量保障的實施分為四個類別，缺一不可。

1）流程保障

為何要有流程？

在安全管理領域，極度注重標準操作流程的制定和實施。飛機乘務員關閉艙門的操作、化工廠轉運化學品的操作，都有嚴格的標準操作流程，而這些流程強大到能夠保障人員的生命安全。可見，流程保障是一種強有力的保障措施。

在我們的流程保障中，需要重點講述的是資料准入、釋出變更這兩個流程。

資料准入：

曾經發生過一個case，有一個新的產品A，在做埋點上報開發時，直接copy了另一個產品B的上報指令碼，導致用以區分這兩個產品的關鍵屬性appid上報為同一個值，從而影響了產品B的核心指標。

在這次case的覆盤中，我們提出，任由一個新產品、新場景隨意接入既存的重要埋點，顯然是不合適的。因此我們建立了資料准入流程。

准入流程的建立依賴幾個必要條件：

1. 經由准入流程分配的屬性值，須做雙向繫結驗證（上報側與埋點管理側）。

2. 經由准入流程分配的屬性值，上報時須由SDK或公共元件（如播放器）收斂，不可由接入業務自行填值上報。

3. 未經准入的資料，須能限制上報、或在上報後被限制接收、使用。

最終實際的流程參考下圖：

釋出變更：

超過90%的資料質量事故是由變更帶來的，這是我們在聊驗收測量時提到的一個事實。為此，釋出變更必須有一套流程來保障。

如圖所示，是一個簡略的埋點變更的流程。

2）制度保障

運維責任制度是必須存在的。它定義了每一份資料、每一類元件、每一項服務的責任歸屬認定邏輯，能夠確保任何資料在各個環節都有其質量保障的執行負責人。

運維分級制度也是必須存在的。它定義了每一份資料在全生命週期的各個環節，能得到哪一層標準的保障，且高等級資料一定能獲得比低等級資料更穩定的保障。

• 我們對分級的定義，會從以下幾個方面來評估：

• 涉及財報、營收、資損

• 涉及業務重大決策

• 涉及線上功能服務與使用者體驗

• 涉及有關部門監管內容

事故處罰制度是可以選擇的制度（當然我們推薦它存在）。它定義了異常發生後的過失成本。

我們的事故定義、事故等級的劃分，會從多種指標來評估：

• 資損的量級

• 客訴的量級

• 資料異常的幅度和時長

• 資料的可恢復性

• 資料異常的影響PV、UV

• 資料修復的人力工時成本

此外，在新的週期，我們也吸收了前幾個週期的經驗，除了消極壓力的處罰制度，還考慮增加積極鼓勵的獎勵制度。

3）監控保障

我們認為監控保障包含了四項工作：

1. 監視、監聽：長時間觀察資料生產的健康情況；

這個健康情況，包含大資料元件的穩定性、大資料資源使用用量、任務執行狀態、資料產出結果的校驗等。

2. 測量：即我們在前文所指的質量測量；

3. 督促：促使相關責任方去處理問題；

通常，透過群訊息推送、企業微信告警、電話告警等不同等級的資訊通知來實現。

4. 糾偏：輔助執行問題的處理。

告警原因分析、任務阻斷等功能，就屬於這一類。

4）資源保障

資源保障指的是針對不同運維等級的資源傾斜，且這裡的資源包含兩重意義：

• 物理資源：CPU和記憶體，磁碟容量，頻寬等。

• 人力工時資源：測試、校驗的執行排期、運維響應速度、異常修復順序等。

繼續回到【業務物件曝光與點選日誌】這份資料，來看一看我們對它的上下游鏈路實施了哪些保障。

「單份資料可以人工跟進保障實施情況，但成千上萬的資料，怎麼知道每一份資料該怎麼保障、有沒有實施、實施效果好不好呢？」

我們來思考一下執行質量保障措施的目的是什麼。質量保障的實施，其目的在於規避異常，它需要在每個上游環節中：

• 發現異常

• 攔截異常

• 處理異常

由此可見，它的基礎標準應當是：

• 確實發現了異常

• 確實攔截了異常

• 確實處理了異常

我們繼續思考，誰，在什麼時機，透過什麼方式，消耗多少人力工時，會造成多少損失？

任何一個人都希望能規避所有異常，且即使真的發生異常，也能在造成損失前處理完畢。那麼，我們要進一步提升它的標準：

• 在有限的測試、驗收工時裡最大程度攔截異常釋出

• 上游比下游先一步發現異常

• 異常的告警最早通知到能處理這個異常的人

• 在人力介入之前，系統率先自動攔截異常

• 處理人員以最短路徑、最小成本處理異常

• 不讓同樣的問題再一次重複發生

可以看到，質量保障的基礎要求體現在透過保障避免損失，進階要求體現在保障效率的提升。我們由此得到資料質量運營的兩個運營目標：

1. 降低事故損失

2. 提升保障效率

作為資料工作者，我們理所當然要透過資料化運營來實現我們的目標。為此，我們設計了質量運營的指標體系。

我們的質量運營指標體系是基於我們的治理指標體系建設模型，包含：治理目標、治理策略、治理評估。下述為我們最近幾個週期質量運營指標體系的概圖。

其中，治理策略矩陣代表著，我們需要對生命週期中每一個環節的事前、事中、事後，都去制定保障標準、設計執行策略的規則，以及提供相應的工具能力。

（一）制定保障標準

標準是一個執行參照。

告訴所有人怎樣算達標，按什麼流程最安全……等等。標準統一了我們在質量保障執行過程中的意識和行為，杜絕責任推諉。

保障標準來源於各類質量期望的彙總，其中公共的、通用的部分，應對所有使用者公示。它可能會經歷談判、妥協，最終達成意見的一致。它包含並不限於：

• 服務SLA標準

• 測試/監控覆蓋標準

• 異常響應時效標準

• 資源劃分標準

標準需要分級，不同運維保障等級，對映到不同的保障標準值。

團隊的人員精力、物理資源都是有限的，要在有限範圍內保障最重要的部分。

比如我們在前文提到的【業務物件曝光與點選日誌】這份資料，依照運維分級制度，屬於P0級。作為P0等級的資料，其資料時效保障為1分，響應時效要求是15分鐘。而其他P1級甚至更低等級的資料，時效標準就會逐級放低。

（二）設計執行策略的具體規則

規則是標準展開的細則。

比如我們將事件處理標準流程展開，當異常發生時，我們的標準流程是先止損、再修復。基於這個標準，假設【業務物件曝光與點選日誌】這份資料在某個環節出現異常，我們的細化規則是：

1. 該環節的異常處理人必須直接收到告警，並在10分鐘內響應；

2. 10分鐘內無響應，會上升至技術LD；

3. 收到告警後，先通知到能夠做災備切換的人員（最快、最短鏈路），再將資訊同步到該專案的應急響應群；

4. 異常處理人說明異常原因，評估修復耗時；

5. 根據該專案的災備啟動條件，災備執行人判斷是否啟動災備方案；

6. 修復問題；

7. 切回主方案。

這些規則使大家遠離誤操作，提高執行效率。也能讓一個新人快速上手，降低執行難度。

另外從中我們也看到，這項事件處理規則有幾個前提規則：

1. 需要有全鏈路的監控覆蓋

2. 需要有災備方案

3. 需要有告警升級機制和通知機制

（三）提供工具能力

目前，我們已經積累了一批工具，用於資料生命週期的各個環節，提供自動執行能力。

比如監控告警工具、基線管理工具、DQC管理工具、指標異動工具、運維操作工具等，可以在公眾號的其他文章中獲得詳細瞭解。

策略的執行需要評估效果好壞，以隨時調整策略規則、或改進工具能力。如何評估策略的執行效果，就需要我們做評估指標的設計。

評估指標的設計原則，一是必須從第一層目標指標拆解而來，二是能夠暴露出現狀中的問題點，三是能夠評估治理策略的執行進度，四是能夠評估效果收益。這樣的設計，使運營工作處於一個從指標中發現問題-問題解決後體現在指標中的持續性迴圈中，不斷逼近、最終完成目標。

在前面的質量運營指標體系概圖中，我們先將目標指標（事故次數）拆解為與事故直接相關的事故定級指標。

定級指標的值幅度降低，則事故次數就降低。

那麼，接下來我們要拆解定級指標的降低與哪些執行指標相關，這一步拆解，要與策略規則直接繫結。因為無法評估效果的規則，在執行上很難有說服力，不容易落地。

測試覆蓋率，與測試用例的實施繫結；監控覆蓋率，與監控配置的實施繫結；修復人時，與運維工具的提效最佳化繫結……諸如此類。

其中概念較抽象的指標，如監控覆蓋率這一項，它貫穿全生命週期，且在不同環節有不同的口徑定義。

比如在資料開發環節，我們要求所有P0級資料必須配置三大類監控告警（失敗、延遲、內容異常），且告警形式為電話告警 + 部門內升級。這些配置規則缺一不可，只有全部完成，才計作這份資料的“監控覆蓋完成”。透過每週審計監控覆蓋率，來控制我們在資料開發環節的監控保障實施。

在這裡，有一個告警有效性運營的真實案例，能夠解釋我們的資料化運營方式。

先介紹一下背景，我們認為，監控不是越多越好，且需要隨著業務變化及時調整監控規則。告警太多，會干擾執行人員的運維關注點，對告警產生麻痺或牴觸情緒，乃至錯過關鍵告警，降低異常發現率。

我們首先要確定在這個運營事項中，一個可持續的迴圈是怎樣的。根據前面提到的指標-問題-標準-實施迴圈圖，我們簡單列舉一下這個迴圈：

• 指標：需要有指標來暴露無效、未響應、缺失、越級等告警缺陷

• 問題：將這些缺陷視為一個待治理的問題

• 標準：定義有效告警的標準

• 實施：制定降低告警缺陷、提升有效告警的策略

為了便於理解，我先解釋一下告警效果的定義。

有效告警：命中規則，且確實命中異常，同時能促使處理人員快速介入。

無效告警：命中規則，但並未命中異常，通常是規則配錯、或業務活動導致。

未響應告警：命中規則，且確實命中異常，但無人響應，或響應人員無法、無權介入處理。

越級告警：資料運維等級較低，但配置了標準較高的告警形式，使起夜次數虛高。

誤告：未命中規則，工具誤觸發告警。

告警缺失：發生異常，但無告警。

第一步，制定告警反饋機制，督促owner對告警進行分級反饋。

第二步，建設告警模組的後設資料主題數倉，製作告警缺陷統計報表，給出待治理明細清單，推送治理資訊給清單中的資料owner。

第三步，制定有效告警標準、執行細則，督促owner給出治理優先順序，確定短期長期治理目標。細則參考下圖：

第四步，定期審計告警缺陷，更新待治理清單，分析執行進度、治理餘量、新增量的情況，逐步完成頭部高優的部分。

第五步，工具最佳化方案提出，阻截不合理新增量、自動化處理長尾餘量部分。

經過一個季度的運營，我們的告警缺陷從每週2000+例降低到100例以下，極好地改善了異常遺漏、夜間起夜、告警反饋成本等問題。

至此，我們的資料質量管理理論大綱就基本講述完畢了。而我們的資料質量管理必然還沒有做到頭，還有非常多的細節場景有待我們圍繞這個大綱去逐個解決。

下個季度、下一年，我們會不斷有新的質量話題拿出來討論。也許可以擴充套件廣度，比如將質量運營覆蓋到鏈路更前端的業務資料；也許可以下探深度，對埋點、任務鏈路等具體的保障物件做專題展開。相信我們能做得更好。