MPP与批处理设计

MPP与批处理设计
2021年11月02日12:45:43 0 562

译序

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

MPP设计

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

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

MPP与批处理设计

MPP设计的问题

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

MPP与批处理设计

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

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

MPP与批处理设计

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

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

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

MPP与批处理设计

正如你所见,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:

MPP与批处理设计

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

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

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

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就望尘莫及了。

点赞(0) 打赏
weinxin
微信客服
问题+文章链接,发送到jyhcc95,咨询处理。
猜您今天喜欢
猜您
喜欢
《麦肯锡方法》| 成甲解读,麦肯锡方法 信息快餐

《麦肯锡方法》| 成甲解读

关于作者 艾森拉塞尔,曾担任麦肯锡公司咨询顾问,服务过的客户包括金融、电信、计算机和消费品等领域的众多知名公司。 关于本书 麦肯锡是世界顶级的管理咨询公司,全球排名前100家公司中...
新年文案,20句,高级,且不,重样,新年,文案 信息快餐

20句高级且不重样的新年文案

20句高级且不重样的新年文案1.辞暮尔尔,烟火年年。2.心之所向,行之可往。3.奉上满怀热情,只愿百无禁忌。4.眉目伊始,可爱如斯。5.新年,心纳吉,万事欣,岁安平。6.所爱如山海...
历史上的疫情,历史,疫情,中的,鉴往知来 信息快餐

【历史篇】“疫情”中的历史 鉴往知来

【历史篇】“疫情”中的历史 鉴往知来2020的“开学季”,被一场突如其来的疫情按下了暂停键。在这场“全民防疫攻坚战”中,潍坊新华中学的老师们不但通过线上课程对学生开展张弛有度地学科...
丧偶式婚姻,7年,丧偶,婚姻,老公,简直,自私,极致 信息快餐

7年丧偶式婚姻,老公简直自私到极致

7年丧偶式婚姻,老公简直自私到极致早上起来看到洗碗池里的餐盘,内心只有一遍遍的失望,他永远都是那么自私,每次吃饭他只拿自己的碗筷,洗碗只洗自己吃的,洗衣服也是永远只把自己的衣服放进...

评论列表 共有 0 条评论

暂无评论