スパークストリーミングKafkaダイレクトストリーミングAPIと並列処理

Question

私は、KafkaパーティションとSpark RDDパーティションとの間に存在し、最終的にSpark Taskの間に存在する自動マッピングを理解しました。しかし、（コアの数で）My Executorのサイズを正しく設定するためには、最終的に私のノードとクラスタのサイズを決めるために、私は文書の中ではっきりと見えるものを理解する必要があります。

1. はカフカパーティション両方に対応スパークタスクを行います正確言い換えれば、タスク割り当て VSデータ処理対データ消費機能しない方法火花ストリーミングにおいて

   を読み取り、データをすべて処理しますか？

• この質問の背後にある合理的には、以前のAPIで、 であることを、ベースの受信機は、TASKがあなたのエグゼキュータの数タスクスロットはなかった意味、 のデータを受信するために捧げられたということですデータ用に予約されており、処理のためにそこに残りました。これは が、コアの期間で実行プログラムのサイズをどのように決定するかに影響しました。

• 例えばローカル --master
  で火花ストリーミングを起動する方法についてのアドバイスをください。 コアの一つは、その決して 両端長い受信タスク、および他のコアの実行専用されますので、誰もが、 1は、ローカルを置く必要があり、スパーク・ストリーミングの場合には、[2]最小のものを言うだろうデータ処理を行います。答えは、この場合には、タスクは一度読ん と処理の両方を行うことで、次の、その後、質問、
  本当に賢いということであれば

• だから、私は意味し、これは、非同期のように聞こえます。私たちは次の処理でデータを処理する間に取り込むことができる
  になりたがっています。データは既にそこに です。しかし、コアが1つだけであれば、もっと正確に
  にデータを読み込んで処理すると、どのようにして両方とも
  パラレルで実行できます。私の元には理解

• は持っているだろう事は何とかタスクは打ち上げが読みけど
  処理が別のタスクで実行されることになり、という意味で 同じまま、ということでした。つまり、
  処理タスクがまだ実行されていない場合、一定のメモリ制限である まで読み取りを続けることができます。

正確にここで何が起こっているのか明瞭に説明できますか？

EDIT1

私たちも、このメモリ制限制御を持っている必要はありません。処理が行われている間にフェッチすることができ、そこですぐに停止するという単純な事実。言い換えれば、2つのプロセスは非同期でなければならず、限界は単に一歩先に進むことです。私にはどういうわけかこれが起こっていなければ、Sparkがパフォーマンスを損なうようなものを実装することは非常に奇妙です。

Answer 1

Kafkaパーティションに対応するSparkタスクは、読み取りと の両方でデータを処理しますか？

kafkaからシャッフル操作までグラフの部分を参照しているタスクについて話すと、その関係は非常に近いです。次のように実行の流れは以下のとおりです。

1. ドライバーは
2. ドライバーが読み取りを可能とに処理するために、各エグゼキュータトピックやパーティションを割り当て、すべてのカフカのトピックからのオフセットとパーティションを読み込みます。
3. シャッフル境界操作がない限り、Sparkは同じエグゼキュータ上のパーティションの実行全体を最適化する可能性があります。

これは、我々がシャッフルする必要がある場合を除き、単一のエグゼキュータは、与えられたTopicPartitionを読んで、その上に全体の実行グラフを処理することを意味します。 KafkaパーティションはRDD内のパーティションにマップされているので、保証が得られます。

ストラクチャードストリーミングはこれをさらに引き継ぎます。ストラクチャードストリーミングでは、TopicPartitionとワーカー/エグゼキュータの間に粘着性があります。つまり、特定のワーカーにTopicPartitionが割り当てられている場合は、アプリケーションの存続期間全体にわたって処理を続ける可能性があります。