一、數(shù)據(jù)倉(cāng)庫(kù)的用途

• 整合公司所有業(yè)務(wù)數(shù)據(jù)，建立統(tǒng)一的數(shù)據(jù)中心
• 產(chǎn)生業(yè)務(wù)報(bào)表，用于作出決策
• 為網(wǎng)站運(yùn)營(yíng)提供運(yùn)營(yíng)上的數(shù)據(jù)支持
• 可以作為各個(gè)業(yè)務(wù)的數(shù)據(jù)源，形成業(yè)務(wù)數(shù)據(jù)互相反饋的良性循環(huán)
• 分析用戶行為數(shù)據(jù)，通過(guò)數(shù)據(jù)挖掘來(lái)降低投入成本，提高投入效果
• 開(kāi)發(fā)數(shù)據(jù)產(chǎn)品，直接或間接地為公司盈利

二、數(shù)倉(cāng)運(yùn)行架構(gòu)圖

三、數(shù)據(jù)集市與數(shù)倉(cāng)的區(qū)別

數(shù)據(jù)集市（Data Market）：是一種微型的數(shù)據(jù)倉(cāng)庫(kù)，它通常有更少的數(shù)據(jù)，更少的主題區(qū)域，以及更少的歷史數(shù)據(jù)，因此是部門(mén)級(jí)的，一般只能為某個(gè)局部范圍內(nèi)的管理人員服務(wù)。

數(shù)據(jù)倉(cāng)庫(kù)（Data Warehouse）：數(shù)據(jù)倉(cāng)庫(kù)是企業(yè)級(jí)的，能為整個(gè)企業(yè)各個(gè)部門(mén)的運(yùn)行提供決策支持手段。

四、數(shù)倉(cāng)分層

1. 分層原因

• 把復(fù)雜問(wèn)題簡(jiǎn)單化：將復(fù)雜的任務(wù)分解成多層來(lái)完成，每一層只處理簡(jiǎn)單任務(wù)，方便定位問(wèn)題。
• 減少重復(fù)開(kāi)發(fā)：規(guī)范數(shù)據(jù)分層，通過(guò)中間層數(shù)據(jù)，能夠減少大量的重復(fù)計(jì)算，增加一次計(jì)算結(jié)果的復(fù)用性。
• 隔離原始數(shù)據(jù)：不論是數(shù)據(jù)的異常還是數(shù)據(jù)的敏感性，使真實(shí)數(shù)據(jù)與統(tǒng)計(jì)數(shù)據(jù)解耦開(kāi)。

2. 基本分層模型

ODS（數(shù)據(jù)源層，原始數(shù)據(jù)） – ETL --> DWD（數(shù)據(jù)明細(xì)層） – hive sql --> DWS（數(shù)據(jù)匯總） – sqoop --> ADS（數(shù)據(jù)應(yīng)用：報(bào)表、用戶畫(huà)像）

3. 數(shù)據(jù)倉(cāng)庫(kù)分層

3.1 數(shù)倉(cāng)分層概述

在阿里巴巴的數(shù)據(jù)體系中，建議將數(shù)據(jù)倉(cāng)庫(kù)分為三層，自下而上為：

數(shù)據(jù)引入層ODS（Operation Data Store）：存放未經(jīng)過(guò)處理的原始數(shù)據(jù)至數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)，結(jié)構(gòu)上與源系統(tǒng)保持一致，是數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)準(zhǔn)備區(qū)。主要完成基礎(chǔ)數(shù)據(jù)引入到MaxCompute的職責(zé)，同時(shí)記錄基礎(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ì)的明細(xì)事實(shí)表，以及匯總公共粒度的指標(biāo)，根據(jù)目前業(yè)務(wù)特點(diǎn)，暫時(shí)只建立DWD層

• 明細(xì)粒度事實(shí)層（DWD）：以業(yè)務(wù)過(guò)程作為建模驅(qū)動(dòng)，基于每個(gè)具體的業(yè)務(wù)過(guò)程特點(diǎn)，構(gòu)建最細(xì)粒度的明細(xì)層事實(shí)表。可以結(jié)合企業(yè)的數(shù)據(jù)使用特點(diǎn)，將明細(xì)事實(shí)表的某些重要維度屬性字段做適當(dāng)冗余，即寬表化處理。
• 數(shù)據(jù)中間層：DWM（Data WareHouse Middle）該層會(huì)在DWD層的數(shù)據(jù)基礎(chǔ)上，對(duì)數(shù)據(jù)做輕度的聚合操作，生成一系列的中間表，提升公共指標(biāo)的復(fù)用性，減少重復(fù)加工。直觀來(lái)講，就是對(duì)通用的核心維度進(jìn)行聚合操作，算出相應(yīng)的統(tǒng)計(jì)指標(biāo)。
• 公共匯總粒度事實(shí)層（DWS）：以分析的主題對(duì)象作為建模驅(qū)動(dòng)，基于上層的應(yīng)用和產(chǎn)品的指標(biāo)需求，構(gòu)建公共粒度的匯總指標(biāo)事實(shí)表，以寬表化手段物理化模型。構(gòu)建命名規(guī)范、口徑一致的統(tǒng)計(jì)指標(biāo)，為上層提供公共指標(biāo)，建立匯總寬表、明細(xì)事實(shí)表。
• 公共維度層（DIM）：基于維度建模理念思想，建立整個(gè)企業(yè)的一致性維度。降低數(shù)據(jù)計(jì)算口徑和算法不統(tǒng)一風(fēng)險(xiǎn)。公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對(duì)應(yīng)。

數(shù)據(jù)應(yīng)用層ADS（Application Data Service）：存放數(shù)據(jù)產(chǎn)品個(gè)性化的統(tǒng)計(jì)指標(biāo)數(shù)據(jù)。根據(jù)CDM與ODS層加工生成。

中英文及簡(jiǎn)寫(xiě)：

數(shù)據(jù)引入層（ODS，Operation Data Store）
數(shù)據(jù)公共層（CDM，Common Data Model）
公共維度層（DIM，Dimension）
數(shù)倉(cāng)明細(xì)層（DWD，Data Warehouse Detail）
數(shù)據(jù)匯總層（DWS，Data Warehouse Service）
數(shù)據(jù)應(yīng)用層（ADS，Application Data Service）。

3.2 各層級(jí)用途

1) 數(shù)據(jù)引入層（ODS，Operation Data Store）：將原始數(shù)據(jù)幾乎無(wú)處理的存放在數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)，結(jié)構(gòu)上與源系統(tǒng)基本保持一致，是數(shù)據(jù)倉(cāng)庫(kù)的數(shù)據(jù)準(zhǔn)備區(qū)。原始數(shù)據(jù)，主要是埋點(diǎn)數(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)計(jì)的明細(xì)事實(shí)表，以及匯總公共粒度的指標(biāo)。這一層里又包括三層：

• 公共維度層（DIM）：

基于維度建模理念思想，建立整個(gè)企業(yè)的一致性維度。降低數(shù)據(jù)計(jì)算口徑和算法不統(tǒng)一風(fēng)險(xiǎn)。公共維度層的表通常也被稱為邏輯維度表，維度和維度邏輯表通常一一對(duì)應(yīng)。

主要使用 MySQL、Hbase、Redis 三種存儲(chǔ)引擎，對(duì)于維表數(shù)據(jù)比較少的情況可以使用 MySQL，對(duì)于單條數(shù)據(jù)大小比較小，查詢 QPS 比較高的情況，可以使用 Redis 存儲(chǔ)，降低機(jī)器內(nèi)存資源占用，對(duì)于數(shù)據(jù)量比較大，對(duì)維表數(shù)據(jù)變化不是特別敏感的場(chǎng)景，可以使用 HBase 存儲(chǔ)。

• 數(shù)倉(cāng)明細(xì)層（DWD）：

ODS 層經(jīng)過(guò)清洗，落地這一層，一般是最細(xì)粒度。

以業(yè)務(wù)過(guò)程作為建模驅(qū)動(dòng)，**基于每個(gè)具體的業(yè)務(wù)過(guò)程特點(diǎn)，構(gòu)建最細(xì)粒度的明細(xì)層事實(shí)表。**可以結(jié)合企業(yè)的數(shù)據(jù)使用特點(diǎn)，將明細(xì)事實(shí)表的某些重要維度屬性字段做適當(dāng)冗余，即寬表化處理。

• 數(shù)據(jù)匯總層（DWS）：

對(duì) DWD 層的輕微聚合，對(duì)一些可累加的指標(biāo)進(jìn)行聚合，增加復(fù)用性。

以分析的主題對(duì)象作為建模驅(qū)動(dòng)，基于上層的應(yīng)用和產(chǎn)品的指標(biāo)需求，構(gòu)建公共粒度的匯總指標(biāo)事實(shí)表，以寬表化手段物理化模型。構(gòu)建命名規(guī)范、口徑一致的統(tǒng)計(jì)指標(biāo)，為上層提供公共指標(biāo)，建立匯總寬表、明細(xì)事實(shí)表。公共匯總粒度事實(shí)層的表通常也被稱為匯總邏輯表，用于存放派生指標(biāo)數(shù)據(jù)。

3) 數(shù)據(jù)應(yīng)用層（ADS，Application Data Service）：存放數(shù)據(jù)產(chǎn)品個(gè)性化的統(tǒng)計(jì)指標(biāo)數(shù)據(jù)。根據(jù) CDM 與 ODS 層加工生成。

4. 開(kāi)發(fā)規(guī)范

4.1 命名規(guī)則

1) ods 層

增量數(shù)據(jù)： {project_name}.ods_{數(shù)據(jù)來(lái)源}_{源系統(tǒng)表名}_delta 全量數(shù)據(jù)： {project_name}.ods_{數(shù)據(jù)來(lái)源}_{源系統(tǒng)表名}數(shù)據(jù)來(lái)源說(shuō)明： 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_user

2) dim 層

公共區(qū)域維表： {project_name}.dim_pub_{自定義命名標(biāo)簽} 具體業(yè)務(wù)維表： {project_name}.dim_{業(yè)務(wù)縮寫(xiě)}_{自定義命名標(biāo)簽}舉例如下： 公共區(qū)域維表： dim_pub_area 公共時(shí)間維表： dim_pub_date A公司電商板塊的商品全量表： dim_asale_itm

3) dwd 層

多個(gè)業(yè)務(wù)公共表： {project_name}.dwd_pub_{自定義命名標(biāo)簽} 具體業(yè)務(wù)數(shù)據(jù)增量表： {project_name}.dwd_{業(yè)務(wù)縮寫(xiě)}_{自定義命名標(biāo)簽}_di 具體業(yè)務(wù)數(shù)據(jù)全量表： {project_name}.dwd_{業(yè)務(wù)縮寫(xiě)}_{自定義命名標(biāo)簽}_df舉例如下： 交易會(huì)員信息事實(shí)表：ods_asale_trd_mbr_di 交易商品信息事實(shí)表：dwd_asale_trd_itm_di 交易訂單信息事實(shí)表：dwd_asale_trd_ord_di

4) dws 層

多個(gè)業(yè)務(wù)公共表： {project_name}.dws_pub_{自定義命名標(biāo)簽} 具體業(yè)務(wù)最近一天匯總事實(shí)表： {project_name}.dws_{業(yè)務(wù)縮寫(xiě)}_{自定義命名標(biāo)簽}_1d 具體業(yè)務(wù)最近N天匯總事實(shí)表： {project_name}.dws_{業(yè)務(wù)縮寫(xiě)}_{自定義命名標(biāo)簽}_nd 具體業(yè)務(wù)歷史截至當(dāng)天匯總表： {project_name}.dws_{業(yè)務(wù)縮寫(xiě)}_{自定義命名標(biāo)簽}_td 具體業(yè)務(wù)小時(shí)匯總表： {project_name}.dws_{業(yè)務(wù)縮寫(xiě)}_{自定義命名標(biāo)簽}_hh舉例如下： dws_asale_trd_byr_subpay_1d（A電商公司買(mǎi)家粒度交易分階段付款一日匯總事實(shí)表） dws_asale_trd_byr_subpay_td（A電商公司買(mǎi)家粒度分階段付款截至當(dāng)日匯總表） dws_asale_trd_byr_cod_nd（A電商公司買(mǎi)家粒度貨到付款交易匯總事實(shí)表） dws_asale_itm_slr_td（A電商公司賣(mài)家粒度商品截至當(dāng)日存量匯總表） dws_asale_itm_slr_hh（A電商公司賣(mài)家粒度商品小時(shí)匯總表）---維度為小時(shí) dws_asale_itm_slr_mm（A電商公司賣(mài)家粒度商品分鐘匯總表）---維度為分鐘

5) ads 層

{project_name}.ads_{業(yè)務(wù)縮寫(xiě)}_{自定義命名標(biāo)簽}舉例如下： 訂單統(tǒng)計(jì)表： ads_nshop_order_form 訂單支付統(tǒng)計(jì)： ads_nshop_orderpay_form

4.2 數(shù)據(jù)來(lái)源介紹

1) 業(yè)務(wù)數(shù)據(jù)
業(yè)務(wù)數(shù)據(jù)往往產(chǎn)生于事務(wù)型過(guò)程處理，所以一般存儲(chǔ)在關(guān)系型數(shù)據(jù)庫(kù)中，如 mysql、oracle。
業(yè)務(wù)數(shù)據(jù)源： 用戶基本信息、商品分類(lèi)信息、商品信息、店鋪信息、訂單數(shù)據(jù)、訂單支付信息、活動(dòng)信息、物流信息等

2) 埋點(diǎn)日志

埋點(diǎn)日志相對(duì)業(yè)務(wù)數(shù)據(jù)是用于數(shù)據(jù)分析、挖掘需求，一般以日志形式存儲(chǔ)于日志文件中，隨后通過(guò)采集落地分布式存儲(chǔ)介質(zhì)中如 hdfs、hbase。
用戶行為日志： 用戶瀏覽、用戶點(diǎn)評(píng)、用戶關(guān)注、用戶搜索、用戶投訴、用戶咨詢

3) 外部數(shù)據(jù)

當(dāng)前一般公司都會(huì)通過(guò)線上廣告來(lái)進(jìn)行獲客，與三方公司合作更多的提取相關(guān)數(shù)據(jù)來(lái)進(jìn)行深度刻畫(huà)用戶及用戶群體，另外爬取公共公開(kāi)數(shù)據(jù)也是分析運(yùn)營(yíng)的常用方式。
外部數(shù)據(jù)源： 廣告投放數(shù)據(jù)、爬蟲(chóng)數(shù)據(jù)、三方接口數(shù)據(jù)

5. 分層的誤區(qū)

數(shù)倉(cāng)層內(nèi)部的劃分不是為了分層而分層，分層是為了解決 ETL 任務(wù)及工作流的組織、數(shù)據(jù)的流向、讀寫(xiě)權(quán)限的控制、不同需求的滿足等各類(lèi)問(wèn)題。

業(yè)界較為通行的做法將整個(gè)數(shù)倉(cāng)層（DW）又劃分成了 dwd、dwb、dws、dim、mid 等等很多層。然而我們卻始終說(shuō)不清楚這幾層之間清晰的界限是什么，或者說(shuō)我們能說(shuō)清楚它們之間的界限，復(fù)雜的業(yè)務(wù)場(chǎng)景卻令我們無(wú)法真正落地執(zhí)行。

所以數(shù)據(jù)分層這塊一般來(lái)說(shuō) ODS、DWD、DWS 這三層是最基礎(chǔ)的：

至于DW層如何進(jìn)行切分，是根據(jù)具體的業(yè)務(wù)需求和公司場(chǎng)景自己去定義，一般來(lái)說(shuō)需要：

• 分層是解決數(shù)據(jù)流向和快速支撐業(yè)務(wù)的目的；
• 必須按照主題域和業(yè)務(wù)域進(jìn)行貫穿；
• 層級(jí)之間不可逆向依賴。
• 如果依賴ODS層數(shù)據(jù)可以完成數(shù)據(jù)支撐，那么業(yè)務(wù)方直接使用落地層這也有利于快速、低成本地進(jìn)行一些數(shù)據(jù)方面的探索和嘗試。
• 確定分層規(guī)范后，后續(xù)最好都遵循這個(gè)架構(gòu)，約定成俗即可；
• 血緣關(guān)系、數(shù)據(jù)依賴、數(shù)據(jù)字典、數(shù)據(jù)命名規(guī)范等配套先行；

?DW 內(nèi)的分層沒(méi)有最正確的，只有最適合你的。

6. 寬表的誤區(qū)

在數(shù)倉(cāng)層開(kāi)始引入了寬表。所謂寬表，迄今為止并沒(méi)有一個(gè)明確的定義。通常做法是把很多的維度、事實(shí)上卷（roll-up）或者下鉆（drill-down）之后關(guān)聯(lián)到某一個(gè)事實(shí)表中，形成一張既包含了大量維度又包含了相關(guān)事實(shí)的表。

寬表的使用，有其一定的便利性。使用方不需要再去考慮跟維度表的關(guān)聯(lián)，也不需要了解維度表和事實(shí)表是什么東西。
但是隨著業(yè)務(wù)的增長(zhǎng)，我們始終無(wú)法預(yù)見(jiàn)性地設(shè)計(jì)和定義寬表究竟該冗余多少維度，也無(wú)法清晰地定義出寬表冗余維度的底線在哪里。

一個(gè)可能存在的情況是，為了滿足使用上的需求，要不斷地將維表中已經(jīng)存在的列增加到寬表中。這直接導(dǎo)致了寬表的表結(jié)構(gòu)頻繁發(fā)生變動(dòng)。

目前我們所采用的做法是：

• 根據(jù)主題域和業(yè)務(wù)域，將某個(gè)業(yè)務(wù)的所有節(jié)點(diǎn)梳理清楚；
• 將關(guān)鍵節(jié)點(diǎn)的數(shù)據(jù)作為事實(shí)表依據(jù)，然后橫向擴(kuò)充其他事實(shí)表上卷數(shù)據(jù)（包含一些統(tǒng)計(jì)指標(biāo)），同時(shí)縱向的添加該節(jié)點(diǎn)上一些主鍵對(duì)應(yīng)的維度；
• 寬表的涉及不依賴具體的業(yè)務(wù)需求而是根據(jù)整體業(yè)務(wù)線相匹配；
• 盡量用維度建模代替寬表；

為什么說(shuō)盡量用維度建模代替寬表，就算字段和數(shù)據(jù)會(huì)冗余，維度建模的方式也會(huì)表全量數(shù)據(jù)的寬表模式較好，原因：

• 維度建模是以某一個(gè)既定的事實(shí)為依據(jù)，既然是事實(shí)表，那么這塊的業(yè)務(wù)如果不變動(dòng)的情況下，事實(shí)表的粒度基本不會(huì)改變；
• 事實(shí)表和維度表解耦，維度表的變更事實(shí)表基本不會(huì)影響，結(jié)果表也只需要回刷一下數(shù)據(jù)流程即可；
• 新增維度完全可以按照星型模型或者雪花模型動(dòng)態(tài)添加新維度；
• 維度模型可以作為寬表的基礎(chǔ)，一旦確定全部的數(shù)據(jù)流程，可以通過(guò)維度模型再生成對(duì)應(yīng)寬表進(jìn)行快速的業(yè)務(wù)支撐；
  ?

五、數(shù)倉(cāng)建模

1.范式理論

1.1 范式概念

1）定義

范式可以理解為設(shè)計(jì)一張數(shù)據(jù)表的表結(jié)構(gòu)，符合的標(biāo)準(zhǔn)級(jí)別、規(guī)范和要求。

2）優(yōu)點(diǎn)

采用范式，可以降低數(shù)據(jù)的冗余性。

為什么要降低數(shù)據(jù)冗余性？

（1）十幾年前，磁盤(pán)很貴，為了減少磁盤(pán)存儲(chǔ)。

（2）以前沒(méi)有分布式系統(tǒng)，都是單機(jī)，只能增加磁盤(pán)，磁盤(pán)個(gè)數(shù)也是有限的

（3）一次修改，需要修改多個(gè)表，很難保證數(shù)據(jù)一致性

3）缺點(diǎn)

范式的缺點(diǎn)是獲取數(shù)據(jù)時(shí)，需要通過(guò)Join拼接出最后的數(shù)據(jù)。

4）分類(lèi)

目前業(yè)界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。?

1.2?函數(shù)依賴

1、完全函數(shù)依賴

設(shè)X、Y是關(guān)系R的兩個(gè)屬性集合，X'是X的真子集，存在X→Y，但對(duì)于每一個(gè)X'都有X'!→Y，則稱Y完全函數(shù)依賴于X。

比如通過(guò)，（學(xué)號(hào)，課程）推出分?jǐn)?shù)，那么就可以說(shuō)：分?jǐn)?shù)完全依賴于（學(xué)號(hào)，課程）。

即：通過(guò)AB能得出C,但是AB單獨(dú)得不出C,那么說(shuō)C完全依賴于AB。

2、部分函數(shù)依賴

假如Y函數(shù)依賴于X，但同時(shí)Y并不完全函數(shù)依賴于X，那么我們就稱Y部分函數(shù)依賴于X。

比如通過(guò)（學(xué)號(hào)，課程）推出姓名，因?yàn)橹苯涌梢酝ㄟ^(guò)學(xué)號(hào)推出姓名。所以姓名部分依賴于（學(xué)號(hào)，課程）

即：通過(guò)AB能得出C,通過(guò)A也能得出C，或者通過(guò)B也能得出C，那么說(shuō)C部分依賴于AB。

3、傳遞函數(shù)依賴

設(shè)X、Y、Z是關(guān)系R中互不相同的屬性集合，存在X→Y（Y'!→X），Y→Z，則稱Z傳遞函數(shù)依賴于X。

學(xué)號(hào)推出系名，系名推出系主任，但是系主任推不出學(xué)號(hào)，系主任主要依賴于系名。這種情況可以說(shuō)系主任傳遞依賴于學(xué)號(hào)。

即：通過(guò)A得到B，通過(guò)B得到C，但是C得不到A，那么說(shuō)C傳遞依賴于A。

1.3?三范式區(qū)分

第一范式

1NF核心原則：屬性不可切割

很明顯上圖所示的表格設(shè)計(jì)是不符合第一范式的，商品列中的數(shù)據(jù)不是原子數(shù)據(jù)項(xiàng)，是可以進(jìn)行分割的，于是對(duì)表格進(jìn)行修改，讓表格符合第一范式的要求，如下圖所示：

?事實(shí)上，1NF是所有關(guān)系型數(shù)據(jù)庫(kù)的最基本要求，只要在RDBMS中已經(jīng)存在的數(shù)據(jù)表，一定是符合1NF的。

第二范式

2NF核心原則：不能存在部分函數(shù)依賴

以上表格明顯存在部分依賴。比如，這張表的主鍵是（學(xué)號(hào)，課名），分?jǐn)?shù)確實(shí)完全依賴于（學(xué)號(hào)，課名），但是姓名并不完全依賴于（學(xué)號(hào)，課名）。

?上圖右面表格符合第二范式，去掉了部分函數(shù)依賴。

第三范式

3NF核心原則：不能存在傳遞函數(shù)依賴

在下圖所示表格中，存在傳遞函數(shù)依賴：學(xué)號(hào)->系名->系主任，但是系主任推不出學(xué)號(hào)。

上面表需要再次拆解：

2.?關(guān)系建模與維度建模

當(dāng)今的數(shù)據(jù)處理大致可以分成兩大類(lèi)：聯(lián)機(jī)事務(wù)處理OLTP（on-line transaction processing）、聯(lián)機(jī)分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)的主要應(yīng)用，主要是基本的、日常的事務(wù)處理，例如銀行交易。OLAP是數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)的主要應(yīng)用，支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結(jié)果。二者的主要區(qū)別對(duì)比如下表所示。

對(duì)比屬性	OLTP	OLAP
讀特性	每次查詢只返回少量記錄	對(duì)大量記錄進(jìn)行匯總
寫(xiě)特性	隨機(jī)、低延時(shí)寫(xiě)入用戶的輸入	批量導(dǎo)入
使用場(chǎng)景	用戶，Java?EE項(xiàng)目	內(nèi)部分析師，為決策提供支持
數(shù)據(jù)表征	最新數(shù)據(jù)狀態(tài)	隨時(shí)間變化的歷史狀態(tài)
數(shù)據(jù)規(guī)模	GB	TB到PB

2.1 關(guān)系建模

?關(guān)系模型如圖所示，嚴(yán)格遵循第三范式（3NF），從圖中可以看出，較為松散、零碎，物理表數(shù)量多，而數(shù)據(jù)冗余程度低。由于數(shù)據(jù)分布于眾多的表中，這些數(shù)據(jù)可以更為靈活地被應(yīng)用，功能性較強(qiáng)。關(guān)系模型主要應(yīng)用與OLTP系統(tǒng)中，為了保證數(shù)據(jù)的一致性以及避免冗余，所以大部分業(yè)務(wù)系統(tǒng)的表都是遵循第三范式的。

2.2?維度建模

維度模型如圖所示，主要應(yīng)用于OLAP系統(tǒng)中，通常以某一個(gè)事實(shí)表為中心進(jìn)行表的組織，主要面向業(yè)務(wù)，特征是可能存在數(shù)據(jù)的冗余，但是能方便的得到數(shù)據(jù)。

關(guān)系模型雖然冗余少，但是在大規(guī)模數(shù)據(jù)，跨表分析統(tǒng)計(jì)查詢過(guò)程中，會(huì)造成多表關(guān)聯(lián)，這會(huì)大大降低執(zhí)行效率。所以通常我們采用維度模型建模，把相關(guān)各種表整理成兩種：事實(shí)表和維度表兩種。

3.?維度表和事實(shí)表

3.1?維度表

維度表：一般是對(duì)事實(shí)的描述信息。每一張維表對(duì)應(yīng)現(xiàn)實(shí)世界中的一個(gè)對(duì)象或者概念。例如：用戶、商品、日期、地區(qū)等。

在維度表中，每個(gè)表都包含獨(dú)立于其他維度表的事實(shí)特性，例如，客戶維度表包含有關(guān)客戶的數(shù)據(jù)。維度表中的列字段可以將信息分為不同層次的結(jié)構(gòu)級(jí)。

維表的特征：

• 維表的范圍很寬（具有多個(gè)屬性、列比較多）
• 跟事實(shí)表相比，行數(shù)相對(duì)較小：通常< 10萬(wàn)條
• 內(nèi)容相對(duì)固定：編碼表

時(shí)間維度表：

日期ID	day?of?week	day?of?year	季度	節(jié)假日
2020-01-01	2	1	1	元旦
2020-01-02	3	2	1	無(wú)
2020-01-03	4	3	1	無(wú)
2020-01-04	5	4	1	無(wú)
2020-01-05	6	5	1	無(wú)

3.2?事實(shí)表

事實(shí)表：每個(gè)數(shù)據(jù)倉(cāng)庫(kù)都包含一個(gè)或者多個(gè)事實(shí)數(shù)據(jù)表。事實(shí)數(shù)據(jù)表可能包含業(yè)務(wù)銷(xiāo)售數(shù)據(jù)，如現(xiàn)金登記事務(wù)所產(chǎn)生的數(shù)據(jù)，事實(shí)數(shù)據(jù)表通常包含大量的行。事實(shí)數(shù)據(jù)表的主要特點(diǎn)是包含數(shù)字?jǐn)?shù)據(jù)（事實(shí)），并且這些數(shù)字信息可以匯總，以提供有關(guān)單位作為歷史的數(shù)據(jù)，每個(gè)事實(shí)數(shù)據(jù)表包含一個(gè)由多個(gè)部分組成的索引，該索引包含作為外鍵的相關(guān)性緯度表的主鍵，而維度表包含事實(shí)記錄的特性。事實(shí)數(shù)據(jù)表不應(yīng)該包含描述性的信息，也不應(yīng)該包含除數(shù)字度量字段及使事實(shí)與緯度表中對(duì)應(yīng)項(xiàng)的相關(guān)索引字段之外的任何數(shù)據(jù)。

包含在事實(shí)數(shù)據(jù)表中的“度量值”有兩中：一種是可以累計(jì)的度量值，另一種是非累計(jì)的度量值。最有用的度量值是可累計(jì)的度量值，其累計(jì)起來(lái)的數(shù)字是非常有意義的。用戶可以通過(guò)累計(jì)度量值獲得匯總信息，例如。可以匯總具體時(shí)間段內(nèi)一組商店的特定商品的銷(xiāo)售情況。非累計(jì)的度量值也可以用于事實(shí)數(shù)據(jù)表，單匯總結(jié)果一般是沒(méi)有意義的，例如，在一座大廈的不同位置測(cè)量溫度時(shí)，如果將大廈中所有不同位置的溫度累加是沒(méi)有意義的，但是求平均值是有意義的。?

一般來(lái)說(shuō)，一個(gè)事實(shí)數(shù)據(jù)表都要和一個(gè)或多個(gè)緯度表相關(guān)聯(lián)，用戶在利用事實(shí)數(shù)據(jù)表創(chuàng)建多維數(shù)據(jù)集時(shí)，可以使用一個(gè)或多個(gè)維度表。

事實(shí)表中的每行數(shù)據(jù)代表一個(gè)業(yè)務(wù)事件（下單、支付、退款、評(píng)價(jià)等）。“事實(shí)”這個(gè)術(shù)語(yǔ)表示的是業(yè)務(wù)事件的度量值（可統(tǒng)計(jì)次數(shù)、個(gè)數(shù)、金額等），例如，2020年5月21日，宋老師在京東花了250塊錢(qián)買(mǎi)了一雙安踏鞋。維度表：時(shí)間、用戶、商品、商家。事實(shí)表：250塊錢(qián)、一雙

每一個(gè)事實(shí)表的行包括：具有可加性的數(shù)值型的度量值、與維表相連接的外鍵，通常具有兩個(gè)和兩個(gè)以上的外鍵。

事實(shí)表的特征：

• 非常的大
• 內(nèi)容相對(duì)的窄：列數(shù)較少（主要是外鍵id和度量值）
• 經(jīng)常發(fā)生變化，每天會(huì)新增加很多。

1）事務(wù)型事實(shí)表

以每個(gè)事務(wù)或事件為單位，例如一個(gè)銷(xiāo)售訂單記錄，一筆支付記錄等，作為事實(shí)表里的一行數(shù)據(jù)。一旦事務(wù)被提交，事實(shí)表數(shù)據(jù)被插入，數(shù)據(jù)就不再進(jìn)行更改，其更新方式為增量更新。

2）周期型快照事實(shí)表

周期型快照事實(shí)表中不會(huì)保留所有數(shù)據(jù)，只保留固定時(shí)間間隔的數(shù)據(jù)，例如每天或者每月的銷(xiāo)售額，或每月的賬戶余額等。

例如購(gòu)物車(chē)，有加減商品，隨時(shí)都有可能變化，但是我們更關(guān)心每天結(jié)束時(shí)這里面有多少商品，方便我們后期統(tǒng)計(jì)分析。

3）累積型快照事實(shí)表

累計(jì)快照事實(shí)表用于跟蹤業(yè)務(wù)事實(shí)的變化。例如，數(shù)據(jù)倉(cāng)庫(kù)中可能需要累積或者存儲(chǔ)訂單從下訂單開(kāi)始，到訂單商品被打包、運(yùn)輸、和簽收的各個(gè)業(yè)務(wù)階段的時(shí)間點(diǎn)數(shù)據(jù)來(lái)跟蹤訂單聲明周期的進(jìn)展情況。當(dāng)這個(gè)業(yè)務(wù)過(guò)程進(jìn)行時(shí)，事實(shí)表的記錄也要不斷更新。

訂單id	用戶id	下單時(shí)間	打包時(shí)間	發(fā)貨時(shí)間	簽收時(shí)間	訂單金額
		3-8	3-8	3-9	3-10

4. 維度模型分類(lèi)

在維度建模的基礎(chǔ)上又分為三種模型：星型模型、雪花模型、星座模型。

4.1 星型模型

?星型模型和雪花模型的主要區(qū)別在于維度的層級(jí)，標(biāo)準(zhǔn)的星型模型維度只有一層，而雪花模型會(huì)涉及多級(jí)。

4.2 雪花模型

?雪花模型，比較靠近3NF，但是無(wú)法完全遵守，因?yàn)樽裱?NF的性能成本太高。

4.3 星座模型

?星座模型與前兩種的區(qū)別是事實(shí)表的數(shù)量，星座模型是基于多個(gè)事實(shí)表。

基本上是很多數(shù)據(jù)倉(cāng)庫(kù)的常態(tài)，因?yàn)楹芏鄶?shù)據(jù)倉(cāng)庫(kù)都是多個(gè)事實(shí)表的，所以星座不星座只反映是否有多個(gè)事實(shí)表，他們之間是否共享一些維度表。所以星座模型并不和前兩種沖突。

4.4 模型的選擇

首先就是星座不星座這個(gè)只跟數(shù)據(jù)和需求有關(guān)系，跟設(shè)計(jì)沒(méi)關(guān)系，不用選擇。

星型還是雪花，取決于性能優(yōu)化，還是靈活更優(yōu)先。

目前實(shí)際企業(yè)開(kāi)發(fā)中，不會(huì)絕對(duì)選擇一種，根據(jù)情況靈活組合，甚至并存（一層維度和多層維度都保存）。但是整體來(lái)看，更傾向于維度更少的星型模型。尤其是Hadoop體系，減少Join就是減少Shuffle，性能差距很大。（關(guān)系型數(shù)據(jù)可以依靠強(qiáng)大的主鍵索引）

總結(jié)

以上是生活随笔為你收集整理的Hive之数仓的分层及建模理论的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。