7

スパーク ストリームでは、ほぼリアルタイムのマイクロバッチ処理のバッチ間隔を設定します。Flink (DataStream) や Storm では、ストリームはリアルタイムなので、バッチ間隔という概念はないと思います。

Kafka では、コンシューマーがプルしています。Spark はバッチ間隔パラメーターを使用して Kafka ブローカーからメッセージをプルすると思いますが、Flink と Storm はどのようにそれを行うのでしょうか? Flink と Storm が高速ループで Kafka メッセージをプルしてリアルタイム ストリーム ソースを形成すると想像します。そうであれば、Spark のバッチ間隔を 100 ミリ秒、50 ミリ秒、またはさらに小さく設定した場合、Spark 間に大きな違いはありますか?ストリーミングとフリンクまたはストーム?

一方、Spark では、ストリーミング データが大きく、バッチ間隔が小さすぎる場合、処理待ちのデータが大量にあるという状況に遭遇する可能性があり、その結果、OutOfMemmory が発生することがわかります。Flink または Storm で発生しますか?

トピックからトピックへの変換を行うアプリケーションを実装しました。変換は簡単ですが、ソース データが膨大になる可能性があります (IoT アプリと考えると)。私のオリジナルの実装はreact-kafkaに支えられており、スタンドアロンの Scala/Akka アプリで問題なく動作します。必要に応じて Flink/Storm/Spark が既に存在するため、クラスター化するアプリケーションを実装しませんでした。次に、Kafka Stream を見つけました。私にとっては、クライアントの使用状況の観点からは、reactive-akka に似ています。では、スタンドアロン アプリケーションまたはマイクロサービスで Kafka ストリームまたはリアクティブ カフカを使用する場合、クライアント コードの信頼性/可用性について考慮する必要がありますか?

4

1 に答える 1

13

マイクロバッチとストリーム処理についての理解は正しいです。また、3 つのシステムはすべて、Kafka が提供する標準の Java コンシューマーを使用して、無限ループで処理するデータをプルすることも正しいです。

主な違いは、Spark が処理するマイクロバッチごとに新しいジョブをスケジュールする必要があることです。そして、このスケジューリング オーバーヘッドは非常に高く、Spark は 100 ミリ秒や 50 ミリ秒などの非常に短いバッチ間隔を効率的に処理できず、これらの小さなバッチのスループットが低下します。

Flink と Storm はどちらも真のストリーミング システムであるため、ジョブは起動時に 1 回だけデプロイされ (ジョブはユーザーによって明示的にシャットダウンされるまで継続的に実行されます)、オーバーヘッドや非常に低いレイテンシーなしで個々の入力レコードを処理できます。

さらに、Flink の場合、利用可能なメイン メモリが小さすぎる場合、Flink はオフヘッド メモリを使用したり、ディスクに書き込むことができるため、JVM メイン メモリは制限ではありません。(ところで: プロジェクト Tungsten 以降の Spark もオフヒープ メモリを使用できますが、ある程度ディスクに流出する可能性がありますが、Flink AFAIK とは異なります)。私の知る限り、Stormはどちらも行わず、JVMメモリに制限されています。

リアクティブ Kafka には詳しくありません。

Kafka Streams の場合、これは完全にフォールト トレラントでステートフルなストリーム処理ライブラリです。マイクロ サービス開発用に設計されています (Flink/Storm/Spark のように専用の処理クラスターは必要ありません) が、アプリケーション インスタンスをどこにでも好きな方法でデプロイできます。より多くのインスタンスを起動するだけで、アプリケーションをスケーリングできます。詳細については、ドキュメントを参照してください: http://docs.confluent.io/current/streams/index.html (Confluent ブログ: http://www.confluent.io/blog/にも Kafka Streams に関する興味深い投稿があります。 )

于 2016-10-24T06:51:51.880 に答える