系列文章目录
- 经典数仓架构
- 传统离线大数据架构
文章目录
- 系列文章目录
- 烂橙子-终生成长社群群主,
- 前言
- 1. 经典数仓架构
- 2. 传统离线大数据架构
烂橙子-终生成长社群群主,
采取邀约模式,不支持付费进入。
前言
经典数仓架构
传统离线大数据架构
背景解析
1. 经典数仓架构
-
1991年,比尔·恩门(Bill Inmon)出版了他的第一本关于数据仓库的书《Building the Data Warehouse》,标志着数据仓库概念的确立。该书定义了数据仓库非常具体的原则,这些原则到现在仍然是指导数据仓库建设的最基本原则。比尔·恩门(Bill Inmon)主张自上而下的建设企业级数据仓库EDW (Enterprise Data Warehouse),这个过程中信息存储符合第三范式,结构如下:
-
Inmon 模型从流程上看是自上而下的,自上而下指的是数据的流向,“上”即数据的上游,“下”即数据的下游,即从分散异构的数据源 -> 数据仓库 -> 数据集市。以数据源头为导向,然后一步步探索获取尽量符合预期的数据,因为数据源往往是异构的,所以会更加强调数据的清洗工作,将数据抽取为实体-关系模型,并不强调事实表和维度表的概念。
由于企业级数据仓库的设计、实施很困难,很重要的原因是因为其数据模型设计,在企业级数据仓库中,Inmon推荐采用3范式进行数据建模,从而无法支持决策支持(DSS -Decision Suport System )系统的性能和数据易访问性的要求,即:数据存储方式严格按照范式建模方式,导致数据分析效率低下。很多公司按照这种方式构建数据仓库遭到失败。 -
同时期,拉尔夫·金博尔(Ralph Kimball)提出自下而上的建立数据仓库,整个过程中信息存储采用维度建模而非三范式,思路如下:
-
Kimball 模型从流程上看是自下而上的,即从数据集市-> 数据仓库 -> 分散异构的数据源。Kimball 是以最终任务为导向,将数据按照目标拆分出不同的表需求,数据会抽取为事实-维度模型,数据源经 ETL 转化为事实表和维度表导入数据集市,以星型模型或雪花模型等方式构建维度数据仓库,架构体系中,数据集市与数据仓库是紧密结合的,数据集市是数据仓库中一个逻辑上的主题域。
-
维度建模方式没有采用三范式方式设计存储数据,适用于数据分析场景,以上设计方式构建数据仓库实施难度大大降低,并且能够满足公司内部部分业务部门的迫切需求,在初期获得了较大成功。但是很快,他们也发现自己陷入了某种困境:随着数据集市的不断增多,这种架构的缺陷也逐步显现,公司内部独立建设的数据集市由于遵循不同的标准和建设原则,以致多个数据集市的数据混乱和不一致,解决以上问题,还需回归到范式建模。
-
1998年,Bill Inmon提出了新的BI架构CIF(Corporation information factory),CIF的核心是将数仓架构划分为不同的层次以满足不同场景的需求,比如常见的ODS、DW、DM等,每层根据实际场景采用不同的建设方案,现在CIF已经成为建设数据仓库的框架指南。
2. 传统离线大数据架构
-
21世纪初随着互联网时代的到来,数据量暴增,大数据时代到来。Hadoop生态群及衍生技术慢慢走向“舞台”,Hadoop是以HDFS为核心存储,以MapReduce(简称MR)为基本计算模型的批量数据处理基础设施,围绕HDFS和MR,产生了一系列的组件,不断完善整个大数据平台的数据处理能力,例如面向KV操作的HBase、面向SQL分析的Hive、面向工作流的PIG等。以Hadoop为核心的数据存储及数据处理技术逐渐成为数据处理中的“中流砥柱”。
-
大数据中的数据仓库构建就是基于经典数仓架构而来,使用大数据中的工具来替代经典数仓中的传统工具,架构建设上没有根本区别。在离线大数据架构中离线数仓结构如下:
-
随着数据处理能力和处理需求的不断变化,越来越多的用户发现,批处理模式无论如何提升性能,也无法满足一些实时性要求高的处理场景,流式计算引擎应运而生,例如Storm、Spark Streaming、Flink等。
-
以上离线大数据架构不能够处理实时性业务,早期,很过公司都是基于Storm来处理处理实时性比较强的业务场景,随着越来越多的应用上线,大家发现,其实批处理和流计算配合使用,才能满足大部分应用需求。而对于用户而言,其实他们并不关心底层的计算模型是什么,用户希望无论是批处理还是流计算,都能基于统一的数据模型来返回处理结果,于是Lambda架构被提出。