离线数仓总结

离线数仓总结
一、1、背景介绍（某APP上线后，由于业务模式新颖，市场需求量大，经过一段时间的精心运营后，逐渐积累起了上千万会员，以及三四百万的日活量， app的业务功能和产品种类、数量也急速膨胀；主要问题有：营销分析断层；产品迭代无法量化；用户运营不精准；全局运营指标监控不实时）
2、需求总览：流量域分析
2.1、基础数据分析（整体概况、用户获取、活跃与留存、事件转化、用户特征）
2.2、基础数据分析指标概览
整体概况：产品整体的使用情况，包括用户量、访问情况、留存等帮助对产品整体指标有一个大致的了解（累计用户量、每日新增用户量、每日的全部访问人数、次数新老用户访问占比、新用户/全部用户的7日留存等）
用户获取
渠道访问（每个渠道的用户的使用情况，包括渠道中新用户的占比、留存等，了解产品在获客层面上的优势与不足；其中 App 的渠道数据，会根据 iOS，Android 进行细分）
新增用户量：全部新用户数量，包括自然流量和渠道流量
渠道新增用户量：仅计算渠道流量新增用户数（人均访问时长）
版本数据
App 每个版本的使用情况，帮助了解在产品升级的过程中，是否在活跃和留存方面有所改善（版本访问流量、人均访问时长、各版本留存：各版本的用户7日留存
活跃与留存
访问流量
产品的每日访问数据，指标集中在新老用户的访问行为上，提供访问次数、时长、次数分布、访问时段高峰等指标，帮助了解新老用户在使用产品时的一些行为特征
访问用户数
新老用户访问占比新老用户人均使用时长新老用户启动/访问次数 每日/每周启动时段（用户每日访问产品的时段分布、用户每周访问产品的星期分布）
用户留存
提供用户7日，次日，次周，次月留存、的数据，帮助了解新老用户的使用粘性
事件转化
各类关键事件（如收藏，分享，转发，加购等），发生次数、人数以及分布情况、新老用户事件发生次数/人数/人均次数、事件次数的分布
收益类事件转化
用户自定义收益类事件，神策会自动生成该事件的发生次数、人数以及分布情况，会根据您选择的数值类型属性，计算该数值的总值、人均值以及次均值、新老用户收益事件发生次数/人数/人均次数、新老用户收益事件
用户特征（访问省份分布、访问城市分布、访问性别分布、访问操作系统分布、新老用户占比）
2.3进阶用户行为分析
漏斗分析（漏斗模型主要用于分析一个多步骤过程中每一步的转化与流失情况）（举例来说，用户购买商品的完整流程可能包含以下步骤：1.浏览商品；2.将商品添加进购物车；3.结算购物车中的商品；4.选择送货地址、支付方式；5.点击付款；6.完成付款）
留存分析(留存分析是一种用来分析用户参与情况/活跃程度的分析模型，考查进行初始行为后的用户中，有多少人会进行后续行为,这是衡量产品对用户价值高低的重要指标)
分布分析、归因分析、用户路径分析、间隔分析、自定义查询
3、需求总览：业务域分析
3.1交易域
购物车分析（多维分析：品类、人群、时段）（7日加购总数、提交总数、取消总数）
订单GMV分析（多维分析：终端，地域，品类）(当日GMV总额、当日订单支付总额、当日下单人数客单价分析、7日取消订单数、取消订单用户数、退货次数、退货用户数、GMV近30日变化趋势
GMV各端贡献情况（平台类型，GMV，订单量，下单人数，客单价，笔单价）（下单金额分布（1000以下，1000-2000,2000-3000,3000-4000,4000+）))
7日商品销售情况（商品名称，商品品类，店铺，购买次数，购买人数，销售额）、各品类商品销量趋势（品类，日期，购买次数，购买人数，销售额）、店铺商品销量占比（店铺，购买次数，购买人数，销售额）
复购分析（多维分析：品类，人群，终端，地域）7日各端复购率、7日购买频次分析（1次，2-3次，3-4次，4-5次）、订单实时分析、订单量分钟级、订单量小时级、订单用户趋势分析）
3.2营销域
优惠券分析
优惠券抵扣力度（优惠券，日期，抵扣金额）、优惠券使用情况（优惠券，日期，使用次数）
团购分析(团购订单趋势、参团用户趋势、各品类开团数、各品类成团数
秒杀限时购分析（秒杀订阅人数、秒杀成交订单趋势、秒杀支付类型趋势）
其他营销活动（国庆大豪礼、金秋大放送、活动地域趋势分析、活动订单趋势分析）
3.3运营活动域（广告运营位分析、曝光度、点击率、转化率、拉新注册分析、渠道分布、转化率
3.4会员域（消费情况、充值情况、会员等级分布）
4、整体方案设计
4.1数据收集（主要数据类别：用户行为日志数据、业务数据、历史数据、其他第三方数据）
4.2核心处理流程
数据采集汇聚
用户行为数据（1、日志前端埋点，生成日志数据；2、数据采集；3、kafka缓存；4、Flume采集落地hdfs；5、日志预处理；6、落hive数仓明细层）
业务数据（1、业务系统增删改数据库，形成数据；2、Sqoop/DataX数据抽取；3、落hive数仓明细层；4、增量合并处理；）
数据仓库 & OLAP分析平台
模型设计
数仓分层运算
各类数据的输出
需要查询的明细数据，入库hbase、（用户画像标签明细，用户行为序列明细）、需要做规范模型分析的，由kylin映射、 需要做深入行为分析的，入库clickhouse（或者kudu+impala）
数据服务
固定报表查询（需要查询的固定报表数据，入库mysql/HBASE）（日新、日活、pv、留存、核心业务转化、关键路径转化、关键事件报表，gmv日报周报月报等）
规范多维分析（原料数据，入库kylin，基于kylin的restapi，开发上层olap平台）
进阶深入用户行为分析（入库kudu+impala （click house），基于jdbc，开发上层olap平台）
4.3管理辅助系统
Azkaban任务调度系统、Sqoop/datax业务库数据抽取、Atlas元数据和血缘管理、其他自研系统
5、数据埋点说明
日志埋点，是业务系统开发端的工作（作为数据开发人员的我们，仅需提出数据埋点需求，对具体实现技术仅作基本了解）
5.1埋点技术介绍
5.2埋点日志数据说明
埋点生成的日志数据，统一设计为JSON格式；
各个终端渠道的埋点日志，都由公共属性字段，和事件属性字段组成；1、不同终端渠道，公共属性字段略有不同；2、事件属性则根据事件类型，灵活多样；
6、业务数据说明
业务数据，是由业务系统（程序）根据用户的业务操作，在业务系统数据库（比如mysql）中记录下来的重要事务性数据（比如，订单信息，用户注册信息，积分信息，物流信息，商品信息等，通常至少几十张表，业务越丰富，表越多，上百是常事）
6.1、订单交易信息表（oms_order_item、oms_order_operate_history、oms_order_return_apply、oms_order_return_reason）；
6.2、产品信息表（pms_album、pms_album_pic、pms_brand、pms_comment、pms_product、pms_product_category）；
6.3、优惠券信息表（sms_coupon）；
6.4、限时购秒杀信息表（sms_flash_promotion）；
6.5、营销广告位信息表（sms_home_advertise）；
6.6、会员信息表（ums_member、ums_member_level、ums_member_login_log）；
6.7、购物车信息表（oms_cart_item）等等
7、数据建模理论
7.1经典建模方法论：三范式建模
第一范式（1NF）：每一列都是不可分割的原子数据项
第二范式：在1NF基础上，非码属性必须完全依赖于主码（在1NF基础上消除非主属性对主码的部分函数依赖）
第三范式（3NF）：在2NF的基础上，任何的非主属性不依赖于其他非主属性 （在第二范式基础上消除传递依赖）
7.2 经典建模方法论：维度建模
基本概念
事实：现实发生的某件事
维度：衡量事实的一个角度
事实表：记录事实的表；比如，订单表，注册表，购物车，退货表，浏览日志表
维度表：对维度的详细描述信息；比如，地域维表，产品维表，品类维表，栏目维表，时间维表；
对事实表，假如要计算pv数（指标 | 度量）
我们可以按如下口径来统计：
总pv数
每个栏目的pv数
每个省份的pv数
每个商品品类的pv数
每个省份下每个栏目的pv数
从这些需求中可以看出，同一个指标，可以通过多种角度（口径）去统计
这些角度，或口径，就叫“维度！”
维度组合中的维度越多，统计出来的事实指标粒度越细
维表举例
栏目维度表：
栏目id，栏目名称
lm1,生鲜水产
lm2,冲调饮品
lm3,智能设备
地域码维表：
地域码 省 市
11010 湖北省,武汉市
01010 山西省,临汾市
时间维表：
日期 季度 周数 周几 销售季 活动期间
2019-10-21 4 38 monday
2019-10-21 4 38 monday
维表的作用：可以对统计维度进行人性化的诠释，可以丰富维度内容；
维度建模经典模型
星型模型（星型模式的核心是一个大的中心表（事实表），一组小的附属表（维表））
雪花模型（雪花模式是星型模式的扩展，其中某些维表被规范化，进一步分解到附加表（维表）中）
星座模型（数据仓库由多个主题构成，包含多个事实表，而维表是公共的，可以共享，这种模式可以看做星型模式的汇集，因而称作星系模式或者事实星座模式）
8、项目建模：流量域方案
以Event事件表为中心事实表，以user，页面频道信息，产品信息，活动信息等为关联维表
9、项目建模：业务域方案
按不同事实主题建设宽表（交易域、营销域、活动域、广告域、会员域）
10、项目建模：画像域方案
用户基本属性标签表、用户订单属性标签表、用户退换货属性标签表、用户购物车属性标签表、用户活跃属性标签表、用户偏好属性标签表

二、数仓整体说明
1.1技术选型（数据采集：FLUME、存储平台：HDFS、基础设施：HIVE 、运算引擎：SPARK SQL、资源调度：YARN、任务调度：AZKABAN、元数据管理：ATLAS）
1.2分层设计：
分层原因（数据仓库中的数据表，往往是分层管理、分层计算的，所谓分层，具体来说，就是将大量的数据表按照一定规则和定义来进行逻辑划分；
ADS层： 应用服务层；DWS层：数仓汇总层；DWD层：数仓明细层；ODS层：操作数据（最原始的数据）层 – 贴源层；DIM层：存储维表
ODS层：对应着外部数据源ETL到数仓体系之后的表！
DWD层：数仓明细层；一般是对ODS层的表按主题进行加工和划分；本层中表记录的还是明细数据；
DWS层：数仓汇总层；
ADS层： 应用层，主要是一些结果报表；
分层的意义：数据管理更明晰；运算复用度更高；需求开发更快捷；便于解耦底层业务（数据）变化；
分层详解
ODS层（数据内容：存放flume采集过来的原始日志，存储格式以json格式文本文件存储，存储周期：3个月）
DWD层（数据内容：对ODS层数据做ETL处理后的扁平化明细数据，存储格式：以orc / parquet文件格式存储，存储周期：6个月）
DWS层（数据内容：根据主题分析需求，从DWD中轻度聚合后的数据，存储格式：以ORC/PARQUET文件格式存储，存储周期：1年）
ADS层（数据内容：根据业务人员需求，从DWS计算出来的报表存储格式：以ORC/PARQUET文件格式存储，存储周期：3年）
DIM层（存储各种维表）
1.3模型设计：
ODS层：操作数据层，建模方法：与原始日志数据保持完全一致，数据备份；
存储周期：相对来说，存储周期较短；视数据规模，增长速度，以及业务的需求而定；对于埋点日志数据ODS层存储，通常可以选择3个月或者半年；存1年的是土豪公司（或者确有需要）
数据规模
假如：公司用户规模1000万，平均日活400万，平均每个用户访问1.2次，每个用户平均每次访问时长10分钟，按经验，每个用户平均每 5~10 秒产生一条事件，则每次访问，将产生10分钟60秒/10 = 60条事件日志，则，每天产生的日志总条数：400万1.260条 = 28800 万=2.88亿条日志（2-3亿）
每条日志大小平均为0.5k，则每日增量日志大小为：28800万0.5k = 288005M= 144G（100多个G），每月累积增量为：144G30 = 4.3T(2-4T)，假如要存储1年的数据量，则1年的累计存储量为：51.6T(30-50T)，考虑，增长趋势： 预估每月增长20%，则1年的累计存储量为：接近100T
注：在这里也可以估算实时流式计算中的数据量，假如最高峰值时，每秒同时在线人数有10万，则在此峰值期间，每秒将有50万条日志产生
数据采集：采集源：KAFKA ；TOPIC：app_log, wx_log,web_log；采集工具：FLUME；
创建外部表：由于原始数据是普通文本文件，而文件内容是json格式的一条一条记录，将数据按json格式进行映射（这需要外部工具包JsonSerde 的支持）
下载 json-serde-1.3.8-jar-with-dependencies.jar 并上传到 Hive的/lib库目录下
如果需要，也可以把本jar包安装到本地maven库
bin\mvn install:install-file -Dfile=d:/json-serde.1.3.8.jar -DgroupId=“org.openx.data” -DartifactId=json-serde -Dversion=“1.3.8” -Dpackaging=jar
create external table ods.app_event_log
(
account string,
appId string,
appVersion string,
carrier string,
deviceId string,
deviceType string,
eventId string,
ip string,
latitude double,
longitude double,
netType string,
osName string,
osVersion string,
properties map<string,string>,
releaseChannel string,
resolution string,
sessionId string,
timeStamp bigint
)
partitioned by (y string,m string,d string)
row format serde ‘org.openx.data.jsonserde.JsonSerDe’
stored as textfile
;
DWD层（ods—>(etl)dwd）（spark）（dwd.app_event_dtl）
建模思想：不完全星型模型，事实表中，不是所有维度都按维度主键信息存储（维度退化）
地域维度信息：年月日周等时间维度信息，这些维度信息，基本不会发生任何改变，并且在大部分主题分析场景中，都需要使用，直接在事实表中存储维度值
页面信息：页面类别信息，频道信息，业务活动信息，会员等级信息等，可能发生缓慢变化的维度信息，事实表中遵循经典理论存储维度主键，具体维度值则在主题分析计算时临时关联
事实表（app_event_detail：APP-Event事件明细表；web_event_detail：WEB-Event事件明细表；wxapp_event_detail：小程序-Event事件明细表）
维度表coupon_info、ad_info、campain_info、lanmu_info、page_info、page_type、pindao_info、promotion_location、huodong_info、miaosha_info、product、product_detail、product_type、shop_info、tuangou_info、user_info）
清洗过滤
1，去除json数据体中的废弃字段（前端开发人员在埋点设计方案变更后遗留的无用字段）：
2，过滤掉json格式不正确的（脏数据）
3，过滤掉日志中account及deviceid全为空的记录
4，过滤掉日志中缺少关键字段（event/eventid/sessionid 缺任何一个都不行）的记录
5，过滤掉日志中不符合时间