数据仓库发展、架构与趋势
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
数据仓库发展、架构与趋势
1. 数据仓库概述
1). 概念
Data warehouse is a
subject oriented,
integrated,
non-volatile and
time variant collection of data
in support of management’s decision
— [Inmon,1996]
•面向主题的
联机交易型或操作型数据库的数据组织面向事务处理任务,而数据仓库中的数据是按照一定的主题域进行组织的。
•集成的
数据仓库中的数据是在对原有分散的数据库进行数据抽取、清理的基础上经过系统加工、汇总和整理得到的,必须消除源数据库中的不一致,以保证数据仓库内的信息是关于整个企业的一致的全局信息。
•相对稳定的
数据仓库的数据主要供企业决策分析之用,所涉及的数据操作主要是数据查询。
一旦某个数据进入数据仓库以后,一般情况下将被长期保留。
也就是说数据仓库中一般有大量的查询操作,但修改和删除操作很少,通常只需要定期的加载、刷新。
•反应时间变化的
数据仓库中的数据通常包括历史和实时数据。
通过这些信息,可以对企业业务的运营现状、未来趋势等做出定量分析和预测。
•支持管理决策的
数据仓库一般不是面向最终客户,而是面向企业领导、业务部门和内部分析人员,用于决策分析等场景。
2). 发展阶段
上图是摘自某国外网站,其将数据仓库发展划分为5个阶段。
•固定报表阶段
通过预置的固定报表,
解决'what happen'问题。
•即席分析阶段
通过增加即席查询,
解决'why did it happen'。
•趋势预测阶段
引入数据建模,预测未来,
解决'what will happen'。
•实时决策阶段
支持实时数据变化及查询,
解决'what is happening'。
•主动决策阶段
基于事件驱动,主动决策,
解决'what do I want to happen'。
2. 数仓分层与建模
1). 数仓分层
在数据仓库中,往往采用分层结构。
数据逐层处理,每层可采用不同的处理机制及适合的存储方式。
•STAGE - 预处理层
存储每天的增量数据,表与ODS层一致。
•ODS - 操作数据层
做数据清洗,存储基础原始明细数据。
•DW - 数据仓库层
一般采用维度、事实表设计。
根据主题定义好事实与维度表,保存最细粒度的事实数据。
•DM - 数据集市层
宽表化设计,形成公共指标。
数据集市/轻度汇总层,在 DW层的基础之上根据不同的业务需求做轻度汇总所得。
•APP - 数据应用层
数据个性化指标,面向最终展示,可做少量计算。
2). 数仓建模
•ROLAP
关系模型,可细分为ER模型、星型模型和雪花模型等。
其特点是与事务实体对应,关系清晰;但一般需要较为复杂的数据准备。
在响应前端需求时,一般较快,但取决于计算引擎能力。
•MOLAP
多维模型,可简单理解为将数据存放在一个n维数组中,而不是像关系数据库那样以记录的形式存放。
因此它存在大量稀疏矩阵,人们可以通过多维视图来观察数据。
它的优势在于响应较快、分析灵活、但数据准备时间较长。
•HOLAP
混合OLAP,顾名思义,由MOLAP和ROLAP组成。
3. 数据仓库架构演进
1). 传统数仓架构
这是比较传统的一种方式,结构或半结构化数据通过离线ETL定期加载到离线数仓,之后通过计算引擎取得结果,供前端使用。
这里的离线数仓+计算引擎,通常是使用大型商业数据库来承担,例如Oracle、DB2、Teradata等。
2). 离线大数据架构
随着数据规模的不断增大,传统数仓方式难以承载海量数据。
随着大数据技术的普及,采用大数据技术来承载存储与计算任务。
当然,也可以使用传传统数据库集群或MPP架构数据库来完成。
例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。
3). Lambda架构
随着业务的发展,随着业务的发展,人们对数据实时性提出了更高的要求。
此时,出现了Lambda架构,其将对实时性要求高的部分拆分出来,增加条实时计算链路。
从源头开始做流式改造,将数据发送到消息队列中,实时计算引擎消费队列数据,完成实时数据的增量
计算。
与此同时,批量处理部分依然存在,实时与批量并行运行。
最终由统一的数据服务层合并结果给于前端。
一般是以批量处理结果为准,实时结果主要为快速响应。
4). Kappa架构
Lambda架构,一个比较严重的问题就是需要维护两套逻辑。
一部分在批量引擎实现,一部分在流式引擎实现,维护成本很高。
此外,对资源消耗也较大。
而后面诞生的Kappa架构,正是为了解决上述问题。
其在数据需要重新处理或数据变更时,可通过历史数据重新处理来完成。
方式是通过上游重放完成(从数据源拉取数据重新计算)。
Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理,但这个可以通过增加计算资源来弥补。
5). 混合架构
上述架构各有其适应场景,有时需要综合使用上述架构组合满足实际需求。
当然这也必将带来架构的复杂度。
用户应根据自身需求,有所取舍。
在一般大多数场景下,是可以使用单一架构解决问题。
现在很多产品在流批一体、海量、实时性方面也有非常好的表现。
可以考虑这种“全能手”解决问题。
4. 数据仓库发展趋势
上图摘自网上的一幅图,总结了数仓的发展趋势,总结如下:
•实时
随着企业数字化转型,对数据的实时性要求越来越高。
未来传统离线数仓将逐渐消失,实时方式将成为主流方式。
•海量
数仓承载的体量将越来越大,十亿、百亿级别、TB甚至PB级别,将成为数仓的容量刚需。
•多模
半结构化、非结构化数据,将更多被使用在数仓领域,发挥出更大的价值。
•多元
数据使用方式,将出现多元化特征。
除常规的复杂查询、高频点
查等外,搜索类、向量计算等也成为常规计算需求。
在单一平台提供更加丰富的计算能力,对于客户来说不在需要频繁移动数据,一站式解决。
•虚拟
传统的大集中方式,存在诸多问题。
如果构建轻量化的解决方案,无需搬动数据即可形成虚拟数仓,解决客户问题成为数仓的基本能力。
•治理
数仓除了传统的数据存储、计算能力外,还需提供完备的数据治理能力。
包括元数据、数据血缘、数据质量等等,构成数据全生命周期的管理平台。
•智能
数据使用上,AI、ML将赋能数据应用,这些都需要在数仓平台提供支持能力。
韩锋频道:
关注技术、管理、随想。