文章目錄

• 1 維度設計
• • 1.1 代理鍵(太復雜，不推薦)
  • 1.2 穩定維度
  • 1.3 緩慢漸變維 => 拉鏈表
  • 1.4 維度表的拆分、合并
• 2 事實表設計
• • 2.1 明細事實表(dwd)
  • • 2.1.2 案例：
    • 2.1.3 存儲方案
    • 2.1.4 事實拉鏈表示例：
  • 2.2 聚合事實表(dws)
  • • 2.2.1 分類
    • 2.2.2 案例
• 3 數據集市
• 4 業務數據案例
• • 4.1 數據采集
  • 4.2 數倉設計
• 5 流量數據相關場景
• • 5.1 區分流量來源
  • 5.2 頁面訪問軌跡
  • 5.3 跳出率 斷點處
  • 5.4 設備信息用途
• 6 數據應用

星座模型只是星型模型的維度公用，類似這種

實際開發中，針對某一主題可以有明確的星型模型，星座模型啥的。但是眾多主題間也存在維度公用的情況，這樣交織在一起形成一張大網，很難說是啥模型吧。

1 維度設計

1.1 代理鍵(太復雜，不推薦)

維度表主鍵，關聯事實表

解決辦法：自創一個自增的id，取代source+id這種判斷方法

所以有了代理鍵這個東西：

實現方法：前一天gid的max+新增數據的行號，就是增量的gid了。

1.2 穩定維度

1.3 緩慢漸變維 => 拉鏈表

這樣這個id就不唯一了，跟事實表關聯的話就要再弄一個代理鍵才行

這樣按部門統計有兩個，按客戶統計有一個就解決問題了，沒有代理鍵的話，就亂了。

mysql的業務數據=>事實表的時候，就要把代理鍵給弄進去

具體操作方法：
不管全量增量，先把今天發生的事情選出來，再去關聯。
第一種是給普通數據庫用的，hive不能用非等值連接，就只能先join再where了

但是這樣很麻煩，一般用的不多，有時候可以用全量快照。

1.4 維度表的拆分、合并

橫向拆分：銷售員工、技術員工等
縱向拆分：不同員工關注不同的字段

弄一張大寬表，沒有對應的屬性字段就空著，誰要啥信息就從里面弄一張子表用，
沒啥特殊情況就用這個就行，空間換時間。

也可以弄一個基礎信息表，不同的表在這個基礎上加上自己想要的相關屬性字段

2 事實表設計

2.1 明細事實表(dwd)

降維就是把外面關聯的維度信息弄進事實表，統計的時候減少關聯操作用的

有時候事實表里面沒有度量，比如這個審核表

多個動作的事實表啥設計？
多事實表
單事實表，不斷更新

2.1.2 案例：

方案一：每個動作都做表。分析起來很靈活，但是業務側自己可能也不會做的這么細，有需求只能采集他們的日志啥的。

第二種就是一個訂單完整流程一張表整合到一張寬表上

總結：第二種常用，好維護，第一種在某些特殊分析場景下可以搞定，而第二種不行。

2.1.3 存儲方案

沒狀態變化的就增量存儲
有變化的可以每天快照，如果嫌站空間可以只保存近一年的數據，再之前的保存每月底分區就行了。
如果變化的數據占比小，可以考慮拉鏈表，變化多了還是快照比較好。

2.1.4 事實拉鏈表示例：

舊數據結束日期改掉，新數據插進去

如果是快照表，要做拉鏈的話：用MD5判斷是否新增變化數據

2.2 聚合事實表(dws)

2.2.1 分類

按照是否可累加：
不可累加事實(xx率，去重客戶數)就拆開存，比如xx率就分子分母一起存

按照統計周期：

2.2.2 案例

2.1 案例的dws設計：
通用匯總層：
按照不同粒度的每日匯總，以及歷史匯總
對于歷史匯總數據，不用每天都去算全量數據，可以只計算當天新增數據，再與前一天的歷史匯總數據關聯，就能出來整個的歷史匯總了。

周期匯總層：
日粒度的交易日報，以及周粒度的用戶匯總
這個周粒度的匯總有些結果可以直接從每日匯總用戶表累加得到，盡量減少計算工作量。

3 數據集市

基于大數據的架構下的數倉，集市概念很弱，相當于一個應用層，梳理基于各個主題的匯總數據。
不像傳統行業，比如銀行，集市就是從各個源系統拉明細數據，自己用啥就加工啥，有點像自己在做一個小數倉一樣。

4 業務數據案例

1 梳理業務流程
2 梳理數據流轉
認證項里面有好多：身份證號、借記卡、授權通訊公司密碼可以調取通話記錄 等等

題外話：還有可能是芝麻信用，其他收費三方接口
有的像這種并行的效率就高一些，可能幾秒就有額度；想節約成本可能判定黑名單了，就不會去花錢調接口繼續查了，串行的多的可能要幾個小時才有額度。

3 數據類型、存儲介質、最好有樣例數據
4 需求：功能性的、非功能性的需求(性能、時效性)

4.1 數據采集

線上數據 (ER模型)

關注下表的數據量、每日增量、是否有唯一自增主鍵、createtime和updatetime這些。
sqoop導入的時候會指定 --split-by xx字段
如果主鍵id不均勻，就數據傾斜了，這時候可以考慮用updatetime來split

采集方案：
根據數據量、是否狀態變化

全量采集 user_info

增量采集訂單表，先把變化的數據弄進臨時庫stage，避免數據傾斜用updated_time切分map

4.2 數倉設計

先把公用的維度表定了
然后做事實表，根據可能的分析角度來進行信息整合，維度退化，雖然有些事實表信息冗余，但是分析簡單。
像額度管理表就可以做成拉鏈表
dwd：

dws：
如果dws表太寬了不方便，可以根據業務、常用與否、計算范圍來拆個輔助模型出來。
比如這張訂單表，盡可能覆蓋全面，把還款情況聚合過來

5 流量數據相關場景

5.1 區分流量來源

內部標簽有他自己的標簽id，外面進來的就看url參數

5.2 頁面訪問軌跡

區分會話方法：
=>只有uid和時間戳的就用超時時間來判斷
=>有reffer可以用reffer為空來判斷，也可以加上超時時間條件
=>有sessionid reffer 那就好弄了

5.3 跳出率 斷點處

跳出前最后一次的頁面

5.4 設備信息用途

6 數據應用

BI(報表)，運營效果評估 算是最快最容易變現的數據應用了
但是AB客群的劃分，也可以通過標簽系統來搞定，這也算個應用吧。
整體的，標簽系統->劃分客群->點擊轉化分析 這個大系統。比如之前見到的golfer平臺。這個對營銷、運營幫助還挺大的。

總結

以上是生活随笔為你收集整理的维度建模详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。