Foundry Iceberg 작업의 트랜잭션
Foundry 카탈로그가 관리하는 Iceberg 테이블을 Foundry 빌드 시스템의 작업(Job)에서 읽고 쓸 때는 작업 단위의 전체 성공 또는 전체 폐기 의미가 적용됩니다. 작업의 여러 테이블 쓰기를 함께 조정하므로 일부 출력만 갱신된 상태를 다른 소비자에게 노출하지 않습니다.
이 보장은 Foundry 빌드 시스템을 통하는 작업에 적용됩니다. 외부 클라이언트의 쓰기는 기본적으로 표준 Iceberg 클라이언트의 커밋 동작을 따릅니다. PyIceberg의 명시적 테이블 Transaction API가 존재하는 것과 Foundry가 작업 전체에 자동 적용하는 다중 테이블 보장은 구분해야 합니다.
작업 안의 보장
| 보장 | 의미 |
|---|---|
| All-or-nothing commits | 작업의 테이블 변경을 함께 커밋합니다. 중간에 실패하면 부분 쓰기가 다운스트림이나 다른 작업에 보이지 않습니다. |
| Repeatable reads | 작업 중 외부에서 입력을 갱신하더라도 같은 작업의 읽기 기준은 안정적으로 유지됩니다. |
| 자신의 쓰기 읽기 | 같은 작업에서 수행한 쓰기는 이후의 읽기에서 볼 수 있습니다. 다른 작업 및 외부 독자에게는 커밋 전까지 보이지 않습니다. |
| Multi-table snapshot isolation | 트랜잭션 시작 시 입력 테이블들의 일관된 스냅샷을 정합니다. 입력 버전과 출력 버전 사이의 데이터 계보도 이 기준으로 기록합니다. |
사용자가 별도로 켜야 하는 설정은 아닙니다. 이 범위의 읽기와 쓰기는 Foundry가 자동으로 트랜잭션에 포함합니다. 여러 작업으로 이루어진 파이프라인 전체나 외부 시스템 API 쓰기까지 하나의 트랜잭션이 된다는 뜻은 아닙니다.
두 출력 중간에서 실패하는 예
가상 파이프라인이 orders와 customers의 새 행을 읽어 조인한 뒤 order_summary와 customer_metrics에 추가한다고 가정합니다. 첫 출력에 쓰는 단계 이후, 두 번째 출력을 쓰기 전에 실패할 수 있습니다.
각 쓰기를 독립 커밋하는 일반 클라이언트 흐름이라면 첫 출력은 새 데이터를 반영하고 두 번째 출력은 이전 상태에 남습니다. 같은 입력을 다시 처리하면 첫 출력에 중복 추가가 생길 수도 있습니다.
Foundry 작업 트랜잭션에서는 첫 출력도 아직 커밋하지 않습니다. 두 출력은 이전 상태를 유지하고, 재시도할 때 새 데이터를 함께 기록합니다. 이 보장은 부분 커밋 때문에 생기는 불일치를 막는 것이며 입력 자체의 중복을 제거하는 기능은 아닙니다.
작업 대기열과 충돌
같은 출력에 쓰는 일반 파이프라인 작업은 대기열에서 순서대로 실행됩니다. 이 경로는 여러 작성자가 동시에 낙관적 커밋을 시도하는 표준 Iceberg 패턴과 다르게 동작합니다.
유지보수 작업은 일반 파이프라인 작업과 동시에 실행될 수 있습니다. 예를 들어 컴팩션이 진행 중인 작업의 테이블을 변경하면 그 작업의 커밋이 충돌할 수 있습니다. 이 경우 커밋이 실패하고 빌드 시스템이 작업을 다시 실행합니다. 정합성을 유지하지만 다시 계산하는 비용이 듭니다.
컴팩션을 자주 실행하는 테이블은 이런 재시도가 발생할 수 있으므로 유지보수 일정을 실제 빌드 패턴과 함께 계획합니다.