我在写入 HDFS 时遇到了一些问题（通过 Flume 的 HDFS Sink）。我认为这些主要是由于 IO 超时引起的，但不确定。
我最终得到了长时间打开以供写入的文件，并给出错误“无法获得定位块 {...} 的块长度”。如果我明确恢复租约，它可以修复。我试图了解可能导致这种情况的原因。我一直在尝试重现这个外部水槽，但还没有运气。有人可以帮助我了解这种情况何时会发生 - 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 岁 :-)），但它可能对其他人有帮助。
【讨论】：