Hadoop EC 踩坑 :data block 缺失导致的 HDFS 传输速率下降

Posted PigeonNoir

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了Hadoop EC 踩坑 :data block 缺失导致的 HDFS 传输速率下降相关的知识,希望对你有一定的参考价值。

环境:hadoop-3.0.2 + 11 机集群 + RS-6-3-1024K 的EC策略

状况:某天,往 HDFS 上日常 put 业务数据时,发现传输速率严重下降

分析:

  • 检查集群发现,在之前的传输中,发生过个别 datanode 临时不可用的状况。
  • 而由于 hadoop EC 机制,当失效 datanode 小于容忍值 (这里是3),put 等传输任务仍然成功。但 hadoop 当时会报错,用于提示程序员,这个报错不会影响当此传输任务,故 put 等传输请求会返回成功。然后,缺失的 data block 会在出发 EC 恢复机制时被恢复。
  • 缺失的 data block 何时恢复?EC恢复的触发机制是低优先的:
    • 首先,恢复非常吃CPU和带宽,EC policy 引用的机器越多,这种消耗越大,因此,恢复任务会被执行于机器不忙碌的时候。
    • 然后,据我发现,EC恢复机制的主动触发有两种,
      • A:碰它一下,比如 get 那个文件,那么这个文件的缺失的 data block 会立即恢复,但是,并不会立即全部恢复,实验只会立即恢复1个缺失的data block,剩下的会被安排在接下来的时间内陆续恢复,这个时间无法控制。之前说过,EC恢复消耗大,会被安排在机器空闲时。
      • B:强制全部立即恢复,在重启HDFS时执行。虽然强效,但实际HDFS很少选择重启,故这个方法选择性采用。

操作:尝试重启了HDFS,强制立即全部恢复所有丢失数据块。

结果:HDFS传输速率恢复。

结论:

  • 无论在 hadoop ec 的官方文档中,还是在google等社区帖子中,都没有提到过EC的这种BUG。
  • 所以,本文提到的这个HDFS速率 BUG 和 EC 策略的相关性待进一步考究,先mark在这里。
  • 追究根本,还是 EC 对于恢复机制的高消耗带来的隐患,所以采纳 hadoop 的建议,要再一次考虑引入 ISL 编码的必要性。

  

以上是关于Hadoop EC 踩坑 :data block 缺失导致的 HDFS 传输速率下降的主要内容,如果未能解决你的问题,请参考以下文章

vue中集成blockly的踩坑之旅

vue中集成blockly的踩坑之旅

Hadoop编程踩坑

接口踩坑:Status (blocked:other)

hadoop安装踩坑

新手必踩坑之display: inline-block