我的问题与此完全相似，只是我的应用程序中的反压力是“ok”。
我认为问题是我的本地机器没有足够的配置，所以我创建了一个72核的windows机器，在那里我从kafka读取数据，用flink处理，然后用kafka写回输出。我查过了，写进Kafka的Flume不会引起任何问题。
我所寻找的是那些可能通过增加并行性而导致任务槽之间吞吐量分裂的区域？
flink版本：1.7.2
scala版本：2.12.8
Kafka版本：2.11-2.2.1
java版本：1.8.231
应用程序工作：数据来自由flink反序列化的kafka（1个分区）（这里的吞吐量是5k/秒）。然后反序列化的消息通过基本模式验证（这里的吞吐量是2k/秒）。即使在将并行度增加到2之后，级别1（反序列化阶段）的吞吐量仍然保持不变，并且不会按照预期增加两倍。
我明白，没有代码，很难进行调试，所以我想问一下您对这个问题的建议，这样我就可以回到我的代码中去尝试。
1条答案
按热度按时间8tntrjer1#
我们使用1个kafka分区作为输入主题。
如果要并行处理数据，实际上需要并行读取数据。
并行读取数据有一定的要求。最重要的一点是源能够将数据实际分割成更小的工作块。例如，如果从文件系统读取，则会有多个文件，或者系统会将这些文件细分为多个分区。对于Kafka来说，这必然意味着你必须有更多的分区。理想情况下，分区的数量至少与最大使用者并行性的数量相同。
5k/s似乎是一个分区所能达到的最大吞吐量。您还可以根据希望达到的最大吞吐量来计算分区数。如果需要达到50k/s，则至少需要10个分区。在重新处理或故障恢复的情况下，您应该使用更多的方法来追赶。
另一种分配工作的方法是添加一个手动洗牌步骤。这意味着，如果保留单个输入分区，仍然只能达到5k/s，但在这之后，工作实际上是并行地重新分配和处理的，这样以后就不会看到吞吐量的巨大下降。洗牌操作之后，工作在并行的下游任务之间稍微均匀地分布。