离线数据仓库建设
数据仓库的核心是展现层和提供优质的服务。ETL及其规范、分层等所做的一切都是为了一个更清晰易用的展现层。
数仓分层
数仓分层的原则:
- 屏蔽底层复杂业务,简单、完整、集成的将数据暴露给分析层。
- 结合自上而下的建设方法削弱需求变动对模型的影响。
- 高类聚松耦合
- 构建仓库基础数据层,是底层业务数据整合工作与上层应用开发工作相隔离。
分层结构:
ODS(原始数据层):保存最原始的数据集,不需要进行清洗过滤等操作,一般和我们导入数据层是一模一样的。
DWD(明细数据层):基于ODS实现数据的清洗过滤等操作,划分对应的主题域及创建对应的主题表
DWS(中间数据层):基于DWD实现数据的预聚合操作以及构建宽表实现
ADS(数据应用层):基于上层的所有数据集实现报表指标实现
DIM维度层
注意:数仓分层内部的表之间不能同层调用表以及不能逆向调用层级的表
数仓建模
数仓建模在哪层建设?
- 我们以维度建模为例,建模是在数据源层的下一层进行建设——DW层
DW层是数仓建设的核心层
建模方法
- 范式建模
该方法的主要由 Inmon 所提倡,主要解决关系型数据库的数据存储。
范式 是符合某一种级别的关系模式的集合。构造数据库必须遵循一定的规则,而在关系型数据库中这种规则就是范式,这一过程也被称为规范化。目前关系数据库有六种范式:第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、Boyce-Codd范式(BCNF)、第四范式(4NF)和第五范式(5NF)。
在数据仓库的模型设计中,一般采用第三范式。符合条件:
- 每个属性值唯一,不具有多义性;
- 每个非主属性必须完全依赖于整个主键,而非主键的一部分;
- 每个非主属性不能依赖于其他关系中的属性,因为这样的话,这种属性应该归类到其他关系中去。
-
维度建模
-
星形建模(Star-schema)
-
雪花建模(Snow-schema)
-
-
实体建模(不常见)
从哲学的意义上说,客观世界应该是可以细分的,客观世界应该可以分成由一个个实体,以及实体与实体之间的关系组成。那么我们在数据仓库的建模过程中完全可以引入这个抽象的方法,将整个业务也可以划分成一个个的实体,而每个实体之间的关系,以及针对这些关系的说明就是我们数据建模需要做的工作。
维度建模详解
维度建模中表的类型
维度建模分为两种表:事实表和维度表
事实表
必然存在的一些数据,像采集的日志文件,订单表,都可以作为事实表。事实表表示对分析主题的度量。
特征:是一堆主键的集合,每个主键对应维度表中的一条记录,客观存在的,根据主题确定出需要使用的数据
事实表分为六类:
- 事务
- 周期快照
- 累计快照
- 无事实
- 聚集
- 合并
维度表
维度就是所分析的数据的一个量,维度表就是以合适的角度来创建的表,分析问题的一个角度:时间、地域、终端、用户等角度。
-
维度表结构
-
跨表钻取
上卷
下钻
-
退化维度
-
多层次维度
-
维度表空值属性(了解)
-
日历日期维度(了解)
维度建模模式
星形模式
最常用的维度建模方式。星形模式以事实表为中心,所有的维度表直接连在事实表上,可能存在数据冗余,查询效率高
雪花模式
雪花模式的维度表可以拥有其他维度表,没有数据冗余,在关联查询的时候性能较低
星座模式
基于多张事实表,共享维度信息,由星形模式演变,特性相似
维度建模过程
选择业务过程
维度建模紧贴业务,必须以业务为根基进行建模
声明粒度
在同一事实表中,必须具有相同的粒度
确认维度
确保维度表中不能出现重复数据,应使维度主键唯一
确认事实
同一事实表中的所有度量必须具有相同的粒度
数仓建设实战思路
模型和规范
数仓建设的核心思想:从设计、开发、部署和使用层面,避免重复建设和指标冗余建设,从而保证数据口径的规范和统一,最终实现数据资产全链路关联、提供标准数据输出以及建立统一的数据公共层。
数仓建设主要从两个方面进行,模型和规范,所有业务进行统一化
- 模型
- 模型分层
- 数据流向
- 规范
数据层具体实现
- 数据源层ODS
- 数据明细层DW
- 数据轻度汇总层DM
- 数据应用层ADS
实际开发注意事项
请勿操作自己管理及授权表之外的其他库表
未经授权,请勿操作生产环境中其他人的脚本及文件
在修改生产环境脚本前,请务必自行备份到本地
请确认自己的修改操作能迅速回滚
生产环境中表名及字段等所有命名请遵循命名规则
ETL过程
ETL前提
确认ETL范围:通过对目标表文件的收集
选择ETL工具:a.考虑资金 b.运行的平台、对源和目标的支持度、数据抽取管理监控、对异常处理
确认解决方案:抽取分析、变化数据的捕获、目标表的刷新策略、数据的转换以及数据验证
ETL原则
尽量对数据进行预处理。保证数据的安全性、集成与加载的高效性。
ETL的过程是主动的‘拉取’,而不是内部的’推送‘,其可控性将大大增加。
流程化的配置管理
数据质量的保证:正确性、一致性、完成性、有效性、可获取性
Extract数据抽取
- 抽取方式
从源数据拉取数据(pull)、请求源数据推送到数据仓库(push)。一般来讲,后一种方式需要增加业务系统的功能才能进行推送,这个在现实情况中不大行的通,一方面影响业务系统的性能,另一方面增加开发者的工作量,理论上讲,数据仓库不应该要求对源系统做任何的改造,因此一般都采用拉取数据的方式。
- 抽取类型
全量抽取、增量抽取。如果数据量小并且容易处理,一般采用全量抽取即可。如果数据量很大,就只能抽取变化的源数据,即最后一次抽取以来发生了变化的数据。所以,对所有的维表采用全量抽取,对业务表采用增量抽取的方式
Transform数据转换
- 格式内容问题产生的原因
- 不同数据源采集而来的数据内容和格式定义不一致
- 时间、日期格式不一致清洗,根据实际情况,把时间/日期数据转换成统一的表示方式
- 数据类型不符清洗
- 逻辑错误
- 数据重复清洗
- 矛盾内容修正
- 缺失值
- 信息被遗漏,实时性高还未来得及判断
- 删除元组,只适合在对象有多个属性缺失值
- 数据填充用一定的值去填充空值,从而使信息表完备化
- 去空处理 null-string’\N’
- 不符合业务需求的数据
- 越界数据