传统数据仓库过时了吗
传统数据仓库由源系统、ODS、EDW、Data Mart这几部分组成，源系统就是业务系统、生产系统，ODS是操作数据存储，EDW是企业级数据仓库，Data Mart是数据集市。
生产系统、财务系统、人力资源系统还有12306的订票系统等其实都是源系统，源系统的主要作用是产生数据。传统行业大多是将这些数据存储在oracle、db2上，互联网行业选择开源数据库的居多。
ODS是Openrational Data Store的简称，叫操作数据存储，在项目中也被叫做中间库或临时库。数据从业务系统进入真正的数据仓库前会有一个中间层，这中间层就是ODS。
作为一个中间层ODS有着以下几个特点。
整合异构的数据，比如各种业务数据以及mysql或者oracle的数据都是通过中间库进入数据仓库
转移一部分业务系统细节查询的功能，如果直接对使用传统关系型数据库的业务系统进行查询，对于Oracle和db2这样的数据库来说存在一定的局限性。
数据编码标准化转化。
DW是静态数据而ODS中的数据是动态的、可更新的。
数据内容不同，ODS存储当前或者近期的数据，DW存储历史性数据。
ODS数据容量级别较小，DW的数据容量很大。
上文提到的是传统意义上对ODS的定义，而现在我们所理解的ODS已不再局限于此。现在ODS存储的不单单是文本，还包括图片和视频。也就是说它变成了一个中间层，而涉及的技术也不仅仅是关系型数据库，还有NoSQL或Redis这样的类型数据库。在前端采集数据量非常大的时候，关系型数据库可能会顶不住压力，但如果是Redis的话就可以将数据缓存在内存中，然后批量刷到关系库中。
EDW也就是企业级数据仓库，以下是它的一些特点。
面向主题：操作型数据库的数据组织面向事物处理任务，各个业务系统 之间各自分离，而数据仓库中的数据是按照一定的主题域进行组织的。 例如：当事人、协议、机构、财务、事件、产品等主题。
集成的：数据仓库中的数据是在对原有分散的数据库数据抽取、清理的 基础上经过系统加工、汇总和整理得到的，必须消除源数据中的不一致 性，以保证数据仓库内的信息是关于整个企业的一致的全局信息。
相对稳定的：数据仓库的数据主要供企业决策分析之用，所涉及的数据操作主要是数据查询，一旦某个数据进入数据仓库以后，一般情况 下将被长期保留，也就是数据仓库中一般有大量的查询操作，但修改 和删除操作很少，通常只需要定期的加载、刷新。
反映历史变化：数据仓库中的数据通常包含历史信息，系统记录了企 业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信 息，通过这些信息，可以对企业的发展历程和未来趋势做出定量分析 和预测。
无论是传统的的数据仓库还是大数据时代的数据仓库，EDW提供的功能并无太多差异。主要还是随机查询、固定报表以及数据挖掘，一般大数据层面更多的是偏向数据挖掘。
DM介绍
数据集市的英文名称是Data Marts。它是一种小型的部门级的数据仓库，主要面向部门级业务，并且只面向某个特定的主题，是为满足特定用户（一般是部门级别的）的需求而建立的一种分析型环境。投资规模比较小，更关注在数据中构建复杂的业务规则来支持 功能强大的分析。
大数据的概念和数据集市的概念正好相反，数据集市是从一个超集中得出一个子集，而大数据是集合众多业务数据，然后从其中发掘数据的关联以及价值。所以我们认为数据集市的概念在大数据时代已经是过时了，这也是近些年来已经很少有人讨论数据集市的原因。
上图是我们认为的正确的体系结构，最后的DW被替换成DV（可视化数据库/结果库）。在EDW中计算的结果最终被存到DW中，然后由DW做展示或者可视化。
PG/GP是否已经过时
前面提到过传统型数据库有着很多局限，接下来我们会重新梳理和设计，让传统数据仓库也能去适应大数据时代的变化。
上图展示的是SCADA（数据采集与监视控制系统），这样的一套系统中如果存在着上万个传感器，那么在一瞬间所产生的数据量会非常庞大。过去SCADA的做法是将采集的数据存放在内存中，但是由于数据量太大且无法发现数据价值，所以会进行定期清除。
近些年随着大数据的发展，这些数据的价值慢慢被体现出来，因此有了将数据存储到后端的需求。在数据库的选择上很多是倾向于PG，主要原因在于SCADA是和数据库捆绑在一起销售，而如果捆绑的是MySQL则会存在一定风险，PG则没有这方面的顾虑。
上面所提的这些，其实就是想说明在源系统上PG可能是更好的选择。
中间库通常被设计成数据库集群而不是单机。下图的接口数据库其实就是一个中间库，是由多台机器组成的集群，每台机器上会有多个MySQL或PG实例。这样就可以将数据分布到不同的机器上，形成一个接口库成为集群。这里的集群并非传统意义上的集群，中间库应该是松散的MySQL集群、PG集群，数据量大的时候也可以选择Redis集群。
既然谈到数据仓库设计，那么就要先回到传统层面——基于Oracle的数据仓库。
传统的数据仓库有这样几个特点，一是使用分区技术加速数据访问，Oracle中一个大表可以分为几个区，每个区又可以放到不同物理硬盘中，这样的设计对于性能提升其实很大，但是在大数据时代就有些捉襟见肘。二是应用集群技术，前端是多台服务器提供运算能力，后端是共享存储也就是IO。从架构上可以看出这其实是一个磁盘并列，一旦IO出现瓶颈，整个应用集群也会随之出现问题，所以这样的架构同样不适于数据仓库。三是Oracle的Exadata，它在交易平台使用的比较多，在数据仓库上则很少见。另外从可视化角度来看Oracle的BIEE也很难跟上时代。
综上所述，可以说传统的数据仓库技术虽然并非完全过时，但也在慢慢退出舞台。
当我们有海量数据的时候，就要面临数据仓库的选型问题，比如Oracle、DB2、PG生态圈或者Hadoop生态圈。基于上文所述Oracle和DB2肯定要被排除在外，在PG和Hadoop之间如果选择的是PG生态圈，就会有两个选择：PostgreSQL和Greenplum。对于在线交易系统选择的肯定是PostgreSQL，而对于真正的数据仓库就应该选择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。
基于传统的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。
总结
最后我们反过来梳理下整个体系结构，底层的DV使用PG，EDW采用Greenplum加Hadoop，ODS这层最好也使用PG，这是为了避免项目中出现太多的异构数据库，也便于开发人员开发。