Retention 정책 실행과 삭제 단계
Retention은 모든 데이터셋을 반복 순회하며 각 정책을 각 트랜잭션에 평가합니다. 환경의 데이터셋 수에 따라 한 순회에 며칠이 걸릴 수 있습니다. 정책 저장 직후 모든 대상이 즉시 처리되는 방식은 아닙니다.
브랜치와 최신 view 보호
삭제 대상은 트랜잭션 단위로 정합니다. 브랜치마다 조건을 평가하지만 기본적으로 어느 브랜치에서든 최신 view에 포함된 트랜잭션은 보호합니다. 하나의 트랜잭션이 여러 브랜치에 존재할 수 있기 때문입니다.
여기서 view는 한 브랜치의 파일 상태를 구성하는 트랜잭션 집합이며, 여러 기반 데이터셋을 합쳐 읽는 View 리소스와는 다릅니다. 첫 view는 브랜치의 첫 트랜잭션부터 시작하고 이후 SNAPSHOT이 새 view를 시작합니다. 그 SNAPSHOT 뒤의 트랜잭션들은 새 최신 view에 속합니다. SNAPSHOT이 없는 브랜치에서는 첫 트랜잭션부터 계속 같은 view를 구성합니다.
가상 예시로 xyz가 abc의 T2에서 분기했다고 가정합니다.
| 브랜치 | 트랜잭션 이력 | 최신 view |
|---|---|---|
abc | T1(APPEND), T2(APPEND), T3(SNAPSHOT), T4(APPEND) | T3, T4 |
xyz | T1(APPEND), T2(APPEND), T5(APPEND) | T1, T2, T5 |
T1과 T2는 abc의 과거 view에 있지만 xyz의 최신 view에 있으므로 기본 정책으로 삭제 표시하지 않습니다. abc에서 오래되었다는 조건만 확인하고 공유 트랜잭션을 삭제하지 않습니다.
Advanced options의 Allow deletion from latest view를 켜면 이 보호를 해제할 수 있습니다. 현재 사용하는 데이터가 삭제되고 증분 빌드에 영향을 줄 수 있는 위험한 설정입니다. Python 증분 변환에서 보존 정책 삭제 때문에 스냅샷 실행으로 전환되는 것을 막으려면 @incremental(allow_retention=True)가 필요합니다. 이 옵션이 삭제된 입력을 복원하는 것은 아닙니다.
여러 정책이 같은 트랜잭션을 선택하면 먼저 실행된 정책이 처리하고 이후 정책은 이미 처리한 트랜잭션을 건너뜁니다. 정책 사이의 실행 순서에 의존해서 보호 조건을 구성하지 않습니다.
삭제 표시와 sweep
먼저 트랜잭션을 삭제 대상으로 표시합니다. 이 상태의 데이터는 언제든 제거될 수 있으므로 읽어서는 안 됩니다. 데이터셋 History에서 해당 트랜잭션을 선택하면 다음 메시지가 표시됩니다.
This transaction has been scheduled for deletion.
표시 이후 일정 기간이 지나면 sweep이 실제 데이터를 삭제합니다. 보통 약 7일이지만 환경에 따라 달라질 수 있습니다. Sweep 이후에는 복구할 수 없으며 History에는 다음 메시지가 표시됩니다.
Transaction data has been deleted.
잘못된 삭제 표시 대응
아직 sweep하지 않은 트랜잭션에는 데이터가 남아 있어 표시를 해제할 수 있습니다. 먼저 잘못 표시한 정책을 모두 수정하고 Palantir 담당자에게 지원을 요청합니다. 표시 후 7일 이내에 연락해야 하며 가능한 한 즉시 처리합니다. 이 기간을 복구가 보장되는 유예 기간으로 해석하면 안 됩니다. 실제 sweep이 시작된 뒤에는 데이터를 되돌릴 수 없습니다.
정책 자체를 비활성화하거나 삭제하는 것만으로 이미 적용한 삭제 표시가 자동 해제되지 않습니다.