@TOC
应用示例
Data warehouse(可简写为DW或者DWH)数据仓库,是在数据库已经大量存在的情况下,它是一整套包括了etl、调度、建模在内的完整的理论体系。
数据仓库的方案建设的目的,是为前端查询和分析作为基础,主要应用于OLAP(on-line Analytical Processing),支持复杂的分析操作,侧重决策支持,并且提供直观易懂的查询结果。目前行业比较流行的有:AWS Redshift,Greenplum,Hive等。
数据仓库并不是数据的最终目的地,而是为数据最终的目的地做好准备,这些准备包含:清洗、转义、分类、重组、合并、拆分、统计等
特性 | 数据仓库 | 事务数据库 |
---|---|---|
适合的工作负载 | 分析、报告、大数据 | 事务处理 |
数据源 | 从多个来源收集和标准化的数据 | 从单个来源(例如事务系统)捕获的数据 |
数据捕获 | 批量写入操作通过按照预定的批处理计划执行 | 针对连续写入操作进行了优化,因为新数据能够最大程度地提高事务吞吐量 |
数据标准化 | 非标准化schema,例如星型Schema或雪花型schema | 高度标准化的静态schema |
数据存储 | 使用列式存储进行了优化,可实现轻松访问和高速查询性能 | 针对在单行型物理块中执行高吞吐量写入操作进行了优化 |
数据访问 | 为最小化I/O并最大化数据吞吐量进行了优化 | 大量小型读取操作 |
数据仓库中涉及到的问题:
在实际的工作中,我们都希望自己的数据能够有顺序地流转,设计者和使用者能够清晰地知道数据的整个声明周期,比如下面左图。
但是,实际情况下,我们所面临的数据状况很有可能是复杂性高、且层级混乱的,我们可能会做出一套表依赖结构混乱,且出现循环依赖的数据体系,比如下面的右图。
为了解决我们可能面临的问题,需要一套行之有效的数据组织、管理和处理方法,来让我们的数据体系更加有序,这就是数据分层。数据分层的好处:
每个公司的业务都可以根据自己的业务需求分层不同的层次;目前比较成熟的数据分层:数据运营层ODS、数据仓库层DW、数据服务层ADS(APP)。
数据运营层:Operation Data Store 数据准备区,也称为贴源层。数据源中的数据,经过抽取、洗净、传输,也就是ETL过程之后进入本层。该层的主要功能:
在源数据装入这一层时,要进行诸如去噪(例如有一条数据中人的年龄是 300 岁,这种属于异常数据,就需要提前做一些处理)、去重(例如在个人资料表中,同一 ID 却有两条重复数据,在接入的时候需要做一步去重)、字段命名规范等一系列操作。
但是为了考虑后续可能需要追溯数据问题,因此对于这一层就不建议做过多的数据清洗工作,原封不动地接入原始数据也可以,根据业务具体分层的需求来做。
这层的数据是后续数据仓库加工数据的来源。数据来源的方式:
数据仓库层从上到下,又可以分为3个层:数据细节层DWD、数据中间层DWM、数据服务层DWS。
数据细节层:data warehouse details,DWD(数据清洗/DWI)
该层是业务层和数据仓库的隔离层,保持和ODS层一样的数据颗粒度;主要是对ODS数据层做一些数据的清洗和规范化的操作,比如去除空数据、脏数据、离群值等。
为了提高数据明细层的易用性,该层通常会才采用一些维度退化方法,将维度退化至事实表中,减少事实表和维表的关联。
数据中间层:Data Warehouse Middle,DWM
该层是在DWD层的数据基础上,对数据做一些轻微的聚合操作,生成一些列的中间结果表,提升公共指标的复用性,减少重复加工的工作。
简答来说,对通用的核心维度进行聚合操作,算出相应的统计指标
数据服务层:Data Warehouse Service,DWS(宽表-用户行为,轻度聚合)
该层是基于DWM上的基础数据,整合汇总成分析某一个主题域的数据服务层,一般是宽表,用于提供后续的业务查询,OLAP分析,数据分发等。
一般来说,该层的数据表会相对较少;一张表会涵盖比较多的业务内容,由于其字段较多,因此一般也会称该层的表为宽表。
数据应用层:Application Data Service,ADS(APP/DAL/DF)-出报表结果
该层主要是提供给数据产品和数据分析使用的数据,一般会存放在ES、Redis、PostgreSql等系统中供线上系统使用;也可能存放在hive或者Druid中,供数据分析和数据挖掘使用,比如常用的数据报表就是存在这里的。
事实表是指存储有事实记录的表,比如系统日志、销售记录等。事实表的记录在不断地增长,比如电商的商品订单表,就是类似的情况,所以事实表的体积通常是远大于其他表。
维度表(Dimension Table)或维表,有时也称查找表(Lookup Table),是与事实表相对应的一种表;它保存了维度的属性值,可以跟事实表做关联,相当于将事实表上经常重复出现的属性抽取、规范出来用一张表进行管理。维度表主要是包含两个部分:
每一层的计算都会有很多临时表,专设一个DWTMP层来存储我们数据仓库的临时表
狭义ADS层; 广义上指hadoop从DWD DWS ADS 同步到RDS的数据
数据集市(Data Mart),也叫数据市场,数据集市就是满足特定的部门或者用户的需求,按照多维的方式进行存储,包括定义维度、需要计算的指标、维度的层次等,生成面向决策分析需求的数据立方体。
从范围上来说,数据是从企业范围的数据库、数据仓库,或者是更加专业的数据仓库中抽取出来的。数据中心的重点就在于它迎合了专业用户群体的特殊需求,在分析、内容、表现,以及易用方面。数据中心的用户希望数据是由他们熟悉的术语表现的。
带有数据集市的数据仓储结构
数据集市就是企业级数据仓库的一个子集,它主要面向部门级业务,并且只面向某个特定的主题。为了解决灵活性与性能之间的矛盾,数据集市就是数据仓库体系结构中增加的一种小型的部门或工作组级别的数据仓库。数据集市存储为特定用户预先计算好的数据,从而满足用户对性能的需求。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。
理论上讲,应该有一个总的数据仓库的概念,然后才有数据集市。实际建设数据集市的时候,国内很少这么做。国内一般会先从数据集市入手,就某一个特定的主题(比如企业的客户信息)先做数据集市,再建设数据仓库。数据仓库和数据集市建立的先后次序之分,是和设计方法紧密相关的。而数据仓库作为工程学科,并没有对错之分。
在数据结构上,数据仓库是面向主题的、集成的数据的集合。而数据集市通常被定义为星型结构或者雪花型数据结构,数据集市一般是由一张事实表和几张维表组成的。
**问:**还是不太明白 ods 和 dwd 层的区别,有了 ods 层后感觉 dwd 没有什么用了。
**答:**嗯,我是这样理解的,站在一个理想的角度来讲,如果 ods 层的数据就非常规整,基本能满足我们绝大部分的需求,这当然是好的,这时候 dwd 层其实也没太大必要。 但是现实中接触的情况是 ods 层的数据很难保证质量,毕竟数据的来源多种多样,推送方也会有自己的推送逻辑,在这种情况下,我们就需要通过额外的一层 dwd 来屏蔽一些底层的差异。
**问:**我大概明白了,是不是说 dwd 主要是对 ods 层做一些数据清洗和规范化的操作,dws 主要是对 ods 层数据做一些轻度的汇总?
**答:**对的,可以大致这样理解。
问答三:app 层是干什么的?
**问:**感觉DWS层是不是没地方放了,各个业务的DWS表是应该在 DWD还是在 app?
**答:**这个问题不太好回答,我感觉主要就是明确一下DWS层是干什么的,如果你的DWS层放的就是一些可以供业务方使用的宽表表,放在 app 层就行。如果你说的数据集市是一个比较泛一点的概念,那么其实 dws、dwd、app 这些合起来都算是数据集市的内容。
**问:**那存到 Redis、ES 中的数据算是 app层吗?
**答:**算是的,我个人的理解,app 层主要存放一些相对成熟的表,能供业务侧使用的。这些表可以在 Hive 中,也可以是从 Hive 导入 Redis 或者 ES 这种查询性能比较好的系统中。
ETL :Extract-Transform-Load,用于描述将数据从来源端经过抽取、转换、加载到目的端的过程。
是在较高层次上将企业信息系统中的数据进行综合、归类和分析利用的一个抽象概念,每一个主题基本对应一个宏观的分析领域。在逻辑意义上,它是对应企业中某一宏观分析领域所涉及的分析对象。例如“销售分析”就是一个分析领域,因此这个数据仓库应用的主题就是“销售分析”。