01、歐拉平臺建設思路和目標

首先簡單介紹數據治理平臺的建設思路。

1. 數據治理的終態

數據治理似乎成了一個人人都似懂非懂的詞，甚至大有“人人要參與治理數據”的趨勢，人人都知道數據治理要做啥、要做成啥，但人人都不知道數據治理啥時候能有結局。我覺得數據治理的最終目標是實現數據生產和應用的工業化。要實現數據工業化，可能會有?2 種場景案例：

業務流程或數據模型較為固化、存算技術選型較為單一：如傳統制造業信息管理系統一類，很少聽他們大規模搞數據治理，我認為主要原因是業務流程和數據模型經過多年發展，形成了相對比較固化、標準的流程和模型(其實工業 4.0 也在強調從“大規模生產“轉為”大規模定制“,主張靈活、快速響應多樣化的定制需求，那時的工業 4.0 我想也需要類似現在互聯網的數據治理平臺)。

基于多種技術構建系統性解決方案應對復雜多變的業務場景：互聯網在過去一直高速發展，業務流程復雜多變，各種玩法層出不窮，導致數據平臺很難快速響應變化的同時又能保證數據不亂，業務數據需求多樣無法用單一數據庫滿足，又導致必須要用多種技術組件滿足特定場景需求，多組件增加了技術架構的復雜性。

互聯網數據治理平臺需要具備 3 點核心能力
才能應對這種復雜多變：

①高效的業務流程定制能力

②高效的數據模型管理能力

③統一的存算服務

其中統一的存算服務是底座，目前頭部互聯網公司相對比較成熟。但前兩點聽起來簡單，但到實際數據驅動業務的全流程中，就包含業務過程建模、數據開發建模、數據治理等一系列能力，下面主要介紹這些能力的建設思路。

2. 歐拉平臺概覽

歐拉數據治理的整體思路是通過平臺能力+治理專項的推進來互相牽引，實現數據治理的最佳實踐落地。主要有以下 4 方面措施：

① 需要數據規范與標準，拉齊各業務數據標準

② 需要完整的全鏈路元數據能力，從而明確數據到底發生了什么，什么地方需要治理，提升數據的可觀測性、空間感

③ 需要構建統一數據實體、統一數據模型、統一數據服務，做到數據生產即治理

④ 需要統一的治理評價體系，配合治理專項，推動和牽引治理落地

首先，我們需要一個簡單可理解的量化目標，牽引業務和治理平臺雙向奔赴：

歐拉中臺從數據的規范、質量、安全、成本、應用 5 個維度定義了資產化的標準。基于這個指標牽引，業務的數據治理的目標就是實現數據的資產化，業務和中臺就會一起去努力提升資產化率，通過運營手段，治理專項配合平臺進行日常運營，修復不符合資產化率的問題。同時對于新增數據，可以通過平臺來實現“生產即治理”，讓數據在生產過程中就符合資產化率的要求，最終得到存量和新增數據整體的治理。稍微需要注意的是，資產化率的分子度量需要大量的元數據分析，一開始可能會讓人望而生畏，但是我們要堅持 “粗略的正確好過精確的錯誤”，逐步迭代，一開始絕對準確不可能做到。

混亂是慣性，對抗混亂必須要創造內部驅動力、外部推動力兩方面條件，歐拉內部驅動力是提升平臺能力，外部推動力是依托 BG 技術戰略推動治理專項落地，

從推力上來講，主要是資產化率目標的要求、成本方面的要求和安全管理方面的要求，尋求管理層支持。從拉力的角度來看，業務方希望中臺能提供資產化認證為業務的治理結果提供依據，此外也有資產共享的激勵以及從集團層面出發的關于成本控制和安全管理的需求拉動數據治理的落地。

有推力跟拉力之后，數據治理需要從存量治理和新增治理兩方面入手實現全部的數據治理。對存量數據，從應用、安全、規范、質量、成本這幾個維度，通過治理的掃描平臺追蹤需要掃描哪些數據，有什么問題需要去修復；對新增數據，只需要新增數據在歐拉平臺上進行建模生產，數據即符合資產化率要求。最終治理好的數據可以在統一的數據服務門戶上申請應用，從而實現降低成本，保護數據安全，提升治理公信力和業務的配合度。

歐拉治理平臺的解決方案從事前的數據埋點、采集，到事中進行規范化的數據規劃、模型設計和管理維護，再到事后進行資產治理展示，實現了全鏈路的治理。

02、數據開發治理

為了規范新增數據、治理存量數據，騰訊基于 DataOps 的理念來打造規范化的數據開發建模平臺。首先看一個數倉混亂的具體 Case，如下圖：

假設有一張 ODS 表，包括事件、時間、用戶ID、IP、渠道、位置、頁面屬性等。數倉開發人員會使用這個 ODS 表加 DIM 維表（如用戶的維度表或渠道維度表）構建 DWD 的明細寬表，在此之上輕度聚合生成 DWS 表，用戶會基于 DWS 表產生各類 ADS 表或報表。這個過程中至少會出現三類問題：

① 由于表的開發者不統一，導致計算加工邏輯和口徑不一致的問題。同一個“曝光次數”在 3 個 ADS 表中加和后卻不相等

② 有一些數據冗余、跨層依賴的問題

③ 用戶不知道自己想要的指標從哪個表里取數

解決方案主要以下四點，在下會詳細介紹主要做法：

① 通過規范化維度建模、可視化建模等能力提升數據生產效率

② 建設 DataOps 能力，提升數據編排過程的效率和規范性

③ 基于指標平臺統一指標口徑，半自助式配置生產 DWS、ADS 表、統一指標出口，提升數據一致性

④ 建設完備數據知識庫或數據信息網絡，形成構建統一數據地圖和服務

1. 規范化數據建模平臺設計理念

使用規范的數據模型的話有三點好處：

第一，因為模型相對來講比較規范的，它的變更也是比較規范的，因此模型質量跟開發效率得到提升，同時降低安全風險。

第二，模型比代碼更容易理解，可視化模型或邏輯模型能讓數據使用者輕松看清數據的關系，便于數據的理解與協作，也便于定位問題。

第三，規范的建模平臺會保障數據的存儲、計算效率，降低物理資源成本

從模型來講，數據模型可以分為三個層次。

物理模型是基于具體引擎定義了數據的具體實現。

邏輯模型定義了數據或者字段之間的關系，而不區分是底層用的引擎是什么，它是定義兩份數據之間的映射關系或轉換關系。

概念模型定義了數據的范疇、業務域、主題域等在業務過程層面的含義和規則，通常說的數倉的分層分域就是在概念模型上的定義，此外一些樹形結構或者些圖結構也會被用來表達數據之間的業務流程。

只有建模的能力還不夠，還需要構建一套 DataOps 的流程和平臺，保障建模開發的過程是高效的，DataOps 可以分為兩個層面，一是像 DevOps 一樣實現生產流程的編排，包括數據的需求與協作、設計與規劃、開發與建模、集成測試、環境管理、發布運維、數據治理、監控和服務與應用這些環節。二是從價值輸出層面的業務流程編排，定義數據使用的業務流程，例如一份數據 Ready 后觸發廣告投放。目前歐拉主要的能力主要集中在生產流程編排。

2. 歐拉平臺基礎能力七大亮點

歐拉數據中臺具備一站式建模開發、測試發布、質量運維和版本管理的基礎能力。

① 數倉的規劃和規范配置的能力，可以配置數倉業務過程，以及定義數倉規范。

② 開發規范，如注釋規范、CR規范、資源使用規范。

③ 治理平臺化能力，歐拉數據中臺可以自動掃描開發好的數據或存量導入的數據，進行問題檢測，實現數據治理。

④ 全鏈路的質量運維的能力。上下游依賴重跑、通知、基線控制。

⑤ Everything is code，code review 及發布管理。

⑥ 歷史代碼、配置、模型變更可視化比對，版本管理和回滾。

⑦ 可視化維度建模。

3. 治理引擎

歐拉中臺的治理引擎和 DQC 是統一的一套平臺，在數據開發里 DQC（Data Quality Center，數據質量中心）是很重要的一個能力，它主要關注數據質量，通過配置數據質量校驗規則，自動在數據處理任務過程中進行數據質量方面的監控，包括對數據內容和各種元數據的監控。歐拉統一質量治理引擎在最底層會有統一的基礎元數據層，包括埋點元數據、上報鏈路元數據、離線數倉、實時數倉、報表、指標的各種元數據，整合后有統一的特征提取層，基于元數據的基礎特征（如負責人、產出時間、大小等）、離線或實時（抽樣）統計特征（如數據的波動、數據的記錄數等）和一些用戶定義的特征構建數據畫像，再上一層會有統一的規則引擎定義各種異常，第四層判定層根據事件或者根據規則來判定數據是不是發生了異常，應用層可以實現告警和治理策略推送，比如通過規則判定，發現一部分數據存在問題需要被治理，那么應用層就會推送到數據的 Owner 方進行治理。

整體來看數據治理是通過元數據及其特征制定治理方案，推動治理執行，最終反饋到資產評價體系里面實現資產健康分效果的提升，治理閉環。

03、統一指標 tMetric

數據開發和建模的流程重點說明了如何提升開發效率，如何挖掘治理動作，這一部分介紹如何對數倉產生的很多表實現口徑收斂。我們打造了統一的 Metric Store 來提升口徑一致性的問題。

1. 指標生產應用現狀

現在我們有各種指標的出口，比如說報表平臺、分析平臺、實驗平臺，以及業務發布日報的平臺，大家一般在數倉里進行表的開發，之后將數據導入各個平臺進行二次加工，這樣會導致指標的統計口徑出現差別，存在建模難復用、數據可信度低等問題。因此需要打造統一的 Metric Store 來收斂口徑，大家取指標或口徑時都從統一的 Metric Store 來產出。達成此種目標有四方面的能力需要建設，第一是需要標準化的指標建模的能力，第二是統一的指標口徑管理和口徑收斂的能力，第三是具備官方的認證機制，第四是需要建設一個指標生態，使得指標平臺中的指標可以實現全平臺復用，從而保證口徑逐步收斂。

2. 歐拉統一指標 tMetric 模型

從整體架構來看，最底層有各種來源的數據，我們在這些數據上面定義指標和口徑的模型，通過可視化方法定義指標生產邏輯的聚合。定義好后，可以配置指標的物化加速，平臺會由調度系統自動執行物化生成，最后由統一的 API 接口實現各個系統使用統一指標服務進行查詢。

為達成這樣的效果，具體來說，指標平臺允許用戶去注冊各類數據源，允許用戶在這些數據源上做數據維度建模，建好模型后就產生了邏輯寬表，在此之上可以定義指標的聚合口徑。

我們把指標分為兩個層次，原子指標（原子口徑）指的是基于業務過程的度量值，不可以再進行拆分。派生指標，是對原子指標進行維度過濾后得到的指標。使用 API 對接下游的指標應用生態，如報表、日報等。定義好指標之后，只要一鍵創建指標加速，那么我們就自動物化指標的 Cube，最后可以通過指標 API 進行查詢，下游的一些報表平臺就可以實現指標口徑的收斂。指標使用出口有 2 種形式：

① 通過指標API 對接各種報表、數據門戶平臺

② 基于指標口徑定義生產 DWS\ADS 表，用于靈活的數據集分析

04、數據地圖與服務建設方法和思路

前面部分介紹了治理開發的工具和平臺，但酒香也怕巷子深，用戶沒有及時可用的信息網絡找數據、用數據的話，那后果往往又會導致數據重復做、口徑繼續變亂的惡性循環。歐拉數據發現期望基于元數據構建一個 Data Fabric，讓用戶能方便地找數據、用數據。通過自動化和增強集成、聯合治理以及元數據治理等技術，構建數據的信息網絡，從而尋找數據之間的關系，構建一個數據信息知識庫，使用戶找到想用的數據，其實核心是數據管理平臺。

識別用戶的意圖，本質上需要構建一種關系。例如我們發現 DS 用戶來尋找DAU 指標的時候，我們優先給他出 DAU 這個指標，那用戶可以根據 DAU 得到它對應的數倉表是什么，可用的維度是什么，對應維度的枚舉值是什么，分別表示什么含義等一連串的信息。如果只是進行全局模糊檢索，那找到的結果需要逐個點進去瀏覽或者詢問相關人員，這就避免不了有時對方直接丟一個 Wiki 或者簡單使用口口相傳的信息交互方式。只有建立完善的信息網絡才能讓大家真正容易地進行檢索。

前面說明了怎么找數據、用數據、申請數據，接下來介紹騰訊內部用的比較多的數據服務的能力。之前我們數據團隊向業務團隊交付數據的方式是產生 ADS 表、DWS 表或者數倉表。假設有電影播放量的指標需要在終端上進行展示，就需要數據同學去實時或者離線地統計電影的播放量，統計出來之后把它導入到數據庫里面，再交給業務開發的同學去寫后臺 Server，再跟業務平臺去對接。這樣流程比較長，而且當團隊建制不是很全的話，就會出現責任不清晰的問題，使用歐拉做數據服務可以解決 API 生產溝通流程上成本花費高的問題。

此外我們數據服務還解決了離線數據共享的問題，用戶可以申請一些數據去接出應用。這個流程簡單說是數據開發人員開發好的數據可以一鍵在數據上配置 API，由后臺自動根據用戶的使用場景把數據導入到 Redis、ClickHouse、MySQL 等生成 API 進行調用，在以上過程中會自動包裝監控和自動擴縮容的能力，用戶可以零代碼實現數據 API 化。

05、Q&A環節

Q1：資產健康分、資產化率是怎么算的？

A1：資產分我們分規范、安全、質量、成本、應用 5 個維度，每各維度都有一些檢測規則和對應標準。舉個例子，比如說安全類，包括數據是不是有明確的責任人？數據的審批是不是會根據不同分類有明確不同的審批規則？我們會根據元數據來檢測是不是符合規則，如果不符合規則就會扣分。

Q2：數據血緣是怎么存儲的？

A2：血源存儲應該比較簡單吧，現在有很成熟的一些圖數據庫，但是存儲不是最大的挑戰，業界都有非常成熟的圖數據庫存儲查詢和分析的方案，反而是數據血緣的構建是比較大的挑戰。從上游埋點到下游的平臺，怎么把血緣完整串聯起來，其實是最大的問題。

前面講到我們有統一的元數據上報的 Open API，推動各個業務把他們的元數據都上報上來，這些元數據里面就包含有數據是通過什么作業或者通過什么平臺產生了另外的出口，基于上報的元數據報能把血緣串起來。

歐拉數據平臺的血緣構建方面從埋點，到數倉，到指標，到報表這一層血緣我們串聯得比較好，因為一份數據經過計算任務，或者經過集成平臺的作業，最終數據之間的總是有邊可以連起來的。但是還有一些別的數據出口，比如數據在各種存儲系統之間的復制、用戶自己的一些臨時處理程序。