一、背景及現狀

首先來介紹一下當前企業數倉建設的現狀。

1、模型分層和建模流程

數倉建設的意義，簡單來說就是將業務數據通過整合、轉換、計算以及其它一些操作，提取出有價值的信息，最終把這些信息反饋給業務，為業務的發展持續賦能。

從技術上來看，現在通用的模型遵循圖中的分層設計準則。源頭是ODS層，即引入層，嚴選的數據主要有兩個來源，一個是數據庫binlog對應的快照，另一個是日志，包括業務日志、埋點日志、APP日志等等。

中間部分是數倉建模。包括貼源層，我們命名為DWD事實層，然后是DWS明細層，第三層是DWS匯總層，再后面是DM集市層，主要是面向上層的應用以及數據產品的需求。

圖中右邊是嚴選數倉建模的生命周期。首先是業務調研和需求分析；然后定義指標，進行數據刻畫；第三步就是進行邏輯模型的設計，把不同的指標和它們的維度進行關聯，也就是進行數據組織的過程；第四步就是編碼開發，將數據生產出來；接下來是上線交付、對外服務，也就是進行數據使用；最后就是長期的運行維護。

2、網易嚴選數倉現狀

網易嚴選的核心業務是電商，數倉建設已有六七年時間，已經具有了相當大的規模，有大量的模型和指標都在服務于各種各樣的生產環境上的產品。其中物理模型的數量有一萬多個，開發任務有近萬個，指標數也有近萬個，產品和服務有數十個。

嚴選整個數倉建模流程中的各個步驟都有相應的一些產品進行承接，比如指標設計，就是通過我們的指標管理系統進行指標定義和模型設計；模型開發和任務運維是通過離線開發平臺進行編碼；數據對外提供服務是通過數據服務平臺。由于歷史原因，我們各個產品之間目前基本上是獨立的狀態，沒有形成一個完整的體系，而各系統也存在著一些問題，包括接下來將重點介紹的指標管理系統。

3、舊指標管理系統現狀

舊的指標管理系統存在的問題大致可以歸納為四大方面：

首先是功能邊界有限。當前系統不支持DW層模型的設計和管理，沒有模型物理化能力，無法有效指導模型開發，缺乏與任務運維和數據服務關聯的能力。

第二是指標定義不規范。存在比較多的指標重復定義、原子指標命名不規范、原子指標與派生指標混用等。比如包含派生詞、未包含統計單位，另外非匯總數據也可能被錯誤的定義成一些指標，比如一些根據機器學習算法得出預測值。

第三是模型設計不規范。模型命名分層不清晰，模型開發線上化率比較低，存在大量沒有進行登記的模型，模型與指標的關聯關系也比較混亂。整個模型設計，沒有跟模型開發進行強綁定，可能有些需求比較緊急就導致開發人員忽略了設計過程。

第四是模型構建不規范。邏輯模型與物理模型的結構存在差異。存在很多煙囪式的開發，導致指標被重復計算。還有跨層依賴問題，比如DM層直接依賴了最底下的DWD層；反向依賴問題，比如DWS層依賴了DM層，DM層的有些數據當作匯總表在用。

4、數倉建設的痛點

通過對現有系統的量化分析，我們整理出了當前數倉建設的痛點。

首先，業務復雜多變，比如電商會經常做活動，各種玩法帶來很多復雜的業務流程，由此帶來的就是數倉體量龐大，數據之間的關系網非常復雜。

其次，事前規劃不足，模型設計能力欠缺，經常出現指標重復定義、描述不規范的情況，指標和模型缺乏嚴謹性。

第三，設計和實現過程就脫節，一方面開發效率低下，職責不清，存在重復計算的問題，另外，依賴關系混亂，人工編碼也很容易引入錯誤。

第四，事后治理困難，由于事前和事中沒有做好，就會導致事后治理起來非常困難，比如業務有變動，模型設計或者指標的計算方式就會有變化，但是很難追溯，變更過程非常復雜。數據質量也就無法保障，運維管理過程會非常低效。

第五，數據孤島問題，指標口徑不一致，觀察視角不統一，比如開發人員看到的是指標模型，而上層應用可能看到的是表字段的視角，繼而導致學習和使用數據的成本比較高。

二、解決方案

1、方案切入點

針對上述痛點，我們制定了以建設完整、規范的數倉建模體系為目標的解決方案：制定一個標準，輸出一款產品，落地一套規范。

我們在一開始的時候其實是有一個標準的，但僅停留在文檔層面，并沒有非常好的落地。所以希望通過產品化的方式，對這套標準進行強制的規范落地。產品會包括業務過程管理、維度管理、指標定義、模型設計等能力。通過這款產品，落地一整套的規范，比如指標定位數據、數據訪問約束，以及后期的模型治理、任務運維規范等等。

2、方案做什么-平臺定位

我們的數倉建模平臺，整體上還是以經典的數倉建模方法論為理論依據，結合網易嚴選的數倉建設現狀，對標業界優秀的相關產品，借助大數據其它產品能力，指導數倉從設計、開發、使用到最后維護，這樣一套全流程一站式的解決方案。

上圖中右邊是我們新建的數據建模平臺在大數據體系中的定位，以及與其它一些平臺的關聯。

3、方案怎么做-產品框架

上圖是整體的產品框架，產品功能重點在紅框中的數據模型設計部分。主要分為五大塊內容：數據規劃、數據標準、維度建模、數據指標和數據資產。其中維度建模和數據指標是我們整個產品設計的核心。數據規劃和數據標準主要是結合嚴選現狀，做一些定制化內容，相對來說沒有后面幾塊做的靈活。

下面一層是數據開發，這一層就是將上面的邏輯定義設計真正落實到代碼當中。最下面是物理層，包括引擎、存儲、計算等等。

右邊的應用場景包括數據報表、風控引擎、用戶畫像、榜單服務、輿情管理等等。

4、方案怎么做-功能模塊

功能模塊中，有三個核心的功能模塊：

第一塊是業務過程和指標定義，包括業務過程定義、總線矩陣設計、維度管理、度量定義、原子指標管理、派生指標管理等等。

第二塊是邏輯模型設計，結合現狀設計了一個分層模型，最底下是數據引入層ODS層；通過清洗轉換，形成了明細模型DWD層；再通過一些細粒度計算，以及一些復雜的數據規劃（如歸一化、標準化、維度計算等），形成數據服務模型DWS明細層，在這個明細層關聯原子指標；然后再把原子指標這一層數據進行派生匯總，形成匯總DWS層，這一層模型跟派生指標進行關聯；最后上面是面向應用的集市層DM，按需進行取數。

第三塊是模型物理化和構建，主要包括模型進行物理化，任務的發布和運維，以及數據服務的生成和綁定。

三、實施步驟

1、實施過程-3步走戰略

嚴選數倉規范化建設制定了三步走的戰略：

第一步是規范指標定義體系建設，包括規范業務過程、度量、指標命名、指標分類、派生依賴、匯總算法、派生算法、派生詞關聯等等。

第二步是規范模型的設計體系建設，在指標定義規范的前提下，進行模型設計的規范，包括模型命名、分層、依賴、數據時效、維度關聯等等。

第三步是規范指標計算和模型構建的過程，我們希望不僅模型是規范的，數據的生產過程也必須是規范的，包括結構的一致性、自動構建任務、任務運維、變更通知、算法優化、參數調優等。

2、實施步驟1 - 規范指標定義體系建設

第一個實施步驟是規范指標定義體系的建設。原先的設計流程通常僅僅是很隨意地錄入到舊的指標管理系統中，經常存在指標含義表述不清、重復設計等問題；此外還存在不少指標只記錄在離線文檔，口口相傳。

規范后的定義流程按照下面五步強制流程來走：

（1）切分業務域。

（2）進行維度設計，生成派生詞，也就是業務限定。

（3）設計業務過程，包括確定業務流程，設計維度矩陣以及度量。

（4）設計原子指標、衍生原子指標，包括關聯度量，明確數據類型、匯總方式，公式化地描述衍生原子指標的計算方式。

（5）基于原子指標，設計派生指標、派生計算指標，保證派生指標能夠自動關聯依賴的原子指標，確定派生詞集合以及時間周期，自動生成中英文標識。

對于指標派生和依賴的規范建設，我們制定了各類指標派生的原則，定義派生指標=統計周期+派生詞集合+原子指標。比如”日支付成功抖音渠道銷售額“，“日”就是統計周期，“支付成功”是支付狀態維度的一個派生詞，“抖音渠道”是渠道維度的一個派生詞，“銷售額”是原子指標。

在產品層面，如上圖右邊所示，做了一些限定去保證指標完全按照我們的設計規范進行設計。

我們希望形成圖中的邏輯閉環，首先在設計規范上達成共識，使得指標是可描述、可理解、可查詢、可管理，并且可使用的，最后要達到可驗證，通過驗證來優化指標定義規范，從而形成一個邏輯閉環。我們單獨對于指標的可查詢、可管理、可理解這一塊做了一個指標地圖，目的就是對于指標的一些必要信息能夠快速定位和快速查詢，能夠快速消除理解上的歧義，降低指標的使用門檻。

3、實施步驟2 - 規范模型設計體系建設

第二個實施步驟是規范模型設計體系建設。為了打破原有數據開發的一些不好的工作習慣，我們設計了一整套嚴格的模型設計流程：

（1）設計DWD事實模型，要關聯業務過程和度量設計。

（2）設計DWS底層模型，要實現標識自動生成，關聯原子指標、維度，以及模型物理化。

（3）設計DWS匯總模型，因為DWS底層模型是關聯原子指標的，而DWS匯總層模型是關聯派生指標的，派生指標本身就有嚴格的量化定義，所以DWS匯總模型的指標依賴包括模型的依賴關系是可以自動發現并自動關聯的。借助產品的能力，可以做到所有指標、維度等信息都是可以溯源的，從而達到模型設計規范化建設的目的。

（4）設計DM集市層模型，我們將這一層定位為僅取數，不做任何數據計算匯總、轉換的工作，也就是達到one data的效果。我們的模型指標只會在一個地方進行設計和計算，其它地方都是從這個地方取數就行了。

對于模型設計規范，舉幾個例子來說明。首先，我們做了模型命名規范的分層，前后綴當中要體現分層和業務過程，后綴代表模型數據的更新方式。

模型分層職責劃分為，DWD事實層只做清洗、轉換、歸一化等工作；DWS明細層做一些細粒度計算，包括一些復雜的計算，比如有的訂單數據里面需要對每一件商品的銷售額計算用戶支付的金額，要把這一單商品的運費均攤到每一件商品當中，那么就要在明細層中實現運費均攤計算；DWS匯總層就是基于明細層做派生計算；DM集市層僅僅是面向應用，只取數不計算。

最后，模型內容限定，就是不同層對應不同類型的指標，且只包含維度、匯總粒度、時間周期等這些信息。

上圖是我們產品設計的一個demo。可以看到，匯總信息是基于派生指標得到的，所依賴的原子指標都可以自動發現，并且定位到上游的模型以及計算的邏輯。基于規范的指標依賴和規范的模型定義，就可以實現對模型構建和指標計算的規范化。

4、實施步驟3 - 規范指標計算和模型構建

第三個步驟是規范指標計算和模型構建。原來我們存在一些不規范的模型開發習慣，首先，我們的模型設計和開發幾乎是獨立的，導致人工編碼工作量大，還有可能前后不一致，存在實際的業務邏輯與定義不符。另外為了快速交付，存在一些煙囪式開發、指標重復計算和跨層依賴的情況。

在規范后的模型開發流程中，我們對DWD層和DWS底層模型還是按照平臺設計+人工開發的方式。但對DWS匯總層進行了自動構建能力的建設，平臺基于指標定義和模型設計，完全能自動發現依賴并按指標匯總邏輯生成計算代碼，自動完成任務的開發、調度和運維。最后DM層相對簡單，且定位清晰：只取數不計算，平臺也做了自動構建能力的建設，并支持自動生成和綁定標準數據服務。

從DWD層模型到DM層模型構建的職責劃分如上圖所示。前兩層雖然是人工開發的，但為了盡可能規范整個數倉體系的建設，模型的設計必須在平臺上完成，并且平臺能夠對這兩層模型進行持續規范化掃描和監控，防范指標模型體系的快速腐化。

后面兩層則完全由平臺進行設計，基于指標之間的關聯派生關系，黑盒形式實現數據的計算可以從源頭保障指標口徑統一、數據質量穩定。減少開發工作量、降低變更的復雜性，達到指標可定位、可管理、可追溯，并且可控制。整個數倉體系的指標實現“定義即實現，所見即所得”是本平臺建設的最終目標。

我們還實現了一個指標匯總代碼生成引擎，支持并抽象了嚴選離線數倉幾乎所有常用的指標計算場景。主要包括9步：首先是找到派生指標依賴的原子指標，綁定底層模型，根據派生詞拼接匯總時的過濾條件，然后根據指標匯總方法拼接聚合函數，根據維度關聯相應維度表，再從維度表中獲取維度屬性，接著是根據取數范圍拼接取數的時間周期條件，根據模型粒度拼接分組條件，最后根據回刷周期拼接目標分區。

這是我們系統自動生成的匯總代碼的一個demo，里面每一部分都能體現出前面描述的流程。

模型的發布、更新和運維是指標數據真正落地的過程，通過對接嚴選大數據體系的其它相關產品如離線開發平臺、實時開發平臺、數據質量平臺等實現。

上圖是產品設計的一個demo，對模型的發布、更新和運維完全實現了黑盒化。這樣做的好處一方面是大大降低了數據開發人工操作的工作量，他們只需要在平臺上直接點發布，就可以完成一整套流程；另一方面也可以避免數據質量以及時效性、產出效率等方面的問題。

網易嚴選已有一個相對比較完整和成熟的數據服務平臺，所以我們就直接對接即可實現數據的對外服務。我們通過規范化的指標和模型的定義，生成標準的數據服務的查詢代碼，形成了代碼的模板化構建，減少了人工干預，為下游數據使用規范化進行了約束。

四、成果和總結

1、取得效果

最后做一個成果總結，現在我們這個平臺在模型指標的定義和設計規范化，以及模型的自動化構建這兩塊已經全面落地。一方面是增量的指標模型，已經實現完全的規范化，對于存量的指標模型正在逐步進行切換。另一方面由于DWS匯總層以及DM層的自動化構建能力的交付，使得模型的開發效率、業務需求的交付效率都有了大幅提升。

2、業務價值

我們的產品最重要的價值是解決了指標口徑不一致的核心問題，對于數據的設計、生產、使用、維護治理都形成統一的視角，達到了降本增效的目的。

在整個實施過程中，比較重要的一點就是我們一直在探索規范性和靈活性之間的平衡點，有些規范定的太死可能會導致需求不能滿足，即數倉建模一些現有的場景可能無法滿足；但是太靈活又可能會導致逐漸腐化的后果。所以其間的平衡是很重要的一項工作。