Iceberg Scan Planning, Optimistic Concurrency, Sequence Numbers

Scan Planning

• 스캔 계획 = snapshot의 manifest 파일 읽기로 시작.
• 삭제된 엔트리(DELETED) → 스캔에 포함되지 않음.
• 최적화 기법
  1. 불필요한 manifest 스킵
     • partition summary, file count 이용.
  2. Predicate pushdown
     • row-level filter → partition-level filter 변환 (inclusive projection).
     • 예: ts > X → ts_day >= day(X). (일부 row는 매칭 안 돼도 포함될 수 있음 → inclusive).
  3. 파일 메트릭 활용
     • min/max 값 기반으로 data/delete file prune 가능.
• Delete 파일 적용 규칙
  • DV(Deletion Vector): 동일 partition + 동일/이전 seq-number.
  • Position delete: 파일 경로 + position 일치해야 적용.
  • Equality delete: partition 동일 + data file seq-number < delete seq-number.

Optimistic Concurrency

• Iceberg의 트랜잭션 모델은 낙관적 동시성 제어(Optimistic Concurrency Control).
• 기본 원리
  • Reader → 특정 시점의 snapshot을 읽고, 변경이 있어도 refresh 전까지 영향받지 않음.
  • Writer → 새로운 snapshot 메타데이터 파일 생성 후 교체 시도.
  • 만약 동시에 커밋이 일어나면, 실패한 writer는 재시도(retry) 해야 함.
• 격리 수준(Isolation level) 은 writer가 어떤 조건을 검증하는지에 따라 달라짐.
  • 예: “이 파일들이 아직 테이블에 남아 있는지 확인 후 삭제” → higher isolation

Commit Conflict Resolution and Retry

• 동시 커밋 처리
  • 같은 메타데이터 버전을 기반으로 두 커밋이 동시에 발생하면 하나만 성공.
  • 실패한 커밋은 최신 버전에 재적용 후 retry 가능.
• 조건
  • Append: 조건 없음 → 항상 적용 가능.
  • Replace: 삭제하려는 파일이 여전히 존재하는지 확인 필요.
  • Delete: 삭제 대상 파일이 여전히 존재하는지 확인 필요. (조건 기반 delete는 항상 가능)
  • Schema / Partition Spec 변경: 현재 버전에서 스키마가 변하지 않았는지 검증 필요.

Sequence Numbers

• Iceberg는 각 commit에 sequence number를 부여하여 데이터/삭제 파일의 “연령” 추적.
• 구조
  • Commit 성공 시 → 새로운 snapshot이 sequence number 획득.
  • 이 번호는 snapshot뿐 아니라 그 snapshot이 가진 데이터 파일, 매니페스트 파일에 상속됨.
• 의미
  • 순서 보장: 어떤 파일이 먼저 들어왔는지 추적 가능.
  • 재시도 지원: 실패 후 다시 커밋할 때, 매니페스트 전체를 다시 쓰지 않아도 됨 → manifest list만 업데이트하면 됨.

참조

• https://iceberg.apache.org/spec/