MapReduce性能优化大纲

检测系统瓶颈

• 性能调优
  1. 创建一项基线，用来评估系统的首次运行性能（即集群默认配置）
  2. 分析Hadoop计数器，修改，调整配置，并重新执行任务，与基线进行比较
  3. 重复执行第2步，直到最高效率

识别资源瓶颈

• 内存瓶颈
  • 当发现节点频繁出现虚拟内存交换时表示出现了内存瓶颈
• CPU瓶颈
  • 通常情况下，处理器负载超过90%，在多处理器系统上整体负载超过50%
  • 判断是否是单个特定线程独占了CPU
• IO瓶颈
  • 磁盘持续活动率超过85%（也有可能是由CPU或内存导致）
• 网络带宽瓶颈
  • 在输出结果或shuffle阶段从map拉取数据时

识别资源薄弱环节

• 检查Hadoop集群节点健康状况
  • 检查JobTracker页面中是否存在黑名单，灰名单和被排除的节点
  • 灰名单节点会间歇性发生故障从而影响作业运行，应尽快处理（排除或修复）
• 检查输入数据的大小
  • 当输入数据变大时会导致任务运行时间变长
  • 检查计数器中的HDFS_BYTES_WRITTEN，Reduce shuffle bytes，Map output bytes，Map input bytes
• 检查海量IO和网络阻塞
  • 如果在读取数据时出现网络或IO瓶颈，会导致计算资源被迫等待
  • 检查FILE_BYTES_READ，HDFS_BYTES_READ来判断是否是输入引起的
  • 检查Bytes Writeen，HDFS_BYTES_WRITTEN来判断是否是写入引起的
  • 通过压缩数据和使用combiner
• 检查并发任务不足
  • 集群中CPU核处于闲置状态
  • IO核网络利用率不足
• 检查CPU过饱和
  • 当低优先级任务经常等待高优先任务运行时发生过饱和，体现为过多的上下文切换
  • 使用vmstat显示上下文切换情况(cs=context switch)
  • 可能由于在主机上运行了过多的任务

强化Map&Reduce任务

• 强化Map任务
  • 通过单个map的写入文件大小和任务处理时间得出
  • 发生大量溢写时会产生性能问题和读取过载，比较Map output records < Spilled Records
  • 需要精确分配内存缓冲区
  • 二进制文件和压缩文件本质上不基于块，因此不能拆分
  • 小文件会产生大量并行任务来处理，会浪费很多资源
  • 处理小文件的最好方法是打包为大文件
  • 使用Avro对数据序列化来创建容器文件
  • 使用HAR格式文件
  • 使用序列文件把小文件存储成单个大文件
  • 如果数据集很大但数据块很小会导致mapper过多，需要花时间进行拆分；因此输入文件大则数据块大小也要加大
  • 大的数据块会加速磁盘IO，但会增加网络传输开销，因而在Map阶段造成记录溢写
  • Map任务的流程
  • 输入数据和块大小的影响
  • 处置小文件和不可拆分文件
  • 在Map阶段压缩溢写记录
  • 计算Map任务的吞吐量
  1. Read阶段：从HDFS读取固定大小（64M）的数据块
  2. Map阶段：需要测量整个Map函数执行时间和处理的记录数。来判断是否有某个Map处理了超常规数据；过多的文件数量（小文件）或者过大的文件大小（单个不可拆分的文件）
  3. Spill阶段：对数据进行本地排序，并针对不同的reduce进行划分，同时如果有可用的combiner则进行合并，然后把中间数据写入磁盘
  4. Fetch阶段：把Map的输出缓冲到内存，记录产生的中间数据量
  5. Merge节点：针对每一个reduce任务，把Map输出合并成单个溢写文件
• 强化Reduce任务
  • 压缩排序和合并的数据量（combiner，数据压缩，数据过滤）
  • 解决本地磁盘问题和网络问题
  • 最大化内存分配以尽可能把数据保留在内存而不是输出到磁盘
  • 造成Reduce低速的原因可能是未经优化的reduce函数，硬件问题或者不当的Hadoop配置
  • 通过输入Shuffle除以Reduce运行时间得到吞吐量
  • Reduce任务的流程
  • 计算Reduce吞吐量
  • 改善Reduce执行阶段
  1. Shuffle阶段：Map任务向Reduce传输中间数据，并对其进行合并和排序
  2. Reduce阶段：测量每个数据键及其对应的所有值上运行reduce函数的耗时
  3. Write阶段：将结果输出到HDFS
• 调优Map和Reduce参数

优化MapReduce任务

• 使用Combiner
  • 类似于本地Reduce操作，可以提升全局Reduce操作效率
  • 习惯上一般直接把reduce函数当做Combiner，逻辑需满足交换律和结合律
  • Combiner会在Map函数生成的键值对收集到列表，并经过Combiner运算直到Combiner缓冲区达到一定数目时，才会发送给reduce。因此在数据量非常大的情况下可以很好的改善性能
• 使用压缩技术
  • 输入压缩：在有大量数据且计划重复处理时，应考虑输入压缩。Hadoop会自动对合适扩展名的文件启用压缩和解压
  • 压缩Mapper输出：当map任务中间数据量大时，应考虑在此阶段启用压缩。能改善Shuffle过程，降低网络开销
  • 压缩Reducer输出：可以减少要存储的结果数据量，同时降低下游任务的输入数据量
  • 如果磁盘IO和网络影响了MR作业性能，则在任意阶段（压缩输入，Mapper或Reduce输出）启用压缩都可以改善处理时间，减小IO和网络开销
• 使用正确的Writable类型
  • 通过使用FileInputFormat实现原始字节比WriteableComparable更有优势
  • 使用Text而不是String来消除字符串拆分所花的时间
  • 使用VIntWritable或者VLongWritable有时比使用int和long更快
  • 在代码中使用正确的可写类型能提高MR作业整体性能
  • 在Shuffle和Sort阶段，中间键的比较可能会成为瓶颈
• 复用类型
  • 复用已存在的实例比创建新的代价更低
  • 尽量避免创造短生命周期的对象，会造成GC压力变大
  • 开启JVM复用，降低新启动JVM造成的开销
• 优化Mapper和Reduce代码
  • 用更少的时间获得相同的输出
  • 在相同的时间内用更少的资源获得相同的输出
  • 在相同的时间内用相同的资源获得更多的输出