Spark-Streaming Kafka Direct Streaming API＆Parallelism

Question

我瞭解Kafka分區和Spark RDD分區之間存在的自動映射關係，並最終實現Spark Task。然而，爲了正確確定我的執行程序的大小（以Core數量計算），並最終實現節點和集羣的大小，我需要理解文檔中似乎被掩蓋的內容。

火花流如何不正是工作數據消費VS數據處理VS任務分配，換句話說：

1. 是否相應星火任務到卡夫卡分區兩讀取 並完全處理數據？

• 後面這個問題的理性是以前的API中，這 是，基於接收器，任務是專門用於接收數據， 這意味着你的遺囑執行人的多項任務插槽的保留數據 攝入和其他人在那裏處理。這對你在覈心方面的執行者規模有一個 的影響。

• 舉個例子就如何啓動火花流與
  --master當地的建議。每個人都會告訴火花流的情況下， 應該把本地[2]最小，因爲 核心之一，將致力於運行從未 兩端的長接收任務，以及其他核心將做數據處理。

• 所以，如果答案是，在這種情況下，任務確實都讀 和處理一次，然後接下來的問題是，
  真聰明，我的意思是，這聽起來像異步的。我們想在
  可以拿取的同時我們處理等下一次處理的數據是 已經在那裏。但是，如果只有一個核心或更精確地讀取數據並對其進行處理，那麼兩者如何能夠並行地完成，以及如何使這些數據在一般情況下更快。

• 我原來的理解是，事情會仍然以某種方式 同樣在這個意義上，一個任務是推出閱讀，但該
  處理將在另一項任務來完成。那就意味着，如果
  處理任務尚未完成，我們仍然可以繼續讀取，直到 有一定的內存限制。

有人可以清楚地概述這裏究竟發生了什麼嗎？

EDIT1

我們甚至不必有這樣的內存限制控制。僅僅是在處理過程中能夠獲取並在那裏停止的事實。換句話說，這兩個過程應該是異步的，並且限制僅僅是領先一步。對我來說，如果這種情況沒有發生，我覺得Spark會執行一些破壞性能的東西，這很奇怪。

Answer 1

相應的Spark任務到卡夫卡分區都讀和 一起處理數據嗎？

該關係與您所描述的非常接近，如果通過討論任務我們指的是從卡夫卡讀取直到洗牌操作的圖表部分。執行流程如下：

1. 驅動讀取來自所有卡夫卡主題偏移和分區
2. 驅動程序分配的每個執行器的話題和分區爲讀取和處理的。
3. 除非有洗牌邊界操作，否則Spark可能會優化同一個執行程序上分區的整個執行。

這意味着除非我們需要洗牌，否則單個執行程序將讀取給定的TopicPartition並處理其上的整個執行圖。由於卡夫卡分區映射到RDD內部的分區，因此我們獲得了該保證。

結構化流式傳輸甚至可以進一步實現這一點。在結構化流媒體中，TopicPartition與工作者/執行者之間存在粘性。這意味着，如果給定的工作人員被分配了TopicPartition，則可能會繼續處理該應用程序的整個生命週期。