Hadoop作业性能指标及参数调优实例 （一）Hadoop作业性能异常指标

作者：Shu, Alison 

Hadoop作业性能调优的两种场景：

一、用户观察到作业性能差，主动寻求帮助。

（一）eBayEagle作业性能分析器

1. Hadoop作业性能异常指标

2. Hadoop作业性能调优7个建议

（二）其它参数调优方法

二、Hadoop集群报告异常，发现个别作业导致集群事故。

 

一、用户观察到作业性能差，主动寻求帮助。

（一）eBay Eagle作业性能分析器

对一般作业性能调优，eBay Eagle[i]的作业性能分析器已经能满足用户大部分需求。eBayEagle作业性能分析包含两个部分，第一部分是根据定量指标，捕捉性能异常的作业。在本文中，我们不考虑Hadoop集群或者节点故障造成作业性能的普遍下降，因此我们认为这些性能指标异常只与Hadoop作业有关，可以通过性能调优来改善。第二部分是调优建议。根据Hadoop作业性能异常指标判断作业是否需要调优，再综合采用第二部分的建议。第二部分也可以作为Hadoop作业开发的指引，并在后期性能测试中检查。

 

1. Hadoop作业性能异常指标有7个，以2015年5月的数据看，发生比例如下：

指标	％
作业进展缓慢	32%
Reduce数量太多	24%
Bytes Consumed Per CPU Second太低	23%
和历史记录比较，作业用时太久	15%
作业用时太久	3%
Shuffle size太大	2%
Read/Write Ops太大	0%
总计	100%

§  作业进展缓慢

HDFS的读写或者File的读写没有任何进展，并且持续相当一段时间。设15分钟为标杆，则当Hadoop作业没有任何读写操作持续达到15分钟，认为作业性能异常。如果作业普遍进展缓慢，可能是系统负载过高或否存在坏节点，这种情况是集群问题，与个别作业无关，但是用户可以通过选择合适的时间窗口或者queue来避免系统资源紧张导致作业性能下降。在Hadoop 2中，yarn通过scheduler管理大型集群多用户之间的资源分享。有两种scheduler：Fair Scheduler和Capacity Scheduler。作业对应的queue如果负载过高，则相应queue里的作业因为等待资源而进展缓慢。eBay Hadoop集群使用Capacity Scheduler，不同的queue拥有不同的资源，同一个作业如果有多个queue可以选择，建议作业使用相对空闲的queue，或者在相对空闲的时间窗口运行。

 

§  Reduce数量太多

这个指标需要设定合适的标杆，eBay Ealge认为Reduce 数量大于1500，作业性能会变差。初衷是通过控制Reduce 数量减少Seek operation 数量。在实践中，我们发现有些特殊的作业，Map output非常大，减少Seek operation 带来的收益小于Reduce 数据溢出到磁盘导致的额外成本。对这种作业，Reduce 数量超过1500是合理的。

示例：job_1401947195699_0367 Map number=9300, Reducenumber=4500

Job Counter截图

计算控制Reduce 数量的综合损益：

－减少Seek operation 带来的收益：

Reduce 数量从4500降低到1500，目的是减少Seek operation number。简化计算，忽略Shuffle handler使用read ahead来cache data。Reduce 数量减少3000会节省75小时。

reduced # of Seeks:(4500 – 1500) * 9000 (maps) =27000000.

假设IOPS＝100, max. reduced time: 27000000 / 100 / 3600(seconds) = 75 hours.

 

－增加每个Reduce data导致的成本：

已知每个Reduce memory=3GB，ShuffleBytes=19TB

19(TB)/1500*1024(GB)=13(GB)

数据溢出到磁盘:13(GB)-3(GB)=10(GB)

假设磁盘平均读写速度＝100MB/s

10(GB) * 2(write + read) * 1500 / 100(MB/s) /3600(seconds) = 85 hours.

 

－减少Reduce 数量的净收益：

75(hour) -85(hour)=－10(hour)

 

§  BytesConsumed per CPU second太低

这个指标也要和标杆比较，设BytesConsumed per CPU second低于200KB，认为作业性能较差，需要调优。用户也可以从job counter计算这个指标。

Bytes Consumed = File Bytes Read + File BytesWritten + HDFS Bytes Read + HDFS Bytes Written

示例：job_1431213413583_506297

Bytes consumed per CPU second=194.65 KB

Job Counter截图：

§  和历史记录比较，作业用时太久

有很多统计算法可以发现作业用时过长。eBay Eagle使用如下算法：

·        采集最少100个历史用时，每个用时作为一个数据点

·        去除10%最长用时数据点,计算中位数p90

·        计算绝对离差的中位数MAD

·        计算离差倍增数的95分位数dmMax

·        如果作业用时的离差倍增数大于dmMax,且大于p90,则认为作业用时太久，需要用户注意作业性能。如果普遍发生，则可以是集群问题，和个别作业无关。

很多Hadoop作业每天运行一次或者一天运行多次，适合统计历史用时。但根据Hadoop 平台架构，每次ＭapReduce作业都会获得新的Job Id，因此需要作业命名正则化来唯一确定作业。eBay Eagle创建了属性 ebay.job.name=<normalized job name>，来获得正则化作业名称。

Hadoop作业命名正则化示例（命令行方式）：

/bin/hadoop jar <your-job.jar> -Debay.job.name=${TABLE_NAME}.${JOB_NAME} -D ebay.alert.email=$NOTIFY_EMAIL_ADDR-D ebay.job.runid=$(date +%s)

 

§  作业耗时太久，超过标杆

设12小时为标杆，如果Hadoop作业耗时超过12小时，即认为作业性能差 。

用户很容易通过JobTrackerweb URL或是Hadoop API观察这个指标。

 

§  ShuffleSize太大

标杆设为单个Reduce对应的Shuffle size上限为10GB，超过这个数值，作业需要调优。

示例：job_1431213413583_517459

Reduce number=1 Reduce Shuffle Bytes=10709428036

Job Counter截图：

§  Read/WriteOps太大

标杆设为HDFS Read or Write Ops上限为10MB，超过这个数值，作业需要调优。

示例：job_1431213413583_597431 HDFS_READ_OPS=55.77M

Job Counter截图：

[1] eBay Eagle是eBay自主研发的系统，用于大型Hadoop集群管理，集监控、警示和智能修复功能于一体。eBayEagle即将开源，有望成为Apache的孵化项目。