토스증권 Iceberg 적용기 #1: CDC 환경은 왜 제대로 동작하지 않을까?

토스증권은 잦은 Update/Delete가 발생하는 CDC 파이프라인에서 Iceberg 데이터가 중복되는 정합성 문제를 겪었습니다. Iceberg의 COW·MOR 방식과 Position Delete·Equality Delete의 Data Sequence Number 적용 규칙을 분석해, 같은 Commit 안의 변경은 이전 Row를 Position Delete로 지워야 한다는 원칙을 세웠습니다. Databricks Iceberg Sink Connector에서 파티션 분산, Commit Timeout, Schema Evolution이 `insertedRowMap`을 초기화하거나 공유하지 못하게 해 이 원칙을 깨뜨리는 경로를 찾아, Kafka 키 설정과 preCommit 단계, 별도 Registry로 대응했습니다. 그 결과 Iceberg를 준실시간 CDC 적재와 Upsert·History·Delete-only 테이블에 활용하고, 저장소 수준의 중복 제거에도 사용할 수 있게 됐습니다.

• MOR은 쓰기 비용을 낮추지만 Delete File이 쌓이면 읽기 성능이 저하되므로 컴팩션 계획도 함께 세워야 합니다.
• Kafka에서 같은 키의 이벤트 순서를 보장하려면 레코드 키를 Iceberg의 식별자 컬럼으로 설정해 같은 파티션에 보내야 합니다.
• Commit 경계와 Writer 수명 주기를 점검해, 파일이 다음 Commit으로 넘어가거나 Writer가 교체돼도 삭제 위치 정보가 유지되는지 확인하세요.
• Equality Delete는 같은 Data Sequence Number의 새 파일에는 적용되지 않지만, Commit 경계가 어긋나면 의도치 않은 중복을 만들 수 있습니다.