火山引擎 DataLeap：揭祕字節跳動業務背後的分佈式數據治理思路

導讀：經過十多年的發展，數據治理在傳統行業以及新興互聯網公司都已經產生落地實踐。字節跳動也在探索一種分佈式的數據治理方式。本篇內容來源於火山引擎超話數據直播活動的回顧，將從以下四個部分展開分享：

  • 字節的挑戰與實踐

  • 數據治理的發展與分佈式

  • 分佈式自治架構

  • 分佈式自治核心能力

字節的挑戰與實踐

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

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

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

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

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

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

字節數據治理演進階段

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

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

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

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

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

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

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

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

字節的部分場景實踐

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

案例一：

案例二：

數據治理的發展與分佈式

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

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

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

維基百科對數據治理的定義：數據治理是一個涉及全體組織的數據管理概念，通過數據治理，確保在數據的整個生命週期中擁有高數據質量的能力，也是對業務目標的支持。

數據治理的關鍵的重點領域包括可用性、一致性、數據完整性和數據安全性，也包括建立流程來確保整個企業實施有效數據管理。

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

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

  1. 需要明確組織制度

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

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

  1. 需要明確權責管理

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

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

  1. 需要進行復盤抽查

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

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

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

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

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

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

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

從集中式到分佈式

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

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

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

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

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

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

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

我們理解的分佈式治理

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

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

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

分佈式自治架構

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

我們的產品體系

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

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

治理雙路徑

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

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

規劃式治理路徑案例

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

響應式治理路徑案例

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

治理全規則

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

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

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

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

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

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

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

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

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

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

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

分佈式自治核心能力

治理全景 - 分佈式驗收

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

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

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

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

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

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

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

覆盤管理

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

SLA 治理

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

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

數據安全

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

資源優化

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

報警歸因

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

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/QNJbGEf8wQfc8Ac4by_7fA

猜你喜歡