증분 처리 범위와 브랜치 오류
데이터셋의 현재 뷰는 마지막 SNAPSHOT부터 브랜치가 가리키는 최신 트랜잭션까지로 구성됩니다. 증분 입력은 그 전체 뷰 중 지난 처리 경계 이후의 구간을 계산에 사용합니다. 브랜치의 HEAD를 옮겨 이전에 처리한 구간이 현재 뷰에서 빠지면 두 구간을 비교할 수 없게 됩니다.
처리 구간과 현재 뷰
다음 숫자는 예제에서 트랜잭션을 구분하는 기호입니다. 실제 트랜잭션 ID의 숫자 크기로 시간순을 추론하는 규칙을 뜻하지 않습니다.
| 항목 | 예시 |
|---|---|
| 현재 뷰 | SNAPSHOT(1), UPDATE(2), UPDATE(3), UPDATE(4), UPDATE(5) |
| 마지막 처리 경계 | 트랜잭션 3 |
| 아직 처리하지 않은 구간 | 트랜잭션 4와 5 |
| 브랜치 HEAD | 트랜잭션 5 |
브랜치는 트랜잭션을 가리키는 포인터입니다. 여러 브랜치가 공통 이력을 공유하다가 서로 다른 후속 트랜잭션을 가질 수 있습니다. 새 코드 브랜치에서 빌드하면 기반 브랜치의 마지막 커밋을 이전 트랜잭션으로 보고 증분 계산을 이어갈 수 있습니다. 단순히 브랜치를 만들었다고 반드시 전체 입력을 다시 계산하지는 않습니다.
현재 뷰에 없는 트랜잭션
Catalog:TransactionsNotInView 또는 Catalog:TransactionNotInView 문구를 확인했다면 이전 처리 경계가 현재 뷰에 포함되는지 살펴봅니다.
예를 들어 지난 빌드가 3번까지 처리한 뒤, 입력 브랜치를 2번에서 갈라진 다른 이력으로 바꾸어 현재 뷰가 1, 2, 6, 7번이 되면 이전 처리 경계인 3번이 현재 뷰 밖에 있습니다. 증분 검사가 이전 범위와 새 범위의 파일 변경을 비교할 수 없어 오류가 발생합니다.
| 이전 상태 | 변경 후 상태 |
|---|---|
| 이전 처리 경계: 3 | 현재 HEAD: 7 |
| 이전 계보: 1, 2, 3, 4, 5 | 현재 계보: 1, 2, 6, 7 |
| 다음에 처리할 구간을 기존 계보에서 계산 | 3이 새 계보에 없어 범위 연결 불가 |
처리 경계보다 과거로 옮긴 HEAD
Catalog:InconsistentBranchesOrder는 마지막으로 처리한 prevTransaction보다 현재 endTransaction, 즉 HEAD가 앞선 이력을 가리킬 때 발생할 수 있습니다. 예를 들어 5번까지 처리했는데 HEAD가 3번으로 돌아간 경우입니다.
단순한 새 파일 추가 여부보다 먼저 트랜잭션 범위 자체의 순서와 계보가 유효해야 합니다.
원인과 복구
Catalog 엔드포인트로 HEAD를 직접 변경했거나 변환 작업 외부에서 데이터셋의 브랜치 이력을 변경한 작업이 있었는지 확인합니다. Code Workbook 브랜치 병합도 데이터셋 병합을 수반하지만, Workbook 데이터셋의 트랜잭션은 항상 SNAPSHOT이므로 이 증분 범위 불일치를 그대로 유발하는 경우와 구분합니다.
일반적인 복구 방법은 semantic version을 변경하여 변환을 스냅샷으로 실행하는 것입니다. 새 뷰와 처리 기준을 만들어 증분 검사를 다시 시작합니다. 다만 스냅샷을 누적한 이력 데이터셋은 현재 입력에서 과거 이력을 재생할 수 없으므로 먼저 보존할 이력과 복구 경로를 확인합니다.
수동 계보 복구가 필요한 경우 숙련된 담당자가 Catalog의 updateBranch2를 사용하여 HEAD가 이전 처리 범위 뒤에 이어지도록 조정할 수 있습니다. 이때 parentRef는 마지막으로 처리한 트랜잭션을 기준으로 지정합니다. 이 조작은 실제 데이터셋 이력을 바꾸므로 대상 브랜치와 처리 경계를 확인한 담당자가 수행해야 합니다.
일반적인 증분 불가 원인은 드라이버 로그의 transforms.api._incremental: Not running incrementally 경고와 작업의 트랜잭션 범위 보고서에서 확인합니다.