6.1 電商常識

SKU：一臺銀色、128G記憶體的、支援聯通網路的iPhoneX

SPU：iPhoneX

Tm_id：品牌Id蘋果，包括IPHONE，耳機，mac等

6.2 電商業務流程

6.3 業務表關鍵欄位

6.3.1 訂單表（order_info）

6.3.2 訂單詳情表（order_detail）

6.3.3 商品表

6.3.4 使用者表

6.3.5 商品一級分類表

6.3.6 商品二級分類表

6.3.7 商品三級分類表

6.3.8 支付流水錶

訂單表跟訂單詳情表有什麼區別？

• 訂單表的訂單狀態會變化，訂單詳情表不會，因為沒有訂單狀態。

• 訂單表記錄user_id，訂單id訂單編號，訂單的總金額order_status，支付方式，訂單狀態等。

• 訂單詳情表記錄user_id，商品sku_id ,具體的商品資訊（商品名稱sku_name，價格order_price，數量sku_num）

6.4 MySql中表的分類

實體表，維度表，事務型事實表，週期性事實表

其實最終可以把事務型事實表，週期性事實表統稱實體表，實體表，維度表統稱維度表

訂單表（order_info）（週期型事實表）

訂單詳情表（order_detail）(事務型事實表)

商品表(實體表)

使用者表(實體表)

商品一級分類表(維度表)

商品二級分類表(維度表)

商品三級分類表(維度表)

支付流水錶(事務型實體表)

6.5 同步策略

實體表，維度表統稱維度表，每日全量或者每月（更長時間）全量

事務型事實表：每日增量

週期性事實表：拉鍊表

6.6 關係型資料庫正規化理論

  1NF：屬性不可再分割（例如不能存在5臺電腦的屬性，壞處：表都沒法用）

  2NF：不能存在部分函式依賴（例如主鍵（學號+課名）-->成績，姓名，但學號 -->姓名，所以姓名部分依賴於主鍵（學號+課名），所以要去除，壞處：資料冗餘）

  3NF：不能存在傳遞函式依賴（學號 --> 宿舍種類 --> 價錢，壞處：資料冗餘和增刪異常）

   Mysql關係模型：關係模型主要應用與OLTP系統中，為了保證資料的一致性以及避免冗餘，所以大部分業務系統的表都是遵循第三正規化的。

  Hive 維度模型：維度模型主要應用於OLAP系統中，因為關係模型雖然冗餘少，

但是在大規模資料，跨表分析統計查詢過程中，會造成多表關聯，這會大大降低執行效率。

所以HIVE把相關各種表整理成兩種：事實表和維度表兩種。所有維度表圍繞著事實表進行解釋。

6.7 資料模型

雪花模型、星型模型和星座模型

（在維度建模的基礎上又分為三種模型：星型模型、雪花模型、星座模型。）

星型模型（一級維度表），雪花（多級維度），星座模型（星型模型+多個事實表）

6.8 業務資料數倉搭建

sqoop

  導資料的原理是mapreduce,

  import 把資料從關係型資料庫 導到 資料倉庫，自定義InputFormat，

  export 把資料從資料倉庫 導到 關係型資料庫，自定義OutputFormat，

  用sqoop從mysql中將八張表的資料匯入數倉的ods原始資料層

  全量無條件，增量按照建立時間，增量+變化按照建立時間或操作時間。

origin_data

  sku_info商品表（每日導全量）

  user_info使用者表（每日導全量）

  base_category1商品一級分類表（每日導全量）

  base_category2商品二級分類表（每日導全量）

  base_category3商品三級分類表（每日導全量）

  order_detail訂單詳情表（每日導增量）

  payment_info支付流水錶（每日導增量）

  order_info訂單表（每日導增量+變化）

6.8.1 ods層

  （八張表，表名，欄位跟mysql完全相同）

  從origin_data把資料匯入到ods層，表名在原表名前加ods_

6.8.2 dwd層

  對ODS層資料進行判空過濾。對商品分類表進行維度退化(降維)。其他資料跟ods層一模一樣

訂單表 dwd_order_info

訂單詳情表 dwd_order_detail

使用者表 dwd_user_info

支付流水錶 dwd_payment_info

商品表 dwd_sku_info

其他表字段不變，唯獨商品表，通過關聯3張分類表，增加了

              category2_id` string COMMENT '2id', 

              `category1_id` string COMMENT '3id', 

              `category3_name` string COMMENT '3', 

              `category2_name` string COMMENT '2', 

              `category1_name` string COMMENT '1', 

小結：

1）維度退化要付出什麼代價？或者說會造成什麼樣的需求處理不了？

• 如果被退化的維度，還有其他業務表使用，退化後處理起來就麻煩些。

• 還有如果要刪除資料，對應的維度可能也會被永久刪除。

2）想想在實際業務中還有那些維度表可以退化

• 城市的三級分類（省、市、縣）等

6.8.3 dws層

從訂單表 dwd_order_info 中獲取 下單次數 和 下單總金額

從支付流水錶 dwd_payment_info 中獲取 支付次數 和 支付總金額

從事件日誌評論表 dwd_comment_log 中獲取評論次數

最終按照user_id聚合，獲得明細，跟之前的mid_id聚合不同

6.9、需求

6.9.1 需求一：GMV成交總額

從使用者行為寬表中dws_user_action，根據統計日期分組，聚合，直接sum就可以了。

6.9.2、 需求二：轉化率

6.9.2.1 新增使用者佔日活躍使用者比率表

  從日活躍數表 ads_uv_count 和 日新增裝置數表 ads_new_mid_count 中取即可。

6.9.2.2 使用者行為轉化率表

從使用者行為寬表dws_user_action中取，下單人數（只要下單次數>0）,支付人數（只要支付次數>0）

從日活躍數表 ads_uv_count 中取活躍人數，然後對應的相除就可以了。

6.9.3、 需求三：品牌復購率

需求：以月為單位統計，購買2次以上商品的使用者

6.9.3.1 使用者購買商品明細表（寬表）

6.9.3.2 品牌復購率表

從使用者購買商品明細寬表dws_sale_detail_daycount中，根據品牌id--sku_tm_id聚合，計算每個品牌購買的總次數，購買人數a=購買次數>=1,兩次及以上購買人數b=購買次數>=2，三次及以上購買人數c=購買次數>=3,

單次復購率=b/a，多次復購率=c/a

6.10、 專案中有多少張寬表

   寬表要3-5張，使用者行為寬表，使用者購買商品明細行為寬表，商品寬表，購物車寬表，物流寬表、登入註冊、售後等。

1）為什麼要建寬表

   需求目標，把每個使用者單日的行為聚合起來組成一張多列寬表，以便之後關聯使用者維度資訊後進行，不同角度的統計分析。

6.11、 拉鍊表

訂單表拉鍊表 dwd_order_info_his

      `id` string COMMENT '訂單編號',

    `total_amount` decimal(10,2) COMMENT '訂單金額',

    `order_status` string COMMENT '訂單狀態',

    `user_id` string COMMENT '使用者id' ,

    `payment_way` string COMMENT '支付方式', 

    `out_trade_no` string COMMENT '支付流水號', 

    `create_time` string COMMENT '建立時間', 

    `operate_time` string COMMENT '操作時間' ,

    `start_date`  string COMMENT '有效開始日期',

    `end_date`  string COMMENT '有效結束日期'

1）建立訂單表拉鍊表，欄位跟拉鍊表一樣，只增加了有效開始日期和有效結束日期

  初始日期，從訂單變化表ods_order_info匯入資料，且讓有效開始時間=當前日期，有效結束日期=9999-99-99

  （從mysql匯入數倉的時候就只導了新增的和變化的資料ods_order_info，dwd_order_info跟ods_order_info基本一樣，只多了一個id的判空處理）

2）建一張拉鍊臨時表dwd_order_info_his_tmp，欄位跟拉鍊表完全一致

3）新的拉鍊表中應該有這幾部分資料，

• （1）增加訂單變化表dwd_order_info的全部資料

• （2）更新舊的拉鍊表左關聯訂單變化表dwd_order_info，關聯欄位：訂單id, where 過濾出end_date只等於9999-99-99的資料，如果舊的拉鍊表中的end_date不等於9999-99-99，說明已經是終態了，不需要再更新

  • 如果dwd_order_info.id is null , 沒關聯上，說明資料狀態沒變，讓end_date還等於舊的end_date

  • 如果dwd_order_info.id is not null , 關聯上了，說明資料狀態變了，讓end_date等於當前日期-1

  - 把查詢結果插入到拉鍊臨時表中
  

4）把拉鍊臨時表覆蓋到舊的拉鍊表中

關注我的公眾號【寶哥大資料】， 更多幹貨