Topic, Partition, Segment

Partition은 Broker들에 분산되며, 각 Partition은 Segment File들로 구성된다고 했다. 이번에는 이 segment file이 어떻게 구성되어 있는지 확인해보자.

image

Kafka Log Segment File Directory

Kafka Log Segment File은 Data File 이라고 부르기도 한다. Segment File이 생성되는 위치는 각 Broker의server.properties 파일 안에서 log.dirs 파라미터로 정의한다. (comma로 구분하여 여러 디렉토리 지정 가능)

log.dirs=/data/kafka/kafka-log-a,/data/kafka/kafka-log-b,/data/kafka/kafka-log-c

각 Topic과 그 Partition은 log.dirs 아래에 하위 디렉토리로 구성한다. 예를 들어 test_topic의 Partition 0은 /data/kafka/kafka-log-a/test_topic-0 디렉토리로 생성된다. partition 디렉토리 안에는 많은 파일들이 생성되는데, 이름이 같은 index, timeindex, log 파일과 leader 가 바뀔 때 offset 정보를 저장하는 leader-epoch-checkpoint 파일이 만들어진다.

$ ls /data/kafka/kafka-log-a/test_topic-0
00000000000000123453.index
00000000000000123453.timeindex
00000000000000123453.log
00000000000007735204.index
00000000000007735204.timeindex
00000000000007735204.log
leader-epoch-checkpoint

00000000000000123453.* 파일은 00000000000000123453 offset부터 00000000000007735203 offset까지의 메시지를 저장하고 관리한다.

  • .log: Log Segment File ‒ 메시지와 metadata를 저장
  • .index: Index File ‒ 각 메시지의 Offset을 Log Segment 파일의 Byte 위치에 매핑
  • .timeindex: Time-based Index File ‒ 각 메시지의 timestamp를 기반으로 메시지를 검색하는데 사용
  • leader-epoch-checkpoint: Leader Epoch Checkpoint File ‒ Leader Epoch과 관련 Offset 정보를 저장
  • .snapshot: 메세지의 순서를 보장하기 위해 사용하는 Idempotent Producer를 사용하면 생김
  • .txnindex: Transactional Producer를 사용하면 생김

Log segment file의 특징

Log segment file의 파일명은 해당 파일에 첫번째로 저장되는 메세지의 offset이 된다. Active segment 는 현재 data가 저장되고 있는 파일이다. 따라서 Log segement file만 봐도 어떤 데이터가 어느 file에 저장되어 있는지를 알 수 있다.

image

Log segment file을 rolling 하는 파라미터는 여러개가 있다. 아래의 파라미터 중 하나라도 해당되면 새로운 Segment File로 Rolling이 일어난다.

  • log.segment.bytes (default: 1 GB)
  • log.roll.ms (default: 168 시간)
  • log.index.size.max.bytes (default: 10 MB)

__consumer_offset (Offset Topic)의 Segment File Rolling 파라미터는 별도이다.

  • offsets.topic.segment.bytes (default: 100 MB)

Checkpoint file

각 broker에는 2개의 checkpoint file 이 존재하는데, 이 파일들은 log.dirs 디렉토리에 위치한다.

  • replication-offset-checkpoint
    • 마지막으로 Commit된 메시지의 ID인 High Water Mark 를 저장
    • 시작 시 Follower가 이를 사용하여 Commit 되지 않은 메시지를 Truncate
  • recovery-point-offset-checkpoint
    • 데이터가 디스크로 Flush된 지점
    • 복구할 때 Broker는 이 시점 이후의 메시지가 손실되었는지 여부를 확인