Apache Iceberg 1.11.0은 2026년 5월 19일 공식 출시되었습니다. 이는 개방형 데이터 라이브하우스 아키텍처의 발전에서 중대한 마일스톤을 상징합니다. 소수점 버전은 일반적으로 작은 버그 수정과 의존성 업데이트에 집중하지만, 이 릴리스는 기본적인 구조적 변경 사항을 도입합니다. 커뮤니티는 보안 향상, 파일 형식 기능 확장, 쿼리 계획 오버헤드 최적화와 같은 주요 이니셔티브를 완료했습니다.
이 릴리스는 두 개의 개발 집중 분야가 통합된 것을 나타냅니다. 첫째, 핵심 메타데이터 사양에 구조적 변경 사항을 도입하여 고급 보안 기능을 지원하고 향후 형식 변경의 기반을 마련합니다. 둘째, Iceberg 형식 사양에서 여러 기능 세트를 안정화하여 실험 중인 상태에서 완전히 안정적인 기본값으로 이동합니다.
이 게시물은 Apache Iceberg 1.11.0 릴리스에서 가장 중요한 개선 사항을 분석합니다. 우리는 구체적인 GitHub pull request를 검토하고 각 기능의 기반이 되는 메커니즘을 설명하며 이러한 변경 사항이 데이터 엔지니어와 플랫폼 아키텍트에게 의미하는 바를 살펴보겠습니다.
메니페스트 목록 암호화 (PR #7770, #15813)
개방형 데이터 라이크하우스에서의 보안은 역사적으로 객체 저장소에 저장된 실제 데이터 파일을 암호화하는 데 중점을 두었습니다. 파일 수준의 암호화는 권한 없는 사용자가 원시 Parquet 또는 ORC 데이터를 읽지 못하도록 방지하지만, 테이블 메타데이터는 여전히 노출되었습니다. 기본 설정에서는 저장소 버킷에 읽기 권한이 있는 모든 사람이 메타데이터 JSON, 매니페스트 목록 및 매니페스트 파일을 검사할 수 있습니다.
이 메타데이터 파일에는 민감한 구조적 세부 정보가 포함되어 있습니다. 암호화되지 않은 매니페스트 목록을 스캔하는 공격자는 파일 경로, 열 이름, 파티션, 파티션 경계, 정확한 null 값 개수를 추출할 수 있습니다. 의료나 금융 서비스와 같은 엄격하게 규제되는 산업에서 이러한 구조적 노출은 주요 데이터 누출로 간주됩니다.
이 취약점을 해결하기 위해 @ggershinsky가 소개한 PR #7770은 매니페스트 목록에 대한 네이티브 암호화를 추가합니다. 이 변경 사항은 PR #15813의 후속 개선 사항과 함께 작동합니다. 매니페스트 목록은 이제 Galois/Counter 모드(GCM) 스트림 암호화를 사용하여 암호화할 수 있습니다.
Metadata JSON (Contains encryption state references)
│
▼
Manifest List (Encrypted via GCM Stream Cipher) ◄── Decrypted in-memory during planning
│
▼
Manifest Files (Point to encrypted Parquet data files)
테이블 암호화 구성은 테이블 생성 중에 정의하거나 테이블 속성을 통해 업데이트할 수 있습니다.
쿼리 엔진이 암호화된 테이블에 대해 스캔을 계획할 때 다음 순서를 수행합니다.
- 클라이언트는 каталог을 쿼리하여 테이블 메타데이터를 가져옵니다.
- каталог은 필요한 복호화 키와 함께 메타데이터 위치를 반환합니다.
- 쿼리 엔진은 객체 저장소에서 암호화된 매니페스트 목록을 읽습니다.
- 카탈로그 키를 사용하여 엔진은 메모리 내에서 매니페스트 목록을 복호화합니다.
- 엔진은 복호화된 파티션과 통계를 처리하여 매니페스트 파일을 정리합니다.
이 접근 방식은 매니페스트 목록이 평문으로 디스크에 쓰이지 않도록 보장합니다. 이는 암호화 봉투 모델을 구현합니다: 각 메타데이터 파일은 고유한 데이터 암호화 키(DEK)로 암호화되고, 이 DEK들은 테이블의 마스터 키를 관리하는 키 관리 서비스(KMS)에 의해 관리되는 테이블의 마스터 키로 다시 암호화됩니다. 공격자가 저장 버킷에 원시 접근을 얻더라도 그들은 암호화된 바이트만 찾아서, 테이블의 내용과 구조적 메타데이터 모두를 보호합니다.
플러그아웃 가능한 파일 형식 API 및 V4 사양 기반 (PR #15049)
역사적으로 Apache Iceberg은 데이터 파일 형식에 대한 지원을 고정 코드로 작성했습니다. 핵심 라이브러리에는 Parquet, ORC, Avro에 대한 형식별 코드 경로가 포함되어 있었습니다. 테이블을 쿼리하거나 작성하려면 엔진은 해당 구조에 맞게 맞춤화된 내부 코드 블록을 실행했습니다.
이 하드코딩된 설계는 형식 혁신에 큰 장벽을 만들었습니다. 팀이 다음 세대 형식을 테스트하고 싶으면 핵심 엔진 코드베이스를 수정해야 하며, 복잡한 스위치 문과 형식에 종속된 유틸리티를 확장해야 했습니다.
PR #15049, @anoopj에 의해 소개된 것은 이 아키텍처를 재구성합니다. 이는 플러그인 가능한 파일 형식 API를 도입하여 Iceberg 핵심 메타데이터 관리를 물리적 저장 레이아웃과 분리합니다.
┌────────────────────────────────────────────────────────┐
│ Iceberg Core Engine │
└───────────────────────────┬────────────────────────────┘
│
▼
┌────────────────────────────────────────────────────────┐
│ File Format API Interface Layer │
└──────┬────────────┬─────────────┬─────────────┬────────┘
│ │ │ │
▼ ▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Parquet │ │ ORC │ │ Vortex │ │ Lance │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
파일 형식 API는 깨끗한 플러그인 인터페이스를 제공합니다. 파일 형식은 표준 리더와 작성자 인터페이스를 구현하는 플러그인으로 정의됩니다. Iceberg 핵심은 테이블 트랜잭션, 스키마, 파티션 스펙을 협상하고, 물리적 파일 접근을 등록된 플러그인에 위임합니다.
이 분리는 다음 세대 형식을 지원하는 데 실용적입니다:
- Vortex: 일반 용도의 모듈식 형식으로 Parquet의 후속자로 설계되었습니다. 고성능 분석을 위해 최적화되었으며, 비워진 값에 비트맵 마스크를 사용하는 고정 너비 열을 활용합니다. 이는 메모리 매핑 파일에 직접 단일 명령 다중 데이터(SIMD) 필터링을 가능하게 하며, CPU 해제 주기 없이 이를 수행할 수 있습니다. 커뮤니티는 새로운 API를 활용하여 Vortex를 지원하는 Iceberg 플러그인을 구축하고 있습니다.
- Lance: 머신러닝과 AI 작업에 맞게 설계된 레이아웃입니다. 고차원 벡터 검색 및 중첩 임베딩에 대한 랜덤 액세스를 최적화하며, 파일 형식에 직접 Inverted File with Product Quantization (IVF-PQ)와 같은 인덱스 구조를 구현하여 빠른 쿼리 계획을 가능하게 합니다.
- Nimble: 넓은 테이블에 수천 개의 특징 열을 포함하도록 최적화된 형식입니다. Nimble은 높은 압축률보다 빠른 디코딩을 우선시하며, 가벼운 run-length 및 비트 패킹 압축 방식을 선택합니다. 이는 초당 수백만 개의 행을 소비하는 ML 훈련 루프의 CPU 오버헤드를 줄입니다.
또한, PR #15049는 앞으로 출시될 V4 매니페스트 사양의 기본 Java 인터페이스와 타입을 소개합니다. 이 변경 사항은 Iceberg가 포맷에 독립적인 매니페스트 저장을 준비하도록 하며, 메타데이터 레이어가 백만 개의 파일을 가진 테이블로 확장될 수 있도록 Java 메모리 오버헤드 제한을 초과하지 않도록 합니다.
REST 클라이언트 프로토콜 및 확장 헤더 (PR #12194)
REST Catalog 프로토콜은 여러 처리 엔진에서 Iceberg 테이블을 관리하는 표준 인터페이스가 되었습니다. 이는 클라이언트를 카탈로그 카탈로그 세부 사항에서 분리하고 스키마 관리, 스냅샷 커밋 및 자격 증명 판매를 위한 통합 API를 제공합니다.
그러나 대형 기업 내에서 배포가 확장됨에 따라, 카탈로그는 사용자 맞춤 클라이언트 컨텍스트를 처리해야 합니다. 예를 들어, 플랫폼 팀은 어떤 비즈니스 부문이 쿼리를 제출했는지 추적하고, 사용자 맞춤 보안 토큰을 전달하거나, 분산 추적을 위해 관련 ID를 주입하고 싶을 수 있습니다. 이전 버전에서는 표준 RESTClient가 클라이언트가 사용자 맞춤 HTTP 헤더를 전송할 수 없었습니다.
PR #12194, @gaborkaszab에 의해 작성되었으며, 이 제약 조건을 해결하기 위해 RESTClient 구현 내에서 헤더 지원을 확장합니다.
┌────────────────────────────────┐
│ Iceberg REST Client │
│ (Spark, Flink, Trino, etc.) │
└───────────────┬────────────────┘
│
│ POST /v1/namespaces/db/tables/events
│ Custom-Headers:
│ - X-Trace-Id: trace-98421
│ - X-Tenant-Id: finance-billing
│
▼
┌────────────────────────────────┐
│ REST Catalog Server │
│ (Parses headers for auditing) │
└────────────────────────────────┘
이 업데이트를 통해 클라이언트 엔진은 모든 REST 호출에 맞춤형 헤더를 구성하고 주입할 수 있습니다. 클라이언트-서버 핸드셰이크는 다음 순서를 따릅니다:
- 클라이언트는 속성 맵을 사용하여 REST 카탈로그를 초기화합니다.
- 클라이언트는
header.custom.접두사를 사용하여 정적 사용자 지정 헤더를 지정합니다:
header.custom.X-Tenant-Id=finance-billing
header.custom.X-Trace-Id=system-trace-99
- 요청 실행 중에
RESTClient는 HTTP 호출을 중단하고 이러한 사용자 지정 헤더를 주입합니다. - REST 카탈로그 서버는 헤더를 처리하여 동적 권한 부여, 감사 로깅 또는 요청 라우팅을 적용합니다.
이 변경 사항은 다음 기능을 활성화합니다.
- 감사 및 거버넌스:엔진은 HTTP 헤더에 테넌트 식별자 또는 사용자 프로필을 전달할 수 있게 하여, REST 카탈로그 서버가 전체 사용자 맥락으로 카탈로그 작업을 로그로 남길 수 있게 합니다.
- 분산 추적: W3C Trace Context와 같은 추적 헤더는 클라이언트 엔진을 통해 카탈로그 서버로 전파될 수 있으며, 쿼리 계획 작업에 대한 끝에서 끝까지 추적 가시성을 제공합니다.
- 동적 인가: 클라이언트는 REST 카탈로그 서버가 동적으로 평가하여 미세한 수준의 접근 제어를 강제하는 사용자 지정 인가 토큰을 전송할 수 있습니다.
카탈로그 초기화 중 표준 구성 맵을 사용하여 속성이 구성되며, 기존 쿼리 플랫폼에 헤더를 쉽게 배포할 수 있습니다.
오버라이트-에어리 Table 등록 (PR #15525)
다중 임대 데이터 플랫폼에서 여러 엔진이 자주 동일한 테이블 메타데이터에 접근하고 수정합니다. 새로운 테이블을 등록하거나 기존 테이블 상태를 카탈로그에 가져올 때 동시성 충돌이 발생할 수 있습니다.
두 개의 분리된 프로세스가 동시에 같은 위치에서 테이블 참조를 등록하거나 덮어쓰려고 할 때, 순수한 카탈로그는 두 번째 요청을 등록하고 첫 번째 요청을 조용히 덮어씁니다. 이는 카탈로그가 최신이거나 잘못된 metadata.json 파일을 가리키는 데이터 불일치를 생성합니다.
PR #15525, @sririshindra에 의해 작성되었으며, 카탈로그 API에 덮어쓰기 인지 테이블 등록을 추가합니다.
Writer 1: Commits events_v1 ────► [Catalog Table Pointer] ◄──── Writer 2: Commits events_v2
│
├────────► If conflict: Catalog rejects Writer 2
└────────► Prevents silent metadata overwrites
이 구현은 캐탈로그 수준에서 오프닝 컨컨트롤 (OCC)을 활용합니다. 충돌 해결 순서는 다음과 같습니다.
- 작성자 A와 작성자 B 모두 현재 테이블 상태를 스냅샷 v1으로 가리키고 있습니다.
- 작성자 A는 새로운 데이터 파일을 작성하여 메타데이터 버전
metadata_v2.json을 생성합니다. - 작성자 B는 병렬로 새로운 데이터 파일을 작성하며, 메타데이터 버전
metadata_v3.json을 생성합니다. - 작성자 A는 카탈로그의
/v1/namespaces/db/tables/events/register엔드포인트를 호출하며 기대되는 기본 위치가metadata_v1.json임을 명시합니다. - 카탈로그는 기본 위치가 일치하는지 확인하고, 새로운 포인터를
metadata_v2.json에 등록하며, 테이블 버전을 업데이트합니다. - 작성자 B는 자신의 상태를 등록하려고 시도하며,
metadata_v1.json를 기대하는 기본값으로 나열합니다. - 카탈로그는 현재 포인터가 이제
metadata_v2.json임을 감지합니다. - 카탈로그는 작성자 B의 요청을 거부하고 HTTP 409 Conflict를 반환합니다. 작성자 B는 업데이트된 테이블 상태를 다시 읽고 겹치는 파티션 커밋을 해결한 후 다시 등록을 시도해야 합니다.
이 검증은 테이블 등록이 안전하며 활발한 환경에서 침묵하는 메타데이터 오버라이트를 방지합니다.
스냅샷 검증에서 삭제 벡터 가지치기 (PR #15653)
V3 형식 사양의 주요 특징 중 하나는 삭제 벡터의 안정화입니다. 삭제 벡터는 위치 기반 삭제 파일을 Roaring 비트맵으로 대체하여 행 수준 삭제 성능을 향상시킵니다. 매우 작은 업데이트마다 새로운 삭제 파일을 작성하는 대신, 엔진은 데이터 파일에 직접 연결된 이진 비트맵을 업데이트합니다.
이 삭제 비트맵은 Puffin 파일 형식으로 저장됩니다. 활성 삭제 벡터 위치를 메타데이터 시스템 테이블을 사용하여 확인할 수 있습니다:
SELECT file_path, pos, row_position, deletion_vector
FROM TABLE(table_files('my_catalog.schema.events'));
그러나 테이블이 수백만 개의 데이터 파일을 저장하도록 커지면, 쿼리 계획 중 삭제 벡터를 검증하는 데 지연이 발생할 수 있습니다. 스캔 계획 중에 쿼리 엔진은 메타데이터에 연결된 삭제 벡터가 유효한지 확인하고 해당 데이터 파일과 일치해야 합니다.
이전 버전에서는 계획 초기화 중 전체 테이블 스냅샷 전체에서 이 유효성 검사를 수행했습니다. 50 TB 테이블이 있고 단일 날짜를 쿼리했다면, 플래너는 여전히 전체 테이블의 삭제 벡터를 유효성 검사하는 데 시간을 소비했습니다.
PR #15653, @anoopj에 의해 도입되었습니다, 이 과정을 최적화합니다. 삭제 벡터 유효성 검사 내에 MergingSnapshotProducer에 명시적 파티션 절제를 추가합니다.
Query Filter: WHERE event_date = '2026-05-23'
│
▼
Partition Pruning Step
│
├─► Skip Partition '2026-05-22' ──► Skip Deletion Vector Validation
│
└─► Read Partition '2026-05-23' ──► Run Deletion Vector Validation
이 변경으로, 쿼리 플래너는 삭제 벡터 검사를 실행하기 전에 쿼리 필터 페르미테이드를 파티션 경계와 일치시킵니다. 파티션이 잘려나가면, 엔진은 해당 파티션의 파일에 대한 삭제 벡터를 검증하지 않습니다. 이 변경은 플래닝 CPU 사이클을 줄이고 파티션된 테이블의 스캔 시작 시간을 개선합니다.
숨겨진 파티셔닝이 쿼리 엔진이 파티션 가리기를 수행하고 메타데이터 스캔 크기를 줄이는 방법에 대한 자세한 내용은 Apache Iceberg Hidden Partitioning Post.
일정된 자격 증명 수명 주기 새로 고침 (PR #15678, #15732, #15696)
데이터 라크하우스의 보안을 강화하기 위해 플랫폼은 오래 지속되는 저장소 자격 증명을 사용하지 않습니다. 대신 쿼리 엔진은 REST 카탈로그 또는 클라우드 식별 공급자가 제공하는 일시 토큰을 사용하여 인증합니다. 이러한 자격 증명은 일반적으로 짧은 수명을 가지며, 보통 한 시간 후에 만료됩니다.
이 보안 모델은 긴급 실행 작업에 문제를 일으킵니다. 거대한 쿼리가 90분 동안 실행되거나 스트리밍 Flink 소스가 지속적으로 실행되면 임시 자격 증명이 작업 중간에 만료됩니다. 클라이언트가 만료 시간 후에 새 파일을 쓰거나 мани페스트를 가져보려고 시도하면 저장 클라이언트는 인증 예외를 던지며 작업이 실패합니다.
1.11.0 릴리스는 이 생애주기 문제를 해결합니다. PR #15678 (@danielcweeks)과 PR #15732 (@nastra)는 S3FileIO 클라이언트에 일정 갱신 스레드를 추가합니다. PR #15696 (@nastra)의 병렬 변경은 GCSFileIO에 동일한 기능을 구현합니다.
Query Thread (Reads/Writes Data)
│
├───────► Token Expiration Approaching (e.g. at 50 minutes)
│
Background Refresh Thread
│
├───────► Send Request to Catalog ──► Fetch New Credentials
│
└───────► Update S3FileIO/GCSFileIO Credentials In-Memory
│
Query Thread (Continues without interruption)
인증서 갱신 시스템은 토큰 만료 시간을 추적하는 백그라운드 데몬 스레드를 실행합니다. 생애주기는 다음 속성에 의해 제어됩니다.
활성 인증서가 만료되기 전에 백그라운드 스레드는 캐탈로그의 자동으로 폴링합니다./v1/tokens 엔드포인트는 새로 고침된 토큰을 사용하고 파일 시스템 클라이언트 메모리를 업데이트합니다. 주요 쿼리 및 쓰기 스레드는 중단 없이 계속 실행되어 만료된 자격 증명으로 인한 쿼리 실패를 제거합니다.
Spark Streaming 트리거 및 Z-Ordering (PR #13824, #15706)
Apache Spark은 Iceberg 테이블의 무거운 쓰기 작업과 배치 압축에 주요 엔진으로 남아 있습니다. 버전 1.11.0은 Spark 스트리밍 및 레이아웃 최적화를 개선하기 위한 여러 업데이트를 포함합니다.
트리거.AvailableNow 지원 (PR #13824, #14026)
PR #13824, @alexprosak에 의해 소개되었으며, 트리거 지원을 추가합니다AvailableNow Spark Structured Streaming에서 트리거됩니다. 이 변경 사항은 PR #14026에서 Spark 4.0, 3.5, 및 3.4로도 역배포되었습니다.
Continuous Trigger:
[Read Batch 1] -> [Write] -> [Wait] -> [Read Batch 2] -> [Write] -> (Runs indefinitely)
AvailableNow Trigger:
[Scan All Available Data] -> [Process Batch 1] -> [Process Batch 2] -> [Write All] -> [Graceful Shutdown]
Spark streaming에서 기본 트리거는 백그라운드에서 지속적으로 실행되며, 새로운 파일이 도착하지 않을 때에도 리소스를 소비합니다. 대안Once은 단일 배치만 트리거하고 종료되므로, 큰 백로그가 누적되어 있으면 데이터가 처리되지 않을 수 있습니다.
AvailableNow 트리거는 두 가지 접근 방식의 장점을 결합합니다. 이는 소스에서 모든 사용 가능한 데이터를 스캔하고, 작업을 연속적인 미크로-배치로 나누어, 단일 실행에서 모두 처리한 다음 스트리밍 컨텍스트를 종료합니다. 이는 PySpark에서 다음과 같이 구성됩니다:
# Configure Trigger.AvailableNow with Iceberg source and sink
query = spark.readStream \
.format("iceberg") \
.load("prod_catalog.db.events") \
.writeStream \
.format("iceberg") \
.trigger(availableNow=True) \
.option("checkpointLocation", "/mnt/checkpoints/events") \
.toTable("prod_catalog.db.events_compacted")
이 트리거 구성은 데이터 플랫폼이 스트리밍 수집 파이프라인을 일정된 크론 작업으로 실행할 수 있게 하여 클러스터 비활성 시간을 줄입니다.
Z-Order 열 충돌 검증 (PR #15706)
PR #15706, @YanivZalach에 의해 도입되었으며, Z-order 레이아웃 최적화 중에 발생하는 오류 모드를 해결합니다. Spark는 내부 열 이름을 사용합니다ICEZVALUE는 Z-order 정렬 중에 발생합니다. 사용자 테이블에 이미 ICEZVALUE이라는 이름의 열이 포함되어 있으면 컴팩트 프로세스가 실패하거나 잘못된 정렬 순서를 생성했습니다.
업데이트는 Z-order 컴팩트 작업을 실행하기 전에 열 이름 충돌을 확인하는 엄격한 스키마 검증을 추가하여 데이터 손상을 방지합니다.
Flink Post-Commit Maintenance 및 Branch Compaction (PR #15566, #15672, #14148)
Apache Flink은 Iceberg 테이블에 실시간 스트리밍을 수용하는 표준 엔진입니다. 스트리밍 수용은 배치 수용과 다른 쓰기 특성을 가지며, 종종 높은 빈도로 많은 작은 파일을 작성합니다. Iceberg 1.11.0은 이러한 파일을 Flink 파이프라인 내에서 직접 관리할 수 있는 기능을 추가했습니다.
Flink Post-Commit Maintenance (PR #15566, #15667)
PR #15566, @mxm 작성는 Flink의 IcebergSink 빌더 내에서 임의의 커밋 후 유지보수 작업을 지원합니다. 이는 PR #15667에서 활성 Flink 분기로도 복원되었습니다.
스트리밍 수집 중, Flink은 매 checkpoint마다 Iceberg 테이블에 데이터를 커밋합니다. 이러한 빈번한 커밋은 많은 수의 작은 매니페스트 파일을 생성합니다. 새로운 커밋 후 인터페이스를 통해, 백그라운드 유지보수 작업을 직접 소스에 연결할 수 있습니다:
// Configure Flink sink with post-commit compaction
IcebergSink.forRowData(dataStream, tableLoader)
.table(icebergTable)
.tableLoader(tableLoader)
.writeParallelism(4)
.distributionMode(DistributionMode.HASH)
.postCommitMaintenance(
PostCommitMaintenance.builder()
.optimizeDataFiles(true)
.rewriteManifests(true)
.build()
)
.append();
커밋이 성공하면, Flink는 백그라운드에서 컴팩션과 매니페스트 정리 작업을 실행하여 테이블 구조를 최적화하고 외부 스케줄러 작업 없이 유지합니다.
Flink Stream Ingestion
│
▼
[Commit Data File (Checkpoint)]
│
├───────► Post-Commit Trigger
│
▼
[Background Maintenance Action (RewriteDataFiles / Compaction)]
Flink 브랜치 컴팩션 지원 (PR #15672, #15690)
PR #15672는 또한 @mxm에 의해 작성되었으며, Flink RewriteDataFiles 동작에 브랜치 지원을 추가합니다.
역사적으로 Flink의 배경 압축 작업은 테이블의 메인 브랜치에서만 실행할 수 있었습니다. 현대 아키텍처에서는 엔진들이 종종 실험 데이터나 스테이징 실행을 별도의 테이블 브랜치에 통합합니다. Flink은 이제 메인 브랜치가 아닌 이러한 브랜치에서 파일 압축을 직접 실행할 수 있으며, 병합되기 전에 스테이징 및 실험 브랜치를 정리할 수 있습니다.
Flink 메타데이터 열 (PR #14148)
PR #14148, @Guosmilesmile에 의해 소개된, Flink readers에게 메타데이터 열을 노출시킵니다.
Flink 애플리케이션은 이제 _row_id와 _last_updated_sequence_number 시스템 열을 읽을 수 있습니다. 이는 행의 정확한 수집 순서를 추적해야 하는 CDC(Change Data Capture) 조정 파이프라인에 유용합니다.
JSON에서 Variant 매핑 및 Spec 정리 (PR #13137, #14045)
Variant 타입은 Iceberg V3 사양의 핵심 부분으로, 선형 구조화된 데이터를 이진 표현을 사용하여 저장하도록 설계되었습니다. 이는 전제 조건 전파를 지원합니다. Iceberg 1.11.0은 여러 엔진에 걸쳐 이 통합을 정제합니다.
Variant 타입 검증 (PR #13137, #14081)
PR #13137 (by @manirajv06)와 PR #14081 (by @geruh)는 Parquet 메트릭스에서 Variant 타입의 스키마 검증 및 필터링 규칙을 추가합니다.
이 업데이트는 Parquet 파일 리더가 중첩된 변형 구조에서 열 수준 통계를 추출할 수 있도록 보장합니다. 이는 쿼리 엔진이 중첩된 변형 필드를 기준으로 파일을 제거할 수 있게 하여 쿼리 성능을 향상시킵니다.
Trino 변형 타입 매핑
동시에 쿼리 엔진 커넥터는 이러한 변경 사항을 채택하고 있습니다. Trino는 이제 자체 네이티브JSON를 Iceberg의 Variant 타입으로 V3 테이블에 변환합니다. 이는 Trino에서 JSON 데이터를 작성하고, 전제 조건 전파를 통해 쿼리할 수 있게 하며, 평범한 문자열 JSON의 성능 패널티를 피할 수 있음을 의미합니다.
행 데이터를 포함하는 위치적 삭제는 폐지되었습니다 (PR #14045)
PR #14045, @pvary에 의해 작성된, 행 데이터를 포함하는 위치적 삭제 파일은 폐지되었습니다.
Iceberg V2에서 위치 기반 삭제 파일은 파일 경로와 행 오프셋과 함께 실제 삭제된 행 데이터를 저장할 수 있습니다. 이 설계는 읽기 중 결합 단계를 절약했지만, 삭제 파일에서 데이터를 복제하여 저장 비용과 메타데이터 복잡성을 증가시켰습니다.
커뮤니티는 삭제 벡터를 선호하여 이 옵션을 폐기했으며, V3 읽기 경로를 단순화했습니다.
테이블 업그레이드 경로 및 커넥터 호환성
V3 기능 모두: мани페스트 목록 암호화, 삭제 벡터, 변형 유형, 지리 공간 유형 및 나노초 타임스탬프: 테이블을 형식 버전 3으로 업그레이드해야 합니다.
Existing V2 Table
│
├───────► Run: ALTER TABLE events SET TBLPROPERTIES ('format-version' = '3')
│
Upgraded V3 Table
│
├───────► New writes use Deletion Vectors and Variant type
└───────► Existing data files are left untouched (no rewrite required)
업그레이드는 메타데이터만을 사용하는 SQL을 통해 실행됩니다.
-- Upgrade an existing table to Iceberg V3 format version
ALTER TABLE my_catalog.schema.events
SET TBLPROPERTIES ('format-version' = '3');
이 작업은 테이블의 메타데이터 JSON에서 format-version 포인터를 업데이트합니다. 기존 데이터 파일을 다시 작성하지 않으며, 이는 그 자리에 남아 계속 읽을 수 있습니다.
테이블에 대한 새로운 쓰기는 자동으로 V3 기능을 채택합니다. 예를 들어, 이후 업데이트 또는 삭제 문장은 삭제 벡터를 작성 대신 위치 삭제 파일을 작성합니다.
생애주기 상태 업데이트
V3로의 이전을 계획하기 전에 Iceberg 1.11.0의 엔진 호환성 변경 사항을 검토하십시오:
- Java 11 지원 중단: Iceberg 1.11.0은 Java 11을 더 이상 지원하지 않습니다. 핵심 라이브러리와 엔진 커넥터는 이제 Java 17 또는 Java 21을 요구합니다.
- Spark 3.4 지원 폐지: Spark 3.4 지원이 폐지되었습니다. 팀은 Spark 3.5 또는 Spark 4.0+로 이전해야 합니다.
- Flink 1.19 지원 제거: Flink 1.19은 더 이상 지원되지 않습니다. 릴리스는 Flink 2.1.0를 지원합니다.
생산 테이블 업그레이드 전에 lakehouse 배포에 있는 모든 쿼리 엔진과 도구체인이 Iceberg V3와 Java 17을 지원하는지 확인하세요.
Dremio 내에서 쿼리 성능 최적화 및 테이블 형식 버전 관리에 대한 자세한 내용은 Dremio Autonomous Performance Blog를 참조하십시오.
결론
Apache Iceberg 1.11.0은 프로젝트에 있어 중요한 릴리스입니다. 이는 점진적인 향상을 넘어 주요 아키텍처 업데이트를 제공합니다.
統일된 파일 형식 API는 Iceberg가 물리적 저장 형식과 상호작용하는 방식을 재구성합니다. 이 변경 사항은 AI 및 고성능 작업을 위해 설계된 다음 세대 코덱 통합을 더 쉽게 만듭니다.
동시에 V3 기능의 안정화는 삭제 벡터, 변형 데이터, 지리 공간 유형 및 나노초 정밀도에 대한 생산 준비된 경로를 제공합니다. 이러한 기능은 조직이 쿼리 성능을 최적화하고 운영 부담을 줄이는 데 도움이 됩니다.
Iceberg V2 테이블을 운영 중이라면, V3 업그레이드로부터 혜택을 받을 수 있는 테이블을 식별하기 위해 작업 부하를 평가하세요. 특히, 활성 업데이트 패턴이 있는 테이블이나 큰 JSON 열을 가진 테이블은 즉각적인 성능 향상을 경험하게 됩니다.
Your Data Lakehouse Expertise를 구축하세요
현대 데이터 플랫폼을 설계하거나 구축하거나 관리하고 있다면 형식 사양을 앞서 나가는 것이 중요합니다. 이러한 기술에 대한 이해를 심화시키려면 다음을 읽어보세요:
- "Architecting an Apache Iceberg Lakehouse": 개방형 lakehouse 플랫폼 설계, 카탈로그 아키텍처 관리 및 테이블 레이아웃 최적화에 대한 아키텍처 가이드.
- 기타 데이터 Lakehouse出版物 실용적인 책들로 숨겨진 파티셔닝, 스키마 진화, 쿼리 가속 엔진을 다루고 있습니다.
이 책들을 찾아 다른 lakehouse 학습 자원은 books.alexmerced.com 에서 찾을 수 있습니다.
Iceberg V3 테이블을 자동 파일 레이아웃 최적화, 백그라운드 압축, 인프라 관리 없이 쿼리하려면 Dremio Cloud의 무료 트라이얼을 시작하세요.dremio.com/get-started