项目整理

1.项目的整体简介

从需求上面讲,主要包含两方面:

​ (1)流量域分析

​ (2)业务域分析

从数据分析上面讲包含:

​ 运营报表分析
用户画像分析

数据的来源分为两部分:

​ (1)用户的日志行为(埋点可以植入业务系统的后端程序中(比如:Java,php),也可以植入业务系统的前端程序中(原生APP,微信小程序中,页面js))

​ (2)业务数据库

技术选型:

​ (1)数据采集:flume,sqoop

​ (2)存储平台:hdfs

​ (3)基础设施:Hive

​ (4)运算引擎:SparkSql

​ (5)资源调度:YARN

​ (6)任务调度:AZKABAN

​ (7)元数据管理:Atals

从技术架构上面上讲分为三层:

​ (1)数据采集汇聚层

​ (2)数据计算层

​ (3)数据服务层

分层设计:

​ (1)ODS层(贴源层):(存放flume采集过来的日志文件,以json文本文件格式存储)与原始日志保持一致(一般存储周期3个月)

​ (2)DWD层(数仓明细层):对从ADS层采集来的数据进行ETL处理后的扁平化数据(存储格式是orc或者parquet,存储时间一般为6个月)

​ (3)DWS层(数仓汇总层):根据主题分析需求,从DWD中轻度聚合后的数据(存储格式为orc或者parquet,存储时间一般为1年)

​ (4)ADS层(应用服务层):根据业务员的要求,从DWS中计算出来的报表(存储格式为orc或者parquet,存储时间为3年)

​ (5)DIM层:存储各种维表

​ 这种分层设计数据管理更加清晰,运算复用度更高,开发更快捷

2.项目技术简介

2.1.1流量域 ODS层到DWD层数据开发

(1)ods层数据:业务埋点数据直接到kafka的活跃分区topic中然后flume从kafka活跃分区中采集数据到hdfs中,启动hive,在hive中创建一个表把flume采集的数据放到创建的表中

(2)对采集的数据进行json解析 清洗过滤去除json数据体中的废弃字段（前端开发人员在埋点设计方案变更后遗留的无用字段）：

过滤掉json格式不正确的（脏数据）

过滤掉日志中account及deviceid全为空的记录

过滤掉日志中缺少关键字段（event/eventid/sessionid 缺任何一个都不行）的记录！

(2)在对ods曾数据进行ETL之前先准备生成三个字典,gps位置字典转换成geohash位置字典,

(3)有的可能gps没有只能根据ip定位置所以生成ip位置搜索字典准备,

(4)设备device设备guid绑定字典开发(我们使用的是关联设备ID和登录ID动态修正,一个设备ID被绑定到某个登陆ID（A）之后，如果该设备在后续一段时间（比如一个月内）被一个新的登陆ID（B）更频繁使用，则该设备ID会被调整至绑定登陆ID（B）我们会设定一个绑定的分,登录的次数越多得分越高,如果设备没有登陆过就绑定设备ID,如果有人登录就绑定用户ID)

(5)进行新老用户的标识(数据上的guid如果在前日中的设备绑定中存在,则为老访客,否则即为新访客)

2.2.2流量域 DWD层数据导到DWS层

根据主题分析需求,从DWD层进行数据的轻度聚合后的数据

DWS层存储流量主题概括表,

用户活跃度分区表新用户留存分析表,

交互时间概况表,

站内运营分析表,

优惠劵分析表,

常规固定漏斗分析表等

2.2.3 业务域ODS层数据开发

业务域的数据来自业务系统的数据库,通过sqoop或者datax进行数据的抽取到ods层

抽取原则:

维度表:

维度小表（品类信息维表，活动信息维表等），每天抽取过来一份全量（或者一周、一月）

维度大表（商品信息表）[实体表]，每天抽取过来一份增量数据

事实表:

​ 订单相关表

优惠券领取使用记录表

秒杀订阅记录表

每天都会抽取一份增量数据,每天滚动生成

总体原则: 小表全量抽取 大表抽取增量

ODS层表的模型主要有:

商品信息（主要信息、详情信息、类目信息、属性信息、商品相册信息）

用户信息（主要信息、附加信息、会员等级信息）

订单信息及购物车(详情信息,物流信息,评论信息)

内容管理(话题,文章,评论)

营销管理(优惠劵,代金卷,活动规则,主题推荐)

拉链表

2.2.4 业务域DWD层数据开发

本层的处理是对ODS层数据根据相关主题建设各种主题的宽表

这层存储的表为:

​ 订单明细表

​ 购物车明细表

​ 团购活动明细表

​ 秒杀活动明细表

​

2.2.5 业务域DWS层数据开发

本层处理主要是按照维度建模的思想,按各主题,对事实度量指标进行轻度聚合

DWS层包括的表为:

​ 订单金额维度聚合轻聚合表

​ 订单数量,人数维度请聚合表

​ 优惠劵领取数据量,使用数据量,使用人数,抵扣金额维度轻度聚合表

​ 营销活动参与次数,人数多维度请聚合表

​ 用户消费情况月度聚合表

​ 用户消费统计画像表

​ 用户商品退距画像分析表

​ 用户画像购物偏好画像分析表

2.2.6 数据计算

​ (1)主要用hive基础设施构建数仓,分层分主题进行各种报表的计算,这里我们除了用到hive之外,还用到了spark,spark主要计算一些相对复杂的计算任务(比如数据处理和后期的逻辑回归算法,评论语分析,朴素贝叶斯算法)

(2)任务调度用的是azkaban

(3)元数据管理用的是atlas,atlas中的数据管理分类,集中审计,搜索与血缘关系挺方便的

ATLAS的使用也挺方便，

通过atlas为数据系统开发好的hook来注入

通过atlas自带的WEB-UI来人工填写元数据信息再注入

通过在自己的数据系统中调用atlas对外暴露的api，来灵活注入

通过atlas自带的WEB-UI前端系统来查看、修改元数据

通过调用atlas对外暴露的api，来开发自己的管理系统

3.数据规模
公司用户规模500万
平均日活50万
平均每个用户访问1.2次
每个用户平均每次访问时长10分钟
按经验，每个用户平均每 5~10 秒产生一条事件

则每次访问，将产生10分钟60秒/10 = 60条事件日志
则，每天产生的日志总条数： 50万1.2*60条 = 3600万条日志

每条日志大小平均为0.5k，则每日增量日志大小为：
3600万0.5k = 18G
每月累积增量为：18G30 = 0.6T
假如要存储1年的数据量，则1年的累计存储量为：7.2T
考虑，增长趋势： 预估每月增长10%
则1年的累计存储量为：接近20T