如何理解維度表和數倉建模
一、從目的上說，這是為做分析，建數倉，組織管理資料的一種方式，即就是所謂說的資料建模
你不列出可分析維度，你們做各角色的資料集，你沒有一個縱向組合的維度把資料管理起來，你的資料怎麼能成為資料資產，那隻能是分散在業務中的資料，你給人說你有多少線索多少城市，沒有根據，這就是一種拿資料說話的方式，有零有整，不和你瞎說對不這才有可信度
二、技術角度，預計算，平埔，加速，，
三、 倉庫建模本身有維度粒度度量的概念的，不能用db思想去理解和思考，它是來自欄位，但有些不是，如8090後，Q1Q2這是生成的觀測維度，業務表只時間欄位，再一個是據分析需求粒度，可以到天級市級，而不在細分，或地域和負責人區分開不同維度，未來給觀察人做的資料集或是許可權隔離了什麼的都可以從這上面做
四、DBER模型方便做分析的上鑽下取旋轉切片，那就沒有數倉建模啥事了，是吧，自己寫寫SQL，我要看哪個城市個哪省區線索最高，同時要看哪個季度，哪個月最高，同時我繼續看，哪個季度月在哪個省市區最高，就這一個分析線索指標是吧不同維度粒度切換，你哪dbsql原始的方式，省區，季，月，這個用函式求了多少遍，得寫多少條sqL
總結 ：要用數倉立方體的思維，不要用db二維表的思維，思想很重要
倉庫、模型、事實表建立：
1.倉庫可按業務及業務組合分別分層建立（如：報名，邀約，成交，報名成交等），也可用通用觀測維建立分層觀測倉
2.倉庫中含一和多個模型（星型，雪花型，或3f混合）建立分層資料集
3.一模型中通常由維表，事實表，lookup表組成
4.維度又有狀態過濾普通/標準維和JOIN/匯出維及通用/強制組合維（如圖中四大通用/強制維在每個業務都有觀測需求）和層級維之分，目的是為優化CUBE的建立，避免隨著維度的增加，計算量和儲存量呈幾何倍數增長
5.cube是dm的預計算結果集，最快的查詢優化計算方法就是不計算，它用空間換時間來提速大資料查詢，實現秒級響影
參考kylin相關概念
3.1Fact Table(事實表)：
事實表是指包含了大量不冗餘資料的表，其列一般有兩種，分別為包含事實資料的列，包含維表foreign key的列。
3.3Dimenssion Table(維表)：
由fact table和lookup table 抽象出來的表，包含了多個相關的列，提供對資料不同維度的觀察，其中每列的值的數目稱為cardinatily。
3.4model:用來定義使用者需要使用的hive表名，及所包含的維度列、度量列、partition列和date格式。
3.5cube:用來定義某具體查詢時會涉及到的維度列及相互之間的關係（如層級關係）、度量列的具體型別（如max，min，sum）等,一個model下可存在多個cube。
1.什麼是cube？
cube是所有dimession的組合，每一種dimession的組合稱之為cuboid。某一有n個dimession的cube會有2n個cuboid，如圖：
對應一張hive表，有time,item,location,supplier這四個維度，則0-D cuboid時對應的查詢語句為 select sum(money) from table;1-D cuboid對應的查詢語句有四個，分別為select sum(money) from table group by time，以及select sum(money) from table group by item,以及select sum(money) from table group by location。對應的在2-D時group by 後面的維度會是time,item,location,supplier兩兩組合。如果不採取優化措施，理論上kylin在預計算過程中會對上述每一種組合進行預計算，隨著維度的增加，計算量將會呈幾何倍數的增長。為了解決這種問題，kylin對dimession做了分類，見下文。
2.dimession
為了減少cuboid的數量，kylin對dimession做了如下分類
normal：最為普通常見的dimession型別，與其他型別的dimession組成cuboid。
mandatory：每次查詢均會使用到的dimession，在下圖中A為Mandatory dimension，則與B、C總共構成了4個cuboid，相較於normal dimension的cuboid（23=8)減少了一半。
在實際生產應用中，比如對於日報表的分析，可能日期就是一個mandatory dimession。
hierarchy：帶層級的dimession,如：年->月->日，要求子級的父級必須存在。如下的例子中cuboid由2n降為了n+1。
然而，Kylin的Hierarchy dimensions並沒有做集合包含約束，比如：kylin_sales_cube定義Hierarchy dimension為META_CATEG_NAME->CATEG_LVL2_NAME->CATEG_LVL3_NAME，但是同一個CATEG_LVL2_NAME可以對應不同META_CATEG_NAME。因此，hierarchy 顯得非常雞肋，以至於在Kylin後臺處理時被廢棄了。
derived：指該dimession與維表的primary key是一一對應的關係，可以有效減少cuboid的數量，derived dimession只能由Lookup Table生成。
3.measure
measure為事實表的度量值，kylin提供了下面幾個函式：
sum,count,max,min,avarage,count_distinct
其中count_distinct有兩種實現方式：
（1）近似Count Distinct。Apache Kylin使用HyperLogLog演算法實現了近似Count Distinct,提供了錯誤率從9.75%到1.22%幾種精度供選擇；
演算法計算後的Count Distinct指標，理論上，結果最大隻有64KB，最低的錯誤率是1.22%；這種實現方式用在需要快速計算、節省儲存空間，並且能接受錯誤率的Count Distinct指標計算。
（2）準Count Distinct。從1.5.3版本開始，Kylin中實現了基於bitmap的精確Count Distinct計算方式。當資料型別為tiny int(byte)、small int(short)以及int，
會直接將資料值對映到bitmap中；當資料型別為long,string或者其他，則需要將資料值以字串形式編碼成dict(字典)，再將字典ID對映到bitmap;
指標計算後的結果，並不是計數後的值，而是包含了序列化值的bitmap.這樣，才能確保在任意維度上的Count Distinct結果是正確的。
這種實現方式提供了精確的無錯誤的Count Distinct結果，但是需要更多的儲存資源，如果資料中的不重複值超過百萬，結果所佔的儲存應該會達到幾百MB。
Mandatory Dimensions：每次查詢均會使用的維度可新增在此。比如某些情況下的partition column.
Hierarchy Dimensions：維度列中彼此間存在層級關係的列，比如“國家-省份-市-縣”
Joint Dimensions：每次查詢會同時使用或不使用的維度組合。
Aggregation Group:在不同的查詢中，兩組維度組合之間不會產生交叉，可選擇此選項，比如所有的cube維度有 [ a,b,c,d,e,f ] 6個，每次查詢中只會同時查與 [ a,b,c ] 相關的資訊（比如[a],[a,c]等）而不會查詢 [ d,e,f ]，或者相反，則可選擇此選項。
以上選擇均可減少build過程中的資料量，是加快build與query速度的優化點之一。
轉載於:https://my.oschina.net/hblt147/blog/1936200