字節的挑戰與實踐

首先來看一個問題：“一家公司，數據體系要怎么搭建？”

• 方案一：整體規劃，系統架構驅動
• 方案二：問題出發，業務價值驅動

在字節跳動，我們選擇的是方案二，即從業務遇到的問題出發，重視落地結果與業務過程，去解決實際的治理問題。

基于這個理念，在數據治理過程中，字節跳動也面臨以下三個挑戰與機遇：

業務特點：業務發展快、場景豐富、數據量大且形態各異。 業務的線上服務及創新，都對數據有較強的依賴，核心業務數據延遲，質量問題將直接影響業務表現及發展。

組織特點：扁平化的組織模式，分布式的組織管理。 無行政手段或強組織約束，也無全局治理委員會，且數據從采集到應用全部的生產流程，沒有全局規范，業務團隊需要自主制定策略并落地。

文化特點： OKR 拆解與對齊文化，業務團隊有充足的目標定義與拆解權限，且任何人都可能有動機、有角色、甚至有權限去進行數據治理，導致數據治理的業務流程復雜

字節數據治理演進階段

字節數據治理演進階段分為 6 個階段：

業務第一原則： 堅持業務第一原則，解決業務實際遇到的治理痛點

優先穩定建設： 優先解決交付穩定，保障數據鏈路與產出穩定，減少交付延遲

保障數據質量： 核心鏈路質量管控，配置強質量規則，自動熔斷，避免全鏈路數據污染；加強事前檢查，從源頭加強質量控制；完善事后評估，為每一張表建立健康檔案，持續改進。

關注數據安全： 冗余權限識別，消除授權風險；數據分類分級，風險定義與多策略控制，減少安全風險

重視成本優化： 基于多種規則的與完備的治理元數倉，提供低門檻的治理產品能力，快速優化存儲

提高員工幸福感： 在幫助業務完成數據治理的后，還需要考慮團隊的負載壓力，報警治理，降低員工起夜率；歸因分析，快速排查修復故障。

在這里，再介紹字節特色的“0987”量化數據服務標準。這四個數字分別指的是：穩定性 SLA 核心指標要達到 0 個事故，需求滿足率要達到 90%，數倉構建覆蓋 80% 的分析需求，同時用戶滿意度達到 70%。按照這個高標準來要求自己，同時這也是一種自監管的機制，能夠有效的防止自嗨，脫離業務需求和價值。

字節的部分場景實踐

下面通過兩個例子為大家介紹數據治理在字節的場景實踐。

案例一：

• 問題：字節跳動內部 2019 年到 2020 年間，雙月內事故數量較多，對業務造成一定影響，且收斂困難，每天都有告警、起夜、對正常開發進度造成影響。
• 解決方案：采用了分布式用戶自治的 SLA 治理，通過數據分級保障目標管理，在各業務內部進行【拉齊鏈路-數據分級-廣泛共識-系統管理】的行動閉環，系統化保障目標傳遞和落地。
• 效果：截止 2020 年中，事故以每雙月 30% 環比下降，在 1 年內達到穩定性問題徹底收斂。

案例二：

• 問題：抖音的實時數倉治理人員的精力分散，以被動的運動式、“救火”式的工作模式為主。協同效率低，人力投入巨大，缺少可持續性。
• 解決方案：覆蓋質量、成本、SLA、安全等治理方向，以業務評估體系，構建治理方案進行例行診斷，對存量問題進行識別和派發，形成一套【評估->識別->規劃->執行->復盤】業務內部分布式自治的治理機制。
• 效果：從 21 年至今，治理人員的精力徹底從”運動式“治理的模式中解放出來，更多精力會集中在監督執行與規則優化中，團隊起夜率降低 30%。質量保障覆蓋率達到 100%。雙月存儲優化均在 20+PB。

數據治理的發展與分布式

眾所周知，有很多機構都分享了對數據治理的定義，這里簡單分享一下

國際數據管理協會（DAMA）：數據治理是對數據資產管理行使權力和控制的活動集合

IBM：數據治理是對企業中的數據可用性、相關性、 完整性和安全性的全面管理。它幫助組織管理 他們的信息知識和作為決策依據

維基百科對數據治理的定義：數據治理是一個涉及全體組織的數據管理概念，通過數據治理，確保在數據的整個生命周期中擁有高數據質量的能力，也是對業務目標的支持。數據治理的關鍵的重點領域包括可用性、一致性、數據完整性和數據安全性，也包括建立流程來確保整個企業實施有效數據管理。

在傳統的數據治理方法論與定義中，注意到他有以下共性特點，同時也是現在大多數公司的實踐路徑，即：

但是在實際的執行過程中，他需要以下幾個前提和隨之帶來的落地難點

1. 需要明確組織制度

梳理業務數據部門，設立公司級別數據治理委員會/部門，各業務分設執行部門，公司內各業務宣導討論，統一制定公司數據治理規章制度

難點一：組織依賴重、建設周期長。需要招聘大量專業的治理專家或引入外部咨詢機構，計劃制定周期長；專設部門牽頭，若無自頂向下的項目背景，業務協調對齊困難。

2. 需要明確權責管理

梳理公司數據資產，遷移、拆分、業務改造。確保資產歸屬與治理權責明確，定期梳理資產類目，維護資產元數據的有效性，確保治理邊界清晰

難點二：業務影響大，目標對齊難。需完成存量的資產歸屬劃分、改造生產開發體系，對增量定期人力打標，確保資產歸屬與權責邊界清晰，因可能業務系統改造，會對業務發展造成影響。

3. 需要進行復盤抽查

管理組織定期檢查各業務治理過程是否符合公司治理制度，定期檢查各項治理結果是否落地，線下復盤與推動不符合預期的治理過程

難點三：溝通成本高，執行推動難。如何制定適用于不同業務特點與發展階段的團隊的治理評估體系，各團隊是否認可評估標準。

為了解決以上三個問題，我們有些新的思考，即引入「分布式」的理念。

Governance 一詞在根源上同 Government，1990 年代被經濟學家和政治科學家重新創造，由聯合國、世界貨幣組織和世界銀行等機構進行傳播。其核心有以下兩種論述：

第一個論述：標準與規范。指的是一定范圍內的一致的管理，統一的政策，某一責任區指導以及合適的監管和可問責機制。這種行政力的集中化管理存在一些問題，比如決策成本高，人力投入高、落地阻力大，精力消耗大。

第二個論述：過程與結果。指的是只要關注結果和產出以及業務內部實踐，通過分布式協作讓業務的治理結果、業務痛點和治理方式及手段在內部閉環，而不是由中臺層面統一推動。

我們嘗試從第二種論述，即重視過程落地和治理結果產出的出發，更快的落地產品，落地數據治理的產品解決方案

從集中式到分布式

基于分布式的數據自治的理念，我們來解決在落地執行上的兩個最困難的點

一、組織制度分布式： 嘗試將組織的強管理屬性轉換到監督屬性，治理單元與制度設計回歸到業務單元。好處是，不強依賴橫向中心化組織，業務治理痛點閉環在業務單元，且業務基于自身發展階段制定治理目標，ROI 論證回歸業務。

二、權責驗收分布式： 基于產品體系與落地解決方案，支持業務按需自驅，市場化執行，平臺輔助與按需驗收。好處是，無須長周期的資產類目梳理，業務系統改造，權責均由業務區分，基于業務單元與多維視角，按需驗收治理結果，業務單元內對齊。

如上圖展示的餅圖，對于一個公司的數據資產，傳統來說，可以很清晰地按照業務邊界來劃分清楚。對于分布式數據治理，我們通常是由業務單元自行認領，業務單元 A 自行認領屬于自己部分，業務單 B 也自行認領屬于自己部分。認領就意味著，所有治理的動作包括結果，安全性、成本、質量、穩定都由認領業務單元負責。

當然，這樣這樣也可能存在兩個問題，不過在分布式的理念中能夠得到較好解決。

第一是認領范圍重合：這種情況往往讓業務在線下對齊是否需要去做改造和劃分，各自拿到自身需要的治理結果，短期無須重人力投入，不追求絕對的邊界劃分。長期因不同治理驗收需求或團隊管理需求，自行進行資產歸集和整理。達到動態的平衡狀態。

第二是無人認領：針對長期無人認領的資產，我們可以基于每個業務的歷史的規則和能力，形成一個治理的平均線，再從平臺層面推動無人認領的資產治理，由于無人認領，這樣的資產推動起來相對較快。

我們理解的分布式治理

定義：以業務單元為數據治理閉環單元，通過完善的產品工具，將管理視角轉化為監督視角，解決數據治理落地痛點；各業務團隊分布式自運行，整體上達到全局最優，從形態上，適配更多業務特性和發展階段，從效果上，強推進重落實與結果。

字節跳動通常以業務單元作為一個數據治理閉環，即在業務單元內部完成數據穩定性、質量、存儲、計算等治理。同時每個業務單元不是孤立的，也有相互協作，比如 A 業務單元的數據治理經驗可以沉淀為治理模板，供后續其他業務使用。

這樣的分布式治理方式，有以下一些優勢：

• 影響小，依賴小。治理下放到各個業務中，各級業務乃至個人都能自驅治理，業務根據自身發展階段靈活組合治理工具，無須對組織強依賴。
• 周期短，見效快。業務自驅梳理核心數據及鏈路，跨團隊對齊線上化、協議簽署、過程追蹤。治理周期顯著縮短，很快就出成效，增強團隊信心。
• 效率高，省人力。SLA 治理提高跨團隊協作效率，聚焦核心數據任務集中資源保障，集中精力，報警歸因減少起夜，幫助企業節省年度人力消耗。
• 算清帳，降成本。各業務口徑的存儲計算資源消耗、核算成本，制定降本目標并追蹤落地；業務經驗規則化、策略化、自動化、自驅化持續降本增效。

分布式自治架構

為達成業務分布式自治，產品需要對用戶行為路徑完全覆蓋，對業務經驗完全接受。平臺提供完善的開放能力，協助業務進一步提效。

產品體系

以上關于分布式的理解，下面將介紹字節分布式自治的產品體系。

從治理門戶來看，包括治理全景、工作臺、規劃、診斷、復盤等全流程治理環節。在治理場景中，提供數據質量安全、資源優化、報警、企業復盤管理等一系列垂直場景。在底層，包含數據全生命周期流程，從數據采集、數據傳輸、數據存儲、數據處理、數據共享到數據銷毀。

治理雙路徑

為了把用戶所有治理經驗沉淀為平臺能力，我們抽象了 2 種治理路徑。

• 第一種是規劃式路徑。這是一個比較常見的規劃式路徑，即從看板和報表出發，自上而下做規劃。比如看板已經反映出成本增加、延時變長或者數據質量變差，團隊管理者發起報告或事故，推動業務單元同事進行數據治理，最后進行復盤。
• 第二種是響應式。比如生產者收到一個數據質量或延時的報警，隨后快速定位原因并做改進計劃。

為了更好把業務經驗全部線上化，我們通常雙路徑并行使用。

規劃式治理路徑案例

首先看通用模塊資產視圖，包括資產增量情況評估等，以及業務對于資產的評價，如健康分體系。我們通常根據資產情況去制定目標。如果發現問題之后，業務驅動制定目標，可能是降低存儲。同時需要去應用一些業務規則，比如團隊內部認為 TTL (數據生命周期)很重要，需要幫助識別出來的同時也需要設定一個診斷周期。在團隊方案確認完之后，產品會做監督，包括定義提醒，同時也推動資產 owner 完成總結。

響應式治理路徑案例

例如，我們發現一些任務在深夜執行失敗了，需要先做問題排查，發現問題是 HDFS 丟塊導致。在傳統情況下，解決方案是去檢查 API 問題，再去拉相關人員，可能 2- 3 小時才能完成，最后配合監控并收歸到 wiki 中。而在 DataLeap 數據治理產品里，可以直接實現歸因打標等能力，最后快速復盤。

治理全規則

如果要覆蓋業務的全部屬性，治理平臺需要形成有效且全面的規則模板。目前，我們的規則模板包含兩個部分：

第一是 規則引擎 ，具體包括業務輸入、平臺輸入、推薦輸入。

• 業務輸入：主要依據業務團隊的治理經驗以及行業經驗。
• 平臺輸入：平臺會提供一些基礎能力，如存儲、計算、質量、報警等幾個維度。截至目前已經提供了 80 多個規則。
• 推薦輸入：基于業務輸入和平臺輸入，去做分析和挖掘，發現哪些規則用得多、哪些規則閾值更合理。

第二是治理數倉 ，具體包括行為數據、治理操作、效果數據。

• 行為數據：包括用戶規則配置等內容是否有重復以及帶元素標簽的資產數據等。
• 治理操作：包括生命周期、任務關閉、數據刪除、SLA 簽署等。
• 效果數據：包括操作收益、資產收益、指標收益等。

不同業務快速靈活接入治理規則

分布式自治基礎是要構建治理生態、建設開放平臺，讓不同業務能夠快速、靈活接入。

為了讓業務能快速介入，我們把數據分成了四種類型：表達式、三方元數據、標準元數據、算法包。針對不同的業務，根據當前的經驗和能力，我們會提供不同的接入方式，讓業務去更好把規則和能力去接入到我們的平臺。

基于業務單元進行智能化提效

在獲取不同業務的規則和能力之后，我們需要再做平臺能力沉淀，把好的規則和能力復用給更多業務。

Case 1：任務 SLA 簽署推薦。基于運營時間做權重分配，保證下游任務運行完成，同時也會進行關鍵鏈路分析。這個規則目前在字節內部廣泛使用。

Case 2：動態閾值監控。這是基于業務在報警閾值上的實踐提取的規則。

Case 3：相似任務識別。通過序列化和向量化操作，去和底層 spark 引擎做配合。在業務內部應用覆蓋 99%，且優化任務都千級以上，由此接入平臺并推薦給其他業務。

分布式自治核心能力

治理全景 - 分布式驗收

在分布式驗收中，會區分為全員視角、團隊視角和個人視角。全員視角可以看到公司級資產，包括整體的健康分體系以及核心指標。團隊視角中，主要由業務自己梳理，包括內部的評價體系。

治理工作臺 - 集中治理待辦

上圖為個人工作臺功能，主要為了把 SLA 保障、計算任務、數據存儲等治理場景展示在一個頁面，方便 owner 業務全局查看治理待辦事項。

治理規劃與診斷 - 權責與規劃分布式

第一，支持自定義治理域，靈活自治，提供多種維度，自定義組合和圈選資產范圍。

第二，支持創建治理方案，例行診斷：發起人基于業務需求，選擇治理域，設計治理規則，發起存儲/計算/質量等類型治理方案。例行診斷與推進實施。

第三，支持規則管理，提供 80+ 治理基礎規則，支持自定義組合和配置規則與分享。

復盤管理

復盤管理是一個通用模塊。業務根據自身需要去識別任務是否需要復盤，或者僅僅做問題登記。除此之外，業務還可以用復盤管理能力做內部管理，比如查看、檢索所有的事故復盤，查看每個事故發生的原因和改進計劃。同時，也可了解歸因分布情況，并幫助下一個值班同學快速反饋和定位問題。

SLA 治理

在字節跳動內部，SLA 不是平臺級保障，而是源于業務團隊內部。首先是業務按需申報，可能是 PM、運營或數據研發等任何角色，認為自身任務重要，填寫背景、原因、等級、時間等信息之后，即可發起一個 SLA。發起之后，在團隊內部進行審核，可能存在同一個團隊多個高優任務的情況，這由團隊內部自行調整優先級。同時，這個也是跨團隊判斷該任務重要性的標準。

之后是完成簽署，簽署也會在產品里面體現出來。每個節點時間都有實時監控，如果產生了延遲，會推動業務做復盤和登記。我們也提供基礎的 DAG，包括申報業務單的查看，同時也可以讓大家去查看每個等級的破線情況，以及團隊對業務的服務情況。

數據安全

在數據安全層面，主要專注于清理冗余權限，完善分類分級。不同團隊對冗余權限定義不同，有的 90 天無訪問算冗余權限，有的 70 天，有的 7 天。因此我們提供自定義能力，由業務內部發起 review，完成冗余權限的識別和定義規則，識別之后復用診斷能力。

資源優化

基于每個團隊實際執行情況，提煉出一些通用的規則。例如，某些規則可能有幾十個業務在使用，近 90% 認為近 30 天無查詢需要被識別出來，我們就會在平臺中提供這類能力，方便新業務或者小白業務去使用。

報警歸因

在報警歸因方面，我們能提供所有報警明細，方便查看是否有重復規則，是否有高頻報警規則，幫助用戶發現無效報警和重復規則，降低告警量和跟起夜率。除此之外，我們也提供業務內部的歸因登記和分析能力。