ODS：數據 來源 ： 一部分是來自關系型數據庫，符合ER模型 。一部分來自日志 ，清洗成二維表
DWD： 把所有的數據清理整合 ，規范化 。臟數據清理 ，命名不規范的。最后拿到的是干凈的 ，一致性的數據 。
把公共維度抽取出來，如區域
DWS： 維度建模，通用的匯總層 ，為了避免重復計算。 DWS的表底層可能依賴DWD或ODS層的幾十張表。所以從ETL性能出發要考慮DWS層表的數量和依賴 。
DM：指標庫 ，集市是面向分析的
清洗過程： ODS清洗臟數據到DWD, DWD匯總到DWS，DWD到DM做指標。
維度 ：
維度，顧名思義，看待事物的角度。比如時間日期 、區域、部門 、客戶、應用程序等 維度 ，而省、市、縣又叫維度的粒度，粒度可以是一組組合：比如我要看某個省某個市下某個縣年齡在28歲以下的購買能力。
維度表一般為單一主鍵，在ER模型中，實體為客觀存在的事物，會帶有自己的
描述性屬性，屬性一般為文本性、描述性的，這些描述被稱為維度
比如商品，單一主鍵：商品ID，屬性包括產地、顏色、材質、尺寸、單價等，
但並非屬性一定是文本，比如單價、尺寸，均為數值型描述性的，日常主要的維
度抽象包括：時間維度表、地理區域維度表等
維度設計：
代理鍵
緩慢漸變維
事實表設計：
明細事實表
聚合事實表
代理鍵：
維度表中必須有一個能夠唯一標識一行記錄的列，通過該列維護維度表與事實表之間的關系，一般維度表中業務主鍵符合條件可以當作維度主鍵。
當整合多個數據源的維度時，不同數據源的業務主鍵重復怎么辦？
比如下圖：
原有業務主鍵id,整合后發生重復。此時引入一個新的和業務無關的鍵（代理建），並且在整個維度表中是全局唯一的，而且通常情況下自增的方式來做的
傳統數據庫有自增id默認功能，但hive中怎么生成自增的代理鍵？
表命名規則:
-i結尾: 流水型的純增量的
-d結尾: 快照的
-a結尾: 全量沒有任何分區
維度有分為:
1/ 穩定維度:
如時間,區域等,不發生變化或很少發生變化.針對這種維度,設計維度表時,僅需要完整的數據,不需要天的快照數據,因為當前數據狀態即是歷史數據狀態.
2/ 緩慢漸變緯度
維度數據會隨着時間發生變化,變化速度比較緩慢.由於數據倉庫需要追溯歷史變化,尤其是一些重要的數據,所以歷史狀態也需要采取一定的措施進行保存.
兩種方法:
a. 每天保存等錢數據的全量快照數據,適合數據量較小的維度,使用簡單.
b. 在維度表中添加官軍屬性值的歷史字段,僅保留上一個的狀態值. (復雜,不常用)
c. 拉鏈表
當維度數據發生變化時,將舊數據置為失效,將更改后的數據當作新的記錄,插入到維度表中,並開始生效,這樣就記錄了數據在某種粒度上的變化歷史.
比如: 員工的部門變化
因為是對維度表做拉鏈,所以同一維度實體必然存在多條記錄,此時維度表的原子性主鍵就不存在了.如上表中的兩條記錄id都是1
那么拉鏈表怎么和事實表關聯?
引入代理鍵:
問題：事實表來源於業務事務表，代理鍵和業務本身沒有關系，那么怎么在事實表中裝載代理鍵？
D:\數據倉庫\PART3\09 數據倉庫維度建模\數據倉庫維度建模2.mp4
小結:
代理鍵是維度建模中極力推薦的方式,它的應用能有效隔離源端變化帶來的數倉結構不穩定問題,同時也能提高數據檢索性能.
但,代理鍵維護代價非常高,尤其是數據裝載過程中,對事實表帶來較大的影響,如代理鍵的生成、事實表中關聯鍵的裝載、不支持非等值關聯等問題，帶來ETL過程更加復雜。
所以，謹慎使用代理鍵，同時對緩慢漸變維場景，可以考慮每天保留維表全量快照，但這樣會帶來存儲成本，根據實際情況衡量。
案例:
一個事實表，可以拆分成為多個不同的維度 ==》針對不同的維度進行分析。 這就叫多維分析
中間的是主表,右邊是財務關心的,左邊是技術部關心的
時間維度 用戶維度 金額維度 ==》 可以組合出來多少個不同的分析的角度？？？
不同的緯度表可以組合關聯分析。
kylin其實就是在做多維的分析 : 通過各種不同的維度都來做聚合的分析
事實表設計：
1/ 明細事實表，一般在dwd層
2/ 聚合事實表，一般在dws(輕度匯總)和DM
明細事實表：
事實表有粒度大小之分，一般在dwd層，該層事實表設計部進行聚合、匯總動作，只做數據規范化、數據降維動作，同時數據保持業務事務粒度，確保數據信息無丟失。
數據降緯：
為了提高模型易用性，將常規維度表中的常用的屬性數據冗余到相應的事實表中，從而在使用時避免維表關聯的方式，
如下圖,中間就是事實表，如果要做區域商品購買力分析，把常住地等也放到事實表中，這就是降維的過程。以后在使用事實表時就不用再和維度表再做關聯。
明細事實表設計:
案例:
出行,用戶下單打車,該訂單的整個流程包括用戶下單、司機接單、司機做單、乘客支付，可能還伴隨有評價、投訴等環節，這個場景的明細表怎么設計?
設計維度,要求業務側記錄這些事實:
采集成這么一張事實表:
事實表的存儲設計:
注意用拉鏈表要是緩慢變化，如果變化特別快，比如每天變一次，那12天就會產生12張拉鏈表，可能存儲量比全量快照還大。
案例: D:\數據倉庫\PART3\09 數據倉庫維度建模\數據倉庫維度建模7.mp4
信用卡場景，由於用戶的信用額度、已用額度存在緩慢的變化，又需要跟蹤變化的記錄，設計相關事實表。
源數據包括用戶id、卡id、已有額度、剩余額度、創建時間、更新時間
聚合事實表:
可累加事實：
在一定的粒度范圍內，可累加的事實度量，比如：訂單金額、訂單數等
不可累加事實：
在更高粒度上不可累加的事實，比如通過率、轉換率、下單用戶。
明細表的不用考慮粒度，它就是最小粒度.
實例:
按照出行訂單明細事實表，構建數據倉庫上層模型。
解:
到訂單粒度--->到用戶粒度（粒度粗一些）--->司機粒度
所以從下面表中可以看到：
比如訂單表有2000萬個訂單，可能到用戶表就1500萬個用戶，到司機表就可能更少。所以有了聚合表后，衡量、選擇從哪張表里去計算數據,就不用每天去遍歷所有數據。
匯聚用戶畫像用到的表::
日報（時間緯度）
區域
數據集市的設計：
實際上數據倉庫是包括數據集市的，而且物理上是統一、非隔離的。並不是說我們單獨要建一個數據集市,是一個邏輯概念.
