FlinkとStormのパフォーマンスを比較し、分散リアルタイムコンピューティングフレームワークを選択する方法

1. 背景

Apache Flink と Apache Storm は、現在業界で広く使用されている 2 つの分散リアルタイム コンピューティング フレームワークです。その中で、Apache Storm（以下、「Storm」）は、Meituan Dianpingのリアルタイムコンピューティング事業において比較的成熟した形で使用されています。管理プラットフォーム、共通 API、および対応するドキュメントがあります。多数のリアルタイムジョブが Storm に基づいて構築されています。

Apache Storm 参照リンク: http://storm.apache.org/

[[269062]]

Apache Flink（以下、「Flink」）は最近注目を集めています。高スループット、低レイテンシ、高信頼性、正確な計算という特徴があり、イベント ウィンドウのサポートも優れています。 Meituan Dianpingのリアルタイムコンピューティング事業にも応用されています。

Apache Flink 参照リンク: https://flink.apache.org/

Flinkフレームワークをより深く理解し、その安定性と信頼性を検証し、リアルタイム処理性能を評価し、システムの欠点を特定し、性能ボトルネックを見つけて最適化し、ユーザーに最も適したリアルタイムコンピューティングエンジンを提供するために、豊富な実用経験を持つStormフレームワークをコントロールとして使用して、Flinkフレームワークのパフォーマンスをテストする一連の実験を実施しました。

「少なくとも 1 回」および「正確に 1 回」のセマンティクスを保証するリアルタイム コンピューティング フレームワークとしての Flink のリソース消費を計算し、リアルタイム コンピューティング プラットフォームのリソース計画、フレームワークの選択、パフォーマンス チューニング、Flink プラットフォームの構築などの決定に対して提案を行い、データ サポートを提供し、その後の SLA 構築に一定のリファレンスを提供します。

FlinkとStormの比較:

2. テストの目的

異なるシナリオと異なるデータ圧力下での 2 つのリアルタイム コンピューティング フレームワーク (Flink と Storm) の現在のパフォーマンスを評価し、詳細なパフォーマンス データを取得して、処理パフォーマンスの限界を見つけます。さまざまな構成が Flink のパフォーマンスにどの程度影響するかを理解し、さまざまな構成の適用可能なシナリオを分析して、チューニングの推奨事項を作成します。

1. テストシナリオ

1) 「入力-出力」のシンプルな処理シナリオ

「入力-出力」などの単純な処理ロジックのシナリオをテストすることで、他の要素の干渉を可能な限り最小限に抑え、2 つのフレームワーク自体のパフォーマンスを反映できます。

同時に、フレームワークの処理能力の限界が測定され、より複雑なロジックを処理するパフォーマンスは純粋な「入出力」よりも高くなりません。

2) ユーザーの操作に時間がかかるシナリオ

ユーザーの処理ロジックが複雑になったり、データベースなどの外部コンポーネントにアクセスする場合、実行時間が長くなり、ジョブのパフォーマンスに影響します。そのため、ユーザー ジョブに長い時間がかかるシナリオで 2 つのフレームワークのスケジューリング パフォーマンスをテストしました。

3) ウィンドウ統計シナリオ

リアルタイム コンピューティングでは、1 日の 5 分ごとの訪問数、100 件の注文ごとに使用された割引の数など、時間ウィンドウまたはカウント ウィンドウに関する統計を実行する必要があることがよくあります。Flink のウィンドウ サポートは Storm よりも強力で、API もより完全ですが、ウィンドウ統計の一般的なシナリオで 2 つのフレームワークのパフォーマンスを理解することも必要です。

4) 正確な計算シナリオ（つまり、メッセージ配信セマンティクスは「正確に 1 回」）

Storm は、「最大 1 回」および「少なくとも 1 回」のメッセージ配信セマンティクスのみを保証できます。つまり、重複送信が発生する可能性があります。

高いデータ精度が求められ、メッセージが重複や欠落なく配信されることが期待されるビジネス シナリオは数多くあります。 Flink は「正確に 1 回」のセマンティクスをサポートしていますが、リソースが制限されている状況では、精度要件が厳しくなるとコストが高くなり、パフォーマンスに影響する可能性があります。

そのため、私たちは、正確なコンピューティング シナリオでのリソース計画のためのデータ参照を提供することを期待して、異なるメッセージ配信セマンティクスの下で 2 つのフレームワークのパフォーマンスをテストしました。

2. パフォーマンス指標

1) スループット

• コンピューティング フレームワークによって単位時間あたりに正常に送信するデータの量。このテストのスループットの単位は、データ/秒です。
• これは、システムの負荷容量、つまり、対応するリソース条件下でシステムが単位時間あたりに処理できるデータ量を反映します。
• スループットはリソース計画に使用されることが多く、システム パフォーマンスのボトルネックの分析にも使用され、対応するリソース調整を行って、システムがユーザーに必要な処理能力を達成できるようにします。商人が 1 時間あたり 20 食のランチを準備でき (スループット 20 食/時間)、配達員が 1 時間あたり 2 食しか配達できない (スループット 2 食/時間) と仮定します。このシステムのボトルネックは配達員の配達リンクにあります。商店には食品を配達する配達員が 10 人手配されます。

2) レイテンシー

• データがシステムに入り、システムから流出するまでにかかる時間。このテストにおける遅延の単位はミリ秒です。
• これは、システム処理のリアルタイム性を反映しています。
• 金融取引分析などの多くのリアルタイム コンピューティング ビジネスでは、レイテンシに対する要件が高くなります。レイテンシが低いほど、データのリアルタイム性が高まります。
• 商人がランチを準備するのに 5 分、配達員がそれを配達するのに 25 分かかると仮定します。このプロセスでは、ユーザーは 30 分の遅延を経験することになります。配達計画を変更した後、遅延が 60 分になり、到着時に食べ物が冷めている場合、この新しい計画は受け入れられません。

3. テスト環境

Storm および Flink の場合、このテスト用に 1 つのマスター ノードと 2 つのスレーブ ノードで構成されるスタンドアロン クラスターが構築されました。実際の本番環境での Flink のパフォーマンスを観察するために、一部のテスト内容を Yarn 環境でもテストしました。

1. クラスターパラメータ

2. フレームワークパラメータ

4. 試験方法

1. テストプロセス

1) データ生成

データ ジェネレーターは特定のレートでデータを生成し、自動的に増加する ID と eventTime タイムスタンプを使用して Kafka トピック (トピック データ) に書き込みます。

2) データ処理

Storm タスクと Flink タスク (テスト ケースごとに異なります) は、Kafka トピック データの同じオフセットから消費を開始し、結果と対応する inTime および outTime タイムスタンプをそれぞれ 2 つのトピック (Topic Storm と Topic Flink) に書き込みます。

3) 指標統計

メトリック コレクターは、outTime 時間ウィンドウに従って 2 つのトピックからテスト メトリックを収集し、対応するメトリックを 5 分ごとに MySQL テーブルに書き込みます。

Metrics Collector は、outTime に従って 5 分間のローリング時間ウィンドウを取得し、5 分間の平均スループット (出力データの数)、5 分間の遅延の中央値 (outTime - eventTime または outTime - inTime)、および 99 行を計算し、対応する MySQL データ テーブルに書き込みます。最後に、MySQL テーブル内の 99 行の平均スループット、中央値レイテンシ、中央値レイテンシを計算し、グラフを描画して分析します。

2. デフォルトパラメータ

• Storm と Flink はどちらもデフォルトで「少なくとも 1 回」のセマンティクスを使用します。
  • Storm は ACK を有効にし、ACK 送信者の数は 1 です。
  • Flink のチェックポイント間隔は 30 秒で、デフォルトの StateBackend は Memory です。
• Kafka がパフォーマンスのボトルネックにならないようにし、Kafka がテスト結果に与える影響を排除するようにしてください。
• レイテンシをテストする場合、データ生成率はデータ処理能力よりも低くなります。データは Kafka に書き込まれた直後に読み取られると想定されます。つまり、eventTime はデータがシステムに入る時刻と等しくなります。
• スループットをテストするときは、トピックに十分なテスト データがあると仮定して、最も古い Kafka トピックから読み取ります。

3. テストケース

1) アイデンティティ

• Identity ユースケースでは、主に、2 つのフレームワーク自体のパフォーマンスを反映するために、単純な「入出力」処理シナリオをシミュレートします。
• 入力データは「msgId, eventTime」であり、eventTime はデータが生成された時刻とみなされます。 1 つのエントリは約 20 バイトです。
• inTime はジョブ処理フローに入るときに記録され、outTime はジョブ処理が完了した後 (出力の準備をしているとき) に記録されます。
• ジョブは Kafka トピック データからデータを読み取った後、文字列の末尾にタイムスタンプを追加し、それを直接 Kafka に出力します。
• 出力データは「msgId、eventTime、inTime、outTime」です。出力データは1回あたり約50Bです。

アイデンティティフローチャート

2) 睡眠

• Sleep ユースケースは、主にユーザー ジョブに長い時間がかかるシナリオをシミュレートし、複雑なユーザー ロジックによって生じるフレームワークの違いの弱体化を反映し、2 つのフレームワークのスケジューリング パフォーマンスを比較します。
• 入力データと出力データは両方とも Identity と同じです。
• データの読み取り後、一定時間（1 ミリ秒）待機し、文字列の末尾にタイムスタンプを追加して出力します。

睡眠フローチャート

3) ウィンドウ付き単語カウント

• ウィンドウ化された単語カウントの使用例は、主にウィンドウ統計のシナリオをシミュレートし、ウィンドウ統計を実行する際の 2 つのフレームワーク間のパフォーマンスの違いを反映します。
• さらに、Flink の 1 回限りの配信パフォーマンスを反映する正確なコンピューティング シナリオをテストするためにも使用されました。
• 入力は JSON 形式で、msgId、eventTime、およびスペースで区切られた複数の単語で構成される文が含まれます。入力データ 1 つあたりのサイズは約 150 バイトです。
• データを読み取った後、JSON を解析し、文を対応する単語に分割し、eventTime および inTime タイムスタンプとともに CountWindow に送信して単語数をカウントし、ウィンドウ内の最大および最小の eventTime と inTime を記録し、最後に outTime タイムスタンプとともに Kafka の対応する Topic に出力します。
• Spout/Source と OutputBolt/Output/Sink の同時実行性は常に 1 です。同時実行性を増やすと、JSONParser と CountWindow の同時実行性のみが増加します。
• Storm はウィンドウのサポートが弱いため、CountWindow は HashMap を使用して手動で実装され、Flink はネイティブの CountWindow と対応する Reduce 関数を使用します。

ウィンドウ付き単語カウントフローチャート

5. テスト結果

① シングルスレッドスループットの識別

アイデンティティシングルスレッドスループット

• 上の図では、青い列はシングルスレッドの Storm ジョブのスループットであり、オレンジ色の列はシングルスレッドの Flink ジョブのスループットです。
• Identity ロジックでは、Storm のシングルスレッド スループットは 1 秒あたり 87,000 レコードであり、Flink のシングルスレッド スループットは 1 秒あたり 350,000 レコードに達します。
• Kafka Data のパーティション数が 1 の場合、Flink のスループットは Storm の約 3.2 倍になります。パーティション数が 8 の場合、Flink のスループットは Storm の約 4.6 倍になります。
• Flink のスループットは Storm の約 3 ～ 5 倍であることがわかります。

② シングルスレッドジョブの遅延の識別

アイデンティティシングルスレッドジョブ遅延

• 遅延として outTime - eventTime を使用します。図の青い線がStorm、オレンジ色の線がFlinkです。点線は 99 ライン、実線は中央値です。
• 図から、データ量が徐々に増加するにつれて、Identityの遅延も徐々に増加していることがわかります。そのうち、99 行は中央値よりも速く増加しており、Storm は Flink よりも速く増加しています。
• QPS が 80,000 を超えるテスト データは Storm のシングル スレッドのスループット容量を超えるため、Storm をテストすることはできず、Flink の曲線のみが使用可能です。
• 曲線の右端のデータを比較すると、Storm QPS がスループットに近い場合、レイテンシの中央値は約 100 ミリ秒、99 番目の行は約 700 ミリ秒であることがわかります。 Flink の平均レイテンシは約 50 ミリ秒で、99 行目は約 300 ミリ秒です。フルスループットでの Flink のレイテンシは Storm の約半分です。

③ 睡眠スループット

睡眠スループット

• 図からわかるように、スリープ時間が 1 ミリ秒の場合、Storm および Flink の単一スレッドのスループットは 1 秒あたり約 900 であり、同時実行性の増加とともに直線的に増加します。
• 青色の列とオレンジ色の列を比較すると、2 つのフレームワークのスループット機能は基本的に同じであることがわかります。

④ スリープシングルスレッドジョブ遅延（中央値）

スリープ シングルスレッド ジョブの遅延 (中央値)

• 引き続き、outTime - eventTime を遅延として使用すると、Sleep が 1 ミリ秒の場合、Flink の遅延は Storm よりも低いことが図からわかります。

⑤ ウィンドウワードカウントシングルスレッドスループット

ウィンドウ付きワードカウント シングルスレッドスループット

• シングルスレッド実行カウントウィンドウのサイズは 10 で、スループット統計が図に示されています。
• 図からわかるように、Storm のスループットは 1 秒あたり約 12,000 レコード、Flink Standalone のスループットは 1 秒あたり約 43,000 レコードです。 Flink のスループットは、依然として Storm の 3 倍以上です。

⑥ ウィンドウ付きワードカウントFlinkの少なくとも1回と正確に1回のスループット比較

ウィンドウ付きワードカウント Flink の少なくとも 1 回と正確に 1 回のスループット比較

• 同じオペレータの複数の並列タスクの処理速度は異なる場合があるため、上流オペレータの異なるスナップショットの内容は、中間の並列オペレータによって処理された後に下流オペレータに到達すると、同じスナップショットにカウントされる場合があります。このようにして、この部分のデータは繰り返し処理されます。したがって、Flink は Exactly Once セマンティクスに基づいてアライメントを実行する必要があります。つまり、現在の最も古いスナップショット内のすべてのデータが処理される前に、次のスナップショットに属するデータは処理されずにキャッシュ内で待機します。現在のテスト ケースでは、JSON Parser と CountWindow 間、および CountWindow と Output 間の調整が必要であり、時間がかかります。アライメント シナリオを反映するために、Source/Output/Sink の同時実行性は 1 のままで、JSONParser/CountWindow の同時実行性が増加します。具体的なプロセスの詳細については、上記のウィンドウ化された単語カウントのフローチャートを参照してください。
• 上図では、オレンジ色の列は「少なくとも 1 回」のスループット、黄色の列は「正確に 1 回」のスループットです。 2 つを比較すると、現在の同時実行条件下では、Exactly Once のスループットは At Least Once のスループットよりも 6.3% 低いことがわかります。

⑦ ウィンドウ付きワードカウントストームの「少なくとも1回」と「最大で1回」のスループット比較

ウィンドウ付きワードカウントストームの「少なくとも 1 回」と「最大で 1 回」のスループット比較

• Storm が ACK の数をゼロに設定すると、各メッセージは送信されるときに自動的に ACK されます。 Bolt からの ACK を待つ必要がなくなり、メッセージを再送信する必要もなくなりました。これは「At Most Once」セマンティクスです。
• 上図では、青い列が「少なくとも 1 回」のスループット、水色の列が「最大 1 回」のスループットです。 2 つを比較すると、現在の同時実行条件下では、「At Most Once」セマンティクスでのスループットが「At Least Once」でのスループットよりも 16.8% 高いことがわかります。

⑧ ウィンドウワードカウント シングルスレッドジョブ遅延

ウィンドウ化されたワードカウント シングルスレッドジョブの遅延

• Identity と Sleep は両方とも outTime - eventTime を観察します。ジョブの処理時間が短いか、Thread.sleep の精度が高くないため、outTime - inTime はゼロになるか、比較の意味がありません。 outTime - inTime の値は、Windowed Word Count で効果的に測定でき、outTime - eventTime と同じグラフにプロットされます。outTime - eventTime は点線、outTime - InTime は実線です。
• 2 本のオレンジ色の線から、Flink によって両方の方法で計算されたレイテンシが低いレベルに維持されていることがわかります。 2 つの青い曲線から、Storm の outTime - inTime は低く、outTime - eventTime は常に高いことがわかります。つまり、inTime と eventTime の差は常に大きく、これは Storm と Flink のデータ読み取り方法に関連している可能性があります。
• 青い線は、Storm のレイテンシがデータ量とともに増加することを示しており、オレンジ色の線は、Flink のレイテンシがデータ量とともに減少することを示しています (Flink のスループットはここでは測定されておらず、スループットに近づくと Flink のレイテンシは依然として増加します)。
• outTime - inTime (図の実線) のみに注目した場合でも、QPS が徐々に増加するにつれて、レイテンシにおける Flink の優位性が現れ始めることがわかります。

⑨ ウィンドウ付きワードカウントFlinkの「少なくとも1回」と「正確に1回」のレイテンシ比較

ウィンドウ付きワードカウントFlinkの「少なくとも1回」と「正確に1回」のレイテンシ比較

• 図では、黄色の線が 99 ライン、オレンジ色の線が中央値、点線が「少なくとも 1 回」、実線が「正確に 1 回」です。図中の対応する色の仮想曲線と実曲線は基本的に重なり合っています。 Flink Exactly Once の中央レイテンシ曲線は基本的に At Least Once と一致しており、レイテンシパフォーマンスに大きな違いがないことがわかります。

⑩ ウィンドウ付きワードカウントストームの「少なくとも 1 回」と「最大で 1 回」の遅延比較

ウィンドウ付きワードカウントストームの「少なくとも 1 回」と「最大で 1 回」の遅延の比較

• 図では、青い線が 99 ライン、水色の線が中央値、点線が「少なくとも 1 回」、実線が「最大で 1 回」です。 QPS が 4000 以下の場合、点線と実線は基本的に重なります。 QPS が 6000 の場合、両者の間に差があり、点線がわずかに高くなります。 QPS が 8000 に近づくと、「少なくとも 1 回」セマンティクスでの Storm のスループットを超えるため、実線上には点のみが表示されます。
• QPS が低い場合、Storm At Most Once と At Least Once の間でレイテンシに違いがないことがわかります。 QPS が増加するにつれて、差は大きくなり始め、At Most Once のレイテンシは低くなります。

⑪ウィンドウ付きワードカウントFlinkスループットの異なるStateBackendsの比較

ウィンドウ付きワードカウント Flink スループットのさまざまな StateBackends の比較

• Flink は、スタンドアロンおよび YARN のクラスター展開モードをサポートし、Memory、FileSystem、RocksDB の 3 つの状態ストレージ バックエンドもサポートします。オンライン操作のニーズにより、2 つのクラスター展開モードでこれら 3 つの StateBackend のパフォーマンスの違いがテストされました。 Standalone のストレージ パスは JobManager 上のファイル ディレクトリであり、Yarn のストレージ パスは HDFS 上のファイル ディレクトリです。
• 3 つの列グループを比較すると、FileSystem と Memory を使用したスループットはそれほど差がなく、RocksDB を使用したスループットは他の 2 つの約 10 分の 1 しかないことがわかります。
• 2 つの色を比較すると、Standalone と Yarn の全体的な違いはそれほど大きくないことがわかります。 Yarn モードのスループットは、FileSystem と Memory を使用するとわずかに高くなり、スタンドアロン モードのスループットは、RocksDB を使用するとわずかに高くなります。

⑫ ウィンドウ付きワードカウント Flink レイテンシの異なる StateBackends の比較

ウィンドウ化された単語カウントFlinkの異なるStateBackendsの遅延効果

• ファイルシステムとメモリをバックエンドとして使用する場合、レイテンシは基本的に一定で低くなります。
• RocksDB をバックエンドとして使用すると、レイテンシがわずかに高くなり、スループットが低いため、スループットのボトルネックに達する前にレイテンシが急激に増加します。 YARN モードではスループットが低くなり、スループットに近づくとレイテンシが高くなります。

VI.結論と提言

1. フレームワーク自体のパフォーマンス

①と⑤のテスト結果から、Stormのシングルスレッドスループットは1秒あたり約87,000レコード、Flinkのシングルスレッドスループットは1秒あたり350,000レコードに達することがわかります。 Flink のスループットは Storm の約 3 ～ 5 倍です。

②と⑧のテスト結果から、Storm QPSがスループットに近い場合、レイテンシの中央値（Kafkaの読み込みと書き込み時間を含む）は約100ミリ秒、99行で約700ミリ秒であることがわかります。 Flink の平均レイテンシは約 50 ミリ秒で、99 行では約 300 ミリ秒です。フル スループットでの Flink のレイテンシは Storm の約半分であり、QPS が徐々に増加するにつれて、Flink のレイテンシの利点が現れ始めます。

まとめると、Flink フレームワーク自体のパフォーマンスは Storm よりも優れています。

2. 複雑なユーザーロジックがフレームワークの違いを弱める

①と③、②と④のテスト結果を比較すると、1回のBolt Sleepの継続時間が1ミリ秒に達すると、FlinkのレイテンシはStormよりも低いままですが、スループットの優位性は基本的に反映されなくなることがわかります。

したがって、ユーザー ロジックが複雑でテストに時間がかかるほど、そのロジックのテストに反映されるフレームワークの違いは小さくなります。

3. メッセージ配信のセマンティクスの違い

⑥、⑦、⑨、⑩のテスト結果から、Flink Exactly OnceのスループットはAt Least Onceよりも6.3%低く、レイテンシの差は大きくないことがわかります。 Storm At Most Once セマンティクスでのスループットは At Least Once の場合よりも 16.8% 高く、レイテンシはわずかに短縮されます。

Storm は各メッセージに ACK を送信し、Flink はメッセージのバッチに基づいてチェックポイントを実行するため、実装の原則が異なると、2 つの間で At Least Once セマンティクスのコストに大きな差が生じ、パフォーマンスに影響します。 Flink は、アライメント操作を追加するだけで Exactly Once セマンティクスを実装するため、演算子の同時実行性が大きくなく、低速ノードがない場合、Flink のパフォーマンスにほとんど影響はありません。 Storm At Most Once セマンティクスのパフォーマンスは、Flink よりもまだ低いです。

4. Flink状態ストレージバックエンドの選択

Flink は、メモリ、ファイル システム、RocksDB の 3 つの StateBackend を提供します。 ⑪と⑫のテスト結果を組み合わせると、3つの比較は次のようになります。

5. Flinkの使用に推奨されるシナリオ

上記のテスト結果に基づいて、次のリアルタイム コンピューティング シナリオでは Flink フレームワークを使用することをお勧めします。

• メッセージ配信セマンティクスが正確に 1 回であることを必要とするシナリオ。
• 大量のデータと高スループット、低レイテンシが求められるシナリオ。
• 状態管理またはウィンドウ統計が必要なシナリオ。

七。見通し

このテストには、まだ詳細にテストされていない内容がいくつかあり、後続のテストで補足する必要があります。例えば：

• 同時実行性が増加すると、Exactly Once のスループットは大幅に低下しますか?
• ユーザーの消費時間が 1 ミリ秒に達すると、フレームワーク間の違いは明らかではなくなります (Thread.sleep() の精度はミリ秒単位に限られます)。ユーザーの時間消費のどの範囲で Flink の利点が反映されるでしょうか?

このテストでは、スループットとレイテンシという 2 つの指標のみが観察されました。システムの信頼性や拡張性などの重要なパフォーマンス指標は統計データ レベルでは考慮されておらず、後で補足する必要があります。

RocksDBStateBackend を使用する場合の Flink のスループットは低いため、さらなる調査と最適化が必要です。

Table API & SQL や CEP などの Flink のより高度な API については、さらなる理解と改善が必要です。