数仓概念
为什么要使用数仓
统一多系统数据,提供一个所有数据的访问点,便于数据分析和计算,为决策提供数据支持
数仓定义
数仓(DataWareHourse),一般缩写为DW,是一个面向主题的、集成的、非易失的且随时间变化的数据集合
面向主题
主题(subject)是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念
- 每一个主题基本对应一个宏观的分析领域
- 在逻辑意义上,它是对应企业中某一宏观分析领域所涉及的分析对象
- 例如“销售分析”就是一个分析领域,因此这个数据仓库应用的主题就是“销售分析”
集成
- 数据仓库的数据是从原有的分散的多个数据库、数据文件和数据端中抽取来的
- 数据来源可能既有内部数据又有外部数据
- 集成方法
- 统一:消除不一致现象
- 总和:对原有数据进行综合和计算
非易失
- 数据仓库中的数据是经过抽取而形成的分析型数据
- 不具有原始性
- 主要供企业决策分析之用
- 执行的主要是“查询”操作,一般情况下不执行“更新”操作
- 一个稳定的数据环境也有利于数据分析操作和决策的制定
随时间变化
- 数据仓库以维的形式对数据进行组织,时间维是数据仓库中很重要的一个维度
- 不断增加新的数据内容
- 不断删去旧的数据内容
- 更新与时间有关的综合数据
和RMDB的区别
两者的使用目的不同,使用数据库是为了查询和存储数据,而使用数据仓库是为分析数据
数据库 | 数据仓库 | |
---|---|---|
本质 | 数据的集合 | 数据的集合 |
定位 | 事务处理OLTP | 数据分析OLAP |
面向群体 | 前端用户 | 管理人员 |
操作 | 增删改查 | 查询 |
数据粒度 | 事件查询 | 维度 |
表结构 | 3NF(三范式) | 星型、雪花 |
OLTP和OLAP的区别
- 联机事务处理OLTP
- On-Line Transaction Processing
- OLTP是传统的关系型数据库的主要应用
- 主要是基本的、日常的事务处理
- 例如银行交易
- 联机分析处理OLAP
- On-Line Analytical Processing
- OLAP是数据仓库系统的主要应用,支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果
对比属性 | OLTP | OLAP |
---|---|---|
读特性 | 每次查询只返回少量的记录 | 对大量的记录进行汇总 |
写特性 | 随机、低延时写入用户的输入 | 批量导入 |
使用场景 | 用户,JavaEE项目 | 内部分析师,为决策提供支持 |
数据表征 | 最新数据状态 | 随时间变化的历史状态 |
数据规模 | GB | TB到PB |
ETL
数据的ETL
- 抽取(Extract)
- 从操作型数据源获取数据
- 转换(Transform)
- 转换数据,使之转变为适用于查询和分析的形式和结构
- 装载(Load)
- 将转换后的数据导入到最终的目标数据仓库
数仓架构
Inmon架构
左边是操作型系统或者事务系统,有数据库在线系统,有文本文件系统等。这些系统的数据经过ETL的过程,加载数据到企业数据仓库中。
企业数据仓库是企业信息化工厂的枢纽,是原子数据的集成仓库,但是由于企业数据仓库不是多维格式,因此不适合分析型应用程序,BI工具直接查询。他的目的是将附加的数据存储用于各种分析型系统。
数据集市,是针对不同的主题区域,从企业数据仓库中获取的信息,转换成多维格式,然后通过不同手段的聚集、计算,最后提供最终用户分析使用,因此Inmon把信息从企业数据仓库移动到数据集市的过程描述为“数据交付”。
Kimball架构
kimball的维度数据仓库是基于维度模型建立的企业级数据仓库,它的架构有的时候可以称之为“总线体系结构”,和inmon提出的企业信息化工厂有很多相似之处,都是考虑原子数据的集成仓库。
这两种结构的相似之处:
- 都是假设操作型系统和分析型系统是分离的;
- 数据源(操作型系统)众多;
- ETL整合了多种操作型系统的信息,集中到一个企业数据仓库。
最大的不同就是企业数据仓库的模式不同:inmon是采用第三范式的格式,kimball采用了多维模型–星型模型,并且还是最低粒度的数据存储。其次,维度数据仓库可以被分析系统直接访问(这种访问方式毕竟在分析过程中很少使用)。最后就是数据集市的概念有逻辑上的区别,在kimball的架构中,数据集市用维度数据仓库的高亮显示的表的子集来表示。
在kimball的架构中,有一个可变通的设计,就是在ETL的过程中加入ODS层,使得ODS层中能保留第三范式的一组表来作为ETL过程的过度。但是这个思想,Kimball看来只是ETL的过程辅助而已。另外,还可以把数据集市和企业维度数据仓库分离开来,这样多一层所谓的展现层(presentationlayer),这些变通的设计都是可以接受的,只要符合企业本身分析的需求。
数仓分层
为什么要分层
- 用空间换时间,通过大量的预处理来提升应用系统的用户体验(效率),因此数据仓库会存在大量冗余的数据;
- 如果不分层的话,如果源业务系统的业务规则发生变化将会影响整个数据清洗过程,工作量巨大
- 通过数据分层管理可以简化数据清洗的过程,因为把原来一步的工作分到了多个步骤去完成,相当于把一个复杂的工作拆成了多个简单的工作,把一个大的黑盒变成了一个白盒,每一层的处理逻辑都相对简单和容易理解,这样我们比较容易保证每一个步骤的正确性,当数据发生错误的时候,往往我们只需要局部调整某个步骤即可。
如何分层
1、数据运营层:ODS(Operational Data Store)
“面向主题的”数据运营层,也叫ODS层,是最接近数据源中数据的一层,数据源中的数据,经过抽取、洗净、传输,也就说传说中的 ETL 之后,装入本层。本层的数据,总体上大多是按照源头业务系统的分类方式而分类的。
一般来讲,为了考虑后续可能需要追溯数据问题,因此对于这一层就不建议做过多的数据清洗工作,原封不动地接入原始数据即可,至于数据的去噪、去重、异常值处理等过程可以放在后面的DWD层来做。
2、数据仓库层:DW(Data Warehouse)
数据仓库层是我们在做数据仓库时要核心设计的一层,在这里,从 ODS 层中获得的数据按照主题建立各种数据模型。DW层又细分为 DWD(Data Warehouse Detail)层、DWM(Data WareHouse Middle)层和DWS(Data WareHouse Servce)层。
2.1、数据明细层:DWD(Data Warehouse Detail)
该层一般保持和ODS层一样的数据粒度,并且提供一定的数据质量保证。同时,为了提高数据明细层的易用性,该层会采用一些维度退化手法,将维度退化至事实表中,减少事实表和维表的关联。
另外,在该层也会做一部分的数据聚合,将相同主题的数据汇集到一张表中,提高数据的可用性,后文会举例说明。
2.2、数据中间层:DWM(Data WareHouse Middle)
该层会在DWD层的数据基础上,对数据做轻度的聚合操作,生成一系列的中间表,提升公共指标的复用性,减少重复加工。
直观来讲,就是对通用的核心维度进行聚合操作,算出相应的统计指标。
2.3、数据服务层:DWS(Data WareHouse Servce)
又称数据集市或宽表。按照业务划分,如流量、订单、用户等,生成字段比较多的宽表,用于提供后续的业务查询,OLAP分析,数据分发等。
一般来讲,该层的数据表会相对比较少,一张表会涵盖比较多的业务内容,由于其字段较多,因此一般也会称该层的表为宽表。
在实际计算中,如果直接从DWD或者ODS计算出宽表的统计指标,会存在计算量太大并且维度太少的问题,因此一般的做法是,在DWM层先计算出多个小的中间表,然后再拼接成一张DWS的宽表。由于宽和窄的界限不易界定,也可以去掉DWM这一层,只留DWS层,将所有的数据在放在DWS亦可。
3、数据应用层:APP(Application)
在这里,主要是提供给数据产品和数据分析使用的数据,一般会存放在 ES、PostgreSql、Redis等系统中供线上系统使用,也可能会存在 Hive 或者 Druid 中供数据分析和数据挖掘使用。比如我们经常说的报表数据,一般就放在这里。
4、维表层(Dimension)
最后补充一个维表层,维表层主要包含两部分数据:
高基数维度数据:一般是用户资料表、商品资料表类似的资料表。数据量可能是千万级或者上亿级别。
低基数维度数据:一般是配置表,比如枚举值对应的中文含义,或者日期维表。数据量可能是个位数或者几千几万。
建模过程
- 选择业务流程
- 确认哪些业务处理流程是数据仓库应该覆盖的
- 记录方式
- 使用纯文本
- 使用业务流程建模标注(BPMN)方法
- 使用同一建模语言(UML)
- 声明粒度
- 用于确认事实中表示的是什么
- 选择维度和事实前必须声明粒度
- 建议从原始粒度开始设计
- 不同的事实可以有不同的粒度
- 确认维度
- 说明了事实表的数据是从哪里采集来的
- 典型的维度都是名词
- 例如:日期、商店、库存等
- 维度表存储了某一维度的所有相关数据
- 例如:日期维度应该包括年、季度、月、周、日等数据
- 确认事实
- 识别数字化的度量(单位),构成事实表的记录
- 和系统的业务用户密切相关
- 大部分事实表的度量都是数字类型的
- 可累加、可计算
- 例如:成本、数量、金额
星型模型和雪花模型
星型模型
- 由事实表和维度表组成
- 一个星型模型中可以有一个或多个事实表,每个事实表引用任意数量的维度表
- 星型模型将业务流程分为事实和维度
- 事实包含业务的度量,是定量的数据
- 维度是对事实数据属性的描述
- 优点
- 简化查询
- 简化业务报表逻辑
- 获得查询性能
- 快速聚合
- 便于向立方体(数据立方体,多维角度分析数据)提供数据
- 缺点
- 不保证数据完整性
- 对于分析需求来说不够灵活
雪花模型
- 一个多维模型中表的逻辑布局
- 由事实表和维度表所组成
- 将星型模型中的维度表进行规范化处理
- 把低基数的属性从维度表中移除并形成单独的表
- 一个维度被规范化成多个关联的表
- 优点
- 一些OLAP多维数据库建模工具专为雪花模型进行了优化
- 规范化的维度属性节省存储空间
- 缺点
- 维度属性规范化增加了查询的连接操作和复杂度
- 不确保数据完整性