数据仓库
2024-07-05 15:27:57 0 举报AI智能生成
数仓建设的相关知识
作者其他创作
大纲/内容
数仓概念
概念
有规律的存放数据的地方
组成
数据库
用于收集、清理、转换和存储来自各个操作系统或者外部源数据的软件程序
特点
Inmon
面向主题的
有分类
集成的
数据是统一的，内聚的(同一规范存储)
随时间变化的
反应数据状态，包换数据的全生命周期
非易失，稳定的
保留大量历史数据，增量更新
Kimball
为查询和分析定制的交易数据的副本
数仓的必要性
减少重复开发，避免反复造车轮
清晰数据结构，减少数据冗余，提高信息一致性
方便查询
让企业能够利用数据进行更优的决策
主要数仓架构
数据集市架构
理解:部门级别的单一主题
优点:周期短、见效快、数据量小
缺陷:跨部门数据不统一，共享不流畅(各自为王)
Inmon企业工厂架构
流程:业务系统->数据暂存区(ETL)->三范式数仓->分主题的数据集市->查询使用
流程:业务系统->数据暂存区(ETL)->三范式数仓->分主题的数据集市->查询使用
特点：自上而下，要全盘考虑好数据基础，统一分散的各个业务域，然后再着手按照三范式设计标准设计数据仓库
缺点难度较大
Kimball数据仓库架构
流程
业务系统->数据暂存区(ETL)->维度仓库(一个主题就是独立数据集市)->查询使用
特点
自下而上，针对某一个数据域或者业务进行维度建模，得到最细粒度的事实表和维度表，形成适用于某一个数据域、业务的数据集市之后，再集成各个数据集市为数据仓库。这其中的要点就是保持各集市之间的一致性维度和一致性事实。
反规范化处理,存在一定程度的数据冗余(退化维度)，提高查询性能
混合型数仓架构
流程
业务系统->数据暂存区(ETL)->三范式数据仓库->多维数据仓库->查询使用
特点
既可以利用规范化设计消除数据冗余，保证数据的粒度足够细;又可以利用多维结构更员活地在企业级实现报表和分析
数仓建设
建设过程
理解需求
确定业务目标和业务战略，确定业务领域
对相关人员进行访谈，收集信息
尽可能的记录关键指标和计算口径
整理需求并进行优先级排序，要事第一的原则
定义和维护数仓架构和商业智能技术架构
需要根据实际的情况进行选型
制定发布计划
开发数据仓库和数据集市
制定数据转换规范
加载数据仓库
确定数据加载方式
选取商务智能产品
根据目标客户，匹配对应工具
维护数据产品
构建好之后，要扩展，补充
维护以质量和满足需求为主旨
建模方法
范式建模
Inomn
Inomn
一般用于OLTP系统中
优点
规范化处理，降低数据几余及解决数据一致性问题
缺点
查询时需要许多表关联得出结果，降低查询性能能力要求比较高，实施周期比较长
三范式的建模方法
第一范式
无重复的列
属性不可分割
第二范式
属性完全依赖主键
不存在部分依赖【例如:A+B可以得出CB也可以得出C.那么存在部分依赖】
第三范式
不存在传递依赖【例如:通过A可以得出B然后通过B得出C】
属性不能传递依赖主属性
维度建模
表类型
事实表
概念
发生在现实世界中的操作型事件，其所产生的可度量数值，存储在事实表中。
类型
事务事实表
也称原子事实表，描述业务过程，跟踪定义业务过程的个体行为，保存的是最原子的数据(类似银行交易流水，日志信息，每一次相关的change信息都记录下来，生成一行新的数据)
周期快照事实表
以一个周期为时间间隔，来记录事实，一般周期可以是每天、每周、每月、每年等
可以理解为按照某个时间维度聚合的表，每行数据包含汇总后的度量值
累积快照事实表
用来描述过程开始和结束之间的关键步骤事件，覆盖过程的整个生命周期，通常具有多个日期字段来记录关键时间点;
一行数据中体现了一个事实的全生命周期
聚集事实表
聚集，就是对原子粒度的数据进行简单的聚合操作，目的就是为了提高查询性能
合并事实表
这种事实表遵循一个原则，就是相同粒度，数据可以来自多个过程，但是只要它们属于相同粒度，就可以合并为一个事实表
一致性事实
不同数据集市中的相同事实定义一致
维度表
概念
维度表可以看成是用户用来分析一个事实的窗口，它里面的数据应该是对事实的各个方面描述，比如时间维度表，地域维度表，维度表是事实表的一个分析角度
建模流程
调研
数据调研
业务调研
需求调研
数据域划分
划分不同的主题
总线矩阵构建
是什么 --行是业务过程，列是公共维度(一致性维度)，组成的矩阵
事实与维度的交叉点，确定能从哪些维度分析哪些事实
明确统计指标
规范定义
表命名规范
索引命名规范
分区命名规范
存储过程命名规范
调度作业命名规范
文档规范
脚本开发规范
流程规范
指标命名规范
模型设计
建模过程
选择业务过程
声明粒度
确认维度
确认事实
分层
ODS(Operational Data Store-操作存储数据层
是最接近数据源中数据的一层，为了考虑后续可能需要追溯数据问题，因此对于这一层就不建议做过多的数据清洗工作，原封不动地接入原始数据即可
DWD(Date Warehouse Detail-数据明细层
从 ODS 层中获得的数据按照主题建立各种数据模型
DWM(Date Warehouse iddle-数据中间层
该层会在 DWD 层的数据基础上，数据做轻度的聚合操作，生成一系列的中间表，提升公共指标的复用性，减少重复加工。
DWS(Date Warehouse Service-数据服务聚合层
DWS 层为公共汇总层，会进行轻度汇总，粒度比明细数据稍粗，基于 DWD 层上的基础数据，整合汇总成分析某一个主题域的服务数据，一般称为宽表
DIM(Dictionary Data Layer-维表层)
一些维度属性表，从哪些角度可以分析数据
APP(应用层)
主要是提供给数据产品和数据分析使用的数据，一般会存放在 ES、PostgreSq1、Redis 等系统中供线上系统使用，也可能会存在 Hive 或者 Drid 中供数据分析和数据挖
模式
星型
一个事实表，多个维度表
星型模式是以事实表为中心，所有的维度表直接连接在事实表上，像星星一样
雪花
一个事实表，维度表有依赖的维度表
雪花模式的维度表可以拥有其他维度表的
星座
多个事实表，公用维度表
星座模式是基于多张事实表的，而且共享维度信息
实体建模
从哲学的意义上说，客观世界应该是可以细分的，客观世界应该可以分成由一个个实体，以及实体与实体之间的关系组成。
数据加载方式
离线
按时间戳增量
日志表增量
数据库交易日志
消息增量
全量
实时
准实时
涓流式
相对离线调度频率更快
实时
实时流式
目标端积累，队列式消费
特殊名词解释
实体
分析的对象，比如患者
维度
看待问题的角度，从SQL层面就是能够GROUP BY
度量
完全可加
可进行任意维度的汇总
半可加
可进行某些维度的汇总，比如差额
不可加
比如:比率
粒度
可以理解为业务过程中对度量的单位，比如患者的粒度事实表
口径
取数逻辑
指标
通过一定的口径计算出来的结果值
原子指标
不可分割的指标，基于业务事实，没有业务限定，直接取数，不做计算
派生指标
维度+修饰词+原子指标，换句话说就是经过某个口径统计出来的指标
衍生指标
多个派生指标计算出来的
标签
人为的对目标对象运用一定的算法得到的高度精炼的特征标识
分类做记号
自然键
具有一定业务含义的主键，比如患者的唯一号，住院号
持久键
保持永久不会变化，比如病案号、身份证号
代理键
无意义主键，行id
数仓优化
调度优化
耗时长的任务调度开始时间提前
业务比较关注的数据调度时间提前
调度任务剥离，不同项目的调度任务拆分
减少任务的依赖层级
模型优化
减少任务的依赖层级
利用中间临时表，拆分复杂逻辑为多个块
整合表:重善的表，将调度任务和数据合并分区表:合理设计分区，部分大表增加二级子分区
索引:合理增加索引
中间表:数据量大、计算逻辑复杂
拆表:个别字段产出极慢的情况，可以将字段拆分为单独的表
合表:随着数仓的发展，针对业务重善或重复的表，可以进行任务和数据合并
计算资源优化
查询时避免使用*，列出需要的字段
合理使用分区
注意数据倾斜
0 条评论
下一页
