系列文章目录
- 经典数仓架构
- 传统离线大数据架构
文章目录
- 系列文章目录
- 烂橙子-终生成长社群群主，
- 前言
- 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架构被提出。
