数据仓库架构及数据模型介绍

数据仓库体系和数据模型介绍

一、数据仓库基础架构

做大数据分析，建立大数据分析体系，首先需要对源数据进行采集，经过一定的整理，转换成统一规范和量纲之后，得到统一的、规范的数据后才得以进行大数据分析，也就是把数据从OLTP过程转换到 OLAP平台的一个过程，源数据的来源包括不限于：业务数据库、客户端、服务器日志以及第三方数据，从源数据到大数据分析平台（包括银行或其他企业常见的报表系统、数据挖掘平台等分析系统）如下图所示：

数据仓库基础架构图

从源数据到数据仓库这一步，需要对数据进行一定的操作和建模，这个过程统称为ETL(Extract-Transform-Load)，主要是指将源数据经过抽取、清洗转换之后加载到数据仓库，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据，ETL三个部分中，花费时间最长的是“T”(Transform，清洗、转换)的部分，一般情况下这部分工作量是整个ETL的2/3。数据的加载一般在数据清洗完了之后直接写入数据仓库中去。

二、数据模型

在上述的ETL过程之后，将数据整合在一起的模型叫做数据仓库数据模型，数据模型的本质是能够为了真实的模拟或抽象的表示世界，指使用实体、属性及其关系对企业运营和逻辑规则进行统一的定义、编码和命名；是业务人员和开发人员之间沟通的一套语言。数据模型在oltp和olap环境下,有明显的区别：

数据仓库数据模型与业务系统数据模型设计的区别

请大家记住，数据库 ≠ 数据仓库，OLTP和OLAP也有较大的区别，如果还不太明确数据库和数据仓库之间的区别，可以看这一篇文章：

数据库和数据仓库，OLTP和OLAP

数据模型分类

数据仓库数据模型设计的先后次序划分，可以将数据模型分为三类，

· 概念数据模型（concepural data model)：容易理解的，对现实世界的抽象，用来描述世界的概念化结构；

· 逻辑数据模型(logical data model)：进行数据管理、分析和交流的重要手段；

· 物理数据模型(phycial data model)：面向计算机物理表示，描述数据在储存介质上的机构，将数据仓库的逻辑模型物理化到数据库的过程

三、逻辑数据模型

可以看出，概念数据模型离数据使用者很近，各个业务部门、各系统由于业务的不一致，对数据的要求也不一致，那么就需要逻辑数据模型能够提供一种统一的、共享的基础数据平台，为各个业务部门的不同业务需求提供一致、规范的数据，并且是一个可扩展的，动态的模型，能够经受时间的考验，当业务变动的时候，能够对数据模型的影响减少到最小甚至没有。

逻辑数据模型主要作用主要是：统一企业的数据视图、定义业务部门对于数据信息的需求、是构建数据仓库原子层的基础、支持数据仓库的发展规划、初始化业务数据的归属；那么一定要有逻辑数据模型吗？是的，有和没有的区别如下图所示：有就可以构建高楼大厦，能够承接住银行这种海量数据，没有就回归到原始状态，仅仅只能构建一个小木屋，数据就已烂成一团，无法进行大量的数据分析和处理。

四、ER建模和维度建模

目前业界常见的数据仓库数据模型有两类，维度建模和ER建模，

关系建模又叫ER建模，是数据仓库之父Inmon推崇的，其从全企业的高度设计一个3NF模型的方法，用实体加关系描述的数据模型描述企业业务架构，在范式理论上符合3NF，其是站在企业角度进行面向主题的抽象，而不是针对某个具体业务流程的，它更多是面向数据的整合和一致性治理，正如Inmon所希望达到的“single version of the truth”。