데이터셋과 파일, 트랜잭션 및 스키마

데이터셋(Dataset)은 Foundry에 들어온 데이터를 처리하고 온톨로지에 연결하는 과정에서 사용하는 기본 데이터 리소스입니다. 데이터셋의 기반은 파일 집합이며, Foundry는 그 위에 권한, 스키마, 버전과 시간에 따른 변경 관리를 제공합니다.

데이터셋을 열었을 때 보이는 행과 열은 파일을 스키마에 따라 해석한 결과입니다. 데이터셋에는 표 형식 외의 데이터도 저장할 수 있습니다.

표현할 수 있는 데이터

비정형 데이터를 직접 업로드할 때는 Upload as media set 또는 Upload to a dataset without a schema를 선택할 수 있습니다. 미디어 집합은 미디어 처리를 위해 별도로 최적화된 리소스입니다.

반정형 데이터 전용 업로드 옵션은 없습니다. 스키마가 없는 데이터셋으로 가져온 뒤 후속 변환에서 표 형식 스키마를 추론하면 성능과 활용 편의성을 높일 수 있습니다.

트랜잭션과 변경 확정

트랜잭션(Transaction)은 데이터셋의 파일에 대한 원자적인 변경 단위입니다. 보통 사용자는 빌드를 통해 데이터를 갱신하고, 그 내부에서 파일 변경을 트랜잭션으로 처리합니다. Git의 커밋처럼 여러 변경을 하나의 확정 단위로 다루는 개념입니다.

트랜잭션 유형

APPEND에서 기존 파일을 덮어쓰고 커밋하려고 하면 실패합니다. 이 유형은 새 데이터만 처리하는 증분 파이프라인의 기반이 됩니다. 데이터 양이 커도 변경분만 처리할 수 있지만, 증분 상태를 유지하는 구성과 운영에는 추가적인 복잡성이 있습니다.

UPDATE는 행 단위 업데이트가 아닙니다. 기존 파일을 덮어쓰는 UPDATE는 후속 파이프라인의 추가 전용 입력 조건을 깨뜨리므로 해당 파이프라인이 스냅샷 방식으로 다시 처리해야 합니다. 새 파일만 추가하고 기존 파일을 덮어쓰지 않았다면 UPDATE라도 증분성이 유지됩니다.

파일 수집에서는 전체 파일을 다시 가져오는 SNAPSHOT, 새 파일만 추가하는 APPEND, 새 파일과 변경 파일을 가져오는 UPDATE를 목적에 맞추어 사용합니다. 설정 조합은 파일 배치 동기화에서 설명합니다.

변경 이력 예시

가상의 데이터셋 브랜치에 다음 변경이 차례로 커밋되었다고 가정하겠습니다.

1. SNAPSHOT으로 파일 A, B를 기록합니다.
2. APPEND로 C를 추가합니다.
3. UPDATE로 A의 내용을 A'로 바꿉니다.
4. DELETE로 B를 뷰에서 제거합니다.

현재 뷰에는 A'와 C가 있습니다. 여기에 파일 D만 포함한 새 SNAPSHOT을 커밋하면 현재 뷰에는 D만 남고 앞의 네 트랜잭션은 이전 뷰의 이력에 속합니다.

데이터셋 뷰

데이터셋 뷰(Dataset view)는 특정 브랜치의 특정 시점에서 유효한 파일 집합입니다.

뷰를 계산하는 방법은 다음과 같습니다.

1. 빈 파일 집합에서 시작합니다.
2. 대상 시점 이전의 가장 최근 SNAPSHOT을 시작점으로 삼습니다. SNAPSHOT이 없다면 데이터셋의 가장 이른 트랜잭션부터 시작합니다.
3. 시작점부터 대상 시점까지 트랜잭션을 순서대로 적용합니다.
4. SNAPSHOT과 APPEND의 파일은 집합에 추가합니다.
5. UPDATE는 파일을 추가하고 같은 경로의 기존 파일을 바꿉니다.
6. DELETE는 지정한 파일을 집합에서 제거합니다.

새 SNAPSHOT이 새로운 뷰의 경계를 만듭니다. APPEND, UPDATE, DELETE는 현재 뷰를 확장하거나 바꾸며 별도의 스냅샷 경계를 만들지 않습니다. 모든 트랜잭션이 SNAPSHOT인 이력에서는 트랜잭션마다 뷰가 하나씩 생깁니다.

뷰에 여러 브랜치의 트랜잭션이 포함될 수도 있습니다. 예를 들어 master의 스냅샷과 추가 트랜잭션을 바탕으로 분기한 브랜치에서 계속 APPEND를 수행하면, 분기 전 이력도 새 브랜치 뷰의 시작 부분을 구성합니다. 이후 SNAPSHOT을 커밋하면 그 지점에서 새로운 뷰를 시작합니다.

브랜치와 협업

브랜치(Branch)는 여러 사용자가 데이터셋의 변경을 동시에 실험할 수 있도록 변경 이력을 분리하는 단위입니다.

브랜치는 개별 데이터셋뿐 아니라 전체 파이프라인을 함께 변경하는 작업에도 사용합니다.

스키마

스키마(Schema)는 데이터셋 뷰의 파일을 어떻게 해석할지 정하는 메타데이터입니다. 파일을 읽는 방법과 열 또는 필드의 이름 및 타입 등을 포함합니다. 일반적인 표 형식 스키마는 데이터셋의 열과 각 열의 타입을 정의합니다.

스키마가 지정되어 있다는 사실만으로 모든 파일이 그 스키마에 맞는 것은 아닙니다. 가령 CSV 파일이 있는 데이터셋에 Parquet 스키마를 적용하면 읽는 애플리케이션에서 파일 형식 불일치 오류가 생길 수 있습니다.

스키마는 뷰에 저장하므로 시간에 따라 바뀔 수 있습니다. 새 열을 추가하거나 필드의 타입을 바꾸는 변경도 표현할 수 있습니다. 기존 파일과 새 스키마를 함께 읽을 수 있는지는 별도로 확인해야 합니다.

Dataset Preview에서 Details → Schema를 선택하면 스키마를 확인할 수 있습니다.

지원 필드 타입

다음 타입을 사용할 수 있습니다.

BOOLEAN, BYTE, SHORT, INTEGER, LONG, FLOAT, DOUBLE, DECIMAL,
STRING, MAP, ARRAY, STRUCT, BINARY, DATE, TIMESTAMP

일부 타입에는 추가 매개변수가 필요합니다.

DECIMAL의 최대 정밀도는 38입니다. 값을 정하기 어렵다면 precision: 38, scale: 18을 출발점으로 사용할 수 있지만, 실제 데이터에 맞는 정밀도와 소수 자릿수를 지정해야 합니다. 이 매개변수는 필수이며, 생략하면 위 값이 자동으로 적용되지 않습니다.

CSV 해석 옵션

Dataset Preview의 Details → Schema에서 스키마 메타데이터 아래쪽의 options 블록에 CSV 해석 옵션을 추가할 수 있습니다.

저장 형식

널리 사용하는 파일 형식은 Parquet, Avro와 Text입니다. Text는 여러 CSV 형식이나 JSON 같은 파일을 표현할 수 있으며, 구체적인 해석 정보는 스키마의 customMetadata에 저장합니다.

JSON이나 XML처럼 표 형식이 아닌 데이터는 스키마 없는 데이터셋으로 보관한 뒤 후속 변환에서 스키마를 적용하는 방식이 권장됩니다.

삭제와 보존 정책

DELETE를 커밋해도 기반 파일시스템의 실제 파일을 즉시 지우는 것은 아닙니다. 현재 데이터셋 뷰에서 파일 참조를 제거합니다.

더 이상 필요하지 않은 이전 트랜잭션의 데이터를 실제로 제거하려면 보존 정책(Retention policy)을 사용합니다. 파일의 나이 등을 기준으로 데이터를 제거하여 저장 비용과 데이터 관리 요건을 충족할 수 있습니다.

적용 중인 보존 정책 조회

데이터셋의 상세 화면에서 현재 적용 중인 보존 정책을 볼 수 있습니다. 이 조회 기능은 베타(Beta) 단계이므로 플랫폼 인스턴스에 제공되지 않을 수 있고 개발 중 동작이 바뀔 수 있습니다. 이용이 필요하면 Palantir 지원팀에 접근을 요청할 수 있습니다.

기반 파일시스템

데이터셋은 Foundry의 논리적 파일 경로와 기반 파일시스템(Backing filesystem)의 물리적 경로 사이의 매핑을 관리합니다. 파일 자체는 그 기반 파일시스템에 저장됩니다.

기반 저장소는 Hadoop FileSystem의 기준 디렉터리로 정의합니다. 자체 HDFS 클러스터를 사용할 수도 있지만, Amazon S3 같은 클라우드 저장소를 사용하는 구성이 더 일반적입니다. 데이터셋 파일은 이 기준 디렉터리 아래의 폴더 계층에 배치됩니다.