在写入HDFS时（通过flume的HDFS接收器）我遇到了一些问题。我认为这些主要是因为IO超时但不确定。
我最终得到长时间打开写入的文件，并给出错误＆＃34;无法获得LocationBlock {...}＆＃34;的块长度。如果我明确恢复租约，则可以修复。我试图了解可能导致这种情况的原因。我一直试图重现这个外面的水槽，但还没有运气。有人可以帮我理解何时会发生这样的情况 - HDFS上的文件最终没有关闭并保持这样直到人工干预以恢复租约？
我认为租约会根据软限制和硬限制自动恢复。我已经尝试杀死我的示例代码（我还尝试断开网络以确保没有执行关闭挂钩），这是写入HDFS以保持文件打开以进行写入但无法重现它。
答案 0 :(得分：0)
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岁:-)）但它可能对其他人有帮助。