计算机领域的很多概念，在沟通上都有一些“谬误”。MPP的概念就是其中之一。它的“谬误”在于明明叫“MassivelyParallelProcessing（大规模并行处理）”，但很多人将其与大规模并行处理领域最著名的开源框架Hadoop相关框架进行比较。令人困惑——Hadoop不是一种“大规模并行处理”架构吗？很多人在比较两者的时候，其实并不知道MPP是什么意思，两者的可比性在哪里。事实上，人们在比较两者时，与其说是在比较架构，不如说是在比较产品。虽然MPP的本义是“大规模并行处理”，但由于一些历史原因，人们说到MPP架构时，实际上指的是“分布式数据库”，而Hadoop架构指的是Hadoop项目。基于MPP的一系列分布式计算和存储框架，但是由于MPP的字面意思，在现实中，人们常常纠结于两者之间的联系和区别，是否是同一层次的概念。之所以还在流传着这种概念上的歧义，主要是因为有很多人喜欢这些概念，但没有技术知识，所以根本不在乎理清概念。“既然分布式数据库是MPP架构，那么MPP架构等同于分布式数据库应该没有问题。”所以大家都没有在意。但是，作为技术人员，还是应该了解这两种技术的本质。本文旨在厘清一些概念，从技术角度看，两者同源同归。MPP架构到底是什么？MPP架构和Hadoop架构在理论上讲的几乎是同一个东西，就是把大规模数据的计算和存储分布到不同的独立节点上。有人可能会问：“既然如此，为什么人们不说Hadoop是一个MPP（massivelyparallelprocessing）架构呢？”关于这个问题，请问是不是，然后是为什么。在GreenPlum的官方文档中是这样写的：“Hadoop是一种常见的MPP存储和分析工具。Spark也是一种MPP架构。”看下图，更能体会到两者的相似之处。问：这是什么架构？答：MPP架构。相信了解过MPP架构的读者对这张图不会陌生。可能在不同的分布式数据库产品中，节点角色的名称会有所不同，但总的来说是一个主节点加多个从节点的架构。不过也有其他答案，比如MapReduceonYarn：这张图大家可能比较陌生，但它只是省略了资源调度的简化版MapReduce运行时架构。当然可以有更多的答案，比如Spark:自然也可以是Flink:有人可能会说，虽然这些架构直观上看起来很相似，但是MPP架构中的Master负责的东西和其他框架有区别吗？？那么，MPP架构的Master是做什么的呢？它会接收SQL语句，解析并生成执行计划，并将计划分发给各个节点。那么，这与SparkSQL有什么不同吗？它不仅与SparkSQL没有区别，而且与Hadoop生态中的任何其他类似架构（如HiveSQL和FlinkSQL）也没有区别。对于非SQL输入，逻辑是一样的，只是没有了解析SQL的步骤，但是仍然会生成执行图分发给各个节点执行，执行结果也可以汇总到master节点上.不仅在计算上没有区别，在存储架构上也没有区别。下面是HDFS的架构图：所以回到原话——MPP架构和Hadoop架构在理论上讲的几乎是同一个东西，就是把大规模数据的计算和存储分布到不同的地方在节点中独立执行。上面几张架构图印证了这一点。既然MPP架构和Hadoop架构本质上是一样的东西，为什么很多人把两者分开讨论呢？我们可能经常听到这样的话：“这个项目的架构就是MPP架构”。这似乎是在故意说：“这不是Hadoop集”。这跟MPP架构的历史有些关系。虽然两者在理论上是一回事，但MPP架构和Hadoop架构的发展是两条路线。虽然MPP架构也指“大规模并行处理”，但因为提出者是数据库厂商，所以MPP架构在很多人眼里已经成为“分布式数据库”的代名词，而且处理的也是“结构化”数据，往往用作企业数据仓库的解决方案。Hadoop生态系统是随着“大数据”的兴起而发展起来的概念。它需要解决的是大规模数据的存储和计算。它的提出者不是数据库厂商，而是一家拥有C端数据的互联网公司。因此，Hadoop架构虽然也解决了“大规模并行处理”，但没有数据库的限制，处理的大部分是“非结构化”数据（初期自然没有相关优化）。当然，Hadoop生态系统还需要考虑“结构化”数据。此时，Hive成为Hadoop生态系统的数据仓库解决方案。但是，Hadoop、Spark等框架的理论基础与分布式数据库还是一样的。从广义上讲，MPP架构是一个更高层次的概念，其含义是字面意思，但没有具体说明如何实现。Hadoop相关的框架和各种分布式数据库产品都是具体的实现。从狭义上讲，MPP架构是分布式数据库架构的代名词，而Hadoop架构是指基于Hadoop框架的一套生态系统。本文并不想仅仅从更高层次的架构设计上去说明两者是一回事，仍然没有说服力。下面，我们从分布式计算框架中最重要的进程——Shuffle来展示两者更多的相似之处。数据重新分区Shuffle是分布式计算框架中最重要的概念和流程之一。在MPP架构（分布式数据库）中，这种数据重新分区的过程也和Hadoop相关框架在计算中的数据重新分区过程是一致的。无论是HadoopMapReduce、Spark还是Flink，由于业务需求，往往需要在计算过程中对数据进行Hash分区，然后进行Join操作。不同的框架在这??个过程中会有不同的优化，但归根结底可以归纳为两种方式。其中一种方法是直接将两个数据源的数据进行分区，并传递给下游任务进行join。这就是一般的“HashJoin”。另一种方式是，当其中一个数据源的数据较少时，可以将该数据源的数据分发到所有节点，并在这些节点上与另一个数据源的数据进行join。这种方法称为“广播加入”。它的好处是数据源数据多的一方不需要进行网络传输。以上就是Hadoop相关框架的实现。下面通过一个具体的例子来看看MPP架构是如何思考这个过程的。在MPP架构中，数据往往先指定partitionkey，数据根据partitionkey在节点间分布。现在假设有三张表，两张是大表，一张是小表：很自然地，订单表会选择订单ID作为分区键，产品表会选择产品ID作为分区键，而customer表会选择客户ID作为分区键。在这些表中添加一些数据，执行一条查询语句：首先，订单表需要与客户表进行join，joinkey为客户ID。在Hadoop生态的分布式计算框架中，这个操作相当于对两个表进行Hash分区操作。但是，由于customer表已经提前按照customerID进行了分区，此时只需要重新对order表进行分区即可。在MPP架构中，会产生如下结果：此时订单表整表的数据会被重新分区，从而产生网络IO。这种情况相当于Hadoop架构中的“HashJoin”。接下来，需要根据商品ID将结果和商品表join起来。这时候因为之前生成的结果的partitionkey不是productID，看来需要对整个数据重新分区。但是注意product表是一个小表，所以此时只需要将表广播给各个节点即可。结果如下：在这个过程中，只有小表的数据有网络IO。这相当于Hadoop架构中的“BroadcastJoin”。两者之间有什么区别吗？上一篇文章将MPP架构的概念、历史和技术细节与Hadoop架构进行了比较，了解了两者非常相似的一些地方，从广义上讲，Hadoop是MPP架构的一种实现。但是，如前所述，由于传播谬误，人们在谈到MPP架构时，主要指的是分布式数据库，处理的是结构化数据，而Hadoop生态是从“大数据”的概念发展起来的。但是，最初处理的是非结构化数据。以此为出发点，两者在发展过程中有多大的差异？比较的维度有很多。比如很多人会说MPP架构封闭的平台，成熟的人才市场，而Hadoop架构开放的平台，对人才的专业培训较少。但这些都不是本质区别。这里我们还是以技术指标作为比较的维度。从技术角度来看，MPP产品最大的优势就是作业运行速度更快。这不难理解，因为MPP产品处理的是结构化数据，本身就是从数据库发展而来的，有一个极其复杂的优化器来优化作业。这些优化器是各个厂商最有价值的商业机密，自然是开源产品无法比拟的。但从另一个角度来看，这也是MPP产品相对于Hadoop相关产品不够灵活的地方——它只能处理结构化数据。有人说MPP产品能处理的数据量没有Hadoop架构大。这种说法是不准确的。Hadoop架构能够处理更大数据量的原因之一是硬件成本更低，扩展更方便。事实上，一个设计良好的MPP架构仍然可以处理PB及以上级别的数据。有人说MPP产品无法处理大规模数据，因为元数据量巨大。事实上，同样的问题也存在于Hadoop相关的框架中。另一方面，Hadoop相关框架能处理多少数据，与具体实现有很大关系。如果我们有足够的资金去扩充MPP产品，并且我们对Hadoop相关产品采用基于内存的计算，那么对比的结果一定是MPP产品能够处理更大的数据量。如果非要从数据量的维度来比较，可能Hadoop相关的产品对于小数据量更有优势。比如你要存储一个非常小的表，MPP产品可能会根据partitionkey拆分成100个节点，而HDFS是用一个文件块来存储的。未来发展如前所述，MPP产品在计算和存储结构化数据方面更加高效。部分优化包括存储时的“列存”技术，查询时的“CBO优化”等。这些都是Hadoop生态系统最开始缺乏的技术。不过随着这些年的发展，这些技术早已融入到Hadoop生态中，Hive和Spark框架的优化技术也越来越完善。因此，与MPP架构的技术差距越来越小，甚至有被覆盖的趋势。从核心技术来看，两者未来只会越来越相似。可以预见，Hadoop架构的市场会越来越大。但是分布式数据库产品在安全性方面还是提供了比较成熟的解决方案，短时间内是开源产品无法超越的。因此，“MPP架构”的概念在政府和传统企业中仍将长期占据一席之地。本文转载自微信公众号“地生大数据”，作者“地生大数据”，可通过以下二维码关注。转载本文请联系“地生大数据”公众号。
