クラスターに接続していない状態が続くと)、その間にブローカーによってオフセットが削除され、アプリケーションの再開時にデータの再処理が必要になることがあります。構成によって異なります。適度に大きな値にすることをお勧めします。読み取っている入力トピックのパーティションの最大数によって決まります。このストリームタスクの数が、アプリケーションの並列処理の上限となります。例を考えてみましょう。つのパーティションがあるとします。この場合、いくつのアプリインスタンスを実行することができるでしょうか。アプリインスタンスも問題なく起動しますが、それらはアイドル状態のままになります。その処理を引き継いで再開します。この例についてより詳しく回答すると、次のようになります。つの入力パーティションを処理します。実際には、アプリケーションの並列処理の上限はストリームタスクの数によって決まります。入力パーティションの数は、ストリームタスクの数を算出するための主要なパラメーターというだけです。これで、アプリケーションの並列処理に関する理論上の上限がわかりました。実際にアプリケーションで最大限の並列処理を実行するにはどうすればよいでしょうか。つのストリームタスクのすべてを並列に実行する必要があります。これを実現するには、いくつかの方法があります。「オプションの構成パラメーター」を参照してください)。このオプションは、たとえば、多数の性能の低いマシンでアプリのインスタンスを実行する場合に使用します。台あり、そこでアプリのインスタンスを実行する場合に適しています。アプリケーションの複数のインスタンスを実行し、それぞれで複数のスレッドを実行します。このオプションは、たとえば、アプリケーションを大規模に実行する場合に使用します。マシンごとに複数のアプリインスタンスを実行することもできます。各構成を設定すると、これらのトピックに書き込まれた処理結果の保持時間を指定できます。ブローカーは、レコードに関連付けられたタイムスタンプと現在のシステム時刻を比較して、古いデータをクリーンアップするかどうかを決定します。設定することもできます。ライブラリは、ブローカーと同じように、格納されたレコードのタイムスタンプと現在のシステム時刻を比較して、設定されたポリシーを守ります(キーと値のステートストアでは、更新が永続的に保持されるため、保持ポリシーはありません)。アプリケーションのデフォルトでは、結果レコードのタイムスタンプは元のソーストピックから変更されません。以上のレコードやステートの更新が発生した場合、結果レコードとステートの更新は、関連付けられたタイムスタンプで示される過去の時刻と同じ時刻のものとして反映されます。トピックまたはステートストアに書き込まれた直後にクリーンアップされることになります。その意味するところに注意が必要です。ある時刻のイベントを処理することは、実際には別の時刻の結果を得ることになります。通じてアクセスできます。間接的にアクセスすることもできます。使用してレコードメタデータにアクセスできます。コンテキストへの参照をプロセッサーのインスタンスフィールドに格納します。メソッドからは、常に現在のレコードのメタデータが返されます。関数からプロセッサーコンテキストを呼び出す場合も、同じ注意事項が適用されます。