我开始想知道与减少 flink 作业中特定运算符的并行性的性能相关的用例是什么。我了解所有技术性与子任务和插槽等数量的关系。
让我们想象一个有三个任务的工作，即源 -> Agg -> 接收器
如果我将 flink 配置为使用例如 32 个插槽，那么如果我为所有 3 个任务分配相同的并行度，即性能会有什么差异，即 32 与分配 Source 降低 10 的并行度？ 我的理解是从源读取的记录更少(即更少的使用者线程(，但这会导致性能下降？降低源的并行度并不意味着我可以在 CPU 要求苛刻的运算符(如分配 (32-10( + 32 = 54 并行度(上提高并行度(我知道 flink 不允许这样做如果有 32 个插槽可用(
如果源产生太多记录，背压会启动并减慢源的速度吗？
当管道仅由前向连接组成时 - 换句话说，如果没有keyBy 或重新平衡操作，并且并行性保持不变 - 那么运算符将被链接在一起，避免了网络通信和 ser/de 的成本。这具有相当大的性能优势。
通常由以下部分组成的管道：
source -> agg -> sink
真的会做
source -> keyBy + agg -> sink
这意味着源和聚合运营商之间已经存在网络和 ser/de。但是，如果没有keyBy，那么更改源和AGG之间的并行性将带来网络洗牌/重新平衡的成本。
如果没有keyBy，你只会拥有
source + agg + sink
所有这些都在一个线程中运行。
但是有了keyBy，只要聚合器和接收器之间的并行性保持不变，这个管道就会真正执行为。
source -> keyBy + agg + sink
因为聚合器和接收器将在同一任务中链接在一起(因此在同一线程中运行(。
只要源至少有 32 个分区或分片，源的并行度为 32 应该可以提高源的吞吐量。
但这一切究竟将如何表现取决于一堆事情。如果键不平衡，或者接收器很慢，或者聚合器具有非常突发的行为，则这些事情都会影响吞吐量和延迟。
如果源生成记录的速度快于聚合 + 接收器处理它们的速度，则 agg + 接收器任务将对源背压，并且它的读取速度只会与管道其余部分可以处理的速度一样快。虽然这没关系，但最好避免恒定的背压，因为背压会导致检查点超时。因此，在这种情况下，您可能希望降低源端的并行度，或增加 agg + sink 任务的并行度。