Spark構造化ストリーミングチェックポイントのクリーンアップ
構造化ストリーミングを使用してファイルソースからデータを取り込んでいます。私はチェックポイントを設定していて、いくつかの状況で何が起こるかわからないことを除いて、私が知る限り正しく機能します。ストリーミングアプリを長時間実行すると、チェックポイントファイルが永久に大きくなり続けるのでしょうか、それとも最終的にクリーンアップされるのでしょうか。そして、それが決してクリーンアップされないかどうかは重要ですか？最終的には、プログラムが解析するのに長い時間がかかるほど大きくなるようです。
もう1つの質問は、チェックポイントフォルダーを手動で削除または変更した場合、または別のチェックポイントフォルダーに変更した場合、新しいファイルが取り込まれないことです。ファイルは認識されてチェックポイントに追加されますが、ファイルは実際には取り込まれません。これにより、チェックポイントフォルダーが変更された場合、取り込みが失敗するのではないかと心配しています。私はこれらの状況で正しい手順が何であるかについて多くの情報を見つけることができませんでした。
ストリーミングアプリを長時間実行すると、チェックポイントファイルが永久に大きくなり続けるのでしょうか、それとも最終的にクリーンアップされるのでしょうか。
構造化ストリーミングは、状態のスナップショットとデルタの削除を担当するバックグラウンドスレッドを保持するため、状態が非常に大きく、スペースの量が少ない場合を除いて、心配する必要はありません。その場合は、再トレーニングされたデルタ/スナップショットSparkストア。
チェックポイントフォルダを手動で削除または変更したり、別のチェックポイントフォルダに変更したりすると、新しいファイルは取り込まれません。
ここで何を意味するのかよくわかりませんが、チェックポイントされたデータは特別な場合にのみ削除する必要があります。構造化ストリーミングを使用すると、格納されているデータ型に下位互換性がある限り、バージョンアップグレード間で状態を維持できます。何か悪いことが起こらない限り、チェックポイントの場所を変更したり、ファイルを手動で削除したりする正当な理由はわかりません。
構造化ストリーミングアプリを6か月間実行した後、私はいくつかの答えを見つけたと思います。チェックポイントファイルは、10回の実行ごとにまとめて圧縮され、増え続けます。これらの圧縮されたファイルが約2GB大きくなると、処理時間が著しく減少しました。したがって、10回の実行ごとに約3〜5分の遅延がありました。チェックポイントファイルをクリーンアップしたため、最初からやり直すと、実行時間はすぐに通常に戻りました。
2番目の質問では、チェックポイントの場所が基本的に2つあることがわかりました。指定されたチェックポイントフォルダと、テーブルディレクトリ内の別の_spark_metadata。チェックポイントからやり直すには、両方を削除する必要があります。