LLM WikiAccess-protected knowledge portal

WIKI

Delta Lake 4.3 Catalog Commits: 카탈로그가 커밋을 중개하면서 달라진 멀티엔진 쓰기의 경계

왜 지금 이 변화를 봐야 하나 2026년 6월 22일 공개된 Delta Lake 4.3은 숫자 하나가 올라간 릴리스가 아니다. Delta Lake 초창기부터 이어온 파일시스템 기반 커밋 원자성 가정을 바꾸는 릴리스다. 그동안 Delta Lake의 모든 쓰기는 한 가지 전제 위에 돌아갔다. delta log/00000000000000000N.json 을 원자적으로 생성하는 능력을 스토리지 계층이 보장해준다는 전제다. S3의 강한

경로human/study/content/database-frontier/24-delta-lake-4-3-catalog-commits-coordinated-commits.md
카테고리Study
태그#catalog #commits #coordinated #lake #mysql #study

왜 지금 이 변화를 봐야 하나

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 구조

Delta Lake 4.3 Catalog Commits: 커밋 흐름 쓰기 엔진 (Writer) Delta Spark Delta Flink Starburst Trino DuckDB StreamNative 향후 엔진 (플러거블 CommitCoordinatorClient) Commit Coordinator (Unity Catalog) 모든 쓰기 의도를 수신 · 순서 부여 · 승인 또는 충돌 거부 커밋 의도 수신 registerTable / commit API 충돌 감지 · 승인 테이블 버전 단조 증가 보장 메타데이터 즉시 반영 카탈로그와 원자 업데이트 미백필 커밋 저장소 승인된 커밋이 backfill 전 임시로 보관되는 곳 리더는 여기서 최신 버전을 찾음 _delta_log (오브젝트 스토리지) 승인 후 N.json으로 백필 백필된 커밋은 저장소에서 삭제 가능 기존 리더 호환성 유지 Unity Catalog 메타데이터 테이블 최신 버전·위치 즉시 반영 스키마·제약 검증·ABAC 멀티 테이블 트랜잭션 경계 관리 오브젝트 스토리지 (S3 / GCS / ADLS) Parquet 데이터 파일 + _delta_log JSON (백필 완료분) 보관 커밋 원자성 보장 역할은 Unity Catalog로 이전됨 — 스토리지는 저장만 담당 📖 리더: 먼저 UC에서 최신 버전 조회 → 없으면 미백필 저장소 → 없으면 _delta_log 순서 탐색 백필된 커밋은 _delta_log에 있으므로 Catalog Commits 미지원 엔진도 읽기 가능 (하위 호환)
Delta Lake 4.3 Catalog Commits 아키텍처

핵심 개념: Coordinated Commits 프로토콜이 동작하는 방식

1단계: 테이블 등록

테이블이 Catalog Commits 모드로 전환되면 CommitCoordinatorClient.registerTable()을 호출해 코디네이터(Unity Catalog)에 등록한다. 코디네이터는 이 테이블의 커밋을 중재하겠다는 의사를 확인하고, 테이블 식별자와 현재 버전을 보관한다.

2단계: 쓰기 의도 제출

엔진이 새 버전(V+1)을 만들려면 다음 순서를 따른다.

  1. 데이터 파일을 스토리지에 미리 기록한다 (데이터 업로드).
  2. CommitCoordinatorClient.commit(tableId, V+1, actions) 를 호출한다.
  3. 코디네이터가 현재 최신 버전을 확인하고, V+1이 유효한지 검증한다.
  4. 충돌이 없으면 승인하고, 미백필 커밋 저장소에 V+1을 기록한다.
  5. 동시에 Unity Catalog 메타데이터를 원자적으로 갱신한다.

3단계: 백필 (Backfill)

승인된 커밋은 여전히 _delta_log/N.json으로 백필돼야 한다. 이는 Catalog Commits를 모르는 리더(기존 Spark, Presto 등)도 읽을 수 있게 하기 위함이다. AbstractBatchBackfillingCommitCoordinator가 이 작업을 배치로 처리한다.

백필이 완료되면 미백필 커밋 저장소에서 해당 항목을 제거한다. 이는 코디네이터가 무한히 커지지 않도록 한다.

4단계: 읽기

리더는 다음 순서로 최신 버전을 찾는다.

  1. Unity Catalog에 최신 버전 번호를 질의한다 (한 번의 API 호출).
  2. 해당 버전이 아직 백필 전이면 미백필 저장소에서 가져온다.
  3. 백필 완료분은 _delta_log에서 읽는다.

기존 방식(전체 _delta_log 파일 목록을 스캔해 최대 N을 찾는 것)에 비해 읽기 경로가 크게 단축된다.

Split-Brain 문제가 사라지는 이유

기존 구조에서 split-brain은 이렇게 발생했다.

Catalog Commits에서는 커밋이 Unity Catalog를 통하지 않으면 성공하지 않는다. 코디네이터가 커밋을 승인하는 동시에 카탈로그 메타데이터를 갱신하기 때문에, 카탈로그가 보는 버전과 실제 데이터가 항상 일치한다.

멀티 테이블 트랜잭션: 이전에 불가능했던 것

기존 Delta Lake는 단일 테이블 ACID는 강력했지만, 두 테이블을 원자적으로 동시에 업데이트하는 것은 불가능했다. Catalog Commits는 이 경계를 넘는다.

Unity Catalog가 커밋을 중재하기 때문에, 여러 테이블에 대한 커밋을 하나의 트랜잭션 경계 안에서 처리할 수 있다. 예를 들면 다음과 같다.

이 기능은 2026년 현재 Unity Catalog Databricks 환경에서 지원되며, OSS Unity Catalog로 확장 중이다.

엔진별 지원 현황과 제약

엔진Catalog Commits 쓰기비고
Delta Spark (4.x)GA권장 진입점
Delta FlinkGAStreaming + CDF도 지원
Starburst TrinoGA읽기/쓰기 모두
DuckDB (1.2+)GAdelta_scan() 및 쓰기
StreamNativeGAKafka 기반 스트리밍 파이프라인
Presto / 구형 Spark읽기 전용백필된 _delta_log 읽기 가능

중요: Catalog Commits를 모르는 구형 엔진도 백필된 _delta_log를 읽을 수 있다. 따라서 읽기 하위 호환성은 유지된다. 단, 구형 엔진으로 쓰기를 허용하면 코디네이터를 거치지 않아 데이터 손상 위험이 있다. 운영 정책으로 카탈로그 기반 테이블에 대한 직접 스토리지 쓰기를 차단해야 한다.

운영자가 판단해야 할 마이그레이션 기준

기존 테이블을 Catalog Commits로 전환하는 조건

다음 중 하나라도 해당되면 전환을 검토한다.

전환 전 확인 사항

전환 명령 (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 장애 시 쓰기가 차단된다. 기존 방식은 스토리지만 살아 있으면 쓸 수 있었다.

쓰기 지연 증가 가능성: 커밋마다 Unity Catalog API 호출이 추가된다. 로컬 처리량이 높은 마이크로배치 파이프라인에서는 이 API 레이턴시가 병목이 될 수 있다.

운영 단순화: 반대로 MSCK REPAIR TABLE, 메타데이터 동기화 크론 작업, split-brain 감지 로직 같은 기존 운영 부담이 사라진다.

이 릴리스를 한 문장으로

Delta Lake 4.3 Catalog Commits는 스토리지가 중재하던 커밋을 카탈로그가 중재하도록 바꾸면서, 멀티엔진 동시 쓰기와 카탈로그 일관성이라는 두 문제를 구조적으로 해결했다. 다만 카탈로그를 쓰기 경로에 넣는 순간 카탈로그 가용성이 곧 파이프라인 가용성이 된다는 점을 운영 설계에 반드시 반영해야 한다.

References