FlinkとStormの主な違いは何ですか？
Flinkは Sparkと比較して でしたが、これは、ウィンドウ化されたイベント処理システムとマイクロバッチを比較するため、間違った比較です。同様に、FlinkをSamzaと比較することはあまり意味がありません。どちらの場合も、Samzaの場合の「スケール」が小さい場合でも、リアルタイムとバッチイベント処理戦略を比較します。しかし、私はFlinkがStormと比較してどのようになっているのかを知りたいと思っています。
this （スライド＃4）は、Flinkの主な違いを「調整可能なレイテンシ」として文書化しています。別のヒントは、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のボルトに似ています。 StormとFlinkの共通点は、パイプラインデータ転送による低レイテンシストリーム処理を目指していることです。ただし、FlinkはStormと比較してより高レベルのAPIを提供します。 FlinkのDataStream APIは、1つ以上のリーダーとコレクターでボルトの機能を実装する代わりに、Map、GroupBy、Window、Joinなどの機能を提供します。 Stormを使用する場合、この機能の多くは手動で実装する必要があります。別の違いは、処理のセマンティクスです。 Stormは1回以上の処理を保証し、Flinkは1回のみを提供します。これらの処理を保証する実装はかなり異なります。 Stormはレコードレベルの確認応答を使用しますが、FlinkはChandy-Lamportアルゴリズムのバリアントを使用します。簡単に言うと、データソースは定期的にマーカーをデータストリームに挿入します。オペレーターがそのようなマーカーを受け取るたびに、その内部状態をチェックポイントします。すべてのデータシンクがマーカーを受信すると、マーカー（および以前に処理されたすべてのレコード）がコミットされます。障害が発生した場合、すべてのソースオペレーターは、最後にコミットされたマーカーを見たときにその状態にリセットされ、処理が続行されます。このマーカーチェックポイントアプローチは、Stormのレコードレベルの確認応答よりも軽量です。この スライドセット および対応する トーク では、フォールトトレランス、チェックポイント設定、および状態処理を含むFlinkのストリーミング処理アプローチについて説明します。
Stormは、トライデントと呼ばれる1回だけの高レベルAPIも提供します。ただし、トライデントはミニバッチに基づいているため、FlinkよりSparkに似ています。
Flinkの調整可能なレイテンシは、Flinkが1つのタスクから別のタスクにレコードを送信する方法を指します。前に言ったように、Flinkはパイプライン化されたデータ転送を使用し、レコードが生成されるとすぐに転送します。効率のために、これらのレコードはバッファに収集されます。バッファは、いっぱいになるか、一定の時間しきい値に達するとネットワーク経由で送信されます。このしきい値は、レコードが次のタスクに送信されずにバッファ内に留まる最大時間を指定するため、レコードのレイテンシを制御します。ただし、レコードがプログラムに入ってからプログラムを離れるまでにかかる時間については、タスク内の処理時間やネットワーク転送の数などにも依存するため、ハード保証には使用できません。
Fabian Hueskeの答えに追加：
Flinkは、次の方法でもStormを改善します。
バックプレッシャー：Flinkのストリーミングランタイムは、さまざまなオペレーターがさまざまな速度で実行される場合に適切に動作します。これは、ネットワークレイヤーがバッファープールを管理しているにもかかわらず、ダウンストリームオペレーターがアップストリームオペレーターを非常にうまく背圧するためです。
ユーザー定義の状態：Flinkを使用すると、プログラムはオペレーターのカスタム状態を維持できます。その状態は、実際にフォールトトレランスのチェックポイントに参加して、カスタムのユーザー定義状態に対して1回だけの保証を提供できます。 この例 演算子内のユーザー定義のステートマシンを参照してください。これは、データストリームと共に一貫してチェックポイントされます。
ストリーミングウィンドウ：ストリームウィンドウとウィンドウ集約は、データストリームを分析するための重要な構成要素です。 Flinkには、多くの種類のウィンドウをサポートする非常に強力なウィンドウシステムが付属しています。
StormとFlinkの私の経験に基づいています。これらのツールは異なるアプローチで同じ問題を解決できると思います。 @Stephan Ewenが言及したFlinkのすべての機能は、Stormと内部API（つまり、spoltsおよびboltsと一致させることができます。 ）およびTridentAPI。誰かがTridentはミニバッチスタイルであると主張しますが、状態関連または集約を伴う複雑なアプリのほとんどはウィンドウでのバッチ処理にのみ依存すると考えていますスタイル。そのため、ここでは、どちらが優れているかを述べずに、主な違いをいくつか挙げます。
- 開発スタイル。 Flinkのコンピューティング指向（チェーン可能な演算子など）とStormのデータストリーム指向（例えば
addSpolt()/addBolt()）. - 高レベルAPI。 Flink vs. Native WindowとStormのTridentの機能（例：マップ、ウィンドウ、ストリーミングレベルの参加）。
- 保証されたメッセージ処理（GMP。つまり、at-exactly-once）。 FlinkのTwo-Phase Commit Connector（KafkaConsumerなど）を使用したチェックポイントと、外部状態マシンまたはStormのTridentを使用したタプルツリー。
- フォールトトレランス。 FlinkのマーカーチェックポイントとStormのレコードレベルACK。
- 内部アーキテクチャ。 StormのFlinkとマルチレイヤーの抽象化（たとえば、スーパーバイザーのワーカーとしての各JVMと各スーパーバイザーが多くのワーカーを持つことができる各JVMのスロット）の単純な抽象化と相対並列性（CPUコアで考慮される各スレッドのスロットなど）.