如果我的Flink应用程序需要一个高并行接收器，那么最佳实践是什么？

Question

假设我的Flink应用程序有3个组件: Source、Map和Sink。由于某些原因(例如调用API有很高的延迟)，接收器需要非常高的并行性(例如20)。还假设Source和Map占用的CPU/IO非常少。我们知道，最小可用插槽至少应该与应用程序的最大并行性一样大，在本例中为20。部署此应用程序的方法有两种：

1. 如果我已经有一个Flink集群，部署这个应用程序将占用20个插槽。但是，我的Source不需要太多资源，所以这20个插槽大部分时间都是空闲的(因为接收器调用API的延迟很大)。在这种情况下，我在浪费资源。
2. 我可以为这个应用程序设置一个每个作业集群，并将每个任务管理器的插槽数设置得非常高，以减少每个插槽的资源。在这种情况下，为了获得足够的CPU容量，我还需要将Map的并行性设置为一个高值。但是，由于Map是CPU受限的，高并行性会导致性能下降(线程上下文切换)。

所以我的问题是，这个案子的最佳做法是什么？

以前我用过Apache Storm。对于Storm应用程序，我需要指定工人数量(槽)和每个操作符的并行性。但是，可用的插槽至少不需要作为应用程序的最大并行度，因此对于这个应用程序，我可以设置两个工作人员，两个源和映射并行，和20个并行处理Sink，它最终只需要两个槽，每个插槽有一个源，一个地图，和10个Sink螺栓。我认为这样不仅满足了拥有高并行接收器的需要，而且还很好地利用了资源(只有2个Map)。为什么人们想要这样设计Flink并行？还是我的理解错了？

Answer 1

有几种选择，以及它们背后的理由：

1. 在整个作业中使用20的并行性:源、映射、接收器。通过这样做，您可以利用算子链，避免在映射和接收器之间进行序列化/反序列化和网络通信(并行性将从2变为20)。您必须对其进行基准测试才能确定，但通常避免ser/de和网络堆栈的节省将是很大的。
2. 在整个作业(包括接收器)中使用2的并行性，并使用异步客户端与外部API对话，以便每个接收器实例能够处理多个并发请求。您可能可以使用Flink的异步i/o来实现这一点，但是如果您这样做了，您将不得不修改一个虚拟接收器(因为Flink坚持每个作业都有一个接收器)。

除了上面的#2之外，这些方案中的一个问题是，在等待缓慢的外部API响应时，您将占用大量资源，这些资源大部分时间都在闲置。另外，在Flink用户函数中执行阻塞/同步i/o也有问题，因为Flink的操作符是单线程的，您可以通过这样做阻止检查点等等。