Data Eng Wiki

Catalog-Managed Tables

9 min read

Catalog-Managed Tables

카탈로그를 테이블 ID·발견·접근 제어의 권위 있는 시스템으로 활용하는 lakehouse 거버넌스 패턴

핵심 개념

카탈로그 관리 테이블은 파일시스템 경로 기반의 전통적 테이블 관리에서 벗어나, 카탈로그가 테이블의 논리적 신원(identity), 메타데이터 저장, 동시성 제어, 커밋 비준(ratification)을 담당하는 아키텍처다. Delta Lake 4.1.0과 Apache Iceberg가 각각 이 패턴을 도입하면서 오픈 lakehouse 에코시스템의 공통 기반이 되고 있다.

왜 파일시스템 기반 테이블이 문제인가

전통적 Delta/Iceberg 테이블의 4가지 운영 문제:

  1. 경로 의존성: 앱이 물리적 스토리지 위치에 결합되어 인프라 재편 시 취약
  2. 거친 인가 제어: 파일시스템 ACL은 세밀한 권한 제어 불가 → 프라이버시 요구 시 데이터 복제·단편화
  3. 미검증 스키마 변경: 스토리지 자격증명이 쓰기 권한과 메타데이터 수정 권한을 구분 못함
  4. 성능 오버헤드: 테이블 상태 복원에 파일시스템 다중 호출 필요 → 쿼리당 100ms+ 추가

카탈로그 관리 테이블의 작동 방식

테이블 발견

클라이언트가 카탈로그에 논리적 3단계 네임스페이스(catalog.schema.table)로 테이블을 질의 → 카탈로그가 물리적 위치와 접근 규칙 반환

읽기 경로

  1. 카탈로그 API에서 미발행(unpublished) 커밋 조회
  2. 발행된 파일시스템 커밋과 병합하여 완전한 스냅샷 구성

쓰기 경로

  1. 라이터가 카탈로그에 커밋 제안(staged 또는 inline)
  2. 카탈로그가 유효성 검증 후 비준 → 파일시스템 PUT-if-absent 대체
  3. 동시성 충돌을 파일시스템이 아닌 카탈로그가 조정

Apache Iceberg File Format API와의 연계

Iceberg는 File Format API를 통해 Parquet, ORC, Avro 등 스토리지 포맷을 테이블 포맷 레이어에서 플러그인 형태로 교체 가능하게 만들었다. 카탈로그 관리와 결합하면 포맷 혁신(예: Parquet Variant)을 테이블 거버넌스와 독립적으로 도입할 수 있다.

Catalog Commits GA (2026)

Databricks가 Catalog Commits를 GA로 출시하여 카탈로그 관리 테이블의 실용성을 한 단계 끌어올림:

해결하는 3가지 문제

  1. Split-brain 제거: 모든 엔진이 카탈로그 API를 경유하여 테이블 상태와 카탈로그 메타데이터의 사일런트 드리프트 방지
  2. 멀티엔진 접근 스프롤 해소: 카탈로그가 발견·인가·감사의 단일 지점 → 물리적 경로 하드코딩 불필요
  3. 멀티테이블 ACID 트랜잭션: sales + inventory를 원자적으로 업데이트 — 기존 DWH에서만 가능했던 워크로드를 lakehouse에서 실행

에코시스템 지원

  • Delta Spark, Flink, Starburst Trino, DuckDB, StreamNative 등이 이미 지원
  • Delta Kernel 라이브러리로 외부 엔진 통합 간소화
  • delta.feature.catalogManaged = 'supported'로 테이블 단위 활성화

Delta와 Iceberg의 수렴

  • Catalog Commits로 Delta가 Iceberg의 카탈로그 지향 모델을 수용
  • 두 포맷 모두 “카탈로그가 테이블 접근을 중재”하는 공통 아키텍처로 수렴

생태계 현황 (2026)

구현상태
Delta Lake 4.1.0 + Unity Catalog 0.4.0GA — 첫 오픈 lakehouse 카탈로그 지원
Catalog Commits (Databricks)GA — 멀티테이블 트랜잭션, 멀티엔진 쓰기 지원
Apache Iceberg유사 접근으로 수렴 중

트레이드오프

측면카탈로그 관리파일시스템 관리
의존성카탈로그 서비스 가용성없음(파일시스템만)
성능직접 메타데이터 전달로 빠름다중 파일시스템 호출
거버넌스세밀한 통합 정책파편화·중복
단순성카탈로그 운영 필요파일시스템만으로 충분

Hive → Iceberg: 메타데이터 아키텍처로의 전환

Iceberg는 Parquet 대체가 아니라 데이터를 관리하는 방식의 근본적 차이다. 여전히 Parquet로 저장하되, 데이터 파일 위에 메타데이터 레이어(스키마, 파티션 정의, snapshot 이력, 파일 통계, 위치)를 둔다: Glue Catalog는 current metadata 파일 포인터만 → metadata.json → snapshot → manifest list → manifest files → Parquet.

Hive-style 데이터 레이크의 7가지 문제를 Iceberg가 해결하는 방식:

Hive 문제Iceberg 해결
디렉토리 file discovery(50,000 파일 = 50 S3 LIST)manifest의 file-level 통계로 pruning(파일 안 열고)
파티션이 폴더 구조에 결합파티션을 메타데이터에 분리(S3는 dumb store)
파티션 진화가 대량 rewritespec ID로 구 파일 그대로, 신 파일만 새 spec
reader가 partial write 관찰snapshot 기반 atomic commit
fragile 스키마 진화column ID(이름·위치 아닌 영구 정수)로 add/drop/rename, rewrite 없음
append 전용(update 어려움)Copy-on-Write(read 빠름) vs Merge-on-Read(write 빠름)
time travel 없음매 commit이 snapshot

새 운영 부담: small files 문제, 메타데이터 오버헤드 → compaction·manifest compaction·snapshot expiration·orphan cleanup 필요. control vs simplicity 트레이드오프(Self-Managed → Glue Maintenance → S3 Tables). 이 유지보수 부담은 Partition Sizing and Management·Distributed SQL Engine Operations의 multi-engine 라우팅에서 “테이블 최적화가 라우팅을 푼다”는 주제와 직결.

S3의 멀티모달 진화와 연계

AWS S3가 오브젝트 스토리지에서 멀티모달 데이터 플랫폼으로 진화하면서 카탈로그 관리 테이블과의 접점이 확대된다:

  • S3 Tables (2024): Iceberg 테이블을 관리형 프리미티브로 제공 — 카탈로그 관리의 S3 네이티브 구현
  • S3 Files (2026): 파일시스템과 오브젝트 스토리지를 “stage and commit” 모델로 양립
  • S3 Tables + 카탈로그 관리 테이블이 결합되면, 파일시스템 경로 의존성이 완전히 제거됨

자세한 내용은 Object Storage Evolution 참조.

연관 개념

Source: Delta Lake - The Next Evolution - Catalog-Managed Tables, Apache Iceberg - Introducing the File Format API, S3 Files and the Changing Face of S3, Catalog Commits GA, Why We Moved from Hive-Style Data Lakes to Apache Iceberg

그래프 뷰

백링크