基于Greenplum,postgreSQL的大型数据仓库实践

传统数据仓库由源系统、ODS、EDW、Data Mart这几部分组成，源系统就是业务系统、生产系统，ODS是操作数据存储，EDW是企业级数据仓库，Data Mart是数据集市。

源系统

生产系统、财务系统、人力资源系统还有12306的订票系统等其实都是源系统，源系统的主要作用是产生数据。传统行业大多是将这些数据存储在oracle、db2上，互联网行业选择开源数据库的居多。

作为一个中间层ODS有着以下几个特点。

• 整合异构的数据，比如各种业务数据以及 mysql 或者oracle的数据都是通过中间库进入数据仓库

• 转移一部分业务系统细节查询的功能，如果直接对使用传统关系型数据库的业务系统进行查询，对于Oracle和db2这样的数据库来说存在一定的局限性。

• 数据编码标准化转化。

• DW是静态数据而ODS中的数据是动态的、可更新的。

• 数据内容不同，ODS存储当前或者近期的数据，DW存储历史性数据。

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

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

PG/GP是否已经过时

前面提到过传统型数据库有着很多局限，接下来我们会重新梳理和设计，让传统数据仓库也能去适应大数据时代的变化。

源系统设计

上图展示的是SCADA（数据采集与监视控制系统），这样的一套系统中如果存在着上万个传感器，那么在一瞬间所产生的数据量会非常庞大。过去SCADA的做法是将采集的数据存放在内存中，但是由于数据量太大且无法发现数据价值，所以会进行定期清除。

近些年随着大数据的发展，这些数据的价值慢慢被体现出来，因此有了将数据存储到后端的需求。在数据库的选择上很多是倾向于PG，主要原因在于SCADA是和数据库捆绑在一起销售，而如果捆绑的是MySQL则会存在一定风险，PG则没有这方面的顾虑。

上面所提的这些，其实就是想说明在源系统上PG可能是更好的选择。

中间库（ODS）设计

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

EDW设计

既然谈到数据仓库设计，那么就要先回到传统层面——基于Oracle的数据仓库。

传统的数据仓库有这样几个特点，一是使用分区技术加速数据访问，Oracle中一个大表可以分为几个区，每个区又可以放到不同物理硬盘中，这样的设计对于性能提升其实很大，但是在大数据时代就有些捉襟见肘。二是应用集群技术，前端是多台服务器提供运算能力，后端是共享存储也就是IO。从架构上可以看出这其实是一个磁盘并列，一旦IO出现瓶颈，整个应用集群也会随之出现问题，所以这样的架构同样不适于数据仓库。三是Oracle的Exadata，它在交易平台使用的比较多，在数据仓库上则很少见。另外从可视化角度来看Oracle的BIEE也很难跟上时代。

综上所述，可以说传统的数据仓库技术虽然并非完全过时，但也在慢慢退出舞台。

当我们有海量数据的时候，就要面临数据仓库的选型问题，比如Oracle、DB2、PG生态圈或者Hadoop生态圈。基于上文所述Oracle和DB2肯定要被排除在外，在PG和Hadoop之间如果选择的是PG生态圈，就会有两个选择：PostgreSQL和Greenplum。对于在线交易系统选择的肯定是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生态圈来满足机器学习的需求。