온톨로지 상태를 데이터셋으로 구체화

구체화(Materialization)는 기반 데이터와 사용자 편집을 합친 최신 객체 상태를 데이터셋이나 제한 뷰(Restricted view)로 제공합니다. 사용자 편집을 포함한 값을 후속 파이프라인에서 처리하거나, 객체 유형 전체의 최신 상태를 다운로드할 때 사용합니다.

대량 다운로드는 구체화 데이터셋을 만든 뒤 일반 데이터셋의 데이터 내보내기나 변환 기반 다운로드 경로를 사용하는 방식이 권장됩니다.

생성과 갱신

Ontology Manager의 Datasources에서 Edits 구성을 켜고 Materializations 탭을 엽니다. 입력 데이터소스에 따라 일반 데이터셋이나 제한 뷰를 생성할 수 있습니다. 구체화 결과는 자동으로 갱신하며 Dataset Preview에서 수동 빌드할 수 없습니다.

OSv1의 쓰기용 데이터셋(Writeback dataset)은 객체나 조인 테이블 기반 다대다 링크에 사용자 편집을 켜기 위한 필수 구성입니다. OSv2에서는 편집을 켜는 데 구체화 데이터셋이 필요하지 않습니다. 필요할 때만 만들고, 서로 다른 속성 부분집합을 담는 여러 구체화를 구성할 수 있습니다.

편집 전파 주기와 비용

OSv1에는 새 사용자 편집이 생겼다는 이유로 쓰기용 데이터셋 빌드를 시작하는 기능이 없습니다. 사용자가 빌드 일정을 구성해야 하며 새 데이터가 없으면 불필요한 컴퓨팅을 피하도록 빌드를 자동 중단합니다. 일정이나 빌드가 없으면 쓰기용 데이터셋이 현재 온톨로지 상태를 반영하지 못할 수 있습니다.

OSv2에는 다음 두 방식이 있습니다.

보존 기간과 스키마

OSv1의 쓰기용 데이터셋에는 일반 데이터셋처럼 보존 정책을 설정할 수 있습니다. 정기적으로 빌드했다면 이전 스냅샷을 보존 정책에 따라 조회할 수 있습니다.

OSv2 구체화의 보존 정책은 사용자 지정할 수 없습니다. 과거 트랜잭션을 계속 삭제하며 최신 스냅샷만 보장합니다. 과거 객체 상태를 남겨야 하면 구체화 뒤에 별도 변환을 구성하여 보존해야 합니다. 객체 유형을 삭제한 뒤에도 데이터를 남겨야 하는 경우 역시 하류 변환이 필요합니다.

OSv1 쓰기용 데이터셋의 스키마는 입력 데이터소스에서 복사합니다. OSv2 구체화는 온톨로지 정의를 사용하며, 속성의 API Name이 결과 열 이름이 됩니다. OSv1에서 이전하면서 입력 열 이름을 유지해야 한다면 기존 파이프라인 호환성을 위해 Palantir 담당자와 설정을 확인합니다.

__is_deleted, __patch_offset처럼 __로 시작하는 열은 Foundry가 중복 제거 등에 사용하는 내부 메타데이터입니다. 객체 상태를 나타내는 업무 데이터가 아니며 예고 없이 이름이 바뀌거나 제거될 수 있으므로 운영 워크플로에서 사용하지 않습니다.

제한 뷰와 다중 데이터소스의 출력 선택

OSv1은 제한 뷰를 입력으로 사용하더라도 제한 뷰 형태로 구체화할 수 없습니다. 기반 데이터셋의 모든 행을 담는 쓰기용 데이터셋을 만들고 사용자가 그 출력의 접근을 직접 통제해야 합니다.

데이터소스 기반 권한을 사용하는 OSv2 유형은 제한 뷰 입력을 일반 데이터셋 또는 제한 뷰로 구체화할 수 있습니다. 객체 보안 정책(Object security policy)을 사용하는 유형은 일반 Foundry 데이터셋으로만 구체화할 수 있습니다.

다중 데이터소스 객체에서는 구체화에 포함할 입력 데이터소스를 선택합니다. 선택하지 않은 원천에 매핑한 속성은 출력에 포함하지 않습니다.

제한 뷰 입력 하나를 선택하면 제한 뷰로 구체화할 수 있습니다.

여러 입력 데이터소스를 선택하면 일반 Foundry 데이터셋으로만 구체화할 수 있습니다. 원천 제한 뷰의 정책이 서로 다를 수 있고 제한 뷰가 열별 정책을 지원하지 않기 때문입니다.

제한 뷰를 일반 데이터셋으로 만들 때의 권한

제한 뷰는 변환의 입력으로 직접 사용할 수 없습니다. 온톨로지 구체화는 제한 뷰를 기반으로 일반 데이터셋을 만드는 지원 경로입니다. 일반 출력 데이터셋은 제한 뷰의 행 정책을 그대로 가져오지 않으므로 생성과 조회에 더 넓은 권한이 필요합니다.

여기서 기반 데이터셋은 제한 뷰의 원천이며, 제한 뷰는 그 원천에 행 접근 정책을 적용하고, 객체 유형은 해당 제한 뷰를 입력으로 사용합니다.

새 구체화 데이터셋을 만들려면 기반 데이터셋을 새 데이터셋으로 그대로 옮기는 항등 변환을 수행할 권한이 필요합니다. 기반 데이터셋과 제한 뷰 양쪽의 재량 통제와 필수 통제를 모두 충족해야 합니다.

필요한 재량 통제가 없으면 데이터셋 생성 선택지가 제공되지 않습니다.

생성 권한과 트랜잭션 조회 권한은 별개입니다. 결과 트랜잭션을 보려면 기반 데이터셋의 트랜잭션을 볼 수 있어야 하며, 그 트랜잭션의 필수 통제도 충족해야 합니다.

제한 뷰에서 연결이 끊겼던 기반 데이터셋의 보안 표지(Marking)는 일반 구체화 데이터셋으로 다시 전파됩니다. 따라서 제한 뷰의 행을 볼 수 있다는 사실만으로 출력 트랜잭션도 볼 수 있는 것은 아닙니다.

객체 유형의 필수 통제 전파

OSv2 객체 유형에 필수 통제(Mandatory control) 속성이 있으면, 구체화 데이터셋을 보는 사용자는 Allowed markings, Allowed organizations와 Max classification에 설정한 통제도 충족해야 합니다. 기반 데이터셋에서 상속한 통제와 객체 유형의 통제를 함께 적용합니다.

예를 들어 기반 데이터셋에 보안 표지 하나를 적용하고, 객체 유형의 필수 통제 속성에 다른 보안 표지를 지정할 수 있습니다.

구체화 결과에는 두 출처의 통제가 모두 반영됩니다.

객체 및 속성 보안 정책의 반영 시점

객체나 속성 보안 정책을 사용하는 구체화 트랜잭션은 빌드 시점에 생성한 정책으로 보호합니다. 정책에 보안 표지를 추가하거나 제거해도 이미 커밋한 트랜잭션에 자동으로 소급 적용하지 않습니다. 변경한 정책을 새 출력에 반영하려면 구체화 빌드가 완료되어야 합니다.

과거의 모든 구체화 트랜잭션까지 같은 표지로 보호해야 한다면 구체화 데이터셋 또는 기반 데이터셋 자체에 그 표지를 설정해야 합니다. 객체나 속성의 정책만 바꾸는 작업과 데이터셋 전체의 접근 범위를 바꾸는 작업을 구분합니다.

구체화할 수 없는 제한 뷰 정책

OSv2의 제한 뷰에 다음 정책이 있으면 구체화 데이터셋을 구성할 수 없습니다.

1. 사용자 필수 통제를 참조하는 조건을 문자열 속성에 적용한 경우입니다. 해당 속성을 필수 통제 속성으로 바꾸고 최대 분류 또는 허용 보안 표지 집합을 구성해야 합니다.
2. 승인된 그룹 ID(Authorized group ID) 조건을 사용하는 경우입니다.
3. 조직이나 보안 표지를 정적 값으로 직접 참조하는 조건이 있는 경우입니다. 조직 및 보안 표지의 세부 조건이 문자열 속성이나 정적 값 대신 필수 통제 속성을 참조하도록 구성해야 합니다.

브랜치에서의 동작

Global Branching의 브랜치에서 구체화를 새로 만들거나 기존 구체화 구성을 편집할 수 없습니다. 기존 구체화가 있는 객체 유형의 변경은 브랜치에서 인덱싱하고, 해당 브랜치의 갱신을 구체화 데이터셋 또는 제한 뷰에 반영합니다.

객체 유형을 삭제하거나 브랜치에서 제거하면 구체화 데이터셋의 대응 브랜치도 삭제합니다. 제한 뷰의 제약 때문에 구체화된 제한 뷰의 브랜치는 자동으로 삭제하지 않습니다.