概述

上一篇文章主要介紹了數(shù)據(jù)中臺(tái)的原理知識(shí)，現(xiàn)在開(kāi)始介紹數(shù)據(jù)中臺(tái)的實(shí)現(xiàn)篇章，主要從3個(gè)方面來(lái)說(shuō)明，第一個(gè)是元數(shù)據(jù)的管理，第二個(gè)是指標(biāo)的規(guī)范的管理，第三個(gè)是數(shù)據(jù)模型的建立。

元數(shù)據(jù)

在原理篇中，我提到數(shù)據(jù)中臺(tái)的構(gòu)建，需要確保全局指標(biāo)的業(yè)務(wù)口徑一致，要把原先口徑不一致的、重復(fù)的指標(biāo)進(jìn)行梳理，整合成一個(gè)統(tǒng)一的指標(biāo)字典。而這項(xiàng)工作的前提，是要搞清楚這些指標(biāo)的業(yè)務(wù)口徑、數(shù)據(jù)來(lái)源和計(jì)算邏輯。而這些數(shù)據(jù)呢都是元數(shù)據(jù)。你可以認(rèn)為，如果沒(méi)有這些元數(shù)據(jù)，就沒(méi)法去梳理指標(biāo)，更談不上構(gòu)建一個(gè)統(tǒng)一的指標(biāo)體系。當(dāng)你看到一個(gè)數(shù) 700W，如果你不知道這個(gè)數(shù)對(duì)應(yīng)的指標(biāo)是每日日活，就沒(méi)辦法理解這個(gè)數(shù)據(jù)的業(yè)務(wù)含義，也就無(wú)法去整合這些數(shù)據(jù)。所以你必須要掌握元數(shù)據(jù)的管理，才能構(gòu)建一個(gè)數(shù)據(jù)中臺(tái)。

那么問(wèn)題來(lái)了：元數(shù)據(jù)中心應(yīng)該包括哪些元數(shù)據(jù)呢？ 什么樣的數(shù)據(jù)是元數(shù)據(jù)？

元數(shù)據(jù)分類

結(jié)合我的實(shí)踐經(jīng)驗(yàn)，我把元數(shù)據(jù)劃為三類：數(shù)據(jù)字典、數(shù)據(jù)血緣和數(shù)據(jù)特征。我們還是通過(guò)一個(gè)例子來(lái)理解這三類元數(shù)據(jù)。

在這個(gè)圖中，dwd_trd_order_df 是一張訂單交易明細(xì)數(shù)據(jù)，任務(wù) flow_dws_trd_sku_1d 讀取這張表，按照 sku 粒度，計(jì)算每日 sku 的交易金額和訂單數(shù)量，輸出輕度匯總表 dws_trd_sku_1d。數(shù)據(jù)字典描述的是數(shù)據(jù)的結(jié)構(gòu)信息，我們以 dws_trd_sku_1d 為例，數(shù)據(jù)字典包括：

數(shù)據(jù)血緣是指一個(gè)表是直接通過(guò)哪些表加工而來(lái)，在上面的例子中，dws_trd_sku_1d 是通過(guò) dwd_trd_order_df 的數(shù)據(jù)計(jì)算而來(lái)，所以，dwd_trd_order_df 是 dws_trd_sku_1d 的上游表。數(shù)據(jù)血緣一般會(huì)幫我們做影響分析和故障溯源。比如說(shuō)有一天，你的老板看到某個(gè)指標(biāo)的數(shù)據(jù)違反常識(shí)，讓你去排查這個(gè)指標(biāo)計(jì)算是否正確，你首先需要找到這個(gè)指標(biāo)所在的表，然后順著這個(gè)表的上游表逐個(gè)去排查校驗(yàn)數(shù)據(jù)，才能找到異常數(shù)據(jù)的根源。而數(shù)據(jù)特征主要是指數(shù)據(jù)的屬性信息，我們以 dws_trd_sku_1d 為例：

通過(guò)這個(gè)例子，你了解了元數(shù)據(jù)了嗎？ 不過(guò)元數(shù)據(jù)的種類非常多，為了管理這些元數(shù)據(jù)，你必須要構(gòu)建一個(gè)元數(shù)據(jù)中心。那么接下來(lái)，我們就來(lái)看看如何搭建一個(gè)元數(shù)據(jù)中心，打通企業(yè)的元數(shù)據(jù)。

業(yè)界元數(shù)據(jù)中心產(chǎn)品

我做系統(tǒng)設(shè)計(jì)這么些年，一直有一個(gè)習(xí)慣，是先看看業(yè)界的產(chǎn)品都是怎么設(shè)計(jì)的，避免關(guān)門造車。業(yè)界的比較有影響力的產(chǎn)品：

開(kāi)源的有 Netflix 的 Metacat、Apache Atlas；

商業(yè)化的產(chǎn)品有 Cloudera Navigator。

我今天重點(diǎn)想帶你了解 Metacat 和 Atlas 這兩款產(chǎn)品，一個(gè)擅長(zhǎng)于管理數(shù)據(jù)字典，一個(gè)擅長(zhǎng)于管理數(shù)據(jù)血緣，通過(guò)了解這兩款產(chǎn)品，你更能深入的理解元數(shù)據(jù)中心應(yīng)該如何設(shè)計(jì)。

Metacat 多數(shù)據(jù)源集成型架構(gòu)設(shè)計(jì)關(guān)于Metacat，你可以在 GitHub 上找到相關(guān)介紹，所以關(guān)于這個(gè)項(xiàng)目的背景和功能特性，我就不再多講，我只想強(qiáng)調(diào)一個(gè)點(diǎn)，就是它多數(shù)據(jù)源的可擴(kuò)展架構(gòu)設(shè)計(jì)，因?yàn)檫@個(gè)點(diǎn)對(duì)于數(shù)據(jù)字典的管理，真的太重要！

在一般的公司中，數(shù)據(jù)源類型非常多是很常見(jiàn)的現(xiàn)象，包括 Hive、MySQL、Oracle、Greenplum 等等。支持不同數(shù)據(jù)源，建立一個(gè)可擴(kuò)展的、統(tǒng)一的元數(shù)據(jù)層是非常重要的，否則你的元數(shù)據(jù)是缺失的。從上面 Metacat 的架構(gòu)圖中，你可以看到，Metacat 的設(shè)計(jì)非常巧妙，它并沒(méi)有單獨(dú)再保存一份元數(shù)據(jù)，而是采取直連數(shù)據(jù)源拉的方式，一方面它不存在保存兩份元數(shù)據(jù)一致性的問(wèn)題，另一方面，這種架構(gòu)設(shè)計(jì)很輕量化，每個(gè)數(shù)據(jù)源只要實(shí)現(xiàn)一個(gè)連接實(shí)現(xiàn)類即可，擴(kuò)展成本很低，我把這種設(shè)計(jì)叫做集成型設(shè)計(jì)。我認(rèn)為這種設(shè)計(jì)方式對(duì)于希望構(gòu)建元數(shù)據(jù)中心的企業(yè)，是非常有借鑒意義的。

Apache Atlas 實(shí)時(shí)數(shù)據(jù)血緣采集同樣，關(guān)于Apache Atlas的背景和功能，我也不多說(shuō)，只是想強(qiáng)調(diào) Atlas 實(shí)時(shí)數(shù)據(jù)血緣采集的架構(gòu)設(shè)計(jì)，因?yàn)樗鼮榻鉀Q血緣采集的準(zhǔn)確性和時(shí)效性難題提供了很多的解決思路。血緣采集，一般可以通過(guò)三種方式：

通過(guò)靜態(tài)解析 SQL，獲得輸入表和輸出表；

通過(guò)實(shí)時(shí)抓取正在執(zhí)行的 SQL，解析執(zhí)行計(jì)劃，獲取輸入表和輸出表；

通過(guò)任務(wù)日志解析的方式，獲取執(zhí)行后的 SQL 輸入表和輸出表。

第一種方式，面臨準(zhǔn)確性的問(wèn)題，因?yàn)槿蝿?wù)沒(méi)有執(zhí)行，這個(gè) SQL 對(duì)不對(duì)都是一個(gè)問(wèn)題。第三種方式，血緣雖然是執(zhí)行后產(chǎn)生的，可以確保是準(zhǔn)確的，但是時(shí)效性比較差，通常要分析大量的任務(wù)日志數(shù)據(jù)。所以第二種方式，我認(rèn)為是比較理想的實(shí)現(xiàn)方式，而 Atlas 就是這種實(shí)現(xiàn)。

對(duì)于 Hive 計(jì)算引擎，Atlas 通過(guò) Hook 方式，實(shí)時(shí)地捕捉任務(wù)執(zhí)行計(jì)劃，獲取輸入表和輸出表，推送給 Kafka，由一個(gè) Ingest 模塊負(fù)責(zé)將血緣寫(xiě)入 JanusGraph 圖數(shù)據(jù)庫(kù)中。然后通過(guò) API 的方式，基于圖查詢引擎，獲取血緣關(guān)系。對(duì)于 Spark，Atlas 提供了 Listener 的實(shí)現(xiàn)方式，此外 Sqoop、Flink 也有對(duì)應(yīng)的實(shí)現(xiàn)方式。這兩款產(chǎn)品在設(shè)計(jì)網(wǎng)易元數(shù)據(jù)中心時(shí)，給了很多靈感，下面我就帶你了解一下其他元數(shù)據(jù)中心的設(shè)計(jì)，以便你掌握一個(gè)元數(shù)據(jù)中心在設(shè)計(jì)時(shí)應(yīng)該考慮哪些點(diǎn)。

我設(shè)定了元數(shù)據(jù)中心必須實(shí)現(xiàn)的 5 個(gè)關(guān)鍵目標(biāo)：

其一，多業(yè)務(wù)線、多租戶支持。電商、音樂(lè)都是不同的業(yè)務(wù)線，同一個(gè)業(yè)務(wù)線內(nèi)，也分為算法、數(shù)倉(cāng)、風(fēng)控等多個(gè)租戶，所以元數(shù)據(jù)中心必須支持多業(yè)務(wù)線、多租戶。

其二，多數(shù)據(jù)源的支持。元數(shù)據(jù)中心必須要能夠支持不同類型的數(shù)據(jù)源（比如 MySQL、Hive、Kudu 等），同時(shí)還要支持相同數(shù)據(jù)源的多個(gè)集群。為了規(guī)范化管理，還需要考慮將半結(jié)構(gòu)化的 KV 也納入元數(shù)據(jù)中心的管理（比如 Kafka、Redis、HBase 等）。這些系統(tǒng)本身并沒(méi)有表結(jié)構(gòu)元數(shù)據(jù)，所以需要能夠在元數(shù)據(jù)中心里定義 Kafka 每個(gè) Topic 的每條記錄 JSON 中的格式，每個(gè)字段代表什么含義。

其三，數(shù)據(jù)血緣。元數(shù)據(jù)中心需要支持?jǐn)?shù)據(jù)血緣的實(shí)時(shí)采集和高性能的查詢。同時(shí)，還必須支持字段級(jí)別的血緣。什么是字段級(jí)別的血緣，我們來(lái)舉個(gè)例子。

1 insert overwrite table t2 select classid, count(userid) from t1 groupby classid;

t2 表是由 t1 表的數(shù)據(jù)計(jì)算來(lái)的，所以 t2 和 t1 是表血緣上下游關(guān)系，t2 的 classid 字段是由 t1 的 classid 字段產(chǎn)生的，count 字段是由 userid 經(jīng)過(guò)按照 classid 字段聚合計(jì)算得到的，所以 t2 表的 classid 與 t1 的 classid 存在字段血緣，t2 表的 count 分別與 t1 表的 classid 和 userid 存在血緣關(guān)系。

字段血緣在做溯源的時(shí)候非常有用，因?yàn)榇髷?shù)據(jù)加工鏈路的下游是集市層，為了方便使用者使用，一般都是一些很寬的表（列很多的表，避免 Join 帶來(lái)的性能損耗），這個(gè)表的上游可能是有幾十個(gè)表產(chǎn)生的，如果不通過(guò)字段血緣限定溯源范圍，就會(huì)導(dǎo)致搜索范圍變得很大，無(wú)法快速地精準(zhǔn)定位到有問(wèn)題的表。另外，數(shù)據(jù)血緣還必須要支持生命周期管理，已經(jīng)下線的任務(wù)應(yīng)該立即清理血緣，血緣要保留一段時(shí)間，如果沒(méi)有繼續(xù)被調(diào)度，過(guò)期的血緣關(guān)系應(yīng)該予以清理。

其四，與大數(shù)據(jù)平臺(tái)集成。元數(shù)據(jù)中心需要與 Ranger 集成，實(shí)現(xiàn)基于 tag 的權(quán)限管理方式。在元數(shù)據(jù)中心中可以為表定義一組標(biāo)簽，Ranger 可以基于這個(gè)標(biāo)簽，對(duì)擁有某一個(gè)標(biāo)簽的一組表按照相同的權(quán)限授權(quán)。這種方式大幅提高了權(quán)限管理的效率。比如，對(duì)于會(huì)員、交易、毛利、成本，可以設(shè)定表的敏感等級(jí)，然后根據(jù)敏感等級(jí)，設(shè)定不同的人有權(quán)限查看。另外，元數(shù)據(jù)中心作為基礎(chǔ)元數(shù)據(jù)服務(wù)，包括自助取數(shù)分析系統(tǒng)，數(shù)據(jù)傳輸系統(tǒng)，數(shù)據(jù)服務(wù)，都應(yīng)該基于元數(shù)據(jù)中心提供的統(tǒng)一接口獲取元數(shù)據(jù)。

其五，數(shù)據(jù)標(biāo)簽。元數(shù)據(jù)中心必須要支持對(duì)表和表中的字段打標(biāo)簽，通過(guò)豐富的不同類型的標(biāo)簽，可以完善數(shù)據(jù)中臺(tái)數(shù)據(jù)的特征，比如指標(biāo)可以作為一種類型的標(biāo)簽打在表上，主題域、分層信息都可以作為不同類型的標(biāo)簽關(guān)聯(lián)到表。

基于這 5 個(gè)因素的考慮，我們?cè)O(shè)計(jì)了元數(shù)據(jù)中心。

這個(gè)圖按照功能模塊分為數(shù)據(jù)血緣、數(shù)據(jù)字典和數(shù)據(jù)特征。數(shù)據(jù)血緣由采集端、消息中間件、消費(fèi)端以及血緣清理模塊組成，基于 Hive Hook，Spark Listener，F(xiàn)link Hook ，可以獲取任務(wù)執(zhí)行時(shí)輸入表和輸出表，推送給統(tǒng)一的消息中間件（Kafka），然后消費(fèi)端負(fù)責(zé)將血緣關(guān)系沉淀到圖數(shù)據(jù)庫(kù)中。圖數(shù)據(jù)庫(kù)選擇 Neo4j，主要考慮是性能快、部署輕量化、依賴模塊少，當(dāng)然，開(kāi)源的 Neo4j 沒(méi)有高可用方案，并且不支持水平擴(kuò)展，但是因?yàn)閱蝹€(gè)業(yè)務(wù)活躍的表規(guī)模基本也就在幾萬(wàn)的規(guī)模，所以單機(jī)也夠用，高可用可以通過(guò)雙寫(xiě)的方式實(shí)現(xiàn)。血緣還有一個(gè)清理的模塊，主要負(fù)責(zé)定時(shí)清理過(guò)期的血緣，一般我們把血緣的生命周期設(shè)置為 7 天。數(shù)據(jù)字典部分，我們參考了 Metacat 實(shí)現(xiàn)，我們由一個(gè)統(tǒng)一的 Connector Mananger 負(fù)責(zé)管理到各個(gè)數(shù)據(jù)源的連接。對(duì)于 Hive、MySQL，元數(shù)據(jù)中心并不會(huì)保存系統(tǒng)元數(shù)據(jù)，而是直接連數(shù)據(jù)源實(shí)時(shí)獲取。對(duì)于 Kafka、HBase、Redis 等 KV，我們?cè)谠獢?shù)據(jù)中心里內(nèi)置了一個(gè)元數(shù)據(jù)管理模塊，可以在這個(gè)模塊中定義 Value 的 schema 信息。數(shù)據(jù)特征主要是標(biāo)簽的管理以及數(shù)據(jù)的訪問(wèn)熱度信息。元數(shù)據(jù)中心內(nèi)置了不同類型的標(biāo)簽，同時(shí)允許用戶自定義擴(kuò)展標(biāo)簽類型。指標(biāo)、分層信息、主題域信息都是以標(biāo)簽的形式存儲(chǔ)在元數(shù)據(jù)中心的系統(tǒng)庫(kù)里，同時(shí)元數(shù)據(jù)中心允許用戶基于標(biāo)簽類型和標(biāo)簽搜索表和字段。元數(shù)據(jù)中心統(tǒng)一對(duì)外提供了 API 訪問(wèn)接口，數(shù)據(jù)傳輸、數(shù)據(jù)地圖、數(shù)據(jù)服務(wù)等其他的子系統(tǒng)都可以通過(guò) API 接口獲取元數(shù)據(jù)。另外 Ranger 可以基于元數(shù)據(jù)中心提供的 API 接口，獲取標(biāo)簽對(duì)應(yīng)的表，然后根據(jù)標(biāo)簽更新表對(duì)應(yīng)的權(quán)限，實(shí)現(xiàn)基于標(biāo)簽的權(quán)限控制。元數(shù)據(jù)中心構(gòu)建好以后，你肯定會(huì)問(wèn)，這個(gè)元數(shù)據(jù)中心沒(méi)有界面嗎？它長(zhǎng)什么樣子？用戶咋使用這個(gè)元數(shù)據(jù)中心？ 別急，我們接著往下看。

數(shù)據(jù)地圖：元數(shù)據(jù)中心的界面

數(shù)據(jù)地圖是基于元數(shù)據(jù)中心構(gòu)建的一站式企業(yè)數(shù)據(jù)資產(chǎn)目錄，可以看作是元數(shù)據(jù)中心的界面。數(shù)據(jù)開(kāi)發(fā)、分析師、數(shù)據(jù)運(yùn)營(yíng)、算法工程師可以在數(shù)據(jù)地圖上完成數(shù)據(jù)的檢索，解決了“不知道有哪些數(shù)據(jù)？”“到哪里找數(shù)據(jù)？”“如何準(zhǔn)確的理解數(shù)據(jù)”的難題。

數(shù)據(jù)地圖提供了多維度的檢索功能，使用者可以按照表名、列名、注釋、主題域、分層、指標(biāo)進(jìn)行檢索，結(jié)果按照匹配相關(guān)度進(jìn)行排序。考慮到數(shù)據(jù)中臺(tái)中有一些表是數(shù)倉(cāng)維護(hù)的表，有一些表數(shù)倉(cāng)已經(jīng)不再維護(hù)，在結(jié)果排序的時(shí)候，增加了數(shù)倉(cāng)維護(hù)的表優(yōu)先展示的規(guī)則。同時(shí)數(shù)據(jù)地圖還提供了按照主題域、業(yè)務(wù)過(guò)程導(dǎo)覽，可以幫助使用者快速了解當(dāng)前有哪些表可以使用。

當(dāng)使用者定位到某一個(gè)表打開(kāi)時(shí)，會(huì)進(jìn)入詳情頁(yè)，詳情頁(yè)中會(huì)展示表的基礎(chǔ)信息，字段信息、分區(qū)信息、產(chǎn)出信息以及數(shù)據(jù)血緣。數(shù)據(jù)血緣可以幫助使用者了解這個(gè)表的來(lái)源和去向，這個(gè)表可能影響的下游應(yīng)用和報(bào)表，這個(gè)表的數(shù)據(jù)來(lái)源。

數(shù)據(jù)地圖同時(shí)還提供了數(shù)據(jù)預(yù)覽的功能，考慮到安全性因素，只允許預(yù)覽 10 條數(shù)據(jù)，用于判斷數(shù)據(jù)是否符合使用者的預(yù)期。數(shù)據(jù)地圖提供的收藏功能， 方便使用者快速找到自己經(jīng)常使用的表。當(dāng)數(shù)據(jù)開(kāi)發(fā)、分析師、數(shù)據(jù)運(yùn)營(yíng)找到自己需要的表時(shí)，在數(shù)據(jù)地圖上可以直接發(fā)起申請(qǐng)對(duì)該表的權(quán)限申請(qǐng)。數(shù)據(jù)地圖對(duì)于提高數(shù)據(jù)發(fā)現(xiàn)的效率，實(shí)現(xiàn)非技術(shù)人員自助取數(shù)有重要作用。經(jīng)過(guò)我的實(shí)踐，數(shù)據(jù)地圖是數(shù)據(jù)中臺(tái)中使用頻率最高的一個(gè)工具產(chǎn)品，在網(wǎng)易，每天都有 500 以上人在使用數(shù)據(jù)地圖查找數(shù)據(jù)。

數(shù)據(jù)指標(biāo)規(guī)范

元數(shù)據(jù)在指標(biāo)管理、模型設(shè)計(jì)、數(shù)據(jù)質(zhì)量和成本治理四個(gè)領(lǐng)域都發(fā)揮著作用，而這些領(lǐng)域構(gòu)成了數(shù)據(jù)中臺(tái) OneData 數(shù)據(jù)體系。從今天開(kāi)始，我將帶你逐一了解元數(shù)據(jù)在上述領(lǐng)域的應(yīng)用，首先是指標(biāo)管理。指標(biāo)是一種特定類型的元數(shù)據(jù)，公司的運(yùn)營(yíng)會(huì)圍繞它進(jìn)行工作，可以說(shuō)，它是業(yè)務(wù)和數(shù)據(jù)的交匯點(diǎn)。指標(biāo)數(shù)據(jù)能不能用，會(huì)影響他們的日常工作。來(lái)看一件我身邊發(fā)生的事兒。在電商業(yè)務(wù)中，新用戶銷售額是考核市場(chǎng)活動(dòng)拉新效果的重要指標(biāo)。馬漂亮（化名）是市場(chǎng)部門的數(shù)據(jù)分析師，某一天，她要給 CEO 提供一份數(shù)據(jù)報(bào)告，報(bào)告中有一項(xiàng)指標(biāo)是“新用戶銷售額”。孫美麗（化名）是會(huì)員中心的運(yùn)營(yíng)，她每天都會(huì)給 CEO 提供每日的新用戶銷售額數(shù)據(jù)。結(jié)果有一天，CEO 看了這兩份報(bào)告后發(fā)現(xiàn)，同一日的新用戶銷售額數(shù)值相差很大，他判斷數(shù)據(jù)出了問(wèn)題，責(zé)令兩個(gè)部門的負(fù)責(zé)人進(jìn)行排查。排查后發(fā)現(xiàn)，市場(chǎng)部門對(duì)新用戶口徑的定義和會(huì)員中心不一樣：

市場(chǎng)部門認(rèn)定新用戶是首次下單并完成支付的用戶；

會(huì)員中心認(rèn)定新用戶是當(dāng)日新注冊(cè)用戶。

也就是說(shuō)，市場(chǎng)部門認(rèn)定的新用戶中，可能有之前注冊(cè)但是沒(méi)有下過(guò)單的客戶；而會(huì)員中心只包括當(dāng)日注冊(cè)并完成下單支付的用戶。其實(shí)，在日常工作中還有很多類似的問(wèn)題。造成上述問(wèn)題的根源是因?yàn)橹笜?biāo)口徑不一致，而你要構(gòu)建全局一致的指標(biāo)口徑，輸出企業(yè)的指標(biāo)字典。

指標(biāo)混亂現(xiàn)狀

同名不同徑，同徑不同名。口徑不清晰，口徑有錯(cuò)誤。命名難理解，計(jì)算不易懂。來(lái)源不清晰，同部不同徑。

第一，相同指標(biāo)名稱，口徑定義不同。我開(kāi)篇說(shuō)的就是這個(gè)問(wèn)題，不同的部門對(duì)相同的“新用戶銷售額”，因?yàn)榭趶蕉x的差別，導(dǎo)致指標(biāo)數(shù)值的不一致。而這種情況是指標(biāo)管理中最容易出現(xiàn)的情況。口徑不一致，數(shù)據(jù)也就沒(méi)辦法橫向?qū)Ρ龋チ藬?shù)據(jù)輔助商業(yè)決策的意義。

第二，相同口徑，指標(biāo)名稱不一樣。這種情況與上面相反，比如發(fā)放優(yōu)惠券是電商常見(jiàn)的促銷手段，現(xiàn)在你有兩個(gè)數(shù)據(jù)產(chǎn)品：一個(gè)是經(jīng)營(yíng)大腦，主要展示的是企業(yè)日常經(jīng)營(yíng)活動(dòng)健康度的核心指標(biāo)，它有一個(gè)指標(biāo)叫“優(yōu)惠券抵扣金額”；一個(gè)是市場(chǎng) 360，主要是展示市場(chǎng)活動(dòng)效果衡量的指標(biāo)，它也有一個(gè)指標(biāo)叫“優(yōu)惠券消耗金額”。其實(shí)，兩者的口徑定義并沒(méi)有區(qū)別，但是指標(biāo)名稱不同，這會(huì)讓使用指標(biāo)的人疑惑，是不是同一個(gè)指標(biāo)，計(jì)算邏輯是否一致？數(shù)據(jù)是否可以橫向?qū)Ρ龋?/p>

第三，不同限定詞，描述相同事實(shí)過(guò)程的兩個(gè)指標(biāo)，相同事實(shí)部分口徑不一致。

第四，指標(biāo)口徑描述不清晰。在梳理過(guò)程中，我們還發(fā)現(xiàn)，有些報(bào)表上的指標(biāo)口徑描述的比較籠統(tǒng)。比如“關(guān)單金額”，口徑描述“關(guān)閉訂單的金額”。不同人的理解可能不一樣，有的人會(huì)認(rèn)為是支付成功后關(guān)閉訂單；也有可能是支付完成前，取消訂單。描述不清晰，就會(huì)讓人們對(duì)數(shù)據(jù)的理解產(chǎn)生歧義。

第五，指標(biāo)口徑描述錯(cuò)誤。在流量分析數(shù)據(jù)產(chǎn)品中，有“7 日 uv”這個(gè)指標(biāo)，口徑的定義是 7 日內(nèi)日均 uv。根據(jù)口徑描述的計(jì)算邏輯，應(yīng)該是最近 7 日，每日 uv 相加除以 7 取平均值。顯然，這個(gè)定義在業(yè)務(wù)場(chǎng)景中是有問(wèn)題的，正確的 7 日 uv 的口徑定義應(yīng)該是 7 日內(nèi)有登錄過(guò)，去重的用戶數(shù)。

第六，指標(biāo)命名難于理解。我們?cè)谑崂泶黉N業(yè)務(wù)過(guò)程的指標(biāo)時(shí)，有一個(gè)數(shù)據(jù)產(chǎn)品的指標(biāo)名稱是“ROI”，口徑定義優(yōu)惠券銷售額 / 優(yōu)惠券成本。ROI 其實(shí)是投資回報(bào)率的簡(jiǎn)稱，在電商業(yè)務(wù)場(chǎng)景中，除了優(yōu)惠劵，商品降價(jià)促銷都可以計(jì)算 ROI，所以比較好的命名應(yīng)該是（商品|類目|通用）優(yōu)惠劵 ROI。所以，指標(biāo)命名不規(guī)范的話，從指標(biāo)名稱中很難看出指標(biāo)描述的業(yè)務(wù)過(guò)程。

最后，指標(biāo)數(shù)據(jù)來(lái)源和計(jì)算邏輯不清晰。如果指標(biāo)數(shù)據(jù)來(lái)源不清楚，一旦這個(gè)指標(biāo)數(shù)據(jù)異常，就很難去做溯源。另外，有些指標(biāo)的計(jì)算邏輯比較復(fù)雜，僅僅憑借業(yè)務(wù)口徑一段描述，使用指標(biāo)的人還是無(wú)法理解這個(gè)指標(biāo)的計(jì)算邏輯，這個(gè)時(shí)候就需要有一些偽碼或者 SQL 描述。

如何規(guī)范化定義指標(biāo)

那么如果你面臨這些問(wèn)題，該如何規(guī)范化定義指標(biāo)呢？我提供給你一些經(jīng)驗(yàn)，希望你能從中學(xué)習(xí)到如何高效、規(guī)范化的管理指標(biāo)。

為了提高指標(biāo)管理的效率，你需要按照業(yè)務(wù)線、主題域和業(yè)務(wù)過(guò)程三級(jí)目錄方式管理指標(biāo)（業(yè)務(wù)線是頂級(jí)目錄）。電商、游戲、音樂(lè)、傳媒、教育都是不同的業(yè)務(wù)線。在業(yè)務(wù)線之下，是主題域，指標(biāo)中的主題域與數(shù)倉(cāng)中的概念是一致的，劃分標(biāo)準(zhǔn)最好是跟數(shù)倉(cāng)保持一致（數(shù)倉(cāng)主題域的劃分，我會(huì)在 06 講詳細(xì)講述）。在主題域下面還有細(xì)分的業(yè)務(wù)過(guò)程，比如對(duì)于交易域，細(xì)分的業(yè)務(wù)過(guò)程有加入購(gòu)物車、下單、支付。

其次，拆分原子指標(biāo)和派生指標(biāo)。為了解決前面提到的，“黑卡購(gòu)買用戶數(shù)”和“非會(huì)員購(gòu)買用戶數(shù)”，這兩個(gè)指標(biāo)對(duì)購(gòu)買用戶數(shù)口徑定義不一致的問(wèn)題，我們需要引入原子指標(biāo)和派生指標(biāo)的管理方式。那么什么是原子指標(biāo)，什么是派生指標(biāo)呢？統(tǒng)計(jì)周期、統(tǒng)計(jì)粒度、業(yè)務(wù)限定、原子指標(biāo)，組成派生指標(biāo)，所以原子指標(biāo)可以定義為不能夠按照上述規(guī)則進(jìn)一步拆分的指標(biāo)。

在例子中，你可以這樣理解：購(gòu)買用戶數(shù)是原子指標(biāo)，原子指標(biāo)的口徑定義是“計(jì)算周期內(nèi)去重的，下單并且支付成功的用戶數(shù)量，包括關(guān)單”；黑卡會(huì)員和非會(huì)員都可以認(rèn)定為業(yè)務(wù)限定詞；統(tǒng)計(jì)粒度是商品粒度的；統(tǒng)計(jì)周期是 30 天。

這樣 30 天內(nèi)，商品維度的黑卡會(huì)員購(gòu)買用戶數(shù)和 30 天內(nèi)商品維度的非會(huì)員購(gòu)買用戶數(shù)就作為兩個(gè)派生指標(biāo)存在，但是他們繼承自同一個(gè)原子指標(biāo)。

除此之外，還需要指標(biāo)命名規(guī)范。指標(biāo)命名規(guī)范要遵循兩個(gè)基本的原則：易懂，就是看到指標(biāo)的名稱，就可以基本判斷這個(gè)指標(biāo)歸屬于哪個(gè)業(yè)務(wù)過(guò)程；統(tǒng)一，就是要確保派生指標(biāo)和它繼承的原子指標(biāo)命名是一致的。除此之外，指標(biāo)應(yīng)該有指標(biāo)名稱和指標(biāo)標(biāo)識(shí)（或者叫英文名）。

對(duì)于原子指標(biāo)，指標(biāo)名稱適合用“動(dòng)作 + 度量”的命名方式（比如注冊(cè)用戶數(shù)、購(gòu)買用戶數(shù)），標(biāo)識(shí)的命名用英文簡(jiǎn)寫(xiě)或者漢語(yǔ)拼音縮寫(xiě)比較好。對(duì)于派生指標(biāo)，指標(biāo)名稱應(yīng)該嚴(yán)格遵循“時(shí)間周期 + 統(tǒng)計(jì)粒度 + 修飾詞 + 原子指標(biāo)”的命名方式，標(biāo)識(shí)命名要用“修飾詞 _ 原子指標(biāo) _ 時(shí)間周期”的方式。

第四，關(guān)聯(lián)的應(yīng)用和可分析維度。對(duì)于使用指標(biāo)的人（運(yùn)營(yíng)、分析師）了解了這個(gè)指標(biāo)的口徑定義之后，下一步就是要看指標(biāo)的數(shù)值。所以，在全局的指標(biāo)字典中，還應(yīng)該有指標(biāo)被哪些應(yīng)用使用，這樣方便去對(duì)應(yīng)的數(shù)據(jù)產(chǎn)品或者報(bào)表上查看指標(biāo)的數(shù)值。除此之外，還應(yīng)該有指標(biāo)的可分析維度，方便分析師從不同的維度分析指標(biāo)的變化趨勢(shì)。

最后一個(gè)是分等級(jí)管理。那這么多指標(biāo)，數(shù)據(jù)中臺(tái)管的過(guò)來(lái)么？是的，確實(shí)管不過(guò)來(lái)，因?yàn)椴粌H僅是數(shù)據(jù)中臺(tái)會(huì)產(chǎn)出一些公共核心指標(biāo)，業(yè)務(wù)部門也會(huì)創(chuàng)建一些專屬業(yè)務(wù)部門內(nèi)的指標(biāo)。那面對(duì)這么多指標(biāo)，如何管理呢？以我的經(jīng)驗(yàn)，你可以按照以下原則區(qū)分等級(jí)，來(lái)管理指標(biāo)。一級(jí)指標(biāo)：數(shù)據(jù)中臺(tái)直接產(chǎn)出，核心指標(biāo)（提供給公司高層看的）、原子指標(biāo)以及跨部門的派生指標(biāo)。二級(jí)指標(biāo)：基于中臺(tái)提供的原子指標(biāo)，業(yè)務(wù)部門創(chuàng)建的派生指標(biāo)。不同等級(jí)的指標(biāo)意味著管理方式不同：一級(jí)指標(biāo)，要確保指標(biāo)按時(shí)、保證質(zhì)量產(chǎn)出，指標(biāo)創(chuàng)建由中臺(tái)負(fù)責(zé)；二級(jí)指標(biāo)，允許業(yè)務(wù)方自己創(chuàng)建，中臺(tái)不承諾指標(biāo)的產(chǎn)出時(shí)間和質(zhì)量。現(xiàn)在你了解如何管理指標(biāo)了嗎？ 我建議你在學(xué)完這部分知識(shí)以后，結(jié)合自己所在的業(yè)務(wù)，找一些指標(biāo)，試著按照上面的方法實(shí)踐一下，這樣掌握得會(huì)加更深刻。

指標(biāo)系統(tǒng)

在了解如何管理指標(biāo)之后，我們還需要一款好用的工具，幫助我們落實(shí)管理方法。我觀察到，很多公司喜歡用 Excel 管理指標(biāo)，覺(jué)得 Excel 上手容易，編輯比較方便。在我看來(lái)，Excel 并不是一個(gè)適合指標(biāo)管理的工具，有這樣幾個(gè)原因：難于共享；缺少權(quán)限控制；無(wú)法動(dòng)態(tài)更新；指標(biāo)無(wú)法跟數(shù)倉(cāng)的模型動(dòng)態(tài)關(guān)聯(lián)。所以，我們需要一個(gè)面向指標(biāo)的管理系統(tǒng)。

指標(biāo)系統(tǒng)是基于元數(shù)據(jù)中心構(gòu)建的一個(gè)指標(biāo)管理工具，它從元數(shù)據(jù)中心自動(dòng)同步數(shù)倉(cāng)的主題域和業(yè)務(wù)過(guò)程，按照規(guī)范化定義創(chuàng)建指標(biāo)。新創(chuàng)建的指標(biāo)同時(shí)會(huì)以特定類型的標(biāo)簽，下沉到元數(shù)據(jù)中心對(duì)應(yīng)的表和字段上，這樣在數(shù)據(jù)地圖上就可以搜索到表關(guān)聯(lián)的指標(biāo)。

既然指標(biāo)系統(tǒng)能夠?qū)崿F(xiàn)指標(biāo)的規(guī)范化定義，幫你解決“如何系統(tǒng)化、規(guī)范化定義指標(biāo)”的問(wèn)題，那接下來(lái)我們的重點(diǎn)就是如何基于指標(biāo)系統(tǒng)構(gòu)建全局的指標(biāo)字典，因?yàn)檫@是指標(biāo)治理的最終結(jié)果。

基于指標(biāo)系統(tǒng)構(gòu)建全局的指標(biāo)字典指標(biāo)治理的最終結(jié)果，就是要形成一個(gè)全局業(yè)務(wù)口徑一致的指標(biāo)字典。讓使用指標(biāo)的人，可以通過(guò)指標(biāo)字典，快速了解指標(biāo)的業(yè)務(wù)含義和計(jì)算過(guò)程，不會(huì)對(duì)指標(biāo)口徑產(chǎn)生歧義。數(shù)據(jù)中臺(tái)團(tuán)隊(duì)必須要有一個(gè)專門負(fù)責(zé)指標(biāo)管理的人或者小組（一般不超過(guò) 3 個(gè)人），最好是數(shù)據(jù)產(chǎn)品經(jīng)理來(lái)負(fù)責(zé)，如果你的公司沒(méi)有這個(gè)職位，也可以讓分析師承擔(dān)（前提是分析師必須屬于中臺(tái)團(tuán)隊(duì)）。

構(gòu)建全局的指標(biāo)字典分為兩個(gè)場(chǎng)景：一個(gè)是面對(duì)一個(gè)新的指標(biāo)需求，如何基于指標(biāo)系統(tǒng)完成指標(biāo)開(kāi)發(fā)流程；另外一個(gè)是面對(duì)已經(jīng)存在的，混亂的指標(biāo)現(xiàn)狀，如何進(jìn)行全局梳理。

我們先看第一個(gè)場(chǎng)景。

這個(gè)圖詳細(xì)地描述了新建指標(biāo)的流程，流程中參與的各個(gè)角色。我在這里想強(qiáng)調(diào)幾點(diǎn)：

指標(biāo)需求評(píng)審，需要需求方、數(shù)據(jù)開(kāi)發(fā)、應(yīng)用開(kāi)發(fā)都參加。評(píng)審首先要確認(rèn)這是不是一個(gè)新的指標(biāo)，并明確它是原子指標(biāo)還是派生指標(biāo)。評(píng)審的目的就是要大家達(dá)成一致。

評(píng)審的結(jié)果一種是不需要開(kāi)發(fā)，是一個(gè)已經(jīng)存在的指標(biāo)，直接可以通過(guò)設(shè)計(jì)邏輯模型（具體我會(huì)在數(shù)據(jù)服務(wù)章節(jié)講），發(fā)布接口，獲取數(shù)據(jù)。第二種就是需要開(kāi)發(fā)。前者交付時(shí)間短，后者需要排期，交付時(shí)間長(zhǎng)。

上面我提到指標(biāo)有一級(jí)和二級(jí)之分，這個(gè)流程適用于一級(jí)指標(biāo)，對(duì)于二級(jí)指標(biāo)，可以不需要評(píng)審，當(dāng)然開(kāi)發(fā)也是由業(yè)務(wù)方開(kāi)發(fā)和發(fā)布上線。

接下來(lái)，我們來(lái)看第二個(gè)場(chǎng)景。除了新建指標(biāo)的流程，對(duì)于很多公司，已經(jīng)有一定的大數(shù)據(jù)業(yè)務(wù)，但是還不能算是一個(gè)中臺(tái)，那這部分公司該如何進(jìn)行一次全局的指標(biāo)梳理呢？我認(rèn)為應(yīng)該有以下幾個(gè)步驟：成立以數(shù)據(jù)產(chǎn)品或者分析師為核心的 1～3 人的工作小組，專門負(fù)責(zé)指標(biāo)的全局梳理；制定指標(biāo)梳理計(jì)劃，明確指標(biāo)梳理目標(biāo)，覆蓋多少個(gè)業(yè)務(wù)線，與業(yè)務(wù)方共同制定時(shí)間計(jì)劃；對(duì)于每一個(gè)業(yè)務(wù)線，需要對(duì)還在使用的數(shù)據(jù)報(bào)表、數(shù)據(jù)產(chǎn)品進(jìn)行盤點(diǎn)，這里順便可以把沒(méi)用的報(bào)表和數(shù)據(jù)產(chǎn)品應(yīng)該下線；對(duì)于每一個(gè)報(bào)表和數(shù)據(jù)產(chǎn)品中涉及的指標(biāo)，按照以下格式進(jìn)行收集；

對(duì)于收集的指標(biāo)，明確業(yè)務(wù)口徑，對(duì)于口徑相同的，應(yīng)該去除重復(fù)，關(guān)聯(lián)的應(yīng)用應(yīng)該合并，此時(shí)以我的經(jīng)驗(yàn)，可以過(guò)濾掉相當(dāng)一部分；根據(jù)指標(biāo)業(yè)務(wù)口徑，明確指標(biāo)所屬的主題域、業(yè)務(wù)過(guò)程；區(qū)分指標(biāo)類型，對(duì)于派生指標(biāo)，要明確指標(biāo)的統(tǒng)計(jì)粒度、修飾詞、時(shí)間周期以及關(guān)聯(lián)的原子指標(biāo)；按照指標(biāo)系統(tǒng)對(duì)指標(biāo)的規(guī)范化定義，把整理好的指標(biāo)錄入指標(biāo)系統(tǒng)。通過(guò)全局的梳理和新建指標(biāo)流程的管控，你就可以構(gòu)建一個(gè)全局一致的指標(biāo)字典了。

數(shù)據(jù)模型

我?guī)懔私饬藬?shù)據(jù)中臺(tái)如何管理指標(biāo)，如果我們把指標(biāo)比喻成一棵樹(shù)上的果實(shí)，那模型就是這棵大樹(shù)的軀干，想讓果實(shí)結(jié)得好，必須讓樹(shù)干變得粗壯。

先來(lái)看一幕真實(shí)的場(chǎng)景。大多數(shù)公司的分析師會(huì)結(jié)合業(yè)務(wù)做一些數(shù)據(jù)分析（需要用到大量的數(shù)據(jù)），通過(guò)報(bào)表的方式服務(wù)于業(yè)務(wù)部門的運(yùn)營(yíng)。但是在數(shù)據(jù)中臺(tái)構(gòu)建之前，分析師經(jīng)常發(fā)現(xiàn)自己沒(méi)有可以復(fù)用的數(shù)據(jù)，不得不使用原始數(shù)據(jù)進(jìn)行清洗、加工、計(jì)算指標(biāo)。由于他們大多是非技術(shù)專業(yè)出身，寫(xiě)的 SQL 質(zhì)量比較差，我甚至見(jiàn)過(guò) 5 層以上的嵌套。這種 SQL 對(duì)資源消耗非常大，會(huì)造成隊(duì)列阻塞，影響其他數(shù)倉(cāng)任務(wù)，會(huì)引起數(shù)據(jù)開(kāi)發(fā)的不滿。數(shù)據(jù)開(kāi)發(fā)會(huì)要求收回分析師的原始數(shù)據(jù)讀取權(quán)限，分析師又會(huì)抱怨數(shù)倉(cāng)數(shù)據(jù)不完善，要啥沒(méi)啥，一個(gè)需求經(jīng)常要等一周甚至半個(gè)月。分析師與數(shù)據(jù)開(kāi)發(fā)的矛盾從此開(kāi)始。這個(gè)矛盾的根源在于數(shù)據(jù)模型無(wú)法復(fù)用，數(shù)據(jù)開(kāi)發(fā)是煙囪式的，每次遇到新的需求，都從原始數(shù)據(jù)重新計(jì)算，自然耗時(shí)。而要解決這個(gè)矛盾，就要搞清楚我們的數(shù)據(jù)模型應(yīng)該設(shè)計(jì)成什么樣子。

什么才是一個(gè)好的數(shù)據(jù)模型設(shè)計(jì)？

來(lái)看一組數(shù)據(jù)，這兩個(gè)表格是基于元數(shù)據(jù)中心提供的血緣信息，分別對(duì)大數(shù)據(jù)平臺(tái)上運(yùn)行的任務(wù)和分析查詢（Ad-hoc）進(jìn)行的統(tǒng)計(jì)。

下圖是數(shù)倉(cāng)分層架構(gòu)圖，方便你回憶數(shù)據(jù)模型分層的設(shè)計(jì)架構(gòu)：

我們首先來(lái)看表 1。表 1 中有 2547 張未識(shí)別分層的表，占總表 6049 的 40%，它們基本沒(méi)辦法復(fù)用。 重點(diǎn)是在已識(shí)別分層的讀表任務(wù)中，ODS：DWD：DWS：ADS 的讀取任務(wù)分別是 1072：545：187：433，直接讀取 ODS 層任務(wù)占這四層任務(wù)總和的 47.9%，這說(shuō)明有大量任務(wù)都是基于原始數(shù)據(jù)加工，中間模型復(fù)用性很差。我們?cè)賮?lái)看看表 2，在已識(shí)別的分層的查詢中，ODS：DWD：DWS：ADS 的命中的查詢分別是 892：1008：152：305，有 37.8% 的查詢直接命中 ODS 層原始數(shù)據(jù)，說(shuō)明 DWD、DWS、ADS 層數(shù)據(jù)建設(shè)缺失嚴(yán)重。尤其是 ADS 和 DWS，查詢?cè)降讓拥谋恚蜁?huì)導(dǎo)致查詢掃描的數(shù)據(jù)量會(huì)越大，查詢時(shí)間會(huì)越長(zhǎng)，查詢的資源消耗也越大，使用數(shù)據(jù)的人滿意度會(huì)低。最后，我們進(jìn)一步對(duì) ODS 層被讀取的 704 張表進(jìn)行分解，發(fā)現(xiàn)有 382 張表的下游產(chǎn)出是 DWS，ADS，尤其是 ADS 達(dá)到了 323 張表，占 ODS 層表的比例 45.8%，說(shuō)明有大量 ODS 層表被進(jìn)行物理深加工。通過(guò)上面的分析，我們似乎已經(jīng)找到了一個(gè)理想的數(shù)倉(cāng)模型設(shè)計(jì)應(yīng)該具備的因素，那就是“數(shù)據(jù)模型可復(fù)用，完善且規(guī)范”。

如何衡量完善度

DWD 層完善度：衡量 DWD 層是否完善，最好看 ODS 層有多少表被 DWS/ADS/DM 層引用。因?yàn)?DWD 以上的層引用的越多，就說(shuō)明越多的任務(wù)是基于原始數(shù)據(jù)進(jìn)行深度聚合計(jì)算的，明細(xì)數(shù)據(jù)沒(méi)有積累，無(wú)法被復(fù)用，數(shù)據(jù)清洗、格式化、集成存在重復(fù)開(kāi)發(fā)。因此，我提出用跨層引用率指標(biāo)衡量 DWD 的完善度。跨層引用率：ODS 層直接被 DWS/ADS/DM 層引用的表，占所有 ODS 層表（僅統(tǒng)計(jì)活躍表）比例。跨層引用率越低越好，在數(shù)據(jù)中臺(tái)模型設(shè)計(jì)規(guī)范中，我們要求不允許出現(xiàn)跨層引用，ODS 層數(shù)據(jù)只能被 DWD 引用。

DWS/ADS/DM 層完善度：考核匯總數(shù)據(jù)的完善度，我認(rèn)為主要看匯總數(shù)據(jù)能直接滿足多少查詢需求（也就是用匯總層數(shù)據(jù)的查詢比例衡量）。如果匯總數(shù)據(jù)無(wú)法滿足需求，使用數(shù)據(jù)的人就必須使用明細(xì)數(shù)據(jù)，甚至是原始數(shù)據(jù)。匯總數(shù)據(jù)查詢比例：DWS/ADS/DM 層的查詢占所有查詢的比例。你要明確的是，這個(gè)跟跨層引用率不同，匯總查詢比例不可能做到 100%，但值越高，說(shuō)明上層的數(shù)據(jù)建設(shè)越完善，對(duì)于使用數(shù)據(jù)的人來(lái)說(shuō)，查詢速度和成本會(huì)減少，用起來(lái)會(huì)更爽。

如何衡量復(fù)用度

數(shù)據(jù)中臺(tái)模型設(shè)計(jì)的核心是追求模型的復(fù)用和共享，通過(guò)元數(shù)據(jù)中心的數(shù)據(jù)血緣圖，我們可以看到，一個(gè)比較差的模型設(shè)計(jì)，自下而上是一條線。而一個(gè)理想的模型設(shè)計(jì)，它應(yīng)該是交織的發(fā)散型結(jié)構(gòu)。

我提出用模型引用系數(shù)作為指標(biāo)，衡量數(shù)據(jù)中臺(tái)模型設(shè)計(jì)的復(fù)用度。引用系數(shù)越高，說(shuō)明數(shù)倉(cāng)的復(fù)用性越好。模型引用系數(shù)：一個(gè)模型被讀取，直接產(chǎn)出下游模型的平均數(shù)量。比如一張 DWD 層表被 5 張 DWS 層表引用，這張 DWD 層表的引用系數(shù)就是 5，如果把所有 DWD 層表（有下游表的）引用系數(shù)取平均值，則為 DWD 層表平均模型引用系數(shù)，一般低于 2 比較差，3 以上相對(duì)比較好（經(jīng)驗(yàn)值）。

如何衡量規(guī)范度

表 1 中，超過(guò) 40% 的表都沒(méi)有分層信息，在模型設(shè)計(jì)層面，這顯然是不規(guī)范的。除了看這個(gè)表有沒(méi)有分層，還要看它有沒(méi)有歸屬到主題域（例如交易域）如果沒(méi)有歸屬主題域，就很難找到這張表，也無(wú)法復(fù)用。其次，你要看表的命名。拿 stock 這個(gè)命名為例，當(dāng)你看到這個(gè)表時(shí)，知道它是哪個(gè)主題域、業(yè)務(wù)過(guò)程？是全量數(shù)據(jù)的表，還是每天的增量數(shù)據(jù)？總的來(lái)說(shuō)，通過(guò)這個(gè)表名獲取的信息太有限了。一個(gè)規(guī)范的表命名應(yīng)該包括主題域、分層、表是全量快照，還是增量等信息。除此之外，如果在表 A 中用戶 ID 的命名是 UserID，在表 B 中用戶 ID 命名是 ID，就會(huì)對(duì)使用者造成困擾，這到底是不是一個(gè)東西。所以我們要求相同的字段在不同的模型中，它的命名必須是一致的。

講了這么多，你要如何吸收經(jīng)驗(yàn)?zāi)兀吭谶@里，我給你幾點(diǎn)建議。

你可以拿著這些指標(biāo)去評(píng)估一下，自己的數(shù)倉(cāng)現(xiàn)狀如何。

然后制訂一些針對(duì)性的改進(jìn)計(jì)劃，比如把這些不規(guī)范命名的表消滅掉，把主題域覆蓋的表比例提高到 90% 以上。

在嘗試完一段時(shí)間的模型重構(gòu)和優(yōu)化后，再拿著這些指標(biāo)去測(cè)一測(cè)是不是真的變好了。我見(jiàn)過(guò)很多數(shù)據(jù)開(kāi)發(fā)在向上級(jí)匯報(bào)工作時(shí)，喜歡用重構(gòu)了多少模型說(shuō)明工作成果，很多老大會(huì)想，這些重構(gòu)到底對(duì)數(shù)據(jù)建設(shè)有多少幫助？有沒(méi)有一些量化的指標(biāo)可以衡量？我想有上面的知識(shí)，你可以應(yīng)對(duì)這個(gè)問(wèn)題了。

現(xiàn)在你知道什么是好的數(shù)倉(cāng)設(shè)計(jì)了，可目前已經(jīng)存在了大量煙囪式開(kāi)發(fā)，具體怎么做才能讓它變成一個(gè)數(shù)據(jù)中臺(tái)呢？

如何從煙囪式的小數(shù)倉(cāng)到共享的數(shù)據(jù)中臺(tái)

建設(shè)數(shù)據(jù)中臺(tái)本質(zhì)就是構(gòu)建企業(yè)的公共數(shù)據(jù)層，把原先分散的、煙囪式的、雜亂的小數(shù)倉(cāng)，合并成一個(gè)可共享、可復(fù)用的數(shù)據(jù)中臺(tái)。結(jié)合我的實(shí)踐經(jīng)驗(yàn)，我給你幾點(diǎn)建議。

第一，接管 ODS 層，控制源頭。ODS 是業(yè)務(wù)數(shù)據(jù)進(jìn)入數(shù)據(jù)中臺(tái)的第一站，是所有數(shù)據(jù)加工的源頭，控制住源頭，才能從根本上防止一個(gè)重復(fù)的數(shù)據(jù)體系的出現(xiàn)。數(shù)據(jù)中臺(tái)團(tuán)隊(duì)必須明確職責(zé)，全面接管 ODS 層數(shù)據(jù)，從業(yè)務(wù)系統(tǒng)的源數(shù)據(jù)庫(kù)權(quán)限入手，確保數(shù)據(jù)從業(yè)務(wù)系統(tǒng)產(chǎn)生后進(jìn)入數(shù)據(jù)倉(cāng)庫(kù)時(shí)，只能在數(shù)據(jù)中臺(tái)保持一份。這個(gè)可以跟業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)管理者達(dá)成一致，只有中臺(tái)團(tuán)隊(duì)的賬號(hào)才能同步數(shù)據(jù)。ODS 層表的數(shù)據(jù)必須和數(shù)據(jù)源的表結(jié)構(gòu)、表記錄數(shù)一致，高度無(wú)損，對(duì)于 ODS 層表的命名采用 ODS_ 業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)名 _ 業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)表名方式，比如 ods_warehous_stock，warehous 是業(yè)務(wù)系統(tǒng)數(shù)據(jù)庫(kù)名，stock 是該庫(kù)下面的表名。

第二，劃分主題域，構(gòu)建總線矩陣。主題域是業(yè)務(wù)過(guò)程的抽象集合。可能這么講，稍微有點(diǎn)兒抽象，但其實(shí)業(yè)務(wù)過(guò)程就是企業(yè)經(jīng)營(yíng)過(guò)程中一個(gè)個(gè)不可拆分的行為事件，比如倉(cāng)儲(chǔ)管理里面有入庫(kù)、出庫(kù)、發(fā)貨、簽收，都是業(yè)務(wù)過(guò)程，抽象出來(lái)的主題域就是倉(cāng)儲(chǔ)域。

主題域劃分要盡量涵蓋所有業(yè)務(wù)需求，保持相對(duì)穩(wěn)定性，還具備一定的擴(kuò)展性（新加入一個(gè)主題域，不影響已經(jīng)劃分的主題域的表）。主題域劃分好以后，就要開(kāi)始構(gòu)建總線矩陣，明確每個(gè)主題域下的業(yè)務(wù)過(guò)程有哪些分析維度，舉個(gè)例子：

第三，構(gòu)建一致性維度。售后團(tuán)隊(duì)的投訴工單數(shù)量有針對(duì)地區(qū)的分析維度，而配送團(tuán)隊(duì)的配送延遲也有針對(duì)地區(qū)的分析維度，你想分析因?yàn)榕渌脱舆t導(dǎo)致的投訴增加，但是兩個(gè)地區(qū)的分析維度包含內(nèi)容不一致，最終會(huì)導(dǎo)致一些地區(qū)沒(méi)辦法分析。所以我們構(gòu)建全局一致性的維表，確保維表只存一份。維度統(tǒng)一的最大的難題在于維度屬性（如果維度是商品，那么商品類別、商品品牌、商品尺寸等商品的屬性，我們稱為維度屬性）的整合。是不是所有維度屬性都要整合到一個(gè)大的維表中，也不見(jiàn)得，我給你幾個(gè)建議。

公共維度屬性與特有維度屬性拆成兩個(gè)維表。在自營(yíng)平臺(tái)中，通常也會(huì)有一些第三方的商家入駐，但是數(shù)量很少。大部分商品其實(shí)都沒(méi)有店鋪的屬性，這種情況，就不建議將店鋪和商品的其他維度屬性，比如商品類別、品牌設(shè)計(jì)成一個(gè)維表。

產(chǎn)出時(shí)間相差較大的維度屬性拆分單獨(dú)的維表，比如有些維度屬性產(chǎn)出時(shí)間在凌晨 2 點(diǎn)，有些維度屬性產(chǎn)出時(shí)間在凌晨 6 點(diǎn)，那 2 點(diǎn)和 6 點(diǎn)的就可以拆成兩個(gè)維表，確保核心維表盡早產(chǎn)出。

出于維表穩(wěn)定性產(chǎn)出的考慮，你可以將更新頻繁的和變化緩慢的進(jìn)行拆分，訪問(wèn)頻繁的和訪問(wèn)較少的維表進(jìn)行拆分。對(duì)于維表的規(guī)范化命名，建議你用“DIM_ 主題域 _ 描述 _ 分表規(guī)則”方式。分表你可以這樣理解：一個(gè)表存儲(chǔ)幾千億行記錄實(shí)在是太大了，所以需要把一個(gè)表切割成很多小的分區(qū)，每天或者每周，隨著任務(wù)被調(diào)度，會(huì)生成一個(gè)分區(qū)。我提供給你一個(gè)常見(jiàn)的分區(qū)規(guī)則（這個(gè)規(guī)則你在用的時(shí)候，查閱就可以了）。

第四，事實(shí)表整合。我覺(jué)得事實(shí)表整合遵循的最基本的一個(gè)原則是，統(tǒng)計(jì)粒度必須保持一致，不同統(tǒng)計(jì)粒度的數(shù)據(jù)不能出現(xiàn)在同一個(gè)事實(shí)表中。來(lái)看一個(gè)例子：

在數(shù)據(jù)中臺(tái)構(gòu)建前，供應(yīng)鏈部門、倉(cāng)儲(chǔ)部門和市場(chǎng)部門都有一些重復(fù)的事實(shí)表，我們需要將這些重復(fù)的內(nèi)容進(jìn)行去除，按照交易域和倉(cāng)儲(chǔ)域，主題域的方式進(jìn)行整合。

對(duì)于倉(cāng)儲(chǔ)部門和供應(yīng)鏈部門都有的庫(kù)存明細(xì)表，因?yàn)閭}(cāng)儲(chǔ)部門的統(tǒng)計(jì)粒度是商品加倉(cāng)庫(kù)，而供應(yīng)鏈部門的只有商品，所以原則上兩個(gè)表是不能合并，而是應(yīng)該獨(dú)立存在。

對(duì)于市場(chǎng)部門和供應(yīng)鏈部門的兩張下單明細(xì)表，因?yàn)榻y(tǒng)計(jì)粒度都是訂單級(jí)別，都?xì)w屬于交易域下的下單業(yè)務(wù)過(guò)程，所以可以合并為一張事實(shí)表。除此之外，還應(yīng)該考慮將不全的數(shù)據(jù)補(bǔ)齊。對(duì)于 ODS 層直接被引用產(chǎn)出 DWS/ADS/DM 層的任務(wù)，通過(guò)血緣，找到任務(wù)清單，逐個(gè)進(jìn)行拆解。沒(méi)有 ODS 對(duì)應(yīng)的 DWD 的，應(yīng)該生成 DWD 表，對(duì)于已經(jīng)存在的，應(yīng)該遷移任務(wù)，使用 DWD 層表。

DWD/DWS/ADS/DM 的命名規(guī)則適合采用“[層次][主題][子主題][內(nèi)容描述][分表規(guī)則]”的命名方式。

第五，模型開(kāi)發(fā)。模型設(shè)計(jì)完成后，就進(jìn)入模型開(kāi)發(fā)階段，我想提幾個(gè)你需要注意的點(diǎn)：

所有任務(wù)都必須嚴(yán)格配置任務(wù)依賴，如果沒(méi)有配置任務(wù)依賴，會(huì)導(dǎo)致前一個(gè)任務(wù)沒(méi)有正常產(chǎn)出數(shù)據(jù)的情況下，后一個(gè)任務(wù)被調(diào)度起來(lái)，基于錯(cuò)誤的數(shù)據(jù)空跑，浪費(fèi)資源，同時(shí)增加了排查故障的復(fù)雜度；

任務(wù)中創(chuàng)建的臨時(shí)表，在任務(wù)結(jié)束前應(yīng)該刪除，如果不刪除，會(huì)發(fā)現(xiàn)有大量的臨時(shí)表存在，占用空間；

任務(wù)名稱最好跟表名一致，方便查找和關(guān)聯(lián)；

生命周期的管理，對(duì)于 ODS 和 DWD，一般盡可能保留所有歷史數(shù)據(jù)，對(duì)于DWS/ADS/DM 需要設(shè)置生命周期，7～30 天不等；

DWD 層表宜采用壓縮的方式存儲(chǔ)，可用 lzo 壓縮。

第六，應(yīng)用遷移。最后一步就是應(yīng)用的遷移，這個(gè)過(guò)程的核心是要注意數(shù)據(jù)的比對(duì)，確保數(shù)據(jù)的完全一致，然后進(jìn)行應(yīng)用遷移，刪除老的數(shù)據(jù)表。總的來(lái)說(shuō)，建設(shè)數(shù)據(jù)中臺(tái)不是一口氣就能吃成一個(gè)胖子，它的建設(shè)往往是滾雪球的方式，隨著一個(gè)個(gè)應(yīng)用的遷移，中臺(tái)的數(shù)據(jù)也越來(lái)越豐滿，發(fā)揮的價(jià)值也越來(lái)越大。

總結(jié)

以后關(guān)于數(shù)據(jù)中臺(tái)系列的總結(jié)大部分來(lái)自Geek Time的課件，大家可以自行關(guān)鍵字搜索。

總結(jié)

以上是生活随笔為你收集整理的数据中台学习笔记-元数据管理，指标管理，数据模型的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。