在寫入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歲）：但它可能對其他人有幫助。