01、歐拉平臺建設(shè)思路和目標

首先簡單介紹數(shù)據(jù)治理平臺的建設(shè)思路。

1. 數(shù)據(jù)治理的終態(tài)

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

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

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

互聯(lián)網(wǎng)數(shù)據(jù)治理平臺需要具備 3 點核心能力才能應(yīng)對這種復(fù)雜多變：

①高效的業(yè)務(wù)流程定制能力

②高效的數(shù)據(jù)模型管理能力

③統(tǒng)一的存算服務(wù)

其中統(tǒng)一的存算服務(wù)是底座，目前頭部互聯(lián)網(wǎng)公司相對比較成熟。但前兩點聽起來簡單，但到實際數(shù)據(jù)驅(qū)動業(yè)務(wù)的全流程中，就包含業(yè)務(wù)過程建模、數(shù)據(jù)開發(fā)建模、數(shù)據(jù)治理等一系列能力，下面主要介紹這些能力的建設(shè)思路。

2. 歐拉平臺概覽

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

① 需要數(shù)據(jù)規(guī)范與標準，拉齊各業(yè)務(wù)數(shù)據(jù)標準

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

③ 需要構(gòu)建統(tǒng)一數(shù)據(jù)實體、統(tǒng)一數(shù)據(jù)模型、統(tǒng)一數(shù)據(jù)服務(wù)，做到數(shù)據(jù)生產(chǎn)即治理

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

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

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

混亂是慣性，對抗混亂必須要創(chuàng)造內(nèi)部驅(qū)動力、外部推動力兩方面條件，歐拉內(nèi)部驅(qū)動力是提升平臺能力，外部推動力是依托 BG 技術(shù)戰(zhàn)略推動治理專項落地，

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

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

歐拉治理平臺的解決方案從事前的數(shù)據(jù)埋點、采集，到事中進行規(guī)范化的數(shù)據(jù)規(guī)劃、模型設(shè)計和管理維護，再到事后進行資產(chǎn)治理展示，實現(xiàn)了全鏈路的治理。

02、數(shù)據(jù)開發(fā)治理

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

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

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

② 有一些數(shù)據(jù)冗余、跨層依賴的問題

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

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

① 通過規(guī)范化維度建模、可視化建模等能力提升數(shù)據(jù)生產(chǎn)效率

② 建設(shè) DataOps 能力，提升數(shù)據(jù)編排過程的效率和規(guī)范性

③ 基于指標平臺統(tǒng)一指標口徑，半自助式配置生產(chǎn) DWS、ADS 表、統(tǒng)一指標出口，提升數(shù)據(jù)一致性

④ 建設(shè)完備數(shù)據(jù)知識庫或數(shù)據(jù)信息網(wǎng)絡(luò)，形成構(gòu)建統(tǒng)一數(shù)據(jù)地圖和服務(wù)

1. 規(guī)范化數(shù)據(jù)建模平臺設(shè)計理念

使用規(guī)范的數(shù)據(jù)模型的話有三點好處：

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

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

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

從模型來講，數(shù)據(jù)模型可以分為三個層次。

物理模型是基于具體引擎定義了數(shù)據(jù)的具體實現(xiàn)。

邏輯模型定義了數(shù)據(jù)或者字段之間的關(guān)系，而不區(qū)分是底層用的引擎是什么，它是定義兩份數(shù)據(jù)之間的映射關(guān)系或轉(zhuǎn)換關(guān)系。

概念模型定義了數(shù)據(jù)的范疇、業(yè)務(wù)域、主題域等在業(yè)務(wù)過程層面的含義和規(guī)則，通常說的數(shù)倉的分層分域就是在概念模型上的定義，此外一些樹形結(jié)構(gòu)或者些圖結(jié)構(gòu)也會被用來表達數(shù)據(jù)之間的業(yè)務(wù)流程。

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

2. 歐拉平臺基礎(chǔ)能力七大亮點

歐拉數(shù)據(jù)中臺具備一站式建模開發(fā)、測試發(fā)布、質(zhì)量運維和版本管理的基礎(chǔ)能力。

① 數(shù)倉的規(guī)劃和規(guī)范配置的能力，可以配置數(shù)倉業(yè)務(wù)過程，以及定義數(shù)倉規(guī)范。

② 開發(fā)規(guī)范，如注釋規(guī)范、CR規(guī)范、資源使用規(guī)范。

③ 治理平臺化能力，歐拉數(shù)據(jù)中臺可以自動掃描開發(fā)好的數(shù)據(jù)或存量導入的數(shù)據(jù)，進行問題檢測，實現(xiàn)數(shù)據(jù)治理。

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

⑤ Everything is code，code review 及發(fā)布管理。

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

⑦ 可視化維度建模。

3. 治理引擎

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

整體來看數(shù)據(jù)治理是通過元數(shù)據(jù)及其特征制定治理方案，推動治理執(zhí)行，最終反饋到資產(chǎn)評價體系里面實現(xiàn)資產(chǎn)健康分效果的提升，治理閉環(huán)。

03、統(tǒng)一指標 tMetric

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

1. 指標生產(chǎn)應(yīng)用現(xiàn)狀

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

2. 歐拉統(tǒng)一指標 tMetric 模型

從整體架構(gòu)來看，最底層有各種來源的數(shù)據(jù)，我們在這些數(shù)據(jù)上面定義指標和口徑的模型，通過可視化方法定義指標生產(chǎn)邏輯的聚合。定義好后，可以配置指標的物化加速，平臺會由調(diào)度系統(tǒng)自動執(zhí)行物化生成，最后由統(tǒng)一的 API 接口實現(xiàn)各個系統(tǒng)使用統(tǒng)一指標服務(wù)進行查詢。

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

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

① 通過指標API 對接各種報表、數(shù)據(jù)門戶平臺

② 基于指標口徑定義生產(chǎn) DWS\ADS 表，用于靈活的數(shù)據(jù)集分析

04

數(shù)據(jù)地圖與服務(wù)建設(shè)方法和思路

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

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

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

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