점진적 변환은 파이프라인 업데이트 시 새로운 행만 처리하여 리소스 사용을 최소화하는 데 도움이 됩니다. Foundry에서 점진적 변환은 데이터셋에 새로운 행을 추가할 수만 있고 행을 교체하거나 제거할 수는 없습니다. 데이터 수집의 경우도 마찬가지일 수 있습니다. 각 실행은 일반적으로 작은 양의 데이터를 처리하므로 이러한 추가 사항은 작지만, 활성 뷰를 렌더링할 때 모두 고려해야 합니다.
일반적으로 이것은 괜찮지만, 수십 또는 수백만 개의 작은 업데이트가 축적된 경우(주파수에 따라 중단되지 않고 주간 또는 월간 빌드된 경우) 읽기 성능이 저하될 수 있습니다. 이 문제는 아래에서 설명한 것과 같이 여러 관련 요소로 인해 발생할 수 있습니다.
데이터셋에 너무 많은 파일이 있으면 현재 뷰의 데이터에 액세스하는 백엔드 요청에서 느려집니다. 이로 인해 미리보기 불가능 문제, Contour 실패, 특히 Python Transforms와 같은 Transforms에서 심각한 느려짐이 발생할 수 있습니다. 이는 해당 언어 환경에서 파일을 로드하는 데 특별한 오버헤드가 있기 때문입니다.
시간이 지남에 따라 활성 데이터셋 뷰와 관련된 모든 작업은 비효율적인 데이터 읽기로 지배됩니다. 따라서 처음에는 몇 분 이내에 실행되던 변환 작업이 몇 시간 또는 몇 일이 걸릴 수 있습니다. 극단적인 경우 백엔드 요청이 시간 초과되어 빌드가 실패할 수도 있습니다.
많은 파일과 마찬가지로 뷰에 너무 많은 트랜잭션이 있는 경우 느려질 수 있습니다. 그러나 이 느려짐은 파일이 요청되는 경우뿐만 아니라 뷰 범위가 해결될 때마다 발생하며, 이는 통계 계산, 기록 로드 등의 데이터셋 기능에 영향을 줄 수 있습니다. 변환 작업에서 이 느려짐은 환경이 설정되기 전, Spark 세부 정보를 사용할 수 없는 전처리 단계에서 나타납니다. 이로 인해 문제가 디버그하기 어려울 수 있습니다.
일반적으로 트랜잭션은 파일과 함께 축적되지만, 경우에 따라 빈 트랜잭션이 파일 수가 상대적으로 적더라도 문제를 일으킬 수 있습니다. 반대로 상대적으로 적은 트랜잭션 수가 각 트랜잭션에 많은 파일이 포함되어 있으면 파일 수가 많아질 수 있습니다.
점진적 파이프라인을 고성능으로 유지하는 가장 간단하고, 경우에 따라 가장 효과적인 방법은 정기적인 스냅샷을 실행하는 것입니다. 스냅샷은 전체 데이터를 다시 처리하고 결과물을 효율적으로 분할할 수 있는 새로운 뷰로 교체합니다. 스냅샷 작업은 계산이 많이 필요한 작업이므로 일반 처리보다 점진적 처리가 종종 선호되지만, 가끔 스냅샷을 찍어 동일한 뷰에 파일이나 트랜잭션의 과도한 축적을 방지할 수 있습니다. 스냅샷 빈도를 결정할 때, 관리자는 읽기 및 쓰기 데이터 성능을 균형 있게 유지해야 합니다.
스냅샷 트랜잭션은 연쇄 효과가 있으며, 스냅샷이 찍힌 입력을 사용하는 각 점진적 변환은 스냅샷 자체를 찍습니다. 점진적 변환을 직접 스냅샷 실행으로 강제할 필요 없이, 변환의 입력 중 하나를 스냅샷하고 Transforms 애플리케이션이 점진적 변환에도 스냅샷이 필요하다고 판단하도록 합니다. 따라서 점진적 파이프라인을 정기적으로 스냅샷할 수 있는 유용한 방법은 원하는 스냅샷 일정에 따라 빌드되는 더미 입력을 설정하고 더미 입력을 항상 스냅샷 모드로 실행하도록 하는 것입니다.
정기적인 스냅샷에는 아래와 같이 몇 가지 단점이 있습니다:
점진적 빌드를 처리하는 가장 추천하는 방법은 관련 데이터셋에 데이터셋 투영을 추가하는 것입니다. 데이터셋 투영은 데이터셋에서 데이터를 쿼리하기 위한 대체 메커니즘을 제공하며, 기본 데이터셋과 독립적으로 저장 및 업데이트됩니다. 이러한 특성으로 인해 데이터셋 투영은 점진적 계산의 추가 전용 모델에서 벗어나서 내부 데이터 표현을 자동으로 재구성할 수 있습니다. 이를 압축이라고 합니다. 압축은 프로젝션에서 파일이나 트랜잭션이 기본 데이터셋에 얼마나 많이 있는지에 관계없이 항상 읽기 성능이 좋게끔 합니다.
이는 특히 점진적 파이프라인에서 유용한데, 이는 데이터셋 투영이 기본 데이터셋과 완전히 동기화되지 않아도 독자가 성능 향상을 누릴 수 있기 때문입니다. 모든 Foundry 제품은 투영에서 가져온 데이터와 기본 데이터셋에서 가져온 데이터를 결합하여 투영이 없는 경우와 같은 뷰를 재구성하는 방법을 알고 있습니다. 예를 들어 데이터셋에 점진적 트랜잭션이 100개 있고 처음 99개로 구축된 투영이 있는 경우 99개는 투영에서 읽고 데이터셋에서 하나만 읽습니다. 따라서 데이터셋 투영을 일일이 또는 주간으로 업데이트하는 것이 일반적으로 충분하며, 이로 인해 유지 관리 비용이 매우 저렴해집니다.
데이터셋 투영은 기본 데이터셋과 별개의 리소스이므로 기본 데이터셋이 빌드 중인 경우에도 언제든지 빌드할 수 있습니다(반대로도 마찬가지입니다). 독자는 유효한 트랜잭션에 따라 현재 상태를 사용할 것입니다. 예를 들어 데이터셋이 트랜잭션 10을 빌드하고 있고 투영이 동시에 시작된 경우, 투영은 트랜잭션 9에서 읽습니다. 이 시나리오에서 데이터를 쿼리하는 독자는 트랜잭션 1-8을 투영에서, 9를 데이터셋에서 읽어, 데이터셋을 직접 읽는 것과 마찬가지로 동일한 데이터를 볼 수 있습니다.
데이터셋 투영의 단점은 다음과 같습니다:
파이프라인의 유즈케이스가 영원히 플랫폼에서 이력 데이터를 유지할 필요가 없고 최근 트랜잭션만 유지해도 괜찮은 경우, Foundry Retention을 사용하여 자동으로 처리할 수 있습니다. 이 경우 변환 로직이 교차 트랜잭션 종속성(집계 또는 차등 계산과 같은)을 포함하지 않는 한 점진적 파이프라인을 특별한 고려 사항 없이 구축할 수 있습니다. Python Transforms에서는 점진적 데코레이터에 allow_retention 플래그를 설정해야 합니다(그렇지 않으면 DELETE 트랜잭션은 스냅샷 실행을 트리거합니다).
보존 정책 변경의 단점은 다음과 같습니다:
어떤 상황에서는 파일이 없거나 빈 파일만 있는 트랜잭션이 커밋됩니다. 이러한 트랜잭션은 뷰에 영향을 주지 않지만 유효한 업데이트로 간주되며 스케줄 및 관련된 모든 부작용을 트리거할 수 있습니다. 이로 인해 계산이 낭비될 수 있습니다. 빈 트랜잭션은 파일 및 트랜잭션 수를 크게 늘릴 수 있습니다.
빈 트랜잭션은 일반적으로 Data Connection 동기화와 같은 소스에서 피하는 것이 가장 좋습니다. Data Connection은 항상 파일이 없는 트랜잭션을 중단하지만 빈 파일은 여전히 생성될 수 있습니다. 빈 트랜잭션은 사용자 정의 플러그인에서 특히 문제가 될 수 있습니다. 때로는 빈 트랜잭션을 피하기 위해 플러그인을 수정할 수 없는 경우가 있습니다(예: 비어 있지 않은 트랜잭션이 Data Connection 점진적 메타데이터를 업데이트하는 데 필요한 경우). 다른 경우에는 변환 작업 또는 기타 수단으로 파일이 없는 트랜잭션이 커밋될 수 있습니다.
이러한 빈 또는 파일이 없는 트랜잭션의 영향을 최소화하기 위해 파이프라인에서 가장 상류 변환에서 명시적으로 트랜잭션을 중단할 수 있습니다. 빈 입력을 받거나 빈 출력을 얻게 되면 출력 객체에서 .abort()를 호출할 수 있습니다. 이렇게 하면 작업이 중단되고 트랜잭션도 중단됩니다. 중단된 트랜잭션은 취소된 것으로 간주되며 스케줄을 트리거하거나 부작용을 일으키지 않습니다. 트랜잭션을 중단하면 체인이 끊어지고 파이프라인에서 빈 트랜잭션을 전파하지 않습니다. 또한 트랜잭션 중단은 실패 통계에 기여하지 않습니다(빌드 실패를 고의로 유도하면 실패 통계에 기여합니다).
중단된 빌드는 성공적인 것으로 간주되며 입력 트랜잭션 포인터를 전진시킵니다. 따라서 비어 있지 않은 입력으로 중단하면 데이터가 버려집니다. 이는 빌드를 다른 이유로 중단하려는 경우 원하지 않을 수 있습니다(예: 실패한 전제 조건).
변경 내역 로직을 사용하면 추가 전용 트랜잭션에서 편집 의미 체계를 구현할 수 있으므로 점진적 파이프라인에서 조인 및 집계를 신뢰성 있게 수행할 수 있습니다. 그러나 이전에 언급한 파일 및 트랜잭션 수 문제 외에도 추가 전용 트랜잭션에서 편집 의미 체계를 구현하면 행 수가 제한 없이 늘어나 변환 성능이 점점 더 나빠질 수 있습니다. 상태 결정 단계에 도달할 때(또는 독립 실행 스냅샷이 필요한 경우)입니다.
이러한 파이프라인의 행 수를 제어하는 것은 조금 까다롭습니다. 스냅샷이 가능하며, 부분 상태가 있는 중간 변환 작업에서 많은 도움이 될 수 있습니다(완전한 재빌드에서는 대부분 사라집니다). 그러나 스냅샷의 이점을 최대한 활용하려면 로직이 행을 최신 상태로 축소해야 하며, 이는 항상 바람직하지 않습니다(어떤 경우에는 특정 시점의 행 상태를 파악하려는 것이 아니라 최신 상태만을 원할 수 있습니다). 데이터셋 투영은 어느 정도 도움이 될 수 있습니다. 그리고 행이 원자 단위가 아닌 경우 보존 정책은 원하는 효과를 내지 못할 수 있습니다(예: 일치하지 않는 시작 이벤트가 없는 종료 이벤트가 발생할 수 있음). 따라서 이러한 파이프라인을 설계할 때 특별한 주의가 필요합니다.