網易雲音樂數倉維度建模實踐：模型設計篇

數倉模型架構搭建、模型設計是整個數倉建設的核心部分。數倉建模的價值體現在：數據質量、健壯水平、資源消耗、服務響應速度。

寫在前面：我們爲什麼要建模

這裏想先說下，這些年我在數倉摸爬滾打的一些經歷：

剛畢業那會兒，我覺得數倉簡單啊，不就是用 sql 開發一張張表嘛，誰不會呀，那段時間覺得好沒挑戰呀，沒事的時候搗鼓下高大上的 spark、scala 啥的。

後來開始接觸模型，我的認知開始發生變化，原來每一個表都是一個個精心設計的模型，我以爲數倉就是一個個模型。

再後來，接觸越來越複雜的業務，我發現，設計模型也不是一個簡單的事情。我以爲我設計地很完美，但，業務不斷髮展後：

• 一個需求一個模型，要膨脹了......

• 原來的模型跑的時間越來越長了？

• 有些 kpi 指標要早點出來，但是受模型裏個別指標硬生生的拖慢了速度？

• 發現一個 bug，想快速補數據，發現只能串行一天天的跑？

• 怎麼好多模型的指標有重複咧？

• 這個指標長的一樣，咋定義不一樣呢？

• 怎麼同樣口徑的指標，從不同的表計算，數值不一樣呢？

• 這咋每天都在延遲報警誒？每天都要運維，心塞塞~~

• 業務要這個數據，哪個表計算的來着？

• 常用指標和殭屍指標都在一個模型躺着，刪怕影響業務，用戶難受，不刪我難受，浪費資源 ......

淌過這些坑後，如醍醐灌頂，這其實就是一個系統嘛。它不是一張表，也不是一個模型，而是一個有着完整體系架構和規範，需要同時考慮功能性需求和非功能性需求的系統。功能需求很好理解，就是滿足業務需求，產出數據和指標。難點在於非功能性需求，比如：指標質量高不高、數據安不安全、數據產出快不快、模型是否穩定可擴展、數據服務穩不穩定、代碼是否健壯、是否浪費了計算資源和存儲資源......

總之，數據模型就是數據組織和存儲方法，它強調從業務、數據存取和使用角度合理存儲數據。它的價值體現在：數據質量、健壯水平、服務響應速度、資源消耗。轉化成對企業數倉的要求就是：強穩定、高質量、高效率、低成本。

一、搭建模型架構

這一環節，我給它取了個名字，叫 "定調"。這裏主要根據各自部門的業務形態和數據服務特點來確定整體數倉建設的基調。

 首先，明確數倉各層次的要做的事情，下面是雲音樂模型層次的框架圖：

• DWD：存放面向業務過程的明細事實數據，做一些數據清洗和規範化等。

• DWS：面向分析主題建模，這裏要說明的是，雲音樂 dws 層的基架是輕度彙總事實表，這裏做了一些常用的退化維，基本要求是：大部分指標都可以從輕度彙總層上計算得出。中度彙總層按需建設。重度彙總層基本上是單實體指標。

• DIM：所有實體的維度，雲音樂含有不同身份的用戶和多種類的內容實體，所以會有大量的維度模型

• ADS：數據集市層。基於 dws 和 dim 表，雲音樂建設了大量面向應用的數據集市。

確定橫向模型層的任務後，接下來要確定下縱向數據域下各業務線的建設模式。

根據經驗，數倉的建設難度與業務深度和複雜度是成正比的，dws 層的建設尤爲複雜。dws 層的設計要考慮三個方向：

1. 數據域的劃分特點 

2. 業務的複雜度，各業務線、業務過程之間的區別和聯繫，用戶在各業務線的特點和關係，業務數據體量，解耦因素等等。

3. 指標的特點，指標的構成無非是退化維 + 時間週期 + 原子指標構成，所以分析下指標的退化維一般有哪些、時間週期有哪些、原子指標種類有哪些。

基於以上三點，大致可以給整體數倉定個調，敲定數倉 dws，從而整個數倉架構基本上就可以確定下來了。比如，雲音樂最重要的用戶和內容業務線的設計大致如下架構：

主要思路是：

1. 各內容業務線各自獨立建設內容和用戶類指標，按照上面架構圖分數據域逐步建設

2. 輕度彙總表和中度彙總表都是用戶實體 + 內容實體 + 退化維模式。輕度彙總表基本涵蓋大部分需求場景

3. 重度彙總表要麼是單實體，要麼是用戶 + 內容雙實體組成，且不包含退化維

4. 重度彙總表分爲增量表和全量表，增量包含近 1/3/7/30 天時間週期的指標，全量表計算歷史累計指標。這麼做的目的是在計算人數類指標和計算資源之間做了平衡。

5. 每個內容業務線最後都有自己內容大寬表和維表

6. 用戶指標拆分到具體的內容業務線上，各自獨立建設用戶業務寬表，做到充分解耦，以滿足各自場景需求

7. 用戶維表採用先分後總模型：先建設不受業務數據干擾的公用基礎維表 + 各業務線用戶維表，強解耦，保持獨立，再建設全域用戶維表

二、建模流程

定下數倉的基調，即模型架構後。接下來就要開始進行具體單個模型的設計了。具體建模流程按照下面流程進行：

 三、模型設計方法論

有了模型體系架構和建模流程，我們要實打實地設計一個個模型。我們知道表的分類主要是事實表和維表。事實表是維度建模的核心，維度是維度建模的基礎和靈魂。設計模型其實就是在設計事實表和維度表。簡單介紹下模型設計的基本原則和設計方法。

1. 模型設計基本原則有：

1.1 高內聚低耦合（最重要，非功能性需求決定架構）

• 產出時間

• 粒度

• 業務相關性

• 訪問頻率

• 運行方式：並行、串行

• 資源消耗情況

1.2 核心模型與擴展模型分離

• 核心模型：支持常用的核心業務

• 擴展模型：支持個性化或少量應用需要

• 比如：mlog 的分享引入，只有在做增長時才需要，需要拆開成立專門的分享引入模型

1.3 公共處理邏輯下沉及單一

• 越是底層公用的處理邏輯越應該在數據調度依賴的底層進行封裝與實現，不要讓公用的處理邏輯暴露給應用層實現，不要讓公共邏輯多處同時存在。

1.4 成本與性能平衡

• 適當的數據冗餘可換取查詢和刷新性能，不宜過度冗餘與數據複製。

1.5 數據可回滾

• 處理邏輯不變，在不同時間多次運行數據結果確定不變。

1.6 一致性

• 具有相同含義的字段在不同表中的命名必須相同，必須使用規範定義中的名稱。

1.7 命名清晰、可理解

• 表命名需清晰、一致，表名需易於用戶理解和使用。

2. 事實表設計方法

2.1 選擇業務過程及確定事實表類型

事實表類型：

1）單事務事實表：單個業務過程

2）多事務事實表：多個業務過程放在一個事實表中

①原則：

• 業務過程是否有相似性？

• 是否來源同一業務源系統？

• 用戶使用的學習成本哪種更低？

• 計算和存儲成本是否會降低？

②方式

• 不同的業務過程使用不同的事實字段進行存放

• 不同業務過程的事實使用同一個事實字段進行存放，但增加一個業務過程標籤

2.2 聲明粒度（非常重要）

粒度傳遞的是與事實表度量有關的細節層次，精確定義事實表每一行所代表的業務含義

儘量選擇最細級別的原子粒度，以確保事實表的應用具有最大的靈活性。

2.3 確定維度：應該選擇能夠描述清楚業務過程所處的環境的維度信息。

2.4 確定事實：

• 應該選擇與業務過程有關的所有事實

• 事實的粒度要與所聲明的事實表的粒度一致

2.5 冗餘維度：

冗餘下游用戶方便使用的常用維度：常用的用於統計的維度屬性

冗餘原則

不冗餘查詢速度是不是很慢

存儲資源是不是夠

查詢頻率是不是很多

冗餘在哪一模型層的事實表中：明細層、輕度彙總層？

3. 維度設計的基本方法

• 選擇維度和新建維度

• 確定主維表

• 確定相關維表

• 確定維度屬性：從主維表和相關維表中抽取

• 儘可能生成豐富的維度屬性

• 儘可能多地給出包括一些富有意義的文字性描述，例如名稱等

• 區分數值型屬性和事實：看用途

• 儘量沉澱出通用的維度屬性

• 維度設計遵循的通用原則：反範式、扁平化

四、實例介紹

根據前面介紹的方法論，雲音樂社區 mlog 內容線的部分模型架構如下：

• 維表：一張 mlog 主維表

• mlog 互動行爲輕度彙總表：mlog 的互動行爲合併，因爲具有相同的環境信息

• 流量輕度彙總表：曝光點擊瀏覽合併，環境信息相似

• 歷史累計指標單獨：運行方式解耦

• 1d/3d/7d/28d 指標：合併，運行時間不影響，不解耦

五、總結

上述提到的模型分層、建模流程和建模方法論，在團隊內部形成了較爲穩定的規範，並在團隊內部得到大力推廣。好的規範離不開產品功能的加持，網易有數大數據平臺的模型設計中心基於網易內部多個團隊的數倉建設經驗，將數倉建模實踐經驗和方法論進行了產品化，爲雲音樂數倉團隊落地內部規範、完成數倉建模方面提供了極大的幫助。

雲音樂數倉團隊和網易有數產品也會更加緊密合作，把更多實踐經驗和建設指導，輸出給模型設計中心，讓模型設計中心幫助更多數據團隊完成自身數據中臺的搭建。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/Cr8xf88j9oikzSEvGBTLMw