数仓项目捋一捋
初步认识
1.数仓需具备
数据存储、管理(一些数据混乱)、分析计算(分类,聚合,汇总,挖掘更大价值)
2.对于企业意义
往往作为企业BI(BI重度依赖数据,从大量数据去挖掘有用信息,帮助企业决策)组件
3.典型特点
可以保存历史数据
多一条分析数据的维度,以史为镜,预测未来
核心架构
Hive是数据仓库的主体
官网定义:大数据的数据仓库工具
存数据在分布式、可扩展的海量存储系统HDFS
业务系统:企业当中用来支撑核心业务的系统,例如做电商,就要有线上购物平台,用于用户下单,支付等的平台,就需要有电商系统来支持,即业务系统
数据仓库的数据来自业务系统
业务系统的数据来源:来自数据库的业务数据和埋点获取的用户行为日志
怎么来的:
业务数据:商品信息、订单信息…电商后台,客户端,
意义:拿到所有的订单记录,可以分析某个季度订单总额多少,拿到所有的支付记录,可以拿到某年或某季度的支付总额多少
用户行为日志:典型的前端埋点,js代码监听页面当中所有元素的行为,比如按钮,图片,超链接,输入框等等各种各样的元素,只要捕捉到了,就能抓取信息,将信息发送到专门用来接收用户行为日志的日志服务器上,日志服务器接受到请求,就会把日志落盘写到日志文件当中
意义:观察用户行为习惯,进行针对性地推荐等等
怎么放入数据仓库?
数据库的数据传输用:一些同步工具DataX Maxwell或采集工具
DataX是基于查询的同步工具、Maxwell是基于bingo(数据变更日志)
用户行为日志的数据传输用:Flume
最后都是放在HDFS的路径上
HDFS的数据放到Hive中的表(从文件到表)用load
接下来,为数据建模
:对数据进行更加合理、更加有条理地存储和管理(刚拿过来的数据混乱,杂乱不清晰)
建模后长这样:
每一次都有一堆表
要清楚每一层的数据从哪来
第一层从采集传输的路径而来,第二层从第一层来,逐层往后
每层做专门的处理
数据仓库不是数据最终目的地
是最后的应用:BI应用、报表应用(把数据用一些更生动的图形表示出来)
核心工作:数据仓库(建模,建表(表结构),数据处理逻辑(写sql))
数据仓库如何运行/运行数据仓库注意什么问题?
执行sql注意的问题:顺序、重复执行(因为数据会更新,所以要定时)
时常以天为单位,攒够一批数据,每天晚上24点后跑
最后调度,执行起来
常用工具:Dolphin Scheduler 工作流程定时调度器(还有阿兹卡班)
工作流程特点:由多个工作单元组成 ,工作单元有前后依赖关系
工作流定时调度器使用逻辑:1.明确有哪些工作的单元及其依赖关系 2.定时,确定好开始时间即可
建模方法论
什么叫建模:将数据有序的组合和存储起来之后,数据才能得到高性能、低成本、高效率、高质量的使用
遵循的理论和方法叫 模型(E-R模型、维度模型)
E-R模型
将复杂的业务通过实体和关系进行呈现
规范化:范式,就是为了减少数据冗余,增强数据一致性,经常选三范式,就是只遵守到第三范式,虽然范式越高,数据冗余越低,但表被撕得更碎
1.第一范式1NF核心原则就是:属性不可切割
2.第二范式2NF核心原则:不能存在非主键字段部分依赖于主键字段,”部分函数依赖“
3.第三范式3NF核心原则:不能存在传递函数依赖
这种建模方法得出发点是整合数据,其目的是将整个企业的数据进行组合和合并,减少数据冗余性,增强一致性,不合适直接用于分析统计(1.学习成本高,表零散,多2.性能差,表太多,要join太多表)
维度模型
将复杂的业务通过事实和维度进行呈现
事实通常对应业务流程(一个个不可拆分的行为事件,例如电商交易中的下单,取消订单,付款,退单等),维度通常对应业务过程时所处的环境(何人何时何地…)
就对应采集用户行为日志过程的:行为信息和环境信息
中心思想:维度模型可以完整描述一个业务操作事件,什么人在什么时候,下单了什么
关注如何让用户更快分析,实现较好的大规模查询性能
缺点就是:数据冗余(存储、数据不一致)
对于Hive数仓而言,数据冗余会是很大影响嘛?
因为可扩展,所以存储影响不大;数据不一致也影响不大,因为要出现该问题,就是在随机修改某个数据,有的修改成功,有的没修改成功,才会出现这样的问题。
但是在数仓里的数据,一般不会去修改,都是往里写,几乎不会再去随机修改。
所以也是可接受的。维度模型更适合,ER模型更适合关系型数据库
数据通道
采集数据的集群要求:说白就是对三条数据通道的保证
1.日志一条 2.业务数据中的全量表算一条 3.业务数据中的增量表一条
用户行为日志数据通道
测通道通不通,怎么测?
首先得把通道涉及的进程都提起来,就是得保障Kafka的启动,Kafka要起来就得先Zookeeper起来,Hadoop是必须得起来(HDFS),然后Flume也得启起来
接着开一个Kafka的客户端消费者,消费一下目标的topic,如果能消费就说明有数据,没有就是没数据,再看日志排查
全量表数据通道
如何测有没有通:
保证Mysql有数据,用DataX同步,执行同步脚本,如果数据能出现在HDFS,就说明已经通
增量表数据通道
首先先启Zookeeper,再启Kafka,再启Flume,Maxwell,整个通道起来
测试通道通不通:
做增量表,首次做全量(使用Maxwell 的bootstrap功能),后续做增量。
测增量,通道起来后,执行jar包往MySQL写数据,只要写数据就会生成bingo,然后到Kafka,到HDFS
首日全量和增量走的通道一样,所以测一条就行
事实表
作为数仓维度建模的核心。紧紧围绕着业务过程来设计。包含与该业务过程有关的维度引用(维度表外键)以及该业务过程的度量(通常是可累加的数字类型字段)
特点:细长,列少,行多,行的增速快
分类:事实事实表、周期快照事实表和累积快照事实表
事务事实表
占据主要地位
用来记录各业务过程的原子操作事件,即最细粒度
设计流程
四步走:1.选择业务流程 2.声明粒度 3.确定维度 4.确定事实,即每个业务过程的度量值
不足:可支撑与各业务过程相关的各种统计粒度的需求。逻辑复杂,效率低下
比如:1.存量型指标 账户余额,存货 2.多事务关联统计 统计最近30天,用户下单到支付的时间间隔平均值,逻辑不复杂,但大表join大表
所以有了
周期快照事实表
该事实表以具有规律性的、可预见的时间间隔来记录事实,分析一些存量型指标(商品库存)或状态型(空气湿度、行驶速度)
设计流程:
1)确定粒度 2)确认事实
1确定粒度:确定采样周期和维度,如统计某个仓库的库存,采样周期一般一天,维度为仓库和商品
2 确认事实:指标为统计每个仓库每种商品的库存,则事实为商品库存
事实类型
可加事实、半可加事实、不可加事实
可加事实:全都可累加
半可加:仓库,商品维度可加,时间维度不可加
不可加:比率型事实
累积型快照事实表
累积型快照事实表通常具有多个日期字段,每个日期对应业务流程中的一个关键业务过程(里程碑)。
在求时间间隔,可用这个,高效很多
设计流程
和事务事实表很相似
1.确定业务过程 2.声明粒度 3.确定维度 4.确实事实
不同:
1.业务过程需要关联多个关键业务过程,多个业务过程对应一张累积型快照事实表
3.选择与各业务过程的维度,每各业务过程均需要一个日期维度
维度表
是维度建模的基础和灵魂。围绕业务过程的环境而设计。主要包含一个主键和各种维度字段,维度字段成为维度属性
设计过程
1.确定维度
在设计事实表的时候,已经确定了维度,理论上要每个相关维度均需要一张维度表,但可能有维度相同的情况,这种时候就只要创建一张维度表即可,保证维度唯一性。除此之外,如果维度属性很少,只有一个名称,就不创建维度表了,直接加到事实表中。这称为维度退化
2.确定主维表和相关维表
均指业务系统中与某维度相关的表。
例如业务系统中与商品相关的表有sku_info,spu_info,base_trademark,base_category3,base_category2,base_category1等,其中sku_info就称为商品维度的主维表,其余表称为商品维度的相关维表。维度表的粒度通常与主维表相同。
电商常识:
sku=stock keeping unit 库存量基本单位
spu=standard product unit 商品信息聚合的最小单位,是一组可复用、易检索的标准化信息集合
表同一类商品,同一spu的商品可以共用商品图片、海报、销售属性等
平台属性和销售属性
3.确定维度属性
遵循三点要求:
1。尽可能生成丰富的维度属性
2.进来不使用编码,而使用明确文字说明,一般可以编码和文字共存
3.尽量沉淀出通用的维度属性
维度设计要点
1.规范化与反规范化
规范化是指使用范式设计数据库的过程,减少数据冗余,增强一致性。通常规范化之后一张表的字段会被拆分到多张表
反规范化是将多张表的数据,冗余到一张表,减少join操作,提高查询性能。
规范化得到的维度模型称为雪花模型,反规范化得到的为星型模型
2.维度变化
数仓一个重要特点就是反映历史的变化,所以如何保存维度的历史状态是维度设计的重要工作之一,保存维度数据的历史状态,通常有两种做法:全量快照表和拉链表
1)全量快照表
计算周期,每天一次,保存一份全新的维度数据。
优点简单有效,方便开发维护,理解使用
缺点浪费存储空间,尤其当数据的变化比例比较低时
2)拉链表
意义在于更高效保存维度信息的历史状态
2.1什么是拉链表:记录每条信息的生命周期,一旦一条记录的生命周期结束,就重新开始一条新的记录,并把当前日期放入生效开始日期。
2.2为什么要做拉链表
引入缓慢变化堆
拉链表适合于:数据发生变化, 但是变化频率不高的维度
2.3如何使用拉链表
通过,生效开始日期<=某个日期 且 生效结束日期>=某个日期,能够得到某个时间点的数据全量切片
数据仓库设计
合理的分层,能够使数据体系更加清晰,使复杂问题得以简化。
数据仓库分层规划:
数仓构建流程
数据调研
1)业务调研——2)需求分析——3)总结
1)业务调研目标是: 熟悉业务流程、熟悉业务数据
熟悉业务流程要求做到,明确每个业务的具体流程,需要将该业务所包含的每个业务过程一一列举出来
熟悉业务数据要求做到,将数据(用埋点日志和业务数据表)与业务过程对应起来,明确每个业务过程会对哪些数据产生影响,产生的是什么影响,是增加数据还是修改数据,并且需要明确新增的内容或者是修改的逻辑。
2)需求分析
最典型的需求指标,比如最近一天各省份手机品类订单总额
分析需求时,要明确需求所需的业务过程及维度,例如该需求的业务过程就是买家下单,所需的维度有日期,省份,商品品类。
3)总结
做完了业务分析和需求分析,要保证每个需求都能找到与之对应的业务过程及维度。若有数据无法满足需求的,则需要和业务方沟通,例如某个界面需要新增某个行为的埋点。
明确数据域
数仓除了横向分层外,也需要根据业务情况进行纵向划分数据域。意义在于 便于数据的管理和应用
通常可以根据业务过程或部门来划分,本项目是基于业务过程进行划分,注意一个业务过程只能属于一个数据域
*数据域* | *业务过程* |
---|---|
*交易域* | 加购、下单、取消订单、支付成功、退单、退款成功 |
*流量域* | 页面浏览、启动应用、动作、曝光、错误 |
*用户域* | 注册、登录 |
*互动域* | 收藏、评价 |
*工具域* | 优惠券领取、优惠券使用(下单)、优惠券使用(支付) |
构建业务总线矩阵
这个业务总线矩阵包含维度模型所需的所有事实(业务过程)以及维度,以及各业务过程与各维度的关系。
矩阵的行是一个个业务过程,矩阵的列是一个个的维度,行列的交点表示业务过程与维度的关系。
一个业务过程对应维度模型中一张事务型事实表,一个维度则对应维度模型中一张维度表。
所以 : 构建业务总线矩阵的过程就是设计维度建模的过程。
注意通常只包含事务型事实表,另外两种类型的事实表需要单独设计。
那么又要回顾 事务型事实表的设计流程:选择业务流程—>声明粒度—>确认维度—>确认事实
后续的DWD层和DIM层搭建需要参考 业务总线矩阵
明确统计指标
具体工作是深入分析需求,构建指标体系,其意义是指标定义标准化。
指标体系相关概念
1)原子指标 2)派生指标 3)衍生指标
1.原子指标包含三要素,分别是业务过程、度量值和聚合逻辑
例如订单总额,就是业务过程用户下单,度量值为订单金额,聚合逻辑为sum()求和,通常不会对应有实际统计需求与之对应
2.派生指标
派生指标基于原子指标
派生指标=原子指标+统计周期+业务限定+统计粒度
最近一天各
省份手机品类 = 订单总额 + 最近一天 + 品类为手机 + 省份
订单总额
通常派生指标会对应实际的统计需求。
3.衍生指标
在一个或多个派生指标的基础上,通过各种逻辑运算复合而成。例如比率
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4bLBGzBq-1680960920324)(C:\Users\cx\AppData\Roaming\Typora\typora-user-images\image-20230404002854867.png)]
当需求足够多的时候,这一套指标体系:原子指标、派生指标、衍生指标
必然会出现对应的派生指标相同的情况,这种情况下,就可以考虑将这些公共的派生指标保存下来,目的:减少重复运算,提高数据的复用性。
这些公共的派生指标统一保存在DWS层中。因此DWS层的设计就可以参考我们现有的统计的派生指标。
维度模型设计
维度模型设计参考业务总线矩阵,其中事实表存放在DWD层,维度表存放在DIM层。
汇总模型设计
计周期+业务限定+统计粒度
最近一天各
省份手机品类 = 订单总额 + 最近一天 + 品类为手机 + 省份
订单总额
通常派生指标会对应实际的统计需求。
3.衍生指标
在一个或多个派生指标的基础上,通过各种逻辑运算复合而成。例如比率
[外链图片转存中…(img-4bLBGzBq-1680960920324)]
当需求足够多的时候,这一套指标体系:原子指标、派生指标、衍生指标
必然会出现对应的派生指标相同的情况,这种情况下,就可以考虑将这些公共的派生指标保存下来,目的:减少重复运算,提高数据的复用性。
这些公共的派生指标统一保存在DWS层中。因此DWS层的设计就可以参考我们现有的统计的派生指标。
维度模型设计
维度模型设计参考业务总线矩阵,其中事实表存放在DWD层,维度表存放在DIM层。
汇总模型设计
汇总模型的设计参考上述整理出的指标体系(主要是派生指标)即可