数据仓库架构及数据模型介绍
数据仓库体系和数据模型介绍
一、 数据仓库基础架构
做大数据分析，建立大数据分析体系，首先需要对源数据进行采集，经过一定的整理，转换成统一规范和量纲之后，得到统一的、规范的数据后才得以进行大数据分析，也就是把数据从OLTP过程转换到 OLAP平台的一个过程，源数据的来源包括不限于：业务数据库、客户端、服务器日志以及第三方数据，从源数据到大数据分析平台（包括银行或其他企业常见的报表系统、数据挖掘平台等分析系统）如下图所示：
数据仓库基础架构图
从源数据到数据仓库这一步，需要对数据进行一定的操作和建模，这个过程统称为ETL(Extract-Transform-Load)，主要是指将源数据经过抽取、清洗转换之后加载到数据仓库，目的是将企业中的分散、零乱、标准不统一的数据整合到一起，为企业的决策提供分析依据，ETL三个部分中，花费时间最长的是“T”(Transform，清洗、转换)的部分，一般情况下这部分工作量是整个ETL的2/3。数据的加载一般在数据清洗完了之后直接写入数据仓库中去。
二、数据模型
在上述的ETL过程之后，将数据整合在一起的模型叫做数据仓库数据模型，数据模型的本质是能够为了真实的模拟或抽象的表示世界，指使用实体、属性及其关系对企业运营和逻辑规则进行统一的定义、编码和命名；是业务人员和开发人员之间沟通的一套语言。数据模型在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”。
目前国内大部分银行数据仓库采用的就是Teredata的FS-LDM模型就是典型的ER模型：
FS-LDM模型在数据仓库架构中的地位
维度模型则是数据仓库领域另一位大师Ralph Kimball 所倡导的。维度建模以分析决策的需求为出发点构建模型，一般有较好的大规模复杂查询的响应性能，更直接面向业务，典型的代表是我们比较熟知的星形模型，以及在一些特殊场景下适用的雪花模型。
ER建模和维度建模的区别
另外，关系模型要求数据以最细粒度存在，而多维模型则以轻粒度汇总数据存在。所以ER建模可以查阅到单个客户层级的数据，但是维度建模得到的数据一般都是汇总级
五、总结
以上便是数据仓库架构以及架构中的关键数据模型讨论，基本上了解了全架构主要过程和所使用的逻辑数据模型，就能够对你分析的数据如何获取，流经了何种路径有深入的认识，在数据挖掘的过程中能够更好的理解和分析手头的数据。
更多：
