MPP与批处理设计

译序

谨借此文展开浩瀚大数据研究与应用的序幕。

MPP设计

所有MPP解决方案的最初想法是消除共享资源。每个executor都有独立的CPU、内存和磁盘资源。除了通过网络交换被管数据，一个executor是无法访问另一个executor的资源。MPP解决方案的这一理念让资源隔离得非常漂亮，并使高扩展性成为可能。

MPP的第二个理念是并行。每个executor运行完全相同的数据处理逻辑，处理从本地存储加载的私有数据块。在执行步骤间有一些为数据交换而实现的同步点（例如Apache Spark和MapReduce的shuffle步骤）。下面是一个典型MPP查询执行时间轴每条垂线都是一个同步点。具体来说，在集群内连接和聚合数据都要用到同步，其任务可能代表数据聚合、表连接、数据排序和其他分别经由每个集群节点执行的计算。

MPP设计的问题

但是，这种设计将导致所有MPP解决方案面对同样的棘手问题straggler。如果一个节点经常比其他节点执行得慢，那么无论集群规模，整个引擎的性能都将受到这个故障节点的拖累。下面的例子说明了故障节点（Executor 7）是如何降低整个集群的性能：

大多数情况下，所有的executor都空闲下来，除了一个例外。它们在等着与Executor 7同步，问题根源就出在这里。具体来说，由于磁盘故障引起RAID性能降低，又或是硬件、OS级问题导致的CPU性能低下等等之类的问题都会在MPP上发生。每个MPP系统都要面临这些问题。

如果你能看看这份Google关于磁盘故障率的研究报告，通过观察AFR（年均故障率）指标可以发现，新磁盘在最初3个月运行时间中，有至少2%的故障率：

在由1000块磁盘组成的集群中，一年会遇到20块故障磁盘，大约两周就有一块磁盘出故障；在由2000块磁盘组成的集群中，每周都会遇到；那么4000块磁盘的集群每周遇到两次。使用2年后，故障率将扩大4倍，这就意味着在由1000块磁盘组成的集群中，每周会遇到两次磁盘故障。

事实上，在某个特定的集群中，MPP系统总是会遇到磁盘故障节点，正如前面提到的，不但该节点性能受损，还会限制整个集群性能。这就是世界上几乎没有哪个单MPP集群超过50台服务器的主要原因。

MPP方案和MapReduce批处理方案间另外一个区别是并发性。并发性是指有多少个查询可以有效地被并行执行。MPP是完全对称的一旦开始执行，集群中的每个节点并行执行相同的任务。这意味着MPP方案的并发级别完全与集群节点的数量无关。具体来说，无论集群是4个节点还是400个节点，并发性是一样的，它们的性能衰退也会在同一点体现。下面有个例子：

正如你所见，10-18个并行回话（查询）达到了最大吞吐量，曲线图上表明，如果达到20个以上的会话，吞吐量将缓慢衰退70%甚至更多。特别注意，这里的吞吐量是在固定的时间范围（足够长的时间间隔得出结论）内执行特定数量的查询（同类查询）得出的。Yahoo团队对Impala并发性限制调查也得出了类似的观察结果。插一句：Impala是构建在Hadoop上的MPP引擎。基本上，低并发性是权衡MPP方案实现低查询延迟和高速数据处理的重要指标。

（译注：吞吐量这部分作者没有交代在多少节点下得出的结论，请各位读者注意。）

批处理设计

为应对批处理需求，一种新的解决方案应运而生从MapReduce论文起步并发展壮大。该原理的代表作有Apache HadoopMapReduce和Apache Spark等等。主要思想是在两个同步点之间的step被分成了若干个独立task，task的数量和executor的数量完全没有关系。具体来说，基于HDFS的MapReducetask数量等于输入分片，通常等于输入文件的HDFS块数量。在同步点之间，根据executor的可用性，task被随机分配给executor，相比之下，MPP的每个处理任务限定了具体的executor来处理数据分片。MapReduce的同步点包括job开始、shuffle和job结束。对于Apache Spark来说是job开始、shuffle、缓存数据集和job结束。下面介绍了处理过程是如何工作的以Apache Spark为例，每个条带代表独立的task，每个executor并行处理三个task：

你可以看到executor3似乎有问题所有任务的运行几乎慢了2倍。但这不是问题它只是被安排了较少的任务。如果这个问题变得更严重，预测执行将起效慢节点上的task将在其他节点上重启。

由于共享存储，这种手段是可行的。为了处理一批数据，你无须将这批数据存储在特定设备上。相反，你可以从远端设备获取这些数据。当然，远端处理始终比本地处理开销更大，因为数据必须移动所以引擎也会尽力尝试本地处理数据。在批处理的场景下遇到设备故障，预测执行机制将帮助故障节点，这在MPP方案中是完全不可能实现的。

顺便说下，这里有个学习云环境下预测执行的好教材：

本图是关于WordCount的性能。正如图上所见，就算云环境有臭名昭著的straggler问题，预测执行机制依然在云环境下缩短了2.5倍的执行时间。结合共享存储和更细粒度的调度，使得批处理系统在规模上更优于MPP方案上千个节点上万个磁盘。

批处理设计问题

但是，一切都有代价。MPP你无需把中间数据放在磁盘上，因为一个executor处理一个任务，能将数据流直接交给下一个执行任务。这种机制叫pipelining，会大大提高性能。批处理环境下，当你让一个executor连续执行大量不相关的任务时，下一步需要用到上一步的数据你将无从选择，只有把中间结果存在本地磁盘。这将拖慢整个系统。

根据我的经验，主流MPP系统与Apache Spark比较性能的话同样硬件集群规模Apache Spark通常会慢3-5倍。所以合理的把MPP集群规模限制在50台，将和250台规模的Apache Spark集群性能一致，但是呢Apache Spark可以超过250个节点，MPP就望尘莫及了。