我理解Kafka分区和Spark RDD分区之间以及最终Spark Task之间存在的自动映射。但是为了正确地调整My Executor的大小（核心数量），因此最终我的节点和集群，我需要理解一些似乎在文档中被掩盖的东西。
在Spark-Streaming中，数据消费与数据处理与任务分配的完全相同，换句话说：
- 对 Kafka分区的相应 Spark任务是否都已读取 并完全处理数据？
这个问题背后的理性是在之前的API中 是，基于接收器，TASK专门用于接收数据， 意味着执行程序的数字任务槽是为数据保留的 摄入，另一个在那里进行处理。这有一个 对核心执行者的大小影响。
举例说明如何使用
启动spark-streaming
- 掌握本地 。在火花流的情况下，每个人都会说出来
一个应该把 local [2] 最小化，因为其中一个
核心，将致力于运行从未有过的长期接收任务
结束，另一个核心将进行数据处理。
因此，如果答案是在这种情况下，任务同时进行阅读 并立即处理，接下来的问题是， 真的很聪明，我的意思是，这听起来像异步。我们想成为 能够在我们处理数据时进行下一次处理时获取 已经在那了。但是，如果只有一个核心或更精确到 既读取数据又处理它们，如何在两者中完成 并行，以及如何使事情变得更快。
我原来的理解是，事情会以某种方式存在 同样在某种意义上说，一个任务将被启动阅读，但是 处理将在另一个任务中完成。那意味着，如果是 处理任务还没有完成，我们仍然可以继续阅读，直到 一定的记忆限制。
有人可以清楚地概述这里到底发生了什么吗？
EDIT1
我们甚至不需要这种内存限制控制。仅仅是在处理过程中能够获取并在那里停止的事实。换句话说，这两个过程应该是异步的，而限制只是领先一步。对我来说，如果不知道这种情况发生了什么，我发现Spark会实现一些破坏性能的东西，这是非常奇怪的。
答案 0 :(得分：1)
对Kafka分区的相应Spark任务是否都读取和 完全处理数据？
这种关系非常接近你描述的内容，如果通过谈论一项任务，我们将指向从kafka读取的图形部分，直到进行随机操作。执行流程如下：
这意味着单个执行程序将读取给定的TopicPartition并在其上处理整个执行图，除非我们需要随机播放。由于Kafka分区映射到RDD内的分区，我们得到了保证。
结构化流式传输更进一步。在结构化流中，TopicPartition和工作者/执行者之间存在粘性。这意味着，如果为给定的工作人员分配了TopicPartition，则可能会在应用程序的整个生命周期内继续处理它。