電商數(shù)倉（3電商數(shù)據(jù)倉庫系統(tǒng)）V62

電商數(shù)據(jù)倉庫系統(tǒng)

版本：V6.2.0

第1章數(shù)倉分層

1.1為什么要分層

為什么需要分層

一、數(shù)據(jù)倉庫分層

ODS層：原始數(shù)據(jù)層，存放原始數(shù)據(jù)，直接加載原始日志、數(shù)據(jù)，數(shù)據(jù)保持原貌不做處理。

DWD層：對ODS層數(shù)據(jù)進行清洗（去除空值，臟數(shù)據(jù)，超過極限范圍的數(shù)據(jù)）、維度退

化、脫軟等。粒度是一行信息代表一次行為，例如一次下單。

以DWD為基礎(chǔ)，按天進行輕度匯總。粒度是一行信息代表一天的行為，例如一天下單次數(shù)

以DWS為基礎(chǔ)，按主題進行匯總。粒度是一行信息代表累積的行為，例如用戶從注冊那天

開始至今一共下了多少次單

ADS層，為各種統(tǒng)計報表提供數(shù)據(jù)

二、數(shù)據(jù)倉庫為什么要分層

>1）把復(fù)雜問題簡單化將復(fù)雜的任務(wù)分解成多層來完成，每一層只處理簡單的任務(wù)，方便定位問題。

>2）減少重復(fù)開發(fā)規(guī)范數(shù)據(jù)分層，通過的?間層數(shù)據(jù)，能夠減少極大的重復(fù)計算，增加一次計算結(jié)果的且用性。

>3）隔離原始數(shù)據(jù)不論是數(shù)據(jù)的異常還是數(shù)據(jù)的熨感性，使真實數(shù)據(jù)與統(tǒng)計數(shù)據(jù)解耦開。

1.2數(shù)據(jù)集市與數(shù)據(jù)倉庫概念

數(shù)據(jù)集市與數(shù)據(jù)倉庫的區(qū)別

數(shù)據(jù)集巾（DataMarket）,現(xiàn)在市而上的公司和書籍都對數(shù)據(jù)集市有不同的概念。

數(shù)據(jù)生巾則是?種微型的數(shù)據(jù)倉庫，它通常有更少的數(shù)據(jù)，更少的主題區(qū)域，以

及更少的歷史數(shù)據(jù),因此是部門級的,一般只能為某個局部范圍內(nèi)的管理人員服務(wù)。

數(shù)據(jù)倉際是企業(yè)級的，能為整個企業(yè)各個部門的運行提供決策支持r?段。

1.3數(shù)倉命名規(guī)范

1.3.1表命名

>ODS層命名為ods一表名

>DWD層命名為dwd_dim/fact一表名

>DWS層命名為dws一表名

>DWT層命名為dwt_表名

>ADS層命名為ads一表名

>臨時表命名為xxx_tmp

>用戶行為表，以log為后綴。

1.3.2腳本命名

>數(shù)據(jù)源」o_目標_db/log.sh

>用戶行為腳本以log為后綴；業(yè)務(wù)數(shù)據(jù)腳本以db為后綴。

1.3.3表字段類型

>數(shù)量類型為bigint

>金額類型為decimal16,2）,表示：16位有效數(shù)字，其中小數(shù)部分2位

>字符串（名字，描述信息等）類型為string

>主鍵外鍵類型為string

>時間戳類型為bigint

第2章數(shù)倉理論

2.1范式理論

2.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)。

2.1.2函數(shù)依賴

函數(shù)依賴

學(xué)用-姓名，第名，系主任.西分數(shù)，2、部分函數(shù)依核

1022211101-李小明，經(jīng)濟前王強?高等教學(xué)，95假如Y函數(shù)依賴rX,但同時Y并不完全函數(shù)依賴于X.

1022211101.李小明?短濟系?王強.大學(xué)英遢“87.

1022211101-李小明?經(jīng)濟國王強普通化學(xué)“76那么我們就稱Y部分函數(shù)依賴『X,記做：，

1022211102.張莉風及濟某王強.高等數(shù)學(xué)?72.人類語言：

張利知經(jīng)濟展王強大學(xué)英遇，

1022211102.98比如通過，(4號，課程)推出姓名，因為其實直接可以

1022211102-米司科經(jīng)濟象王足計算機東孫88

1022511101-高芳芳，法律第，劉玲，高零數(shù)學(xué)“82-?，，.：：.課程)

高芳芳,法律再劉玲，法掌基砒，

1022511101^82即：通過AB能得出C,通過A也能得出C,或者通過B也

能得出C?那么說C部分依賴TAB。

1、完全函數(shù)依賴：3、傳遞函數(shù)依賴

傳遞函數(shù)依賴：設(shè)X.Y.Z是關(guān)系R中互不相同的屬性集

設(shè)X,Y是關(guān)系R的兩個屬性集合，X，是X的其「集，存在

合，存在X-Y(YJX).YTZ.則稱Z傳遞函數(shù)依賴了X。記做：

X-Y,但對每一個X，都TTX'!一Y,則稱Y完全函數(shù)依賴「X。記

xLz

做：

人類諳言：

人類語言：

比如：學(xué)號推出系名,一名推出系一任,但是,系

比如通過，(學(xué)號，課程)推出分數(shù),但是單獨用學(xué)號推斷不

E任推不出學(xué)號，系主任主要依幢了系名.這前哨旗前以修

系主任傳遞依賴「學(xué)號

即：通過AB能得出C,但是AB單獨對不出C,那么說C完全通過A得到B,通過B得到C.但是C得不到A.那么說C傳

依賴jABe遞依賴于A.

2.1.3三范式區(qū)分

第一范式

1、第范式1NF核心原則就是：屬性不可切割

表不符合一范式的表格設(shè)計~

ID.商品“商家ID.用戶ID.

001“5臺電腦「XXX旗艦店.0000V

很明顯上圖所示的表格設(shè)il?是不符合第?范式的，商品列中的數(shù)據(jù)不是原子數(shù)據(jù)項，是

可以進行分割的，因此對表格進行修改，讓表格符合第一范式的要求，修改結(jié)果如下圖所示:

表符合一范式的表格設(shè)計〃

ID”商品?、數(shù)量尹商家ID.用戶ID.

001P電腦”6XXX旗艦店“00001.'

實際上，1NF是所有關(guān)系型數(shù)據(jù)庫的最基木要求，你在關(guān)系型數(shù)據(jù)庫管理系統(tǒng)

(RDBMS),例如SQLServer.Oracle.MySQL中創(chuàng)建數(shù)據(jù)表的時候，如果數(shù)據(jù)表的設(shè)“不

符合這個最基木的要求，那么操作定是不能成功的。也就是說，只要在RDBMS中已經(jīng)存在

的數(shù)據(jù)表，一定是符合1NF的。

第二范式

2、第二范式2N取心原則：不能存在‘部分函數(shù)依賴”

學(xué)號。姓名.，系名，系主任，修分數(shù)，

1022211101.李小明,經(jīng)濟系.王強?高等數(shù)學(xué)?95.

1022211101.李小明?經(jīng)濟系.王強?大學(xué)英語?，87.

1022211101.李小明?經(jīng)濟系.王強，普通化學(xué)“76.

1022211102.張莉莉.經(jīng)濟系.王強?高等數(shù)學(xué)，72.

1022211102.張莉莉?姓濟系.王海大學(xué)英語〃98.

1022211102.張莉莉?經(jīng)濟系?王^計算機基礎(chǔ).88.

1022511101.高芳芳，法律系.劉玲?，高等數(shù)學(xué)，82-

1022511101.高芳芳，法律系.劉路法學(xué)基哈82.

以匕表格明顯存在,部分依籟。比如,這張表的主健是（學(xué)號,課名），分數(shù)確實完仝依賴了

（學(xué)號，課名）,但是姓名并不完仝依賴丁?（學(xué)號，課名）

學(xué)號“分敢，.

學(xué)號-姓名?系名.系主任?

1022211101-高等數(shù)學(xué)?95.

李小明，經(jīng)濟系?，王備

1022211101-大學(xué)英語?87.1022211101.

1022211101-力通化學(xué)，76-1022211102-張莉莉?經(jīng)濟系.王濟

1022211102-商等效裝72-1022511101.高芳芳“法律系劉玲“

1022211102.大學(xué)獎遇，98

1022211102-計亶機萎》88

1022511101-熹，敷學(xué)?82.以上符合第：范式，去掉部分函數(shù)依賴依賴

1022511101.法學(xué)圣城,82-

第三范式

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

在下面這張表中，存在傳遞函數(shù)依賴：學(xué)號，系名，系主任,

但是系主任推不出學(xué)號。

學(xué)號?姓名系名?,系主任「

1022211101“李小明。經(jīng)濟系，王強.

1022211102^張莉莉，經(jīng)濟系「王強，

1022511101^高芳芳“法律系，劉玲■、

上面表需要再次拆解:

學(xué)號，姓名?、系名系名a系主任「

1022211101^李小明?，經(jīng)濟系?，經(jīng)濟系「王強“

1022211102^張莉莉??經(jīng)濟系.，法律系「劉玲〃

1022511101^高芳芳「法律系，

2.2關(guān)系建模與維度建模

當今的數(shù)據(jù)處理大致可以分成兩大類:聯(lián)機事務(wù)處理OLTP(on-linetransaction

processing）、聯(lián)機分析處理OLAP（On-LineAnalyticalProcessing）（＞OLTP是傳統(tǒng)的關(guān)系型

數(shù)據(jù)庫的主要應(yīng)用，主要是基本的、日常的事務(wù)處理，例如銀行交易。OLAP是數(shù)據(jù)倉庫系

統(tǒng)的主要應(yīng)用，支持復(fù)雜的分析操作，側(cè)重決策支持，并且提供直觀易懂的查詢結(jié)果。二者

的主要區(qū)別對比如下表所示。

對比屬性O(shè)LTPOLAP

讀特性每次查詢只返回少量記錄對大量記錄進行匯總

寫特性隨機、低延時寫入用戶的輸入批量導(dǎo)入

使用場景用戶,JavaEE項目內(nèi)部分析師，為決策提供支持

數(shù)據(jù)表征最新數(shù)據(jù)狀態(tài)隨時間變化的歷史狀態(tài)

數(shù)據(jù)規(guī)模GBTB至I」PB

2.2.1關(guān)系建模

OrderDetailsProductProductSubCatogaryProductCatogary

“OrderLineld

>Productld，ProductSubCatogaryld，ProductCatogaryld

Orderld

ProductNameProductCatogaryldProductCatogaryName

ProDuctld

ProductSubCatogaryldProductSubCatogaryName

SalesAmount

Gender

>Genderld

GenderNsme

關(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)的表都是遵循第三范式的。

圖維度模型示意圖

維度模型如圖所示，主要應(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)各種表整理成兩種:

事實表和維度表兩種。

2.2.2維度建模

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

星型模型、雪花模型

1、星型模型2、雪花模型

杏花模型與星型模型的區(qū)別主要在「維度的層級,標準的雪花模型，比較低近3NF,但是無法完全遵守，因

星型模型維度只行一層，而丐花模型可能會涉及多級.為遵循3NF的性能成本太高。

星座模型

3、星用模型4、模型的選擇

首先就是星座不星座這個只跟數(shù)據(jù)和需求有關(guān)系，跟

設(shè)計沒關(guān)系，不用選擇。

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

目前實際企業(yè)開發(fā)中，不會絕對選擇?種，根據(jù)情況

braocbkey

靈活組合,展至并存《一區(qū)維度和多2?維度都保存）。但

location_key

umts_5old是整體來看,更便向「逑女更少的星￡模型。尤其是

<k>!lan_M>ldHadoop體系，減少Join就是減少Shuffle,性能京距很大。

__MHC

\Meauirck（關(guān)系型數(shù)據(jù)可以依鋸強大的主鍵索引）

星座模型與前兩種情況的區(qū)別是由實表的數(shù)法.星座模里是

基丁多個事實表。

基本上是很多數(shù)據(jù)倉庫的常態(tài),因為很多數(shù)據(jù)倉庫都是多個

本實表的.所以星座不星座只反映是否有多個事實衣,他們之間

是否共享一些維度表。

所以星座模型并不和前兩個模型沖突。

2.3維度表和事實表（重點）

2.3.1維度表

維度表：一般是對事實的描述信息。每一張維表對應(yīng)現(xiàn)實世界中的一個對象或者概念。

例如：用戶、商品、日期、地區(qū)等。

維表的特征：

>維表的范圍很寬（具有多個屬性、列比較多）

>跟事實表相比，行數(shù)相對較?。和ǔ?lt;10萬條

>內(nèi)容相對固定：編碼表

時間維度表：

日期IDdayofweekdayofyear季度節(jié)假日

2020-01-01211元旦

2020-01-02321無

2020-01-03431無

2020-01-04541無

2020-01-05651無

2.3.2事實表

事實表中的每行數(shù)據(jù)代表一個業(yè)務(wù)事件（下單、支付、退款、評價等）?！笆聦崱边@個

術(shù)語表示的是業(yè)務(wù)事件的度量值（可統(tǒng)計次數(shù)、個數(shù)、金額等），例如，2020年5月21日，

宋宋老師在京東發(fā)了250塊錢買了一瓶海狗人參丸。維度表：時間、用戶、商品、商家。事

實表：250塊錢、一瓶

每一個事實表的行包括：具有可加性的數(shù)值型的度量值、與維表相連接的外鍵、通常具

有兩個和兩個以上的外鍵、外鍵之間表示維表之間多對多的關(guān)系。

事實表的特征：

>非常的大

>內(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-83-83-93-10

2.4數(shù)據(jù)倉庫建模（絕對重點）

2.4.1ODS層

1）HDFS用戶行為數(shù)據(jù)

2）HDFS業(yè)務(wù)數(shù)據(jù)

3）針對HDFS上的用戶行為數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)，我們?nèi)绾我?guī)劃處理？

（1）保持數(shù)據(jù)原貌不做任何修改，起到備份數(shù)據(jù)的作用。

（2）數(shù)據(jù)采用壓縮，減少磁盤存儲空間（例如：原始數(shù)據(jù)100G,可以壓縮到10G左

右）

（3）創(chuàng)建分區(qū)表，防止后續(xù)的全表掃描

2.4.2DWD層

DWD層需構(gòu)建維度模型，一般采用星型模型，呈現(xiàn)的狀態(tài)一般為星座模型。

維度建模一般按照以下四個步驟：

選擇業(yè)務(wù)過程一聲明粒度f確認維度一確認事實

(1)選擇業(yè)務(wù)過程

在業(yè)務(wù)系統(tǒng)中，挑選我們感興趣的業(yè)務(wù)線，比如下單業(yè)務(wù)，支付業(yè)務(wù)，退款業(yè)務(wù)，物流

業(yè)務(wù)，一條業(yè)務(wù)線對應(yīng)一張事實表。

如果是中小公司，盡量把所有業(yè)務(wù)過程都選擇。

如果是大公司(1000多張表)，選擇和需求相關(guān)的業(yè)務(wù)線。

(2)聲明粒度

數(shù)據(jù)粒度指數(shù)據(jù)倉庫的數(shù)據(jù)中保存數(shù)據(jù)的細化程度或綜合程度的級別。

聲明粒度意味著精確定義事實表中的一行數(shù)據(jù)表示什么，應(yīng)該盡可能選擇最小粒度，以

此來應(yīng)各種各樣的需求。

典型的粒度聲明如下：

訂單當中的每個商品項作為下單事實表中的一行，粒度為每次。

每周的訂單次數(shù)作為一行，粒度為每周。

每月的訂單次數(shù)作為一行，粒度為每月。

如果在DWD層粒度就是每周或者每月，那么后續(xù)就沒有辦法統(tǒng)計細粒度的指標了。所

以建議采用最小粒度。

(3)確定維度

維度的主要作用是描述業(yè)務(wù)是事實，主要表示的是“誰，何處，何時”等信息。

確定維度的原則是：后續(xù)需求中是否要分析相關(guān)維度的指標。例如，需要統(tǒng)計，什么時

間下的訂單多，哪個地區(qū)下的訂單多，哪個用戶下的訂單多。需要確定的維度就包括：時間

維度、地區(qū)維度、用戶維度。

維度表：需要根據(jù)維度建模中的星型模型原則進行維度退化。

(4)確定事實

此處的“事實”一詞，指的是業(yè)務(wù)中的度量值(次數(shù)、個數(shù)、件數(shù)、金額，可以進行累

加)，例如訂單金額、下單次數(shù)等。

在DWD層，以業(yè)務(wù)過程為建模驅(qū)動，基于每個具體業(yè)務(wù)過程的特點，構(gòu)建最細粒度的

明細層事實表。事實表可做適當?shù)膶挶砘幚怼?/p>

事實表和維度表的關(guān)聯(lián)比較靈活，但是為了應(yīng)對更復(fù)雜的業(yè)務(wù)需求，可以將能關(guān)聯(lián)上的

表盡量關(guān)聯(lián)上。如何判斷是否能夠關(guān)聯(lián)上呢？在業(yè)務(wù)表關(guān)系圖中，只要兩張表能通過中間表

能夠關(guān)聯(lián)上，就說明能關(guān)聯(lián)上。

時間用戶地區(qū)商品優(yōu)惠券活動編碼度量值

訂單7VVV件數(shù)/金額

訂單詳情VVV件數(shù)/金額

支付VV金額

加購VVV件數(shù)/金額

收藏VVV個數(shù)

評價VVV個數(shù)

退款VVV件數(shù)/金額

優(yōu)惠券領(lǐng)用VVV個數(shù)

至此，數(shù)據(jù)倉庫的維度建模已經(jīng)完畢，DWD層是以'業(yè)務(wù)過程為驅(qū)動。

DWS層、DWT層和ADS層都是以需求為驅(qū)動，和維度建模已經(jīng)沒有關(guān)系了。

DWS和DWT都是建寬表，按照主題去建表。主題相當于觀察問題的角度。對應(yīng)著維

度表。

數(shù)據(jù)倉庫

orderstatus」og||Activ也order|

^favoTjnfd

order_info

訂單事實表［收藏事實表

時問堆度農(nóng)

獲取省份附

uase_regionoase_pro\4nce

地區(qū)維度表

order_detailcoupon_use

訂單譯情事實表base_categoryi優(yōu)意券領(lǐng)用事實表

base_category2

spu」nfobase_category3

商ffii維度表

paymentjnfocoupon_in(o

｛寸事實表

世圖卷雄由表

Act)Mty_info

活動給由農(nóng)

user_info

order_redund_info

躡靛事實表

加齷實表用戶也5表

2.4.3DWS層

DWS層統(tǒng)計各個主題對象的當天行為，服務(wù)于DWT層的主題寬表。

(1)問題引出：兩個需求，統(tǒng)計每個省份訂單的個數(shù)、統(tǒng)計每個省份訂單的總金額

(2)處理辦法：都是將省份表和訂單表進行join,groupby省份，然后計算。相當于類

似的需求重復(fù)計算了兩次。

那怎么設(shè)計能避免重復(fù)計算呢？

地區(qū)寬表的字段設(shè)計為：下單次數(shù)、下單金額、支付次數(shù)、支付金額等。只需要和每個

事實表一次join。

(3)總結(jié)：

需要建哪些表：以維度為基準，去關(guān)聯(lián)對應(yīng)多個事實表

寬表里面的字段:是站在不同維度的角度去看事實表,重點關(guān)注事實表聚合后的度量值。

(4)DWS層寬表包括：每日設(shè)備行為、每日會員行為、每日商品行為、每日活動統(tǒng)計、

每日地區(qū)統(tǒng)計。

2.4.4DWT層

DWT層統(tǒng)計各個主題對象的累積行為。

(1)需要建哪些表：和DWS層一樣。以維度為基準，去關(guān)聯(lián)對應(yīng)多個事實表

(2)寬表里面的字段：我們站在維度表的角度去看事實表，重點關(guān)注事實表度量值的

累積值、事實表行為的首次和末次時間。

例如，訂單事實表的度量值是下單次數(shù)、下單金額。訂單事實表的行為是下單。我們站

在用戶維度表的角度去看訂單事實表，重點關(guān)注訂單事實表至今的累積下單次數(shù)、累積下單

金額和某時間段內(nèi)的累積次數(shù)、累積金額，以及關(guān)注下單行為的首次時間和末次時間。

order_status_logActivity,order例如：用戶行為主題寬表字段，都是首次、末次時間、累積至今的度?值、

訂單狀態(tài)袤；醐訂嵌聯(lián)表

累積某個時間段的度量值

createexternaltaWedwt_user_topic

orderjnfo

訂單事實表useridstringcomment'fflpid',

order_date_firststringcomment省次下單時恒T,

orderdatelaststringcomment:卞瑜3間，，favorjnfo

order_countbigintcomment'累積卡簞次數(shù)*,收藏事實表

獲取省份汨

order_amountdecimal(16,2)comment'累積下單金額\

order_last_30d_countbigintcomment日下期欠數(shù)1

order_last_30d_amountbigintcomment'最近30日卡星金額1,

order_detailpaymentdatejfirststringcomment'首次支付時間'，

'末次支付時間coupon_use

訂單詳情事實表payment_date_laststringcomment優(yōu)惠券領(lǐng)用事實表

payment_countdecimal(16,2)comment嚎積支付次數(shù)

paymentamountdecimal(16,2)comment'聚積支H金鎰.

payment_last_30d_countdecimal(16,2)comment

payment_last_30d_amountdecimal(16,2)comment日支付金額

payment_infoCOMMENT'用戶翔群'commentjnfo

支付小息評價事實表

user_info

cartjnfoorder_redund_info

加麗事實表用戶制度表一退款事實事實表

（4）DWS層寬表包括：每日設(shè)備行為、每日會員行為、每日商品行為、每日活動統(tǒng)計、

每日地區(qū)統(tǒng)計。

2.4.5ADS層

對電商系統(tǒng)各大主題指標分別進行分析。

第3章數(shù)倉搭建-ODS層

1）保持數(shù)據(jù)原貌不做任何修改，起到備份數(shù)據(jù)的作用。

2）數(shù)據(jù)采用LZO壓縮，減少磁盤存儲空間。100G數(shù)據(jù)可以壓縮到10G以內(nèi)。

3）創(chuàng)建分區(qū)表，防止后續(xù)的全表掃描，在企業(yè)開發(fā)中大量使用分區(qū)表。

4）創(chuàng)建外部表。在企業(yè)開發(fā)中，除了自己用的臨時表，創(chuàng)建內(nèi)部表外，絕大多數(shù)場景

都是創(chuàng)建外部表。

3.1Hive環(huán)境準備

3.1.1Hive引擎簡介

Hive引擎包括：默認MR、tez、spark

HiveonSpark：Hive既作為存儲元數(shù)據(jù)又負責SQL的解析優(yōu)化，語法是HQL語法，執(zhí)

行引擎變成了Spark,Spark負責采用RDD執(zhí)行。

SparkonHive:Hive只作為存儲元數(shù)據(jù)，Spark負責SQL解析優(yōu)化，語法是SparkSQL

語法，Spark負責米用RDD執(zhí)行。

3.1.2HiveonSpark配置

1）兼容性說明

注意：官網(wǎng)下載的Hive3.1.2和Spark3.0.0默認是不兼容的。因為Hive3.1.2支持的Spark

版本是2.4.5,所以需要我們重新編譯Hive3.1.2版本。

編譯步驟：官網(wǎng)下載Hive3.L2源碼，修改pom文件中引用的Spark版本為3.0.0,如果

編譯通過，直接打包獲取jar包。如果報錯，就根據(jù)提示，修改相關(guān)方法，直到不報錯，打

包獲取jar包。

2）在Hive所在節(jié)點部署Spark

如果之前已經(jīng)部署了Spark,則該步驟可以跳過，但要檢查SPARK_HOME的環(huán)境變量

配置是否正確。

（1）Spark官網(wǎng)下載jar包地址：

http:〃/downloads.hlm】

（2）上傳并解壓解壓spark-3.0.0-bin-hadoop3.2.tgz

[atguigu0hadooplO2software]$tar-zxvfspark-3.0.0-bin-hadoop3.2.tgz-C

/opt/module/

[atguigu0hadooplO2software]$mv/opt/module/spark-3.0.0-bin-hadoop3.2

/opt/module/spark

（3）配置SPARK_HOME環(huán)境變量

[atguigu@hadoopl02software]$sudovim/etc/profile.d/my_env.sh

添加如下內(nèi)容

#SPARK_HOME

exportSPARK_HOME=/opt/module/spark

exportPATH=$PATH:$SPARK_HOME/bin

source使其生效

[atguigu@hadoopl02software]$source/etc/profile.d/my_env.sh

（4）新建spark配置文件

[atguigu@hadoopl02software]$vim/opt/module/hive/conf/spark-

defaults.conf

添加如下內(nèi)容（在執(zhí)行任務(wù)時，會根據(jù)如下參數(shù)執(zhí)行）

spark.masteryarn

spark.eventLog.enabledtrue

spark.eventLog.dirhdfs://hadoopl02:8020/spark-history

spark.executor.memoryig

spark.driver.memory1g

（5）在HDFS創(chuàng)建如下路徑，用于存儲歷史日志

[atguigu@hadoopl02software]$hadoopfs-mkdir/spark-history

3）向HDFS上傳Spark純凈版jar包

說明1：由于Spark3.0.0非純凈版默認支持的是hive2.3.7版本，直接使用會和安裝的

Hive3.l.2出現(xiàn)兼容性問題。所以采用Spark純凈版jar包，不包含hadoop和hive相關(guān)依賴,

避免沖突。

說明2：Hive任務(wù)最終由Spark來執(zhí)行，Spark任務(wù)資源分配由Yarn來調(diào)度，該任務(wù)有

可能被分配到集群的任何一個節(jié)點。所以需要將Spark的依賴上傳到HDFS集群路徑，這樣

集群中任何一個節(jié)點都能獲取到。

(1)上傳并解壓spark-3.0.0-bin-without-hadoop.tgz

(atguigu@hadoopl02software]$tar-zxvf/opt/software/spark-3.0.0-bin-

without-hadoop.tgz

(2)上傳Spark純凈版jar包到HDFS

[atguigu@hadoopl02software]$hadoopfs-mkdir/spark-jars

[atguigu@hadoopl02software]$hadoopfs-putspark-3.0.O-bin-without-

hadoop/jars/*/spark-jars

4)修改hive?site.xml文件

[atguigu@hadoopl02?]Svim/opt/module/hive/conf/hive-site.xml

添加如下內(nèi)容

<!―Spark依賴位置(注意：端口號8020必須和namenode的端口號一致)一>

<property>

<name>spark.yarn.jars</name>

<value>hdfs://hadoopl02:8020/spark-jars/*</value>

</property>

<!—Hive執(zhí)行弓I擎—>

<property>

<name>hive.execution.engine</name>

<value>spark</value>

</property>

<!—Hive和Spark連接超時時間一>

<property>

<name>hive.spark.client.connect.timeout</name>

<value>10000ms</value>

</property>

注意：hive.spark.client.connect.timeout的默認值是1000ms,如果執(zhí)行hive的insert語句

時，拋如下異常，可以調(diào)大該參數(shù)到10000ms

FAILED:SemanticExceptionFailedtogetasparksession:

org.apache.hadoop.hive.ql.metadata.HiveException:FailedtocreateSpark

clientforSparksessiond9e0224c-3dl4-4bf4-95bc-ee3ec56df48e

3.1.3HiveonSpark測試

(1)啟動hive客戶端

[atguigu@hadoopl02hive]$bin/hive

(2)創(chuàng)建一張測試表

hive(default)>createtablestudent(idint,namestring);

(3)通過insert測試效果

hive(default)>insertintotablestudentvalues(1,1abc1);

若結(jié)果如下，則說明配置成功

hive(default)>insertintotablestudentvalues(l>'abc');

QueryID=atguigu_20200719001740_b025ael3-c573-4a68-9b74-50a4d018664b

Totaljobs=1

LaunchingJob1outof1

Inordertochangetheaverageloadforareducer(inbytes):

sethive.exec.reducers.bytes.per.reducer=<number>

Inordertolimitthemaximumnumberofreducers:

sethive.exec.reducers.max=<number>

Inordertosetaconstantnumberofreducers:

setmapreduce.job.reduces=<number>

STAGESATTEMPTSTATUSTOTALCOMPLETEDRUNNINGPENDINGFAILED

Stage-20FINISHED11000

Stage-30FINISHED11000

STAGES:02/02[==========================>>]100%ELAPSEDTIME:1.01s

Sparkjob[l]finishedsuccessfullyin1.01second(s)

Loadingdatatotabledefault.stud