2023.4.3数仓项目捋一捋
数仓项目捋一捋
初步认识
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层。
汇总模型设计
汇总模型的设计参考上述整理出的指标体系（主要是派生指标）即可
2023.4.3数仓项目捋一捋相关推荐
- 大数据千亿级离线数仓项目第一天 环境部署和etl
千亿级数仓项目第01天讲义 课程目标 了解大数据离线数仓架构 了解项目部署环境(数据规模和集群规模) 掌握ETL工具 Kettle常用组件的使用 能够掌握kettle作业与转换区别以及linux部署 ...
- CDH数仓项目(一) —— CDH安装部署搭建详细流程
0 说明 本文以CDH搭建数据仓库,基于三台阿里云服务器从零开始搭建CDH集群,节点配置信息如下: 节点 内存 安装服务角色 chen102 16G cloudera-scm-server chen1 ...
- 本地数仓项目(四）—— 即席查询
1 背景 本文描述本地数仓项目即席查询相关内容,主要涉及即席查询工具包括Presto.Druid.Kylin. 本文基于文章<本地数据仓库项目(一) -- 本地数仓搭建详细流程> 和< ...
- 电商离线数仓项目实战（下）
电商离线数仓项目实战(下) 电商分析--核心交易 文章目录 电商离线数仓项目实战(下) 电商分析--核心交易 一.业务需求 二.业务数据库表结构 1. 数据库表之间的联系 img 2. 业务数据库-- ...
- 本地数仓项目(二)——搭建系统业务数仓详细流程
1 说明 本文基于<本地数据仓库项目(一)--本地数仓搭建详细流程>业务数据,在本地搭建系统业务数仓. 根据模拟sql脚本生成业务数据,依次执行生成业务数据即可. sql脚本提供如下 链接 ...
- 【大数据数仓项目集群配置 一】
本文用于记录我的第一次内网大数据集群配置过程. 本篇主要实现基础配置. 配置使用的软件版本和脚本参考自尚硅谷,链接如下: 链接: https://www.bilibili.com/video/BV1r ...
- 大数据电商离线数仓项目-上篇
下一篇:电商数仓项目-下篇 文章目录 第1章 数仓分层 1.1 为什么要分层 1.2 数据集市与数据仓库概念 1.3 数仓命名规范 1.3.1 表命名 1.3.2 脚本命名 1.3.3 表字段类型 第 ...
- 【项目】数仓项目（四）
总结 1)数仓概念总结 [1]数据仓库的输入数据源和输出系统分别是什么? 输入系统:埋点产生的用户行为数据.JavaEE 后台产生的业务数据 输出系统:报表系统.用户画像系统.推荐系统 2)项目需求及 ...
- 出大事了！IBM的数仓项目黄了，赔了好几亿！
这是彭文华的第182篇原创 其实建模的文章写了不少了,但是都还停留在什么星型.雪花型这些比较粗浅的内容层面. 其实,建模这件事情是个能力要求非常高的技术活儿.而且这个活儿不是说公司牛.技术牛就能搞定的 ...
最新文章
- 基于Spring Boot + Dubbo的全链路日志追踪(一)
- 【DND图形库】一、简介与环境配置
- php运算符的特殊用法
- md文件生成Java代码_Beetlsql自定义生成entity,mapper,md代码
- stm32cubemx中文_用 STM32 通用定时器做微秒延时函数（STM32CubeMX版本）
- 主机文件复制到Ubuntu系统中
- java11和13_Java1113
- 河南省初三计算机考试题库,河南省计算机等级考试—VB题库
- 中小企业 IT 运维福利：快速构建 on-call 机制
- python2添加pip,无法在python2.6中使用PIP更新/添加任何包
- C# 连接 Exchange 发送邮件
- Android8.1 swap空间不够编译失败:ckati failed with: signal: interrupt
- 利用vb进行autocad图形格式的批量自动转换.pdf_ReaConverter Lite图像批量转换器下载V7.607官方版...
- 犀牛脚本插件-python-vb-编辑使用方式-rhino脚本插件
- Tik Tok账号被封了怎么办？
- Object-Contextual Representations for Semantic Segmentation论文解读
- Detach Procedure
- Linux下vi命令编辑器怎样编辑，怎样保存退出
- 【基于STM32F103+AS608的智能打卡系统】
- CISCO交换机配置命令及释义