【发布时间】:2021-03-16 18:25:11
【问题描述】:
过去几周,我们一直致力于将 Kafka Connect 添加到我们的数据平台,并认为这将是一种将数据从 Kafka 提取到 S3 数据湖中的有用方法。我们已经使用 FieldPartitioner 和 TimeBasePartitioner 并看到了一些相当不错的结果。
我们还需要按用户 ID 进行分区 - 但尝试在用户 ID 字段上使用 FieldPartitioner 后,连接器速度非常慢 - 尤其是与按日期分区等相比。我知道按 ID 分区会产生很多输出分区的数量,因此不会那么快 - 这很好,但它需要能够跟上生产者的步伐。
到目前为止,我们已经尝试增加内存和堆 - 但我们通常不会看到任何内存问题,除非我们将 flush.size 提高到一个很大的数字。我们还尝试了小刷新大小、非常小和大的 rotate.schedule.interval.ms 配置。我们还研究了网络,但这似乎很好 - 使用其他分区器网络保持正常。
在可能浪费大量时间之前,是否有人尝试或成功地使用 S3 Sink 连接器按 id 字段进行分区,尤其是在较大的主题上?或者有没有人在配置或设置方面有任何建议,可能是一个不错的地方?
【问题讨论】:
-
你有多少任务和工人?我假设问题是每个任务都在处理高基数的 id(与只有几个分区或日期分区窗口内顺序增加的日期相比),并且没有很快达到任何给定 ID 分区的刷新大小
-
嘿@OneCricketeer,感谢您的评论。在一个主题上,我们有三个分区,我将 max.tasks 设置为 3。我们还有 3 个处于分布式模式的连接工作人员。我怀疑刷新大小相同,并尝试将刷新大小设置为 1,但仍然看到吞吐量问题。
-
那么,哪一部分实际上很慢?上传文件还是消费?换句话说,您是否在监控消费者滞后?从我从具有非常大的生产者数量和大刷新大小的连接器中看到的是,连接批处理数据一段时间,然后提交数千个偏移量,但所有数据在 S3 中似乎都很好;有时到达那里很慢
-
我所说的慢是指消费者似乎永远无法跟上生产者的步伐。消费者很难通过当前主题中的数据,并且随着时间的推移滞后缓慢增长。与同一主题相比,使用 TimeBasedPartitioner 我们观察到延迟在几个小时内稳步减少。你是什么意思它有时到达那里很慢?欣赏 cmets!
-
数据上传到 S3 很慢。但消费者确实在工作。只有在实际上传文件后才会提交偏移量(因此延迟只会减少)。这是仅向 S3 交付一次的副产品
标签: apache-kafka apache-kafka-connect s3-kafka-connector