GBase导出到FI hdfs延时问题

1.  概述
   1. 问题描述
      1.  问题表现

GBase侧连接FI的HDFS服务使用rpc协议向其router节点发送请求。GBase侧显示导出成功，任务正常退出未卡住。而在FI侧查看HDFS文件时发现，文件字节数为0。经过20分钟后，字节数大小恢复正常。整个过程中存在20分钟的延时情况。

1.  问题结论

问题核心定位20分钟延时原因。

经过排查，现给出导出延时结论(排查过程详见3.2节)：

hadoop源码在invokeSingle处将src和dest的value值写成了常量值，固定为“/”，该src变量存储目标nameservice的写入地址。所以客户端传入任何路径，经过invokeSingle函数后都会被改写为常量“/”，后续checkLease环节会判断待写入文件是否是一个文件，而“/”被判断为是一个路径，抛出异常is not a regular file。进而导致关闭文件块失败。

重试机制启动后仍然是同样的原因，当尝试次数达到最大值后，导致本次关闭文件彻底失败，最后由hadoop的硬租约(hard lease)关闭文件块。硬租约默认值为20分钟。因此，才会出现20分种延时问题。

至此，问题已基本定位(解决方案见3.3节)。

1. 问题排查
   1.  问题复现

本地搭建hadoop联邦集群，其中包含mycluster、mycluster2两个subcluster，另外安装gbase测试客户端。

通过gbase 客户端向联邦集群router rpc端口发送数据

select * from test.t1 limit 10 into outfile 'hdp://hdfs:hdfs@172.16.2.231:8888/tmp/t37' outfilemode by hdfs;

发送完毕后，客户端显示正确发送的字样。查看hdfs上面/tmp/t37文件，显示字节数目为零，但是经过cat后证实确实存在数据。

截止到目前为止，本地复现了和线上同样的问题场景。查看namenode日志，发现了存在下面的异常日志

在20分钟之后，日志里面会有recoverLease的字样，这时查看到相同文件的字节数量，就能够得到正常显示。

发送文件20分钟周期内，使用命令查看hdfs文件/tmp/t37,可以看到文件处于打开状态

./bin/hdfs fsck /tmp/t37 -openforwrite

如此可以得到判断，被写入文件未能得到正常关闭，因为hadoop hdfs的默认硬租约的周期是20分钟，等到20分钟后，hdfs会自动进行租约释放，被写入文件被强制关闭。

未关闭的文件如果使用命令强制释放租约

./bin/hdfs debug recoverLease -path /tmp/t37 -retries 3

那么立马就可以看到文件的字节数量。经过证实，待写入文件确实未能正确关闭。

1. 3.2.2对比测试

本地hadoop联邦集群，共包含mycluster，mycluster2两个子集群，共存在六种写入方式

其中，仅当通过router rpc 的方式发送数据到hdfs上时存在异常现象，其余5种方式均为正常。

1.  远程调试

搭建hadoop调试环境，在RouterRpcServer处进行断点调试

进入debug调试环境

跟随断点进入到invokeSingle环节

其中params是一个数组，第一个元素代表的是目标nameservice的写入地址，这里的value是“/”。

而此时，NameNodeRpServerc在接收到远端RouterRpcServer的过程调用后，会执行namenode.complete过程。

其中，checkLease环节会判断待写入文件是否是一个文件，“/”因为是一个路径被判断为is not a regular file而报出异常，该异常被捕获后，导致complete没法完成，因而导致被写入文件处于了异常关闭状态。

原因就在于，hadooo 3.3.1的源码在invokeSingle处将src和dest的value值写成了常量值，引发了后续异常。

参考hadoop jira issues列表中HDFS-16865和HDFS-16880，其中的明确提到了这个bug。

1. 问题解决方案

预计hadoop 3.4.0以后的版本会修复该bug，之前的版本都会收到影响，如果使用联邦router的方式写数据，推荐使用http协议，避免采用rpc协议。

或是由FI侧合并这个patch，从根本上解决该问题。