一、项目架构
技术选型
数据采集:Flume,Kafka,Datax
数据存储:Mysql,HDFS
数据计算:Hive,Saprk
任务调度:DolphinScheduler
数据可视化:Superset
高可用:Zookeeper
项目架构
前端埋点
别克商城分PC、WAP、微信小程序埋点
PC、WAP为自动埋点 微信小程序为手动埋点
埋点类型
浏览(页面加载的时候)
点击(点击页面某个点位)
停留(近入下一个页面或者离开当前页面时在当前页面的停留时间)
曝光 (开屏、轮播等显示日志) 用来算 CTR(Click-Through-Rate) 点击通过率
留资、订单关联 (在产生留资、订单时会有一条对应id与用户唯一标识关联的数据,为了给留资、订单划分渠道)
二、数据采集
用户行为数据采集
采集Flume
基本配置:
Source:TailDir Source
拦截器:使用ETL拦截器以及提取日志的时间戳放在header中方面落盘,解决由于上报时间和网络抖动造成的数据飘逸问题
选择器:multiplexing
Channel: Kafka Channel
采用Kafka Channel,省去了Sink,提高了效率。
Kafka
浏览、点击、停留、曝光 的数据在一个文件夹里,留资、订单关联数据在另外一个文件夹里
topic_log 和 topic_order_leads 对应这两个topic文件夹 3分区两副本
消费Flume
基本配置:
Source: Kafka Source
Channel: File Channel
Sink: HDFS Sink
Flume拦截器的编写
- 实现Interceptor 接口,实现initialize(),intercept(Event event),intercept(List events),close()
2)intercept(Event event)书写逻辑,intercept(List events)调用intercept(Event event)方法
3)创建静态内部类Builder ,实现Intercepter.Builder接口,实现build()方法返回当前类的实例
输出路径
/topic_log /gmall/log/topic_log/%Y-%m-%d
/topic_order_leads/gmall/log/topic_order_leads/%Y-%m-%d
业务数据采集
同步策略
每天全量:适用于数据量不大,每天既有新的数据插入,又有旧的数据修改的情况
所有的维度数据
增量:适用于数据量大,每天只有数据插入的表
用户行为数据、客服对话、以及维度数据作为事实使用的时候
新增及变化:适用于数据量大,每天有数据插入的表又有数据修改的表
订单数据、留资数据通过调研,最晚变化时间高达200天,每次抽取200天的全量数据
stg 层 201天数据 -> 动态分区覆盖到 ods层 -> 拆分单事物事实表和累计快照事实表 -> 数据汇总 - > 数据应用
Datax参数和使用细节
1.datax导入导出是通过json配置文件控制的
job
content
reader
writer
setting
speed
2.HFDS Writer并未提供nullFormat参数,后期将DataX同步的文件导入Hive表就会出现问题,所有需要Hive中建表时指定null值存储格式为空字符串(‘’)
3.DataX传参,在JSON配置文件中使用${param}引用参数,在提交任务时使用-p"-Dparam=value"传入参数值
4.为了防止OOM等错误,需调大JVM的堆内存,建议将内存设置为4G或者8G,这个也可以根据实际情况来调整
输出路径
/origin_data/gmall/db/表名称/日期
三、数据仓库建模
数仓实施流程
1.数据调研
业务调研 对现有业务划分业务模块,弄清每个业务的业务流程
需求分析 1.与分析师、公司运营人员的沟通获知需求 2.对现有的报表系统研究分析
2.数据域划分
数据域是指面向业务分析,将业务过程或者维度进行抽象的集合。
别克商城数据域划分
数据域 | |
---|---|
数据域 | 业务过程 |
商品域 | 发布、上架、下架、库存 |
会员和经销商域 | 注册、登录、上线、下线 |
交易域 | 下单、支付、退款、核销、申领、审核通过、审核不通过 |
线索域 | 留资、下发、跟进、生成意向、(进店)、成交 |
流量域 | 浏览、点击、停留 |
客服域 | 会员咨询、客服答复、会员评分 |
经销商活动域 | 发布、上架、下架 |
总部活动域 | 分享、签到、订阅通知、兑换礼品、生成订单、申领权益、权益审核通过、权益审核不通过 |
区域活动域 | 发布、活动开始、活动结束、活动报名 |
3.构建总线矩阵
确定业务过程数据属于哪个数据域,明确业务过程与维度的关系
交易域
数据域 业务过程 | 一致性维度 | ||||||||
---|---|---|---|---|---|---|---|---|---|
时间 | 页面操作者 (经销商) | 商品 | 商品类型 | 预约经销商 | 支付方式 | 终端 | 父订单 | 来源 | |
下单 | √ | √ | √ | √ | √ | √ | √ | √ | |
支付 | √ | √ | √ | √ | √ | √ | √ | √ | √ |
核销 | √ | √ | √ | √ | √ | √ | √ | √ | √ |
流量域
数据域 业务过程 | 一致性维度 | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
时间 | 地区 | 页面操作者 (经销商) | 商品 | 车型 | 来源 | 终端 | 上一级 页面 | 页面 | 页面点位 | 页面点位 跳转页面 | |
浏览 | √ | √ | √ | √ | √ | √ | √ | √ | √ | ||
点击 | √ | √ | √ | √ | √ | √ | √ | √ | √ | √ | |
停留 | √ | √ | √ | √ | √ | √ | √ | √ | √ |
4.明细模型设计
DIM层
DWD层
5.汇总模型设计
DWS层
ADS层
6.代码开发,业务逻辑处理
7.部署运维
数仓分层
数据仓库分层
ODS 原始数据层,保持数据原貌,起到数据备份的作用
DIM 一致性维度层 维度是用来分析事实所需要的多样环境,维度的列称为维度属性,维度属性是查询约束条件、分组和报表标签生成的基本来源。维度属性一方面是现实实体的属性,另一方面是事实中沉淀出来的,比如订单里的支付类型。
DWD 明细数据层 对ODS层的数据进行数据清洗(去空值,脏数据,不合理的数据,手机号身份证号等脱敏),粒度一般是一个业务动作,最细粒度
DWS 以DWD为基础,进行轻度汇总,DWS是这个汇总层的统称,可以汇总多次,但最多不要超过三层。
ADS 以DWS和DWD为基础,进行指标分析,为各种统计报表提供数据。一般的开发流程,可能会直接DWD层获取数据,后期把公共逻辑抽取到DWS层。
分层原因
1)减少重复开发和重复计算,可以复用每一层的结果
2)将复杂的问题通过每一层的拆分变得简单
3)排查定位问题变得简单,有利于后期维护
4)对数据进行有序和有结构的分类组织和存储,避免数据不一致性,保证数据的规范
建模理论
OLTP和OLAP的区别
OLTP 英文全称On-Line Transaction Processing
主要数据操作的随机读写,采用3NF的关系模型存储数据,对数据的实时性要求比较高
解决了数据的一致性和数据冗余问题
OLAP 英文全称On-Line Analysis Processing
主要是批量读写,关注数据的整合和大批量数据处理,对数据实时性要求不高
采用维度建模,允许数据冗余
三范式
一范式: 属性不可分
二范式:消除部分函数依赖
三范式:消除传递函数依赖
关系建模和维度建模
关系建模遵循三范式,尽量将表进行拆分细化,降低数据的冗余。
维度建模不遵循三范式,要对关系建模的表进行维度退化,减少表与表之间join的次数。维度建模有星型模型,雪花模型,星座模型。星型模型事实表的周围只有一层维度表,雪花模型事实表周围的维度表有多层。在有多个事实表的情况下就会呈现星座模型。
维度表设计
基本概念
对事实的表述信息,每张表是现实世界的一类事物集合或概念。比如用户,商品,活动,日期,地区等
维度是用来分析事实所需要的多样环境,维度的列称为维度属性,维度属性是查询约束条件、分组和报表标签生成的基本来源。维度属性一方面是现实实体的属性,另一方面是事实中沉淀出来的,比如订单里的支付类型。
维度表行数较少,信息较多,内容相对固定
维度设计的基本流程
-
选择维度或者新建维度
-
确定主维表。主维表一般是ODS层的表,直接与业务系统同步。
-
确定相关维表。这一步也可以称为维度退化,把相关维表的重要维度属性退化到主维表中,减少join
-
确定维度属性。第一阶段是从主维表中选择或者生成属性,第二阶段是从选择或者生成维度属性。
确定维度属性需要注意的点:
- 维度属性尽可能丰富
- 维度属性应该有丰富的文字性描述,不应该是编码
- 区分数值型的属性和事实(参与度量计算是事实,是查询的约束条件或者区间分组统计是唯独属性)
- 尽可能沉淀出通用的维度属性,提高下游易用性,同时避免下游使用解析加公由于逻辑不同而导致数据差异。
事实表设计
事实表特性
事实表的每行代表一个业务事件(下单、支付、退款、评价等),这业务细节程度被称为粒度。
粒度通常可以有两种方式表述,一种是所表示的具体业务含义,一种是维度属性组合所表示的细节程度。
“事实”就这个业务事件的度量值,(次数,个数,件数,金额)有可加(订单金额),半可加(库存),不可加(比率型、UV)三种类型。
事实表数据量大,列数少,每天数据主要新增来源
维度属性可以储存到事实表中,存到事实表中的维度称为退化维度,但退化维度不能太多,维度属性变化需要进行数据回溯(数据重跑)
事实表类型
根据不同业务的需要,把事实表分为三种类型:事物事实表、周期快照事实表和累计快照事实表。
事物事实表用来表述业务过程,跟踪空间或时间点的度量事件,保存原子数据。
周期快照事实表以具有规律性的、可预见的时间间隔记录事实,如每天、每月、每年等。周期快照事实表总是和事物事实表成对出现。
累计快照事实表用来描述过程开始的结束之间的关键步骤状态,覆盖过程的整个生命周期,记录会随着过程的变化而修改。比如订单累计快照事实表的下单时间,付款时间,发货时间,签收时间,确认收货时间等。
事实表设计方法
-
选择业务过程和确定事实表类型
如果是单业务过程,就选择单事物事实表
如果是多个业务过程,并且之间没有联系维度有相同,选择多事物事实表
如果是多个业务过程,并且之间是转化关系,就选者累计快照事实表。
-
声明粒度
尽量选择最细级别的原子粒度
-
确定维度
确定维度表和事实表中的维度属性(比如支付方式)
-
确定事实
选择与业务过程有关的事实,粒度要与声明的事实表的粒度保持一致。比率型的不可加事实要分解为可加事实
四、数仓搭建
ODS层
把datax和flume导入到hdfs上的数据用load data inpath ‘xxx’ into table xxx partition(dt=‘xxx’)导入到相关的表中
表
DWD层
DWD层解析日志,合并PC、WAP和小程序的日志
构建一致性维度和事实
维度表
有商品维度表、经销商维度表、会员维度表、渠道维度表、地区维度表、时间维度表
事实表
事务型事实表:浏览事实表,点击事实表,停留事实表,登录事实表,曝光事实表 ,支付事实表,留资事实表,生成意向事实表
周期快照事实表:访客每日点击,访客每日浏览,用户每日登录,店铺商品每日库存快照,周月累计UV,PV,日活
累积性快照事实表:订单事实表,留资事实表
订单事实表和留资事实表细节
根据业务调研,200天是订单和留资从产生到消亡的最大时间,每天都抽取201天的全量数据
用datax抽取201天的数据放在stg层,使用动态分区把200前的数据按天归档,200天后的数据放在比如9999-99-99的分区里的ods层,然后在dwd层构建累积性快照事实表,依旧把200天的数据放在一个分区里。dws层每天覆盖200天的数据分区数据。
DWS层
DWS层的表就是维度表加事实表的度量值按小时、天、周、月统计
比如访客每日点击次数,PV;会员每日登录次数,下单次数,付款金额,在线时长
粒度一般是多个维度的维度组合,更多的时候是从ads层的业务逻辑下沉淀抽取下来的
ADS层指标分析
流量和用户域
PVUV
分渠道每天,周累计,月累计PV,UV
分经销商店铺PV,UV
分商品PVUV
活跃用户数
登录并且访问深度大于等于2的用户,每日分渠道活跃用户数汇总,周累计,月累计活跃用户数
重复活跃用户数
本月用户活跃天数大于2的用户,当天重复活跃用户数,周累计重复活跃用户数,月累计重复活跃用户数
连续活跃用户数:
连续n天活跃的用户,1,2,3,4,5 ,>5
**每日新增设备:**注册时间为当天的用户
沉默用户数:只在安装当天启动过,且启动时间是在7天前
首次登录时间等于末次登录时间,并且首次登录时间在七天前
本周回流用户:上周未活跃,本周活跃的设备,且不是本周新增设备
末次登录时间在本周并且首次活跃时间不在本周
流失用户数:最近7天未活跃的设备
末次活跃时间小于date_add(“”,-7)
最近连续三周活跃用户数:
查本周,前一周,前两周活跃设备的mid union all 一块
按mid分组having count(*)=3
最近七天连续三天活跃:
把日期用rank()over 开窗,把开窗的值与日期相减,按日期分组后count(*)>=3
交易域
漏斗分析:统计“浏览->购物车->下单->支付”的转化率
每日下单量,付款量,退款量,核销量
分渠道订单量
每天、周累计、月累计分渠道订单量
商品主题
销量排名:order by 商品不会太多,可以用order by
收藏排名:
商品加入购物车排名:
商品差评排名:
商品差评率:差评数/总评价数
五、DolphinScheduler任务调度
调度步骤
1.登录普通账户
2.向DolphinScheduler资源中心上传工作流所需脚本
3.向DolphinScheduler的WorkerServer节点分发脚本依赖的组件
4.修改DolphinScheduler环境变量配置文件并分发
5.在对应项目下创建工作流并连线(依赖)
6.上线工作流
7.执行测试工作流
8.设置定时任务
参数
局部参数、全局参数、系统内置参数
自定义日期格式
$[yyyyMMdd], $[HHmmss], $[yyyy-MM-dd]