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

标签：bug   文件   get   成功   put   nod   日常   任务   因此   

环境：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 传输速率下降

标签：bug   文件   get   成功   put   nod   日常   任务   因此   

原文地址：https://www.cnblogs.com/PigeonNoir/p/9226759.html