Spark-Streaming Kafka Direct Streaming API 和并行性

Question

我了解 Kafka 分区和 Spark RDD 分区以及最终的 Spark 任务之间存在的自动映射。但是，为了正确调整我的执行程序（以核心数量为单位）以及最终调整我的节点和集群的大小，我需要了解文档中似乎被掩盖的一些内容。

在 Spark-Streaming 中，数据消耗 vs 数据处理 vs 任务分配，换句话说：

1. 对 Kafka 分区 执行相应的 Spark 任务 是否都读取 并完全处理数据？

• 这个问题背后的原因是，在之前的 API 中， 是，基于接收器的，一个 TASK 专门用于接收数据， 意味着您的执行者的一些任务槽被保留用于数据 摄取和另一个在那里进行处理。这有一个 影响您在核心方面如何调整执行者的大小。

• 以关于如何使用
  --master local 启动 spark-streaming 的建议为例。每个人都会说，在火花流的情况下， 应该把 local[2] 放在最低限度，因为其中之一 核心，将致力于运行长接收任务，从来没有 结束，由另一个核心进行数据处理。

• 因此，如果答案是在这种情况下，任务会同时读取 并立即处理，那么接下来的问题是
  真的很聪明，我的意思是，这听起来像是异步的。我们想成为
  能够在我们处理时获取，因此下一次处理数据是 已经在那了。但是，如果只有一个核心或更精确地
  既读取数据又处理它们，如何在
  并行，以及总体上这如何使事情变得更快。

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

有人可以清楚地概述这里到底发生了什么吗？

EDIT1

我们甚至不需要这个内存限制控制。只是能够在处理正在进行并在那里停止的同时获取的事实。换句话说，这两个过程应该是异步的，并且限制只是领先一步。对我来说，如果这没有发生，我会觉得 Spark 会实现一些会破坏性能的东西是非常奇怪的。

Answer 1

对 Kafka 分区执行相应的 Spark 任务，包括读取和 完全处理数据？

这种关系与您描述的非常接近，如果通过谈论一项任务，我们指的是从 kafka 读取直到 shuffle 操作的图形部分。执行流程如下：

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

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

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