大数据时代，传统数据仓库技术是否已经过时？

一、传统数据仓库技术介绍

传统的数据仓库架构一般有由源系统、ODS、EDW、Data Mart几部分组成。源系统就是业务系统、管理系统、办公系统等等；ODS是操作数据存储；EDW是企业级数据仓库，Data Mart是数据集市。

1、源系统

业务系统、财务系统、OA系统、ERP系统等其实都是源系统，源系统的主要作用是就是产生数据。传统行业大多是将这些数据存储在Oracle和SQL Server上，互联网行业则选择开源数据库(MySQL、NoSQL)的居多。

2、ODS

ODS全称是Openrational Data Store，直译过来就是操作数据存储。在具体项目中往往被叫做中间库或临时库。数据从源系统进入数据仓库前一般会有一个中间层，就是ODS。

ODS有以下几个特点：

整合异构的数据，数据都是先到ODS再到数据仓库

转移一部分业务系统细节查询的功能，直接跨不同的关系型数据库进行查询有比较大的局限性

数据编码标准化转化

数据是动态的、可更新的，DW是静态数据

ODS存储当前或者近期的数据，DW存储历史性数据

ODS数据容量级别较小，DW的数据容量很大

上文提到的是传统意义上对ODS的定义，而现在我们所理解的ODS已不再局限于此。现在ODS存储的不单单是文本，还包括图片和视频。也就是说它变成了一个中间层，而涉及的技术也不仅仅是关系型数据库，还有NoSQL或Redis这样的类型数据库。在前端采集数据量非常大的时候，关系型数据库可能会顶不住压力，但如果是Redis的话就可以将数据缓存在内存中，然后批量刷到关系库中。

3、EDW介绍

EDW有如下特点：

面向主题：各个源系统之间在物理上往往是分离的，数据也是按照源系统服务的业务/流程进行组织，而数据仓库中的数据是按照一定的主题域进行组织的。例如：用户、组织、财务、事件、产品等主题。

集成性：数据仓库中的数据是在对原有分散的数据库数据进行抽取、清理的基础上，再通过系统加工、汇总和整理后得到的，必须消除源数据中的不一致性，以保证数据仓库内的信息在企业级是全局一致的。

相对稳定：数据仓库的数据主要供企业决策分析之用，主要用来查询，很少涉及修改和删除（不提供修改和删除的功能），通常情况下数据也不会轻易的被刷新（指进入DW的数据不会经常因为源系统的原因需要重新被刷新，如果有这个场景，要思考是否是设计上除了问题）。

反映历史变化：数据仓库中的数据通常包含历史信息，记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析和预测。

无论是传统的的数据仓库还是大数据时代的数据仓库，EDW提供的功能并无太多差异。主要还是随机查询、固定报表以及数据挖掘，一般大数据层面更多的是偏向数据挖掘。

4、DM(Data Marts)介绍

数据集市一般是面向部门级业务(虽然很多时候都在说面向企业级，事实上在实施的时候往往面向的是部门级，这是传统企业的一个很大的特征)，是为了满足他们的需求而建立的一种分析型环境。投资规模比较小，更关注在数据中构建复杂的业务规则来支持功能强大的分析。

现在有人认为数据集市的概念在大数据时代已经是过时了，其实这里面我认为还是有一定误区。大数据时代也需要数据集市，只是数据集市中分析结果背后的逻辑有所变化，由因果关系逐步转向了关联关系。

我们认为传统数仓仍然有非常大的应用场景，起码是在大多数数据分析和商业BI上完全可用。在大多数场景下，最合理的做法是将DM替换成为现在更为流行、体验更好的DV（数据可视化）产品。

二、传统数仓应该做如何的变化

为了适应大数据时代，传统数据仓库技术应该做如下的变化来更好的服务与企业数据分析的需求。

1、源系统设计

源系统设计本身并不属于数据仓库技术的一部分，但是源系统设计的优劣会直接影响数据仓库实施的成本。最明显的就是数据结构的不统一问题，这对后期数据抽取、清洗会带来极大的成本，应该尽早的实行元数据管理。另外特别重要的一点是数据库架构的规划，要跳出某个具体的源系统，站在企业的角度对数据库进行顶层架构设计。

2、ODS设计

中间库通常被设计成数据库集群而不是单机，每台机器上会有多个MySQL或PG(PostgreSQL)实例。这样就可以将数据分布到不同的机器上，形成一个接口库成为集群。这里的集群并非传统意义上的集群，中间库应该是松散的MySQL集群、PG集群，数据量大的时候也可以选择Redis集群。

3、EDW设计

数据仓库的选择在PostgreSQL、Greenplum和Hadoop中展开。对于在线交易系统选择的肯定是PostgreSQL，而对于真正的数据仓库就应该选择Greenplum。

Greenplum体系结构

Greenplum由多个控制节点（master）和多个数据节点（segment Host）构成的集群。

之所以选择Greenplum，第一是因为它的高性能。

而高性能首先体现在大表分布上，Greenplum中会将一个大表的数据均匀的分布到多个节点，为并行执行（并行计算）打下基础。其次是并行执行，Greenplum的并行执行可以是外部表数据加载并行、查询并行、索引的建立和使用并行、统计信息收集并行、表关联并行等等。第三点是列式存储和数据压缩，如果常用的查询只取表中少量字段，则列模式效率更高，如查询需要取表中的大量字段，行模式效率更高。

选择Greenplum的第二个原因是产品成熟度高。前面提到过Greenplum由多个节点组成，其实它的每个节点就是一个PostgreSQL。PostgreSQLy于1986年开始研发，1987年开发出第一个版本，1988年对外展出，可以说PG经过这么多年的发展已经是非常成熟的产品。

第三个原因是容灾机制，Greenplum可以有两个master节点，其中一个宕机的时候，另外一个会继续接收访问，并且这两个节点的Catalog 和事务日志会保持实时同步。

第四个原因是线性扩展，Greenplum采用了通用的MPP并行处理架构，在 MPP架构中增加节点就可以线性提高系统的存储容量和处理能力。Greenplum在扩展节点时操作简单，在很短时间内就能完成数据的重新分布。Greenplum线性扩展支持为数据分析系统将来的拓展给予了技术上的保障，用户可根据实施需要进行容量和性能的扩展。

最后一个原因是似曾相识的开发环境，由于Greenplum是基于PostgreSQL，在语法上和PG区别并不大，所以能够让传统的Java开发人员平稳的过渡到Greenplum。

引入Hadoop

基于传统的SQL查询Greenplum可以轻松应对，但是在机器学习上就明显不足，虽然Greenplum的MADlib支持机器学习，实际案例却并不多见。因此要在EDW中引入Hadoop生态圈来满足机器学习的需求。

上图就是引入的hadoop生态圈，资源管理层使用Mesos和Yarm，分布式存储层是HDPS，处理引擎层可以在MapReduce和Spark core间选择。所以如果要做机器学习，其实有两个选项，一是MapReduce加Mahout，二是Spark core加MLlib。而MapReduce在性能上有所不如，因此我们一般倾向于第二个方案。

最终数据经由Greenplum进入hadoop生态圈，然后根据开发能力以及应用选择要存储的地方。Greenplum在这里成为了机器学习的数据源，另外数据在进入hadoop以后，还是可以做基于SQL的查询。

还有一点需要注意的是数据仓库或者大数据平台的计算结果一般都会被存储到PG中，这是由于PG对大表的处理能力要强于MySQL。

三、总结

数据仓库技术依然有其广泛的应用场景，我们应该根据业务的需求变化、用户体验的提升等角度对设计和技术选型进行调整和适应，而不是鼓吹概念，动则大数据，事实上有几个企业里面拥有的数据真正属于大数据？