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

 
MPP DB 是 大数据实时分析系统 未来的选择吗?_第1张图片
 

  • MPP DB 是 大数据实时分析系统 未来的选择吗?_第2张图片
  • 大小: 96.2 KB
  • 查看图片附件

你可能感兴趣的:(Greenplum,MPP,DB,hbase,hadoop)