写在前面

本文隶属于专栏《100个问题搞定大数据理论体系》,该专栏为笔者原创,引用请注明来源,不足和错误之处请在评论区帮忙指出,谢谢!

本专栏目录结构和文献引用请见100个问题搞定大数据理论体系

解答

MPP DB是一款 Shared Nothing架构的分布式并行结构化数据库集群,具备高性能、高可用、高扩展特性,可以为超大规模数据管理提供高性价比的通用计算平台,并广泛地用于支撑各类数据仓库系统、BI系统和決策支持系统.

补充

MPP

详情请见我的另一篇博客——从系统架构角度出发,服务器该如何分类?

MPP DB特征

  1. 低硬件成本:完全使用 x86 架构的 PC Server,不需要昂贵的 Unix 服务器和磁盘阵列;

  2. 集群架构与部署:完全并行的 MPP + Shared Nothing 的分布式架构,采用 Non-Master 部署,节点对等的扁平结构;

  3. 海量数据分布压缩存储:可处理 PB 级别以上的结构化数据,采用 hash分布、random 存储策略进行数据存储;同时采用先进的压缩算法,减少存储数据所需的空间,可以将所用空间减少 1~20 倍,并相应地提高 I/O 性能;

  4. 数据加载高效性:基于策略的数据加载模式,集群整体加载速度可达2TB/h;

  5. 高扩展、高可靠:支持集群节点的扩容和缩容,支持全量、增量的备份/恢复;

  6. 高可用、易维护:数据通过副本提供冗余保护,自动故障探测和管理,自动同步元数据和业务数据。提供图形化工具,以简化管理员对数据库的管理工作;

  7. 高并发:读写不互斥,支持数据的边加载边查询,单个节点并发能力大于 300 用户;

  8. 行列混合存储:提供行列混合存储方案,从而提高了列存数据库特殊查询场景的查询响应耗时;

  9. 标准化:支持SQL92 标准,支持 C API、ODBC、JDBC、ADO.NET 等接口规范。

MPP DB 适用场景

如果从性能来讲, MPP DB在多维复杂查询方面的性能确实要好于Hive、 Hbase、 Impala等,因此有不少人认为, MPP DB是适合这种场景的未来解决方案。

MPP DB看似对多维度复杂查询性能较好,但是它有两个致命的缺点,大家在选型的时候不得不考虑。

扩展性

MPP DB号称能扩展到1000个节点以上,但在实际应用中不超过100个节点,如在支付宝中用Greenplum来做财务数据分析的一个最大集群只有60多台机器。

MPP DB扩展性不好有很多原因,最根本的原因是架构本身。

MPP DB是基于原DB扩展而来的,DB中天然追求一致性( Consistency),必然会带来分区容错性较差。

当集群规模变得太大、业务数据太多时, MPP DB的元数据管理就完全是一个灾难。元数据巨大无比,一旦出错,将很难恢复。

所以 MPP DB要在扩展性上有质的提升,就要对元数据及数据存储有架构上的突破,降低对一致性的要求,否则很难相信一个MPP DB数据库是易于扩展的。

并发的支持

一个査询系统设计出来就是供用户使用的,所以能支持的并发数越多越好。

MPP DB的核心原理是将一个大的査询通过分解为一个个子查询,分布到底层执行,最后再合并结果,也就是通过多线程并发来暴力扫描以实现高速。

这种暴力扫描的方法对单个查询来说动用了整个系统的能力,所以单个查询比较快,但同时带来用力过猛的问题,整个系统能支持的并发数必然不多。

从目前的实际经验来看,也就支持50~100的并发能力。

当前 Hbase和 Impala在应对复杂查询时,也是通过全盘扫描的方法来实现的,在这种场景下, 硬盘数量越多越好,转速越快越好。

Hbase为什么号称支持上千并发,这也是在特定的场景下(查询时带用户标识,即带row key)才能实现的。在复杂的查询场景下,任何系统都将崩溃。

所以, MPP DB目前更适合小集群(100以内)、低并发(50左右)的场景。

Q.E.D.


大数据开发工程师,精通 Spark,擅长 Java 和 Scala