GlobalKTable — co-partitioning 없이 조인하기
Kafka Streams GlobalKTable 및 Processor API 공식 문서 종합 (웹 리서치, 2026) — Apache Kafka 공식 문서(streams/developer-guide/dsl-api, streams/developer-guide/processor-api) Apache Kafka 공식문서 Streams DSL — GlobalKTable
이 모듈을 다 읽으면
- GlobalKTable이 KTable과 데이터 분산 방식에서 근본적으로 어떻게 다른지 설명할 수 있다
- GlobalKTable과의 조인이 co-partitioning을 요구하지 않는 이유와 그 대가를 설명할 수 있다
kafka-learn-37에서 다룬 KTable(파티션 단위 분산)과 대비해, 모든 인스턴스가 전체 토픽을 통째로 들고 있는 GlobalKTable의 구조와, 그 덕분에 co-partitioning 없이 조인할 수 있게 되는 대신 치러야 하는 저장·네트워크 비용을 정리한다.
KTable과 정반대 — 부분 분산이 아니라 전체 복제
일반 KTable은 애플리케이션 인스턴스마다 토픽의 일부 파티션 데이터만 로컬에 갖는다 — 예를 들어 토픽이 5개 파티션이면 각 인스턴스는 그중 1개 파티션의 데이터만 본다. GlobalKTable은 이와 정반대다. 입력 토픽을 GlobalKTable로 읽으면, 애플리케이션의 모든 인스턴스 각각이 로컬 GlobalKTable에 그 토픽의 '모든' 파티션 데이터를 채워 넣는다 — 즉 인스턴스마다 전체 토픽의 완전한 사본을 갖는다.
핵심 포인트
- KTable: 인스턴스마다 토픽의 일부 파티션만 로컬 보유(파티션 단위 분산)
- GlobalKTable: 인스턴스마다 토픽의 모든 파티션을 로컬에 전부 복제(완전한 사본)
co-partitioning이 필요 없어지는 이유와 KeyValueMapper
스트림-테이블 조인이 co-partitioning(같은 파티션 수·같은 파티셔닝 전략으로 같은 키가 같은 파티션 번호에 오도록 맞추는 것)을 요구하는 이유는, 조인 로직이 '이 인스턴스가 담당하는 파티션에 그 키의 테이블 데이터도 함께 있다'고 가정하기 때문이다. 그런데 GlobalKTable은 이미 모든 인스턴스가 전체 데이터를 갖고 있으므로 이 가정 자체가 필요 없다 — 어느 인스턴스에서 조인하든 로컬에서 바로 찾을 수 있다. 이 덕분에 KStream을 GlobalKTable과 조인할 때는 KeyValueMapper를 써서 KStream 레코드의 키가 아닌 값(혹은 조합)을 기준으로도 조인(non-key-based join)할 수 있다 — 일반 KTable 조인은 반드시 같은 키로만 조인해야 하는 것과 다른 지점이다.
핵심 포인트
- co-partitioning은 '내 파티션에 그 키의 테이블 데이터도 있다'는 가정이 필요해서 요구되는 것 — GlobalKTable은 전체 사본이라 이 가정 자체가 불필요
- KeyValueMapper로 KStream의 키가 아닌 값 기반 조인(non-key-based join)도 가능 — 일반 KTable 조인은 키 일치만 가능
대가 — 저장·네트워크 비용, 그리고 언제 쓰는가
GlobalKTable은 공짜가 아니다. 공식 문서는 두 가지 증가 비용을 명시한다 — 전체 토픽을 추적하기 때문에 (파티션 단위인) KTable 대비 로컬 저장 공간 소비가 늘어나고, 전체 토픽을 읽기 때문에 네트워크 트래픽과 Kafka 브로커 부하도 늘어난다. 그래서 GlobalKTable은 상대적으로 작고 자주 안 바뀌는 참조·차원(dimension) 데이터를 모든 인스턴스에 편리하게 브로드캐스트하려는 경우(예: 국가코드→국가명 매핑)에 적합하고, 크고 계속 갱신되는 데이터에는 부적합하다.
핵심 포인트
- 일반 KTable 대비 로컬 저장 공간 소비 증가(전체 토픽 추적) + 네트워크·브로커 부하 증가(전체 토픽 읽기)
- 작고 자주 안 바뀌는 참조/차원 데이터를 모든 인스턴스에 브로드캐스트하는 용도에 적합, 크고 자주 바뀌는 데이터엔 부적합