Funnel 스트리밍 파이프라인

OSv2는 Foundry 스트림(Stream)을 입력으로 받아 초나 분 단위로 객체를 인덱싱할 수 있습니다. 배치 데이터셋 처리와 다른 실행 경로를 사용하므로 지연이 중요한 업무에 적합하지만 입력 순서와 기능 제한을 먼저 확인해야 합니다.

갱신 단위와 입력 순서

각 스트림 레코드는 기본 키로 객체를 식별하고 그 객체의 모든 속성을 갱신합니다. 일부 속성만 담은 부분 행을 보내는 기능은 지원하지 않습니다. 상류 파이프라인에서 전체 행을 구성해야 합니다. 삭제는 입력 스트림의 삭제 메타데이터로 표현합니다.

Funnel은 스트림에 쓰인 순서로 레코드를 인덱싱하며 가장 최근 갱신이 우선합니다. 원천 이벤트가 뒤섞인 순서로 도착하면 잘못된 상태가 남을 수 있습니다. 상류에서 기본 키로 분할하고 이벤트 시각에 따라 정렬하여 전달해야 합니다. 이 경로 자체가 지정한 업무 시각 열로 뒤늦은 이벤트를 다시 정렬하지는 않습니다.

객체 유형 구성

기존 스트림은 Data Connection의 스트리밍 동기화로 연결하거나 Pipeline Builder의 스트리밍 파이프라인으로 만들 수 있습니다. 객체 유형은 Pipeline Builder나 Ontology Manager에서 구성하며, 다대다 링크 유형도 스트림 입력을 지원합니다.

Ontology Manager에서 새 유형 또는 기존 유형의 Datasources를 열고 Backing datasource에 스트림을 선택한 뒤 온톨로지에 저장합니다.

기반 데이터소스의 ... 메뉴에서 추가 스트림 설정을 엽니다.

컴퓨팅과 전달 보장

Stream configuration에서 다음 항목을 선택합니다.

• Stream compute profile: 기본 프로필은 일반적인 입력에 맞춰져 있습니다. 처리량이 높아 뒤처지면 더 큰 프로필을, 적은 입력의 비용을 줄이려면 작은 프로필을 검토합니다. 적절한 선택지가 없으면 Palantir 담당자에게 문의합니다.
• Stream consistency guarantee: 기본값은 정확히 한 번 처리(Exactly-once)입니다. 객체 집합 변경을 앱에 한 번 전달하도록 하므로 최소 한 번 처리(At-least-once)보다 지연이 늘 수 있습니다. 최소 한 번 처리는 지연을 줄이는 대신 드물게 객체 집합 변경 알림을 중복 전달할 수 있어, 객체 집합 기반 자동화가 여러 번 실행될 수 있습니다.

설정을 바꾸면 스트리밍 작업을 재시작하므로 새 레코드 처리에 일시적인 지연이 생깁니다.

지원 범위와 한도

• 일반 스트림 기반 객체 유형은 사용자 편집을 지원하지 않습니다. 편집 내용을 입력 스트림의 변경으로 보내거나, 배치 데이터소스를 가진 보조 객체 유형에서 사용자 편집을 받을 수 있습니다. 스트림 기반 데이터와 사용자 편집을 함께 처리해야 하면 직접 데이터소스로 전환하는 경로도 있습니다.
• 다중 데이터소스 객체(MDO)는 지원하지 않습니다.
• 레코드 크기는 최대 1MB, 객체 유형의 속성은 최대 250개입니다. 더 큰 레코드는 객체 모델을 나누는 방식을 검토합니다.
• Workshop 외의 Foundry 프런트엔드는 이 경로의 실시간 데이터 새로고침을 지원하지 않으므로 새 값을 보려면 화면을 새로고침해야 합니다.
• 배치 객체 유형의 실패나 잘못된 레코드 및 반영 지연을 감시하는 것과 같은 유형 수준의 모니터링 지원은 없습니다. 아래의 개별 스트리밍 작업 상세와 지표 조회는 별도 기능입니다.

작업 조사

파이프라인 그림의 Stream 노드를 선택하면 관련 스트리밍 작업의 상세 정보와 지표를 볼 수 있습니다.

예상한 객체 상태가 아니면 입력 순서와 전체 행 구성을 먼저 확인합니다. 데이터 제약을 어긴 레코드는 인덱싱에서 제외됩니다. 처리량, 보존 창과 원천 스트림 교체 조건은 인덱싱 운영에서 구분합니다.