項目實戰從0到1之spark（31）大數據項目之電商數倉（總結）（一）：系統業務數據倉庫

第1章 電商業務與數據結構簡介
1.1 電商業務流程   


1.2 電商常識（SKU、SPU）

• SKU=Stock Keeping Unit（庫存量基本單位）。如今已經被引伸爲產品統一編號的簡稱，每種產品均對應有惟一的SKU號。
• SPU(Standard Product Unit)：是商品信息聚合的最小單位，是一組可複用、易檢索的標準化信息集合。

好比，我們購買一臺iPhoneX手機，iPhoneX手機就是一個SPU，可是你購買的時候，不多是以iPhoneX手機爲單位買的，商家也不可能以iPhoneX爲單位記錄庫存SKU。必需要以什麼顏色什麼版本的iPhoneX爲單位。好比，你購買的是一臺銀色、128G內存的、支持聯通網絡的iPhoneX，商家也會以這個單位來記錄庫存數。那這個更細緻的單位就叫庫存單元（SKU）。

那SPU又是幹什麼的呢？




SPU表示一類商品。好處就是：能夠共用商品圖片，海報、銷售屬性等。
1.3 電商表結構


1.3.1 訂單表（order_info）


1.3.2 訂單詳情表（order_detail）

1.3.3 商品表


1.3.4 用戶表


1.3.5 商品一級分類表


1.3.6 商品二級分類表


1.3.7 商品三級分類表


1.3.8 支付流水錶



第2章 數倉理論（面試重點）
2.1 表的分類
2.1.1 實體表
實體表，通常是指一個現實存在的業務對象，好比用戶，商品，商家，銷售員等等。
用戶表：


2.1.2 維度表
維度表，通常是指對應一些業務狀態，編號的解釋表。也能夠稱之爲碼錶。
好比地區表，訂單狀態，支付方式，審批狀態，商品分類等等。




2.1.3 事務型事實表
事務型事實表，通常指隨着業務發生不斷產生數據。特色是一旦發生不會再變化。
通常好比，交易流水，操做日誌，出庫入庫記錄等等。



2.1.4 週期型事實表
週期型事實表，通常指隨着業務發生不斷產生變化(更新, 新增)的數據。
與事務型不一樣的是，數據會隨着業務週期性的推動而變化。
好比訂單，其中訂單狀態會週期性變化。再好比，請假、貸款申請，隨着批覆狀態在週期性變化。

訂單表：


2.2 同步策略
數據同步策略的類型包括：全量表、增量表、新增及變化表、拉鍊表

• 全量表：存儲完整的數據。
• 增量表：存儲新增長的數據。
• 新增及變化表：存儲新增長的數據和變化的數據。
• 拉鍊表：對新增及變化表作按期合併。

2.2.1 實體表同步策略
實體表：好比用戶，商品，商家，銷售員等
實體表數據量比較小：一般能夠作每日全量，就是天天存一份完整數據。即每日全量。

2.2.2 維度表同步策略
維度表：好比訂單狀態，審批狀態，商品分類
維度表數據量比較小：一般能夠作每日全量，就是天天存一份完整數據。即每日全量。
說明：
1）針對可能會有變化的狀態數據能夠存儲每日全量。
2）沒變化的客觀世界的維度（好比性別，地區，民族，政治成分，鞋子尺碼）能夠只存一份固定值。

2.2.3 事務型事實表同步策略
事務型事實表：好比，交易流水，操做日誌，出庫入庫記錄等。
由於數據不會變化，並且數據量巨大，因此天天只同步新增數據便可，因此能夠作成每日增量表，即每日建立一個分區存儲。

2.2.4 週期型事實表同步策略
週期型事實表：好比，訂單、請假、貸款申請等
這類表從數據量的角度，存每日全量的話，數據量太大，冗餘也太大。若是用每日增量的話沒法反應數據變化。
每日新增及變化量，包括了當日的新增和修改。通常來講這個表，足夠計算大部分當日數據的。可是這種依然沒法解決可以獲得某一個歷史時間點（時間切片）的切片數據。
因此要用利用每日新增和變化表，製做一張拉鍊表，以方便的取到某個時間切片的快照數據。因此咱們須要獲得每日新增及變化量。




2.3 範式理論
2.3.1 範式概念
關係型數據庫設計時，遵守必定的規範要求，目的在於下降數據的冗餘性，目前業界範式有：第一範式(1NF)、第二範式(2NF)、第三範式(3NF)、巴斯-科德範式(BCNF)、第四範式(4NF)、第五範式(5NF)。
範式能夠理解爲設計一張數據表的表結構，符合的標準級別。

使用範式的根本目的是：
  1）減小數據冗餘，儘可能讓每一個數據只出現一次。
  2）保證數據一致性
缺點是獲取數據時，須要經過Join拼接出最後的數據。

2.3.2 函數依賴




2.3.3 三範式區分

下載附件