4.5MapReduce性能优化与容错在线视频

现在我们讨论一下

MapReduce系统的一些细节

包括一些性能的优化

以及它的容错性能

那么我们注意到一点

就说不管你把一个任务

分成了多少块

整个的这个大的任务

它的完成时间

是由那个最慢的那个节点决定的

因为你必须等所有的子任务

都完成了以后

你整个大任务才能结束

这时候你就很懊恼

就是这个东西

如果有一个节点特别特别的慢

那么剩下的两千个节点

都完成了那没用

就等这一个人

所以MapReduce这个系统情况

是不可避免的

因为它有些节点

就是会跑得比较慢

它可能因为这个节点

硬件有些问题

或者因为这个节点上

被其他人跑了些其它的东西

它就是一些不可预知的原因

它就跑的比较慢

但是不见得这个跑得慢

一定是这个节点的问题

它有可能就是有一块数据

它跑得就是比较慢

那一块数据可能需要更多的处理

比如说它那文章更长

或者是比如说

它那东西结构更复杂

所以这两种情况你是

对于系统来说它是完全不知道的

那么这时候我们所能做到的

最好的地步就是怎么样

那么我们就是避免

因为是机器的原因

或者因为一些不可预知的

随机的原因导致它跑得慢

它本身就跑得慢它没办法

那么这种解决方法也非常的直接

那怎么说

就是说我最后

剩下那几个任务了

因为大部分都跑完了

就剩几个慢的了

这时候很多机器都是闲着的

我闲着也是闲着

我还不如再多跑几个

一模一样的任务

多跑几个一模一样的任务

有什么好处

如果它是因为它随机的原因

导致它比较慢

那么我不可能老那么背

我每台机器都那么慢

所以它自然有台快的

那么谁快 谁先完成

不管谁先开始的

但是谁先完成了就算谁的

所以这种东西就叫做speculative

因为你不知道这种

你随机在跑多跑几个能不能行

但是我投机性的心里

我想再试一下

反正机器闲着也是闲着

万一它要是跑得很快了

那谁先完成算谁的

这是一个对性能

会有非常大的优化

Google的MapReduce的论文里头说到

其实它就多耗了3%的资源

多跑了3%的任务

那个速度能提升30%

因为确实有一些机器

它就是因为随机的原因

跑得比较慢的

那么要想实现这个事情

是不是所有任何任务都可以重试

那不一定

比如说一个事你往银行里存钱

你说我看着没到账

那我就再存一笔

那这不行

因为你存了两笔之后

你最后银行里多了两笔钱

你必须掏两笔钱出来

你得拿得出来

你给别人付钱

你更不愿意重新再试一次

看能不能付得成

但是这个MapReduceJob

是不一样的

它有两个非常重要的特性

一个是它的数据是独立的

Independent

就数据和数据是独立的

你多跑一个

这一块和另外一块是没关系的

哪一块都是可以拿出来

独立的跑 单独的跑 重复的跑

还有一个词这个词

大家可能见的不是特别多

叫Idempotent

Idempotent这个词叫幂等的

什么叫幂等的

就是说你一个操作

你做一次做两次做无数次

它都是一样的

那么最典型的为什么叫幂等

就是最典型的就是说这个1

1的一次方得1

1的一千次方它还是得1

那么这种东西就叫幂等的

那么这个MapReduce的操作

就是你做多少次

因为它最后我只有一个

Map的结果会被Reduce接受进去

或者是一个Reduce结果

会被写到磁盘上

剩下的Reduce就白做了

而且它做和做之间它互相不采纳

那么所以它是一个幂等的操作

任何的系统

如果它是操作和操作之间

是独立的显示幂等的

那么它就没有同步的问题

它的整个同步的策略

就会变得非常的简化

MapReduce实际上

一个典型的系统

它通过设计

它把所有的操作

都做成幂等的

这就是为什么

你看它把所有的东西

都写到本地的磁盘

本地的磁盘读过去之后

再次分块地写到本地磁盘上

最后再把它排序在一起

所有这些操作都是希望

任何一个操作都是可以重复的

可以来回来去的跑

如果多跑了一次那也无所谓

跑出来结果应该是一样的

那么MapReduce节点失败的话

是怎么处理的

如何因为它是独立的

且是幂等的

那么节点失败就非常容易处理了

它失败了或者它没失败

就是跑得慢

反正你都认为有点问题

你怀疑它不行

不行的话

那么你就重新执行一个就好

在别处重新再执行一个

那你怎么知道它不执行了

那么它定期会跟每一个计算节点

定期会跟每一个Master汇报一下

说 我执行了百分之多少了

它隔会不汇报

要么你死了要么你运行太慢了

我再重新启一个就好了

这个跟跑得慢的那个是

一样的方法来做的

那么如果这个Master说

是因为主主节点出问题

怎么办

MapReduce的论文里说

那主节点出问题的话那我认了

我就整个任务重新跑

这个也是一个合理的假设

当然你可以想到

说主节点我也可以搞成

备份的主节点什么的

但是像GFS一样 对吧

我可以用一个好多个主节点

然后互相备份

这个当然是可以的

但是MapReduce不需要

因为GFS

它是长年累月才要运行的

MapReduce这个任务

你执行的时间再长

那也就是几十个小时

几天的功夫

因为这个时间足够短

那么你主节点就一个

那么你不至于你老那么背

你都在这个时候内

主节点总是出问题

所以它就不用再想

这些复杂的问题了

它就改为假设主节点不会坏

坏了的话我们就重新跑一遍

MapReduce的论文和

后边无穷多的实验

包括Hadoop的实现

说MapReduce这种模型

是非常非常健壮的

非常robust

那么它说我们

1800个节点一下断了1600个

那为什么这么惨

这个东西就是因为

你可能是大面积断电

或者是一个网络断了

网络断了的话

那么这个所有

连接在这个网络上的

不管多少个节点

1600个节点在网络上都断了

它说曾经丢失了1600个节点

但是任务仍然能够完成

说明这个系统的容错性能

是非常好的

当然你要考虑到

MapReduce你要想这样容错

或者你要想让它

设置个幂等的操作

那么还有个重要的因素是什么

就是因为它数据输入之后

它的处理是确定性的

如果你的数据处理里头

有一个随机数的操作

那你想它这些事情

也不是这样的了

所以一般情况下MapReduce

是不跑里头带一个随机数的

就是不确定性的任务

当然有些人说

我也可以跑不确定性的任务

那是因为我理解

就是说这一次的

虽然这一次结果和下一次结果

看起来不一样

但是最终的结果它是一样的

那么这个是一个

应用相关的这么一种优化

但是MapReduce本身

它的意思就是说

如果你每一次跑出来结果

里面是一样的

那我才能做多少处理

否则的话

这个的MapReduce的模型

算出来结果可能是错的

这个也可能

也是大家需要注意的一点