토픽 정리 정책 (cleanup.policy)
1.토픽 삭제 정책 (delete policy)
토픽의 데이터를 삭제할 때는 세그먼트 단위로 삭제를 진행한다.
세그먼트는 파티션마다 별개로 생성되며 세그먼트의 파일 이름은 오프셋 중 가장 작은 값이 된다.
삭제 정책이 실행되는 시점은 시간 또는 용량이 기준이 됨.
retention.ms 는 토픽의 데이터를 유지하는 기간을 밀리초 단위로 설정 가능하다.
카프카는 일정 주기마다 세그먼트 파일의 마지막 수정 시간과 retention.ms를 비교하는데, 세그먼트 파일의 마지막 수정 시간이 retention.ms를 넘어가면 세그먼트는 삭제된다.
segment.bytes 의 크기보다 커질 경우 기존에 적재하던 세그먼트 파일을 닫고 새로운 세그먼트를 열어서 데이터를 저장한다.
데이터를 저장하기 위해 사용 중인 세그먼트를 액티브 세그먼트 라고 함.
2.토픽 압축 정책 (compact policy)
여기서 압축이란 메시지 키별로 메시지 키의 레코드 중 오래된 데이터를 삭제하는 정책을 뜻함.
압축 정책은 액티브 세그먼트를 제외한 나머지 세그먼트들에 한해서만 데이터를 처리한다.
Log Compaction can be a huge improvement in performance when dealing with KTables because eventually records get discarded.
This means less reads to get to the final state ( less time to recover )
Log Compaction has to be enabled by you on the topics that get created ( source or sink topics )
Log Cleanup Policy : Compact
Log compaction ensures that your log contains at least the last know value for a specific key within a partition.
Very useful if we just require a SNAPSHOT instead of full history.
The idea is that we only keep the latest "update" for a key in our log.
Log Compaction Guarantees
Any consumer that is reading from the head of a log will still see all the message sent to the topic.
Ordering of messages it kept, log compaction only removes some messages but does not re-order them.
The offset of a message is immutable.
So if the message is deleted, the offset is just missing (스킵된다)
Deleted records can still be seen by consumers for a period of delete.retention.ms(default 24h)
Log Compaction Myth Busting
It doesn't prevent you from pushing duplicate data to Kafka.
- De-duplication is done after a segment is committed. (액티브 세그먼트는 제외하고 압축을 진행하기 때문)
- Your consumers will still read from head as soon as the data arrives,
It doesn't prevent you from reading duplicate data from Kafka
- Same points as above.
출처
최원영, 아파치 카프카 애플리케이션 프로그래밍 with 자바, 비제이퍼블릭, 2021
