查看原文
其他

MapReduce性能优化大纲

大数据技术与架构点击右侧关注,大数据开发领域最强公众号!

暴走大数据点击右侧关注,暴走大数据!

检测系统瓶颈

  • 性能调优

  1. 创建一项基线,用来评估系统的首次运行性能(即集群默认配置)

  2. 分析Hadoop计数器,修改,调整配置,并重新执行任务,与基线进行比较

  3. 重复执行第2步,直到最高效率

识别资源瓶颈

  • 内存瓶颈

    • 当发现节点频繁出现虚拟内存交换时表示出现了内存瓶颈

  • CPU瓶颈

    • 通常情况下,处理器负载超过90%,在多处理器系统上整体负载超过50%

    • 判断是否是单个特定线程独占了CPU

  • IO瓶颈

    • 磁盘持续活动率超过85%(也有可能是由CPU或内存导致)

  • 网络带宽瓶颈

    • 在输出结果或shuffle阶段从map拉取数据时

识别资源薄弱环节

  • 检查Hadoop集群节点健康状况

    • 检查JobTracker页面中是否存在黑名单,灰名单和被排除的节点

    • 灰名单节点会间歇性发生故障从而影响作业运行,应尽快处理(排除或修复)

  • 检查输入数据的大小

    • 当输入数据变大时会导致任务运行时间变长

    • 检查计数器中的HDFS_BYTES_WRITTENReduce shuffle bytesMap output bytesMap input bytes

  • 检查海量IO和网络阻塞

    • 如果在读取数据时出现网络或IO瓶颈,会导致计算资源被迫等待

    • 检查FILE_BYTES_READHDFS_BYTES_READ来判断是否是输入引起的

    • 检查Bytes WriteenHDFS_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代码

      • 用更少的时间获得相同的输出

      • 在相同的时间内用更少的资源获得相同的输出

      • 在相同的时间内用相同的资源获得更多的输出


    欢迎点赞+收藏+转发朋友圈素质三连


    文章不错?点个【在看】吧! 👇

    : . Video Mini Program Like ,轻点两下取消赞 Wow ,轻点两下取消在看

    您可能也对以下帖子感兴趣

    文章有问题?点此查看未经处理的缓存