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看似对多维度复杂查询性能较好，可是同时有两个致命的缺点，你们选型的时候不得不考虑：

一、扩展性：

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数据库是能够容易扩展的。

 

二、并发的支持：

 

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

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

 

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