一、数据仓库概述
1). 概念
2). 发展阶段
上图是摘自某国外网站,其将数据仓库发展划分为5个阶段:
二、数据分层与建模
1). 数仓分层
在数据仓库中,往往采用分层结构。数据逐层处理,每层可采用不同的处理机制及适合的存储方式。
存储每天的增量数据,表与ODS层一致。
做数据清洗,存储基础原始明细数据。
一般采用维度、事实表设计。根据主题定义好事实与维度表,保存最细粒度的事实数据。
宽表化设计,形成公共指标。数据集市/轻度汇总层,在 DW层的基础之上根据不同的业务需求做轻度汇总所得。
数据个性化指标,面向最终展示,可做少量计算。
2). 数仓建模
三、数据仓库架构演进
1). 传统数仓架构
这是比较传统的一种方式,结构或半结构化数据通过离线ETL定期加载到离线数仓,之后通过计算引擎取得结果,供前端使用。这里的离线数仓+计算引擎,通常是使用大型商业数据库来承担,例如Oracle、DB2、Teradata等。
2). 离线大数据架构随着数据规模的不断增大,传统数仓方式难以承载海量数据。随着大数据技术的普及,采用大数据技术来承载存储与计算任务。当然,也可以使用传传统数据库集群或MPP架构数据库来完成。例如Hadoop+Hive/Spark、Oracle RAC、GreenPlum等。
3). Lambda架构
随着业务的发展,人们对数据实时性提出了更高的要求。此时,出现了Lambda架构,其将对实时性要求高的部分拆分出来,增加条实时计算链路。从源头开始做流式改造,将数据发送到消息队列中,实时计算引擎消费队列数据,完成实时数据的增量计算。与此同时,批量处理部分依然存在,实时与批量并行运行。最终由统一的数据服务层合并结果给于前端。一般是以批量处理结果为准,实时结果主要为快速响应。
4). Kappa架构
Lambda架构,一个比较严重的问题就是需要维护两套逻辑。一部分在批量引擎实现,一部分在流式引擎实现,维护成本很高。此外,对资源消耗也较大。而后面诞生的Kappa架构,正是为了解决上述问题。其在数据需要重新处理或数据变更时,可通过历史数据重新处理来完成。方式是通过上游重放完成(从数据源拉取数据重新计算)。Kappa架构最大的问题是流式重新处理历史的吞吐能力会低于批处理,但这个可以通过增加计算资源来弥补。
5). 混合架构
上述架构各有其适应场景,有时需要综合使用上述架构组合满足实际需求。当然这也必将带来架构的复杂度。用户应根据自身需求,有所取舍。在一般大多数场景下,是可以使用单一架构解决问题。现在很多产品在流批一体、海量、实时性方面也有非常好的表现。可以考虑这种“全能手”解决问题。
四、数据仓库发展趋势
上图摘自网上的一幅图,总结了数据仓库发展趋势,总结如下:
智能数据使用上,AI、ML将赋能数据应用,这些都需要在数仓平台提供支持能力。