フリンクはスパークと比較してこれは、ウィンドウ化されたイベント処理システムとマイクロバッチ処理を比較しているため、間違った比較だと私は思います。同様に、Flink と Samza を比較しても、あまり意味がありません。どちらの場合も、Samza の場合は「規模」が小さいとはいえ、リアルタイムとバッチ処理のイベント処理戦略を比較しています。しかし、概念的には Flink に非常に似ていると思われる Storm と Flink を比較するとどうなるのか知りたいです。
見つけたこれ（スライド4）Flinkの「調整可能なレイテンシ」という主な違いを文書化しています。もう1つのヒントは、シリコン角度FlinkはSparkやHadoopMRの世界とよりよく統合されることを示唆しているが、実際の詳細は言及も参照もされていない。最後に、Fabian Hueske自身が述べている。インタビューで「Apache Storm と比較して、Flink のストリーム分析機能は高レベルの API を提供し、より軽量なフォールト トレランス戦略を使用して、正確に 1 回の処理を保証します。」
これらはすべて私にとっては少々物足りなく、要点がよくわかりません。Storm のストリーム処理に関するどのような問題が Flink によって正確に解決されるのか説明してくれる人はいますか? Hueske が API の問題と「より軽量なフォールト トレランス戦略」で言及しているのは何ですか?
ベストアンサー1
免責事項: 私は Apache Flink コミッター兼 PMC メンバーですが、Storm の高レベルの設計には精通しており、内部についてはよく知りません。
Apache Flink は、統合されたストリームおよびバッチ処理のフレームワークです。Flink のランタイムは、パイプライン シャッフルを含む並列タスク間のパイプライン データ転送により、両方のドメインをネイティブにサポートします。レコードは、生成タスクから受信タスクにすぐに送信されます (ネットワーク転送用にバッファーに収集された後)。バッチ ジョブは、オプションでブロッキング データ転送を使用して実行できます。
Apache Spark is a framework that also supports batch and stream processing. Flink's batch API looks quite similar and addresses similar use cases as Spark but differs in the internals. For streaming, both systems follow very different approaches (mini-batches vs. streaming) which makes them suitable for different kinds of applications. I would say comparing Spark and Flink is valid and useful, however, Spark is not the most similar stream processing engine to Flink.
Coming to the original question, Apache Storm is a data stream processor without batch capabilities. In fact, Flink's pipelined engine internally looks a bit similar to Storm, i.e., the interfaces of Flink's parallel tasks are similar to Storm's bolts. Storm and Flink have in common that they aim for low latency stream processing by pipelined data transfers. However, Flink offers a more high-level API compared to Storm. Instead of implementing the functionality of a bolts with one or more readers and collectors, Flink's DataStream API provides functions such as Map, GroupBy, Window, and Join. A lot of this functionality must be manually implemented when using Storm. Another difference are processing semantics. Storm guarantees at-least-once processing while Flink provides exactly-once. The implementations which give these processing guarantees differ quite a bit. While Storm uses record-level acknowledgments, Flink uses a variant of the Chandy-Lamport algorithm. In a nutshell, data sources periodically inject markers into the data stream. Whenever an operator receives such a marker, it checkpoints its internal state. When a marker was received by all data sinks, the marker (and all records which have been processed before) are committed. In case of a failure, all sources operators are reset to their state when they saw the last committed marker and processing is continued. This marker-checkpoint approach is more lightweight than Storm's record-level acknowledgments. This slide set and the corresponding talk discuss Flink's streaming processing approach including fault tolerance, checkpointing, and state handling.
Storm also offers an exactly-once, high-level API called Trident. However, Trident is based on mini-batches and hence more similar to Spark than Flink.
Flink's adjustable latency refers to the way that Flink sends records from one task to the other. I said before, that Flink uses pipelined data transfers and forwards records as soon as they are produced. For efficiency, these records are collected in a buffer which is sent over the network once it is full or a certain time threshold is met. This threshold controls the latency of records because it specifies the maximum amount of time that a record will stay in a buffer without being sent to the next task. However, it cannot be used to give hard guarantees about the time it takes for a record from entering to leaving a program because this also depends on the processing time within tasks and the number of network transfers among other things.