ファイルがいつHDFSで閉じられるのですか

Question

私はHDFSに書き込むときに（flumeのHDFSシンクを介して）いくつかの問題にぶつかります。私はこれらがIO時間切れのために主に引き起こされたとは確信していないと思う。

私は長時間の書き込みのために開いているファイルで終わり、エラーは "ブロックの長さを取得できません{...}"。リースを明示的に回復した場合は修正できます。私はこれを引き起こす原因を理解しようとしています。私はこの外側の水路を再現しようとしていますが、運がまだありません。誰かがこのような状況が起こる可能性があることを理解するのに役立つでしょうか？HDFS上のファイルは、リースを回復するための手作業による介入まで閉鎖されずにそのまま残っていますか？

私はリースがソフトリミットとハードリミットに基づいて自動的に回復すると考えました。私は私のサンプルコードをkillしようとしました（私はまた、シャットダウンフックが実行されていないことを確認するためにネットワークを切断しようとしました）、HDFSに書き込んでファイルを書き込み用に開いたままにしていましたが、

Answer 1

Flumeには繰り返し問題がありましたが、Flume 1.6+では実質的に優れています。シンクとしてHDFSを使用して、Hadoopクラスタの外部にあるサーバ上でエージェントを実行しています。エージェントは、1時間ごとに新しいファイルにロールする（最新のものを閉じて次のイベントで新しいファイルを開始する）ように構成されています。

一度イベントがチャネルにキューイングされると、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オプションはファイルを閉じますが、後で何らかの中間状態でさらに多くのファイルがオープンします。 1時間ほどで、すべてのファイルが正常に "処理"されました。私の仮定は、これらのファイルがエージェントチャネルと再関連付けされたことです。なぜそれほど時間がかかったのか分かりません - ではなく、多くのファイルです。別の可能性は、期限切れのリース後に清掃する純粋なHDFSです。

これは質問への回答（これも1歳ですが:-)でもわかりませんが、他人には役立つかもしれません。