【MapReduce】超大集群的简单数据处理 part5

 

5 性能

在本节，我们用在一个大型集群上运行的两个计算来衡量MapReduce的性能。一个计算用来在一个大概1TB的数据中查找特定的匹配串。另一个计算排序大概1TB的数据。

这两个程序代表了大量的用MapReduce实现的真实的程序的主要类型-一类是对数据进行洗牌，另一类是从海量数据集中抽取少部分的关心的数据。

5.1 集群配置

 

所有这些程序都是运行在一个大约有1800台机器的集群上。每台机器配置2个2G Intel Xeon支持超线程的处理器， 4GB内存，两个160GBIDE硬盘，一个千兆网卡。这些机器部署在一个由两层的，树形交换网络中，在最上层大概有100-200G的聚合贷款。所有这些机器都有相同的部署（对等部署），因此任意两点之间的来回时间小于1毫秒。

在4GB内存里，大概有1-1.5G用于运行在集群上的其他任务。这个程序是在周末下午执行的，这时候的CPU，磁盘和网络基本上属于空闲状态。

 

5.2 GREP

 

grep程序需要扫描大概10的10次方个由100个字节组成的记录，查找比较少见的3个字符的查找串（这个查找串在92，337个记录中存在）。输入的记录被拆分成大约64M一个的块（M=15000），整个输出方在一个文件中（R=1）。

 

图2表示了这个程序随时间的处理过程。Y轴是输入数据的处理速度。处理速度逐渐随着参与MapReduce计算的机器增加而增加，当1764台worker开始工作的时候，达到了30G/s的速度。当map任务结束的时候，在计算开始后80秒，输入的速度降到0。整个计算过程从开始到结束一共花了大概150秒。这包括了大约一分钟的开头启动部分。开头的部分是用来把这个程序传播到各个worker机器上的时间，并且等待GFS系统打开100个输入文件集合并且获得相关的文件位置优化信息。

 

5.3 SORT排序

 

SORT程序排序10的10次方个100个字节组成的记录（大概1TB的数据）。这个程序是仿制TeraSort benchmark[10]的。

sort程序是由不到50行用户代码组成。三行的map函数从文本行中解出10个字节的排序key，并且把这个key和原始行作为中间结果key/value键值对输出。我们使用了一个内嵌的identitiy函数作为reduce的操作。这个函数把中间结果key/value键值对不变的作为输出的key/value键值对。最终排序输出写到一个两路复制的GFS文件中（就是说，程序的输出会写2TB的数据）。

就像前边讲的，输入数据分成64MB每块（M=15000）。我们把排序后的输出分区成为4000个文件（R=4000）。分区函数使用key的原始字节来吧数据分区到R个小块中。

我们这个benchmark中的分区函数自身知道key的分区情况。通常对于排序程序来说，我们会增加一个预处理的MapReduce操作，这个操作用于采样key的情况，并且用这个采样的key的分布情况来计算对最终排序处理得分区点。

 

图三是这个排序程序的正常执行过程。左上的图表示了输入数据读取的速度。数据读取速度会达到13G/s，并且在不到200秒所有map任务完成之后迅速滑落到0。我们注意到数据读取速度小于grep粒子。这是因为排序map任务划了大概一半时间和I/O带宽写入中间输出到本地硬盘。相对应的grep中间结果输出几乎可以忽略不计。

左边中间的图是map任务把中间数据发送到reduce任务的网络速度。这个排序过程自从第一个任务完成之后就开始了。图示上的第一个高峰是启动了第一批大概1700个reduce任务（整个MapReduce分布到大概1700台机器上，每台机器一次大概执行1个reduce任务）。大概计算开始300秒以后，这些第一批reduce任务完成了，并且我们开始执行剩下的reduce任务。所有这些排序任务会在计算开始后大概600秒结束。

左下的图表示reduce任务把排序后的数据写到最终的输出文件的速度。在第一个排序期结束后到写盘开始之前有一个小延时，这是因为机器正在忙于内部排序中间数据。写盘速度持续大概2-4G/s。在计算开始后大概850秒左右写盘完成。包括启动部分，整个计算用了891秒。这个和TeraSort benchmark[18]的最高纪录1057秒差不多。

需要注意的事情是：输入速度要比排序速度和输出速度快，这是因为我们本地化的优化策略，绝大部分数据都是从本地硬盘读取而上去了我们相关的网络消耗。排序速度比输出速度快，这是因为输出阶段写了两份排序后的速度（我们写两份的原因是为了可靠性可可用性的原因）。我们写两份的原因是因为底层文件系统的可靠性和可用性的要求。如果底层文件系统用类似容错编码[14](erasure coding)的方式，而不采用复制写的方式，在写盘阶段可以降低网络带宽的要求。

5.4 高效的backup任务

 

在图三（b），是我们在关闭掉backup任务的时候，sort程序的执行情况。执行流和上边讲述的图3（a）很类似，但是这个关闭掉backup任务的时候，执行的尾巴很长，并且执行的尾巴没有什么有效的写盘动作。在960秒以后，除了5个reduce以外，其他reduce任务都已经完成。不过这些拖后腿的任务又执行了300秒才完成。整个计算化了1283秒，多了44%的执行时间。

 

 

5.5 失效的机器

 

在图三（c）中，我们演示了在sort程序执行过程中故意暂时杀掉1746个worker中的200个worker进程的执行情况。底层的集群调度立刻在这些机器上重新创建了新的worker处理（因为我们只是把这些机器上的处理进程杀掉，而机器依旧是可以操作的）。

因为已经完成的map work丢失了（由于相关的map worker被杀掉了），需要重新再作，所以worker死掉会导致一个负数的输入速率。相关map任务的重新执行很快就重新执行了。整个计算过程在933秒内完成，包括了前边的启动时间（只比正常执行时间多了5%的时间）。