Dr. Elephant 使用文档

1. 引言

Dr. Elephant 由 LinkedIn 于 2016 年 4 月份开源，是一个 Hadoop 和 Spark 的性能监控和调优工具。Dr. Elephant 能自动化收集所有指标，进行数据分析，并以简单易用的方式进行呈现。Dr. Elephant 的目标是提高开发人员的开发效率和增加集群任务调试的高效性。Dr. Elephant 支持对 Hadoop 和 Spark 任务进行可插拔式、配置化以及基于规则的启发式job性能分析，并且根据分析结果给出合适的建议来指导如何调优使任务更有效率。

2. 概述

下面是 Dr.Elephant 的界面展示。

dr_01.png

Dashboard 按时间的由近到远展示出 Job 的诊断结果。下面的 Tab：Mapper Data Skew 等都对应到一条规则。蓝色表示规则诊断通过，其他颜色表示有问题。 Dr.Elephant 将诊断结果做了分级，分别对应不同的颜色。

Dr.Elephant 还提供了 job 的搜索和比较，界面如下图

dr_03.png

针对单个 job 还可以看到 performance 的历史曲线图。

flow-history01.png

优化建议。

suggestions.png

3. 系统架构

Dr. Elephant 的系统架构如下图。主要包括三个部分：

数据采集：数据源为 Job History
诊断和建议：内置诊断系统
存储和展示：MySQL 和 WebUI

drelephant-arch.png

4. 优化建议

下面是一些常规优化建议。

1. Tuning Each Step is Important

对于Pig任务来说，如果使用默认参数来设置reducer的数量，这对任务的性能可能是致命的。一般来说，对每个Pig任务，都花一些时间来调优参数PARALLEL是非常值得做的。例如：

memberFeaturesGrouped = GROUP memberFeatures BY memberId PARALLEL 90;

2. File Count vs. Block Count

由于 NameNode 的内存中要保存文件的 metadata，所以大文件要优于小文件。

3. Java Task Memory Management

map/reduce task 默认会分配 2G 内存。对于 Java job，2G 内存会被拆分为 1G heap 和 0.5 ~ 1G non-heap。然而这对于某些 job 来说并不是足够的。下面是一些能够减少内存使用的技巧。

UseCompressedOops

32 系统的 JVM 使用 32bit 的无符号整型来定位内存区域，最大可表示的堆空间为 2^32 ，也就是 4G。64 位的 JVM 使用 64bit 的无符号 long 型来表示内存位置，最大可以表示的内存堆大小为 2^64。使用 long 代替 int，导致需要的内存增大。最新的 JVM 支持在使用时添加选项 CompressedOops，在一些情况下使用 32bit 的空间代替 64bit 空间来保存内存定位信息，这样也可以在一定程度上减少内存的使用。添加设置

Hadoop-inject.mapreduce.(map|reduce).java.opts=-Xmx1G -XX:+UseCompressedOops

UseCompressedStrings

这样会将 String 类型转换为压缩的 byte[] 型。如果 String 类型变量使用的比较多，这样会节省非常多的内存。设置：添加 -XX:+UseCompressedStrings 到配置项 mapreduce.(map|reduce).java.opts。

4. Mapper time too short

出现这类警告，有可能存在以下三种情况：

A large number of mappers
Short mapper avg runtime
Small file size

5. 常见参数的优化

1. Mapper 相关

mapreduce.input.fileinputformat.split.minsize

map 输入的文件块的大小的最小值。增加这个参数的值就可以减少 mapper 的数量。

mapreduce.input.fileinputformat.split.maxsize

当使用 CombineFileInputFormat 或者 MultiFileInputFormat 时，map 输入的文件块的大小的最大值。相应的，缩小这个参数值就可以增加 mapper 的数量。值得注意的是，如果使用 CombineFileInputFormat 时，不设置最大的 split 大小，那么你的 job 会只使用一个 mapper。

2. Reducer 相关

mapreduce.job.reduces

对工作流性能影响最大的一个因素就是 reducer 的数量。reducer 数量过少导致 task 执行时间过长；数量过多同样会导致问题。reducer 数量调整不是一个简单的事儿，下面是一些建议：

reducer 数量多意味着 NameNode 上更多的文件。过多的文件可能造成 NameNode 挂掉。如果 reduce 的输出小于 512M 时，尽量使用较少的 reducer。
reducer 数量多意味着每个 reducer 处理数据的时间更短。如果使用的reducer数量过少，每个reducer作业消耗的时间会显著增加。reducer运行速度变快，就能处理更多的任务。

mapreduce.job.reduce.slowstart.completedmaps

这个参数是 reducer 开始执行前，至少有多少比例的 mapper 必须执行结束，默认值是 80%。但是对于很多特定的 job，80% 不是最好的。下面是一些参数调整的参考。

每个 reducer 接收数据多少
剩下的 map 需要花费的时间

如果 map 的输出数据量比较大，一般建议 reducer 提前开始执行以处理数据；反之 reducer 可以稍晚执行。一个估算的方法是先计算 shuffle 时间：所有的 map 执行完到第一个 reduce 开始执行中间的时间，然后 reducers 比较理想的执行时间是最后一个 map 结束时间减去 shuffle 时间。

3. Compression

mapreduce.map.output.compress

将该参数设置为 True 可以将 map 输出的数据进行压缩，从而可以减少节点之间的数据传输量。然而需要注意的是压缩和解压的时间要小于数据在节点之间的传输时间。如果 map 输出数据量很大，或者属于比较容易压缩的类型，这个参数设置为 True 则很有必要；反之设置为 False 则可以减少 CPU 的工作量。

4. Memory

mapreduce.(map|reduce).memory.mb

默认 2G，1G heap + 0.5~1G non-heap。一些情况下这个内存大小是不够用的。

5. Advanced

controlling the number of spills / io.sort.record.percent

mapreduce.(map|reduce).speculative

将这个参数设置为 false 可以避免相同的 map 或者 reduce task 并发执行。