一、项目架构
技术选型
数据采集：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配置文件控制的
jobcontentreaderwritersettingspeed
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]
