Yahoo!は，代表的なストリーム処理フレームワークであるApache Flink, Spark, Stormの３つを対象としたベンチマークを行った。
ストリーム処理としてYahoo!は従来，社内開発したS4を使用してきたが，2012年にこれをApache Stormにリプレースする決定をした。現在ではStomを最大2,300ノードで稼働させて，さまざまなデータ処理ニーズに対して幅広く使用している。しかしながら先日，新データ処理フレームワークの候補が第１次段階に到達したことを受け，それらのパフォーマンスをStormと比較するため，GitHubで公開されているベンチマークの実施を決定した。
このベンチマークでは，Apache FlinkとSparkをStormと比較している。テスト対象のアプリケーションは広告に関するもので，100のキャンペーンがそれぞれ10の広告を持つ構成である。５つのKafkaノードを使用して生成されたJSONイベントがデシリアライズされ，フィルタを通過し，関連するキャンペーンと結合された上でRedisノードに格納される仕組みだ。Kafkaは生成するイベント数を50K/秒から170K/秒まで，10刻みに変更することができる。使用されたハードウェアの構成，不足や改善点に関するさまざまな考察などのベンチマークの全容に関しては，このYahoo! Engineeringの記事に示されている。３フレームワークの比較を行うため，Yahoo!では，それぞれのイベント送出率においてタプルが完全に処理されるのに必要な遅延率を測定した。
Yahoo!によると，FlinkとStormの動作には類似点があり，いずれもレイテンシが指数的に増加する場合の遅延率は99%まで，ほぼ直線的に変化した。Storm 0.10.0は，135K/秒のイベントレート以降のデータを処理できなかった。また，ack(肯定応答)を備えたStorm 0.11.0では，150K/秒のデータ処理時に重大な問題があった。ackを無効にした場合のStorm 0.11のパフォーマンスは良好で，Flinkを凌駕した。しかしYahoo!によると，“ackを無効にした状態では，タプルエラーの通知や処理も無効”になるのだという。
Yahoo!のテストでのSparkの成績はバックプレッシャなしで70秒，バックプレッシャありで120秒と，いずれも１秒未満であったFlinkとStormに比較すると，下図のようにかなり見劣りするものだった(150K/秒の場合の遅延率を示す)。
Yahoo!はベンチマークの結果を次のようにまとめている。
私たちにとって重要なのは，Stormの優秀さです。トポロジの記述がシンプルで，かなりのスループットに至るまで，Flinkと同等以上の低レイテンシを簡単に実現できます。ackを使用しない場合のStormは，極めて高いスループットによってFlinkを凌駕しています。インテリジェントの高いタプルのルーティングやack処理の改善などと組み合わせれば，ackを使用したStormでも高いスループットでFlinkを打ち負かすことができるでしょう。
準リアルタイムなストリーミングシステムの競争は激しさを増しています。現時点ではどれが勝者か分かりません。今回取り上げたプラットフォームは，それぞれが長所と短所を有しています。その中でのパフォーマンスは，セキュリティやツールとのインテグレーション，ライブラリなどと同じ，ひとつの要因に過ぎないのです。
Yahoo!では今後もベンチマークを改善して，各データ処理フレームワークの改善への追随を目指すとともに，コミュニティのコントリビュートや改善提案を歓迎している。