Apache KafkaTopic 的配置与组成

Posted 2020-11-15 ZacksTang

Topic 的配置与组成

 

之前我们仅主要介绍了Kafka Producer与Kafka Consumer 的相关配置，而未详细介绍过有关topic的配置。Topic的配置在Kafka 使用中也至关重要，因为它的参数足以影响集群性能以及topic 的行为。

在一个topic被创建后，会有它默认的参数，不过有些topic的参数可能仍需要根据实际情况进行一些调整，例如：

• Replication Factor
• Partition数目
•  Message Size
• Compression level
• Log Cleanup Policy
• Min Insync Replicas
•  …

其中Replication Factor与Partition数目之前有被提及，所以我们主要关注之前未提及过的参数配置。

 

1. 如何配置一个 Kafka Topic

这里我们会简单地介绍如何使用kafka cli 为一个topic 修改配置。首先我们创建一个topic：

> kafka-topics.sh --zookeeper 172.31.24.148:2181 --create --topic configured-topic --partitions 3 --replication-factor 1

 

我们可以使用 kafka-configs cli 配置topic 的参数，例如：

kafka-configs.sh --zookeeper 172.31.24.148 --entity-type topics --entity-name configured-topic --add-config min.insync.replicas=2 --alter

 

然后describe 这个 topic：

kafka-topics.sh --zookeeper 172.31.24.148:2181 --describe --topic configured-topic

Topic:configured-topic  PartitionCount:3    ReplicationFactor:1    Configs:min.insync.replicas=2

    Topic: configured-topic Partition: 0    Leader: 0    Replicas: 0    Isr: 0

    Topic: configured-topic Partition: 1    Leader: 0    Replicas: 0    Isr: 0

    Topic: configured-topic Partition: 2    Leader: 0    Replicas: 0    Isr: 0

 

可以看到在Configs一栏，多出了一个配置。

也可以使用--delete-config 选项，删除一个配置：

kafka-configs.sh --zookeeper 172.31.24.148 --entity-type topics --entity-name configured-topic --delete-config min.insync.replicas --alter

Completed Updating config for entity: topic \'configured-topic\'.

 

2. Partitions 与Segments

我们知道一个topic是由一个或多个partitions组成。而对于一个partition来说，它是由一个或多个segments （本质是文件）组成。如下图所示：

 

每个segment都会有一个starting offset以及一个ending offset。下一个segment的starting offset为前一个segment 的ending offset + 1。最后一个segment 称为active segment，意味着当前segment仍为“被写入”状态。也就是说，若是有新的record写入，则是写入到这个active segment中。在active segment中的offset达到预期值后，则此segment会被关闭，并开启一个新的segment。

所以在任何时刻，均只有一个segment为ACTIVE 状态（也就是数据被写入的segment）。

有关segment 的参数有两个：

• log.segment.bytes：单个segment可容纳的最大数据量，默认为1GB
• log.segment.ms：Kafka在commit一个未写满的segment前，所等待的时间（默认为7天）

 

3. Segment 与 Indexes

每个Segment 均有与之对应的两个index文件：

• Offset 与 Position 之间映射的索引：用于让Kafka通过offset在segment中找到一条message
• Timestamp 与 Offset之间的索引：用于让Kafka通过一个timestamp找到一条message

也是基于这些index文件，使得Kafka可以在一个常数时间内找到数据。在找到此条数据后，会继续顺序读取之后的数据。这也就是为什么Kafka仅适用于顺序读写，而不适用于随机读写。

 

我们进一步可以再查看真正对应到这些概念的文件。之前我们定义了kafka 的log.dirs 为：

/home/hadoop/kafka_2.12-2.3.0/data/kafka-logs

 

进入到此目录，可以看到所有列出来的topics，以及它们对应的partitions：

 

  

进入到kafka_demo-0 这个partition目录中可以看到：

 

 

其中.log 为存储message的文件，.index 为Offset与Position之间的索引文件，.timeindex为Timestamp与 Offset之间的索引文件。

 

4. Segment 配置

在进一步了解了segment后，再回头看看segment的两个配置log.segment.bytes与log.segment.ms。

若是将log.segment.bytes（大小，默认为1GB）调小，则意味着：

• 每个partition对应更多的segments
• Log Compaction发生的会更频繁

·       Kafka 会维护更多的open files（报错：Too many open files）

在决定此参数的大小时，需要考虑到业务吞吐的大小。如果业务的数据量是每天一个GB的数据，则默认的配置即可适用此场景；而如果业务的数据量是一周一个GB，则可以适当调小此值。

 

而若是将 log.segment.ms（默认为一周）调小，则意味着：

• 更频繁的log compaction（触发的更频繁）
• 生成更多的文件

在决定此参数的大小时，需要考虑到：业务中需要log compaction 发生的频率。Log Compaction会在之后介绍。