Hadoop 0.23 性能笔记

[p=30, 2, left]Cloudera 的Hadoop World上看到的这个PPT:51Testing软件测试网s|4X'uYw
Hadoop
-Sh JTV!n0and Performance,介绍了一些现在0.20 和0.23版本性能优化的技巧，这里做个笔记[/p]51Testing软件测试网9Z`YX)Dl'ln
[p=30, 2, left]Hadoop
2c$Yqk,{L0性能误区[/p]

• Java 很慢51Testing软件测试网'H\U#aA
  Hadoop51Testing软件测试网 A:_"SF%u
  主要的瓶颈在磁盘IO 或者网络传输上，不是cpu

[p=30, 2, left]在cpu 热点上，我们可以使用JNI 或者sun.misc.Unsafe[/p]

• Java 没有提供足够的系统底层的支持 JNI 跟C一样可以容许我们调用任何系统调用

[p=30, 2, left]我们能够集成汇编代码[/p]

• Hadoop
  _)px's U+cq2mN0IO 有太多层了 Linux IO调度器，ext4,XFS 的开发人员的确比我们更了解系统底层IO

[p=30, 2, left]每个系统都会有IO调度和文件层，那些绕开操作系统的（比如DBMS)都是为了实现移植性[/p]51Testing软件测试网 `I;z9C#h
[p=30, 2, left]HDFS/MR 的IO/Caching 实现特点[/p]

• MapReduce 主要设计为顺序读取.
• Linux IO 调度提前读很弱(read-ahead) HDFS 0.20即使顺序读也会随机IO寻址多次.
• 数据集比内存容量大很多，缓存无效
• Linux 会将读刷入磁盘的时间延后以防止重写(HDFS 不会有这种状况).

[p=30, 2, left]如果脏页面消耗了多余dirty_ratio 的内存，会阻止所有的写(IO会停止即使在磁盘IO没有完全利用的情况)[/p]
Mb$TERF0[p=30, 2, left]HDFS/MR 改进解决办法[/p]

• Linux 提供3种系统调用: posix_fadvice(POSIX_FADV_WILLNEED) 提示IO 强制提前读

[p=30, 2, left]posix_fadvice(POSIX_FADV_DONTNEED) 读完之后会丢弃[/p][p=30, 2, left]sync_file_range(SYNC_FILE_RANGE_WRITE) 将页面马上写入磁盘[/p]

• 显示提前读
• 丢弃不需要的数据
• 显示写会磁盘

[p=30, 2, left]（上面提到的这些好像主要都是针对MAP阶段的第一次读和MAP阶段的Spill 阶段产生的零时文件)[/p][p=30, 2, left]结果是在Terasort 减少了20%的时间. 磁盘利用率更高，CPU 使用更平滑.[/p]51Testing软件测试网V6J%X/i
KI%n
[p=30, 2, left]MR CPU 排序改进[/p]

• CPU 低效率 主要CPU 用在了WritableComparator.compareBytes

[p=30, 2, left]在字节数组并行循环方面很慢[/p][p=30, 2, left]优化：使用sun.misc.Unsafe 一次比较64个字节[/p]

• CPU 缓存使用: MR 使用间接快速排序

排序操作使用数组指针，不利于CPU缓存的利用

优化：使用4字节的前缀指针，避免大多数比较操作无法有效使用CPU 缓存

[p=30, 2, left]CDHu2 的版本在1T排序，10节点，24G内存，6磁盘里面性能提升了大概20%左右.[/p]
*g8e3tA]'[1eT0[p=30, 2, left]MR 调度器改进[/p][p=30, 2, left]0.20.2:[/p][p=30, 2, left]TaskTracker 默认3秒一次心跳，即使对于小集群[/p][p=30, 2, left]每一次心跳分配一个任务给TT[/p][p=30, 2, left]如果一个task 运行时间小于 3*task slot , TT 会没有充分利用[/p][p=30, 2, left]0.20.205/CDH3[/p][p=30, 2, left]一次心跳分配多个任务[/p][p=30, 2, left]对于小集群将心跳减少到0.3秒（节点变多可以对应调整）[/p][p=30, 2, left]Out-of-band heartbeats on any task completion (task 完成有回调函数？还是从前面提到的多个任务中取一个运行？以后看了代码回来解释一下)[/p]
lUZaP0[p=30, 2, left]HDFS CPU 校验数据改进：[/p][p=30, 2, left]HDFS 校验每一片的输出输出[/p][p=30, 2, left]CPU消耗很多[/p][p=30, 2, left]优化：改成批量模式，一次校验64KB 的数据，而不是512字节[/p][p=30, 2, left]使用CRC32C 模式. [/p]51Testing软件测试网ql'S.]G
[p=30, 2, left]HDFS 随机存取[/p][p=30, 2, left]0.20.2[/p][p=30, 2, left]每一次读会重新连接DataNode[/p][p=30, 2, left]每一次创建线程和TCP 连接的消耗[/p][p=30, 2, left]0.23[/p][p=30, 2, left]客户端使用缓存的socket （跟HTTP 长连接一样） (0.23
l
YI)uZ8k0v+^0用Netty 代替了Jetty, 目前这个功能还在性能测试证明当中)[/p][p=30, 2, left]HBase 使用模式使用一种小数量的sockets(每个region server 的datanode 只连接自己的一片?)[/p][p=30, 2, left]重写了BlockReader 消除数据复制.[/p][p=30, 2, left]FSDataset 类消除了锁竞争. (目前还没做完HDFS-1148 ，HDFS-2533)[/p]51Testing软件测试网S%E4}lB(M,r|
[p=30, 2, left]MR2 Shuffle 改进:[/p][p=30, 2, left]删掉了io.sort.record.percent (MAPREDUCE-64)[/p][p=30, 2, left]Reduce 在一个TCP 之内取多个map 输出而不是重新连接[/p][p=30, 2, left]MR2: Shuffle现在用单独的进程，并用Netty 重写了，zero-copy sendfile .(更少CPU ，更少超时) MAPREDUCE-318[/p]51Testing软件测试网_
Sq b] Q~
[p=30, 2, left]特别说明下,shuffle 已经有的几次比较大的变动. 如果各位还有其他shuffle 的改进欢迎留言[/p]

• combine 函数的引入，对你没看错，Google 04 年发表的Hadoop 论文明确写了combine 阶段对shuffle 有如何的影响，但是Hadoop51Testing软件测试网/f8]3QDp
  一直到0.19 的时候才引入combine ，包括之后的改进SequenceFile 的加入，MapOutputFile 的SpillIndex 的引入.
• Segment Index 机制: 这个可以从example/SecondarySort 中看到，setPartitionerClass() 和 setGroupingComparatorClass() . Hadoop 需要按照输出的值来排序而不是map 的key ,在hive 里的group by 和distributed by 或者order by 不是同一个key 的时候就是这种机制. 在map 的shuffle 阶段，每一次spill ,hadoop 都会将第一个最小的值写在这次spill file 的文件头，这样combine 即使不需要读整个文件也可以知道spill 文件的大小顺序. 这个跟Google 的Tenzing 提到的block shuffle 也有一些相似的地方，Tenzing 的block shuffle 是将一个压缩后的block 按照一个key 加N多值当成一个spill 文件而不是现在Hadoop51Testing软件测试网3M2n ~7yw
  的包括多个key，主要是因为Tenzing 已经实现了列储存，所以这样做比较容易实现.
• MapR 的direct shuffle 机制: MapR 因为使用了自己的HDFS 文件底层，他的hdfs block 块可以attach 到另外的需要的节点上，所以他的shuffle 机制实际上是将spill 文件的key 去找对应其他还正在进行的Map 阶段产生的其他spill 文件进行合并, 你可以认为这是将本来reduce 阶段shuffle 做的事情他的map direct shuffle 就已经做了. 这个对小集群和小数据量的提升还是比较明显的，但是对于大集群和大数据量的影响感觉上有点说不清楚.
• 这次的改动将shuffle 相关类从原来的org.hadoop.mapred 包移除出去了，用单独的 ShuffleHandler 来处理.加上MAPREDUCE-64 将整个map spill 机制变成只受io.sort.spill.percent 控制. 目前的Reduce 端的shuffle 由mapred.reduce.parallel.copies 来控制接收端的socket线程数, 由mapred.job.shuffle.merge.percent 和mapred.inmem.merge.threshold 控制reduce 端的shuffle 触发条件，下一代Hadoop51Testing软件测试网#hj
  VR,GKin
  的新连接模型是由一个http 长连接控制reduce 端接受数据，reduce copy 阶段涉及的这两个参数都废掉了(mapred.reduce.parallel.copies 和mapred.inmem.merge.threshold ). 无论是map 的shuffle 还是reduce 的shuffle 都由单独的ShuffleHanlder 进程单独控制. mapred.reduce.copy.backoff (reduce 接收端超时控制) 和mapred.reduce.slowstart.completed.maps (reduce 启动条件) 可能也会被废掉.

51Testing软件测试网*y6NjcI{Mn |
51Testing软件测试网
r5CD'H,@A
[p=30, 2, left]总结[/p][p=30, 2, left]Hadoop现在比以前更快[/p][p=30, 2, left]对比0.20.2 有2-3倍的随机写性能提升[/p][p=30, 2, left]更少的CPU消耗[/p][p=30, 2, left]对于shuffle 密集的任务有2倍的提升.[/p][p=30, 2, left]Random read keepalive: HDFS-941[/p][p=30, 2, left]Faster Checksum: HDFS-2080[/p][p=30, 2, left]fadvice/sync_file_range :
5v,nsd z0HADOOP-7714[/p][p=30, 2, left]Faster compareBytes:
MZ2HbXzdm%m8e0HADOOP-7761[/p][p=30, 2, left]MR sort cache locality: MAPREDUCE-3235[/p][p=30, 2, left]Rewritten map-side shuffle : MAPREDUCE-64[/p][p=30, 2, left]Rewritten reduce side shuffle : MAPREDUCE-318[/p]51Testing软件测试网)b8}
MU#F/R.kS
[p=30, 2, left]Hadoop World 上有一个谈到将来Hadoop
9MD p$D7YL3Qp(l0生态圈的时候，提到一个opentsdb 的专门的时间数据库也蛮有意思的，基于HBase, 但是将HBase 改成异步多线程的，专门用来做收集大量基于时间的数据点的数据库，非常适合做数据中心的监控分析，机器自动收集的信息比如GPS，温度测量之类的.[/p][p=30, 2, left]Hive 0.8 也差不多准备发布了，这次增加了bitmap index 的支持，timestamp 类型的支持，插件PDK 的开发包和JDBC 的改进（批量模式？）[/p]
zjW/ubT0[p=30, 2, left]参考资料:[/p][p=30, 2, left]hadoop
[(C9M X!Z ~"QS^:b/G0and performance:[/p][p=30, 2, left]http://www.cloudera.com/resource/hadoop-world-2011-presentation-slides-hadoop-and-performance[/p]