面试系列七 之 业务交互数据分析

Posted 2021-06-30 chbxw

6.1 电商常识

SKU：一台银色、128G内存的、支持联通网络的iPhoneX

SPU：iPhoneX

Tm_id：品牌Id苹果，包括IPHONE，耳机，mac等

6.2 电商业务流程

6.3 业务表关键字段

6.3.1 订单表（order_info）

标签	含义
id	订单编号
total_amount	订单金额
order_status	订单状态
user_id	用户id
payment_way	支付方式
out_trade_no	支付流水号
create_time	创建时间
operate_time	操作时间

6.3.2 订单详情表（order_detail）

6.3.3 商品表

6.3.4 用户表

6.3.5 商品一级分类表

标签	含义
id	id
name	名称

6.3.6 商品二级分类表

标签	含义
id	id
name	名称
category1_id	一级品类id

6.3.7 商品三级分类表

标签	含义
id	id
name	名称
Category2_id	二级品类id

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）为什么要建宽表

   需求目标，把每个用户单日的行为聚合起来组成一张多列宽表，以便之后关联用户维度信息后进行，不同角度的统计分析。

2）具体用户行为宽表字段名称
   评论、打赏、收藏、关注–商品、关注–人、点赞、分享、好价爆料、文章发布、活跃、签到、补签卡、幸运屋、礼品、金币、电商点击、gmv

CREATE TABLE `app_usr_interact`(
  `stat_dt` date COMMENT '互动日期', 
  `user_id` string COMMENT '用户id', 
  `nickname` string COMMENT '用户昵称', 
  `register_date` string COMMENT '注册日期', 
  `register_from` string COMMENT '注册来源', 
  `remark` string COMMENT '细分渠道', 
  `province` string COMMENT '注册省份', 
  `pl_cnt` bigint COMMENT '评论次数', 
  `ds_cnt` bigint COMMENT '打赏次数', 
  `sc_add` bigint COMMENT '添加收藏', 
  `sc_cancel` bigint COMMENT '取消收藏', 
  `gzg_add` bigint COMMENT '关注商品', 
  `gzg_cancel` bigint COMMENT '取消关注商品', 
  `gzp_add` bigint COMMENT '关注人', 
  `gzp_cancel` bigint COMMENT '取消关注人', 
  `buzhi_cnt` bigint COMMENT '点不值次数', 
  `zhi_cnt` bigint COMMENT '点值次数', 
  `zan_cnt` bigint COMMENT '点赞次数', 
  `share_cnts` bigint COMMENT '分享次数', 
  `bl_cnt` bigint COMMENT '爆料数', 
  `fb_cnt` bigint COMMENT '好价发布数', 
  `online_cnt` bigint COMMENT '活跃次数', 
  `checkin_cnt` bigint COMMENT '签到次数', 
  `fix_checkin` bigint COMMENT '补签次数', 
  `house_point` bigint COMMENT '幸运屋金币抽奖次数', 
  `house_gold` bigint COMMENT '幸运屋积分抽奖次数', 
  `pack_cnt` bigint COMMENT '礼品兑换次数', 
  `gold_add` bigint COMMENT '获取金币', 
  `gold_cancel` bigint COMMENT '支出金币', 
  `surplus_gold` bigint COMMENT '剩余金币', 
  `event` bigint COMMENT '电商点击次数', 
  `gmv_amount` bigint COMMENT 'gmv', 
  `gmv_sales` bigint COMMENT '订单数')
PARTITIONED BY (  `dt` string)

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）把拉链临时表覆盖到旧的拉链表中

6.12、电商分析指标

1 离线指标

• 网站流量指标 独立访问数UV 页面访客数PV
• 流量质量指标类 跳出率 平均页面访问时长 人均页面访问数

2 购物车类指标

• 加入购物车次数 加入购物车买家次数 加入购物车商品数
• 购物车支付转化率

3 下单类指标

• 下单笔数 下单金额 下单买家数 浏览下单转化率

4 支付类指标

• 支付金额 支付买家数 支付商品数 浏览-支付买家转化率
• 下单-支付金额转化率 下单-支付买家数转换率

5 交易类指标

• 交易成功订单数 交易成功金额 交易成功买家数 交易成功商品数
• 交易失败订单数 交易失败订单金额 交易失败买家数
• 交易失败商品数 退款总订单量 退款金额 退款率

6 市场营销活动指标

• 新增访问人数 新增注册人数 广告投资回报率 UV订单转化率

7 风控类指标

• 买家评价数 买家上传图片数 买家评价率 买家好评率 买家差评率
  物流平均配送时间

8 投诉类指标

• 发起投诉数 投诉率 撤销投诉(申诉数)

9 商品类指标

• 产品总数 SKU数 SPU数
• 上架商品SKU数 上架商品SPU数 上架商品数

日活跃用户，
月活跃用户，
各区域Top10商品统计，
季度商品品类点击率top10，
用户留存，
月APP的用户增长人数，
广告区域点击数top3，
活跃用户每天在线时长，
投诉人数占比，
沉默用户占比，
用户的新鲜度，
商品上架的sku数，
同种品类的交易额排名，
统计买家的评价率，
用户浏览时长，
统计下单的数量，
统计支付的数量，
统计退货的数量，
用户的（日活、月活、周活），
统计流失人数

日活，周活，月活，沉默用户占比，增长人数，活跃用户占比，在线时长统计，歌曲访问数，歌曲访问时长，各地区Top10歌曲统计 ,投诉人数占比，投诉回应时长，留存率，月留存率，转化率，GMV，复购vip率，vip人数，歌榜，挽回率，粉丝榜，打赏次数，打赏金额，发布歌曲榜单，歌曲热度榜单，歌手榜单，用户年龄组，vip年龄组占比，收藏数榜单，评论数
1.用户活跃数统计（日活，月活，周活）
2.某段时间的新增用户/活跃用户数
3.页面单跳转化率统计
4.活跃人数占比（占总用户比例）
5.在线时长统计（活跃用户每天在线时长）
12.统计本月的人均在线时长
6.订单产生效率（下单的次数与访问次数比）
7.页面访问时长（单个页面访问时长）
8.统计本季度付款订单
9.统计某广告的区城点击数top3
10.统计本月用户的流失人数
11.统计本月流失人数占用户人数的比例
13.统计本月APP的用户增长人数
14.统计本月的沉默用户
15.统计某时段的登录人数
16.统计本日用户登录的次数平均值
17.统计用户在某类型商品中的浏览深度（页面转跳率）
18.统计用户从下单开始到交易成功的平均时长
19.Top10热门商品的统计
20.统计下单的数量
21.统计支付的数量
22.统计退货的数量
23.统计动销率（有销量的商品/在线销售的宝贝）
24.统计支付转化率
25.统计用户的消费频率
26.统计商品上架的SKU数
27.统计同种品类的交易额排名
28.统计按下单退款排序的top10的商品
29.统计本APP的投诉人数占用户人数的比例
30.用户收藏商品

6.13、项目流程

6.13.1、商品详情 ----- 购物车 ----- 订单 ------ 付款的转换比率

5% 30% 70%

6.13.2、每天的GMV是多少，哪个商品卖的最好？每天下单量多少？

（1）100万的日活每天大概有10万人购买，平均每人消费100元，一天的GMV在1000万
（2）面膜，每天销售5000个
（3）每天下单量在10万左右

6.13.3、数据仓库每天跑多少张表，大概什么时候运行，运行多久？

基本一个项目建一个库，表格个数为初始的原始数据表格加上统计结果表格的总数。（一般70-100张表格）
每天0：30开始运行。
所有离线数据报表控制在8小时之内
大数据实时处理部分控制在5分钟之内。

6.13.4、数仓中使用的哪种文件存储格式

常用的包括：textFile，rcFile，ORC，Parquet，一般企业里使用ORC或者Parquet，因为是列式存储，且压缩比非常高，所以相比于textFile，查询速度快，占用硬盘空间少

6.13.5、测试相关

1）公司有多少台测试服务器？
测试服务器一般三台
2）测试数据哪来的？
一部分自己写Java程序自己造，一部分从生产环境上取一部分。
3）如何保证写的sql正确性
需要造一些特定的测试数据，测试。
离线数据和实时数据分析的结果比较。
4）测试环境什么样？
测试环境的配置是生产的一半
5）测试之后如何上线？
上线的时候，将脚本打包，提交git。先发邮件抄送经理和总监，运维。通过之后跟运维一起上线。

6.13.6、项目实际工作流程

1）先与产品讨论，看报表的各个数据从哪些埋点中取
2）将取得逻辑过程设计好，与产品确定后开始开发
3）开发出报表SQL脚本，并且跑几天的历史数据，观察结果
4）将报表放入调度任务中，第二天给产品看结果。
5）周期性将表结果导出或是导入后台数据库，生成可视化报表

6.13.7、项目中实现一个需求大概多长时间

刚入职第一个需求大概需要7天左右。
对业务熟悉后，平均一天一个需求。
影响时间的因素：开会讨论需求、表的权限申请、测试等

6.13.8、项目在3年内迭代次数，每一个项目具体是如何迭代的。

差不多一个月会迭代一次。就产品或我们提出优化需求，然后评估时间。每周我们都会开会做下周计划和本周总结。
有时候也会去预研一些新技术。

6.13.9、项目开发中每天做什么事

新需求比如埋点或是报表来了之后，需要设计做的方案，设计完成之后跟产品讨论，再开发。
数仓的任何步骤出现问题，需要查看问题，比如日活，月活下降等。

关注我的公众号【宝哥大数据】， 更多干货