3

私はデータ ストリーミング用の apache flink に取り組んでいますが、いくつか質問があります。どんな助けでも大歓迎です。ありがとう。

1) タンブリング ウィンドウの作成に制限はありますか。たとえば、ユーザー ID ごとに 2 秒間のタンブリング ウィンドウを作成したい場合、たとえば 1,000 万を超えるユーザー ID がある場合、それは問題になります。(keyBy ユーザー ID を使用してから、timeWindow を 2 秒間作成しています)? これらのウィンドウは flink で内部的にどのように維持されますか?

2) ラウンド ロビン パーティショニングのリバランスを調べました。クラスターをセットアップしていて、ソースの並列処理が 1 で、リバランスを行った場合、パフォーマンスを向上させるためにマシン間でデータがシャッフルされるでしょうか? その場合、クラスタ内の他のノードにデータを転送するために使用する特定のポートはありますか?

3) 状態の維持に制限はありますか? 非常に大きくなる可能性のあるユーザー ID 関連のデータを維持する予定です。状態を維持するために rocks db を使用した flink について読みました。維持できるデータ量に制限があるかどうかを確認したいだけですか?

4) また、データ量が少ない場合、状態はどこで維持されますか? (JVM メモリで推測します) クラスターに複数のマシンがある場合、すべてのノードが現在の状態のバージョンを取得できますか?

4

1 に答える 1

2

  1. でストリームを keyBy するとuser、Flink はユーザーごとにストリームを内部的に分割します。したがって、ユーザーは一連の並行サブタスクに分散されます。ウィンドウ オペレーターの並列性は、各並列サブタスクの負荷を制御します。十分な数のマシンを割り当て、プログラムの並列処理を適切に構成すれば、1,000 万人のユーザーを処理しても問題ありません。

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

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

  4. これは、状態が保持される状態バックエンド (ディスクまたはメモリ) の実装に依存します。ディスクに書き込む RocksDB 状態バックエンドも、一部のデータをメモリにキャッシュしていると思います。オペレーターの状態はグローバルにアクセスできないことに注意してください。つまり、オペレーターの各並列サブタスクは、それ自体のローカル状態にしかアクセスできず、同じオペレーターの別のサブタスクの状態を読み書きすることはできません。

于 2016-09-24T18:23:28.680 に答える