資料倉儲維度建模

雪花模型星型模型星座: 多個事實表問題: 1、資料倉儲，不針對某乙個分析主題，而是有多個分析主題，即多個事實表，維度表怎麼設計？ 2、即使是同乙個分析主題，也可能存在多個事實表，維度表如何設計？多個時間維度？無論星型模型、雪花模型還是星座模型，都是針對維度上的區別而來，星座模型實質上還是星型模型，

只是共用了維度。

維度設計

**鍵: 維度表中唯一有乙個能夠唯一標識一行記錄的列，通過該列維護維度表和事實表的關係，一般在維度表中業務主鍵符合條件可以當作維度主鍵。是由資料倉儲處理過程中產生的、與業務本身無關的、唯一標示維度表中一條記錄並充當維度表主鍵的列，也是描述事實表和維度表關係的紐帶，所以在設計有**鍵的維度表中，事實表中的關聯鍵是**鍵而不是原有的業務主鍵，即業務關係是靠**鍵維護，這樣有效避免源系統變化對數倉資料的影響。在實際業務中，**鍵通常是數值型，自增的值。問題: 傳統資料庫有自增id預設功能，但hive怎麼生成自增的**鍵？ row_number() over (partition by .. order by ..) as rn 問題: 1、當整合多個資料來源的維度時，不同資料來源的業務主鍵重複怎麼辦？

2、涉及維度拉鍊表時，同一主題對調記錄，業務鍵重複怎麼辦？

s1.goods

idname

note1da

finc

2jiang

fins2.goods

idname

note

1daanhg

fikknc

2uuug

fijjn

兩個系統整合，主鍵一致，已經不能使用id作為**鍵

這種情況下，可以自己維護乙個**鍵

gidid

name

note

source11

dafincs12

2jiang

fins131

daanhg

fikkncs24

2uuug

fijjn

s2穩定維度

部分維度表的維度是在維度表產生後，屬性是穩定的，無變化的；比如時間維度、區域維度等，針對這種維度，設計維度表的時候，僅需要完整的資料，不需要天的快照資料，因為當前資料狀態即是歷史

資料狀態。

緩慢漸變維度

維度資料會隨著時間發生變化，變化速度比較緩慢，這種維度資料通常稱作緩慢變化維；由於資料倉儲需要追溯歷史變化，尤其是一些重要的資料，所以歷史狀態也需要採取一定的措施進行儲存。緩慢變化維解決辦法: 1、每天儲存當前資料的全量快照資料，該方案適合資料量較小的維度，使用簡單的方式儲存歷史狀態。(目前用的比較多的) 2、在維度表中新增關鍵屬性值的歷史字段，僅保留上乙個的狀態值。(應用場景不是特別多) 3、拉鍊表: 當維度資料發生變化時，將舊資料置為失效，將更改後的資料當作新的記錄插入到維度表中，並開始生效，

這樣能夠記錄資料在某種粒度上的變化歷史。

拉鍊表

因為是對維度表做拉鍊，所以對同乙個維度實體必然存在多條記錄，此時維度表的原子性主鍵就不存在了。

name

dept

start_date

end_date

1zyh

bigdata

20190202

20190208

1zyh

phoenix

20190209

99991231

問題: 拉鍊表怎麼和事實表關聯？

答案: 新增**鍵

fact_order(訂單)

oiduid

tm_id11

92210

dim_user(使用者維度)

uidid

name

dept

start_date

end_date11

zyhbigdata

20190202

2019020821

zyhphoenix

20190209

99991231

問題: 事實表**與業務事務表，**鍵和業務本身沒有關係，那麼怎麼在事實表中裝載**鍵？

事務表中歷史的使用者維度id不會發生變化，所以事實表的**鍵載入僅發生在新增資料上

案例: 對上述的事實表，裝載使用者維度**鍵(uid)

fact_order(事實表)   oid, uid, tm_id...
dim_user(維度表) uid, id, name, dept, start_date, end_date 
order(mysql業務表) oid, id, create_time, update_time
採集--query 'select ... from ... where create_time>20190202' -->> order_inc
裝載事實表(hive的join不支援非等值連線)
select 
ta.*,tb.uid 
from
order_inc as ta 
join 
dim_user as tb on ta.id=tb.id 
and ta.create_time>=tb.start_date and ta.create_time<=tb.end_time;
hive這樣寫:
select * from 
(select 
ta.*,tb.uid 
from
order_inc as ta 
join 
dim_user as tb on ta.id=tb.id) tmp 
where create_time>=start_date and create_time<=end_time;

**鍵優缺點分析:

**鍵是維度建模中極力推薦的方式，它的應用能有效的隔離源端變化帶來的數倉解雇不穩定問題，同時也能夠提高資料檢索效能。但是如所見，**鍵維護成本非常高，尤其是資料裝載過程中，對事實表帶來了較大的影響，在基於 hive的資料倉儲建設影響更加嚴重，比如**鍵的生成、事實表中關聯鍵的裝載、不支援非等值關聯等問題，帶來etl過程更加複雜。故，在大資料體系下，謹慎使用**鍵，同時對於緩慢變化維場景，可以考慮空間換取時間，每天保留

維度全量快照；但這樣會帶來儲存成本，根據實際情況衡量。

資料倉儲維度建模

資料倉儲維度建模概述

資料倉儲維度建模步驟

資料倉儲之維度建模

資料倉儲維度建模

資料倉儲維度建模概述

資料倉儲維度建模步驟

資料倉儲之維度建模

相關推薦