一、2.0版本对比
二、业务介绍
1、术语
SKU
SPU
UV： user views 用户浏览总量【浏览量】
PV：page views 页面浏览总量
2、电商业务表结构
| 表名 | 同步方式 | 字段名 | 字段描述 |
|---|---|---|---|
| order_info(订单表) | 新增和变化 | order_status | 订单状态(会被修改) |
| create_time | 创建时间 | ||
| operate_time | 操作时间(最后一次修改订单的时间) | ||
| order_detail(订单详情表) | 增量 | create_time | 创建时间 |
| order_id | 订单号可以和order_info.id关联 | ||
| sku_info(sku商品表) | 全量 | create_time | 创建时间 |
| user_info(用户表) | 新增和变化 | create_time | 创建时间 |
| operate_time | 操作时间(最后一次用户信息的时间) | ||
| payment_info(支付流水表) | 增量 | payment_time | 支付时间 |
| base_category1(商品一级分类表) | 全量 | ||
| base_category2(商品二级分类表) | 全量 | ||
| base_category3(商品三级分类表) | 全量 | ||
| base_province(省份表) | 全量导一次 | ||
| base_region(地区表) | 全量导一次 | ||
| base_trademark(品牌表) | 全量 | ||
| order_status_log(订单状态表) | 增量 | operate_time | 操作时间 |
| spu_info(SPU商品表) | 全量 | ||
| comment_info(商品评论表) | 增量 | create_time | 创建时间 |
| order_refund_info(退单表) | 增量 | create_time | 创建时间 |
| cart_info(加购表) | (特殊)全量 | create_time | 创建时间 |
| operate_time | 操作时间(最后一次修改购物车的时间) | ||
| favor_info(商品收藏表) | (特殊)全量 | create_time | 创建时间 |
| cancel_time | 取消收藏的最后一次时间 | ||
| coupon_use(优惠券领用表) | 增量和变化 | get_time | 领券时间 |
| using_time | 使用时间 | ||
| used_time | 支付时间 | ||
| coupon_info(优惠券表) | 全量 | create_time | 创建时间 |
| activity_info(活动表) | 全量 | create_time | 创建时间 |
| activity_order(活动订单关联表) | 增量 | create_time | 创建日期 |
| activity_rule(优惠规则表) | 全量 | ||
| base_dic(编码字典表) | 全量 | create_time | 创建日期 |
| operate_time | 操作时间(最后一次修改的时间) | ||
| date_info(时间表) | 全量导一次 | ||
| holiday_info(假期表) | 全量导一次 | ||
| holiday_year(假期年表) | 全量导一次 |
增量表
全量表(包括导一次和导多次)
新增和变化表
3、业务表同步方式
(1)周期
每天一次，并将每天同步的数据在hive中创建一个分区(按日期进行分区)--每日订单等数据
次日凌晨00:30(保证用户行为数据已经采集到hdfs)同步前一天的数据
(2)同步策略-取决于数据量(大/小)
全量同步
增量同步
新增和变化同步(两个字段)
(3)保存周期
数仓中的数据有半年的回溯周期
4、数仓中表的分类☆
事实表：记录发生的事实，参考3W原则，对事实进行描述。记录who ，where, when,do
维度表：描述事实中的一部分
事务型事实表：事实一旦发生不会改变，表中记录只包含新增操作
周期型事实表：记录这个事实在某个时间周期内最终的状态，只重视结果
累计型快照事实表：记录整个事实在某个时间周期内的累积的变化状态！重视过程
5、表的分层
ODS：按日期分区
DWD：对ODS进行ETL后的明细，按日期分区
DWS：数据服务层，分区表，轻度聚合，每天一个分区
DWT：数据主题层，所有此主题的汇总数据，普通表
ADS：数据应用层，普通表
6、数仓中各层的建模
ODS：保持原貌，不做修改
DWD：ETL(清洗)，轻度聚合，展开明细【对维度表组合，实现降维操作】
DWS：分主题建宽表
DWT：分主题建宽表
ADS：根据需求建模
三、安装hive2.3
1、安装
配置环境变量/etc/profile的HIVE_HOME
配置hive-site.xml、拷贝MySQL的驱动
2、使用
启动Metastore：hive --service metastore &
3、JDBC方式连接
配置jdbc-site.xml和hdfs-site.xml
分发重启开启服务hiveserver2
配置hive的tez引擎
四、ODS层
1、数据准备
(1)造log数据
调整集群时间- dt.sh 最早 的日期
启动采集通道 onekeyboot.sh start
调用造数据的脚本 lg 200 300
去hdfs上查看，并继续修改时间重复操作
(2)造db数据
执行造数据的程序java -jar gmall-mock-db-2020-03-16-SNAPSHOT.jar
执行sqoop导入脚本mysql_to_hdfs.sh 是否第一次导入 日期
2、导入数据到ODS层
导入log数据：hdfs_to_ods_log.sh 日期
导入db数据：hdfs_to_ods_db.sh first|all 日期
五、DWD层
1、向DWD层导入log数据
(1)dwd_dim_sku_info
(2)dwd_dim_coupon_info
(3)dwd_dim_activity_info
(4)dwd_dim_base_province
insert overwrite TABLE dwd_dim_base_province
SELECT
bp.id, bp.name province_name, bp.area_code,
bp.iso_code, bp.region_id, br.region_name
FROM
ods_base_province bp left join ods_base_region br
on bp.region_id=br.id
(5)dwd_dim_date_info
(6)维度表总结
将同一类型的多个维度表进行维度退化，退化到一张表中
(7)dwd_fact_order_detail订单明细事实表
(8)dwd_fact_payment_info 支付事实表
(9)dwd_fact_order_refund_info 退款事实表
(10)dwd_fact_comment_info 评价事实表
(11)事务型事实表：取ODS层当日新增数据
(12)周期型快照事实表：每日全量
(13)dwd_fact_cart_info 加购物车表
(14)dwd_fact_favor_info 收藏表
(15)累积型快照事实表：按照统计的事实的生命周期的起始时间作为分区字段
(16)dwd_fact_coupon_use
(17)dwd_fact_order_info
(18)DWD层SQL导入总结
①知道来龙去脉
来龙： 需要从哪些ODS层表中导入数据！
维度表： 找和此维度相关的ods层表！
事实表： 按照星型模型，基于3w原则进行建模，选择需要的字段！
事实表+N个维度表
重点： ODS层这些表的数据，是怎么同步的！
ODS层表的数据，是每日全量？还是每日增量？还是每日新增和变化？
去脉： dwd层所建的表是一种什么样类型的表！
维度表： 从ods层多表join，取字段
事实表： 事务型事实表： 从每日增量的事实表中取数据，join 部分维度表取出维度字段即可！
周期型快照事实表： ODS是全量同步，直接从ODS层原封不动导入即可！
ODS层是增量同步，将ODS所有分区的数据汇总，按照user_id，sku_id进行汇总和去重，统计出要统计数据的最新状态！
累积型快照事实表： ①先查老的要覆盖的分区的数据
②查询新导入的新增和变化的数据
③新老交替，以新换旧
④插入覆盖分区
②思考业务流程
a)考虑 join的方式
b)选择何种函数
c) join表之间的粒度
(19)用户维度表(拉链表)
使用一张全量表(不是分区表)来存储全部的用户信息，以及用户信息的生命周期
如何链条化记录数据的特征变化？
答：为数据提供start_time，end_time
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
