EC存储冷数据

实现成果

• ec文档：https://hadoop.apache.org/docs/stable/hadoop-project-dist/hadoop-hdfs/HDFSErasureCoding.html
• 成果: 降低20PB+存储空间,可以看到每次数据都有阶段性的存储下降

实现方案

• EC存储流程图设计，这个是最初的设计，现流程有优化改动。
• 为了不影响现有集群，我们单独搭建了独立EC冷存储集群，但yarn计算资源还是统一使用，只是把datanode分开部署。
• 调度集成拓扑图 实现逻辑基于python编写，主要是采集到所有表信息，然后对配置表（需要EC转存的信息）进行清洗，比如过滤掉小文件的分区，或时间最近N（可配置）天有改动的分区，对正在EC转存的分区进行锁定hdfs路径，不允许业务改动或删除，会抛出异常提示，人工干预，避免造成脏数据。核对分区大小，文件是否一致等一系列逻辑。
• EC每天转存报表
• EC表配置信息
• EC日志 每个分区存储信息都需要记录下来

实现过程中遇到的问题

补丁修复

• 因我们是用hadoop 3.1.1版本做的EC，而EC功能是在hadoop3.0.0中才有的，必然有很多bug,在调研阶段已升级了很多EC path,但在实践过程中，还是遇到了文件损坏的问题，再次修复了大量patch进行升级

• 第一阶段修复 HDFS-16420 1642xx相关 删除冗余条带块时避免删除唯一数据块
  HDFS-14859 当 dfs.namenode.safemode.min.datanodes 不为零时，防止对代价高昂的操作 getNumLiveDataNodes 进行不必要的评估
  HDFS-14353, 修复 xmitsInProgress 指标异常。
  HDFS-14523, 去除 NetworkTopology 多余锁。
  HDFS-14849, DN 下线导致 EC 块无限复制。
  HDFS-15240, 修复脏缓存导致数据重建错误。
  HDFS-16806 balancer bug

• 第二阶段再次修复 HDFS EC 文件验证器，这个比较重要，需要开启EC恢复验证：https://github.com/sodonnel/hdfs-ec-validator
  当块组最后一个不完整的单元落入 AlignedStripe 时，解码失败：https://issues.apache.org/jira/browse/HDFS-14373
  部分 DataNode 关闭时，部分 ORC 数据无法恢复：https://issues.apache.org/jira/browse/HDFS-15085
  关于EC会造成错误数据的bug 在实时副本检查中应考虑繁忙的 DN 副本：https://issues.apache.org/jira/browse/HDFS-14768
  在某些情况下，退役可能会生成奇偶校验块的内容全为 0 ：https://issues.apache.org/jira/browse/HDFS-15186
  当源数据节点不足时，NameNode不应发送重建工作 ：https://issues.apache.org/jira/browse/HDFS-16479
• 3.4.0 fixed 验证DataNode上EC重构的正确性 ：https://issues.apache.org/jira/browse/HDFS-15759
  修正了数据节点陈旧时块恢复的错误 ：https://issues.apache.org/jira/browse/HDFS-17094
  –check https://github.com/apache/hadoop/pull/3593 https://issues.apache.org/jira/browse/HDFS-16286
  hdfs debug verifyEC -file /dfsperf.0.0
• 其它修复
  Fsck -blockId 显示 EC ：https://issues.apache.org/jira/browse/HDFS-14266
  blockIndices [i] 调用了错误的索引 ：https://issues.apache.org/jira/browse/HDFS-15135
  如果 updatePipeline 期间出现异常，文件写入会在关闭期间挂起 ：https://issues.apache.org/jira/browse/HDFS-15211
  EC 块在故障转移和恢复的情况下被标记为 CORRUPT ：https://issues.apache.org/jira/browse/HDFS-15170
  脏缓冲区导致重建块错误 ：https://issues.apache.org/jira/browse/HDFS-15240
  如果一个或多个数据节点在退役期间停止服务，退役可能会挂起 ：https://issues.apache.org/jira/browse/HDFS-14920
  当复制流硬限制达到阈值时，实时副本中不考虑存储 ：https://issues.apache.org/jira/browse/HDFS-14699
  内部块丢失并且同时被过度复制 ：https://issues.apache.org/jira/browse/HDFS-8881
  LOG 中损坏的 ec 块的大小值不正确 ：https://issues.apache.org/jira/browse/HDFS-14808

损坏文件处理

• 我们之前只做了在转存时验证，没有做定EC重构验证，这个已拉取补丁修复，但我们还是会随机检查文件验效码，同时会收集群据dn重构EC日志，每天去做验证是否损坏

• 损坏原因 是因为机器混部署了其它人的服务，而其它人服务是在灰度验证阶段，导致大量机器网络有问题，但这个问题又没有明显暴露出来，机器不断失去心跳，导致数据不断重构，后面我们加入了大量监控，并且启用了严格的维护模式配置，节点StaleDataNodes日志输出，并指标监控告警。 虽然是其它服务影响，但hdfs EC 确实存在重大bug，只是机率大小问题，所以要使用hdfs EC 至少在3.3.0版本之上用，并且要开启验证功能。

• 对已经损坏的文件做恢复 第一种情况：只有一个节点或二个节点的块损坏，我们是用的RS-3-2-1024k策略，其它的以此类推， 我们重写了hdfs客户端代码，来会屏蔽读取损坏的块，来for持续恢读取EC正常块的数据，再结合具体文件做验证，比如ORC parquet是否是一个合法的文件，如果是则读取出来，进行重写冷的文件，然后进行覆盖坏文件，如果是txt我们结果表字段数来验证是否是合法文件，如果是损坏的文件，大多列是乱码，只有1-2列。
  具体代码参考：https://github.com/liangrui1988/hadoop-client-op/blob/main/src/main/java/com/yy/bigdata/orc/OpenFileLine.java
  hdfs客户端代码修改的部分在hadoop源码分支上，不遍于展示。
• 还有一个问题，就是如果一个datanode上存在2个同一文件的块，是无法自动清除的，社区没有回复，目前是通过自已写的Python服务清除，具体问题详见： https://issues.apache.org/jira/browse/HDFS-17589