よってデータのパーティション化が定義されます。データがどのようにトピック内の特定のパーティションにルーティングされるかが決まります。アプリケーションのプロセッサートポロジーは、複数のストリームタスクに分割することでスケーリングされます。アプリケーションの入力ストリームパーティションに基づいて固定数のストリームタスクを作成します。トピック)からのパーティションのリストが割り当てられます。ため、ストリームタスクは、アプリケーションの並列処理における固定単位となります。各タスクは、割り当てられたパーティションに基づいて独自のプロセッサートポロジーをインスタンス化します。結果として、手動操作を必要とすることなく、各ストリームタスクが独立して並列的に処理されます。ストリームタスクの最大数が上限となります。ストリームタスクの最大数は、アプリケーションが読み取っている入力トピックのパーティションの最大数によって決まります。個のアプリケーションインスタンスを実行できます。これらのインスタンスは協調してトピックのデータを処理します。アプリケーションインスタンスも開始されますが、それらはアイドル状態になります。その処理を引き継いで再開します。つのトポロジーだけが処理用にインスタンス化されます。単一のプロセッサートポロジーが、独立した複数のサブトポロジー(サブグラフ)に分解されることがあります。接続される一連のプロセッサーから成っています。この場合、異なるサブトポロジー同士がトピックを通じてデータを交換しますが、ステートストアは共有されません。インスタンス化することができます。これにより、計算ワークロードがさらに複数のタスクにスケールアウトされます。するライブラリであると理解することが重要です。アプリケーションの複数のインスタンスは、同じマシン上または複数のマシンで実行されます。タスクへのパーティションの割り当てが変わることはありません。され、同じストリームパーティションから消費が継続されます。注釈トピックパーティションはタスクに割り当てられ、タスクはすべてのインスタンスにわたるすべてのスレッドに割り当てられます。このとき、ロードバランシングとステートフルタスクの持続性とのトレードオフを最適化する試みが行われます。クラスが使用され、別のアサイナーに変更することはできません。数を、ユーザーが構成できるようになっています。以上のストリームタスクを、それぞれのプロセッサートポロジーで別々に実行できます。つのストリームスレッド。パーティションの別のサブセットを処理することに等しく、実質的に処理の並列化と変わりません。特筆すべき点として、スレッド間には共有されるステートがないので、スレッド間の協調は必要ありません。このため、アプリケーションインスタンス間およびスレッド間で、非常に簡単に複数のトポロジーを並列実行できます。よって透過的に処理されます。使用したストリーム処理アプリケーションのスケーリングは簡単です。よって、アプリケーションインスタンスで実行中の各ストリームタスクに対するパーティションの分散化が実現されます。トピックパーティションと同じ数まで開始できます。割り当てられることになります。クライアントを拡張する場合とほぼ同じ方法でストリームスレッドを拡張できます。パーティションの再配分を処理します。スレッドを追加して停止したストリームスレッドを置き換えることもできます。これにより、実行中のスレッドの数を回復するためにクライアントを再起動する必要がなくなります。並列処理モデルを理解するために、例を見ていきましょう。アプリケーションがあるとします。つのパーティションがあります。つのタスクに分割します。つのタスクに均等に分散させます。パーティションが割り当てられます。つのパーティションのレコードを処理することになります。つのスレッド間で可能な限り均等に分散されます。つのパーティションが消費されます)。ここで、データ量が大幅に増加したため、このアプリケーションを後からスケールアウトする必要が生じたとしましょう。開始することにします。作成され、入力パーティションが次のように再割り当てされます。トピックパーティション単位で効果的に調整します。同じアプリケーションのインスタンスをさらに追加した場合はどうなるでしょうか。これはある時点まで可能です。実行インスタンスの数が、読み取ることのできる入力パーティションの数と同じになるまでは、インスタンスを増やすことができます。パーティションの数を増やさない限り、それ以上のアプリケーションインスタンスを開始しても意味はありません。開始した場合、アプリケーションが過剰にプロビジョニングされ、アイドル状態のインスタンスがパーティションの割り当てを待機することになりますが、実際には割り当てられない可能性があります。用意されており、ストリーム処理アプリケーションでデータを格納してクエリを実行するために使用できます。実装する場合に重要な機能です。している場合に、このようなステートストアの作成と管理が自動的に行われます。以上のローカルステートストアを埋め込むことができます。経由でアクセスし、処理に必要なデータを格納したりクエリを実行したりできます。データベース、メモリー内のハッシュマップ、または別の扱いやすいデータ構造を使用できます。自動回復機能が提供されます。するため、アプリケーション全体のステートは、アプリケーションの実行インスタンスのローカルステートストアに伝達されます。アプリケーションのレベルでも)操作できます。処理トポロジーのインスタンスに使用される合計メモリー(RAM)サイズを指定できます。このメモリーは、レコードをステートストアに書き込む前や、ダウンストリームの他のノードに転送する前に、レコードを内部にキャッシュしたり圧縮したりするために使用されます。わずかに実装が異なります。スレッド間で均等に分配されます。メモリーは各インスタンスのすべてのスレッドで共有されます。各スレッドにはメモリープールが維持され、キャッシュ用にタスクのプロセッサーノードからアクセスできます。これは特に、集約を実行し、ステートストアを保持するステートフルプロセッサーノードによって使用されます。ステートストアからのデータの読み取りを高速化する読み取りキャッシュとして機能します。ステートストアのライトバックバッファとなります。ライトバックキャッシュを使用すると、各レコードを個別にステートストアに送信する代わりに、複数のレコードの一括送信が可能になります。トピック)の削減にもなります。ライトバックキャッシュにより、ダウンストリームのプロセッサーノードに送信されるレコードの数も削減されます。明示的な処理操作を呼び出さなくても、次のようなトレードオフを選択することができます。ダウンストリームの更新速度が上がり、更新間隔が短くなります。ダウンストリームの更新速度が下がり、更新間隔が長くなります。キャッシュサイズにかかわらず(キャッシュな無効な場合も含めて)、最終的な計算結果は同じです。したがって、キャッシュを有効にしても無効にしても問題はありません。更新の圧縮がいつどのように行われるかを予測することはできません。これは、次のようなさまざまな要因に左右されます。処理されるデータの特性。メモリー管理」を参照してください。内部にネイティブに統合されたフォールトトレランス機能を基に構築されています。永続化されると、アプリケーションで障害が発生して再処理が必要になった場合でもデータを利用できます。提供されるフォールトトレランス機能を利用して障害に対処します。自動的にタスクを再起動します。ローカルステートストアにも障害に対する堅牢性が提供されます。トピックの複製が保持され、そこであらゆるステートの更新が追跡されます。トピックパーティションが割り当てられます。有効になり、古いデータが安全にパージされ、トピックが無制限に増大するのを防ぎます。トピックを再生して、関連付けられたステートストアのコンテンツを障害前の状態に復元します。結果として、障害処理はエンドユーザーに完全に透過的に行われます。トピックを再生してステートを復元する時間に大きく左右されます。この復元時間を最小化するには、ローカルステートのスタンバイレプリカを保持するようにアプリケーションを構成します。スタンバイレプリカとは、ステートを完全に複製したコピーです。このようなスタンバイレプリカが既に存在するアプリケーションインスタンスにタスクを割り当てることで、タスクの(再)初期化コストを最小化します。詳細については、開発者ガイドの「オプションの構成パラメーター」で「num.standby.replicas」を参照してください。ステートのローカルコピーが完全に同期されたインスタンスがあれば、確実にそのインスタンスにタスクが割り当てられるようになっています。スタンバイタスクにより、障害が発生した場合に、同期された状態のインスタンスが存在する可能性が高まります。データレコードのタイムスタンプを使用してストリームの進行状況を調整します。そのために、時刻に基づいてすべてのソースストリームの同期を試みます。トピック)を処理していて、大量の履歴データがある場合に重要になります。分析アルゴリズムのバグ修正によってアプリケーションのビジネスロジックが大幅に変更され、過去のデータを再処理する必要が生じたとします。大量の過去のデータを取得することは簡単ですが、フロー制御が適切でないと、トピックパーティション間でデータの処理が同期されず、誤った結果が生成される可能性があります。各データレコードはタイムスタンプに関連付けられています。ストリームタスクは、ストリームレコードバッファ内のレコードのタイムスタンプに基づいて、すべての入力ストリームから次に処理する割り当てパーティションを決定します。つのストリーム内のレコードを並べ替えることはありません。デリバリーセマンティクスが崩れ、障害からの回復が難しくなるためです。ストリーム間で常に厳密にレコードのタイムスタンプに従って実行順序を適用できるとは限らないため、このフロー制御はベストエフォート型です。ような、タイムスタンプ境界や発見的評価に関する追加情報を挿入する必要があります。バックプレッシャーメカニズムは必要がないため使用されません。書き戻されてから、次のレコードが処理されます。つのストリームプロセッサー間でレコードがメモリー内にバッファリングされることはありません。コンシューマークライアントは、プルベースのメッセージングモデルで動作します。このモデルでは、受信データレコードの読み取り速度をダウンストリームプロセッサーが制御できます。独立した複数のサブトポロジーを含むプロセッサートポロジーの場合も同様で、互いに独立して処理されます(「並列処理モデル」を参照)。つの独立したサブトポロジーがあります。いうトピックを介して交換されます)。したがって、このシナリオでもバックプレッシャーメカニズムは必要ありません。開発されたコンテンツが含まれています。FoundationFeedbackこのページの内容:。