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来应对大数据的实时分析系统是非常吃力的。