Kafka Direct InputDstreamとステートフルストリーム変換を使用しているときのチェックポイントの再認識を理解するにはどうすればよいですか？

Question

糸クラスターでは、入力としてkafka directstream（例：バッチ時間は15秒）を使用し、入力msgを別々のuserIdsに集約したいとします。 私はupdateStateByKeyまたはmapWithStateのようなステートフルなストリーミングAPIを使用しますが、APIソースからはmapWithStateのデフォルトのチェックポイントの持続時間はbatchduration * 10（私の場合は150秒）で、カフカダイレクトストリームではパーティションオフセットがチェックポイントされていますすべてのバッチ（15秒）。実際に、すべてのdstreamは異なるチェックポイントの持続時間を設定できます。

ストリーミングアプリケーションがクラッシュしたとき、私はそれを再起動します。カフカオフセットとステートストリームrddはチェックポイントで非同期です。この場合、データを失わないようにするにはどうすればよいですか？あるいは私はチェックポイントメカニズムを誤解していますか？

Answer 1

データを失わないようにするにはどうすればよいですか？このようmapWithStateやupdateStateByKeyなど

ステートフルストリームは、それは、彼らがどのように動作するかの一部だから、あなたがチェックポイントディレクトリを提供するために、必要が、彼らはすべての中間がクラッシュ時の状態を復元できるようにする状態を格納します。

これ以外にも、チェインの各DStreamは自由にチェックポイントを要求することができます。質問には「他のストリームをチェックポイントする必要がありますか」という質問があります。

アプリケーションがクラッシュした場合、Sparkはチェックポイント内に格納されているすべての状態RDDを取得し、メモリに戻します。そのため、最後にスパークチェックポイントがチェックポイントされたときと同じ状態です。あなたのアプリケーションコードを変更すると、はチェックポイントから状態を回復できないので、それを削除する必要があります。つまり、バージョンのアップグレードが必要な場合は、バージョン管理を可能にする方法で手動で保存しない限り、以前に状態に保存されていたすべてのデータが失われます。