一、背景目標

首先，分享一下 B 站數據質量保障的背景和目標。

B 站數據建設的歷史演進可以分為四個階段。 

• 數據庫階段。在這個階段B 站處于初創階段，業務也在初步發展中，數據逐漸受到各方的重視。這一階段的質量保障重點在于設計測試用例、驗證數據正確性，并進行數據庫的監控和調優。
• 數據倉庫階段。這個階段的出現是因為隨著業務的發展，各方對數據的需求也日益增加，更加關注 OLAP 相關的需求。隨著業務的復雜性增加，我們意識到單一數據庫無法滿足需求。這一階段更加注重數據的完整性、準確性、一致性和及時性的保障。
• 數據平臺階段。隨著中國互聯網浪潮的興起，數據量急劇增加，隨之進入了數據平臺階段。在傳統的 OLAP 分析系統（如TeraData）和 SaaS 傳統分析系統中，面對大數據場景，數據無法有效地服務于應用分析體系。因此，我們逐漸引入開源生態系統，如 Hadoop 和相關開源組件。這個階段更加關注保障架構的質量，包括鏈路的可用性和數據加工鏈路的多樣性，以及實時鏈路。
• 中臺階段。不僅要承接前三個階段的數據和需求，還要著重解決業務問題和數據化的核心需求。在這個階段，業務逐漸多樣化，要求能力服務化和數據智能化。在質量保障方面，兼容了前三個階段的內容，并基于這些內容展開了一些延展討論。這將是接下來分享的重點。

這里想強調的一點是，數據質量保障是持續發展的。只有了解不同階段的背景和目標，才能更好地實現數據質量保障。

B站數據中臺當前數據架構如下圖所示。整體上分為四個層次，自下而上分別是數據源、數據平臺、數據中臺和數據應用。

數據源包括多個相關的服務系統，如賬戶系統、埋點系統、CRM 系統和第三方系統等。這些系統為我們的數據倉庫提供持續的數據，這些數據通過數據平臺進行集成，并具備離線和實時的能力，將數據導入到數據倉庫體系中。

在部分場景下，我們推進全域數據的中心化建設。在此基礎上，再進行相應的主題域拆解，這是互聯網行業常見的主題域劃分，包括用戶主題、交易主題、內容主題、營銷社區等。此外，我們還進行了更多類似于分析項的體系化建設。

在數據應用層面，可以簡單地分為 PC 端和移動端的數據應用。我們著重關注埋點分析看板，包括增長、運營、內容等方面的數據展示。我們可以看到數據的流轉管道，即數據管道，已經擴展得非常龐雜。與傳統的數據倉庫不同，質量保障不再僅僅基于單一的 OLAP 系統，而可能涉及多層次、多組件、多團隊甚至多部門之間的合作和溝通，以推進保障工作。

隨著業務的發展，對數據質量保障的需求也日益增加。下圖中展示了一些來自與我們合作頻繁的團隊的反饋，這些反饋涉及到日常合作中經常出現的問題。這進一步證明了數據質量保障的需求隨著業務的發展而增加。

我們收集到的反饋包括但不限于以下幾點：

首先，分析看板的頁面顯示數據沒有展示透出，這可能會影響用戶體驗。

其次，分析師可能會反饋某天的數據指標為零是否合理，因為這可能會影響他們的業務決策。

此外，開發同學也有數據質量方面的需求，比如夜間的值班報警電話頻繁響起，起夜率爆表等，這會嚴重影響同學們的正常作息。

基于以上情況，我們抽象出三個方面的核心保障痛點：

• 數據使用方，希望數據能夠按預期時間產出，并且數據準確可信。在故障發生時，希望能夠快速恢復，不影響正常使用。
• 作為數據建設方，我們需要根據業務發展的時間推演，確定哪些數據是用戶真正關注的，優先進行強保障，而對于長尾部分可以適當降級。開發同學也希望了解用戶對數據質量和時效性的具體要求。
• 管道方是與數據倉庫協同配合的兄弟團隊，他們對于流轉到其管道中的數據也有保障需求。因為作為數據鏈路的上下游相關方，任何一個節點出現問題都可能導致數據不準確，數據質量不達標。他們的訴求更多是在極端情況下的恢復響應要求以及不同場景的保障要求。

總體目標是通過持續改善數據質量，減少事故糾錯成本，降低數據使用風險，并提升業務服務滿意度。

讓我們進一步深入探討，了解質量問題產生的根本原因。我們進行了一些梳理，將其分為四個部分：

• 技術原因。數據經過多個層次的加工才得到最終結果，因此不同鏈路的標準制定對于數據質量至關重要。這包括模型設計的合理性，是否充分理解數據的業務含義，并根據此進行相應的數據加工，以獲得準確的結果。此外，數據采集和清洗過程是否符合標準規范也是關鍵。
• 業務原因。數據主要承載業務的表達。脫離了業務場景，數據往往就不再有任何價值。因此，如果對業務理解不到位，包括業務流程的變更沒有及時了解，都會影響最終數據質量的展現。
• 管理原因。首先，流程管理是否足夠完善是一個重要方面。其次，團隊成員是否具備足夠的質量保障意識也很關鍵。第三，獎懲機制的設立也是必要的。因為質量保障是一個嚴肅的話題，一旦出現問題，我們需要有明確的責任分配計劃，以引起大家對此事的關注，并確保日常數據的持續保障。
• 推進方面的原因。一旦確立了相關標準，我們需要將這些準則明確地推進到各個工作的細節中，以確保歷史相關問題不再重現。此外，長期的可持續優化策略對于數據質量的保障也非常重要。

根據以上對問題原因的梳理，我們總結了三個主要方向上的痛點： 

• 首先是整體數據質量保障的范圍和目標不夠清晰。這體現在各個團隊對需要保障的數據范圍缺乏清晰的認識，有些鏈路甚至沒有進行日常的保障。并且，保障分級不夠準確，導致無法區分不同能力投入的保障需求。隨著數據建設的推進，架構變得越來越復雜。保障目標沒有拆解到相關團隊，導致這些團隊沒有進行相應的保障工作，影響了數據保障的最終結果。
• 另一方面的痛點是無法衡量保障效果。我們上學時都對分數有著深刻的體驗，分數可以衡量學習的好壞。同樣的邏輯也適用于數據質量保障，但我們無法衡量我們的保障工作對整體目標的貢獻。其次是當前保障推進到什么階段，缺乏相應的指標來指導和持續優化，需要持續衡量的方法論。
• 第三個方面的痛點是整個保障機制的規范性還不夠完善，大多是單點保障。然而，當前的發展趨勢是數據上下游鏈路需要協同解決這些問題。

基于剛剛介紹的背景、痛點和發展趨勢，我們總結出了四個重點的保障目標。 

• 第一個保障目標是準確識別核心場景，并支持數字化的效果衡量，以提升待辦事項的信息化水平。
• 第二個保障目標是確保數據滿足四個基本原則：完整性、準確性、一致性和時效性。同時，還需要滿足各個用戶實際場景的定制化需求。
• 第三個保障目標是確保數據保障貫穿整個數據生命周期的全鏈路。包括事前、事中和事后，涵蓋數據的生產、傳輸、加工、組裝和服務等各個環節。
• 第四個保障目標是基于日常保障工作的經驗，沉淀方法論，并推進數據中臺相應的工具能力建設，支持在預防、響應、處理、恢復和復查等階段高效地解決問題。

二、體系架構

基于上述目標，我們以質量數倉建設為基礎，構建三大核心能力：完備的質量保障體系、數字化驅動持續優化，以及高效的故障處理能力。

1、質量數倉建設

首先，我們引入相關的保障服務數據，統一數據倉庫的建設，并依托數據中臺的能力快速構建數倉架構。完成數倉架構后，我們將以數倉質量數據為指引，描述相應的保障問題，并支持決策數據的使用。同時，數倉的數據將支持日常的數據檢測和分析等工作，以消除事前的問題。數倉還有一個核心的保障工作，即與相關團隊協商保障目標，并進行衡量和拆解。

整個架構可以分為四個層次，自下而上分別是數據源、數倉建設、分析項目建設和最終的應用。在質量數倉的數據源層，包括了告警服務、基線服務、DQC服務、血緣數據、事件管理和值班系統等相關的數據服務系統。我們將這些系統的數據統一導入到數倉中，并進行相應的分層建設。

在分層方面，我們進行了明細層、進度匯總層和高度匯總層的區分。在這些分層中，我們將保障效果的數據進行抽象，包括異常清單和告警情況，并進行相應的數據建設，最終呈現在看板上。這為數倉團隊和橫向團隊提供了數據能力，包括質量分運營看板、實時保障看板和告警歸因看板等一系列數據服務能力。

在質量數倉的基礎之上，接下來是三個核心能力。

2、完備的質量保障體系

第一個核心能力是完備的質量保障體系。目標是確保數據滿足用戶要求。各方需要對數據質量負責，并按照標準監控數據質量。我們會沉淀規則庫，為實現保障目標提供服務，并推進可持續改進計劃。

這一核心能力可以進一步拆解為三個部分。

第一部分是構建監測體系。

在這個體系中，我們將通過數據資產的定級來觸發加工鏈路的卡點校驗，并進一步監控數據風險點。這包括常見的數據保障實體、基線任務和模型，并通過這些來衡量數據質量的效果。其次是構建質量分衡量機制，并支持從多維度的視角進行衡量。最后是制定保障規則，并識別各個數據資產的待優化項。在這個過程中，有兩個重要的方面需要提及，第一個方面是卡點校驗規則庫，這個規則庫主要涵蓋完整性、一致性、有效性和及時性等與數倉傳統卡點校驗相關的內容，我們在此基礎上將進一步擴展到埋點、集成、加工、組裝、出倉和 API 服務等相關環節；第二個方面是建立事故歸因知識庫，這個知識庫主要用于歸因相關的問題，并結合告警和恢復工具的能力，提高用戶解決問題的效率，降低異常成本。 

第二部分是部門間的協同保障。

數據中臺的鏈路已經相對復雜，因此如何與數據中臺的上下游相關方協同合作，共同制定符合 SLA 保障標準的機制，并形成跨團隊的保障機制，是非常重要的保障環節。 

這里重點介紹夜間值班的情況。

夜間值班的流程包括：緊急跟進、原因定位、數據恢復和影響通知。數倉團隊的值班同學會觸發卡點校驗的告警監控。一旦觸發，我們會立即采取止損措施，并評估數據是否對業務產生潛在影響。如果有影響，我們會及時通知相關方，并將問題轉交給兄弟團隊進行跟進和數據恢復。恢復完成后，我們會再次通知相關業務方，并對整個事項進行歸檔。 

第三部分是推進日常運營。

日常運營化是指周期性地同步基于質量數倉產出的保障核心指標和目標的情況，確保其達到標準。同時，我們會定期回顧過去一段時間的歷史問題，并進行規則的沉淀和歸類，以避免類似問題的重復發生。我們會定期確定保障項目的效果，推動代辦人員進行相應事項的完善。 

在推進過程中，我們對保障目標進行了抽象，并確定了衡量和提升的方法。基于當前中臺的核心衡量維度，我們關注數據的完整性、一致性、準確性和告警響應度，以及監控的覆蓋率、作業穩定性、時效性和鏈路保障率等方面。我們還基于八個維度構建了質量分，滿分為 100 分，并將其拆分為多個維度。通過質量分，我們可以衡量當前保障工作的進展和目標。接下來，我們將基于質量分來分發待辦事項。例如，對于模型監控覆蓋率方面，我們會提醒相關人員進行相應的操作，如配置完整性檢查和逐漸重復檢查。

3、數字化驅動持續優化

第二大核心能力是數字化驅動的持續優化。在這一部分，我們主要關注在構建基于源數據的數倉體系后的決策判斷。我們的推進策略按照以下鏈路進行管控：首先是構建衡量指標，然后進行現狀分析的描述，接著基于數據發現問題并提出解決方案，最后持續跟進優化效果。整體目標是通過數字化的衡量來驅動質量保障，并持續提升保障效果。

4、高效的故障處理能力 

第三大核心能力是高效的故障處理能力。根據過去的保障實踐經驗，質量問題是難以避免的。在面對質量保障問題時，我們需要快速響應，將問題最小化，甚至在短時間內實現快速恢復，以確保用戶無感知。這是一個重要的方向。

基于此，我們進行了一些功能支持和方法論的設計。從數據開發的視角，提供了機械風險診斷、告警能力優化、故障恢復系統和規則配置系統等。另外，從底層服務的視角，致力于構建一鍵恢復的故障鏈路、分級全鏈路保障和統一運維值班機制。

目標是通過日常保障實踐來沉淀方法論，持續打磨產品能力，提升數據質量標準。同時，我們也致力于優化故障響應效率，降低夜間值班的成本。

三、案例分享

接下來，分享B站在保障方面的一個實際案例。

以上是數據開發的正常流程，包括任務上線、日常跑批的監控覆蓋以及可能觸發的告警。在發生問題后，我們會進行相應的響應和數據恢復，并推動問題的歸檔。

在開發階段，我們面臨的問題是線上待保障的任務較多。目前，我們已經有超過五千個核心任務，但整個保障事項的監控覆蓋率不足 50%。此外，我們還存在監控覆蓋缺乏審批規則和發布流程相對不完善的問題。

在值班階段，我們面臨的問題是值班響應的 SOP 流程不完善，跟進效率較低。夜間故障信息同步鏈路也不完善。同時，我們的夜間值班率較高，達到了50%左右。這意味著每周大約有三到四天需要有同學進行夜間值班來響應故障。由于故障經常發生，恢復時間較長，人力投入也較大。

在復盤階段，我們發現許多問題并不是由數倉的日常操作引起的，同時也有一些反復出現的保障問題。

總結起來，這些問題可以歸結為三個方面：數據鏈路過長且組件過多，不知從何處著手進行保障；當前的保障指標表現不佳，能推進到什么程度心里沒底；不知是否有推進套路可以借鑒。

在初始階段，大家的保障意識薄弱。隨著時間的推移，我們逐漸進入了起步階段，推進人員開始意識到保障的重要性。隨著保障工作逐步推進，形成了方法論，進而建立了相應的分級保障機制。之后逐漸進入了基于質量數倉的量化管理階段。我們可以基于特定的指標對事項進行拆解，并衡量數據目標的達成情況，從而推動持續優化的工作。

整個推進思路按照以下三個步驟進行推演：數據鏈路的拆解、保障分級的建設以及全生命周期的覆蓋。

在數據鏈路拆解環節，我們將中臺鏈路簡圖進一步抽象成數倉的建設流程。包括從埋點數據轉入數倉加工，數倉模型校驗和數據服務構建，API 構建，最終將數據出倉給服務應用。在這個過程中，我們還可以抽象出保障的數據實體。當前的中臺保障實體包括埋點、離線和實時項目任務，模型表、Kafka 主題，模型字段數據指標，數據基線以及數據基線 API 等相關實體。

保障分級建設。在許多公司和數倉建設的初期階段，對保障的意識可能不夠完善。隨著業務的發展，大家逐漸認識到質量保障的重要性。在實施保障分級的鏈路中，我們按照以下方法論進行迭代推演：確定分級標準，評估數據現狀，完成數據的分級，并基于分級推動持續優化。

預期的收益是能夠梳理出整個核心保障鏈路的數量，并推進重要分級保障場景的覆蓋率。通過這樣的工作，我們可以明確討論哪些數據是重要的，并與相關的上下游方制定相應的保障策略。剛剛我們也提到了保障分級建設的思路。

全生命周期的覆蓋。前文提到了基于數據實體的抽象，針對這些抽象后的實體，我們將跟進相應的事前、事中和事后的保障機制。

事前階段包括埋點數據的準備、開發階段的監控標準以及發布階段的準備工作。在事中階段，我們會進行卡點校驗、值班機制的執行以及事故的修復工作。在事后階段，我們重點關注事件的反饋、保障的衡量，進行事后復盤，并沉淀到知識庫中。

這里再介紹一個B 站保障中存在的痛點問題，即公司層面進行機房遷移工作時，對數倉保障施加了巨大壓力。由于各個組件服務的混部部署，機房遷移會導致極大程度出現告警，并且一旦出現告警，由于基礎服務的原因，會導致全鏈路的擊穿。

因此，在多重原因復合的情況下，進行告警原因歸類成為迫切需要解決的問題。項目挑戰在于單次告警計算涉及全鏈路，并觸發大量告警，同時涉及所有任務的 OWNER。在極端情況下，連續五周工作日的夜間值班率達到 80%以上。這種情況下，數據異常和修復成本都極高，峰值時達到單次事故 80+人天。

基于上述情況，我們首先將所有的告警梳理到數倉的相關鏈路中，并對其原因進行歸類。通過原因的歸類，進一步確定問題是由平臺方、工具方還是數倉相關原因引起的。基于這個歸類，我們建議優先推進解決這些主要問題，并與相關方對齊優化方案和規則的后續覆蓋。

通過保障體系的建設和推進，我們的整體保障情況符合預期。

事件數在三個季度的優化過程中呈下降趨勢，降低了 50%。事件捕獲率趨近于 100%，數倉起夜天數也呈下降趨勢，降低了55%。核心基線破線數逐步收斂，近三個季度中逐季累降。起夜人次相較于保障之前已經下降了59%。夜間耗時也下降了 86%。

結合保障分級的推進，我們也清楚梳理了核心場景的范圍，并進行了相應的保障率的推進，達到了 100%。

在整個保障推進過程中，我們也發現了一些問題。

• 保障的入手比較困難，因為保障事項本身具有一定的學習成本，并且涉及的范圍較廣。同時，如何選擇合適的推廣路徑也是一個較大的問題。
• 推進落地比較困難。目前，一些相關規范的推進仍然依賴人工的推動，需要有更好的方法來提高效率。
• 可視化效果不足。正如之前提到的，我們通過質量分來衡量保障情況，但還需要更好的可視化方式來展示結果。
• 工作仍然容易陷入"運動式治理"，缺乏可持續的效果。 

我們在 B 站數據平臺部門貢獻了方法論，并開發了相應的治理平臺。通過這個平臺，我們可以衡量規則、代辦事項以及未完成操作的同學，并嵌入到平臺組件中，以支持快速點擊、覆蓋和響應。

四、未來展望

未來的工作主要分為兩個方向。

• 第一個方向，持續擴大保障范圍，豐富保障策略，繼續踐行數據化驅動的方法，在保障存量可控的基礎上，持續提升增量覆蓋優化。
• 第二個方向，理論結合實踐，持續推進工具化能力迭代支持，完善溝通機制。 

最后，隨著質量保障工作的發展，我們希望從最初的手工操作階段逐漸進入信息化階段，進而推進到智能化階段。在智能化階段，隨著保障方法論和規則庫的沉淀豐富，通過產品化能力支持，最終做到質量保障可描述、好衡量、易操作。

五、問答環節

Q:數據質量分有八項規則構成，但每個表的規則、數量、規則重要性都不一樣。怎么做到所有表的拉齊?

A:在B站，我們按照五個分級等級進行數據質量保障，重點關注線上數據，如 BOSS看板和公司級分析產品。基于此，我們制定了各個保障分級的規范標準。例如，針對線上服務的數據模型，我們制定了一系列質量規則。除了基礎規則，如表組件的唯一性規則配置和表行數規則配置，我們還推進了基于該模型上游埋點數據的規則，如一致性校驗和跨省校驗。同時，針對最高優先級的分級場景，我們還配置了及時性規則，以驗證線上服務的基線情況。對于較低級別的分級場景，我們僅配置基礎規則，以確保基本模型的可用性。 

Q：文中提到了一個實時任務是部署在一個系統平臺的 Flink任務。如果不是在不同的平臺維護，怎么拉齊評估整體的數據質量？

A:在過去的一段時間里，我們重點推進了解決一個問題，即在不同平臺配置的情況下，我們無法獲取相關信息的挑戰。在B站內部，由于涉及跨部門的情況，不同部門的調度系統也存在不一致性。為了解決這個問題，我們的推進思路是將易購平臺的原始數據信息同步到質量數倉中，基于相同的鏈路進行規范和代辦事項的梳理。并按照規范的數據格式進行整理。整個鏈路可以復用，最終可以呈現類似于質量分和代辦事項的結果。

Q：復盤的時候出現最多的是什么問題？有什么加速排查的工具嗎？

A:第一個問題：在復盤過程中，最常見的問題取決于不同階段。在保障的初級階段，最常見的問題是告警爆炸或告警湮沒的情況，即告警數量非常多。在這個階段，我們面臨的問題是如何從大量的告警中提取有效的告警。針對這個問題，我們的重點工作是：首先，如何有效地降低告警數量，同時確保現有規則的生效和保障結果不受影響；其次，針對無效告警的原因進行進一步分析，以不斷調整保障規則的內容。有些規則內容可能會隨著時間和迭代的過程進行更替。

第二個問題：我們正在與協同的產品團隊和開發團隊一起重點推進，即加速排查工具的開發。這是為了解決告警數量過多的問題。我們的目標是建立一個事故知識庫，并基于該知識庫進行合理的告警分發。通過這個知識庫的分發，我們可以將告警合理地分發給相關的團隊，從而減輕數倉層面的值班壓力。這樣，相關團隊可以更快速地進行排查和處理。