Hive之数仓的分层及建模理论
一、數(shù)據(jù)倉庫的用途
- 整合公司所有業(yè)務(wù)數(shù)據(jù)，建立統(tǒng)一的數(shù)據(jù)中心
- 產(chǎn)生業(yè)務(wù)報表，用于作出決策
- 為網(wǎng)站運營提供運營上的數(shù)據(jù)支持
- 可以作為各個業(yè)務(wù)的數(shù)據(jù)源，形成業(yè)務(wù)數(shù)據(jù)互相反饋的良性循環(huán)
- 分析用戶行為數(shù)據(jù)，通過數(shù)據(jù)挖掘來降低投入成本，提高投入效果
- 開發(fā)數(shù)據(jù)產(chǎn)品，直接或間接地為公司盈利
二、數(shù)倉運行架構(gòu)圖
三、數(shù)據(jù)集市與數(shù)倉的區(qū)別
數(shù)據(jù)集市（Data Market）：是一種微型的數(shù)據(jù)倉庫，它通常有更少的數(shù)據(jù)，更少的主題區(qū)域，以及更少的歷史數(shù)據(jù)，因此是部門級的，一般只能為某個局部范圍內(nèi)的管理人員服務(wù)。
數(shù)據(jù)倉庫（Data Warehouse）：數(shù)據(jù)倉庫是企業(yè)級的，能為整個企業(yè)各個部門的運行提供決策支持手段。
四、數(shù)倉分層
1. 分層原因
- 把復(fù)雜問題簡單化：將復(fù)雜的任務(wù)分解成多層來完成，每一層只處理簡單任務(wù)，方便定位問題。
- 減少重復(fù)開發(fā)：規(guī)范數(shù)據(jù)分層，通過中間層數(shù)據(jù)，能夠減少大量的重復(fù)計算，增加一次計算結(jié)果的復(fù)用性。
- 隔離原始數(shù)據(jù)：不論是數(shù)據(jù)的異常還是數(shù)據(jù)的敏感性，使真實數(shù)據(jù)與統(tǒng)計數(shù)據(jù)解耦開。
2. 基本分層模型
ODS（數(shù)據(jù)源層，原始數(shù)據(jù)） – ETL --> DWD（數(shù)據(jù)明細層） – hive sql --> DWS（數(shù)據(jù)匯總） – sqoop --> ADS（數(shù)據(jù)應(yīng)用：報表、用戶畫像）
3. 數(shù)據(jù)倉庫分層
3.1 數(shù)倉分層概述
在阿里巴巴的數(shù)據(jù)體系中，建議將數(shù)據(jù)倉庫分為三層，自下而上為：
數(shù)據(jù)引入層ODS（Operation Data Store）：存放未經(jīng)過處理的原始數(shù)據(jù)至數(shù)據(jù)倉庫系統(tǒng)，結(jié)構(gòu)上與源系統(tǒng)保持一致，是數(shù)據(jù)倉庫的數(shù)據(jù)準備區(qū)。主要完成基礎(chǔ)數(shù)據(jù)引入到MaxCompute的職責，同時記錄基礎(chǔ)數(shù)據(jù)的歷史變化。
數(shù)據(jù)公共層CDM（Common Data Model，又稱通用數(shù)據(jù)模型層）:包括DIM維度表、DWD和DWS，由ODS層數(shù)據(jù)加工而成。主要完成數(shù)據(jù)加工與整合，建立一致性的維度，構(gòu)建可復(fù)用的面向分析和統(tǒng)計的明細事實表，以及匯總公共粒度的指標，根據(jù)目前業(yè)務(wù)特點，暫時只建立DWD層
- 明細粒度事實層（DWD）：以業(yè)務(wù)過程作為建模驅(qū)動，基于每個具體的業(yè)務(wù)過程特點，構(gòu)建最細粒度的明細層事實表。可以結(jié)合企業(yè)的數(shù)據(jù)使用特點，將明細事實表的某些重要維度屬性字段做適當冗余，即寬表化處理。
- 數(shù)據(jù)中間層：DWM（Data WareHouse Middle）該層會在DWD層的數(shù)據(jù)基礎(chǔ)上，對數(shù)據(jù)做輕度的聚合操作，生成一系列的中間表，提升公共指標的復(fù)用性，減少重復(fù)加工。直觀來講，就是對通用的核心維度進行聚合操作，算出相應(yīng)的統(tǒng)計指標。
- 公共匯總粒度事實層（DWS）：以分析的主題對象作為建模驅(qū)動，基于上層的應(yīng)用和產(chǎn)品的指標需求，構(gòu)建公共粒度的匯總指標事實表，以寬表化手段物理化模型。構(gòu)建命名規(guī)范、口徑一致的統(tǒng)計指標，為上層提供公共指標，建立匯總寬表、明細事實表。
- 公共維度層（DIM）：基于維度建模理念思想，建立整個企業(yè)的一致性維度。降低數(shù)據(jù)計算口徑和算法不統(tǒng)一風險。公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對應(yīng)。
數(shù)據(jù)應(yīng)用層ADS（Application Data Service）：存放數(shù)據(jù)產(chǎn)品個性化的統(tǒng)計指標數(shù)據(jù)。根據(jù)CDM與ODS層加工生成。
中英文及簡寫：
數(shù)據(jù)引入層（ODS，Operation Data Store）
數(shù)據(jù)公共層（CDM，Common Data Model）
公共維度層（DIM，Dimension）
數(shù)倉明細層（DWD，Data Warehouse Detail）
數(shù)據(jù)匯總層（DWS，Data Warehouse Service）
數(shù)據(jù)應(yīng)用層（ADS，Application Data Service）。
3.2 各層級用途
1) 數(shù)據(jù)引入層（ODS，Operation Data Store）：將原始數(shù)據(jù)幾乎無處理的存放在數(shù)據(jù)倉庫系統(tǒng)，結(jié)構(gòu)上與源系統(tǒng)基本保持一致，是數(shù)據(jù)倉庫的數(shù)據(jù)準備區(qū)。原始數(shù)據(jù)，主要是埋點數(shù)據(jù)（日志數(shù)據(jù)）和業(yè)務(wù)操作數(shù)據(jù)（binlong），數(shù)據(jù)源主要是 Mysql、HDFS、Kafka 等
2) 數(shù)據(jù)公共層（CDM，Common Data Model，又稱通用數(shù)據(jù)模型層），包括 DIM 維度表、DWD 和 DWS，由ODS 層數(shù)據(jù)加工而成。主要完成數(shù)據(jù)加工與整合，建立一致性的維度，構(gòu)建可復(fù)用的面向分析和統(tǒng)計的明細事實表，以及匯總公共粒度的指標。這一層里又包括三層：
- 公共維度層（DIM）：
- 數(shù)倉明細層（DWD）：
- 數(shù)據(jù)匯總層（DWS）：
3) 數(shù)據(jù)應(yīng)用層（ADS，Application Data Service）：存放數(shù)據(jù)產(chǎn)品個性化的統(tǒng)計指標數(shù)據(jù)。根據(jù) CDM 與 ODS 層加工生成。
4. 開發(fā)規(guī)范
4.1 命名規(guī)則
1) ods 層
增量數(shù)據(jù)： {project_name}.ods_{數(shù)據(jù)來源}_{源系統(tǒng)表名}_delta 全量數(shù)據(jù)： {project_name}.ods_{數(shù)據(jù)來源}_{源系統(tǒng)表名}數(shù)據(jù)來源說明： 01 -> hdfs 數(shù)據(jù) 02 -> mysql 數(shù)據(jù) 03 -> redis 數(shù)據(jù) 04 -> mongodb 數(shù)據(jù) 05 -> tidb 數(shù)據(jù)舉例如下： 行為日志表： ods_01_action_log 用戶表： ods_02_user2) dim 層
公共區(qū)域維表： {project_name}.dim_pub_{自定義命名標簽} 具體業(yè)務(wù)維表： {project_name}.dim_{業(yè)務(wù)縮寫}_{自定義命名標簽}舉例如下： 公共區(qū)域維表： dim_pub_area 公共時間維表： dim_pub_date A公司電商板塊的商品全量表： dim_asale_itm3) dwd 層
多個業(yè)務(wù)公共表： {project_name}.dwd_pub_{自定義命名標簽} 具體業(yè)務(wù)數(shù)據(jù)增量表： {project_name}.dwd_{業(yè)務(wù)縮寫}_{自定義命名標簽}_di 具體業(yè)務(wù)數(shù)據(jù)全量表： {project_name}.dwd_{業(yè)務(wù)縮寫}_{自定義命名標簽}_df舉例如下： 交易會員信息事實表：ods_asale_trd_mbr_di 交易商品信息事實表：dwd_asale_trd_itm_di 交易訂單信息事實表：dwd_asale_trd_ord_di4) dws 層
多個業(yè)務(wù)公共表： {project_name}.dws_pub_{自定義命名標簽} 具體業(yè)務(wù)最近一天匯總事實表： {project_name}.dws_{業(yè)務(wù)縮寫}_{自定義命名標簽}_1d 具體業(yè)務(wù)最近N天匯總事實表： {project_name}.dws_{業(yè)務(wù)縮寫}_{自定義命名標簽}_nd 具體業(yè)務(wù)歷史截至當天匯總表： {project_name}.dws_{業(yè)務(wù)縮寫}_{自定義命名標簽}_td 具體業(yè)務(wù)小時匯總表： {project_name}.dws_{業(yè)務(wù)縮寫}_{自定義命名標簽}_hh舉例如下： dws_asale_trd_byr_subpay_1d（A電商公司買家粒度交易分階段付款一日匯總事實表） dws_asale_trd_byr_subpay_td（A電商公司買家粒度分階段付款截至當日匯總表） dws_asale_trd_byr_cod_nd（A電商公司買家粒度貨到付款交易匯總事實表） dws_asale_itm_slr_td（A電商公司賣家粒度商品截至當日存量匯總表） dws_asale_itm_slr_hh（A電商公司賣家粒度商品小時匯總表）---維度為小時 dws_asale_itm_slr_mm（A電商公司賣家粒度商品分鐘匯總表）---維度為分鐘5) ads 層
{project_name}.ads_{業(yè)務(wù)縮寫}_{自定義命名標簽}舉例如下： 訂單統(tǒng)計表： ads_nshop_order_form 訂單支付統(tǒng)計： ads_nshop_orderpay_form4.2 數(shù)據(jù)來源介紹
1) 業(yè)務(wù)數(shù)據(jù)
業(yè)務(wù)數(shù)據(jù)往往產(chǎn)生于事務(wù)型過程處理，所以一般存儲在關(guān)系型數(shù)據(jù)庫中，如 mysql、oracle。
業(yè)務(wù)數(shù)據(jù)源： 用戶基本信息、商品分類信息、商品信息、店鋪信息、訂單數(shù)據(jù)、訂單支付信息、活動信息、物流信息等
2) 埋點日志
埋點日志相對業(yè)務(wù)數(shù)據(jù)是用于數(shù)據(jù)分析、挖掘需求，一般以日志形式存儲于日志文件中，隨后通過采集落地分布式存儲介質(zhì)中如 hdfs、hbase。
用戶行為日志： 用戶瀏覽、用戶點評、用戶關(guān)注、用戶搜索、用戶投訴、用戶咨詢
3) 外部數(shù)據(jù)
當前一般公司都會通過線上廣告來進行獲客，與三方公司合作更多的提取相關(guān)數(shù)據(jù)來進行深度刻畫用戶及用戶群體，另外爬取公共公開數(shù)據(jù)也是分析運營的常用方式。
外部數(shù)據(jù)源： 廣告投放數(shù)據(jù)、爬蟲數(shù)據(jù)、三方接口數(shù)據(jù)
5. 分層的誤區(qū)
數(shù)倉層內(nèi)部的劃分不是為了分層而分層，分層是為了解決 ETL 任務(wù)及工作流的組織、數(shù)據(jù)的流向、讀寫權(quán)限的控制、不同需求的滿足等各類問題。
業(yè)界較為通行的做法將整個數(shù)倉層（DW）又劃分成了 dwd、dwb、dws、dim、mid 等等很多層。然而我們卻始終說不清楚這幾層之間清晰的界限是什么，或者說我們能說清楚它們之間的界限，復(fù)雜的業(yè)務(wù)場景卻令我們無法真正落地執(zhí)行。
所以數(shù)據(jù)分層這塊一般來說 ODS、DWD、DWS 這三層是最基礎(chǔ)的：
至于DW層如何進行切分，是根據(jù)具體的業(yè)務(wù)需求和公司場景自己去定義，一般來說需要：
- 分層是解決數(shù)據(jù)流向和快速支撐業(yè)務(wù)的目的；
- 必須按照主題域和業(yè)務(wù)域進行貫穿；
- 層級之間不可逆向依賴。
- 如果依賴ODS層數(shù)據(jù)可以完成數(shù)據(jù)支撐，那么業(yè)務(wù)方直接使用落地層這也有利于快速、低成本地進行一些數(shù)據(jù)方面的探索和嘗試。
- 確定分層規(guī)范后，后續(xù)最好都遵循這個架構(gòu)，約定成俗即可；
- 血緣關(guān)系、數(shù)據(jù)依賴、數(shù)據(jù)字典、數(shù)據(jù)命名規(guī)范等配套先行；
?DW 內(nèi)的分層沒有最正確的，只有最適合你的。
6. 寬表的誤區(qū)
在數(shù)倉層開始引入了寬表。所謂寬表，迄今為止并沒有一個明確的定義。通常做法是把很多的維度、事實上卷（roll-up）或者下鉆（drill-down）之后關(guān)聯(lián)到某一個事實表中，形成一張既包含了大量維度又包含了相關(guān)事實的表。
寬表的使用，有其一定的便利性。使用方不需要再去考慮跟維度表的關(guān)聯(lián)，也不需要了解維度表和事實表是什么東西。
但是隨著業(yè)務(wù)的增長，我們始終無法預(yù)見性地設(shè)計和定義寬表究竟該冗余多少維度，也無法清晰地定義出寬表冗余維度的底線在哪里。
一個可能存在的情況是，為了滿足使用上的需求，要不斷地將維表中已經(jīng)存在的列增加到寬表中。這直接導(dǎo)致了寬表的表結(jié)構(gòu)頻繁發(fā)生變動。
目前我們所采用的做法是：
- 根據(jù)主題域和業(yè)務(wù)域，將某個業(yè)務(wù)的所有節(jié)點梳理清楚；
- 將關(guān)鍵節(jié)點的數(shù)據(jù)作為事實表依據(jù)，然后橫向擴充其他事實表上卷數(shù)據(jù)（包含一些統(tǒng)計指標），同時縱向的添加該節(jié)點上一些主鍵對應(yīng)的維度；
- 寬表的涉及不依賴具體的業(yè)務(wù)需求而是根據(jù)整體業(yè)務(wù)線相匹配；
- 盡量用維度建模代替寬表；
為什么說盡量用維度建模代替寬表，就算字段和數(shù)據(jù)會冗余，維度建模的方式也會表全量數(shù)據(jù)的寬表模式較好，原因：
- 維度建模是以某一個既定的事實為依據(jù)，既然是事實表，那么這塊的業(yè)務(wù)如果不變動的情況下，事實表的粒度基本不會改變；
- 事實表和維度表解耦，維度表的變更事實表基本不會影響，結(jié)果表也只需要回刷一下數(shù)據(jù)流程即可；
- 新增維度完全可以按照星型模型或者雪花模型動態(tài)添加新維度；
- 維度模型可以作為寬表的基礎(chǔ)，一旦確定全部的數(shù)據(jù)流程，可以通過維度模型再生成對應(yīng)寬表進行快速的業(yè)務(wù)支撐；
?
五、數(shù)倉建模
1.范式理論
1.1 范式概念
1）定義
范式可以理解為設(shè)計一張數(shù)據(jù)表的表結(jié)構(gòu)，符合的標準級別、規(guī)范和要求。
2）優(yōu)點
采用范式，可以降低數(shù)據(jù)的冗余性。
為什么要降低數(shù)據(jù)冗余性？
（1）十幾年前，磁盤很貴，為了減少磁盤存儲。
（2）以前沒有分布式系統(tǒng)，都是單機，只能增加磁盤，磁盤個數(shù)也是有限的
（3）一次修改，需要修改多個表，很難保證數(shù)據(jù)一致性
3）缺點
范式的缺點是獲取數(shù)據(jù)時，需要通過Join拼接出最后的數(shù)據(jù)。
4）分類
目前業(yè)界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。?
1.2?函數(shù)依賴
1、完全函數(shù)依賴
設(shè)X、Y是關(guān)系R的兩個屬性集合，X'是X的真子集，存在X→Y，但對于每一個X'都有X'!→Y，則稱Y完全函數(shù)依賴于X。
比如通過，（學號，課程）推出分數(shù)，那么就可以說：分數(shù)完全依賴于（學號，課程）。
即：通過AB能得出C,但是AB單獨得不出C,那么說C完全依賴于AB。
2、部分函數(shù)依賴
假如Y函數(shù)依賴于X，但同時Y并不完全函數(shù)依賴于X，那么我們就稱Y部分函數(shù)依賴于X。
比如通過（學號，課程）推出姓名，因為直接可以通過學號推出姓名。所以姓名部分依賴于（學號，課程）
即：通過AB能得出C,通過A也能得出C，或者通過B也能得出C，那么說C部分依賴于AB。
3、傳遞函數(shù)依賴
設(shè)X、Y、Z是關(guān)系R中互不相同的屬性集合，存在X→Y（Y'!→X），Y→Z，則稱Z傳遞函數(shù)依賴于X。
學號推出系名，系名推出系主任，但是系主任推不出學號，系主任主要依賴于系名。這種情況可以說系主任傳遞依賴于學號。
即：通過A得到B，通過B得到C，但是C得不到A，那么說C傳遞依賴于A。
1.3?三范式區(qū)分
第一范式
1NF核心原則：屬性不可切割
很明顯上圖所示的表格設(shè)計是不符合第一范式的，商品列中的數(shù)據(jù)不是原子數(shù)據(jù)項，是可以進行分割的，于是對表格進行修改，讓表格符合第一范式的要求，如下圖所示：
?事實上，1NF是所有關(guān)系型數(shù)據(jù)庫的最基本要求，只要在RDBMS中已經(jīng)存在的數(shù)據(jù)表，一定是符合1NF的。
第二范式
2NF核心原則：不能存在部分函數(shù)依賴
以上表格明顯存在部分依賴。比如，這張表的主鍵是（學號，課名），分數(shù)確實完全依賴于（學號，課名），但是姓名并不完全依賴于（學號，課名）。
?上圖右面表格符合第二范式，去掉了部分函數(shù)依賴。
第三范式
3NF核心原則：不能存在傳遞函數(shù)依賴
在下圖所示表格中，存在傳遞函數(shù)依賴：學號->系名->系主任，但是系主任推不出學號。
上面表需要再次拆解：
2.?關(guān)系建模與維度建模
當今的數(shù)據(jù)處理大致可以分成兩大類：聯(lián)機事務(wù)處理OLTP（on-line transaction processing）、聯(lián)機分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫的主要應(yīng)用，主要是基本的、日常的事務(wù)處理，例如銀行交易。OLAP是數(shù)據(jù)倉庫系統(tǒng)的主要應(yīng)用，支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結(jié)果。二者的主要區(qū)別對比如下表所示。
| 對比屬性 | OLTP | OLAP |
| 讀特性 | 每次查詢只返回少量記錄 | 對大量記錄進行匯總 |
| 寫特性 | 隨機、低延時寫入用戶的輸入 | 批量導(dǎo)入 |
| 使用場景 | 用戶，Java?EE項目 | 內(nèi)部分析師，為決策提供支持 |
| 數(shù)據(jù)表征 | 最新數(shù)據(jù)狀態(tài) | 隨時間變化的歷史狀態(tài) |
| 數(shù)據(jù)規(guī)模 | GB | TB到PB |
2.1 關(guān)系建模
?關(guān)系模型如圖所示，嚴格遵循第三范式（3NF），從圖中可以看出，較為松散、零碎，物理表數(shù)量多，而數(shù)據(jù)冗余程度低。由于數(shù)據(jù)分布于眾多的表中，這些數(shù)據(jù)可以更為靈活地被應(yīng)用，功能性較強。關(guān)系模型主要應(yīng)用與OLTP系統(tǒng)中，為了保證數(shù)據(jù)的一致性以及避免冗余，所以大部分業(yè)務(wù)系統(tǒng)的表都是遵循第三范式的。
2.2?維度建模
維度模型如圖所示，主要應(yīng)用于OLAP系統(tǒng)中，通常以某一個事實表為中心進行表的組織，主要面向業(yè)務(wù)，特征是可能存在數(shù)據(jù)的冗余，但是能方便的得到數(shù)據(jù)。
關(guān)系模型雖然冗余少，但是在大規(guī)模數(shù)據(jù)，跨表分析統(tǒng)計查詢過程中，會造成多表關(guān)聯(lián)，這會大大降低執(zhí)行效率。所以通常我們采用維度模型建模，把相關(guān)各種表整理成兩種：事實表和維度表兩種。
3.?維度表和事實表
3.1?維度表
維度表：一般是對事實的描述信息。每一張維表對應(yīng)現(xiàn)實世界中的一個對象或者概念。例如：用戶、商品、日期、地區(qū)等。
在維度表中，每個表都包含獨立于其他維度表的事實特性，例如，客戶維度表包含有關(guān)客戶的數(shù)據(jù)。維度表中的列字段可以將信息分為不同層次的結(jié)構(gòu)級。
維表的特征：
- 維表的范圍很寬（具有多個屬性、列比較多）
- 跟事實表相比，行數(shù)相對較小：通常< 10萬條
- 內(nèi)容相對固定：編碼表
時間維度表：
| 日期ID | day?of?week | day?of?year | 季度 | 節(jié)假日 |
| 2020-01-01 | 2 | 1 | 1 | 元旦 |
| 2020-01-02 | 3 | 2 | 1 | 無 |
| 2020-01-03 | 4 | 3 | 1 | 無 |
| 2020-01-04 | 5 | 4 | 1 | 無 |
| 2020-01-05 | 6 | 5 | 1 | 無 |
3.2?事實表
事實表：每個數(shù)據(jù)倉庫都包含一個或者多個事實數(shù)據(jù)表。事實數(shù)據(jù)表可能包含業(yè)務(wù)銷售數(shù)據(jù)，如現(xiàn)金登記事務(wù)所產(chǎn)生的數(shù)據(jù)，事實數(shù)據(jù)表通常包含大量的行。事實數(shù)據(jù)表的主要特點是包含數(shù)字數(shù)據(jù)（事實），并且這些數(shù)字信息可以匯總，以提供有關(guān)單位作為歷史的數(shù)據(jù)，每個事實數(shù)據(jù)表包含一個由多個部分組成的索引，該索引包含作為外鍵的相關(guān)性緯度表的主鍵，而維度表包含事實記錄的特性。事實數(shù)據(jù)表不應(yīng)該包含描述性的信息，也不應(yīng)該包含除數(shù)字度量字段及使事實與緯度表中對應(yīng)項的相關(guān)索引字段之外的任何數(shù)據(jù)。
包含在事實數(shù)據(jù)表中的“度量值”有兩中：一種是可以累計的度量值，另一種是非累計的度量值。最有用的度量值是可累計的度量值，其累計起來的數(shù)字是非常有意義的。用戶可以通過累計度量值獲得匯總信息，例如。可以匯總具體時間段內(nèi)一組商店的特定商品的銷售情況。非累計的度量值也可以用于事實數(shù)據(jù)表，單匯總結(jié)果一般是沒有意義的，例如，在一座大廈的不同位置測量溫度時，如果將大廈中所有不同位置的溫度累加是沒有意義的，但是求平均值是有意義的。?
一般來說，一個事實數(shù)據(jù)表都要和一個或多個緯度表相關(guān)聯(lián)，用戶在利用事實數(shù)據(jù)表創(chuàng)建多維數(shù)據(jù)集時，可以使用一個或多個維度表。
事實表中的每行數(shù)據(jù)代表一個業(yè)務(wù)事件（下單、支付、退款、評價等）。“事實”這個術(shù)語表示的是業(yè)務(wù)事件的度量值（可統(tǒng)計次數(shù)、個數(shù)、金額等），例如，2020年5月21日，宋老師在京東花了250塊錢買了一雙安踏鞋。維度表：時間、用戶、商品、商家。事實表：250塊錢、一雙
每一個事實表的行包括：具有可加性的數(shù)值型的度量值、與維表相連接的外鍵，通常具有兩個和兩個以上的外鍵。
事實表的特征：
- 非常的大
- 內(nèi)容相對的窄：列數(shù)較少（主要是外鍵id和度量值）
- 經(jīng)常發(fā)生變化，每天會新增加很多。
1）事務(wù)型事實表
以每個事務(wù)或事件為單位，例如一個銷售訂單記錄，一筆支付記錄等，作為事實表里的一行數(shù)據(jù)。一旦事務(wù)被提交，事實表數(shù)據(jù)被插入，數(shù)據(jù)就不再進行更改，其更新方式為增量更新。
2）周期型快照事實表
周期型快照事實表中不會保留所有數(shù)據(jù)，只保留固定時間間隔的數(shù)據(jù)，例如每天或者每月的銷售額，或每月的賬戶余額等。
例如購物車，有加減商品，隨時都有可能變化，但是我們更關(guān)心每天結(jié)束時這里面有多少商品，方便我們后期統(tǒng)計分析。
3）累積型快照事實表
累計快照事實表用于跟蹤業(yè)務(wù)事實的變化。例如，數(shù)據(jù)倉庫中可能需要累積或者存儲訂單從下訂單開始，到訂單商品被打包、運輸、和簽收的各個業(yè)務(wù)階段的時間點數(shù)據(jù)來跟蹤訂單聲明周期的進展情況。當這個業(yè)務(wù)過程進行時，事實表的記錄也要不斷更新。
| 訂單id | 用戶id | 下單時間 | 打包時間 | 發(fā)貨時間 | 簽收時間 | 訂單金額 |
| 3-8 | 3-8 | 3-9 | 3-10 |
4. 維度模型分類
在維度建模的基礎(chǔ)上又分為三種模型：星型模型、雪花模型、星座模型。
4.1 星型模型
?星型模型和雪花模型的主要區(qū)別在于維度的層級，標準的星型模型維度只有一層，而雪花模型會涉及多級。
4.2 雪花模型
?雪花模型，比較靠近3NF，但是無法完全遵守，因為遵循3NF的性能成本太高。
4.3 星座模型
?星座模型與前兩種的區(qū)別是事實表的數(shù)量，星座模型是基于多個事實表。
基本上是很多數(shù)據(jù)倉庫的常態(tài)，因為很多數(shù)據(jù)倉庫都是多個事實表的，所以星座不星座只反映是否有多個事實表，他們之間是否共享一些維度表。所以星座模型并不和前兩種沖突。
4.4 模型的選擇
首先就是星座不星座這個只跟數(shù)據(jù)和需求有關(guān)系，跟設(shè)計沒關(guān)系，不用選擇。
星型還是雪花，取決于性能優(yōu)化，還是靈活更優(yōu)先。
目前實際企業(yè)開發(fā)中，不會絕對選擇一種，根據(jù)情況靈活組合，甚至并存（一層維度和多層維度都保存）。但是整體來看，更傾向于維度更少的星型模型。尤其是Hadoop體系，減少Join就是減少Shuffle，性能差距很大。（關(guān)系型數(shù)據(jù)可以依靠強大的主鍵索引）
總結(jié)
以上是生活随笔為你收集整理的Hive之数仓的分层及建模理论的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： c语言MB_HELP用法,help的用法
- 下一篇： Exchange的介绍及使用