一、背景目標

首先，分享一下 B 站數(shù)據(jù)質(zhì)量保障的背景和目標。

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

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

這里想強調(diào)的一點是，數(shù)據(jù)質(zhì)量保障是持續(xù)發(fā)展的。只有了解不同階段的背景和目標，才能更好地實現(xiàn)數(shù)據(jù)質(zhì)量保障。

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

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

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

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

隨著業(yè)務的發(fā)展，對數(shù)據(jù)質(zhì)量保障的需求也日益增加。下圖中展示了一些來自與我們合作頻繁的團隊的反饋，這些反饋涉及到日常合作中經(jīng)常出現(xiàn)的問題。這進一步證明了數(shù)據(jù)質(zhì)量保障的需求隨著業(yè)務的發(fā)展而增加。

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

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

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

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

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

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

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

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

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

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

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

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

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

二、體系架構

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

1、質(zhì)量數(shù)倉建設

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

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

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

在質(zhì)量數(shù)倉的基礎之上，接下來是三個核心能力。

2、完備的質(zhì)量保障體系

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

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

第一部分是構建監(jiān)測體系。

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

第二部分是部門間的協(xié)同保障。

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

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

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

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

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

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

3、數(shù)字化驅(qū)動持續(xù)優(yōu)化

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

4、高效的故障處理能力 

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

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

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

三、案例分享

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在整個保障推進過程中，我們也發(fā)現(xiàn)了一些問題。

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

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

四、未來展望

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

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

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

五、問答環(huán)節(jié)

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

A:在B站，我們按照五個分級等級進行數(shù)據(jù)質(zhì)量保障，重點關注線上數(shù)據(jù)，如 BOSS看板和公司級分析產(chǎn)品?；诖?，我們制定了各個保障分級的規(guī)范標準。例如，針對線上服務的數(shù)據(jù)模型，我們制定了一系列質(zhì)量規(guī)則。除了基礎規(guī)則，如表組件的唯一性規(guī)則配置和表行數(shù)規(guī)則配置，我們還推進了基于該模型上游埋點數(shù)據(jù)的規(guī)則，如一致性校驗和跨省校驗。同時，針對最高優(yōu)先級的分級場景，我們還配置了及時性規(guī)則，以驗證線上服務的基線情況。對于較低級別的分級場景，我們僅配置基礎規(guī)則，以確?；灸Ｐ偷目捎眯浴?nbsp;

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

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

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

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

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