인덱싱 상태와 스트림 운영

완료 판정과 작업 재시도

Ontology Manager의 파이프라인 그래프에서 Object Storage v2 노드에 완료 표시가 나타나면 인덱싱이 끝나 조회할 수 있습니다.

OSv1에 정상 등록했던 데이터라도 OSv2의 더 엄격한 검증에 실패할 수 있습니다. 저장소 호환성과 데이터 제약을 확인해야 합니다.

OSv2가 작업 재시도를 관리합니다. 일시적인 오류라면 약 5분 뒤 자동 재시도합니다. 잘못된 데이터 형식처럼 끝까지 실패할 것으로 판단한 오류는 새 데이터가 들어올 때만 다시 시도합니다. 제한 뷰 입력에서는 데이터나 정책이 바뀌어도 작업을 다시 시작합니다.

인덱스 크기는 대상 객체 데이터베이스의 저장 공간에 제한됩니다. OSv2 검색 노드의 디스크가 부족하면 인덱싱이 실패하고 파이프라인 그래프에 원인이 표시됩니다. 디스크 오류는 Palantir 담당자에게 문의해야 합니다.

스트리밍 지연과 처리량

스트림 기반 유형의 초기 반영은 내부 스트림 생성과 인덱싱으로 나뉩니다. 과거 데이터를 인덱싱하는 단계는 Spark 병렬 처리를 사용하여 배치 파이프라인에 준하는 처리를 수행합니다. 레코드별로 데이터를 처리하는 내부 스트림 생성이 과거 데이터 보충의 주요 제한 요인이 될 수 있습니다. 이 초기 처리와 이후 실시간 갱신의 지연을 구분합니다.

기본 Exactly-once 경로에서는 Flink 체크포인트가 주요 지연 요인입니다. 기본 체크포인트 주기는 1초이지만 이것이 전체 수집부터 앱 표시까지의 1초 SLA를 뜻하지는 않습니다. 필요한 설정 변경은 Palantir Support와 확인합니다.

표준 Funnel 스트리밍의 OSv2 인덱싱 처리량은 객체 유형당 2MB/s입니다. 더 높은 처리량이 필요하면 지원을 요청합니다. 이 수치를 별도 Beta 기능인 직접 데이터소스의 처리량 보장으로 사용하지 않습니다.

순서, CDC와 전체 행

일반 스트림 입력은 사용자가 지정한 시각 열로 중복을 해소하지 않고 입력 순서를 보존합니다. 상류 파이프라인에서 이벤트 시각으로 윈도우를 만들고 기본 키로 해시 분할하여 순서를 맞춰야 합니다. 시각 기반으로 늦게 도착한 직접 쓰기를 제외하는 기능은 직접 데이터소스의 별도 구성입니다.

생성, 갱신과 삭제의 CDC 처리를 지원합니다. 삭제 메타데이터는 변경 데이터 캡처에서 구성합니다. 부분 행을 보내 일부 속성만 바꿀 수는 없으므로 상류에서 전체 객체 상태를 구성해야 합니다. 상태를 가진 스트리밍 처리로도 규모 요구를 충족하지 못하면 Palantir Support와 확인합니다.

스트리밍은 다대다 링크 유형에도 사용할 수 있습니다. 지원 인덱싱 저장소는 OSv2이며, 다른 객체 데이터베이스나 별도 구체화 및 Automate 저장 대상으로 같은 인덱싱을 적용하는 기능과 구분해야 합니다. OSv2에 저장된 스트리밍 객체를 함수로 조회하는 동작은 배치 객체와 같습니다.

일반 스트림 기반 객체 유형에는 구체화 데이터셋을 지원하지 않습니다. 스트림 아카이브 데이터와 온톨로지 객체 상태를 제공하는 구체화는 별개입니다. 특히 아카이브의 변경 로그 해소와 온톨로지의 입력 순서 처리가 항상 같다고 가정하지 않아야 합니다.

계속 실행되는 작업과 비용

Funnel 스트리밍 파이프라인은 운영 유형의 가용성을 위해 계속 실행하며 사용자가 취소할 수 없습니다. 프로토타입에서도 비용이 발생할 수 있으므로 필요하면 시험 중 객체 유형을 배치 입력으로 바꾸거나 Palantir Support와 대안을 확인합니다. 컴퓨팅 사용량은 일반 스트리밍 리소스와 같은 방식으로 계산합니다.

원천 스트림 교체

Funnel은 대체 스트림의 인덱스가 최신 상태인지 판단한 뒤 전환합니다.

1. 새 로직을 별도 스트림 또는 다른 스트림 브랜치에서 실행합니다.
2. 과거 레코드의 재생이 끝날 때까지 기다립니다.
3. 객체 유형의 입력 데이터소스를 새 스트림으로 변경합니다.
4. 새 스트림의 대체 파이프라인이 완전히 인덱싱될 때까지 기존 스트림의 Live 파이프라인을 유지합니다.
5. Funnel 전환을 마친 뒤 기존 스트림을 중단합니다.

이 교체 절차는 기존 뷰를 즉시 비우는 직접 데이터소스의 재생과 다릅니다.

보존 창과 삭제 시점

스트리밍 보존 창(Retention window)은 최선 노력 방식입니다. 창 안에 있는 유효한 객체는 조회할 수 있지만, 창 밖의 객체를 특정 시각까지 삭제한다는 보장은 없습니다.

예를 들어 보존 창이 2주이고 입력 스트림이 마지막으로 객체를 갱신한 것이 3주 전이어도, 객체가 더 여러 날 남아 있을 수 있습니다. 정해진 삭제 시한을 충족하는 기능으로 사용해서는 안 됩니다.

기본 정리는 2주마다 실행하는 파이프라인 대체를 통해 이루어집니다. 대체 시 보존 창의 시작부터 스트림을 다시 재생하여 오래된 객체를 제거합니다. 더 잦은 삭제가 필요하면 지원을 요청합니다. 보존 창을 지정하지 않으면 입력 스트림의 모든 데이터를 수집합니다.

예상과 다른 데이터 조사

값이 다르면 입력 순서를 먼저 확인합니다. 스트리밍에도 데이터 검증을 적용하지만 처리를 멈추어 사용자 변환에서 오류를 낼 수 없으므로 잘못된 레코드를 제외합니다. 배치와 스트리밍에 대한 속성 크기 제한의 적용 단계는 데이터 제약에 따릅니다.

스트림이 배치로 인덱싱되거나 중복 키 오류가 발생하면 Ontology Manager에서 입력 유형을 명시적으로 스트림으로 지정했는지 확인합니다. 스트림을 지정하지 않으면 일반 배치 파이프라인으로 처리될 수 있습니다. 제한 뷰를 스트림에 직접 구성하는 경로는 지원하지 않으며, 스트리밍 데이터의 행과 열 보안에는 객체 및 속성 보안 정책을 사용합니다.