Kafka 토픽과 Iceberg 테이블 네이밍 방식

요약

구분	네임스페이스 구조	예시
Kafka 토픽	<project>.<entity>.<layer>	olist.orders.raw
Iceberg	<catalog>.<database>.<table>	warehouse_dev.olist.bronze_orders

Kafka 토픽 네이밍 컨벤션

구분	설명
패턴	<project>.<entity>.<layer>[-v<version>]
<project>	비즈니스 도메인 또는 팀 이름
<entity>	처리할 데이터 대상명
<layer>	데이터 처리 단계 (raw, enriched, aggregates 등)
<version>	스키마 변경 시 부가하는 선택적 접미사 (-v2, -v3 등)

장단점 비교

구분	장점	단점
직관성	엔티티, 레이어 구분이 명확해 운영, 모니터링이 용이	토픽이 과도하게 생성돼 관리 오버헤드 발생
확장성	멀티테넌시 및 스키마 버전 관리가 확장 가능	네이밍 변경 시 기존 소비자 구성 업데이트 필요
필터링	olist.orders.*, olist.raw.* 로 빠른 토픽 그룹 조회 가능	레이어 중심 필터링 시 엔티티별 세부 파악이 어려울 수 있음

Apache Iceberg 카탈로그, 네임스페이스, 테이블 네이밍 관례

계층	네임스페이스 구성	설명
Catalog	warehouse_dev, iceberg_catalog	테이블 메타데이터 저장소(메타스토어) 식별자
Database	olist	비즈니스 도메인 또는 프로젝트 구분
Table	<layer>_<entity>	레이어와 엔티티 결합 (bronze_orders, silver_reviews)

장단점 비교

구분	장점	단점
일관성	도메인별 네임스페이스 통일로 권한, 백업 관리 용이	테이블명이 길어져 가독성 저하 가능
유연성	레이어 확장 시 테이블 추가만으로 관리	레이어 변경 시 일괄 테이블명 수정 필요
확장성	다수 Catalog 환경에서도 Database 최소화로 관리 용이	별도 Schema(하위 Database) 사용 시 일관성 해칠 위험

핵심 포인트

• Kafka 토픽: 메시지 큐 목적으로 간결한 단일 네임스페이스 (project.entity.layer)
• Iceberg 테이블: 영구 저장, 쿼리 목적으로 3계층 네임스페이스 (catalog.database.table)
• 각 컨벤션은 서로 독립적이며, 목적에 맞게 일관 적용 시 운영, 확장, 협업 효율성 극대화
• 단점 보완을 위해 자동화 스크립트 및 변경 관리 프로세스 도입 권장