증분 파이프라인 설계

증분 파이프라인은 마지막 처리 이후 바뀐 행이나 파일을 처리하여 반복 계산을 줄입니다. 데이터가 계속 늘고 대부분의 과거 데이터는 바뀌지 않는 입력에서 종단 간 지연과 연산 사용량을 줄일 수 있습니다. 대신 전체 재계산보다 입력 이력과 상태를 더 정확하게 이해해야 합니다.

트랜잭션을 기준으로 입력 해석

Foundry 데이터셋은 트랜잭션으로 변경됩니다. 수집 동기화와 변환이 어떤 트랜잭션을 만드는지 알아야 처리할 변경분을 정할 수 있습니다.

추가 전용 파이프라인에서는 보통 APPEND로 들어온 새 데이터를 처리합니다. 입력이 가끔 전체 재계산되어 SNAPSHOT으로 바뀔 수도 있으므로 이런 경우에도 결과가 정확해야 합니다. 증분 코드에 데코레이터를 붙이는 것만으로 전체 교체, 조인이나 집계의 정확성이 보장되지는 않습니다.

기본적인 비증분 전환을 지원하고 단위 테스트로 해당 경로를 확인하는 것이 권장됩니다. incremental API의 snapshot_inputs, require_incremental 같은 설정을 사용하면 예외 범위를 바꿀 수 있으므로 입력 변경이 기존 출력의 의미를 무효화하는지를 기준으로 선택합니다.

수집부터 증분으로 구성

상위 동기화가 매번 전체 스냅샷을 가져온 뒤 하위에서 변경분만 찾을 수도 있습니다. 다만 수집 단계의 비용은 여전히 남습니다. 증분 동기화로 원천에서 새 데이터만 가져오면 원천 시스템의 부하와 불필요한 저장을 함께 줄일 수 있습니다.

Pipeline Builder의 증분 계산 모드 또는 Python과 Java의 증분 API로 후속 변환을 구성할 수 있습니다. 데이터셋 트랜잭션의 의미는 데이터셋에서 확인할 수 있습니다.

장기간 실행할 때의 누적 상태

작은 추가 트랜잭션이 반복되면 데이터셋은 많은 작은 파일로 구성됩니다. Spark의 파일 읽기와 파티션 처리, 현재 뷰의 이력 해석이 점차 느려질 수 있으므로 새 데이터의 양만으로 처리 비용을 판단하지 않습니다.

성능 유지에서는 파일 수와 트랜잭션 수를 구분하고, 전체 스냅샷, 데이터셋 프로젝션, 보존 정책과 빈 출력 중단을 선택하는 기준을 설명합니다. Iceberg 테이블의 변경 로그와 행 단위 갱신은 Iceberg 증분 처리의 별도 계약을 적용합니다.