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