Spark-Streaming Kafka直接流API及并行性

Question

我理解了Kafka分区和Spark RDD分区之间的自动映射，并最终理解了Spark任务。然而，为了正确地调整我的执行器（核心数量）的大小，并最终确定节点和集群的大小，我需要理解文档中似乎掩盖了的一些内容。

null

例如，关于如何使用
--master local启动spark-streaming的建议。每个人都会说，在spark streaming的情况下，应该把local[2]最小化，因为其中一个核心将致力于运行永不结束的长时间接收任务，而另一个核心将进行数据处理。

所以如果答案是，在这种情况下，任务同时进行读取和处理，那么接下来的问题是，
真的很聪明，我的意思是，这听起来像是异步的。我们希望
能够在处理时获取数据，因此在下一次处理时，数据已经在那里了。但是，如果只有一个内核，或者更精确地说，
两个内核都读取数据并处理它们，如何在
中并行地完成这两个内核，以及如何在总体上使事情变得更快。

我最初的理解是，在某种意义上，事情将保持不变，即一个任务将被启动以读取，但
处理将在另一个任务中完成。这意味着，如果
处理任务还没有完成，我们仍然可以继续读取，直到某个内存限制。

编辑1

我们甚至不必有这种内存限制控制。仅仅是能够在处理进行和停止的时候获取的事实。换句话说，这两个进程应该是异步的，限制只是领先一步。对我来说，如果不知何故没有发生这种情况，我发现Spark会实现破坏性能的东西是非常奇怪的。

Answer 1

Kafka分区对应的Spark任务是否同时读取和处理数据？

这种关系非常接近于你所描述的，如果我们谈论一个任务，我们指的是从Kafka到洗牌操作的部分。执行流程如下：

1. 驱动程序从所有kafka主题和分区读取偏移量
2. 驱动程序为每个执行器分配一个要读取和处理的主题和分区。
3. 除非有洗牌边界操作，否则Spark很可能会在同一个执行器上优化分区的整个执行。

这意味着单个执行器将读取给定的TopicPartition并在其上处理整个执行图，除非我们需要洗牌。由于Kafka分区映射到RDD中的分区，因此我们得到了这种保证。

结构化流甚至更进一步。在结构化流中，TopicPartition和worker/executor之间存在粘性。这意味着，如果为给定的工作程序分配了TopicPartition，它可能会在应用程序的整个生存期内继续处理它。