網易雲音樂數倉建模實踐 - 聲波 APP

數倉是商業智能的基礎，它爲 OLAP、數據挖掘提供分析和決策支持。本文以在聲波業務中的實踐經歷，總結了如何開始構建一個數倉模型、如何配置數據任務流調度、以及如何在自助取數上抽象模型配置 cube！

聲波 app 是網易雲音樂推出的一款主打語音交友的陌生人社交軟件，能夠進行語音連麥、1V1 聊天、娛樂交友等互動的平臺。

1

聲波基礎數倉模型

1. 初期設計

早期的聲波數倉模型

早期的聲波數倉模型梳理了主要的業務域以及核心業務過程，構建的總線矩陣如上圖所示，當然現在看來是有很多不夠完善的地方。

2. 思考

因此，當有機會接手一個新 APP 時，該如何構建一個完整的數據倉庫模型？這裏總結了相關經驗以及踩過的坑，建議按照以下步驟進行：

step1：數據調研

數據調研步驟非常重要，主要目的是確定需求及需求分析。可以通過調查或訪談等形式來了解，主要分爲兩部分。

（1）諮詢不同需求方對數據倉庫的需求

不同分工人員（分析師、策劃、運營、財務等各個部門）對數據倉庫的需求不同，前期需要諮詢他們的初期、中期、長期的目標，瞭解了目標，才能夠建設有利的數據倉庫。以下是聲波業務的需求歸納：

• 分析師的初期的期望是能夠產出自上而下的，可直接監控業務大盤的數據，中長期是對新的產品功能做監控，幫助業務實現營收 KPI；

• 策劃在初期的期望是能夠對用戶在註冊登錄環節的流失做些分析，中期是不斷擴展拉新用戶方式，並對用戶做渠道歸因，同時增加新的產品功能體驗，提升用戶留存，長期目標是引導用戶付費，實現年終營收 KPI，需要分析相關數據；

• 運營的目標是爲產品提供運營抓手，組織月度活動，以及對廳主做培訓，引導用戶付費，其中需要分析活動效果及廳主培訓成果；

• 財務的需求是按月要求輸出各類型用戶的消費、收益、充值、毛利率預估、波幣的 movement 等監控數據。

（2）整體的業務數據框架

這裏按照 AARRR 模型整理了聲波業務的整體框架，如下表所示：

step2：主題域

主題域一般可以按照企業的部門劃分，也可以按照業務過程或者業務板塊中的功能模塊進行劃分，這裏遵循雲音樂主端的規範，將一級主題域劃分爲參與者、服務及產品，版權及協議、公共、事實這 5 個大的主題域，二級細節分類在下文中詳述。

step3：定義維度與構建總線矩陣

維度建模中我們選用了 Kimball 維度建模方法，在定義好主題域之後，需要對具體對業務過程做分類。

下面是對聲波重新構建了總線矩陣，結構大致如表所示：

其中打勾的是指在對應的業務過程功能與一致性維度下有關聯性，由此來構建事實表與維度表。

step4：明確指標統計

統計指標一般是來源於分析師梳理的監控報表。其中指標 = 時間週期 + 統計粒度 + 業務過程的度量（描述）。請注意，口徑一般包含業務口徑和技術口徑。一般業務口徑分析師經與策劃等溝通後會給到一個明確統一的口徑，技術口徑可能需要我們回填給業務。

聲波的常用統計指標一般包括（時間週期）近 1/3/7/15/30 日的（統計粒度）用戶的（業務過程）進房次數、進房時長、消費金額、是否留存等等。

step5：結果驗證

構建數據倉庫，主要是爲我們及下游使用方分析數據，以賦能產品，所以數據的準確性至關重要，可以先通過網易有數大數據平臺提供的數據測試中心的測試功能進行測試、找前輩們 review 代碼或者通過與已有報表中相同指標進行覈對，然後再交由分析師配置報表。

至此，我們將數據做了一個以業務過程爲分類的縱向劃分，下面要開始對數據做橫向的分層。

2

聲波任務流建設

2.1 現有設計

聲波數據任務流的地址爲：XXXX。主要分爲 source_sync、slive_model、reports、transmit 四個目錄。下圖中詳細描述了各文件存放的數據內容：

2.2 思考

如何進行數據分層？

常規的數據倉庫模型分層一般包括 ODS 貼源數據層，DIM 維度層，DWD 明細數據層，DWS 輕 (中 / 重) 度彙總層以及 ADS 應用數據層。在分層中我們需要思考以下問題：

業務數據是根據什麼（維度、粒度）彙總的，衡量標準是什麼？

eg: 聲波劃分的粒度包括：用戶粒度、房間粒度、用戶 + 房間粒度、動態粒度、用戶 + 動態粒度，衡量標準主要是各粒度下的各種指標：次數、時長、金額等等。

DIM 該如何設計？DWD 和 DWS 應該如何設計？是否有公共的指標？

eg:DIM 是觀察業務的角度，建議可以設計主維表（一般爲直接從業務庫中同步來的、包含常用的屬性、穩定性高）和多個次維表（常變更），因爲維表一般有嚴格的時間要求與依賴任務，同時對與需要經常修改的任務做回跑有利，例如我們爲聲波用戶設計了基礎的 dim_slive_user_base_d 主維表和指標豐富的 dim_slive_user_d 次維表。

DWD 一般是基於具體業務過程，構建最細粒度的明細層事實表，也可以將明細事實表的某些重要維度屬性字段做退化設計，這裏也可以添加一些常用統計口徑的雜項維度。例如消費明細表中並不是每一筆消費都是計入 KPI 的，可以添加一些 is_real_consume（是否實際消費）、is_consume_water（是否消費流水）、is_operation（是否運營操作），這樣便於下游的統計。

DWS 以分析的主題對象作爲建模驅動，將相對應的事實進行聚合統計，形成一些輕度聚合、中度聚合或者重度聚合的寬表。

任務調度設置

任務流建設是對整個業務過程的橫向分層，下表是聲波業務的任務分層，也是契合於上述的數據分層。

優缺點：

• 優點：相對於單表單任務流來講，任務流依賴配置簡單，同時易讀性高；對於有依賴的任務可一次性提交回跑任務；核心任務能夠及時產出。

• 缺點：相對於單表單單任務流來講，定位某表屬於那個任務流相對較慢；某些核心任務報表產出相對延遲些。

注意：

• 當調度任務失敗時，要在實例詳情頁面進行重跑；

• 一般依賴任務的開始調度時間要晚於被調度的任務；

• ads 層表從 dim/dwd/dws 層來調用，不要直接走 ods 層。

3

聲波 OLAP 取數模型及流量自動化

3.1 現有設計

快速便捷獲取高質量數據是業務側的希冀，同時爲減少 ad-hoc 式的查詢也是我們的希冀。因此構建聲波 olap 模型，目標是幫助業務人員快速使用數據，獲取結果並用於業務生產。

取數模型設計：

目前模型建設流程：

1. 業務側 / 已有報表中歸納常用指標

2. 模型設計（常分析的業務過程（交易、互動）的明細、用戶、房間、用戶 + 房間的彙總表）

3. 模型評審

4. 配置模型（使用場景的說明、字段業務口徑、技術口徑、添加自定義維度、自定義度量）

5. 測試使用

流量自動化的解決方案：

1. 策劃梳理坑位信息 -〉與策劃勾兌坑位信息 -〉設計埋點 scm 信息 -〉上傳埋點到埋點平臺 -〉與開發勾兌埋點內容 --〉下載最終版坑位信息製作坑位碼錶。

2. 設計流量自動化的聚合表模型：uid+os+appver+mspm+source（+ 房間 id + 房間模版類型 id）的粒度統計對應的 (曝光、點擊、進房) 次數、人數和時長等信息。構建流量自動化模型，最終可由取數展示，該模型可以查看日常曝光點擊的坑位 PV、UV，同時可以查看核心（曝光 - 點擊 - 進房）漏斗數據。

3.2 思考

目前存在的難點，這些都是後期會優化的內容。

• 數據側：a. 模型設計 (聚合、解耦)   b. 模型迭代回跑

• 平臺側：a. 平臺開發進度無法滿足模型使用   b. 問題響應速度依賴其他部門

• 業務側：a. 對數據的維度、度量、聚合、日期分區的理解困難  b. 自主分析數據的習慣尚未建立

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