FlinkはSparkと比較されていますが、これはウィンドウ表示のイベント処理システムをマイクロバッチ処理と比較するため、これは間違った比較です。同様に、FlinkをSamzaと比較しても、あまり意味がありません。どちらの場合も、Samzaの場合は「スケール」が小さくても、リアルタイムとバッチ処理のイベント処理戦略を比較します。しかし、私はFlinkとStormの比較を知りたいと思っています。

私はこれ（スライド4）でFlinkの「調整可能なレイテンシ」としての主な違いを説明しています。もう1つのヒントは、FlinkがSparkまたはHadoopMRの世界によりよく統合されることを示唆するSlicon Angleの記事のようですが、実際の詳細については言及も参照もされていません。最後に、Fabian Hueske自身がインタビューで、「Apache Stormと比較して、Flinkのストリーム分析機能は高レベルのAPIを提供し、より軽量なフォールトトレランス戦略を使用して、1回限りの処理を保証します」と述べています。

私にとってそれは少しまばらであり、私は要点をまったく理解していません。誰かがStormでのストリーム処理のどの問題をFlinkによって正確に解決できるのか説明できますか？APIの問題とその「より軽量なフォールトトレランス戦略」でHueskeは何を参照していますか？

免責事項：私はApache FlinkコミッターおよびPMCメンバーであり、Stormの高レベルな設計にのみ精通しており、内部には精通していません。

Apache Flinkは、統合されたストリームとバッチ処理のためのフレームワークです。Flinkのランタイムは、パイプライン化されたシャッフルを含む並列タスク間のパイプライン化されたデータ転送により、両方のドメインをネイティブにサポートします。レコードは、作成タスクから受信タスクにすぐに送信されます（ネットワーク転送用のバッファーに収集された後）。バッチジョブは、オプションでブロッキングデータ転送を使用して実行できます。

Apache Sparkは、バッチ処理とストリーム処理もサポートするフレームワークです。FlinkのバッチAPIは、Sparkと非常によく似ており、同様の使用例に対応していますが、内部は異なります。ストリーミングの場合、どちらのシステムも非常に異なるアプローチ（ミニバッチとストリーミング）を採用しているため、さまざまな種類のアプリケーションに適しています。SparkとFlinkの比較は有効で便利ですが、SparkはFlinkと最も類似したストリーム処理エンジンではありません。

元の質問に戻ると、Apache Stormはバッチ機能のないデータストリームプロセッサです。実際、Flinkのパイプラインエンジンは内部的にStormに少し似ています。つまり、Flinkの並列タスクのインターフェースはStormのボルトに似ています。ストームとフリンクは、パイプライン化されたデータ転送による低レイテンシストリーム処理を目指しているという共通点があります。ただし、FlinkはStormと比較してより高レベルのAPIを提供します。FlinkのDataStream APIは、1つ以上のリーダーとコレクターでボルトの機能を実装する代わりに、Map、GroupBy、Window、Joinなどの機能を提供します。Stormを使用する場合、この機能の多くは手動で実装する必要があります。もう1つの違いは、セマンティクスの処理です。Stormは少なくとも1回の処理を保証し、Flinkは1回だけの処理を提供します。これらの処理を保証する実装は、かなり異なります。Stormはレコードレベルの確認応答を使用しますが、FlinkはChandy-Lamportアルゴリズムのバリアントを使用します。簡単に言うと、データソースは定期的にマーカーをデータストリームに挿入します。オペレーターがそのようなマーカーを受け取るたびに、その内部状態をチェックポイントします。マーカーがすべてのデータシンクによって受信されると、マーカー（および以前に処理されたすべてのレコード）がコミットされます。障害が発生した場合、すべてのソースオペレーターは、最後にコミットされたマーカーを確認したときの状態にリセットされ、処理が続行されます。このマーカーとチェックポイントのアプローチは、Stormのレコードレベルの確認応答よりも軽量です。この データソースは定期的にマーカーをデータストリームに挿入します。オペレーターがそのようなマーカーを受け取るたびに、その内部状態をチェックポイントします。マーカーがすべてのデータシンクによって受信されると、マーカー（および以前に処理されたすべてのレコード）がコミットされます。障害が発生した場合、すべてのソースオペレーターは、最後にコミットされたマーカーを確認したときの状態にリセットされ、処理が続行されます。このマーカーとチェックポイントのアプローチは、Stormのレコードレベルの確認応答よりも軽量です。この データソースは定期的にマーカーをデータストリームに挿入します。オペレーターがそのようなマーカーを受け取るたびに、その内部状態をチェックポイントします。マーカーがすべてのデータシンクによって受信されると、マーカー（および以前に処理されたすべてのレコード）がコミットされます。障害が発生した場合、すべてのソースオペレーターは、最後にコミットされたマーカーを確認したときの状態にリセットされ、処理が続行されます。このマーカーとチェックポイントのアプローチは、Stormのレコードレベルの確認応答よりも軽量です。この すべてのソースオペレーターは、最後にコミットされたマーカーを確認して処理を続行すると、その状態にリセットされます。このマーカーとチェックポイントのアプローチは、Stormのレコードレベルの確認応答よりも軽量です。この すべてのソースオペレーターは、最後にコミットされたマーカーを確認して処理を続行すると、その状態にリセットされます。このマーカーとチェックポイントのアプローチは、Stormのレコードレベルの確認応答よりも軽量です。このスライドセットと対応する講演では、フォールトトレランス、チェックポイント、および状態処理を含むFlinkのストリーミング処理アプローチについて説明します。

Stormは、Tridentと呼ばれる1回限りの高レベルAPIも提供します。ただし、トライデントはミニバッチに基づいているため、FlinkよりもSparkに似ています。

Flinkの調整可能なレイテンシは、Flinkがレコードをあるタスクから別のタスクに送信する方法を指します。前に言ったように、Flinkはパイプラインデータ転送を使用し、レコードが生成されるとすぐにレコードを転送します。効率を上げるために、これらのレコードはバッファに収集され、バッファがいっぱいになるか、特定の時間のしきい値に達すると、ネットワーク経由で送信されます。このしきい値は、レコードが次のタスクに送信されずにバッファにとどまる最大時間を指定するため、レコードの待ち時間を制御します。ただし、レコードがプログラムに入ってからプログラムを離れるまでにかかる時間を厳密に保証するために使用することはできません。これは、タスク内の処理時間やネットワーク転送の数などにも依存するためです。

ファビアン・ウエスケの答えに加えて：

Flinkは、Stormを次のようにさらに改善します。

• バックプレッシャー：Flinkのストリーミングランタイムは、さまざまなオペレーターが異なる速度で実行されている場合に適切に動作します。これは、ネットワークレイヤーがバッファープールを管理しているにもかかわらず、ダウンストリームオペレーターがアップストリームオペレーターを適切にバックプレッシャーするためです。

• ユーザー定義の状態：Flinkを使用すると、プログラムでオペレーターのカスタム状態を維持できます。その状態は、フォールトトレランスのチェックポイント設定に実際に参加でき、カスタムユーザー定義の状態に対して1回限りの保証を提供します。オペレーター内のユーザー定義の状態マシンのこの例を参照してください。これは、データストリームと共に一貫してチェックポイントが設定されます。

• ストリーミングウィンドウ：ストリームウィンドウ処理とウィンドウ集計は、データストリームを分析するための重要な構成要素です。Flinkには、多くのタイプのウィンドウをサポートする非常に強力なウィンドウシステムが付属しています。

ストームとフリンクの私の経験に基づいています。これらのツールは、さまざまなアプローチで同じ問題を解決できると思います。@Stephan Ewenによって言及されたFlinkのすべての機能は、Stormによって内部API（つまり、spoltsとボルト）とTrident APIに一致するようになりました。誰かがトライデントはミニバッチスタイルであると主張していますが、状態関連または集約のある複雑なアプリのほとんどはウィンドウスタイルのバッチ処理にのみ依存していると思います だから、私はここにいくつかの主な違いをリストしますが、どちらが良いかは言うまでもありません。

• 開発スタイル。Flinkの計算指向（たとえば、チェーン可能な演算子addSpolt()/addBolt()）とStormのデータストリーム指向（たとえば、）。
• 高レベルAPI。Flinkの関数（マップ、ウィンドウ、ストリーミングレベルでの結合など）とStormのネイティブウィンドウおよびトライデント。
• 保証されたメッセージ処理（GMP、つまりat-exactly-once）。Flinkの2フェーズコミットコネクタ（KafkaConsumerなど）を使用したチェックポイントと、外部状態マシンまたはStormのTridentを使用したタプルツリー。
• フォールトトレランス。FlinkのマーカーチェックポイントとStormのレコードレベルACK。
• 内部アーキテクチャ。Flinkでの単純な抽象化と相対的な並列処理（たとえば、CPUコアで考慮される各スレッドのスロット）とStormでのマルチレイヤー抽象化（たとえば、スーパーバイザーのワーカーとしての各JVMのスロットと各スーパーバイザーは多くのワーカーを持つことができます）。

免責事項：私はClouderaの従業員で、Stormと（まもなく）Flinkの主要なサポーターです。

機能的

多くの優れた技術的ポイントがすでに提示されています。ハイライトの非常に短い要約：

• FlinkとStormはどちらもイベントごとの処理を実行できます
• ストームはそのままではイベント時間をサポートしていないようです
• ストームはSQLサポートを実験段階から引き上げていません

機能しない

• 多くのお客様がStorm（too）が使いづらいと感じました
• ストームの採用は鈍化し、Flinkのコミュニティはストームよりもアクティブになっているようです
• Flinkにはまだいくつかの追いつきがあります（例：文書化された例）。

結論

Clouderaは最近、Storm（HDP）の廃止を発表しました。そして同時にFlinkが後継者として発表されました。

したがって、嵐の中でユースケースがある場合、もちろんそれらは機能し続けます。しかし、新しいユースケースでは、Flinkまたは他のストリーミングエンジンを調べます。