我的拓扑结构如下:kafka(p:6)->reduce(p:6)->db writer(p:12)
(其中p:是并行性)。
taskmanager.numberOfTaskSlots: 30
当我观察这项工作(通过flink UI)约1分钟时,这些是我看到的值:
(其他部分的发送/接收值之间存在较小的差异,但我可以将这些差异归因于测量误差)
问题(S):
1.其余记录在哪里?
2.运行时,此机器上的负载永远不会超过1.5。还有其他限制因素吗?
3.我是否误读了UI中的值?
Java 8
Flink 1.0(最新github)
机器:32核/ 96 Gb RAM
1 这个可以通过汇总过程来解释 2 这个值与写入db的内容对齐。
答案 0 :(得分:6)
Flink不会丢失记录,它们只是在飞行中缓冲,或者在Kafka停留更长时间。从数字来看,您似乎遇到了背压。
你可以看到"减速机"已经发出了很多记录,这些记录还没有被" db writer"收到。在这种情况下,这些记录仍然在运营商之间的通信信道的缓冲区中。这些通道具有有限的缓冲量(取决于配置的缓冲区的数量,通常为几MB)。对于小记录,它们可能会保存多个10k记录。
如果一个运营商中发送的记录数量明显落后于接收运营商收到的记录,则表明接收者(此处为" db writer")无法跟上数据速率。也许是因为DB没有足够快地处理插入(太同步,太细粒度的提交?),也许是" db writer"之间的网络。并且数据库已饱和。
在这种情况下," db writer"将对减速器进行背压,这最终也会使卡夫卡源背压。
如果您没有来自数据库的反压力,要试用数据速率,您可以尝试一个实验,其中" db writer"简单地删除所有记录。