MPP DB 是 大数据实时分析系统

大数据领域，实时分析系统（在线查询）是最常见的一种场景，前面写了一个《 实时分析系统 (HIVE/HBASE/IMPALA) 浅析 》讨论业界当前常见的方案。互联网公司用得比较多是 HIVE/HBASE ，如腾讯基于 HIVE 深度定制改造，改名为 TDW ，小米等公司选用 HBASE 等。关于 HIVE/HBASE/IMPALA 介绍等可以看我前面的文章。

当前在实时分析系统中，最难的是多维度复杂查询，目前没有一个很好的解决方案，这两天和人讨论到 MPP DB （分布式数据库，以 Greenplum 为最典型代表）。如果从性能来讲， MPP DB 在多维复杂查询性能确实要好于 HIVE/HBASE/IMPALA 等，因此有不少声音认为， MPP DB 是适合这种场景的未来的解决方案。 MPP DB 看似对多维度复杂查询性能较好，但是同时有两个致命的缺点，大家选型的时候不得不考虑：

1、 扩展性：

MPP DB 都号称都能扩展到 1000 个节点以上，实际在应用过程中，就我目前从公开资料看到的不超过 100 个节点，如支付宝中用 Greenplum 来做财务数据分析的最大一个集群 60 多台机器。另外和 Greenplum 公司交流，在广东移动最大的用来做数据存储的，也就 100 台以内。这和 hadoop 动不动 4,5 千个节点一个节点集群简直不在一个数量级上。

为什么 MPP DB 扩展性不好？

有很多原因，有产品成熟度，也有应用广度的问题，但是最根本的还是架构本身的问题。讲到架构这里就要先讲下 CAP 原则：

Consistency( 一致性 ),  数据一致更新，所有数据变动都是同步的
Availability( 可用性 ),  好的响应性能
Partition tolerance( 分区容错性 )  可靠性

定理：任何 分布式 系统只可同时满足二点，没法三者兼顾。
忠告：架构师不要将精力浪费在如何设计能满足三者的完美 分布式 系统，而是应该进行取舍。

MPP DB 还是基于原 DB 扩展而来， DB 里面天然追求一致性（ Consistency ），必然带来分区容错性较差。集群规模变得太大，业务数据太多时， MPP DB 的元数据管理就完全是一个灾难。元数据巨大无比，一旦出错很难恢复，动不动导致毁库。

所以 MPP DB 要在扩展性上有质的提示，要对元数据，以及数据存储有架构上的突破，降低对一致性的要求，这样扩展性才能提升，否则的话很难相信一个 MPP DB 数据库是可以容易扩展的。

2、 并发的支持：

一个查询系统，设计出来就是提供人用的，所以能支持的同时并发越高越好。 MPP DB 核心原理是一 个大的查询通过分析为一一个子查询，分布到底层的执行，最后再合并结果，说白了就是通过多线程并发来暴力 SCAN 来实现高速。 这种暴力 SCAN的方法，对单个查询来说，动用了整个系统的能力，单个查询比较快，但同时带来用力过猛的问题，整个系统能支持的并发必然不高，从目前实际使用的经验来说，也就支持50～100的并发能力。

当前HBASE/IMPALA应对复杂查询时，也是通过全盘SCAN的方法来实现的，这种场景下，硬盘数量越多越好，转速越快越好。HBASE为什么号称支持上千并发，这也是在特定的场景下（查询时带用户标示，即带row key)才能实现的，复杂查询场景下，什么系统都歇菜。

所以MPP DB应用场景已经非常明显了，适合小集群（100以内），低并发的（50左右）的场景。MPP DB未来是不是趋势，我不知道，但是至少目前来看，用MPP DB来应对大数据的实时分析系统是非常吃力的。