維度設計雪花模型
星型模型
星座: 多個事實表
問題:
1、資料倉儲,不針對某乙個分析主題,而是有多個分析主題,即多個事實表,維度表怎麼設計?
2、即使是同乙個分析主題,也可能存在多個事實表,維度表如何設計?多個時間維度?
無論星型模型、雪花模型還是星座模型,都是針對維度上的區別而來,星座模型實質上還是星型模型,
只是共用了維度。
s1.goods**鍵:
維度表中唯一有乙個能夠唯一標識一行記錄的列,通過該列維護維度表和事實表的關係,一般在
維度表中業務主鍵符合條件可以當作維度主鍵。
是由資料倉儲處理過程中產生的、與業務本身無關的、唯一標示維度表中一條記錄並充當維度表
主鍵的列,也是描述事實表和維度表關係的紐帶,所以在設計有**鍵的維度表中,事實表中的
關聯鍵是**鍵而不是原有的業務主鍵,即業務關係是靠**鍵維護,這樣有效避免源系統變化
對數倉資料的影響。
在實際業務中,**鍵通常是數值型,自增的值。
問題: 傳統資料庫有自增id預設功能,但hive怎麼生成自增的**鍵?
row_number() over (partition by .. order by ..) as rn
問題:
1、當整合多個資料來源的維度時,不同資料來源的業務主鍵重複怎麼辦?
2、涉及維度拉鍊表時,同一主題對調記錄,業務鍵重複怎麼辦?
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、拉鍊表: 當維度資料發生變化時,將舊資料置為失效,將更改後的資料當作新的記錄插入到維度表中,並開始生效,
這樣能夠記錄資料在某種粒度上的變化歷史。
因為是對維度表做拉鍊,所以對同乙個維度實體必然存在多條記錄,此時維度表的原子性主鍵就不存在了。
id
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
案例: 對上述的事實表,裝載使用者維度**鍵(uid)問題: 事實表**與業務事務表,**鍵和業務本身沒有關係,那麼怎麼在事實表中裝載**鍵?
事務表中歷史的使用者維度id不會發生變化,所以事實表的**鍵載入僅發生在新增資料上
**鍵優缺點分析: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過程更加複雜。
故,在大資料體系下,謹慎使用**鍵,同時對於緩慢變化維場景,可以考慮空間換取時間,每天保留
維度全量快照;但這樣會帶來儲存成本,根據實際情況衡量。
資料倉儲維度建模概述
面向主題的。操作型資料庫的資料組織面向事物處理任務,各個業務系統之間各自分離,而資料倉儲中的資料是按照一定的主題域進行組織的。例如 當事人 協議 機構 財務 事件 產品等主題。整合的。資料倉儲中的資料是從多個不同的資料來源傳送來的。多個應用之間在編碼,命名習慣,物理屬性 不同的資料庫 欄位的資料型別...
資料倉儲維度建模步驟
在商業智慧型專案的實施過程中,維度建模技術和企業資料倉儲建模是兩種不同的方 以下是以應用驅動 提供快速原型的商業智慧型專案的實施和規劃過程中使用的維度建模方法時的標準實施過程。具體到專案中則根據專案的規模及所涉及的業務範圍而有所補充或裁減。1.商業智慧型專案規劃 a 資料倉儲專案的定義及範圍 b 專...
資料倉儲之維度建模
1.資料倉儲建模目標 資料倉儲建模的目標是通過建模的方法更好的組織 儲存資料,以便在效能 成本 效率和資料質量之間找到最佳平衡點。訪問效能 能夠快速查詢所需的資料,減少資料 i o 資料成本 減少不必要的資料冗餘,實現計算結果資料復用,降低大資料系統中的資料 成本和計算成本 使用效率 改善使用者應用...