第2章 离线数仓项目（简历，重中之重）

第2章 离线数仓项目

2.1 提高自信

云上数据仓库解决方案：云上大数据仓库解决方案_阿里云大数据_ODPS_阿里云

2.2 为什么做这个项目

随着公司的发展，老板需要详细的了解公司的运营情况。比如，日活、新增、留存、转化率等。所以公司绝对招聘大数据人才来做这个项目，目的是为老板做决策提供数据支持。

2.3 数仓概念

数据仓库的输入数据源和输出系统分别是什么？

（1）输入系统：前端埋点产生的用户行为数据、JavaEE后台产生的业务数据、个别公司有爬虫数据。

（2）输出系统：报表系统、用户画像系统、推荐系统。

2.4 项目架构

2.5 框架版本选型

1）Apache：运维麻烦，组件间兼容性需要自己调研。（一般大厂使用，技术实力雄厚，有专业的运维人员）。

2）CDH6.3.2：国内使用最多的版本。CDH和HDP合并后推出，CDP7.0。收费标准，10000美金一个节点每年。（不建议使用）

3）HDP：开源，可以进行二次开发，但是没有CDH稳定，国内使用较少。

4）云服务选择

（1）阿里云的EMR、MaxCompute、DataWorks

（2）腾讯云EMR、流计算Oceanus、数据开发治理平台WeData

（3）华为云EMR

（4）亚马逊云EMR

Apache框架各组件重要版本发版时间

框架	版本号	发版时间	框架	版本号	发版时间
Hadoop	2.7.2	2017-06	Spark	1.6.0	2016-01
	3.0.0	2018-03		2.0.0	2016-07
	3.1.3	2020-07		2.2.0	2018-05
Zookeeper	3.4.12	2018-05		2.4.0	2018-11
	3.4.14	2019-04		3.0.0	2020-06
	3.5.8	2020-05		2.4.8	2022-06
	3.7.0	2021-03		3.2.0	2021-10
	3.8.0	2022-03		3.3.0	2022-06
Flume	1.9.0	2019-01	Flink	1.7.0	2018-11
	1.10.0	2022-03		1.8.0	2019-04
	1.11.0	2022-10		1.9.0	2019-08
Kafka	1.0.0	2017-11		1.10.0	2020-02
	2.0.0	2018-07		1.11.0	2020-07
	2.3.0	2019-03		1.12.0	2020-12
	2.4.0	2019-12		1.13.0	2021-04
	2.7.0	2020-12		1.13.6	2022-02
	3.0.0	2021-09		1.14.0	2021-09
Hive	1.2.1	2015-06		1.15.0	2022-05
	2.0.0	2016-02		1.16.0	2022-10
	2.2.0	2017-07	DolphinScheduler	1.2.0（最早）	2020-01
	3.0.0	2018-05		1.3.9	2021-10
	2.3.6	2019-08		2.0.0	2021-11
	3.1.2	2019-08		3.0.0	2022-08
	2.3.7	2020-04	Doris	0.13.0（最早）	2020-10
	3.1.3	2022-04		0.14.0	2021-05
HBase	1.2.0	2016-02		0.15.0	2021-11
	1.4.0	2017-12		1.1.0	2022-07
	1.5.0	2019-10	Hudi	0.10.0	2021-12
	1.6.0	2020-07		0.11.0	2022-03
	2.0.0	2018-05		0.12.0	2022-08
	2.2.0	2019-06	Sqoop	1.4.6	2017-10
	2.4.0	2020-12		1.4.7	2020-07
	2.5.0	2022-08
Phoenix	4.14.0 (1.4)	2018-06
	4.16.1 ( 1.3, 1.4, 1.5, 1.6)	2021-05
	5.1.2 ( 2.1, 2.2, 2.3, 2.4)	2021-07

*注：着重标出的为公司实际生产中的常用版本。

2.6 服务器选型

服务器使用物理机还是云主机？

1）机器成本考虑：

（1）物理机：以128G内存，20核物理CPU，40线程，8THDD和2TSSD硬盘，单台报价4W出头，惠普品牌。一般物理机寿命5年左右。

（2）云主机，以阿里云为例，差不多相同配置，每年5W。华为云、腾讯云、天翼云。

2）运维成本考虑：

（1）物理机：需要有专业的运维人员（1万 * 13个月）、电费（商业用户）、安装空调、场地。

（2）云主机：很多运维工作都由阿里云已经完成，运维相对较轻松。

3）企业选择

（1）金融有钱公司选择云产品（上海）。

（2）中小公司、为了融资上市，选择云产品，拉到融资后买物理机。

（3）有长期打算，资金比较足，选择物理机。

2.7 集群规模

1）硬盘方面考虑

2）CPU方面考虑

20核物理CPU  40线程 * 8 = 320线程     （指标 100-200）

3）内存方面考虑

内存128g * 8台 = 1024g  （计算任务内存800g，其他安装框架需要内存）

128m =》1g内存

=》

100g数据 、800g内存

4）参考案例说明

根据数据规模大家集群（在企业，干了三年 通常服务器集群 5-20台之间）

（1）参考腾讯云EMR官方推荐部署

• Master节点：管理节点，保证集群的调度正常进行；主要部署NameNode、ResourceManager、HMaster 等进程；非 HA 模式下数量为1，HA 模式下数量为2。

• Core节点：为计算及存储节点，您在 HDFS 中的数据全部存储于 core 节点中，因此为了保证数据安全，扩容 core 节点后不允许缩容；主要部署 DataNode、NodeManager、RegionServer 等进程。非 HA 模式下数量≥2，HA 模式下数量≥3。
• Common 节点：为 HA 集群 Master 节点提供数据共享同步以及高可用容错服务；主要部署分布式协调器组件，如 ZooKeeper、JournalNode 等节点。非HA模式数量为0，HA 模式下数量≥3。

（2）数据传输数据比较紧密的放在一起（Kafka、clickhouse）

（3）客户端尽量放在一到两台服务器上，方便外部访问

（4）有依赖关系的尽量放到同一台服务器（例如：Ds-worker和hive/spark）

Master	Master	core	core	core	common	common	common
nn	nn	dn	dn	dn	JournalNode	JournalNode	JournalNode
rm	rm	nm	nm	nm
					zk	zk	zk
hive	hive	hive	hive	hive
		kafka	kafka	kafka
spark	spark	spark	spark	spark
datax	datax	datax	datax	datax
Ds-master	Ds-master	Ds-worker	Ds-worker	Ds-worker
maxwell
superset
mysql
flume	flume
flink	flink
		clickhouse
			redis
hbase

2.8 人员配置参考

2.8.1 整体架构

大数据开发工程师 =》 大数据组组长=》项目经理=》部门经理=》技术总监CTO

 =》 高级架构师 =》 资深架构师

2.8.2 你的的职级等级及晋升规则

小公司：职级就分初级，中级，高级。晋升规则不一定，看公司效益和职位空缺。

大公司都有明确的职级：

         

         

       

2.8.3 人员配置参考

小型公司（1-3人左右）：组长1人，剩余组员无明确分工，并且可能兼顾JavaEE和前端。

中小型公司（3~6人左右）：组长1人，离线2人左右，实时1人左右（离线一般多于实时），组长兼顾和JavaEE、前端。

中型公司（5~10人左右）：组长1人，离线3~5人左右（离线处理、数仓），实时2人左右，组长和技术大牛兼顾和JavaEE、前端。

中大型公司（10~20人左右）：组长1人，离线5~10人（离线处理、数仓），实时5人左右，JavaEE1人左右（负责对接JavaEE业务），前端1人（有或者没有人单独负责前端）。（发展比较良好的中大型公司可能大数据部门已经细化拆分，分成多个大数据组，分别负责不同业务）

上面只是参考配置，因为公司之间差异很大，例如ofo大数据部门只有5个人左右，因此根据所选公司规模确定一个合理范围，在面试前必须将这个人员配置考虑清楚，回答时要非常确定。

咱们自己公司：大数据组组长：1个人；离线3-4个人；实时1-3个人。

IOS多少人？安卓多少人？前端多少人？JavaEE多少人？测试多少人？

（IOS、安卓） 1-2个人   前端3个人； JavaEE一般是大数据的1-1.5倍，测试：有的有，1个左右，有的没有。  产品经理1个、产品助理1-2个，运营1-3个。

公司划分：

0-50 小公司；50-500 中等；500-1000 大公司；1000以上 大厂 领军的存在。

2.9 从0-1搭建项目，你需要做什么？

1）需要问项目经理的问题

（1）数据量（增量、全量）： 100g

（2）预算：     50万

（3）数据存储多久：     1年

（4）云主机、物理机： 云主机

（5）日活：             100万

（6）数据源：           用户行为数据(文件)、业务数据（MySQL）

（7）项目周期：         1个月-3个月

（8）团队多少人：     3-5个

（9）首批指标：         1-10个

（10）未来的规划：      离线和实时 是否都要做

2）项目周期（2个月）

（1）数据调研（2周） +  集群搭建

（2）明确数据域（2天）

（3）构建业务矩阵（3天）

（4）建模  至下而上 （2周）

①ODS层 ②DWD层 ③DIM层

（5）指标体系建设  至上而下  （2周）

（6）处理bug  1周

2.10 数仓建模准备

1）数据仓库建模的意义

如果把数据看作图书馆里的书，我们希望看到它们在书架上分门别类地放置；

1. 减少重复计算。
2. 快速查询所需要的数据。

2）ER模型

如果对方问三范式问题。初步判断对方是一个java程序员，就不要和他深入聊，mysql高级、redis、多线程、JVM、SSM等框架了。

应该把话题转移到大数据技术。Spark、flink、海量数据如何处理、维度建模。

3）维度建模

星型模型：事实表周围一级维度    减少join  => 大数据场景不适合频繁的join

雪花模型：事实表周期多级维度

星座：多个事实表

4）事实表

（1）如何判断一张表是事实表？

具有度量值的    可以累加的   个数、件数、金额、次数

（2）同步策略

数据量大   =》  通常增量    特殊的，加购 （周期快照事实表）

（3）分类

     ①事务型事实表

     找原子操作。  例如：下单 加购  支付

        ①选择业务过程

        ②声明粒度

        ③确定维度

        ④确定事实

     不足：

        连续性指标，不好找原子操作。   例如，库存（周期快照事实表）

        多事实表关联。 例如，统计加购到支付的平均使用时长 （累积型快照事实表）

     ②周期快照事实表

     ③累积型快照事实表

5）维度表

（1）如何判断一张表是维度表？

没有度量值，都是描述信息。  身高  体重、年龄、性别

（2）同步策略

数据量小  =》  通常 全量  特殊的  用户表

（3）维度整合  减少Join操作

    ①商品表、商品品类表、SPU、商品一级分类、二级分类、三级分类=》商品维度表

    ②省份表、地区表 =》 地区维度表

    ③活动信息表、活动规则表 =》 活动维度表

（4）拉链表

对用户表做了拉链。

    缓慢变化维 场景

6）建模工具是什么？

PowerDesigner、EZDML

2.11 数仓建模

1）数据调研

   （1）先和Java人员要表，表中最好有字段的描述或者有表和字段的说明文档。（项目经理帮助协调）  =》  快速熟悉表中业务。梳理清楚业务线，找到事实表和维度表。

   （2）和业务人员聊  =》  验证你猜测的是否正确

   （3）和产品经理聊

需求：派生指标、衍生指标

        派生指标  = 原子指标（业务过程 + 度量值 + 聚合逻辑） + 统计周期 + 统计粒度 + 业务限定

需求中的业务过程必须和实际的后台业务能对应上。

2）明确数据域

（1）用户域：登录、注册

（2）流量域：启动、页面、动作、故障、曝光

（3）交易域：加购、下单、支付、物流、取消下单、取消支付

（4）工具域：领取优惠卷、使用优惠卷下单、使用优惠卷支付

（5）互动域：点赞、评论、收藏

3）构建业务矩阵

     用户、商品、活动、时间、地区、优惠卷

（1）用户域：

        登录、注册

（2）流量域：                      √

        启动、页面、动作、故障、曝光

（3）交易域：

        加购、下单、支付、物流、取消下单、取消支付

（4）工具域：

        领取优惠卷、使用优惠卷下单、使用优惠卷支付

（5）互动域：

        点赞、评论、收藏

4）建模  至下而上

    （1）ODS层

        ①保持数据原貌不做任何修改    起到备份作用

        ②采用压缩   减少磁盘空间，采用Gzip压缩

        ③创建分区表    防止后续全表扫描

（2）DWD层 事实表

         ①事务型事实表

            找原子操作

            a）选择业务过程

               选择感兴趣的业务过程。  产品经理提出的指标中需要的。

            b）声明粒度

               粒度：一行信息代表什么含义。可以是一次下单、一周下单、一个月下单。

如果是一个月的下单，就没有办法统计一次下单情况。保持最小粒度。

              只要你自己不做聚合操作就可以。

           c）确定维度

               确定感兴趣的维度。   产品经理提出的指标中需要的。

               例如：用户、商品、活动、时间、地区、优惠卷

           d）确定事实

               确定事实表的度量值。  可以累加的值，例如，个数、件数、次数、金额。

           事务型事实表的不足：  

1. 1. 1. 1. 连续性指标，不好找原子操作。   例如，库存（周期快照事实表）
         2. 多事实表关联。例如，统计加购到支付的平均使用时长（累积型快照事实表）

            （2）周期快照事实表

                ①选择业务过程

                ②声明粒度   =》  1天

                ③确定维度

                ④确定事实

            （3）累积型快照事实表

                ①选择业务过程

                ②声明粒度

                ③确定维度

                ④确定事实   确定多个事实表度量值

（3）DIM层 维度表

           ①维度整合  减少join

             a）商品表、商品品类表、spu、商品一级分类、二级分类、三级分类=》商品维度表

             b）省份表、地区表 =》 地区维度表

             c）活动信息表、活动规则表 =》 活动维度表

          ②拉链表

对用户表做了拉链。

            缓慢变化维 场景。

5）指标体系建设  至上而下

   （1）ADS层

        需求、日活、新增、留存、转化率、GMV

   （2）DWS层  聚合层

        需求：派生指标、衍生指标

        派生指标  = 原子指标（业务过程 + 度量值 + 聚合逻辑） + 统计周期 + 统计粒度 + 业务限定

        例如，统计，每天各个省份手机品牌交易总额

        交易总额  （下单 + 金额 +  sum ） + 每天 + 省份  + 手机品牌

        找公共的：业务过程 + 统计周期 + 统计粒度   建宽表

2.12 数仓每层做了哪些事

1）ODS层做了哪些事？

（1）保持数据原貌，不做任何修改

（2）压缩采用gzip，压缩比是100g数据压缩完10g左右。

（3）创建分区表

2）DIM/DWD层做了哪些事？

建模里面的操作，正常写。

（1）数据清洗的手段

HQL、MR、SparkSQL、Kettle、Python（项目中采用SQL进行清除）

（2）清洗规则

金额必须都是数字，[0-9]、手机号、身份证、匹配网址URL

        解析数据、核心字段不能为空、过期数据删除、重复数据过滤

        json =>  很多字段 =》  一个一个判断 =》 取数，根据规则匹配

（3）清洗掉多少数据算合理

参考，1万条数据清洗掉1条。

（4）脱敏

对手机号、身份证号等敏感数据脱敏。

①加*

135****0013  互联网公司经常采用

②加密算法 md5  需要用数据统计分析，还想保证安全

    美团  滴滴  md5（12334354809）=》唯一值

③加权限  需要正常使用   军工、银行、政府

（5）压缩snappy

（6）orc列式存储

3）DWS层做了哪些事？

指标体系建设里面的内容再来一遍。

4）ADS层做了哪些事？

一分钟至少说出30个指标。

日活、月活、周活、留存、留存率、新增（日、周、年）、转化率、流失、回流、七天内连续3天登录（点赞、收藏、评价、购买、加购、下单、活动）、连续3周（月）登录、GMV、复购率、复购率排行、点赞、评论、收藏、领优惠卷人数、使用优惠卷人数、沉默、值不值得买、退款人数、退款率  topn  热门商品

产品经理最关心的：留转G复活

2.13 数据量

数据量的描述都是压缩前的数据量。

1）ODS层：

（1）用户行为数据（100g => 1亿条；1g => 100万条）

曝光（60g or 600万条）、页面（20g）、动作（10g）、故障 + 启动（10g）

（2）业务数据（1-2g => 100万-200万条）

登录（20万）、注册（100-1000）；

加购（每天增量20万、全量100万）、下单（10万）、支付（9万）、物流（9万）、取消下单（500）、退款（500）；

领取优惠卷（5万）、使用优惠卷下单（4万）、使用优惠卷支付（3万）；

点赞（1000）、评论（1000）、收藏（1000）；

用户（活跃用户100万、新增1000、总用户1千万）、商品SPU（1-2万）、商品SKU（10-20万）、活动（1000）、时间（忽略）、地区（忽略）

2）DWD层 + DIM层：

和ODS层几乎一致；

3）DWS层

轻度聚合后，20g-50g。

4）ADS层

10-50m之间，可以忽略不计。

2.14 项目中遇到哪些问题？（*****）

1）Flume零点漂移

2）Flume挂掉及优化

3）Datax空值、调优

4）HDFS小文件处理

5）Kafka挂掉

6）Kafka丢失

7）Kafka数据重复

8）Kafka消息数据积压

9）Kafk乱序

10）Kafka顺序

11）Kafka优化（提高吞吐量）

12）Kafka底层怎么保证高效读写

13）Kafka单条日志传输大小

14）Hive优化（Hive on Spark）

15）Hive解决数据倾斜方法

16）疑难指标编写（7天内连续3次活跃、1 7 30指标、路径分析、用户留存率、最近7/30日各品牌复购率、最近30天发布的优惠券的补贴率、 同时在线人数）

17）DS任务挂了怎么办？

18）DS故障报警

2.15 离线---业务

2.15.1 SKU和SPU

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

SPU：iPhoneX。

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

2.15.2 订单表跟订单详情表区别？

订单表的订单状态会变化，订单详情表不会，因为没有订单状态。

订单表记录user_id，订单id订单编号，订单的总金额order_status，支付方式，订单状态等。

订单详情表记录user_id，商品sku_id，具体的商品信息（商品名称sku_name，价格order_price，数量sku_num）

2.15.3 上卷和下钻

上卷：上卷是沿着维度的层次向上聚集汇总数据。

下探（钻）：下探是上卷的逆操作，它是沿着维度的层次向下，查看更详细的数据。

比如这个经典的数据立方体模型：

维度有产品、年度、地区等，统计销售额。实际上，维度还可以更细粒度，如时间维可由年、季、月、日构成，地区也可以由国家、省份、市、区县构成等。

下钻可以理解为由粗粒度到细粒度来观察数据，比如对产品销售情况分析时，可以沿着时间维从年到月到日更细粒度的观察数据。

增加维度粒度“月”。

上卷和下钻是相逆的操作，所以上卷可以理解为删掉维的某些粒度，由细粒度到粗粒度观察数据，向上聚合汇总数据。

2.15.4 TOB和TOC解释

TOB（toBusiness）：表示面向的用户是企业。

TOC（toConsumer）：表示面向的用户是个人。

2.15.5 流转G复活指标

1）活跃

日活：100万 ；月活：是日活的2-3倍  300万

总注册的用户多少？1000万-3000万之间。

渠道来源：app  公众号   抖音  百度  36   头条  地推

2）GMV

GMV：每天 10万订单 （50 – 100元） 500万-1000万

10%-20%  100万-200万（人员：程序员、人事、行政、财务、房租、收电费）

3）复购率

某日常商品复购；（手纸、面膜、牙膏）10%-20%

电脑、显示器、手表  1%

4）转化率

商品详情  =》  加购物车  =》下单   =》  支付

        1%-5%          50-60%     80%-95%

5）留存率

1/2/3-60日、周留存、月留存

搞活动：  10-20%

2.15.6 活动的话，数据量会增加多少？怎么解决？

日活增加50%，GMV增加多少20%。（留转G复活）情人节，促销手纸。

集群资源都留有预量。11.11，6.18，数据量过大，提前动态增加服务器。

2.15.7 哪个商品卖的好？

面膜、手纸，每天销售5000个。

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

基本一个项目建一个库，表格个数为初始的原始数据表格加上统计结果表格的总数。（一般70-100张表格）。

用户行为5张；业务数据33张表 =》ods34 =》dwd=>32张=》dws 22张宽表=>ads=》15张 =》103张。

Datax：00:10  => 20分钟左右  第一次全量。

用户行为数据，每天0：30开始运行。=》ds =》 5-6个小时运行完指标。

所有离线数据报表控制在8小时之内。

大数据实时处理部分控制在5分钟之内。（分钟级别、秒级别）

如果是实时推荐系统，需要秒级响应。

2.15.9 哪张表数据量最大

（1）用户行为数据

曝光（60g or 600万条）、页面（20g）

（2）业务数据（1-2g => 100万-200万条）

登录（20万）、注册（100-1000）；

加购（20万）、下单（10万）

用户（活跃用户100万、新增1000、总用户1千万）

商品SKU（10万-20万）

2.15.10 哪张表最费时间，有没有优化

最费时间，一般是发生数据倾斜时，会比较费时间。

1）Group By

    （1）统计各个省份对应的交易额

     第一个统计完的指标和最后一个统计完是时间相差20倍

     我们从Yarn上看到的

     一共执行了多长时间  4-5小时

     你想：发生了数据倾斜  任务停止掉

     （2）解决办法：

          ①开启map-side  预聚合

          ②skewindata

          解决后的效果怎么样 ？

          30-50分钟内执行完了

2）Join

     统计 事实表 和维度表join => mapjoin

     （1）小表   大表 join  mapjoin

          解决办法：  mapjoin

      （2）大表 =》 大表 join

          项目中什么出现  统计 加购到支付的平均使用时长

          执行时间  4-5小时   yarn

          ①：skewjoin

          ②：smbjoin  分桶有序join     使用的前提 （分桶且有序）

          ③：左表随机  右表扩容

          ④：通过建模 规避 大表join大表

                    累积型快照事实表

2.15.11 并发峰值多少？大概哪个时间点？ 

高峰期晚上7-12点。Kafka里面20m/s   2万/s  并发峰值在1-2万人

2.15.12 分析过最难的指标

1. 路径分析
2. 用户留存率
3. 最近7/30日各品牌复购率
4. 7天内连续3天登录
5. 每分钟同时在线人数

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

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

2.15.14 数仓当中数据多久删除一次

（1）部分公司永久不删

（2）有一年、两年“删除”一次的，这里面说的删除是，先将超时数据压缩下载到单独安装的磁盘上。然后删除集群上数据。 很少有公司不备份数据，直接删除的。

2.16 埋点

1）埋点选择

免费的埋点：上课演示。前端程序员自己埋点。

收费的埋点：神策、百度统计、友盟统计。

2）埋点方式主要有两种：

（1）按照页面埋点，有几个页面就创建几个表。

（2）按照用户行为：页面数据、事件数据、曝光数据、启动数据和错误数据。 咱们项目中采用的这种方式。

3）埋点数据日志格式

为了减少网络上数据的传输，日志格式设计时都会有公共信息。

{

  "common": {                  -- 公共信息

    "ar": "230000",              -- 地区编码

    "ba": "iPhone",              -- 手机品牌

    "ch": "Appstore",            -- 渠道

    "md": "iPhone 8",            -- 手机型号

    "mid": "YXfhjAYH6As2z9Iq", -- 设备id

    "os": "iOS 13.2.9",          -- 操作系统

    "uid": "485",                 -- 会员id

    "vc": "v2.1.134"             -- app版本号

  },

"actions": [                     --动作(事件)  

    {

      "action_id": "favor_add",   --动作id

      "item": "3",                   --目标id

      "item_type": "sku_id",       --目标类型

      "ts": 1585744376605           --动作时间戳

    }

  ]，

  "displays": [

    {

      "displayType": "query",        -- 曝光类型

      "item": "3",                     -- 曝光对象id

      "item_type": "sku_id",         -- 曝光对象类型

      "order": 1                        --出现顺序

    },

    {

      "displayType": "promotion",

      "item": "6",

      "item_type": "sku_id",

      "order": 2

    },

    {

      "displayType": "promotion",

      "item": "9",

      "item_type": "sku_id",

      "order": 3

    }

  ],

  "page": {                       --页面信息

    "during_time": 7648,        -- 持续时间毫秒

    "item": "3",                  -- 目标id

    "item_type": "sku_id",      -- 目标类型

    "last_page_id": "login",    -- 上页类型

    "page_id": "good_detail",   -- 页面ID

    "sourceType": "promotion"   -- 来源类型

  },

"err":{                     --错误

"error_code": "1234",      --错误码

    "msg": "***********"       --错误信息

},

  "ts": 1585744374423  --跳入时间戳

}