Delta Lake 4.3 Catalog Commits: 카탈로그가 커밋을 중개하면서 달라진 멀티엔진 쓰기의 경계
왜 지금 이 변화를 봐야 하나
2026년 6월 22일 공개된 Delta Lake 4.3은 숫자 하나가 올라간 릴리스가 아니다. Delta Lake 초창기부터 이어온 파일시스템 기반 커밋 원자성 가정을 바꾸는 릴리스다.
그동안 Delta Lake의 모든 쓰기는 한 가지 전제 위에 돌아갔다. _delta_log/00000000000000000N.json을 원자적으로 생성하는 능력을 스토리지 계층이 보장해준다는 전제다. S3의 강한 일관성(2020년 이후), HDFS의 원자적 rename, GCS의 조건부 PUT이 그 보장을 제공했다.
이 구조의 문제는 두 가지였다.
첫째, 카탈로그와 스토리지 사이의 분리(split-brain). Spark가 S3에 새 버전을 기록해도, Databricks Unity Catalog 같은 메타스토어는 그 사실을 알지 못한다. 카탈로그에서 보는 최신 버전과 _delta_log에 기록된 버전이 달라질 수 있고, 이를 동기화하려면 주기적인 메타데이터 동기화나 우회 로직이 필요했다.
둘째, 멀티엔진 동시 쓰기의 한계. Spark와 Flink가 같은 테이블에 동시에 쓸 때, 두 엔진은 스토리지의 원자성에만 의존해 충돌을 감지한다. 스케일이 커질수록 커밋 재시도가 쌓이고, 처리량 한계가 낮아졌다.
Delta Lake 4.3의 Catalog Commits는 이 두 문제를 동시에 건드렸다. 커밋의 중재자를 스토리지에서 카탈로그로 옮기는 것이 이 릴리스의 핵심이다.
예전 방식과 새 방식 비교
| 항목 | 기존 (_delta_log 기반) | Catalog Commits |
|---|---|---|
| 커밋 원자성 보장 주체 | 스토리지 계층 (S3/GCS/HDFS) | 카탈로그 (Unity Catalog) |
| 최신 버전 위치 | _delta_log/N.json (파일) | 카탈로그 메타데이터 + 미백필 커밋 저장소 |
| 카탈로그 메타데이터 동기화 | 주기적 sync 또는 MSCK REPAIR | 커밋과 동시에 원자 업데이트 |
| 멀티 테이블 트랜잭션 | 불가 | 지원 (UC 기반) |
| 지원 엔진 | 모든 Delta 엔진 | Delta Spark, Delta Flink, Trino, DuckDB, StreamNative |
| 리더 위치 탐색 | _delta_log 순서 탐색 | 카탈로그 API로 즉시 반환 |
전체 아키텍처: Coordinated Commits 구조
핵심 개념: Coordinated Commits 프로토콜이 동작하는 방식
1단계: 테이블 등록
테이블이 Catalog Commits 모드로 전환되면 CommitCoordinatorClient.registerTable()을 호출해 코디네이터(Unity Catalog)에 등록한다. 코디네이터는 이 테이블의 커밋을 중재하겠다는 의사를 확인하고, 테이블 식별자와 현재 버전을 보관한다.
2단계: 쓰기 의도 제출
엔진이 새 버전(V+1)을 만들려면 다음 순서를 따른다.
- 데이터 파일을 스토리지에 미리 기록한다 (데이터 업로드).
CommitCoordinatorClient.commit(tableId, V+1, actions)를 호출한다.- 코디네이터가 현재 최신 버전을 확인하고, V+1이 유효한지 검증한다.
- 충돌이 없으면 승인하고, 미백필 커밋 저장소에 V+1을 기록한다.
- 동시에 Unity Catalog 메타데이터를 원자적으로 갱신한다.
3단계: 백필 (Backfill)
승인된 커밋은 여전히 _delta_log/N.json으로 백필돼야 한다. 이는 Catalog Commits를 모르는 리더(기존 Spark, Presto 등)도 읽을 수 있게 하기 위함이다. AbstractBatchBackfillingCommitCoordinator가 이 작업을 배치로 처리한다.
백필이 완료되면 미백필 커밋 저장소에서 해당 항목을 제거한다. 이는 코디네이터가 무한히 커지지 않도록 한다.
4단계: 읽기
리더는 다음 순서로 최신 버전을 찾는다.
- Unity Catalog에 최신 버전 번호를 질의한다 (한 번의 API 호출).
- 해당 버전이 아직 백필 전이면 미백필 저장소에서 가져온다.
- 백필 완료분은
_delta_log에서 읽는다.
기존 방식(전체 _delta_log 파일 목록을 스캔해 최대 N을 찾는 것)에 비해 읽기 경로가 크게 단축된다.
Split-Brain 문제가 사라지는 이유
기존 구조에서 split-brain은 이렇게 발생했다.
- Spark가
_delta_log/00000000000000000010.json을 S3에 기록했다. - 카탈로그(예: Hive Metastore)는 이를 모른다. 카탈로그는 여전히 버전 9를 가리키고 있다.
- 다른 엔진이 카탈로그를 통해 테이블을 읽으면 버전 9를 보게 된다.
- 두 뷰가 달라지는 split-brain.
Catalog Commits에서는 커밋이 Unity Catalog를 통하지 않으면 성공하지 않는다. 코디네이터가 커밋을 승인하는 동시에 카탈로그 메타데이터를 갱신하기 때문에, 카탈로그가 보는 버전과 실제 데이터가 항상 일치한다.
멀티 테이블 트랜잭션: 이전에 불가능했던 것
기존 Delta Lake는 단일 테이블 ACID는 강력했지만, 두 테이블을 원자적으로 동시에 업데이트하는 것은 불가능했다. Catalog Commits는 이 경계를 넘는다.
Unity Catalog가 커밋을 중재하기 때문에, 여러 테이블에 대한 커밋을 하나의 트랜잭션 경계 안에서 처리할 수 있다. 예를 들면 다음과 같다.
orders테이블과inventory테이블을 동시에 업데이트하는 주문 처리 파이프라인- 원본 테이블과 집계 테이블을 원자적으로 교체하는 ETL 패턴
이 기능은 2026년 현재 Unity Catalog Databricks 환경에서 지원되며, OSS Unity Catalog로 확장 중이다.
엔진별 지원 현황과 제약
| 엔진 | Catalog Commits 쓰기 | 비고 |
|---|---|---|
| Delta Spark (4.x) | GA | 권장 진입점 |
| Delta Flink | GA | Streaming + CDF도 지원 |
| Starburst Trino | GA | 읽기/쓰기 모두 |
| DuckDB (1.2+) | GA | delta_scan() 및 쓰기 |
| StreamNative | GA | Kafka 기반 스트리밍 파이프라인 |
| Presto / 구형 Spark | 읽기 전용 | 백필된 _delta_log 읽기 가능 |
중요: Catalog Commits를 모르는 구형 엔진도 백필된 _delta_log를 읽을 수 있다. 따라서 읽기 하위 호환성은 유지된다. 단, 구형 엔진으로 쓰기를 허용하면 코디네이터를 거치지 않아 데이터 손상 위험이 있다. 운영 정책으로 카탈로그 기반 테이블에 대한 직접 스토리지 쓰기를 차단해야 한다.
운영자가 판단해야 할 마이그레이션 기준
기존 테이블을 Catalog Commits로 전환하는 조건
다음 중 하나라도 해당되면 전환을 검토한다.
- Spark와 Flink가 동일 테이블에 동시에 쓰고 있다 (커밋 충돌이 자주 발생한다).
- Hive Metastore와 _delta_log 사이의 버전 불일치로
MSCK REPAIR TABLE을 주기적으로 실행 중이다. - 멀티 테이블 원자 업데이트가 필요한 비즈니스 요구가 있다.
- 테이블 크기가 커져 최신 버전 탐색 쿼리 플래닝 시간이 길어졌다.
전환 전 확인 사항
- [ ] 해당 테이블에 접근하는 모든 엔진의 버전을 확인한다. Catalog Commits 지원 여부를 엔진별로 검증한다.
- [ ] 구형 쓰기 엔진이 있다면 먼저 읽기 전용 모드로 전환하거나 업그레이드 계획을 세운다.
- [ ] Unity Catalog 버전이 GA 요건을 충족하는지 확인한다. OSS UC를 자체 운영 중이라면 지원 범위가 다를 수 있다.
- [ ] 전환 전
DEEP CLONE또는 스냅샷으로 백업한다. 전환 중 실패 시 롤백 계획을 갖춰라.
전환 명령 (Databricks 환경 기준)
-- Catalog Commits 활성화 (관리형 Delta 테이블)
ALTER TABLE my_catalog.my_schema.my_table
SET TBLPROPERTIES ('delta.coordinatedCommits.coordinatorName' = 'unity-catalog');
-- 현재 커밋 코디네이터 확인
DESCRIBE DETAIL my_catalog.my_schema.my_table;전환 후 모니터링 포인트
- [ ] 커밋 지연 증가 여부를 모니터링한다. Unity Catalog API 호출이 추가되므로 p99 쓰기 지연이 소폭 오를 수 있다.
- [ ] 미백필 커밋 저장소 크기를 관찰한다. 백필이 지연되면 저장소 항목이 누적된다.
- [ ] 카탈로그 API 오류율을 알림에 포함한다. 코디네이터 장애는 쓰기 전체에 영향을 미친다.
주의해야 할 트레이드오프
가용성 의존성 추가: 카탈로그가 커밋을 중재하므로, Unity Catalog 장애 시 쓰기가 차단된다. 기존 방식은 스토리지만 살아 있으면 쓸 수 있었다.
쓰기 지연 증가 가능성: 커밋마다 Unity Catalog API 호출이 추가된다. 로컬 처리량이 높은 마이크로배치 파이프라인에서는 이 API 레이턴시가 병목이 될 수 있다.
운영 단순화: 반대로 MSCK REPAIR TABLE, 메타데이터 동기화 크론 작업, split-brain 감지 로직 같은 기존 운영 부담이 사라진다.
이 릴리스를 한 문장으로
Delta Lake 4.3 Catalog Commits는 스토리지가 중재하던 커밋을 카탈로그가 중재하도록 바꾸면서, 멀티엔진 동시 쓰기와 카탈로그 일관성이라는 두 문제를 구조적으로 해결했다. 다만 카탈로그를 쓰기 경로에 넣는 순간 카탈로그 가용성이 곧 파이프라인 가용성이 된다는 점을 운영 설계에 반드시 반영해야 한다.
References
- Delta Lake 4.3 릴리스 블로그 (2026-06-22): https://delta.io/blog/2026-06-22-delta-4-3-release/
- Databricks Catalog Commits GA 블로그: https://www.databricks.com/blog/convergence-open-table-formats-and-open-catalogs-catalog-commits-generally-available
- Delta Coordinated Commits 공식 문서 (3.2.1): https://docs.delta.io/3.2.1/delta-coordinated-commits.html
- Databricks Catalog Commits 운영 문서 (AWS): https://docs.databricks.com/aws/en/delta/catalog-commits
- Delta Lake 4.3 + DuckDB: Delta Grows Up (DuckDB 블로그, 2026-05-07): https://duckdb.org/2026/05/07/delta-uc-updates
- Coordinated Commits Protocol 설계 (GitHub Issue #2598): https://github.com/delta-io/delta/issues/2598
- Data + AI Summit 2026 Unity Catalog 발표: https://www.databricks.com/blog/whats-new-unity-catalog-data-ai-summit-2026
- Delta Lake Coordinated Commits DeepWiki: https://deepwiki.com/delta-io/delta/4.4-coordinated-commits-and-catalog-integration