Flink读到Kafka，在某些情况下，消费速度急剧下降。
Flink读到Kafka，在某些情况下，消费速度急剧下降。
提问于 2021-06-04 07:41:32
我们有一个Flink作业(Flink版本: 1.9)，它通过键连接两个kafka源，对于每个键，启动一个5分钟的定时器，消息被缓存在Flink状态，当定时器结束时，将具有相同键的消息合并到一个胖消息中(通常每个键有1~5条消息)并将其发送给kafka。
两个kafka消息来源：
- source1 (160个分区，每分钟20~3000万条消息)，
- source2 (30个分区，每分钟1~300万条消息)。
平面地图只是反序列化了卡夫卡的信息。
KeyedProcess是计时器和Flink状态发挥作用的地方。
我尝试了一些改进性能的方法，例如模块化键来减少计时器的数量，或者增加硬件(目前是2000 c 4000 to )，或者调整操作符的并行性。
目前的问题是，当source1超过每分钟2500万条消息时，消耗速度急剧下降，而且永远不会恢复。如果少于2500万条消息/分钟，它就能正常工作。
卡夫卡集群本身似乎没有问题，因为有另一个系统读取它，而且该系统没有任何消费速度问题。
谁能帮我弄点光吗？如何解决原因？或者任何我能尝试的东西？增加更多的硬件(我认为2000 c&4000 of是大量的资源)是个好主意吗？非常感谢。
回答 1
Stack Overflow用户
回答已采纳
发布于 2021-06-04 10:34:04
首先，您可以附加一个分析器来查看瓶颈所在。(也许是磁盘？)
似乎有道理的是，在某种程度上，RocksDB不再表现良好。可能需要进行一些调整。您应该能够通过启用RocksDB本机度量获得一些洞察力，并查看问题发生时各种RocksDB指标是如何变化的。
以下是一些更有用的指标：
estimate-live-data-size
estimate-num-keys
num-running-compactions
num-live-versions
estimate-pending-compaction-bytes
num-running-flushes
size-all-mem-tables
block-cache-usage取决于工作负载的运行位置和方式，您可能遇到了某种速率限制或节流。有关一个有趣的示例，请参见磁盘对Flink中RocksDB状态后端的影响:一个案例研究。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/67833312
复制相关文章
相似问题
腾讯云开发者
