揭秘位元組跳動業務背後的分散式資料治理思路

　　導讀：經過十多年的發展，資料治理在傳統行業以及新興網際網路公司都已經產生落地實踐。位元組跳動也在探索一種分散式的資料治理方式。本篇內容來源於火山引擎超話資料直播活動的回顧，將從以下四個部分展開分享：位元組的挑戰與實踐；資料治理的發展與分散式；分散式自治架構；分散式自治核心能力。

　　 位元組的挑戰與實踐

　　首先來看一個問題：“一家公司，資料體系要怎麼搭建？”

　　方案一：整體規劃，系統架構驅動

　　方案二：問題出發，業務價值驅動

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

　　基於這個理念，在資料治理過程中，位元組跳動也面臨以下三個挑戰與機遇：

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

　　組織特點：扁平化的組織模式，分散式的組織管理。 無行政手段或強組織約束，也無全域性治理委員會，且資料從採集到應用全部的生產流程，沒有全域性規範，業務團隊需要自主制定策略並落地。

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

　　位元組資料治理演進階段

　　位元組資料治理演進階段分為 6 個階段：

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

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

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

　　關注資料安全：冗餘許可權識別，消除授權風險；資料分類分級，風險定義與多策略控制，減少安全風險

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

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

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

　　位元組的部分場景實踐

　　下面透過兩個例子為大家介紹資料治理在位元組的場景實踐。

　　案例一：

　　問題：位元組跳動內部 2019 年到 2020 年間，雙月內事故數量較多，對業務造成一定影響，且收斂困難，每天都有告警、起夜、對正常開發進度造成影響。

　　解決方案：採用了分散式使用者自治的 SLA 治理，透過資料分級保障目標管理，在各業務內部進行【拉齊鏈路-資料分級-廣泛共識-系統管理】的行動閉環，系統化保障目標傳遞和落地。

　　效果：截止 2020 年中，事故以每雙月 30% 環比下降，在 1 年內達到穩定性問題徹底收斂。

　　案例二：

　　問題：抖音的實時數倉治理人員的精力分散，以被動的運動式、“救火”式的工作模式為主。協同效率低，人力投入巨大，缺少可持續性。

　　解決方案：覆蓋質量、成本、SLA、安全等治理方向，以業務評估體系，構建治理方案進行例行診斷，對存量問題進行識別和派發，形成一套【評估->識別->規劃->執行->覆盤】業務內部分散式自治的治理機制。

　　效果：從 21 年至今，治理人員的精力徹底從”運動式“治理的模式中解放出來，更多精力會集中在監督執行與規則最佳化中，團隊起夜率降低 30%。質量保障覆蓋率達到 100%。雙月儲存最佳化均在 20+PB。

　　 資料治理的發展與分散式

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

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

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

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

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

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

　　需要明確組織制度

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

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

　　需要明確權責管理

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

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

　　需要進行復盤抽查

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

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

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

　　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 天無查詢需要被識別出來，我們就會在平臺中提供這類能力，方便新業務或者小白業務去使用。

　　報警歸因

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

　　以上是位元組跳動在資料治理相關實踐。目前，位元組跳動也將沉澱的資料治理經驗，透過火山引擎大資料研發治理套件 DataLeap 對外提供服務。作為一站式資料中臺套件，DataLeap 彙集了位元組內部多年積累的資料整合、開發、運維、治理、資產、安全等全套資料中臺建設的經驗，助力 ToB 市場客戶提升資料研發治理效率、降低管理成本。