Flinkのウィンドウと状態の維持

Question

私はデータストリーミングのためにapache flinkで作業しています。どんな助けでも大歓迎です。ありがとう。

1）タンブリングウィンドウの作成に制限はありますか？たとえば、ユーザーIDごとに2秒間の回転ウィンドウを作成して、1,000万人を超えるユーザーIDが問題になるとしましょう。 （私はkeyByユーザーIDを使用して、2秒間timeWindowを作成しています）？これらのウィンドウは内部的にどのようにフリンクしていますか？

2）私は、ラウンドロビンパーティショニングのために再バランスを検討しました。クラスタを設定していて、ソースの並列度が1で、リバランスをとった場合、データをマシン間でシャッフルしてパフォーマンスを向上させますか？ある場合は、クラスタ内の他のノードにデータを転送するための特定のポートがありますか？

3）状態の保守に制限はありますか？私は非常に大きくなる可能性のあるユーザーID関連のデータを維持する予定です。私は状態を維持するためにロックdbを使用してフリンクについて読む。どれくらいのデータを維持できるかに制限があるかどうかを確認したいのですが？

4）データの量が少ない場合、状態はどこに維持されますか？ （私はJVMのメモリで推測する）私のクラスタ上にいくつかのマシンがある場合、すべてのノードが現在の状態のバージョンを取得できますか？

Answer 1

1. あなたがuserであなたのストリームをkeyBy場合、FLINKは、内部ユーザーによるストリームを分割します。したがって、ユーザーは一連の並列サブタスクに分散されます。ウィンドウ演算子の並列処理は、各並列サブタスクの負荷を制御します。十分なマシンを割り当て、プログラムの並列性を適切に設定すると、1000万人のユーザーには問題はありません。

2. はい、ジョブが複数のマシンで実行されている場合、rebalance()はネットワーク経由でシャッフルします。デフォルト設定では、データポートが自動的に選択されます。固定ポートが必要な場合はconfigureにtaskmanager.data.portキーを使用できます。

3. 状態サイズの制限はコンフィグレーションされたstate backendによって異なります。 RocksDBのバックエンドでは、ローカルファイルシステムのサイズが制限されます。つまり、RocksDBはデータをディスクに吐き出します。この制限に達すると、各作業者は通常複数のキーのキーを処理するため、並列処理を増やすことができます。

4. 状態が永続化されている状態バックエンド（ディスクまたはメモリ）の実装によって異なります。私は、ディスクに書き込むRocksDB状態のバックエンドもメモリ内のいくつかのデータをキャッシュすると仮定します。オペレータ状態はグローバルにアクセス可能ではないことに注意してください。つまり、演算子の各並列サブタスクは、それ自身のローカル状態にのみアクセスでき、同じ演算子の別のサブタスクの状態を読み書きすることはできません。