Spark Streaming vs Flink vs Storm vs Kafka Streams vs Samza : Choose Your Stream Processing Framework

Written by on in Articles

IBM Marketing cloudの最近のレポートによると、「今日の世界のデータの90％は、過去2年間だけで作られ、2が生み出されている」。また、新しいデバイス、センサー、およびテクノロジの出現により、データの増加速度はさらに加速する可能性があります。
技術的には、私たちのビッグデータ処理の世界は、より複雑で困難になっていくことを意味します。 また、多くのユースケース（モバイルアプリの広告、詐欺の検出、タクシー予約、患者のモニタリングなど）では、データが到着したときにリアルタイムでデータ処理を行い、すぐに実行可能な決定を下す必要があります。 これが、分散ストリーム処理がビッグ データ分野で非常に普及している理由です。

現在、多くのオープン ソース ストリーミング フレームワークが利用可能になっています。 興味深いことに、ほとんどすべてのフレームワークは非常に新しく、ここ数年で開発されたものばかりです。 そのため、ストリーミングフレームワークを理解し、区別する際に、初心者は非常に混乱しやすくなっています。 この記事では、まず一般的なストリーム処理の種類と側面について話し、次に最も人気のあるオープンソースのストリーミングフレームワークを比較します：Flink、Spark Streaming、Storm、Kafka Streamsです。 これらがどのように動作するか（簡単に）、使用例、長所、限界、類似点、相違点を説明します。

ストリーミング/ストリーム処理とは：
私が見つけた最もエレガントな定義は、「無限データセットを念頭に置いて設計された、データ処理エンジンの一種」です。 3619>

バッチ処理では、データの開始と終了がジョブで定義され、その有限のデータを処理した後にジョブが終了しますが、ストリーミングは、数日、数か月、数年、永遠に連続してリアルタイムで入ってくる無限のデータを処理するためのものです。

ストリーム処理の重要な側面：

Streaming frameworkの強さと限界を理解するために知っておくべき、ストリーム処理に関連するいくつかの重要な特性や用語があります：

  • Delivery Guarantees :
    それは、何があっても、ストリーミングエンジンの特定の受信レコードが処理されるという保証とは何かということです。 Atleast-once（失敗しても最低1回は処理する）、Atmost-once（失敗しても処理しない）、Exact-once（失敗してもちょうど1回だけ処理する）のいずれかになります。
  • Fault Tolerance :
    ノード障害やネットワーク障害などの障害が発生した場合、フレームワークは回復でき、出発点から再び処理を開始できる必要があります。 例えば、Kafka からレコードを取得し、それを処理した後、kafka オフセットを zookeeper にチェックポイントするような場合です。
  • パフォーマンス：
    レイテンシー（レコードを処理できる時間）、スループット（処理したレコード数/秒）、スケーラビリティが含まれます。 レイテンシはできるだけ小さく、スループットはできるだけ大きくする必要があります。
  • 高度な機能。 イベントタイム処理、ウォーターマーク、ウィンドウ処理
    これらはストリーム処理の要件が複雑な場合に必要となる機能である。 例えば、ソースで生成された時間に基づいてレコードを処理する（イベントタイム処理）。 詳しくは、GoogleのTyler Akidau氏による必読の投稿をご覧ください：part1およびpart2
  • Maturity :
    採用の観点から重要なことは、フレームワークがすでに実績があり、大企業によって大規模にテストされていればいいということです。 4978>

ストリーム処理の2つのタイプ:

今説明した用語を理解した上で、ストリーミングフレームワークを実装するには2つのアプローチがあることを理解するのは簡単です:

ネイティブストリーミング :
ネイティブストリーミングとしても知られています。 これは、すべての受信レコードが、他のレコードを待たずに、到着と同時に処理されることを意味します。 いくつかの連続実行プロセス（我々は、フレームワークに応じて演算子/タスク/ボルトとして呼び出される）があり、永遠に実行され、すべてのレコードが処理されるためにこれらのプロセスを通過する。 例: 例：Storm、Flink、Kafka Streams、Samza。

マイクロバッチ：
Fast Batching とも呼ばれる。 数秒ごとに受信するレコードを一括して、数秒の遅れで1つのミニバッチとして処理することを意味します。 例 3619>

いずれのアプローチにも利点と欠点があります。
Native Streaming はすべてのレコードを到着と同時に処理するので自然に感じ、フレームワークは最短遅延を達成することが可能になります。 しかし、それはまた、各レコードについて、一度処理されたら追跡してチェックポイントする必要があるため、スループットを犠牲にすることなくフォールト トレランスを達成することが困難であることを意味します。 また、必要な状態を簡単に維持できる長時間稼働するプロセスがあるため、状態管理も簡単です。

一方、マイクロバッチはまったく逆です。 バッチ処理なので耐故障性は高く、処理とチェックポイントをレコード群に対して一発で行うのでスループットも高くなります。 しかし、その分レイテンシーが発生し、自然なストリーミングとは言い難い。

ストリーミングフレームワーク：

Storm :
Stormはストリーミングの世界ではHadoopです。 最も古いオープンソースのストリーミングフレームワークであり、最も成熟し、信頼できるものの1つです。 真のストリーミングであり、単純なイベントベースのユースケースに適しています。 Stormの詳細については、以下の投稿で詳しく説明しています：パート1、パート2。

長所。

  • 非常に低いレイテンシ、真のストリーミング、成熟した高いスループット
  • 複雑でないストリーミングの使用例に最適

デメリット

  • 状態管理なし
  • イベントタイム処理などの高度な機能なし。 アグリゲーション、ウィンドウ、セッション、ウォーターマークなど
  • アトレストワンス保証

Spark Streaming :

Spark はバッチ処理における hadoop の真の後継として登場し、Lambda Architecture (バッチとストリーミングの両方が実装されたフレームワーク; 正しさのためのバッチと速さのためのストリーミング) を完全にサポートする最初のフレームワークです。 バッチ処理とストリーミング処理の両方が実装されています。 Spark StreamingはSparkに無償で付属しており、ストリーミングにマイクロバッチを使用します。 2.0以前のSpark Streamingは性能に大きな制限がありましたが、2.0+では構造化ストリーミングと呼ばれ、Tungstenと呼ばれるカスタムメモリ管理（flinkのように）、ウォーターマーク、イベントタイム処理サポートなど多くの優れた機能を備えています。 また、Structured Streamingはより抽象的で、2.3.0リリースではマイクロバッチモードと連続ストリーミングモードを切り替えるオプションが用意されています。 Continuous StreamingモードはStormやFlinkのようなサブレイテンシーを約束するものですが、まだ初期段階であり、オペレーションに多くの制限があるのが実情です。

利点です。

  • Lambda アーキテクチャをサポートし、Spark
  • 高いスループットを実現します。 サブレイテンシーを必要としない多くのユースケースに適している
  • マイクロバッチの性質によるデフォルトのフォールトトレランス
  • 高レベルAPIの使用がシンプル
  • 大きなコミュニティと積極的な改善
  • 正確に一度

デメリット

  • 真のストリーミングではないこと。 低遅延の要件に適していない
  • 調整するパラメータが多すぎる。 正しく動作させるのが難しい。 Spark Streaming をチューニングしたときの個人的な経験について記事を書きました
  • Stateless by nature
  • Lags behind Flink in many advanced features

Flink :

Flink も Spark と同様の学術背景を持つものである。 Sparkがカリフォルニア大学バークレー校出身であるのに対して、FlinkはベルリンTU大学出身です。 Sparkと同様にLambdaアーキテクチャをサポートしています。 しかし、実装はSparkとは全く逆です。 Sparkは基本的にバッチ処理で、Spark Batchのマイクロバッチと特殊なケースとしてSpark Streamingがあるのに対し、Flinkは基本的に真のストリーミングエンジンで、バッチはデータを束縛したストリーミングの特殊なケースとして扱われます。 両フレームワークのAPIは似ているが、実装は似ていない。 Flinkでは、map, filter, reduceなどの各関数はlong running operatorとして実装されています（StormのBoltに似ています）

Flink は、バッチにおけるHadoopを継承したSparkのように、Stormの真の後継となりそうです。

長所。

  • オープンソースのストリーミング処理における革新のリーダー
  • イベントタイム処理、ウォーターマークなど、すべての先進機能を備えた初の真のストリーミングフレームワーク
  • 高スループットで低レイテンシー。 要件に応じて設定可能
  • 自動調整、調整すべきパラメータはそれほど多くない
  • 正確に一度
  • Uber、Alibabaなどの大規模な大企業で広く受け入れられている。

Disadvantages

  • Little late in game, there was lack of adoption initially
  • Community is not bigger as Spark but growing at fast pace now
  • No known adoption of the Flink Batch as now, only popular for streaming.It is not known as now.

Kafka Streams :

Kafka Streamsは、他のストリーミングフレームワークと異なり、軽量なライブラリです。 Kafka からデータをストリーミングし、変換を行い、Kafka に送り返すのに便利です。 Java Executor Service Thread poolに似たライブラリとして理解できますが、Kafkaのサポートは内蔵されています。 どのようなアプリケーションにもうまく統合でき、すぐに動作します。

その軽量な性質により、マイクロサービスタイプのアーキテクチャで使用できます。 Flink のパフォーマンスにはかなわないが、実行するために別のクラスタを必要とせず、非常に便利で簡単にデプロイして動作させることができる。 この記事では、Kafka StreamsとFlink Streamingのユースケースを徹底的に説明します。

Kafka Streamsの大きな利点の1つは、その処理がまさにOnce to Endであるということです。 送信元と送信先、両方がKafkaだからできることで、2017年6月頃にリリースされたKafka 0.11バージョンからExactly onceがサポートされました。 この機能を有効にするためには、フラグを有効にするだけで、すぐに動作するようになります。 詳細はこちらとこちらをご覧ください。

Advantages:

  • Very light weight library, good for microservices, IOT applications
  • Does no need dedicated cluster
  • Inherits all Kafka good characteristics
  • upported Stream join, internally uses rocksDb for maintaining state.
  • Ectly Once ( Kafka 0.).11以降）。

デメリット

  • Kafkaと密接に連携しており、Kafkaなしでは使用できない
  • 初期段階でかなり新しく、まだ大企業でテストされていない
  • スパークストリーミングやフリンクなどの重い仕事には使えない
  • Kafkaのような強力なアプリケーションでは使わない。

サムザ：

サムザについて簡単に説明します。 Samzaは、Kafka Streamsと同じようなアプローチに見えます。 多くの類似点があります。 この2つのフレームワークは、LinkedInでSamzaを実装し、Confluentを設立してKafka Streamsを書いたのと同じ開発者によって開発されました。 どちらもKafkaと密接に連携し、Kafkaから生データを取得し、処理したデータをKafkaに戻すという技術です。 同じKafka Logの哲学を使う。 SamzaはKafka Streamsのスケーラブルバージョンといったところでしょうか。 Kafka Streamsがマイクロサービス向けのライブラリであるのに対し、SamzaはYarn上で動作する本格的なクラスタ処理です。
利点：

  • rocksDbとkafka logを使って大きな情報の状態を維持するのに非常に適しています（ストリームを結合するユースケースに適しています）。
  • Kafka のプロパティを使用した耐障害性と高パフォーマンス
  • 処理パイプラインですでに Yarn と Kafka を使用している場合に考慮すべきオプションの 1 つです。
  • Good Yarn citizen
  • Low latency , High throughput , mature and tested at scale

Disadvantages :

  • Kafka and Yarn と密接に結合している。
  • Atleast-Once 処理保証。 Kafka 0.11以降のKafka Streamsのように、1回しか処理できないのかどうかはわかりません。
  • ウォーターマーク、セッション、トリガーなどの高度なストリーミング機能がない。 Storm、Kafka Streams、および Samza は、より単純なユースケースには便利ですが、本当の競争は、最新の機能を備えたヘビー級製品の間ではっきりと行われます。 Spark vs Flink

    比較について話すとき、一般的には、「数字を見せてくれ」と尋ねがちですが、

    Benchmarking は第三者によって行われていれば良い比較方法なんですが、例えば昔のベンチマークの1つはこれです。
    しかし、これは Spark Streaming 2.0 より前の時期で、RDD の制限があり、project Tungsten も導入されていませんでした。
    2.0 リリース後の Structured Streaming で Spark Streaming はかなり追いつこうとしていますが、今後厳しい戦いになるように思われます。

    Spark は最近 Flink とのベンチマーク比較を行い、Flink 開発者は別のベンチマークで応え、その後 Spark 開発者はその投稿を編集しました。

    最近のベンチマークは信じないほうがよいでしょう。 自分たちで試してみてから判断するのが一番です。
    今日、Flink がストリーミング解析の分野をリードしていることは明らかで、正確に一度、スループット、レイテンシー、状態管理、フォールト トレランス、高度な機能など、望ましい側面の大部分を備えています。
    Flink に関する1つの重要な懸念は、成熟度と採用レベルでしたが、今では Uber、Alibaba、CapitalOne といった企業が大規模に Flink ストリーミングを使用しており、Flink ストリーミングの潜在能力を証明しています。 この投稿では、彼らがストリーミング分析をどのように STorm から Apache Samza へと移行し、現在は Flink に移行したかについて説明しています。 RocksDbは、各ノード上でローカルに永続的な状態を維持し、高いパフォーマンスを発揮するという意味でユニークです。 新しいストリーミング・システムには欠かせない存在になっている。 RocksDbの詳細については、以前の記事で紹介しています。

    最適なストリーミングフレームワークの選び方：

    ここが一番重要なところですね。 正直なところ、「場合による」です。
    単一の処理フレームワークがすべてのユースケースのための特効薬になることはないということを心に留めておくことが重要です。 どのフレームワークにも、いくつかの長所があり、また、いくつかの制限もあります。 それでも、いくつかの経験をもとに、意思決定に役立ついくつかのポインタを共有します：

    1. 使用事例による
      ユースケースが単純な場合、学習と実装が複雑な最新かつ最高のフレームワークを使用する必要はありません。 多くの場合、どれだけの見返りを求めて、どれだけの投資をするつもりなのかに依存します。 たとえば、単純な IOT のようなイベント ベースのアラート システムであれば、Storm や Kafka Streams でまったく問題なく動作します。
      同時に、将来どのようなユースケースが考えられるかについて、意識的に検討する必要があります。 イベントタイム処理、集約、ストリーム結合などの高度な機能の要求が将来来る可能性はあるのでしょうか。 もし答えがイエスかノーなら、Spark StreamingやFlinkのような先進的なストリーミング・フレームワークを導入した方がよいでしょう。 一度、ある技術に投資し、実装すると、後で変更するのは難しく、莫大なコストがかかります。 例えば、前の会社では、2年前からStormパイプラインを稼働させていて、受信イベントを一意化して、一意なイベントだけをレポートするという要件が来るまでは、全く問題なく動いていました。 これはStormが本質的にサポートしていない状態管理を要求していました。 私は時間ベースのインメモリハッシュマップを使用して実装しましたが、再起動時に状態が消えてしまうという制限がありました。 また、以前の投稿で共有したように、このような変更時に問題が発生しました。 私が言いたいのは、フレームワークが明示的に提供していないものを独自に実装しようとすると、未知の問題にぶつかるということです。
    2. Existing Tech Stack :
      もう 1 つの重要な点は、既存の技術スタックを考慮することです。 既存のスタックに Kafka がある場合、Kafka Streams または Samza の方が簡単に適合する可能性があります。 同様に、処理パイプラインがLambdaアーキテクチャに基づいており、Spark BatchまたはFlink Batchがすでに導入されている場合、Spark StreamingまたはFlink Streamingを検討することは理にかなっています。 例えば、私の以前のプロジェクトでは、パイプラインにSpark Batchをすでに持っていたので、ストリーミングの要件が来たとき、ほとんど同じスキルセットとコードベースを必要とするSpark Streamingを選ぶことは非常に簡単でした。 最後に、いくつかのオプションを選択したら、常に POC を持つことは良いことです。

      結論:

      Apache ストリーミング領域は非常に速いペースで進化しているので、この投稿は数年後には情報の面で古くなっているかもしれません。 現在、Spark と Flink が開発の面で先頭を走る重鎮ですが、いくつかの新しい子供がやってきて、レースに参加することができます。 Apache Apexはその一つです。 また、Google Dataflowのように、ここでは取り上げなかったが、独自のストリーミング・ソリューションもある。 この記事の目的は、ストリーミングの初心者が、専門用語を使わずに、ストリーミングのコア・コンセプトを、人気のあるオープンソースのストリーミング・フレームワークの長所、限界、使用例とともに理解できるようにすることだ。 この投稿が何らかの形で役に立ったことを願っています。

      ハッピー ストリーミング！

      Linkedin と Quora

      で私をフォローできます。

コメントを残す

メールアドレスが公開されることはありません。