环境：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 编码的必要性。