一. 機遇與挑戰

數據治理工作有很多挑戰，最主要的一點是落地比較困難。

首先，治理工作中與業務有一定的矛盾。

第二，治理涉及的組織和管理難度大。

第三，規范“人”的動作難度大，治理過程中，需要依靠人來推進和執行，人員能力參差不起，組織文化、目標也存在不對齊的情況。

第四，缺乏適配性強的產品工具。因為治理工作范圍廣，鏈路長，并且涉及跨部門、跨系統的目標對齊，需要一個完備的產品平臺。

下面結合字節的特點，介紹數據治理工作的機遇和挑戰。

• 字節文化

首先，字節業務多，多業務齊頭并進發展，需要快速響應業務需求；

第二，字節的 OKR 文化，使得每個人都可以參與數據治理的規劃和策略的制定，并且主動尋找實現路徑，快速對齊；

第三，為追求高效治理，沒有設立統一的數據治理委員會，而是各個部門根據各自的業務情況進行治理。

• 業務第一

字節業務規模大，并且以數據作為驅動構建閉環的產品較多，導致數據質量對業務的影響非常大。

綜上所述，數據治理在字節是挑戰機遇與并存的工作。

二. 數據治理思路

2.1  新型數據治理 - 分布式數據自洽

針對上述問題，提出了分布式數據自治的思路, 綜合考慮治理收益、業務影響，執行效率。

首先，業務影響方面，為保證影響小，治理工作按照業務單元進行。一個業務單元可能是一個小團隊或者小項目，作為數據治理的范圍和目標。

第二，需要沉淀各業務線的治理經驗，提升治理效率；通過產品輔助業務自驅，實現規則化、策略化、自動化治理。通過工具等平臺能力，降低治理門檻。并且支持靈活的治理方式，如管理者視角，自上而下規劃性治理，和一線執行者視角，自下而上推動治理。

第三，需要適配性強，建設產品來覆蓋治理全鏈路。

實現多種場景中，產品都有能力覆蓋，多個模塊可以獨立使用，按需組合；并且提供完整的開發能力，支持業務根據自身特點和發展階段，自行接入。

2.2  集中式 VS 分布式

分布式治理，與傳統集中式治理相比，有很多優勢。

• 集中式治理，需要制定制度進行大范圍組織，劃分權責，定期抽查考核，建設周期長，適配能力弱，并且組織投入多。
• 分布式自治，業務影響??；周期短，見效快；效率高，節省人力；便于算清對業務的收益，降低成本。

三. 技術架構演進

針對上述思路，平臺工具如何支撐數據治理？

3.1  解決方案 - 一站式

首先提出了一站式的解決方案。將治理劃分為三層。

• 第一層 - 視圖層

從資產視角、管理者視角 、實施者視角 縱覽數據治理的情況。

• 第二層 - 方案層
• 針對治理過程，提出了雙路徑。

• 路徑一【主動規劃】規劃式流程

• 主要解決的問題是：確定目標后，如何推進執行。將治理目標，拆解成治理規則，進行診斷，根據診斷結果，執行治理。治理結束后，通過收益統計、改進計劃等進行總結。

• 路徑二【系統發現】響應式流程

由系統發現的問題，通過高警等形式，通知到資產責任人，進行處理。通過根因分析等，進行總結。

• 第三層 - 工具層

為上述兩層，提供完備的治理工具。覆蓋質量、安全、成本、穩定性、報警與起夜等場景，通過打通基礎服務，賦能上述兩條治理路徑。

3.2  平臺建設 - 治理方案 - 規劃式流程

接下來將為大家介紹，在治理過程中，我們兩條路徑的具體建設過程。

路徑一：規劃式治理

目標是資產清晰，規則豐富，動線完整，收益準確。

首先需要制定目標，包括健康分目標，以及降低存儲、計算資源的目標。針對目標，建立治理方案，包括劃分治理域，以及在治理域內通過規則，發現有問題的資產。建立方案后，由系統找到有存儲、計算等問題的明細。對上述找到的問題進行分析，通過消息催辦等方式，將問題下發到責任人，進行治理。系統會對治理的效果進行采集，反饋目標達成情況，并對一段時間內的治理結果進行驗收和統計。

以上是規劃式流程的主線思路 。

下面介紹如何實現規劃式流程的幾個目標。

3.2.1 資產清晰

主要從治理全景和健康分兩個方面對資產進行描述。

第一，治理全景。 從各個維度，通過明細、統計量，對團隊或個人資產的具體情況進行描述。如各個表占了多少存儲空間，計算資源使用情況，任務報警率、起夜率，數據及時性和質量等。

第二，對資產健康度進行衡量。 根據三個層級建立了健康分體系。第一層是根據治理的垂直方向劃分，包括：存儲健康分、計算健康分、質量健康分等。第二層在第一層的維度下，細化了問題大類。如存儲方面，包括：無效存儲、異常存儲等；質量方面，包括：及時性、報警、元信息配置規范等。

在第二層的劃分下，將具體問題通過標簽定義，得到了第三層。比如無效存儲方面，涉及了 TT 不合理、熱度方面信息(xx 天無查詢)等。

綜上，主要通過健康度和治理全景將資產清晰地表述出來。通過元數據倉庫，進行底層數據的建設。

3.2.2 規則豐富

目前平臺具備了完備的治理規則，涵蓋了存儲、計算、質量、報警 4 大維度，50 多個規則。

其中包括全局規則，如：生命周期永久、近 7 天產出為空、暴力掃描任務等；也包括一些自定義的規則，如生命周期 xxxt 天，近 xxx 天產出為空等。同時還兼具了一些挖掘類規則，包括基于統計信息進行聚合后形成的規則，以及基于資產（包括庫、表等）相似性，通過關聯、排序來發現問題。

規則部分以及能力建設方面分為以下幾部分：首先通過底層與平臺基礎組件打通，將數據收集上來，形成數據倉庫的基礎層；基于基礎層對數據資產進行畫像描述，進一步形成特征域，做特征挖掘和關聯分析；然后將應用的數據，放到數據服務中，對外提供靈活的數據查詢能力。

最上層為組合在線的規則引擎，將數據和規則進行聯動，應用于規則建設。

3.2.3 動線完整

標出有問題的資產后，如何盡快完成治理，減少和業務的沖突，提高效率非常重要。

基于治理平臺的能力，在各個垂直場景中，我們建設了比較完善的治理動線。

大致的思路是，把能力劃分為幾類：

• 任務治理方面，和任務開發、任務運維平臺打通，支持任務的關閉、調整、調參，鏈路優化等；
• 庫表規范方面，和元數據平臺聯動，實現表管理、庫管理、資產移交、屬性修改等；
• 生命周期方面，通過治理平臺，和底層的存儲（包括 hdfs, hive 等組件）打通，形成閉環式的治理；
• 在數據質量方面，包括 sla 的及時性，離線、實時數據的監控，會和具體的質量規則平臺進行強聯動，互相登記數據、進行 sla 的簽署、和強跳轉交互等。

以上是動線完整的部分，能夠使用戶在平臺中，通過很低的操作成本，完成一站式的閉環治理。

3.2.4 收益準確

第四個是收益的準確部分。

我們做了治理后，付出的人里成本、精力、怎么知道是有效或者達標呢？如何衡量這一階段的工作是有價值的，治理是有收益的？這就需要在平臺建設上，準確度量收益。目前統一建設了基于事件中心的底層框架。總體來說，就是定義數據的消費模型，通過上面的一些消息通道，來定時收集各個平臺操作的消息；同時定義了事件的 SDK, 并兼容 API 的方式，靈活對接上游不同的平臺。

目前來說，我們和研發平臺、元數據平臺、質量平臺等，大部分都是通過消息訂閱和消費的方式，將治理的事件，接入到事件中心里，并將事件中心的離線數據 dump 到數據倉庫，進行離線加工，同時我們會將最新的事件，注入在線的元數據服務中，來及時完成治理收益的計算。

3.2.5 技術架構

在規劃式流程的技術方面，遵循的原則是：統一的數據查詢、各種規則靈活組合，操作結耦，治理收益準確。

整體的平臺后端，會負責分發和轉換治理的各種邏輯，包括查數、設置目標、健康分的展示和透出，治理的操作等。

后端平臺拿到消息后，會做具體事件的拆分。比如說看板類查數的部分，統一將需求發送到查詢服務里，數據查詢服務會對底層存儲做適配，通過點查、list、聚合類的查詢，根據底層選取的存儲引擎的特點，解析后，選取不同的底層存儲。

規則引擎服務部分，可以與數據查詢服務聯動。通過數據查詢服務取到數據后，通過規則的定義形成標簽，這個過程可以抽象成一個服務。這個服務對外可以提供對資產標簽的描述，作為通用的能力。

在治理的具體實施部分，我們統一抽象成一個后臺的模塊。具體的實施，如設置消息、設置 ddl、進行刪除等，統一由這個模塊下發到組件層，進行操作，在組件層或其他平臺進行了有效操作后，由事件的收集服務，將事件收集上來，寫回到數據查詢服務，形成治理收益的匯總。

3.3 平臺建設 - 治理方案 - 響應式流程

第二條路徑是響應式路徑。主要做事后治理、問題總結、經驗沉淀。

在這條路徑里，大致分了幾個部分，首先以報警、消息作為源頭。包括 sla 破線告警，數據質量任務的報警，計算任務的報警等。

系統會將上述消息進行匯總，展示在治理平臺中。治理平臺可以對消息進行搜索，對問題進行歸因，并做根因打標，把問題定位到組件、平臺等問題上；再通過一些組織方式，比如通過系統來去找到組件方面的對接人，或通過組織會議，將問題提給相關的責任方，推動他們做一些有針對性的保障。做了以上推進后，我們會將系統中的問題描述、改進計劃列出來，有針對性地對問題進行定義，以及分析該怎么做達到事后治理的目的。最后，在問題解決后，推動方案的分享、沉淀和復用。

3.3.1 技術架構

響應式治理的架構，和規劃式治理類似，區別是里面消息服務的部分。這部分作為基礎的能力，將大數據平臺的各種產品，包括研發平臺、質量平臺等所有的消息，接到統一的服務中，所有消息的發出，都通過服務對外。這個消息服務成為所有報警消息的入口。通過它可以做一些升級策略，如消息聚合、加急等。此外，和規劃式治理類似，后端平臺控制響應式路徑的邏輯，包括消息訂閱、問題登記、總結復盤模塊等。其他部分和規劃式路徑類似。

3.4 平臺建設 - 開放接入

講完兩條路徑，下面是一些實踐中的解決思路。因為業務有各自發展的階段，以及不同的治理目標。比如說，比較新興的業務，現在主要關注的是sla的能力；一些成熟的業務，現在做的已經比較好了，要去做規范性。不同業務有不同的訴求。如何避免一刀切，讓不同的業務用平臺進行治理，開放能力非常重要。開放能力是說，要構建治理生態，業務可以自定義地接入治理規則，實施治理。

當前階段，將治理分為了四個象限，橫坐標為元數據部分，縱坐標為規則的部分。規則包括表達式和算法包等形式。系統提供的能力，主要在一象限：定義的標準的元數據，和統一的表達式，通過規則引擎直接適配。如果業務方有第三方元數據，來接入我們已定義好的規則，如圖中第二象限的部分，需要定義第三方元數據的接入。接入的第三方元數據需要遵循接入的標準，通過規則引擎進行適配。規則部分如果要做升級，比如進行相似度計算等，不是在一維上對資產打標，不是純表達式可以描述的規則，這種情況下將其定義為算法包或者邏輯單元。需要定義好輸入輸出的標準，通過調用包或者插件的方式，執行邏輯。第三方元數據和算法包的結合同理，定義好輸入輸出，并關注包的執行效率、時間等，就能滿足整體的接入。

整體來說，將平臺能力開放出去，讓業務接入自己的規則和數據，需要定義好標準的元數據格式，比如：可以定義行是具體的資產，列是具體的 profile。業務方負責加工自己的接入部分，完成配置和數據映射，通過表達式或者算法包的計算后，定義統一的輸出，就可以對接到系統。目前，系統支持對單資產打標（pointwise）和兩個資產關聯打標（pairwise）。

3.5 平臺建設 - 智能化能力

接下來是近期在做的事情。平臺工具側做了很多能力上的建設，通過智能化的方式，進一步降低治理成本，提高治理效率。下面介紹幾個有代表性的落地。

3.5.1 任務 SLA 簽署推薦

在做 SLA 簽署時候，任務上下游，可能存在幾百上千個節點，怎樣估計出應該在什么時間產出呢？我們目前是通過血緣關系，找到節點所在的關鍵路徑，基于運行時間，進行權重的分配，來確保節點有相對合理的 SLA buffer。

推薦簽署部分，目前已經有了專利，并有了一定的效果。現在在做第二期，基于運行失敗概率分布的情況，來調整上游 buffer 壓縮，下游 buffer 寬松的問題。

3.5.2 動態閾值監控

解決的問題是：數據量正常分布，但看起來異常化的情況。比如流量日志在假期或活動日，出現正常突增或突降的情況。

平時做質量監控時候，會用絕對值閾值來限定作報警范圍，比如參考歷史7天波動率等。這樣，容易造成假期或活動日誤報警，給值班人員造成不必要的打擾。動態閾值就是為了解決這個問題。主要思路是：基于數據的歷史情況，歸納為幾種分布。針對不同的分布，提供不同的預測方法，預測整個表在某一天應該是在什么量級，然后基于數據量級設置上下閾值，超出閾值再進行報警或者消息通知。

在數據分布方面，針對我們自己的業務，劃分了幾種典型的分布：數據量單調不減的，大部分為快照表或者全量表；日志類的表，長時間觀察時，假期或活動日可能出現數據量突增或突降；維度表，數據量比較穩定，維度發生變化時，會反應出一定的問題；以及與維度表類似的一些波動比較小的分布。

基于不同的數據分布，目前采取了四種不同的預測方法：

移動平均法、指數平滑法、自回歸法、同期檢測法。針對不同的波動做擬合，目前得到了一定的驗證。

3.5.3 有相似任務識別

由于業務龐大、開發人員多、任務量大，在開發任務時，并不知道是否線上已有類似的任務，跨團隊情況更明顯，因此詳細任務的檢測很有必要。

基本思路是將目標源代碼和待檢測源代碼 sql 的 ast 序列化，然后進行向量化，對特征向量做余弦相似度計算，結果通過產品進行透出，再由業務進行標注，經過人工的確認分析，對任務進行合并或下線。

以上是我們在智能化方面的一些探索。

3.6 平臺建設 - 架構總結

總結一下，平臺總體架構分為三層：

• 產品層，將管理者視角和執行者視角做了區分。具體治理時候，通過雙路徑的方式：做規劃式治理時候，從目標制定、規則圈選、治理實施、到收益統計、經驗總結；第二條路徑是響應式治理。通過訂閱消息、發現問題、實施治理、登記問題、復盤總結幾個步驟進行治理。
• 服務層，提供了整體的服務邏輯層，在下面拆分了不同的模塊，特別是接入服務，提供了開放的能力。通過對任務執行、事件中心等不同模塊進行拆解，方面我們針對各種不同的場景，提供靈活服務。
• 數據組件層，作為基礎建設層，包括元數據倉庫的建設、大數據組件的適配。

四. 未來展望

未來展望主要由三個部分。

• 體驗打磨

平臺建設階段，已經建立了比較完善的能力，在內部得到了有效的使用。進一步，會更加貫徹雙路徑的建設，規劃式路徑上，使資產更清晰、規則更豐富，進一步打磨動線，并提高收益準確性。

響應式路徑上，除了問題登記、歸因、總結外，后面會主要針對總結歸納、經驗沉淀進行建設，使經驗更好地復用到其他業務方。

• 開放能力

基于分布式自治的理念，目前沒有采取一刀切的策略進行治理。大家可以自定義自己的目標，對齊自己的 SLA 等。后續會支持自定義健康分，不同業務可以自己定義健康分的組織形式和描述。第二點是自定義方案。我們會進一步打磨自定義規則的接入流程，并將規則能力進一步開放化，支持業務調用。業務拿到打標后的信息，可以做自己的資產分析。第三點是打通業務，進一步以業務視角看待問題，針對業務問題，做好平臺建設。

• 增強型數據治理

目前大部分是基于統計類規則，正在建設部分挖掘類規則。

后續會在智能化模型建設方面，做一些預測分析。