一、整體思路與框架

首先是整個(gè)歐拉平臺(tái)建設(shè)的思路和框架。

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

1、平臺(tái)主旨

怎么能讓一個(gè)雜亂無序的系統(tǒng)變得規(guī)整？在物理學(xué)中，一個(gè)封閉系統(tǒng)要對(duì)抗熵增，通常會(huì)對(duì)外做功，這有點(diǎn)像事后治理的概念。例如，對(duì)于已有存量的數(shù)據(jù)，需要通過掃描元數(shù)據(jù)進(jìn)而發(fā)現(xiàn)問題來進(jìn)行事后治理。這是大家普遍知道的做法，也就是先污染后治理。

物理學(xué)上其實(shí)還有一種方法，即建立一個(gè)內(nèi)部自治的耗散結(jié)構(gòu)。就像人體，即使躺在那里沒有外部做功，也不會(huì)馬上生病，因?yàn)槿梭w本身是一個(gè)自調(diào)節(jié)的耗散結(jié)構(gòu)。

因此，我們?cè)跀?shù)據(jù)治理過程中 也可以嘗試建立生產(chǎn)即治理的耗散結(jié)構(gòu)，使得數(shù)據(jù)在整個(gè)生產(chǎn)和使用過程中都是規(guī)范和自調(diào)節(jié)的，緩解熵增（變混亂）過程。

本文內(nèi)容正是關(guān)于如何建立從數(shù)倉到指標(biāo)生產(chǎn)即治理的耗散結(jié)構(gòu)。

2、評(píng)價(jià)體系

首先我們需要過資產(chǎn)分來量化數(shù)據(jù)體系的信息熵，建立一個(gè)評(píng)價(jià)體系，形成對(duì)數(shù)據(jù)現(xiàn)狀、治理效果的共識(shí)，進(jìn)而牽引、推動(dòng)治理平臺(tái)的落地。資產(chǎn)分高越則數(shù)據(jù)的信息熵越低、數(shù)據(jù)的確定性越高。在此基礎(chǔ)上，基于歐拉平臺(tái)，配合治理專項(xiàng)不斷提高資產(chǎn)分。

3、數(shù)據(jù)痛點(diǎn)及平臺(tái)應(yīng)對(duì)方案

很多企業(yè)在數(shù)據(jù)治理的時(shí)用了各種方法仍然避免不了 3 個(gè)問題——治理難、維護(hù)難、使用難。數(shù)據(jù)治理的成果像沙子堆的碉堡，缺乏骨架，經(jīng)不起風(fēng)吹草動(dòng)。而騰訊歐拉這樣生產(chǎn)即治理的平臺(tái)工具就可以成為骨架。

因此，歐拉數(shù)據(jù)生產(chǎn)即治理的理念是從業(yè)務(wù)角度出發(fā)，重點(diǎn)關(guān)注標(biāo)準(zhǔn)化、可信數(shù)據(jù)資產(chǎn)的沉淀和交付。將數(shù)據(jù)資產(chǎn)交付分為主要3步：

第一步：數(shù)據(jù)體系規(guī)劃。即數(shù)據(jù)的業(yè)務(wù)、概念建模。定義業(yè)務(wù)域、主題域、業(yè)務(wù)過程等，定義和管理數(shù)據(jù)標(biāo)準(zhǔn)，例如字典、命名規(guī)范、度量、單位、詞根等，以及質(zhì)量標(biāo)準(zhǔn)。

第二步：數(shù)據(jù)建模。通常是邏輯建模、物理建模，形成一個(gè)Uni-Model，即統(tǒng)一模型。

第三步：數(shù)據(jù)發(fā)現(xiàn)與應(yīng)用。酒香也怕巷子深，要呈現(xiàn)可信數(shù)據(jù)資產(chǎn)，需要將建模后的元信息和元數(shù)據(jù)集成起來，形成一個(gè)上層應(yīng)用能夠使用的統(tǒng)一數(shù)據(jù)服務(wù)和資產(chǎn)目錄，供大家查找、發(fā)現(xiàn)、使用和申請(qǐng)數(shù)據(jù)。

4、歐拉的服務(wù)框架

接下來介紹歐拉平臺(tái)服務(wù)的框架，主要有3個(gè)子產(chǎn)品——資產(chǎn)工場(chǎng)、指標(biāo)中臺(tái)和數(shù)據(jù)發(fā)現(xiàn)。

歐拉數(shù)據(jù)資產(chǎn)工場(chǎng)，定位是在湖、倉、流上構(gòu)建標(biāo)準(zhǔn)化的數(shù)倉模型。

在數(shù)倉模型上是tMetric，也就是指標(biāo)中臺(tái)，基于headless BI理念在數(shù)倉之上定義指標(biāo)，提供統(tǒng)一指標(biāo)服務(wù)。

資產(chǎn)工場(chǎng)和指標(biāo)中臺(tái)，其實(shí)面向數(shù)據(jù)建模和生產(chǎn)，數(shù)據(jù)發(fā)現(xiàn)則是面向數(shù)據(jù)消費(fèi)端，把標(biāo)準(zhǔn)化生產(chǎn)的數(shù)據(jù)的元信息通過各種方式集成到一起。

元數(shù)據(jù)分為技術(shù)元數(shù)據(jù)和業(yè)務(wù)元數(shù)據(jù)。技術(shù)元數(shù)據(jù)主要是數(shù)據(jù)的存儲(chǔ)位置、存儲(chǔ)結(jié)構(gòu)、存儲(chǔ)大小、存儲(chǔ)格式等。在技術(shù)源數(shù)據(jù)之上會(huì)補(bǔ)充很多業(yè)務(wù)信息，比如此數(shù)據(jù)代表的業(yè)務(wù)過程、業(yè)務(wù)含義、口徑、分類等，最終形成一個(gè)統(tǒng)一的數(shù)據(jù)知識(shí)索引庫。上層是一個(gè)數(shù)據(jù)發(fā)現(xiàn)產(chǎn)品，大家在這里找數(shù)據(jù)、共享數(shù)據(jù)、申請(qǐng)數(shù)據(jù)、洞察數(shù)據(jù)。

歐拉在整個(gè)現(xiàn)代數(shù)據(jù)棧中的位置如下圖：

這里歐拉治理引擎則是一個(gè)偏事后治理工具，即采集全鏈路元數(shù)據(jù)后，掃描問題、發(fā)現(xiàn)問題、修復(fù)問題。

二、數(shù)倉與指標(biāo)建模

接下來是數(shù)倉和指標(biāo)建模以及它們所面臨的問題和應(yīng)對(duì)方法，還有指標(biāo)中臺(tái)、資產(chǎn)工場(chǎng)、數(shù)據(jù)發(fā)現(xiàn)三個(gè)平臺(tái)的設(shè)計(jì)。

1、典型數(shù)據(jù)問題案例

通常，數(shù)據(jù)集成入倉后會(huì)形成一個(gè)結(jié)構(gòu)化的ODS層的表。在這個(gè)表上，數(shù)據(jù)工程師會(huì)進(jìn)行維度擴(kuò)展或邏輯建模，將一些維表與ODS表關(guān)聯(lián)，如關(guān)聯(lián)用戶年齡、性別和渠道信息。這樣，就會(huì)形成一個(gè)明細(xì)的DWD寬表，可能還會(huì)進(jìn)行一些transform操作或格式轉(zhuǎn)換。

在這個(gè)DWD表格的基礎(chǔ)上，我們會(huì)進(jìn)行輕度的匯總，形成DWS表，基于DWS表再構(gòu)建應(yīng)用層的ADS表，ADS表直接用來配置報(bào)表或者用作數(shù)據(jù)分析，典型問題case 如下圖所示：

（1）三個(gè) ADS 表指標(biāo)口徑不一致，理論上它們的曝光次數(shù)加起來是一樣的，但是因?yàn)檫@個(gè)三個(gè) ADS 層它的加工邏輯不一樣，開發(fā)的負(fù)責(zé)人不一樣，可能會(huì)導(dǎo)致口徑未對(duì)齊，這是最典型的問題。

（2）數(shù)據(jù)依賴錯(cuò)綜復(fù)雜，維護(hù)、修改、口徑排查困難，同層依賴、跨層依賴，甚至下層依賴上層都有可能。

（3）過度重復(fù)冗余，DWD表、ODS表占用存儲(chǔ)大，數(shù)據(jù)冗余度高。

（4）使用難，對(duì)于曝光次數(shù)這個(gè)指標(biāo)，在不同的地方都會(huì)有不同的取值，這會(huì)讓人困惑應(yīng)當(dāng)以哪個(gè)出口的數(shù)據(jù)為準(zhǔn)。很多業(yè)務(wù)中表的命名可能是英文的，沒有明確的中文描述、分類或分域定義，我們也不知道它們代表的業(yè)務(wù)過程是什么，要臨時(shí)取數(shù)用哪個(gè)表合適。

2、關(guān)鍵思路

本質(zhì)是數(shù)據(jù)的確定性差，下面講述如何一步步解決這些問題。

第一個(gè)關(guān)鍵思路是具備標(biāo)準(zhǔn)化企業(yè)數(shù)據(jù)模型構(gòu)建和管理的能力。數(shù)據(jù)建模可以分為三個(gè)層面：物理建模、邏輯模型和概念模型。物理建模層主要涉及到具體執(zhí)行引擎上定義數(shù)據(jù)的具體實(shí)現(xiàn)，比如編寫一段SQL或Python代碼，通過Spark 、Hive來統(tǒng)計(jì)表格等。

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

至于物理模型，這方面已經(jīng)很成熟了。

總結(jié)一下，我們?cè)跀?shù)據(jù)建模的過程中往往缺乏的是概念模型和邏輯模型的構(gòu)建和管理能力，這會(huì)對(duì)數(shù)據(jù)的確定性造成很大影響，導(dǎo)致可理解性降低，重復(fù)冗余嚴(yán)重，同名不同義、同義不同名等一些列問題，數(shù)據(jù)空間感極差。就像在圖書館找一本沒有目錄和描述的圖書。

如果沒有良好的數(shù)據(jù)架構(gòu)支持，數(shù)據(jù)管理也會(huì)變得十分困難。所以，需要加強(qiáng)對(duì)概念模型和邏輯模型的建立和管理。

第二個(gè)關(guān)鍵思路就是基于DataOps 理念的物理建模。我們?cè)瓉淼拈_發(fā)模式是：數(shù)據(jù)集成到hive數(shù)倉或數(shù)據(jù)湖里，并撰寫一些SQL、Python代碼，配置調(diào)度作業(yè)。

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

3、如何實(shí)現(xiàn)數(shù)倉建模CRCD

這部分會(huì)說明如何實(shí)現(xiàn)數(shù)據(jù)開發(fā)流程的軟件工程化。

在進(jìn)行前后端開發(fā)時(shí)，我們要遵循軟件工程的理念，常聽到的一個(gè)詞就是面向?qū)ο缶幊獭＿@種編程方式先聲明一個(gè)對(duì)象，這個(gè)對(duì)象可能有很多屬性方法，其它對(duì)象也可以繼承這個(gè)對(duì)象。

在數(shù)據(jù)開發(fā)中，我們往往是面向表格的開發(fā)和交付，表格包含：基礎(chǔ)信息、生產(chǎn)代碼、scheme定義、調(diào)度配置，這些都可以代碼化。打通發(fā)布流水線，就可以實(shí)現(xiàn)數(shù)據(jù)開發(fā)的DevOps，也可以在整個(gè)工程實(shí)踐中增加很多事前、事中、事后的檢測(cè)約束，保障數(shù)據(jù)開發(fā)規(guī)范落地。

4、數(shù)據(jù)工程的編碼抽象

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

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

5、規(guī)范化的概念模型

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

概念建模，也是定義數(shù)據(jù)的業(yè)務(wù)模型。定義業(yè)務(wù)過程與業(yè)務(wù)主題域，可以采用樹形結(jié)構(gòu)的方式進(jìn)行定義。此外，業(yè)務(wù)過程域下還會(huì)定義一些詞根以及業(yè)務(wù)域主題的描述等。創(chuàng)建數(shù)據(jù)庫表時(shí)，必須要將其掛載在具體的業(yè)務(wù)域和主題域下。表名可以根據(jù)前后綴和關(guān)鍵點(diǎn)以及業(yè)務(wù)所在的業(yè)務(wù)過程來自動(dòng)生成。如果沒有完整的概念模型，就無法形成這種統(tǒng)一的數(shù)據(jù)資產(chǎn)目錄，除非采用人工的方式事后進(jìn)行整理。

6、規(guī)范化的邏輯模型

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

因此，概念模型實(shí)際上形成了一個(gè)虛擬的邏輯表。這個(gè)邏輯表與底層引擎無關(guān)，可以提交到Hive或spark等平臺(tái)運(yùn)行物化。整體產(chǎn)品效果如下圖：

7、指標(biāo)治理面臨的主要問題

前面講了數(shù)倉建模，那么指標(biāo)存在哪些問題呢？答案是“不知道口徑”或“口徑不一致”，原因是重復(fù)（同意不同名、同名不同義也是一種重復(fù)）。那么為什么會(huì)出現(xiàn)重復(fù)？同樣的指標(biāo)在不同的平臺(tái)被多次重復(fù)定義，導(dǎo)致難以保證口徑的一致性，從而經(jīng)常出現(xiàn)同名不同義或同義不同名的問題。

我們的方案是以Headless BI為導(dǎo)向，建立一個(gè)指標(biāo)中臺(tái)。我們希望統(tǒng)一構(gòu)建一個(gè)指標(biāo)庫并向下游提供SDK、API或類似SQL的方式來查詢這些指標(biāo)。我們能確保這個(gè)指標(biāo)庫中的指標(biāo)不會(huì)重復(fù)。例如，如果出現(xiàn)多個(gè)DAU，它們的名稱也不同，它們的口徑也不同，我們可以輕松區(qū)分它們。

然后下游系統(tǒng)便可以統(tǒng)一對(duì)接指標(biāo)查詢服務(wù)，無需重復(fù)定義和計(jì)算該指標(biāo)。而這個(gè)核心思想的關(guān)鍵在于"headless"，這個(gè)概念其實(shí)早在中臺(tái)概念提出之前就已存在。

"headless"其實(shí)就是前后端分離，由后端以API方式為上層的可視化展現(xiàn)層提供服務(wù)。可視化展現(xiàn)層可以是多個(gè)，應(yīng)用層業(yè)務(wù)也可以有多個(gè)場(chǎng)景。提供統(tǒng)一API服務(wù)，同一個(gè)指標(biāo)或服務(wù)的API保障一致性。

8、指標(biāo)中臺(tái)與敏捷分析

基于這一理念，可能會(huì)有一個(gè)問題，指標(biāo)中臺(tái)和敏捷分析有什么關(guān)系？因?yàn)橹笜?biāo)是用于分析的。這是否會(huì)導(dǎo)致降低分析的敏捷性？

實(shí)際上，我們應(yīng)該從提升數(shù)據(jù)分析效率的角度來考慮問題。影響數(shù)據(jù)分析效率的因素有多種，例如找數(shù)據(jù)的效率、計(jì)算效率、確認(rèn)數(shù)據(jù)是否正確的效率等。

如果數(shù)據(jù)不準(zhǔn)確，整體的數(shù)據(jù)分析效率也不會(huì)提高。指標(biāo)和維度的廣義定義是無限的，數(shù)據(jù)分析同學(xué)可能會(huì)隨時(shí)提出不同的指標(biāo)定義或維度想法。敏捷分析通過提倡快速定義指標(biāo)維度并即時(shí)分析。指標(biāo)中臺(tái)的定位是規(guī)范地定義指標(biāo)并提供統(tǒng)一指標(biāo)服務(wù)，在某種程度上會(huì)與敏捷矛盾。

如果規(guī)范能保證每次查找指標(biāo)時(shí)都快速定位，且結(jié)果正確，那么我認(rèn)為它的分析效率也會(huì)大幅提升。因此，歐拉指標(biāo)中臺(tái)也在提供規(guī)范化、標(biāo)準(zhǔn)化的統(tǒng)一指標(biāo)服務(wù)前提下，盡可能地提高指標(biāo)定義的敏捷性。

9、tMetric的領(lǐng)域模型

接下來我們要講的是指標(biāo)中臺(tái)的領(lǐng)域模型。

第一步：在多種數(shù)據(jù)源上創(chuàng)建數(shù)倉模型（基于星型模型的邏輯表或者物理表）。

第二步：在數(shù)倉模型之上 定義原子指標(biāo)、派生指標(biāo)以及指標(biāo)的維度

第三步：會(huì)有2個(gè)場(chǎng)景，①基于指標(biāo)定義，創(chuàng)建物化視圖或者預(yù)計(jì)算的cube；②是基于指標(biāo)定義自助生產(chǎn)數(shù)倉ADS表。

第四步：對(duì)外提供統(tǒng)一的指標(biāo)查詢API或者SDK，也可以直接在實(shí)驗(yàn)平臺(tái)、Adhoc分析等引用指標(biāo)口徑。

10、如何標(biāo)準(zhǔn)化的定義指標(biāo)

那么指標(biāo)的定義呢如何標(biāo)準(zhǔn)化指定呢？例如：以最近七天的體育類視頻播放時(shí)長為指標(biāo)，度量是視頻總播放時(shí)長，維度是性別、年齡等，業(yè)務(wù)限定體育類。統(tǒng)計(jì)周期為最近七天。最終確定了指標(biāo)定義之后，自動(dòng)生成計(jì)算SQL。這是一個(gè)基本的語義模型。

11、tMetric的的體系架構(gòu)

接下來講一下整體框架。

應(yīng)用生態(tài)：對(duì)接決策智能平臺(tái)、報(bào)表平臺(tái)、實(shí)驗(yàn)平臺(tái)和目標(biāo)管理平臺(tái)等。所有這些平臺(tái)都可以接入指標(biāo)庫，使用指標(biāo) API 或類 SQL API 獲取指標(biāo)數(shù)據(jù)。在這些平臺(tái)看到同一個(gè)指標(biāo)時(shí)，口徑一定是相同的。

• 查詢層：包括緩存、查詢協(xié)議、轉(zhuǎn)換和路由策略等。
• 語義層：指標(biāo)、維度的標(biāo)準(zhǔn)化定義和元信息維護(hù)。
• 數(shù)倉模型層：數(shù)倉邏輯表、物理表定義以及統(tǒng)一數(shù)倉模型元數(shù)據(jù)服務(wù)。
• 物化加速層：我們提供了一個(gè)統(tǒng)一的物化服務(wù)，并針對(duì)不同的指標(biāo)查詢場(chǎng)景實(shí)施不同的物化策略。這些策略包括 OLAP 的物化策略和預(yù)計(jì)算的物化策略。

12、tMetric的物化加速方案

根據(jù)不同的場(chǎng)景選擇不同的物化加速方式：

場(chǎng)景一：如果這個(gè)指標(biāo)常被觀測(cè)，其維度組合也已知，且維度基數(shù)不高，那么我們會(huì)選擇預(yù)計(jì)算方式，定義好指標(biāo)和需要使用的日常維度組合，預(yù)計(jì)算是一個(gè)cube。這種方式優(yōu)勢(shì)是查詢速度快、存儲(chǔ)、計(jì)算成本都比較低，缺點(diǎn)是多維分析的靈活性較低。

場(chǎng)景二：指標(biāo)可能具有多個(gè)維度，而未來可能需要使用的維度不確定，這時(shí)可以使用StarRocks或Clickhouse等OLAP引擎支持任意維度的OLAP查詢。通常會(huì)根據(jù)一些使用頻率較高的維度創(chuàng)建物化視圖。

場(chǎng)景三：在配置指標(biāo)時(shí)，需要快速預(yù)覽其定義以確保指標(biāo)定義正確性。為了實(shí)現(xiàn)快速預(yù)覽，使用MPP內(nèi)存計(jì)算引擎，如Presto、Impala。不過，這并不是一個(gè)頻繁的操作，通常只在定義指標(biāo)時(shí)進(jìn)行預(yù)覽查詢。

13、效果展示

三、數(shù)據(jù)發(fā)現(xiàn)

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

首先我們需要統(tǒng)一的元數(shù)據(jù)底座-Uni-Meta。它可以從各種不同的數(shù)據(jù)系統(tǒng)中獲取元數(shù)據(jù)，形成一個(gè)數(shù)據(jù)資產(chǎn)目錄，或者說一個(gè)全域的數(shù)據(jù)知識(shí)圖譜和資產(chǎn)現(xiàn)狀概覽。

四、未來展望

現(xiàn)在大家都在談?wù)揅hatGPT，也有很多人在討論AI for BI在企業(yè)中應(yīng)用的一些可能性。例如數(shù)據(jù)分析師在進(jìn)行指標(biāo)分析時(shí)面臨的痛點(diǎn)，不僅僅是知道指標(biāo)數(shù)值，關(guān)鍵痛點(diǎn)是連貫的順暢的漸進(jìn)式的分析。如果AI可以解決這個(gè)痛點(diǎn)，那將會(huì)是質(zhì)的飛躍。

但如果數(shù)據(jù)未經(jīng)治理，沒有統(tǒng)一的數(shù)據(jù)標(biāo)準(zhǔn)和數(shù)據(jù)框架，那么即使把所有的元數(shù)據(jù)信息都采集，AI的回答也會(huì)似是而非。

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

這個(gè)問題的難度在于如何構(gòu)造Prompt，如果 Prompt 基于一個(gè)或是幾個(gè)標(biāo)準(zhǔn)化的模板來構(gòu)造出來，讓 AI 填空，寫出來的SQL就能直接運(yùn)行。如果沒有標(biāo)準(zhǔn)化的模板，寫出來的SQL 大概率錯(cuò)誤，只能作為一種輔助。

因此，如果我們數(shù)據(jù)治理能力足夠強(qiáng)，AI輔助下連貫的順暢的漸進(jìn)式的分析是很可能實(shí)現(xiàn)的。

五、Q&A

Q1：騰訊如何統(tǒng)一指標(biāo)的？

A1：這個(gè)問題可以從三個(gè)層面來回答。一個(gè)層面是如何統(tǒng)一指標(biāo)的口徑，比如戰(zhàn)略層面的一些指標(biāo)如“DAU 怎么算”、“各個(gè)業(yè)務(wù)大家是不是一致認(rèn)可的”等。在這方面，我們有一個(gè)數(shù)據(jù)治理的工作組，工作組和業(yè)務(wù)的數(shù)據(jù)分析人員會(huì)有一個(gè)類似數(shù)據(jù)決策委員會(huì)的組織，在戰(zhàn)略層的一些關(guān)鍵的指標(biāo)口徑達(dá)成共識(shí)。

另一方面是技術(shù)保證口徑一致。其實(shí)就是我前面講的，我們基于headless BI 的理念，建設(shè)一個(gè)統(tǒng)一的指標(biāo)中臺(tái)tMetric，把一些常用的指標(biāo)都定義在這個(gè)指標(biāo)庫里面，下游的各個(gè)地方引用時(shí)都統(tǒng)一從這個(gè)指標(biāo)庫里獲取指標(biāo)。

第三個(gè)層面，就是日常的臨時(shí)洞察分析。廣義上的指標(biāo)其實(shí)是無法窮舉的。數(shù)據(jù)分析人員可能會(huì)忽然想到臨時(shí)指標(biāo)來統(tǒng)計(jì)分析，此時(shí)用戶的痛點(diǎn)在于怎么算這個(gè)指標(biāo)。這種場(chǎng)景往往是基于日常例行觀測(cè)指標(biāo)的衍生指標(biāo)，也就是說如果知道日常例行觀測(cè)指標(biāo)怎么算，大部分情況也能推理出自己新構(gòu)造的指標(biāo)怎么算。

Q2：環(huán)境分為開發(fā)環(huán)境、測(cè)試環(huán)境還有生產(chǎn)環(huán)境嗎？

A2：我們現(xiàn)在只有測(cè)試環(huán)境跟生產(chǎn)環(huán)境，沒有預(yù)發(fā)的過程。但未來我們也會(huì)有預(yù)發(fā)，在一些很嚴(yán)苛的場(chǎng)景，數(shù)據(jù)測(cè)試完后可以發(fā)布到預(yù)發(fā)環(huán)境可試跑幾天，確認(rèn)沒有問題再整個(gè)上線。

Q3：指標(biāo)庫的規(guī)模大概是多大？

A3：坦白說現(xiàn)在指標(biāo)的數(shù)量只有 6000 多個(gè)，但是維度的數(shù)量比較多，一個(gè)指標(biāo)可能有特別多的維度，我認(rèn)為能從各個(gè)維度去看這個(gè)指標(biāo)才是最大的挑戰(zhàn)。

Q4：系統(tǒng)地講一下在數(shù)據(jù)治理中用到了哪些 AI 技術(shù)？

A4：我覺得是兩個(gè)方面。

一個(gè)是通過 AI 手段來提升數(shù)據(jù)治理的自動(dòng)化的水平。通過 AI直接自動(dòng)化治理是比較難的，畢竟數(shù)據(jù)治理有很強(qiáng)的業(yè)務(wù)性，需要理解業(yè)務(wù)模式和數(shù)據(jù)專家經(jīng)驗(yàn)。但 AI 的一些技術(shù)可以加強(qiáng)數(shù)據(jù)治理工具能力，比如有些表可能沒有描述，之前要人工梳理和補(bǔ)充表描，但現(xiàn)在 AI 可以根據(jù)表的一些數(shù)據(jù)的樣本自動(dòng)補(bǔ)充描述，自動(dòng)給數(shù)據(jù)分類。

第二個(gè)是 AI 對(duì)數(shù)據(jù)治理的促進(jìn)作用，也就是用 AI 做增強(qiáng)分析。但如前文所言，這需要極高的數(shù)據(jù)治理的水平，需要數(shù)據(jù)治理的平臺(tái)化和生產(chǎn)即治理的模式，事后治理不能滿足 AI for BI的需求的。

Q5：枚舉值的最初來源是埋點(diǎn)信息嗎？

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

Q6：概念模型和邏輯模型在沒有平臺(tái)化管理的情況下，應(yīng)該怎么迭代管理？

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

Q7：騰訊如何量化評(píng)估指標(biāo)資產(chǎn)的價(jià)值？

A7：這個(gè)是大家都很關(guān)心的問題，其實(shí)也就是數(shù)據(jù)治理。

那么我們?nèi)绾巫尷习逯劳读诉@么多資源的最終效果呢？其實(shí)數(shù)據(jù)治理本質(zhì)上就是 4 個(gè)方面：成本、質(zhì)量、安全風(fēng)險(xiǎn)和效率。單點(diǎn)治理時(shí)，切入點(diǎn)可以選成本，好度量。質(zhì)量也有一些評(píng)估的方法，比如數(shù)據(jù)的及時(shí)性、數(shù)據(jù)問題反饋率和數(shù)據(jù)異常率等。

數(shù)據(jù)安全和效率的效果量化困難比較困難，可以先組織大家形成共識(shí)，確定必須要做的事，在這個(gè)前提下再定義量化指標(biāo)來牽引結(jié)果。我們的組織是數(shù)據(jù)治理工作組，量化指標(biāo)是我前面講的資產(chǎn)分，通過量化評(píng)估把大家的治理水平拉到一個(gè)評(píng)價(jià)標(biāo)準(zhǔn)上，誰的資產(chǎn)分低，說明說誰的治理效果可能存在問題。

總結(jié)來講，先通過組織共識(shí)目標(biāo)（要做什么），再定義量化指標(biāo)牽引目標(biāo)達(dá)成，量化指標(biāo)的定義也要注意，粗略的正確好過精確的錯(cuò)誤。

Q8：如果構(gòu)建了指標(biāo)體系，傳統(tǒng)的數(shù)倉會(huì)不會(huì)做的比較薄？

A8：數(shù)倉應(yīng)該會(huì)下沉，比如說原來數(shù)倉有大量的ADS 表，現(xiàn)在就收斂到DWD或者少數(shù)DWS表，我認(rèn)為可以通過指標(biāo)中臺(tái)的指標(biāo)定義，自動(dòng)化或半自動(dòng)化地生產(chǎn)大量應(yīng)用層的表。

Q9：最后一問題的話是說現(xiàn)在經(jīng)濟(jì)環(huán)境不好，那業(yè)務(wù)都要敏捷，那數(shù)據(jù)治理怎么敏捷跟上業(yè)務(wù)的發(fā)展？

A9：我認(rèn)為現(xiàn)在整個(gè)行業(yè)更偏向像保守的方向，倡導(dǎo)降本增效。數(shù)據(jù)治理的目標(biāo)就是降本增效，剛好符合現(xiàn)在的企業(yè)訴求，原來不重視數(shù)據(jù)治理，同一個(gè)指標(biāo)可能會(huì)反復(fù)統(tǒng)計(jì)多次，計(jì)算跟存儲(chǔ)成本會(huì)非常高。現(xiàn)在數(shù)據(jù)治理想辦法幫業(yè)務(wù)降本增效。做好這點(diǎn)，就是對(duì)業(yè)務(wù)發(fā)展最好的幫助。