実際のミニバッチストリーミングとリアルタイムストリーミングの違いは何ですか（理論ではありません）？

Question

実際のミニバッチストリーミングとリアルタイムストリーミングの違いは何ですか（理論ではありません）？理論的には、ミニバッチは特定の時間枠でバッチ処理するものであるのに対し、リアルタイムストリーミングはデータが到着したときに何かを行うようなものであると理解していますが、私の最大の質問は、イプシロン時間枠（たとえば1ミリ秒）のミニバッチを使用しない理由です。 1つが他よりも効果的な解決策になる理由を理解したいですか？

最近、不正検出にミニバッチ（Apache Spark）を使用し、不正防止にリアルタイムストリーミング（Apache Flink）を使用する例を見つけました。ミニバッチは不正防止の効果的な解決策ではないと誰かがコメントしました（目的はトランザクションが発生したときに発生しないようにすることであるため）今、これがミニバッチ（スパーク）ではそれほど効果的ではないのはなぜですか？ 1ミリ秒の遅延でミニバッチを実行するのが効果的でないのはなぜですか？バッチ処理は、ディスクまたはネットワークへのデータが実際にバッファリングされるOSやカーネルTCP/IPスタックを含むあらゆる場所で使用される手法です。ここで、1つが他よりも効果的であると言う説得力のある要因は何ですか？

Fabian Hueske · Accepted Answer

免責事項：私はApacheFlinkのコミッターおよびPMCメンバーです。私はSpark Streamingの全体的な設計に精通していますが、その内部については詳しく知りません。

Sparkストリーミングによって実装されるミニバッチストリーム処理モデルは、次のように機能します。

ストリームのレコードは、バッファー（ミニバッチ）に収集されます。
収集されたレコードは、定期的にSparkジョブを使用して処理されます。これは、ミニバッチごとに、完全な分散バッチ処理ジョブがスケジュールされ、実行されることを意味します。
ジョブの実行中に、次のバッチのレコードが収集されます。

では、なぜ1msごとにミニバッチを実行するのが効果的でないのでしょうか。これは、ミリ秒ごとに分散バッチジョブをスケジュールすることを意味するからです。 Sparkはジョブのスケジューリングが非常に高速ですが、これは少し多すぎます。また、可能なスループットが大幅に低下します。 OSまたはTCPで使用されるバッチ処理手法も、バッチが小さくなりすぎるとうまく機能しません。

T. Gawęda · Answer

一つの答えが受け入れられたことは知っていますが、この質問に完全に答えるにはもう一つ言わなければならないと思います。「Flinkのリアルタイムはストリーミングの方が速い/良い」という答えは間違っていると思います。何をしたいかに大きく依存するからです。

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

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

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

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

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

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

レイテンシーが非常に小さい場合は、FlinkまたはApacheIgniteなどのいくつかの計算グリッドが適しています。これらは非常に低いレイテンシでの処理に適していますが、非常に複雑な計算には適していません。
中規模以上のレイテンシーの場合、Sparkはより統合されたAPIを備え、バッチジョブが実行されるのと同じ方法でより複雑な計算を実行できるようになります。

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

Chobeat · Answer

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

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

1ミリ秒の遅延でミニバッチを実行することが効果的でないのはなぜですか？

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

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

業界は現在、別のモデルが必要であることを認識しており、そのため、Flinkをフロントランナーとして、多くの「ストリーミングファースト」エンジンが現在成長しています。この種のテクノロジーのユースケースは、少なくとも今のところ非常に限られているため、流行語や誇大広告だけではないと思います。基本的に、大きくて複雑なデータについてリアルタイムで自動決定を行う必要がある場合は、リアルタイムの高速データエンジンが必要です。ほぼリアルタイムを含むその他の場合、リアルタイムストリーミングはやり過ぎであり、ミニバッチは問題ありません。