一、整體思路與框架

首先是整個歐拉平臺建設的思路和框架。

企業面臨本質問題是數據體系的信息熵太大、信息量小，數據治理本質是打造一個對抗熵增的系統。信息熵往往就等價于確定性，比如我們看到一份數據，如果不知道它用來算什么指標、有什么價值、上下游的應用和所占用的成本，確定性就很低，信息熵就很大。因此我們需要從數據的可理解性、規范性、易用性、可靠性、安全性、成本幾個方面來提升確定性。

1、平臺主旨

怎么能讓一個雜亂無序的系統變得規整？在物理學中，一個封閉系統要對抗熵增，通常會對外做功，這有點像事后治理的概念。例如，對于已有存量的數據，需要通過掃描元數據進而發現問題來進行事后治理。這是大家普遍知道的做法，也就是先污染后治理。

物理學上其實還有一種方法，即建立一個內部自治的耗散結構。就像人體，即使躺在那里沒有外部做功，也不會馬上生病，因為人體本身是一個自調節的耗散結構。

因此，我們在數據治理過程中 也可以嘗試建立生產即治理的耗散結構，使得數據在整個生產和使用過程中都是規范和自調節的，緩解熵增（變混亂）過程。

本文內容正是關于如何建立從數倉到指標生產即治理的耗散結構。

2、評價體系

首先我們需要過資產分來量化數據體系的信息熵，建立一個評價體系，形成對數據現狀、治理效果的共識，進而牽引、推動治理平臺的落地。資產分高越則數據的信息熵越低、數據的確定性越高。在此基礎上，基于歐拉平臺，配合治理專項不斷提高資產分。

3、數據痛點及平臺應對方案

很多企業在數據治理的時用了各種方法仍然避免不了 3 個問題——治理難、維護難、使用難。數據治理的成果像沙子堆的碉堡，缺乏骨架，經不起風吹草動。而騰訊歐拉這樣生產即治理的平臺工具就可以成為骨架。

因此，歐拉數據生產即治理的理念是從業務角度出發，重點關注標準化、可信數據資產的沉淀和交付。將數據資產交付分為主要3步：

第一步：數據體系規劃。即數據的業務、概念建模。定義業務域、主題域、業務過程等，定義和管理數據標準，例如字典、命名規范、度量、單位、詞根等，以及質量標準。

第二步：數據建模。通常是邏輯建模、物理建模，形成一個Uni-Model，即統一模型。

第三步：數據發現與應用。酒香也怕巷子深，要呈現可信數據資產，需要將建模后的元信息和元數據集成起來，形成一個上層應用能夠使用的統一數據服務和資產目錄，供大家查找、發現、使用和申請數據。

4、歐拉的服務框架

接下來介紹歐拉平臺服務的框架，主要有3個子產品——資產工場、指標中臺和數據發現。

歐拉數據資產工場，定位是在湖、倉、流上構建標準化的數倉模型。

在數倉模型上是tMetric，也就是指標中臺，基于headless BI理念在數倉之上定義指標，提供統一指標服務。

資產工場和指標中臺，其實面向數據建模和生產，數據發現則是面向數據消費端，把標準化生產的數據的元信息通過各種方式集成到一起。

元數據分為技術元數據和業務元數據。技術元數據主要是數據的存儲位置、存儲結構、存儲大小、存儲格式等。在技術源數據之上會補充很多業務信息，比如此數據代表的業務過程、業務含義、口徑、分類等，最終形成一個統一的數據知識索引庫。上層是一個數據發現產品，大家在這里找數據、共享數據、申請數據、洞察數據。

歐拉在整個現代數據棧中的位置如下圖：

這里歐拉治理引擎則是一個偏事后治理工具，即采集全鏈路元數據后，掃描問題、發現問題、修復問題。

二、數倉與指標建模

接下來是數倉和指標建模以及它們所面臨的問題和應對方法，還有指標中臺、資產工場、數據發現三個平臺的設計。

1、典型數據問題案例

通常，數據集成入倉后會形成一個結構化的ODS層的表。在這個表上，數據工程師會進行維度擴展或邏輯建模，將一些維表與ODS表關聯，如關聯用戶年齡、性別和渠道信息。這樣，就會形成一個明細的DWD寬表，可能還會進行一些transform操作或格式轉換。

在這個DWD表格的基礎上，我們會進行輕度的匯總，形成DWS表，基于DWS表再構建應用層的ADS表，ADS表直接用來配置報表或者用作數據分析，典型問題case 如下圖所示：

（1）三個 ADS 表指標口徑不一致，理論上它們的曝光次數加起來是一樣的，但是因為這個三個 ADS 層它的加工邏輯不一樣，開發的負責人不一樣，可能會導致口徑未對齊，這是最典型的問題。

（2）數據依賴錯綜復雜，維護、修改、口徑排查困難，同層依賴、跨層依賴，甚至下層依賴上層都有可能。

（3）過度重復冗余，DWD表、ODS表占用存儲大，數據冗余度高。

（4）使用難，對于曝光次數這個指標，在不同的地方都會有不同的取值，這會讓人困惑應當以哪個出口的數據為準。很多業務中表的命名可能是英文的，沒有明確的中文描述、分類或分域定義，我們也不知道它們代表的業務過程是什么，要臨時取數用哪個表合適。

2、關鍵思路

本質是數據的確定性差，下面講述如何一步步解決這些問題。

第一個關鍵思路是具備標準化企業數據模型構建和管理的能力。數據建模可以分為三個層面：物理建模、邏輯模型和概念模型。物理建模層主要涉及到具體執行引擎上定義數據的具體實現，比如編寫一段SQL或Python代碼，通過Spark 、Hive來統計表格等。

邏輯模型層則定義數據之間的邏輯流向和組織關系，通常會使用ER模型、星型模型或其他可視化方法來表示這些關系，并不需要關注底層技術。例如無論底層是Hive、Spark還是Clickhouse等等，在邏輯模型中應當使用一種統一的數據邏輯描述語言。最上層是概念模型，定義數據的范疇、業務過程等。通常會使用分層分域或流程圖等方式表示。

至于物理模型，這方面已經很成熟了。

總結一下，我們在數據建模的過程中往往缺乏的是概念模型和邏輯模型的構建和管理能力，這會對數據的確定性造成很大影響，導致可理解性降低，重復冗余嚴重，同名不同義、同義不同名等一些列問題，數據空間感極差。就像在圖書館找一本沒有目錄和描述的圖書。

如果沒有良好的數據架構支持，數據管理也會變得十分困難。所以，需要加強對概念模型和邏輯模型的建立和管理。

第二個關鍵思路就是基于DataOps 理念的物理建模。我們原來的開發模式是：數據集成到hive數倉或數據湖里，并撰寫一些SQL、Python代碼，配置調度作業。

有些情況下，我們可能會在本地的編輯器里編寫好代碼，將它復制粘貼到調度系統或者作業配置系統，再提交到Git。然而，這種開發流程與軟件開發的devops有很大的差距，從邏輯上講，數據工程也可以被軟件工程化，甚至可以說是必然趨勢。這可以解決數據工程中的研發、版本、測試、集成、部署、以及質量等問題，因此我們也需要一個數據資產的CMDB。

3、如何實現數倉建模CRCD

這部分會說明如何實現數據開發流程的軟件工程化。

在進行前后端開發時，我們要遵循軟件工程的理念，常聽到的一個詞就是面向對象編程。這種編程方式先聲明一個對象，這個對象可能有很多屬性方法，其它對象也可以繼承這個對象。

在數據開發中，我們往往是面向表格的開發和交付，表格包含：基礎信息、生產代碼、scheme定義、調度配置，這些都可以代碼化。打通發布流水線，就可以實現數據開發的DevOps，也可以在整個工程實踐中增加很多事前、事中、事后的檢測約束，保障數據開發規范落地。

4、數據工程的編碼抽象

除了CR、CI、CD的流程，數據工程代碼也需要一定的抽象能力。如果我們只用純 SQL 來開發表格，就會產生許多問題，SQL代碼難以實現可測試性、可讀性。當 SQL 代碼過于龐大時，可讀性會降低，難以進行單元測試或單步調試，也無法實現流程控制，代碼復用性也比較低。在軟件工程中有一條原則叫做“don’t repeat yourself”，意思是要盡量避免重復。

Python 和 SQL 結合是一種不完美、但能實現一些流程控制的放式，抽象公共腳本，實現類似宏的功能，也能引用一些模塊化的公共腳本（如下圖demo）。

5、規范化的概念模型

我們可以將dataops視為一種軟件工程化的物理建模。在開始物理建模之前，我們需要先進行概念建模和邏輯建模。

概念建模，也是定義數據的業務模型。定義業務過程與業務主題域，可以采用樹形結構的方式進行定義。此外，業務過程域下還會定義一些詞根以及業務域主題的描述等。創建數據庫表時，必須要將其掛載在具體的業務域和主題域下。表名可以根據前后綴和關鍵點以及業務所在的業務過程來自動生成。如果沒有完整的概念模型，就無法形成這種統一的數據資產目錄，除非采用人工的方式事后進行整理。

6、規范化的邏輯模型

邏輯建模，通常定義一個星型模型或雪花模型，或可視化定義一個pipeline（這是一個數據加工邏輯的可視化方式，易于理解）。

因此，概念模型實際上形成了一個虛擬的邏輯表。這個邏輯表與底層引擎無關，可以提交到Hive或spark等平臺運行物化。整體產品效果如下圖：

7、指標治理面臨的主要問題

前面講了數倉建模，那么指標存在哪些問題呢？答案是“不知道口徑”或“口徑不一致”，原因是重復（同意不同名、同名不同義也是一種重復）。那么為什么會出現重復？同樣的指標在不同的平臺被多次重復定義，導致難以保證口徑的一致性，從而經常出現同名不同義或同義不同名的問題。

我們的方案是以Headless BI為導向，建立一個指標中臺。我們希望統一構建一個指標庫并向下游提供SDK、API或類似SQL的方式來查詢這些指標。我們能確保這個指標庫中的指標不會重復。例如，如果出現多個DAU，它們的名稱也不同，它們的口徑也不同，我們可以輕松區分它們。

然后下游系統便可以統一對接指標查詢服務，無需重復定義和計算該指標。而這個核心思想的關鍵在于"headless"，這個概念其實早在中臺概念提出之前就已存在。

"headless"其實就是前后端分離，由后端以API方式為上層的可視化展現層提供服務?？梢暬宫F層可以是多個，應用層業務也可以有多個場景。提供統一API服務，同一個指標或服務的API保障一致性。

8、指標中臺與敏捷分析

基于這一理念，可能會有一個問題，指標中臺和敏捷分析有什么關系？因為指標是用于分析的。這是否會導致降低分析的敏捷性？

實際上，我們應該從提升數據分析效率的角度來考慮問題。影響數據分析效率的因素有多種，例如找數據的效率、計算效率、確認數據是否正確的效率等。

如果數據不準確，整體的數據分析效率也不會提高。指標和維度的廣義定義是無限的，數據分析同學可能會隨時提出不同的指標定義或維度想法。敏捷分析通過提倡快速定義指標維度并即時分析。指標中臺的定位是規范地定義指標并提供統一指標服務，在某種程度上會與敏捷矛盾。

如果規范能保證每次查找指標時都快速定位，且結果正確，那么我認為它的分析效率也會大幅提升。因此，歐拉指標中臺也在提供規范化、標準化的統一指標服務前提下，盡可能地提高指標定義的敏捷性。

9、tMetric的領域模型

接下來我們要講的是指標中臺的領域模型。

第一步：在多種數據源上創建數倉模型（基于星型模型的邏輯表或者物理表）。

第二步：在數倉模型之上 定義原子指標、派生指標以及指標的維度

第三步：會有2個場景，①基于指標定義，創建物化視圖或者預計算的cube；②是基于指標定義自助生產數倉ADS表。

第四步：對外提供統一的指標查詢API或者SDK，也可以直接在實驗平臺、Adhoc分析等引用指標口徑。

10、如何標準化的定義指標

那么指標的定義呢如何標準化指定呢？例如：以最近七天的體育類視頻播放時長為指標，度量是視頻總播放時長，維度是性別、年齡等，業務限定體育類。統計周期為最近七天。最終確定了指標定義之后，自動生成計算SQL。這是一個基本的語義模型。

11、tMetric的的體系架構

接下來講一下整體框架。

應用生態：對接決策智能平臺、報表平臺、實驗平臺和目標管理平臺等。所有這些平臺都可以接入指標庫，使用指標 API 或類 SQL API 獲取指標數據。在這些平臺看到同一個指標時，口徑一定是相同的。

• 查詢層：包括緩存、查詢協議、轉換和路由策略等。
• 語義層：指標、維度的標準化定義和元信息維護。
• 數倉模型層：數倉邏輯表、物理表定義以及統一數倉模型元數據服務。
• 物化加速層：我們提供了一個統一的物化服務，并針對不同的指標查詢場景實施不同的物化策略。這些策略包括 OLAP 的物化策略和預計算的物化策略。

12、tMetric的物化加速方案

根據不同的場景選擇不同的物化加速方式：

場景一：如果這個指標常被觀測，其維度組合也已知，且維度基數不高，那么我們會選擇預計算方式，定義好指標和需要使用的日常維度組合，預計算是一個cube。這種方式優勢是查詢速度快、存儲、計算成本都比較低，缺點是多維分析的靈活性較低。

場景二：指標可能具有多個維度，而未來可能需要使用的維度不確定，這時可以使用StarRocks或Clickhouse等OLAP引擎支持任意維度的OLAP查詢。通常會根據一些使用頻率較高的維度創建物化視圖。

場景三：在配置指標時，需要快速預覽其定義以確保指標定義正確性。為了實現快速預覽，使用MPP內存計算引擎，如Presto、Impala。不過，這并不是一個頻繁的操作，通常只在定義指標時進行預覽查詢。

13、效果展示

三、數據發現

前面講了指標生產和數倉建模，接下來就需要讓用戶方便地找到和使用這些數據資產——有哪些指標API可以使用？指標庫包含哪些指標？數倉表中包含哪些重要表？這些問題需要通過清晰的呈現來得到解答。

首先我們需要統一的元數據底座-Uni-Meta。它可以從各種不同的數據系統中獲取元數據，形成一個數據資產目錄，或者說一個全域的數據知識圖譜和資產現狀概覽。

四、未來展望

現在大家都在談論ChatGPT，也有很多人在討論AI for BI在企業中應用的一些可能性。例如數據分析師在進行指標分析時面臨的痛點，不僅僅是知道指標數值，關鍵痛點是連貫的順暢的漸進式的分析。如果AI可以解決這個痛點，那將會是質的飛躍。

但如果數據未經治理，沒有統一的數據標準和數據框架，那么即使把所有的元數據信息都采集，AI的回答也會似是而非。

舉一個例子，假設用戶問昨天新聞各媒體渠道曝光的量如何，假設有一張表，我們明確知道表的用途、字段及含義，那么就可以構造prompt來寫一段SQL統計各媒體渠道曝光量。

這個問題的難度在于如何構造Prompt，如果 Prompt 基于一個或是幾個標準化的模板來構造出來，讓 AI 填空，寫出來的SQL就能直接運行。如果沒有標準化的模板，寫出來的SQL 大概率錯誤，只能作為一種輔助。

因此，如果我們數據治理能力足夠強，AI輔助下連貫的順暢的漸進式的分析是很可能實現的。

五、Q&A

Q1：騰訊如何統一指標的？

A1：這個問題可以從三個層面來回答。一個層面是如何統一指標的口徑，比如戰略層面的一些指標如“DAU 怎么算”、“各個業務大家是不是一致認可的”等。在這方面，我們有一個數據治理的工作組，工作組和業務的數據分析人員會有一個類似數據決策委員會的組織，在戰略層的一些關鍵的指標口徑達成共識。

另一方面是技術保證口徑一致。其實就是我前面講的，我們基于headless BI 的理念，建設一個統一的指標中臺tMetric，把一些常用的指標都定義在這個指標庫里面，下游的各個地方引用時都統一從這個指標庫里獲取指標。

第三個層面，就是日常的臨時洞察分析。廣義上的指標其實是無法窮舉的。數據分析人員可能會忽然想到臨時指標來統計分析，此時用戶的痛點在于怎么算這個指標。這種場景往往是基于日常例行觀測指標的衍生指標，也就是說如果知道日常例行觀測指標怎么算，大部分情況也能推理出自己新構造的指標怎么算。

Q2：環境分為開發環境、測試環境還有生產環境嗎？

A2：我們現在只有測試環境跟生產環境，沒有預發的過程。但未來我們也會有預發，在一些很嚴苛的場景，數據測試完后可以發布到預發環境可試跑幾天，確認沒有問題再整個上線。

Q3：指標庫的規模大概是多大？

A3：坦白說現在指標的數量只有 6000 多個，但是維度的數量比較多，一個指標可能有特別多的維度，我認為能從各個維度去看這個指標才是最大的挑戰。

Q4：系統地講一下在數據治理中用到了哪些 AI 技術？

A4：我覺得是兩個方面。

一個是通過 AI 手段來提升數據治理的自動化的水平。通過 AI直接自動化治理是比較難的，畢竟數據治理有很強的業務性，需要理解業務模式和數據專家經驗。但 AI 的一些技術可以加強數據治理工具能力，比如有些表可能沒有描述，之前要人工梳理和補充表描，但現在 AI 可以根據表的一些數據的樣本自動補充描述，自動給數據分類。

第二個是 AI 對數據治理的促進作用，也就是用 AI 做增強分析。但如前文所言，這需要極高的數據治理的水平，需要數據治理的平臺化和生產即治理的模式，事后治理不能滿足 AI for BI的需求的。

Q5：枚舉值的最初來源是埋點信息嗎？

A5：枚舉值的來源有三部分。第一部分是埋點信息，比如說一個APP的啟動方式的枚舉值可能在埋點系統定義。第二個部分是直接提取一些表的字段的枚舉值。第三個就是人工補充。需要注意的是，枚舉值的定義一定是可枚舉的。不是所有維度都要枚舉，比如維度是用戶ID，就不可枚舉。

Q6：概念模型和邏輯模型在沒有平臺化管理的情況下，應該怎么迭代管理？

A6：目前沒有很好的方案。如果沒有平臺管理，而是通過 wiki 、文檔等去梳理，你那么維護成本極高。

Q7：騰訊如何量化評估指標資產的價值？

A7：這個是大家都很關心的問題，其實也就是數據治理。

那么我們如何讓老板知道投了這么多資源的最終效果呢？其實數據治理本質上就是 4 個方面：成本、質量、安全風險和效率。單點治理時，切入點可以選成本，好度量。質量也有一些評估的方法，比如數據的及時性、數據問題反饋率和數據異常率等。

數據安全和效率的效果量化困難比較困難，可以先組織大家形成共識，確定必須要做的事，在這個前提下再定義量化指標來牽引結果。我們的組織是數據治理工作組，量化指標是我前面講的資產分，通過量化評估把大家的治理水平拉到一個評價標準上，誰的資產分低，說明說誰的治理效果可能存在問題。

總結來講，先通過組織共識目標（要做什么），再定義量化指標牽引目標達成，量化指標的定義也要注意，粗略的正確好過精確的錯誤。

Q8：如果構建了指標體系，傳統的數倉會不會做的比較?。?/span>

A8：數倉應該會下沉，比如說原來數倉有大量的ADS 表，現在就收斂到DWD或者少數DWS表，我認為可以通過指標中臺的指標定義，自動化或半自動化地生產大量應用層的表。

Q9：最后一問題的話是說現在經濟環境不好，那業務都要敏捷，那數據治理怎么敏捷跟上業務的發展？

A9：我認為現在整個行業更偏向像保守的方向，倡導降本增效。數據治理的目標就是降本增效，剛好符合現在的企業訴求，原來不重視數據治理，同一個指標可能會反復統計多次，計算跟存儲成本會非常高?，F在數據治理想辦法幫業務降本增效。做好這點，就是對業務發展最好的幫助。