Catalog-Managed Tables
카탈로그를 테이블 ID·발견·접근 제어의 권위 있는 시스템으로 활용하는 lakehouse 거버넌스 패턴
핵심 개념
카탈로그 관리 테이블은 파일시스템 경로 기반의 전통적 테이블 관리에서 벗어나, 카탈로그가 테이블의 논리적 신원(identity), 메타데이터 저장, 동시성 제어, 커밋 비준(ratification)을 담당하는 아키텍처다. Delta Lake 4.1.0과 Apache Iceberg가 각각 이 패턴을 도입하면서 오픈 lakehouse 에코시스템의 공통 기반이 되고 있다.
왜 파일시스템 기반 테이블이 문제인가
전통적 Delta/Iceberg 테이블의 4가지 운영 문제:
- 경로 의존성: 앱이 물리적 스토리지 위치에 결합되어 인프라 재편 시 취약
- 거친 인가 제어: 파일시스템 ACL은 세밀한 권한 제어 불가 → 프라이버시 요구 시 데이터 복제·단편화
- 미검증 스키마 변경: 스토리지 자격증명이 쓰기 권한과 메타데이터 수정 권한을 구분 못함
- 성능 오버헤드: 테이블 상태 복원에 파일시스템 다중 호출 필요 → 쿼리당 100ms+ 추가
카탈로그 관리 테이블의 작동 방식
테이블 발견
클라이언트가 카탈로그에 논리적 3단계 네임스페이스(catalog.schema.table)로 테이블을 질의 → 카탈로그가 물리적 위치와 접근 규칙 반환
읽기 경로
- 카탈로그 API에서 미발행(unpublished) 커밋 조회
- 발행된 파일시스템 커밋과 병합하여 완전한 스냅샷 구성
쓰기 경로
- 라이터가 카탈로그에 커밋 제안(staged 또는 inline)
- 카탈로그가 유효성 검증 후 비준 → 파일시스템 PUT-if-absent 대체
- 동시성 충돌을 파일시스템이 아닌 카탈로그가 조정
Apache Iceberg File Format API와의 연계
Iceberg는 File Format API를 통해 Parquet, ORC, Avro 등 스토리지 포맷을 테이블 포맷 레이어에서 플러그인 형태로 교체 가능하게 만들었다. 카탈로그 관리와 결합하면 포맷 혁신(예: Parquet Variant)을 테이블 거버넌스와 독립적으로 도입할 수 있다.
생태계 현황 (2026)
| 구현 | 상태 |
|---|---|
| Delta Lake 4.1.0 + Unity Catalog 0.4.0 | GA — 첫 오픈 lakehouse 카탈로그 지원 |
| Apache Iceberg | 유사 접근으로 수렴 중 |
트레이드오프
| 측면 | 카탈로그 관리 | 파일시스템 관리 |
|---|---|---|
| 의존성 | 카탈로그 서비스 가용성 | 없음(파일시스템만) |
| 성능 | 직접 메타데이터 전달로 빠름 | 다중 파일시스템 호출 |
| 거버넌스 | 세밀한 통합 정책 | 파편화·중복 |
| 단순성 | 카탈로그 운영 필요 | 파일시스템만으로 충분 |
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