我们使用的是 Kafka 2.5.1 版本的集群。 最近注意到其中一个topic分区的数据大小是不均匀的。 与其余分区相比，一个特定分区的大小增加了 300%。 这会导致集群中的磁盘利用率不均。
验证了消费者的滞后，看起来和其他分区一样正常 此外，我们使用 DefaultPartitioner 并将“metadata.max.age.ms”配置设置为默认值，即 300000 毫秒（5 分钟）
我们如何使分区数据均匀分布？
【问题讨论】：
标签： apache-kafka
作为运营商，没有什么可以做的；特别是因为消费者依赖于分区分配和消息排序。
Kafka 不保证非空键会均匀分布。您需要修改您的生产者，以便分区方案均匀分布数据。
例如，默认情况下，如果 80% 的记录具有相同的 hash(key)，那么它们都会被发送到同一个分区，导致该分区比其他 20% 的总和大 4 倍。你可以编写自己的分区器来改变这种行为，但是如果你有多种语言的客户端都针对同一个主题进行生产，那么你最终会得到很多重复的工作
【讨论】：
要添加@OneCricketeer 的答案，我建议首先弄清楚您的事件键是什么，哪个键是在您的主题中造成如此巨大的不平衡的键...为此，我会：
检查“大”分区和一个“普通”分区中的数据。您可以使用此命令查看 kafka 数据日志中的事件，例如：
/usr/bin/kafka-dump-log --print-data-log --files /apps/kafka-data/tracking.ap.client.traffic.keyed-1/00000000000004735501.log
[当然，用你自己的kafka日志目录、主题名、分区号和日志文件名替换]
你会看到这样的：
offset: 4736628 position: 676217 CreateTime: 1622043813 isvalid: true keysize: 8 valuesize: 506 magic: 2 compresscodec: NONE producerId: -1 producerEpoch: -1 sequence: -1 isTransactional: false headerKeys: [] key: 123 payload: {"CID":"123",
事件的关键是“key:123”部分。
比较两个分区中的键分布，并尝试找到“大”分区中的罪魁祸首键值 - 您可以编写一个简单的 awk/bash 脚本来通过不同的键值计算日志中的事件数，或者它可能马上就很明显了
既然您知道什么是键以及哪个特定键（或者可能是几个键）是问题所在 - 您可以开始考虑如何解决问题。这可能很容易 - 如果对事件分组没有硬性要求，您可以将键更改为 UUID 或其他分布良好的字段值。或者可能很难 - 如果出于某种原因以这种方式设计并且您必须将相同键的所有事件（例如 CustomerID）保存在同一个分区中 - 如果说您在消费者中做一些依赖于拥有所有在同一个消费者线程中处理相同键的事件（例如，一些内存中的聚合）。在这种情况下，如果重新平均分配主题中的数据很重要（通常是这样），您可能必须重新考虑您的应用程序/消费者逻辑。
【讨论】：