Apache flink 在源代码开始时，在flink中对整个数据流进行分区，并将分区保持到sink

我正在使用队列（ApachePulsar）中的跟踪日志。我使用5 keyedPrcoessFunction并最终将有效负载接收到Postgres Db。我需要为每个keyedProcessFunction按customerId订购。现在我通过

Datasource.keyBy(fooKeyFunction).process(processA).keyBy(fooKeyFunction).process(processB).keyBy(fooKeyFunction).process(processC).keyBy(fooKeyFunction).process(processE).keyBy(fooKeyFunction).sink(fooSink).

processFunctionC非常耗时，最坏情况下需要30秒才能完成。这会导致背压。我尝试为processFunctionC分配更多的插槽，但我的吞吐量从未保持不变。它通常保持每秒<4条消息

每个processFunction的当前插槽为

processFunctionA: 3
processFunctionB: 30
processFunctionc: 80
processFunctionD: 10
processFunctionC: 10

在Flink UI中，它显示从进程B开始的背压，这意味着C非常慢。 是否有一种方法可以在源代码本身使用应用分区逻辑，并将每个任务的相同插槽分配给每个processFunction。例如：

dataSoruce.magicKeyBy(fooKeyFunction).setParallelism(80).process(processA).process(processB).process(processC).process(processE).sink(fooSink).

这将导致仅在少数任务中出现背压，而不会使由多个KeyBy导致的背压发生偏移

---

我能想到的另一种方法是将我的所有processFunction和sink组合成单个processFunction，并在sink本身中应用所有这些逻辑。

我认为不存在类似的情况。最接近的是

datastreamits.reinterpreaskeyedstream

，它重新创建

KeyedStream

，而不在操作符之间实际发送任何数据，因为它使用的分区器只在本地转发数据。这或多或少是您想要的，但是它仍然添加了分区操作符，并且在引擎盖下重新创建了

KeyedStream

，但是它应该更简单、更快，并且可能会解决您面临的问题

---

如果这不能解决问题，那么我认为最好的解决方案是对操作员进行分组，以便按照您的建议将背压降至最低，即将所有操作员合并到一个更大的操作员中，这将使背压降至最低。

如果您只需将整个管道在环境中的并行度设置为80，会发生什么？