파이프라인 저장, 배포와 빌드
저장은 편집 중인 파이프라인을 기록합니다. 배포는 출력에 적용할 변환 로직을 갱신하고, 빌드는 그 로직을 실행하여 데이터를 만듭니다. 큰 입력을 다시 처리하는 빌드는 시간과 컴퓨팅 자원이 많이 필요하므로 일부 출력은 로직만 배포하고 빌드를 나중에 수행할 수 있습니다.
변경 전달
변환과 출력 스키마의 오류를 해결한 뒤 위쪽 도구 모음의 Deploy를 선택합니다.
Build settings에서 배포 후 빌드할 출력을 선택합니다. 빌드 단위는 job group입니다. 그룹에 속한 출력은 그룹 전체를 빌드하고, 그룹에 없는 출력은 Single ungrouped jobs에서 각각 선택합니다.
온톨로지 유형 출력은 항상 빌드해야 합니다. 따라서 온톨로지 출력을 포함한 job group도 빌드 대상에서 제외할 수 없습니다.
배포를 시작하면 그래프 위에 파란 배너가 나타납니다. View를 선택하여 Build details를 엽니다.
| 항목 | 확인할 정보 |
|---|---|
| Build info | 상태, 총 소요 시간, 예상 시간, 시작 및 종료 시각, 시작한 사용자, job 목록의 진행도와 빌드 ID입니다. |
| Build progress | 시간에 따른 빌드 진행을 Gantt 차트로 표시합니다. |
| Build schedule | 스케줄 이름, 주기, 상태 이력과 마지막 수정일입니다. |
| Progress details | Starting, 프로젝트 자원 큐 대기, Spark 애플리케이션 초기화, Running, Finishing 등 실행 단계를 보여 줍니다. |
상태를 깨뜨리는 변경이 있으면 배포 이벤트의 작업 행에 변경 감지 여부와 선택한 replay 전략도 표시됩니다.
컴퓨팅 설정
Deploy 옆의 설정 아이콘에서 프로필을 선택합니다.
| 프로필 | 특성 |
|---|---|
| Default | 기본 자동 확장 프로필입니다. 실행기 코어와 메모리 사용량이 가장 작습니다. |
| Medium | 천천히 확장하고 빠르게 축소하는 컴퓨팅 프로필입니다. |
| Large | 천천히 확장하고 빠르게 축소하며 더 큰 자원을 제공합니다. |
큰 프로필이 빌드를 빠르게 마칠 수 있지만 컴퓨팅 비용도 늘어납니다. 관리형 프로필과 warm pool 등은 파이프라인의 build settings에서 별도로 구성합니다.
Embedding이나 LLM처럼 모델을 사용하는 비싼 변환이 있으면 적절한 자원을 설정하도록 경고가 나타날 수 있습니다. 모델 연산의 비용과 입력 크기를 함께 고려합니다.
저장만 하는 경우
도구 모음의 Save는 현재 변경을 기록하지만 운영 출력의 로직을 갱신하지 않습니다. Propose를 먼저 선택하면 현재 상태를 자동 저장합니다.
출력에 새 변환을 적용하려면 저장 후 배포해야 합니다. 그래프 밖에서 출력 데이터셋을 열어 실행하는 Build는 마지막으로 배포한 로직을 사용하며, 그 이후 저장한 변경을 반영하지 않습니다.
스트리밍 재배포와 replay
스트리밍 제공 여부는 플랫폼 인스턴스에 따라 다를 수 있습니다. 사용 가능한 스트리밍 파이프라인에서 재배포와 replay는 서로 다른 작업입니다.
| 작업 | 입력 처리 위치와 출력 |
|---|---|
| 재배포 | 저장한 checkpoint 또는 bookmark의 마지막 처리 위치부터 계속합니다. 기존 출력 스트림을 보존하고 새 데이터를 덧붙입니다. |
| Replay | 상태를 다시 계산하고 과거 입력을 지정한 지점부터 처리합니다. 기본 설정에서는 출력에 새 view를 만들고 기존 출력 이력을 초기화합니다. |
Checkpoint는 스트림이 실행되는 동안 주기적으로 저장되며 중지하거나 실패한 뒤 복구할 때 사용합니다. 재배포하려면 평소처럼 Deploy를 선택합니다.
다음 경우에는 replay를 검토하거나 수행해야 합니다.
- 새 변환 로직을 과거 데이터에도 적용해야 하는 경우입니다.
- 상태를 깨뜨리는 변경이 있어 기존 상태를 사용할 수 없는 경우입니다.
- 상위 입력 스트림이 replay되어 현재 파이프라인의 상태도 다시 맞춰야 하는 경우입니다.
Replay 범위 선택
Deploy pipeline > Advanced settings는 기본적으로 접혀 있으며 replay 옵션은 모두 선택 해제되어 있습니다. 펼치면 재처리할 데이터 범위와 상태 초기화의 영향을 확인할 수 있습니다.
Start of input data는 입력 스트림의 시작부터 처리합니다.From a specified time은 선택한 과거 시각부터 처리합니다. 예를 들어2 months전부터 처리하도록 설정할 수 있습니다. 실제 트랜잭션 경계의 포함 범위는 replay 경계를 따릅니다.
전략을 선택하면 Confirm replay strategy 창에서 동작과 하위 영향을 확인해야 합니다. 상태 변경이 감지되면 Errors 탭에 나타나며 해결 전에는 배포가 차단됩니다.
기본 replay는 기존의 활성 출력 view를 새 view로 바꾸므로 현재 스트림의 이력을 다시 구성합니다. 하위 소비 파이프라인도 replay해야 하며, 처리 범위에 따라 수일 동안 가용성에 영향을 줄 수 있습니다. 이전 view의 데이터에 접근할 수 있는 경로와 현재 출력 스트림이 그대로 이어지는 것은 구분해야 합니다.
상위 스트림이 기본 Reset Outputs on replay로 출력 내용을 초기화하고 재처리 구간만 채웠다면 하위 파이프라인은 같은 기간을 다시 지정하지 말고 Start of input data에서 replay합니다. 새 상위 출력의 전체 재처리 기간을 기준으로 하위 결과를 다시 만들어야 합니다.
이전 스트림을 별도로 유지해야 하면 출력을 새 대상으로 보낼 수 있습니다. 나중에 원래 출력 스트림에 다시 기록하려면 replay가 필요합니다. 출력을 초기화하지 않고 과거 입력만 다시 읽는 방법은 선택적 재수집의 Reset Outputs on replay 설정을 사용합니다.