文章目錄

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

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

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

1 維度設(shè)計

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

維度表主鍵，關(guān)聯(lián)事實表

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

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

實現(xiàn)方法：前一天gid的max+新增數(shù)據(jù)的行號，就是增量的gid了。

1.2 穩(wěn)定維度

1.3 緩慢漸變維 => 拉鏈表

這樣這個id就不唯一了，跟事實表關(guān)聯(lián)的話就要再弄一個代理鍵才行

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

mysql的業(yè)務(wù)數(shù)據(jù)=>事實表的時候，就要把代理鍵給弄進去

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

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

1.4 維度表的拆分、合并

橫向拆分：銷售員工、技術(shù)員工等
縱向拆分：不同員工關(guān)注不同的字段

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

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

2 事實表設(shè)計

2.1 明細(xì)事實表(dwd)

降維就是把外面關(guān)聯(lián)的維度信息弄進事實表，統(tǒng)計的時候減少關(guān)聯(lián)操作用的

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

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

2.1.2 案例：

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

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

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

2.1.3 存儲方案

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

2.1.4 事實拉鏈表示例：

舊數(shù)據(jù)結(jié)束日期改掉，新數(shù)據(jù)插進去

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

2.2 聚合事實表(dws)

2.2.1 分類

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

按照統(tǒng)計周期：

2.2.2 案例

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

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

3 數(shù)據(jù)集市

基于大數(shù)據(jù)的架構(gòu)下的數(shù)倉，集市概念很弱，相當(dāng)于一個應(yīng)用層，梳理基于各個主題的匯總數(shù)據(jù)。
不像傳統(tǒng)行業(yè)，比如銀行，集市就是從各個源系統(tǒng)拉明細(xì)數(shù)據(jù)，自己用啥就加工啥，有點像自己在做一個小數(shù)倉一樣。

4 業(yè)務(wù)數(shù)據(jù)案例

1 梳理業(yè)務(wù)流程
2 梳理數(shù)據(jù)流轉(zhuǎn)
認(rèn)證項里面有好多：身份證號、借記卡、授權(quán)通訊公司密碼可以調(diào)取通話記錄 等等

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

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

4.1 數(shù)據(jù)采集

線上數(shù)據(jù) (ER模型)

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

采集方案：
根據(jù)數(shù)據(jù)量、是否狀態(tài)變化

全量采集 user_info

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

4.2 數(shù)倉設(shè)計

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

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

5 流量數(shù)據(jù)相關(guān)場景

5.1 區(qū)分流量來源

內(nèi)部標(biāo)簽有他自己的標(biāo)簽id，外面進來的就看url參數(shù)

5.2 頁面訪問軌跡

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

5.3 跳出率 斷點處

跳出前最后一次的頁面

5.4 設(shè)備信息用途

6 數(shù)據(jù)應(yīng)用

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

總結(jié)

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

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