hadoop - HDFS 中的文件何时关闭

Question

在写入 HDFS(通过 Flume 的 HDFS Sink)时，我遇到了一些问题。我认为这些主要是由于 IO 超时引起的，但不确定。

我最终得到了长时间打开以供写入的文件，并给出错误“无法获得定位 block {...} 的 block 长度”。如果我明确恢复租约，它可以修复。我试图了解可能导致这种情况的原因。我一直在尝试重现这个外部水槽，但还没有运气。有人可以帮助我了解这种情况何时会发生 - HDFS 上的文件最终不会关闭并保持这种状态，直到手动干预以恢复租约？

我认为租约是根据软硬限制自动恢复的。我已经尝试杀死正在写入 HDFS 的示例代码(我也尝试断开网络以确保不执行关闭 Hook )以打开文件以供写入但无法重现它。

Answer 1

Flume 经常出现问题，但 Flume 1.6+ 的情况要好得多。我们有一个代理在我们的 Hadoop 集群外部的服务器上运行，HDFS 作为接收器。代理配置为每小时滚动到新文件(关闭当前文件，并在下一个事件上启动一个新文件)。

一旦事件在 channel 上排队，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 选项将关闭文件，但稍后会在某个中间状态下打开更多文件。在大约一个小时内，所有文件都已成功“处理”——我的假设是这些文件已与代理 channel 重新关联。不知道为什么花了这么长时间——没有那么多文件。另一种可能性是在租约到期后进行纯 HDFS 清理。

我不确定这是对这个问题的回答(现在也是 1 岁了:-))但它可能对其他人有帮助。