히든 파티셔닝과 파티션 진화
Delta Lake vs Iceberg 2026: Which Table Format Wins? — 미상 (실전 프로덕션 경험 기반 블로그, 2026) Apache Iceberg Key Features 중 Hidden partitioning / Partition evolution (p.5), Head-to-Head Comparison 표의 Partition Evolution/Hidden Partitioning 행 (pp.6-7)
이 모듈을 다 읽으면
- 히든 파티셔닝이 해결하는 문제(사용자가 파티션 컬럼을 직접 알아야 하는 부담)를 설명할 수 있다
- 대표적인 파티션 변환 함수(identity, bucket, truncate, year/month/day/hour)의 역할을 구분할 수 있다
- 파티션 진화가 왜 '전체 재작성 없이' 가능한지, 여러 파티션 스펙이 한 테이블에 공존하는 구조를 설명할 수 있다
Iceberg의 히든 파티셔닝은 사용자가 파티션 컬럼(year, month, day 등)을 직접 WHERE 절에 나열하지 않아도, 원본 컬럼 값(event_date)만으로 쿼리하면 엔진이 알아서 올바른 파티션에 매핑해주는 기능이다. 이는 파티션 변환 함수(transform)를 스키마에 등록해두기 때문에 가능하다. 파티션 진화는 기존 데이터를 재작성하지 않고 파티션 스킴을 바꾸는 기능으로, 한 테이블 안에 여러 파티션 스펙이 공존할 수 있는 Iceberg의 메타데이터 설계 덕분에 가능하다.
히든 파티셔닝: 사용자는 파티션 스킴을 몰라도 된다
전통적인 Hive 스타일 파티셔닝에서는 테이블이 year=2026/month=3/day=15 같은 디렉터리 구조로 쌓이고, 사용자가 쿼리를 쓸 때도 WHERE year=2026 AND month=3 AND day=15처럼 파티션 컬럼을 직접 알고 나열해야 한다. 이 컬럼명과 값 형식(0-padding 여부 등)을 몰라 파티션 프루닝이 실패하는 사고가 실무에서 흔하다.
Iceberg의 히든 파티셔닝은 이 부담을 없앤다. 사용자는 그냥 원본 컬럼으로 WHERE event_date = '2026-03-15'라고 쓰면 되고, Iceberg가 스키마에 등록된 파티션 변환(transform) 정의를 참조해 이를 올바른 파티션으로 자동 매핑한다. 대표적인 변환 함수로는 identity(원본 값 그대로), year/month/day/hour(타임스탬프를 시간 단위로 절단), bucket(N, col)(해시 후 N개 버킷으로 분산), truncate(W, col)(문자열/숫자를 앞자리 W만큼 절단) 등이 있다. 즉 원문이 예시로만 언급한 '파티션 매핑'의 실제 구현은 이런 명명된 변환 함수 목록으로 되어 있다.
핵심 포인트
- 전통적 Hive 파티셔닝은 사용자가 파티션 컬럼명·형식을 정확히 알아야 프루닝이 성공한다
- Iceberg 히든 파티셔닝은 원본 컬럼으로만 쿼리해도 등록된 변환 함수를 통해 자동으로 파티션 프루닝한다
- identity, year/month/day/hour, bucket(N, col), truncate(W, col)가 대표적인 파티션 변환 함수다
파티션 진화: 재작성 없는 스킴 변경
원문은 '일별 파티셔닝에서 시간별 파티셔닝으로 바꿔도 Iceberg는 기존 데이터와 새 데이터를 매끄럽게 처리한다'고 설명한다. 이것이 가능한 이유는 Iceberg가 파티션 스펙 자체를 테이블의 버전 있는 메타데이터 항목으로 취급하기 때문이다.
파티션 스킴을 바꾸는 ALTER TABLE ... PARTITION BY 연산은 새로운 파티션 스펙 ID를 발급할 뿐, 기존에 쓰인 데이터 파일은 전혀 건드리지 않는다. 이후 새로 쓰이는 데이터는 새 스펙을 따르고, 기존 데이터는 예전 스펙을 유지한 채로 매니페스트 파일에 '이 파일은 어떤 스펙으로 쓰였는지'가 함께 기록된다. 쿼리 플래너는 스캔 범위가 여러 파티션 스펙에 걸쳐 있으면 각 스펙에 맞는 프루닝 로직을 스펙별로 적용해 계획을 합친다. 그 결과 사용자 입장에서는 '재작성 없이 파티션 전략을 바꿨다'는 경험을 하게 되지만, 실제로는 여러 파티션 스펙이 계속 공존하는 구조라는 점을 이해하는 것이 중요하다 — 오래된 파티션 스펙에 최적화된 스캔 로직이 영원히 사라지는 것은 아니다.
핵심 포인트
- 파티션 스킴 변경은 새 파티션 스펙 ID만 발급할 뿐 기존 데이터 파일을 재작성하지 않는다
- 한 테이블 안에 여러 파티션 스펙이 동시에 공존할 수 있고, 매니페스트가 파일별로 어떤 스펙을 썼는지 추적한다
- 쿼리 플래너는 스펙이 다른 데이터가 섞여 있어도 스펙별로 프루닝해 결과를 합친다
Delta Lake의 대안: 재작성 필요성과 Liquid Clustering (보조 맥락)
원문에 따르면 Delta Lake는 역사적으로 파티션 스킴을 바꾸려면 테이블 전체를 재작성해야 했다. Databricks는 이 문제를 정적 파티셔닝을 아예 우회하는 방향으로 풀고 있는데, 그것이 리퀴드 클러스터링(Liquid Clustering)이다. 이는 Databricks 전용 기능으로 파티션 컬럼을 미리 고정하지 않고 클러스터링 키만 지정하면 내부적으로 데이터 배치를 최적화해주는 방식이다. 다만 이는 Delta Lake/Databricks 스코프의 기능이므로 세부 동작은 이 학습 프로그램의 범위 밖이며, 'Iceberg는 파티션 진화로, Delta는 재파티셔닝이 필요 없는 방향(리퀴드 클러스터링)으로' 같은 서로 다른 방향의 해법이 존재한다는 사실만 대조 맥락으로 기억하면 충분하다.
핵심 포인트
- Delta Lake는 역사적으로 파티션 스킴 변경 시 전체 재작성이 필요했다 (Iceberg의 파티션 진화와 대조되는 지점)
- Databricks의 리퀴드 클러스터링은 정적 파티셔닝 자체를 대체하려는 별도 접근이며 Delta/Databricks 스코프의 기능이다