2.离线数仓-业务数据采集

前言

数据采集分为两部分，前面已经说了行为日志采集，接下来说明业务数据采集。

一、业务数据采集对应架构图说明

项目总架构图中该部分对应了业务数据的采集过程

二、业务数据从哪里来

业务数据一般指的是存储在数据库中的数据，例如订单数据、支付数据、商品数据等等

三、电商基础知识

1.SKU和SPU

SKU：Stock Keeping Unit（库存量基本单位）。现在已经被引申为产品统一编号的简称，每种产品均对应有唯一的SKU号。
SPU（Standard Product Unit）：是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息集合。
SPU表示一类商品。同一SPU的商品可以共用商品图片、海报、销售属性等。
为了方便理解，如下图：

上图中iPhoneX手机就是SPU。一台银色、128G内存的、支持联通网络的iPhoneX，就是SKU。
当然，不同颜色或者不同内存的iPhoneX就属于不同的SKU。

2.平台属性和销售属性

平台属性和销售属性展示的位置不同，如下图平台属性：

下图则是销售属性（一般指某个商品的具体参数）：

四、电商业务表结构（简单了解）

1.整体结构

2.收藏SKU

收藏表记录的是用户收藏了某个SKU，所以收藏表包含了用户信息和SKU信息
收藏表中一行表示用个用户收藏了一个SKU，用表户和收藏表是1对多的关系，SKU表和收藏表是1对1的关系

2.加购物车

加购物车和收藏SKU是同样的关系
购物车表一行是一个用户把一个商品添加到购物车

3.领用优惠券

领用优惠券也和收藏SKU是同样的关系
优惠券领用表一行是一个用户领用了某一个优惠券

4.下单

订单表中只记录总金额和订单状态，不记录买了什么商品
订单表可以修改（可以修改收货地址）
订单明细表不可以修改
表能不能修改对后面数仓建设息息相关，因为Hive数据保存到HDFS上，HDFS上的数据一般不做修改，如果表能够修改，那么需要做额外的处理

5.支付

支付表中也没有商品信息，只有订单表的信息，因为支付是一次支付一个订单的，不能只支付订单中某些商品

6.退单

退单是可以退某件商品的，因此退单表和SKU信息表关联起来的。
例如一个订单买了10个商品，可以退其中的1件，因此退单表要包含退单的商品信息。

7.退款

退款类似于退单，退单可以退其中某件商品，那么退款也可以是某件商品的退款，因此需要包含SKU商品信息表

8.评价

用户对买的每一件商品都可以进行评价，因此评价表要关联用户表、订单表、SKU商品表

以下为本电商数仓系统涉及到的业务数据表结构关系。这34个表以订单表、用户表、SKU商品表、活动表和优惠券表为中心，延伸出了优惠券领用表、支付流水表、活动订单表、订单详情表、订单状态表、商品评论表、编码字典表退单表、SPU商品表等，用户表提供用户的详细信息，支付流水表提供该订单的支付详情，订单详情表提供订单的商品数量等情况，商品表给订单详情表提供商品的详细信息。本次讲解以此34个表为例，实际项目中，业务数据库中表格远远不止这些。

五、后台管理表结构（简单了解）

这个结构对于大数据人员来说没有意义，因为这个表严格遵守了MySQL的建表方式，严格遵守了三范式，去除掉了冗余（节省了磁盘）。
但是在大数据分析中查找某个属性需要多次关联，严重浪费性能（大数据基本不需要考虑磁盘问题）

1.商品

2.活动

活动可能是针对某件商品做活动的，例如衣服断码了，为了促销对剩下的SKU衣服做了活动

3.优惠券

优惠券是针对一类或一个品牌商品（SPU）做活动的