從ODS層到ADS層，數(shù)據(jù)是越來越少的，數(shù)據(jù)分析都是以大量的數(shù)據(jù)為基礎，對數(shù)據(jù)進行匯總聚合運算，抽絲剝繭，越往后數(shù)據(jù)的匯總層度越高，最后得到匯總的指標。
數(shù)倉分層原因
- 將復雜問題簡化，將復雜的任務分解成多層來完成，每一層只處理簡單的任務，方便定位問題；
- 減少重復開發(fā)，規(guī)范數(shù)據(jù)分層，通過中間層數(shù)據(jù)，能夠減少極大的重復計算，增加一次計算結果的復用性；
- 隔離原始數(shù)據(jù)，不論是數(shù)據(jù)的異常還是數(shù)據(jù)的敏感性，使真實數(shù)據(jù)與統(tǒng)計數(shù)據(jù)解耦開；
數(shù)倉主體就是DWD(data warehouse detail：數(shù)據(jù)明細層),DWS(data warehouse service：服務數(shù)據(jù)層)，DWT(data warehouse topic:數(shù)據(jù)主題層)。其中DWS,DWT兩層都是匯總數(shù)據(jù)，從DWD來。
各分層簡介
ODS
存放原始數(shù)據(jù)，原始數(shù)據(jù)保持原狀。原始數(shù)據(jù)一類是日志，一類是業(yè)務數(shù)據(jù)。業(yè)務數(shù)據(jù)從mysql導入進來，本身就是結構化的，以具體分隔符分割，可以直接記載到對應數(shù)據(jù)庫。但是日志數(shù)據(jù)就不行，是一行一行的字符串，需要將字符串解析成可以導入hive的數(shù)據(jù)格式。
即ODS層主要是對日志進行解析，要考慮解析成多少張表，按照什么邏輯去解析？定下邏輯后，解析的SQL怎么寫？
業(yè)務數(shù)據(jù)主要就是怎么建模？所謂的建模就是明確要建哪些表，明確表中有哪些字段，表與表之間有什么樣的關聯(lián)？建模有一些指導思想，比如維度建模，關系建模，數(shù)倉一般采用維度建模。
DWD
明細層是數(shù)倉中關鍵的一層，是數(shù)倉的地基。明細數(shù)據(jù)從ODS層來，明細數(shù)據(jù)就是最原始最詳細的數(shù)據(jù)，即一行數(shù)據(jù)指代依次業(yè)務行為，比如說order_info，一行數(shù)據(jù)就是依次下訂單行為，該行數(shù)據(jù)就是明細數(shù)據(jù)。
該層需要構建維度模型，一般采用雪花模型。
維度建模一般按照以下四個步驟：
選擇業(yè)務過程→聲明粒度→確認維度→確認事實
- 選擇業(yè)務過程（有幾張事實表）
在業(yè)務系統(tǒng)中，挑選我們感興趣（后面會分析的）的業(yè)務線，比如下單業(yè)務，支付業(yè)務，退款業(yè)務，物流業(yè)務，一條業(yè)務線對應一張事實表。
如果是中小公司，盡量把所有業(yè)務過程都選擇。
如果是大公司（1000多張表），選擇和需求相關的業(yè)務線。
- 聲明粒度
數(shù)據(jù)粒度指數(shù)據(jù)倉庫的數(shù)據(jù)中保存數(shù)據(jù)的細化程度或綜合程度的級別。
聲明粒度意味著精確定義事實表中的一行數(shù)據(jù)表示什么，應該盡可能選擇最小粒度，以此來應各種各樣的需求。
典型的粒度聲明如下：
訂單事實表中一行數(shù)據(jù)表示的是一個訂單中的一個商品項。
支付事實表中一行數(shù)據(jù)表示的是一個支付記錄。
- 確定維度
維度的主要作用是描述業(yè)務是事實，主要表示的是“誰，何處，何時”等信息。
確定維度的原則是：后續(xù)需求中是否要分析相關維度的指標。例如，需要統(tǒng)計，什么時間下的訂單多，哪個地區(qū)下的訂單多，哪個用戶下的訂單多。需要確定的維度就包括：時間維度、地區(qū)維度、用戶維度。
- 確定事實
此處的“事實”一詞，指的是業(yè)務中的度量值（次數(shù)、個數(shù)、件數(shù)、金額，可以進行累加），例如訂單金額、下單次數(shù)等。
在DWD層，以業(yè)務過程為建模驅動，基于每個具體業(yè)務過程的特點，構建最細粒度的明細層事實表。事實表可做適當?shù)膶挶砘幚怼?/p>
事實表和維度表的關聯(lián)比較靈活，但是為了應對更復雜的業(yè)務需求，可以將能關聯(lián)上的表盡量關聯(lián)上。如何判斷是否能夠關聯(lián)上呢？在業(yè)務表關系圖中，只要兩張表能通過中間表能夠關聯(lián)上，就說明能關聯(lián)上。
（補充：申明粒度那有了訂單詳情為什么還要有訂單信息？因為考慮性能，假設一個需求訂單和訂單詳情都可完成，但是訂單詳情需要一定程度聚合才能得到訂單，所以直接使用訂單可以減少性能開銷。）
| 時間 | 用戶 | 地區(qū) | 商品 | 優(yōu)惠券 | 活動 | 編碼 | 度量值 |
|---|
至此，數(shù)據(jù)倉庫的維度建模已經(jīng)完畢，DWD層是以業(yè)務過程為驅動。
DWS
數(shù)據(jù)匯總層：DWS，匯總層有些匯總的比較輕，比如按天匯總用戶訂單表即可得到一天用戶下單數(shù)。即一行信息代表一個主題對象（用戶）一天的匯總行為。
DWT
有些匯總程度比較大，比如按歷史積累數(shù)據(jù)匯總用戶訂單表，即可得到用戶歷史下單記錄數(shù)。即一行信息代表一個主題對象（用戶）歷史累計的行為匯總。
DWS和DWT都是建寬表，按照主題去建表。主題相當于觀察問題的角度。對應著維度表。
寬表層
在維度表中，以事實表為核心，到了寬表層則以維度表為核心。
DWS層和DWT層統(tǒng)稱寬表層，這兩層的設計思想大致相同，通過以下案例進行闡述。
- 問題引出：兩個需求，統(tǒng)計每個省份訂單的個數(shù)、統(tǒng)計每個省份訂單的總金額
- 處理辦法：都是將省份表和訂單表進行join，group by省份，然后計算。同樣數(shù)據(jù)被計算了兩次，實際上類似的場景還會更多。
那怎么設計能避免重復計算呢？
針對上述場景，可以設計一張地區(qū)寬表，其主鍵為地區(qū)ID，字段包含為：下單次數(shù)、下單金額、支付次數(shù)、支付金額等。上述所有指標都統(tǒng)一進行計算，并將結果保存在該寬表中，這樣就能有效避免數(shù)據(jù)的重復計算。 - 總結：
- 需要建哪些寬表：以維度為基準。
- 寬表里面的字段：是站在不同維度的角度去看事實表，重點關注事實表聚合后的度量值。
- DWS和DWT層的區(qū)別：DWS層存放的所有主題對象當天的匯總行為，例如每個地區(qū)當天的下單次數(shù)，下單金額等，DWT層存放的是所有主題對象的累積行為，例如每個地區(qū)最近７天（１５天、３０天、６０天）的下單次數(shù)、下單金額等。
ADS
ADS層用于數(shù)倉后的應用比如報表、用戶畫像、機器學習等。通過ODS=>DWD=>DWT=>ADS得到應用需要的數(shù)據(jù)。
數(shù)倉維度建模
維度模型如圖所示，主要應用于OLAP系統(tǒng)中，通常以某一個事實表為中心進行表的組織，主要面向業(yè)務，特征是可能存在數(shù)據(jù)的冗余，但是能方便的得到數(shù)據(jù)。
關系模型雖然冗余少，但是在大規(guī)模數(shù)據(jù)，跨表分析統(tǒng)計查詢過程中，會造成多表關聯(lián)，這會大大降低執(zhí)行效率。所以通常我們采用維度模型建模，把相關各種表整理成兩種：事實表和維度表兩種。
維度表和事實表
維度表
維度表：一般是對事實的描述信息。每一張維表對應現(xiàn)實世界中的一個對象或者概念。 例如：用戶、商品、日期、地區(qū)等。
維表的特征：
- 維表的范圍很寬（具有多個屬性、列比較多）
- 跟事實表相比，行數(shù)相對較?。和ǔ?lt; 10萬條
- 內容相對固定：編碼表
例子：時間維度表：
| 日期ID | day of week | day of year | 季度 | 節(jié)假日 |
|---|
事實表
事實表中的每行數(shù)據(jù)代表一個業(yè)務事件（下單、支付、退款、評價等）?！笆聦崱边@個術語表示的是業(yè)務事件的度量值（可統(tǒng)計次數(shù)、個數(shù)、金額等）**，例如，2020年5月21日，宋宋老師在京東花了250塊錢買了一瓶海狗人參丸。維度表：時間、用戶、商品、商家。事實表：250塊錢、一瓶。
每一個事實表的行包括：具有可加性的數(shù)值型的度量值、與維表相連接的外鍵，通常具有兩個和兩個以上的外鍵。
事實表的特征：
- 非常的大
- 內容相對的窄：列數(shù)較少（主要是外鍵id和度量值）
- 經(jīng)常發(fā)生變化，每天會新增加很多。
事務型事實表
以每個事務或事件為單位，例如一個銷售訂單記錄，一筆支付記錄等，作為事實表里的一行數(shù)據(jù)。一旦事務被提交，事實表數(shù)據(jù)被插入，數(shù)據(jù)就不再進行更改，其更新方式為增量更新。
周期型快照事實表（全量表）
周期型快照事實表中不會保留所有數(shù)據(jù)，只保留固定時間間隔的數(shù)據(jù)，例如每天或者每月的銷售額，或每月的賬戶余額等。
例如購物車，有加減商品，隨時都有可能變化，但是我們更關心每天結束時這里面有多少商品，方便我們后期統(tǒng)計分析。
比如加購物車、收藏夾表，數(shù)據(jù)亮大，既有更新又有新增，應該采用新增及變化策略。但是由于這兩張表是周期性的快照事實表，所以我們采用全量表。
累積型快照事實表（周期型業(yè)務）
累計快照事實表用于跟蹤業(yè)務事實的變化。例如，數(shù)據(jù)倉庫中可能需要累積或者存儲訂單從下訂單開始，到訂單商品被打包、運輸、和簽收的各個業(yè)務階段的時間點數(shù)據(jù)來跟蹤訂單聲明周期的進展情況。當這個業(yè)務過程進行時，事實表的記錄也要不斷更新。
新增及變化表需要提取新增變化數(shù)據(jù)與原數(shù)據(jù)進行整合。
| 訂單id | 用戶id | 下單時間 | 打包時間 | 發(fā)貨時間 | 簽收時間 | 訂單金額 |
|---|
拉鏈表
當表中的數(shù)據(jù)每日既有新增，也可能修改，但是修改的頻率并不高，屬于緩慢變化維度時，可以采用拉鏈表來存儲用戶維度數(shù)據(jù)，以解決數(shù)據(jù)重復存儲。
拉鏈表簡介
一行數(shù)據(jù)指代用戶的一個狀態(tài)，有一個開始時間和結束日期表示有效狀態(tài)。
為什么要做拉鏈表
如何使用拉鏈表
拉鏈表形成過程
拉鏈表需要做一次初始化，將全量數(shù)據(jù)拉取到拉鏈表。
保證保證用戶狀態(tài)時間不重復。
拉鏈表制作過程圖：
這里的臨時表，是考慮避免在覆蓋數(shù)據(jù)的時候元數(shù)據(jù)丟失，保證數(shù)據(jù)的安全性；hive 的insert overwrite會先往臨時路徑寫數(shù)據(jù)，寫完之后再修改臨時路徑名字，刪除原來路徑的數(shù)據(jù)，這也保證了數(shù)據(jù)的安全性。文章來源：http://www.zghlxwxcb.cn/news/detail-807580.html
原文鏈接：數(shù)據(jù)倉庫從0到1之數(shù)倉建模理論 - 知乎 (zhihu.com)https://link.zhihu.com/?target=https%3A//www.everweekup.com/2021/06/30/%25E6%2595%25B0%25E6%258D%25AE%25E4%25BB%2593%25E5%25BA%2593%25E4%25B9%258B%25E5%25BB%25BA%25E6%25A8%25A1%25E7%2590%2586%25E8%25AE%25BA/侵權刪！文章來源地址http://www.zghlxwxcb.cn/news/detail-807580.html
到了這里，關于數(shù)據(jù)倉庫從0到1之數(shù)倉建模理論的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！
