22

実際のミニバッチとリアルタイム ストリーミングの違いは何ですか (理論ではありません)? 理論的には、ミニバッチは特定の時間枠でバッチ処理するものであると理解していますが、リアルタイムストリーミングはデータが到着したときに何かを行うのに似ていますが、私の最大の疑問は、イプシロン時間枠 (1 ミリ秒など) でミニバッチを使用しない理由です。あるソリューションが他のソリューションよりも効果的である理由を知りたいですか?

私は最近、ミニバッチ (Apache Spark) が不正検出に使用され、リアルタイム ストリーミング (Apache Flink) が不正防止に使用されている例を見つけました。ミニバッチは不正防止の効果的なソリューションではないというコメントもありました (トランザクションが発生したときに発生しないようにすることが目標であるため)。1 ミリ秒のレイテンシでミニバッチを実行することが効果的でないのはなぜですか? バッチ処理は、ディスクまたはネットワークへのデータが実際にバッファリングされる OS およびカーネル TCP/IP スタックを含むあらゆる場所で使用される手法です。

4

3 に答える 3

15

1 つの回答が受け入れられたことは知っていますが、この質問に完全に回答するには、もう 1 つ回答する必要があると思います。「Flinkのリアルタイムはストリーミングの方が速い/ストリーミングに適している」などの答えは間違っていると思います。これは、何をしたいかによって大きく異なります。

Spark ミニバッチ モデルには、前の回答で書かれているように、ミニバッチごとに新しいジョブを作成する必要があるという欠点があります。

ただし、Spark 構造化ストリーミングでは、デフォルトの処理時間トリガーが 0に設定されています。これは、新しいデータの読み取りが可能な限り高速に行われることを意味します。だということだ：

  1. 1 つのクエリが開始されます
  2. データが到着しましたが、最初のクエリが終了しませんでした
  3. 最初のクエリが終了したので、データはすぐに処理されます。

このような場合、レイテンシは非常に小さくなります。

Flink に対する大きな利点の 1 つは、このミニバッチ モデルにより、Spark にはバッチ処理とストリーミング処理用のAPI が統合されていることです。バッチ ジョブをストリーミング ジョブに簡単に変換し、ストリーミング データをバッチの古いデータと結合できます。Flinkでそれを行うことはできません。また、Flink では、受け取ったデータでインタラクティブなクエリを実行することもできません。

前に述べたように、マイクロバッチとリアルタイム ストリーミングではユース ケースが異なります。

  1. レイテンシが非常に小さい場合は、Flink または Apache Ignite などの計算グリッドが適しています。これらは非常に短い待ち時間での処理に適していますが、非常に複雑な計算には適していません。
  2. レイテンシが中程度以上の場合、Spark はより統合された API を持ち、この統合のおかげで、バッチ ジョブが行われるのと同じ方法でより複雑な計算を行うことができます。

構造化ストリーミングの詳細については、このブログ投稿をご覧ください。

于 2016-09-27T09:25:26.323 に答える
5

これは私がよく考えていることです。なぜなら、技術者と非技術者への答えは常に定式化するのが難しいからです。

私はこの部分に答えようとします：

1 ミリ秒のレイテンシでミニバッチを実行することが効果的でないのはなぜですか?

問題はモデル自体ではなく、Spark の実装方法にあると思います。ミニバッチ ウィンドウを縮小しすぎると、パフォーマンスが低下することが経験的に証明されています。実際、この種の劣化を防ぐために、少なくとも 0.5 秒以上の時間が推奨されていました。大きなボリュームでは、このウィンドウ サイズでも小さすぎました。本番環境でテストする機会はありませんでしたが、強力なリアルタイム要件はありませんでした。

Flink は Spark よりもよく知っているので、その内部についてはよくわかりませんが、バッチの処理に少なくとも数秒かかる場合、バッチ プロセスの設計で導入されたオーバーヘッドは無関係だと思いますが、一定のレイテンシーを導入すると、それを下回ることはできません。これらのオーバーヘッドの性質を理解するには、Spark のドキュメント、コード、および未解決の問題を詳しく調べる必要があると思います。

業界は現在、別のモデルが必要であることを認識しており、そのため、多くの「ストリーミング ファースト」エンジンが現在成長しており、Flink が最有力候補となっています。少なくとも今のところ、この種のテクノロジーの使用例は非常に限られているため、流行語や誇大宣伝だけではないと思います。基本的に、大規模で複雑なデータに対して自動化された意思決定をリアルタイムで行う必要がある場合は、リアルタイムの高速データ エンジンが必要です。それ以外の場合 (ほぼリアルタイムを含む)、リアルタイム ストリーミングは過剰であり、ミニバッチで問題ありません。

于 2016-09-27T06:56:23.413 に答える