數倉分層

從ODS層到ADS層，資料是越來越少的，資料分析都是以大量的資料為基礎，對資料進行彙總聚合運算，抽絲剝繭，越往後資料的彙總層度越高，最後得到彙總的指標。

數倉分層原因

將複雜問題簡化，將複雜的任務分解成多層來完成，每一層只處理簡單的任務，方便定位問題；

減少重複開發，規範

資料分層

，透過中間層資料，能夠減少極大的重複計算，增加一次計算結果的複用性；

隔離原始資料，不論是資料的異常還是資料的敏感性，使真實資料與統計資料解耦開；

數倉主體就是DWD（data warehouse detail：資料明細層），DWS（data warehouse service：服務資料層），DWT（data warehouse topic：資料主題層）。其中

DWS,DWT

兩層都是彙總資料，從

DWD

來。

各分層簡介

ODS

存放原始資料，原始資料保持原狀。原始資料一類是日誌，一類是業務資料。業務資料從mysql匯入進來，本身就是結構化的，以具體分隔符分割，可以直接記載到對應資料庫。但是日誌資料就不行，是一行一行的字串，需要將字串解析成可以匯入hive的資料格式。

即ODS層主要是對日誌進行解析，要考慮解析成多少張表，按照什麼邏輯去解析？定下邏輯後，解析的SQL怎麼寫？

業務資料主要就是怎麼建模？所謂的建模就是明確要建哪些表，明確表中有哪些欄位，表與表之間有什麼樣的關聯？建模有一些指導思想，比如

維度建模

，關係建模，數倉一般採用維度建模。

DWD

明細層是數倉中關鍵的一層，是數倉的地基。明細資料從ODS層來，明細資料就是最原始最詳細的資料，即一行資料指代依次業務行為，比如說order_info，一行資料就是依次下訂單行為，該行資料就是明細資料。

該層需要構建維度模型，一般採用雪花模型。

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

選擇業務過程→宣告粒度→確認維度→確認事實

選擇業務過程（有幾張事實表）

在業務系統中，挑選我們感興趣（後面會分析的）的業務線，比如下單業務，支付業務，退款業務，物流業務，一條業務線對應一張事實表。

如果是中小公司，儘量把所有業務過程都選擇。

如果是大公司（1000多張表），選擇和需求相關的業務線。

宣告

粒度

資料粒度指資料倉庫的資料中儲存資料的細化程度或綜合程度的級別。

宣告粒度意味著精確定義事實表中的一行資料表示什麼，應該儘可能選擇

最小粒度

，以此來應各種各樣的需求。

典型的粒度宣告如下：

訂單事實表中一行資料表示的是一個訂單中的一個商品項。

支付事實表中一行資料表示的是一個支付記錄。

確定維度

維度

的主要作用是描述業務是事實，主要表示的是“誰，何處，何時”等資訊。

確定維度的原則是：後續需求中是否要分析相關維度的指標。例如，需要統計，什麼時間下的訂單多，哪個地區下的訂單多，哪個使用者下的訂單多。需要確定的維度就包括：時間維度、地區維度、

使用者維度

。

確定事實

此處的“事實”一詞，指的是業務中的度量值（次數、個數、件數、金額，可以進行累加），例如訂單金額、下單次數等。

在DWD層，以

業務過程

為建模驅動，基於每個具體業務過程的特點，構建

最細粒度

的明細層事實表。事實表可做適當的寬表化處理。

事實表和維度表的關聯比較靈活，但是為了應對更復雜的業務需求，可以將能關聯上的表儘量關聯上。如何判斷是否能夠關聯上呢？在業務表關係圖中，只要兩張表能透過中間表能夠關聯上，就說明能關聯上。

（補充：申明粒度那有了訂單詳情為什麼還要有訂單資訊？因為考慮效能，假設一個需求訂單和訂單詳情都可完成，但是訂單詳情需要一定程度

聚合

才能得到訂單，所以直接使用訂單可以減少效能開銷。）

時間

使用者

地區

商品

優惠券

活動

編碼

度量值

至此，資料倉庫的維度建模已經完畢，DWD層是以業務過程為驅動。

DWS

資料彙總層：DWS，彙總層有些彙總的比較輕，比如按天彙總使用者訂單表即可得到一天使用者下單數。即一行資訊代表一個主題物件（使用者）一天的彙總行為。

DWT

有些彙總程度比較大，比如按歷史積累資料彙總使用者訂單表，即可得到使用者歷史下單記錄數。即一行資訊代表一個主題物件（使用者）歷史累計的行為彙總。

DWS和DWT都是建寬表，按照主題去建表。主題相當於觀察問題的角度。對應著維度表。

寬表層

在維度表中，以事實表為核心，到了寬表層則以維度表為核心。

DWS層和DWT層統稱

寬表層

，這兩層的設計思想大致相同，透過以下案例進行闡述。

問題引出：兩個需求，統計每個省份訂單的個數、統計每個省份訂單的總金額

處理辦法：都是將省份表和訂單表進行join，group by省份，然後計算。同樣資料被計算了兩次，實際上類似的場景還會更多。

那怎麼設計能避免

重複計算

呢？

針對上述場景，可以設計一張地區寬表，其主鍵為地區ID，欄位包含為：下單次數、下單金額、支付次數、支付金額等。上述所有指標都統一進行計算，並將結果儲存在該寬表中，這樣就能有效避免資料的重複計算。

總結：

需要建哪些寬表：以維度為基準。

寬表裡面的欄位：是站在不同維度的角度去看事實表，重點關注事實表聚合後的度量值。

DWS和DWT層的區別：DWS層存放的所有主題物件當天的彙總行為，例如每個地區當天的下單次數，下單金額等，DWT層存放的是所有主題物件的累積行為，例如每個地區最近７天（１５天、３０天、６０天）的下單次數、下單金額等。

ADS

ADS層用於數倉後的應用比如報表、使用者畫像、

機器學習

等。透過ODS=>DWD=>DWT=>ADS得到應用需要的資料。

數倉維度建模

維度模型如圖所示，主要應用於OLAP系統中，通常以某一個事實表為中心進行表的組織，主要面向業務，特徵是可能存在資料的冗餘，但是能方便的得到資料。

關係模型雖然冗餘少，但是在大規模資料，跨表分析統計查詢過程中，會造成多表關聯，這會大大降低執行效率。所以通常我們採用

維度模型建模

，把相關各種表整理成兩種：事實表和維度表兩種。

維度表和事實表

維度表

維度表

：一般是對事實的

描述資訊

。每一張維表對應現實世界中的一個物件或者概念。 例如：使用者、商品、日期、地區等。

維表的特徵：

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

跟事實表相比，行數相對較小：通常< 10萬條

內容相對固定：編碼表

例子：時間維度表：

日期ID

day of week

day of year

季度

節假日

事實表

事實表中的

每行資料代表一個業務事件（下單、支付、退款、評價等）

。“事實”這個術語表示的是業務事件的

度量值（可統計次數、個數、金額等）**，例如，2020年5月21日，宋宋老師在京東花了250塊錢買了一瓶海狗人參丸。維度表：時間、使用者、商品、商家。事實表：250塊錢、一瓶。

每一個事實表的行包括：具有可加性的數值型的度量值、與

維表相連線的外來鍵

，通常具有

兩個和兩個以上的外來鍵

。

事實表的特徵：

非常的大

內容相對的窄：列數較少（主要是外來鍵id和度量值）

經常發生變化，每天會新增加很多。

事務型事實表

以

每個事務或事件為單位

，例如一個銷售訂單記錄，一筆支付記錄等，作為事實表裡的一行資料。一旦事務被提交，事實表資料被插入，資料就不再進行更改，其更新方式為增量更新。

週期型快照事實表（全量表）

週期型快照事實表中

不會保留所有資料

，

只保留固定時間間隔的資料

，例如每天或者每月的銷售額，或每月的賬戶餘額等。

例如購物車，有加減商品，隨時都有可能變化，但是我們更關心每天結束時這裡面有多少商品，方便我們後期統計分析。

比如加購物車、收藏夾表，資料亮大，既有更新又有新增，應該採用新增及變化策略。但是由於這兩張表是週期性的快照事實表，所以我們採用全量表。

累積型快照事實表（週期型業務）

累計快照事實表用於跟蹤業務事實的變化。

例如，資料倉庫中可能需要累積或者儲存訂單從下訂單開始，到訂單商品被打包、運輸、和簽收的各個業務階段的時間點資料來跟蹤訂單宣告週期的進展情況。當這個業務過程進行時，事實表的記錄也要不斷更新。

新增及變化表需要提取新增變化資料與原資料進行整合。

訂單id

使用者id

下單時間

打包時間

發貨時間

簽收時間

訂單金額

拉鍊表

當表中的資料每日既有新增，也可能修改，但是修改的頻率並不高，屬於緩慢變化維度時，可以採用拉鍊表來儲存使用者維度資料，以解決資料重複儲存。

拉鍊表簡介

一行資料指代使用者的一個狀態，有一個開始時間和結束日期表示有效狀態。

為什麼要做拉鍊表

如何使用拉鍊表

拉鍊表形成過程

拉鍊表需要做一次初始化，將全量資料拉取到拉鍊表。

保證保證使用者狀態時間不重複。

拉鍊表製作過程圖：

這裡的臨時表，是考慮避免在覆蓋資料的時候元資料丟失，保證資料的安全性；hive 的insert overwrite會先往臨時路徑寫資料，寫完之後再修改臨時路徑名字，刪除原來路徑的資料，這也保證了資料的安全性。

今日分享就到這裡，後續會補充每個維度建模的具體例項~