MPP架构与Hadoop架构是一回事吗？
计算机领域的很多概念都存在一些传播上的“谬误”。
MPP 这个概念就是其中之一。它的“谬误”之处在于，明明叫做“Massively Parallel Processing（大规模并行处理）”，却让非常多的人拿它与大规模并行处理领域最著名的开源框架 Hadoop 相关框架做对比，这实在是让人困惑——难道 Hadoop 不是“大规模并行处理”架构了？
很多人在对比两者时，其实并不知道 MPP 的含义究竟是什么、两者的可比性到底在哪里。实际上，当人们在对比两者时，与其说是对比架构，不如说是对比产品。虽然 MPP 的原意是“大规模并行处理”，但由于一些历史原因，现在当人们说到 MPP 架构时，它们实际上指代的是“分布式数据库”，而 Hadoop 架构指的则是以 Hadoop 项目为基础的一系列分布式计算和存储框架。不过由于 MPP 的字面意思，现实中还是经常有人纠结两者到底有什么联系和区别，两者到底是不是同一个层面的概念。
这种概念上的含混不清之所以还在流传，主要是因为不懂技术的人而喜欢这些概念的大有人在，所以也并不在意要去澄清概念。“既然分布式数据库是 MPP 架构，那么 MPP 架构就等于分布式数据库应该也没什么问题吧。”于是大家就都不在意了。
不过，作为一个技术人员，还是应该搞清楚两种技术的本质。本文旨在做一些概念上的澄清，并从技术角度论述两者同宗同源且会在未来殊途同归。
到底什么是 MPP 架构？
MPP 架构与 Hadoop 架构在理论基础上几乎是在讲同一件事，即，把大规模数据的计算和存储分布到不同的独立的节点中去做。
有人可能会问：“既然如此，为什么人们不说 Hadoop 是 MPP（大规模并行处理）架构呢？”
关于这个问题嘛，请先问是不是，再问为什么。
在 GreenPlum 的官方文档中就写道：“Hadoop 就是一种常见的 MPP 存储与分析工具。Spark 也是一种 MPP 架构。”来看下面的图，更能体会到两者的相似性。
问：这是什么架构？
答：MPP 架构。
相信了解过 MPP 架构的读者对这幅图不会陌生。也许在不同的分布式数据库产品中，节点角色的名称会有差异，但总体而言都是一个主节点加上多个从节点的架构。
但是，还可以有其他答案，比如 MapReduce on Yarn：
这幅图或许大家有些陌生，但只不过是省略了资源调度的简化版 MapReduce 运行时架构罢了。
当然，还可以有更多答案，如 Spark：
自然还可以是 Flink：
有人可能会说，虽然直观上这些架构长得很像，但是 MPP 架构中的 Master 所负责的事情是不是与其他框架不一样？
那么，MPP 架构的 Master 做的什么事呢？它会接收 SQL 语句，解析它并生成执行计划，将计划分发到各个节点。那么，这与 Spark SQL 有区别吗？不仅与 Spark SQL 没有区别，与其他任何 Hadoop 生态圈类似架构如 Hive SQL、Flink SQL 都没有区别。对于非 SQL 的输入，逻辑也是一致的，只是没有了解析 SQL 的步骤，但还是会生成执行图分发到各个节点去执行，执行结果也可以在主节点进行汇总。
不仅是在计算上没有区别，存储架构上也没有区别。下面是 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 相关框架在计算中的数据重分区过程也是一致的。
无论是 Hadoop MapReduce，还是 Spark 或 Flink，由于业务的需求，往往需要在计算过程中对数据进行 Hash 分区，再进行 Join 操作。这个过程中不同的框架会有不同的优化，但是归根到底，可以总结为两种方式。
其中一种方式就是直接将两个数据源的数据进行分区后，分别传输到下游任务中做 Join。这就是一般的“Hash Join”。
另一种方式是，当其中一个数据源数据较少时，可以将该数据源的数据分发到所有节点上，与这些节点上的另一个数据源的数据进行 Join。这种方式叫做“Broadcast Join”。它的好处是，数据源数据较多的一方不需要进行网络传输。
以上是 Hadoop 相关框架的实现。下面用一个具体的例子来看 MPP 架构对这一过程的思考。
在 MPP 架构中，数据往往会先指定分区 Key，数据就按照分区 Key 分布在各个节点中。
现在假设有三张表，其中两张为大表，一张为小表：
很自然地，订单表会选择订单 ID 为做分区 Key，产品表会选择产品 ID 作为分区 Key，客户表会选择客户 ID 作为分区 Key。给这些表中添加一些数据，并且执行一个查询语句：
首先，订单表要与客户表做 Join，Join Key 是客户 ID。这种操作在 Hadoop 生态圈的分布式计算框架中，相当于对两个表做了 Hash 分区的操作。不过由于客户表已经按照客户 ID 提前做好了分区，所以这时只需要对订单表做重分区。在 MPP 架构中，会产生如下的结果：
此时，订单表整个表的数据会发生重分区，由此产生网络 IO。这种情况相当于 Hadoop 架构中的“Hash Join”。
接着，需要让结果与产品表按照产品 ID 做 Join。这时，因为之前产生的结果的分区 Key 不是产品 ID，看起来又需要将整个数据进行重分区。不过，注意到产品表是个小表，所以此时只需要将该表广播到各个节点即可。结果如下：
在这个过程中，就只有小表的数据发生了网络 IO。这就相当于 Hadoop 架构中的“Broadcast Join”。
两者还有区别吗？
前文在 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 产品也许会根据分区 Key 将其拆分到 100 个节点中去，而 HDFS 用一个文件块存储就够用了。
未来发展
前面讲到 MPP 产品对结构化数据的计算和存储都更有效率。其中一部分优化就包括了存储时的“列存储”技术，查询时的“CBO 优化”等等。这些都是 Hadoop 生态圈一开始比较缺乏的技术。但是随着这些年的发展，这些技术早就融入到了 Hadoop 生态圈中，Hive、Spark 框架的优化技术也越做越好，由此与 MPP 架构的技术差距也越来越小，甚至有覆盖的趋势。从最核心的技术上来看，两者未来只会越来越像。可以预测，Hadoop 架构的市场会越来越大。
不过，分布式数据库产品在安全性等方面仍然提供着更成熟的解决方案，这是开源产品短时间内无法超越的。因此，“MPP 架构”这个概念仍然会在政府、传统企业中长期占有一席之地。
WeChatSina WeiboEvernotePocketInstapaperEmailLinkedInPinterest
来自: insights.thoughtworks.cn