在写入HDFS时（通过flume的HDFS接收器），我遇到了一些问题。我认为这些主要是由于IO超时造成的，但不确定。什么时候在HDFS中关闭文件
我最终打开了长时间写入的文件，并给出错误“无法获取位置块的块长度{...}”。如果我明确收回租约，这可以是固定的。我试图了解可能导致这种情况的原因。我一直在试图重现这个外部水槽，但没有运气。有人能帮助我理解何时会发生这样的情况 - HDFS上的文件最终没有被关闭并保持这种状态，直到人工干预才能恢复租约？
我认为租约是根据软硬限制自动恢复的。我试过杀死我的示例代码（我也尝试断开网络以确保没有执行关闭钩子）写入HDFS以使文件保持打开状态，但无法重现。
Flume反复出现了问题，但使用Flume 1.6+的时候它的效果会更好。我们在Hadoop集群外部的服务器上运行代理，并使用HDFS作为接收器。该代理被配置为每小时滚动到新文件（关闭当前，并在下一个事件中启动一个新文件）。
一旦事件在通道上排队，Flume代理将以事务方式运行 - 文件被发送，但不会被出队，直到代理可以确认成功写入HDFS为止。
如果代理程序无法使用HDFS（重新启动，网络问题等），HDFS上仍有文件仍处于打开状态。连接恢复后，Flume代理将查找这些搁浅的文件，并继续写入或正常关闭它们。
但是，我们发现了几个边缘情况，即使在每小时滚动已成功重命名文件后，文件似乎仍处于搁浅状态并保持打开状态。我不确定这是一个错误，一个配置问题，还是只是它的方式。当它发生时，它会完全混淆后续需要读取文件的处理。
我们可以找到hdfs fsck /foo/bar -openforwrite这些文件，并可以成功hdfs dfs -mv他们，那么hdfs dfs -cp从他们的新位置回原来的一个 - 一个可怕的黑客。我们认为（但没有确认）hdfs debug recoverLease -path /foo/bar/openfile.fubar会导致文件关闭，这是非常简单的。
最近我们遇到了一个情况，我们停止了几分钟的HDFS。这打破了水槽的连接，并在几个不同的州留下了一堆看似搁浅的开放文件。在重新启动HDFS后，recoverLease选项将关闭这些文件，但不久之后会有更多文件在某些中间状态下打开。在一个小时左右的时间里，所有的文件都被成功“处理了” - 我的假设是这些文件与代理通道重新关联。不知道为什么花了这么久 - 不是那很多文件。另一种可能性是在过期的租约之后纯HDFS清理。
我不确定这是问题的答案（现在也是1岁）：但它可能对其他人有帮助。