云计算3 Google MapReduce.pptVIP

Worker故障 Master 周期性的ping每个worker。如果master在一个确定的时间段内没有收到worker返回的信息，那么它将把这个worker标记成失效 重新执行该节点上已经执行或尚未执行的Map任务 重新执行该节点上未完成的Reduce任务，已完成的不再执行 Master故障 定期写入检查点数据 从检查点恢复 WHY？ 任务备份机制 慢的workers 会严重地拖延整个执行完成的时间 由于其他的任务占用了资源 磁盘损坏 解决方案: 在临近结束的时候，启动多个进程来执行尚未完成的任务 谁先完成，就算谁 可以十分显著地提高执行效率 本地处理 Master 调度策略: 向GFS询问获得输入文件blocks副本的位置信息 Map tasks 的输入数据通常按 64MB来划分 (GFS block 大小) 按照blocks所在的机器或机器所在机架的范围 进行调度 效果 绝大部分机器从本地读取文件作为输入，节省大量带宽 跳过有问题的记录 一些特定的输入数据常导致Map/Reduce无法运行 最好的解决方法是调试或者修改 不一定可行~ 可能需要第三方库或源码 在每个worker里运行一个信号处理程序，捕获map或reduce任务崩溃时发出的信号，一旦捕获，就会向master报告，同时报告输入记录的编号信息。如果master看到一条记录有两次崩溃信息，那么就会对该记录进行标记，下次运行的时候，跳过该记录 实践证明，MapReduce是出色的分布式计算模型 Google宣布，其对分布于1000台计算机上的1TB数据进行排序仅仅需要68s 对4000台计算机上的1PB数据进行排序处理仅需要6小时2分钟（每次测试至少会损坏1块硬盘） 在08年1月份，Google MapReduce平均每天的数据处理量是20PB，相当于美国国会图书馆当年5月份存档网络数据的240倍 MapReduce的性能 我们用在一个大型集群上运行的两个计算来衡量MapReduce的性能: 计算在大约1TB的数据中进行特定的模式匹配,对数据格式进行转换，从一种表现形式转换为另外一种表现形式 计算对大约1TB的数据进行排序 ,从海量数据中抽取少部分的用户感兴趣的数据 集群配置 所有这些程序都运行在一个大约由1800台机器构成的集群上。每台机器配置2个2G主频、支持超线程的Intel Xeon处理器，4GB的物理内存，两个160GB的IDE硬盘和一个千兆以太网卡。这些机器部署在一个两层的树形交换网络中，在root节点大概有100-200GBPS的传输带宽。所有这些机器都采用相同的部署（对等部署），因此任意两点之间的网络来回时间小于1毫秒。 GREP 这个分布式的grep程序需要扫描大概10的10次方个由100个字节组成的记录，查找出现概率较小的3个字符的模式（这个模式在92337个记录中出现）。输入数据被拆分成大约64M的Block（M=15000），整个输出数据存放在一个文件中（R=1）。 GREP 该图显示了这个运算随时间的处理过程。其中Y轴表示输入数据的处理速度。处理速度随着参与MapReduce计算的机器数量的增加而增加，当1764台worker参与计算的时，处理速度达到了30GB/s。当Map任务结束的时候，即在计算开始后80秒，输入的处理速度降到0。整个计算过程从开始到结束一共花了大概150秒。这包括了大约一分钟的初始启动阶段。初始启动阶段消耗的时间包括了是把这个程序传送到各个worker机器上的时间、等待GFS文件系统打开1000个输入文件集合的时间、获取相关的文件本地位置优化信息的时间。 排序 排序程序处理10的10次方个100个字节组成的记录（大概1TB的数据）。这个程序模仿TeraSort benchmark[10]。 排序程序由不到50行代码组成。只有三行的Map函数从文本行中解析出10个字节的key值作为排序的key，并且把这个key和原始文本行作为中间的key/value pair值输出。我们使用了一个内置的恒等函数作为Reduce操作函数。这个函数把中间的key/value pair值不作任何改变输出。最终排序结果输出到两路复制的GFS文件系统（也就是说，程序输出2TB的数据）。 排序 排序 上图（a）显示了这个排序程序的正常执行过程。左上的图显示了输入数据读取的速度。数据读取速度峰值会达到13GB/s，并且所有Map任务完成之后，即大约200秒之后迅速滑落到0。 值得注意的是，排序程序输入数据读取速度小于分布式grep程序。这是因为排序程序的Map任务花了大约一半的处理时间和I/O带宽把中间输出结果写到本地硬盘。相应的分布式grep程序的中间结果输出几乎可以忽略不计。 排序 图（a）中间的图显示了中间数据从M