一、整體思路與框架

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

(相關資料圖)

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

1、平臺主旨

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

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

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

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

2、評價體系

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

3、數(shù)據(jù)痛點及平臺應對方案

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

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

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

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

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

4、歐拉的服務框架

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2、關鍵思路

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

8、指標中臺與敏捷分析

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

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

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

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

9、tMetric的領域模型

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

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

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

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

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

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

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

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

接下來講一下整體框架。

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

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

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

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

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

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

13、效果展示三、數(shù)據(jù)發(fā)現(xiàn)

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

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

四、未來展望

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

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

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

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

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

五、Q&AQ1：騰訊如何統(tǒng)一指標的？

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

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

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

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

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

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

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

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

A4：我覺得是兩個方面。

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

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

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

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

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

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

Q7：騰訊如何量化評估指標資產(chǎn)的價值？

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

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

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

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

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

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

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

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

關鍵詞：