加入收藏 | 设为首页 | 会员中心 | 我要投稿 宁德站长网 (https://www.0593zz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 大数据 > 正文

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

发布时间:2020-12-24 20:53:06 所属栏目:大数据 来源:网络整理
导读:大数据领域,实时分析系统(在线查询)是最常见的一种场景,前面写了一个《 实时分析系统 (HIVE/HBASE/IMPALA) 浅析 》讨论业界当前常见的方案。互联网公司用得比较多是 HIVE/HBASE ,如腾讯基于 HIVE 深度定制改造,改名为 TDW ,小米等公司选用 HBASE 等

大数据领域,实时分析系统(在线查询)是最常见的一种场景,前面写了一个《 实时分析系统 (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来应对大数据的实时分析系统是非常吃力的。

(编辑:宁德站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读