电商数据仓库项目总结

一、项目架构

技术选型

数据采集：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]