가상 테이블과 외부 데이터 활용
가상 테이블(Virtual table)은 지원되는 외부 데이터 플랫폼의 테이블을 가리키는 Foundry 리소스입니다. 데이터를 먼저 Foundry 데이터셋으로 수집하지 않고 조회할 수 있습니다.
외부 시스템과 저장 형식의 차이를 가상 테이블 리소스로 감싸므로, 서로 다른 원천의 데이터와 Foundry 데이터셋을 함께 사용하는 워크플로를 만들 수 있습니다. 변환 결과를 새 가상 테이블로 기록하여 저장은 외부 시스템에 두고 실행 조정과 권한 관리는 Foundry에서 수행하는 구성도 가능합니다.
가상 테이블에는 두 가지 정보가 필요합니다.
- 연결 정보: 원천 저장 시스템의 주소와 인증 정보 등입니다. Data Connection의 소스로 구성합니다.
- 테이블 식별 정보인 Locator: 원천 안에서 테이블을 찾는 값입니다. 데이터베이스, 스키마와 테이블 이름 등이 해당합니다.
가상 테이블도 Foundry의 보안과 권한 모델을 따르며 여러 애플리케이션에서 열거나 입력으로 사용할 수 있습니다.
지원 소스와 등록 방식
| 소스 | 지원 단계 | 주요 형식 또는 테이블 종류 | 수동 등록 | 자동 등록 |
|---|---|---|---|---|
| Amazon S3 | 정식 제공 | Avro, Delta, Iceberg, Parquet | 지원 | 미지원 |
| OneLake 및 Azure Data Lake Storage Gen2 | 정식 제공 | Avro, Delta, Iceberg, Parquet | 지원 | 미지원 |
| BigQuery | 정식 제공 | 테이블, 뷰, 구체화 뷰 | 지원 | 지원 |
| Databricks | 정식 제공 | 테이블, 뷰, 구체화 뷰 | 지원 | 지원 |
| Foundry | 베타(Beta) | 관리형 Iceberg 테이블 | 지원 | 미지원 |
| Google Cloud Storage | 정식 제공 | Avro, Delta, Iceberg, Parquet | 지원 | 카탈로그를 구성한 Iceberg 테이블에 지원 |
| Snowflake | 정식 제공 | 테이블, 뷰, 구체화 뷰 | 지원 | 지원 |
여기서 뷰와 구체화 뷰(Materialized view)는 외부 데이터 시스템의 테이블 종류입니다. 테이블을 읽을 수 있는지와 그 종류를 출력 대상으로 쓸 수 있는지는 별도로 확인해야 합니다.
Iceberg 카탈로그
Iceberg 카탈로그는 어떤 테이블이 존재하고 각 테이블의 파일이 현재 어디에 있는지 기록합니다. Apache Iceberg 기반 가상 테이블을 읽으려면 카탈로그가 필요합니다.
| 소스 | 사용할 수 있는 카탈로그 | 기존 구성에 대한 조건 |
|---|---|---|
| Amazon S3 | AWS Glue, Object Storage, Polaris | Unity Catalog 연결은 기존 기능 유지 단계(Legacy)이며 Databricks 소스 사용이 권장됨 |
| Databricks | Unity Catalog | Databricks 소스의 카탈로그 사용 |
| Google Cloud Storage | Lakehouse, Object Storage | Lakehouse는 카탈로그 이름이며 테이블 형식은 Iceberg |
| OneLake 및 Azure Data Lake Storage Gen2 | Object Storage, Polaris | Unity Catalog 연결은 기존 기능 유지 단계이며 Databricks 소스 사용이 권장됨 |
| Snowflake | Horizon Catalog | Iceberg의 외부 저장 위치 접근 조건을 함께 충족해야 함 |
같은 소스에 등록하는 Iceberg 테이블은 같은 카탈로그를 사용합니다. Object Storage 카탈로그에서는 Iceberg 메타데이터가 있는 위치를 warehousePath로 지정합니다.
애플리케이션별 사용 범위
| 애플리케이션 | 지원 작업 | 주요 제한 |
|---|---|---|
| Data Connection | 소스 구성과 가상 테이블 등록 | 에이전트 워커 및 에이전트 프록시 연결 미지원 |
| Contour | 가상 테이블 분석 | Save as dataset 미지원 |
| Ontology Manager, Pipeline Builder | 가상 테이블을 바탕으로 객체 생성 | 외부 변경을 객체에 반영하려면 갱신 감지 구성 필요 |
| Data Lineage | Foundry 안의 데이터 계보 조회 | 원천 시스템 내부의 전체 계보를 자동으로 뜻하지 않음 |
| Pipeline Builder | 입력과 출력, 스냅샷 빌드, 추가 전용 증분 빌드, 외부 시스템으로 연산 위임 | 스트리밍 빌드와 Faster pipelines 미지원 |
| Code Repositories | Python, Java, SQL 변환의 입력과 출력, 스냅샷 및 추가 전용 증분 빌드, 원천 시스템으로 연산 위임 | 새 가상 테이블 생성은 Python만 지원. SQL과 Java는 기존 가상 테이블에 기록 |
| Observability | 가상 테이블 상태 검사, Pipeline Builder와 Code Repositories의 데이터 검증 조건 | 단일 노드 변환의 가상 테이블 출력에는 아래 오류 처리 제한 적용 |
| Code Workspaces | JupyterLab과 VS Code에서 사용 | 지원 범위는 소스와 테이블 형식에 따름 |
가상 테이블을 직접 지원하지 않는 기능에는 가상 테이블에서 데이터셋이나 객체를 만드는 후속 파이프라인을 구성하여 연결할 수 있습니다. 이렇게 만든 데이터셋과 객체는 일반적인 Foundry 리소스로 사용합니다.
데이터 검증 조건의 실패 처리
단일 노드 변환에서 가상 테이블을 출력으로 사용하는 경우, 데이터 검증 조건이 실패했을 때 on_error='FAIL'로 실행 작업을 중단하는 설정은 지원하지 않습니다.
가상 테이블 입력, Foundry 관리형 Iceberg 테이블과 일반적인 Spark 변환에서는 이 실패 처리 방식을 사용할 수 있습니다.
소스와 테이블 종류별 입출력 조건
데이터 웨어하우스
| 소스와 테이블 | 입력 | 출력 및 추가 조건 |
|---|---|---|
| BigQuery 테이블 | 지원 | 테이블 출력 지원 |
| BigQuery 뷰, 구체화 뷰 | 지원 | 출력 대상은 테이블. 뷰 등록에는 임시 테이블 기능과 관련 권한 필요 |
| Databricks의 외부 Delta | 지원 | 외부 접근이 활성화된 Spark 경로에서 출력 지원 |
| Databricks의 관리형 Iceberg | 지원 | 외부 접근이 활성화된 Spark 경로에서 출력 지원 |
| Databricks의 관리형 Delta, Avro, Parquet | 지원 | 이 형식의 관리형 테이블을 Spark 가상 테이블 출력으로 쓰는 방식은 미지원 |
| Databricks의 외부 Avro, Parquet | 지원 | Spark 가상 테이블 출력 미지원 |
| Databricks의 일반 테이블, 뷰와 구체화 뷰를 JDBC로 접근 | 지원 | 외부 접근을 사용하지 않는 이 경로는 테이블 입력에 사용 |
| Snowflake의 일반 테이블 | 지원 | 테이블 출력 지원 |
| Snowflake의 뷰, 구체화 뷰 | 지원 | 출력 대상은 테이블 |
| Snowflake의 관리형 Iceberg | 지원 | Horizon Catalog 직접 쓰기는 Snowflake의 비공개 프리뷰(Private preview) 기능과 해당 접근 조건이 필요 |
Databricks의 외부 접근은 Unity Catalog에서 활성화하고, Foundry가 실제 저장 위치에 도달할 외부 통신 정책과 저장소 접근 인증 정보를 받을 권한을 준비해야 합니다. 조건을 충족하면 Delta 또는 Iceberg 클라이언트로 저장소를 직접 읽고 쓰며, Databricks의 연산을 데이터 읽기와 쓰기에 사용하지 않습니다. 조건이 충족되지 않으면 JDBC 경로를 사용합니다.
Snowflake의 Iceberg 직접 접근에는 외부 볼륨까지의 네트워크 경로와 Horizon Catalog에서 저장소 인증 정보를 얻을 권한이 필요합니다. 데이터는 Iceberg 클라이언트로 저장소에서 직접 읽고 쓰지만, 테이블 종류 확인 같은 일부 메타데이터 쿼리에는 소스에 설정한 웨어하우스를 사용합니다. 이 조건이 없으면 일반 Snowflake 테이블과 같은 방식으로 웨어하우스를 거쳐 접근합니다.
Foundry 연산과 원천 시스템으로의 연산 위임
원천 시스템으로 연산 위임(Compute pushdown)은 외부 시스템의 네이티브 연산 엔진을 사용하는 방식입니다. 가상 테이블의 쿼리와 지원 기능에 따라 Foundry와 원천 시스템 사이에 연산이 나뉠 수 있습니다.
| 대상 | Foundry 연산 경로 | 원천 시스템으로 연산 위임 |
|---|---|---|
| BigQuery | Python 단일 노드와 Spark, Pipeline Builder Spark | Python의 Ibis 경로 지원. Pipeline Builder 경로 미지원 |
| Databricks | Python 단일 노드와 Spark, Pipeline Builder Spark | Python의 PySpark 경로와 Pipeline Builder 지원 |
| Snowflake의 일반 테이블, 뷰와 구체화 뷰 | Python 단일 노드와 Spark, Pipeline Builder Spark | Python의 Snowpark 경로와 Pipeline Builder 지원 |
| Snowflake의 관리형 Iceberg | Python Spark, Pipeline Builder Spark | Python의 Snowpark 경로와 Pipeline Builder 지원 |
위 데이터 웨어하우스 경로에서 Pipeline Builder의 단일 노드 실행은 지원하지 않습니다. Snowflake 관리형 Iceberg에는 Python 단일 노드 실행도 지원하지 않습니다.
객체 저장소의 파일 테이블
S3, Azure Data Lake Storage Gen2와 Google Cloud Storage는 Avro, Delta, Iceberg, Parquet 가상 테이블을 Code Repositories와 Pipeline Builder의 입력 및 출력으로 사용할 수 있습니다. 객체 저장소 자체로 연산을 위임하는 기능은 지원하지 않습니다.
Delta와 Iceberg의 증분 처리는 추가 전용 변경에 한정됩니다. Delta에는 Change Data Feed가 필요하며 Iceberg는 Incremental Reads를 사용합니다. Parquet 가상 테이블은 증분 파이프라인을 지원하지 않고, 스키마 추론에는 최대 100개 파일을 사용합니다.
Google Cloud Lakehouse는 Google Cloud Storage 소스의 Iceberg 카탈로그로 구성합니다. Iceberg 형식의 입력과 출력, 수동 및 자동 등록, 추가 전용 증분 처리를 지원하지만 원천 시스템으로 연산을 위임하지는 않습니다.
가상 테이블 등록
Data Connection에서 지원되는 소스를 구성한 뒤 소스의 Virtual tables 탭을 엽니다.
개별 등록
- Create virtual table을 선택합니다.
- 원천의 테이블을 탐색하고 등록할 테이블을 선택합니다.
- Foundry에 만들 리소스의 이름과 위치를 지정합니다.
다른 위치를 고르지 않으면 소스의 기본 출력 폴더에 생성합니다.
일괄 등록
Databricks, BigQuery와 Snowflake 같은 테이블형 소스는 여러 테이블의 일괄 등록(Bulk registration)을 지원합니다.
왼쪽에서 원천 테이블을 하나 이상 선택하고 오른쪽에서 저장 위치와 Foundry 리소스 이름을 바꿉니다. Foundry의 가상 테이블 이름을 바꾸어도 원천의 테이블 이름은 바뀌지 않습니다.
자동 등록
자동 등록(Auto-registration)을 활성화하면 새 Foundry 프로젝트를 만들고, 소스의 인증 정보로 접근할 수 있는 테이블을 그 프로젝트에 자동 등록합니다. 폴더 계층은 원천 시스템의 구조를 따르며 새 테이블이 생기면 주기적으로 반영합니다.
원천 테이블을 삭제해도 Foundry의 관련 가상 테이블 리소스를 자동으로 삭제하지는 않습니다. 해당 리소스를 열어도 데이터를 읽어 오지 못하는 상태가 됩니다.
자동 등록을 활성화하려면 프로젝트 생성 권한이 필요합니다.
자동 등록 프로젝트는 Foundry가 관리하므로 사용자가 그 안에 리소스를 수동으로 만들거나 갱신할 수 없습니다. 워크플로를 개발할 프로젝트로 가상 테이블을 가져와 사용합니다.
프로젝트의 권한과 접근은 자동 등록을 켤 때 설정할 수 있고, 이후 소유자가 접근 사이드바에서 관리할 수 있습니다.
Databricks 태그 필터
Databricks 자동 등록에서는 테이블 태그 목록으로 대상을 제한할 수 있습니다. Databricks의 TABLE_TAGS 시스템 테이블에서 지정한 태그 중 하나 이상이 있는 테이블만 등록합니다.
Lakehouse 카탈로그의 테이블 이름
Google Cloud Storage 소스에서 Catalog → Lakehouse Catalog를 구성하면 버킷 이름이 카탈로그 ID가 됩니다. 테이블을 등록할 때 Format은 Iceberg, 테이블 이름은 namespace.table_id 형식으로 지정합니다. 가상의 예시는 analytics.orders입니다.
Catalog ID (bucket)은 소스에서 정한 버킷을 표시하며 개별 가상 테이블 등록 과정에서 바꿀 수 없습니다. Foundry 리소스 이름은 Lakehouse의 실제 테이블 이름과 별도로 정합니다.
같은 Google Cloud Storage 소스를 Lakehouse 카탈로그와 BYOB Iceberg 저장소에 동시에 사용할 수는 없습니다. 두 용도에는 별도 소스를 만들고, BYOB 소스에는 Catalog를 설정하지 않습니다.
Code Repositories에서 사용
가상 테이블을 읽는 변환은 소스의 외부 통신 정책에 따라 네트워크 접근을 얻고, 원천에 연결할 인증 정보도 사용합니다. 따라서 소스에 다음 설정이 필요합니다.
| 설정 | 통제하는 범위 |
|---|---|
| Code imports | 소스를 코드 저장소로 가져와 사용할 수 있는지 |
| Export controls | 가상 테이블을 사용하는 Python 변환의 입력에 허용할 보안 표지와 조직 |
소스를 설정하고 코드 저장소에 가져온 뒤에는 transforms.api.Input으로 가상 테이블을 데이터셋처럼 입력에 사용할 수 있습니다. 증분 연산의 API 형태도 데이터셋과 일관되지만 지원 여부와 준비 조건은 소스에 따라 다릅니다.
Python, SQL과 Java 변환에서 입력으로 사용할 수 있습니다. 새 가상 테이블을 출력으로 생성하는 기능은 Python 변환에서만 지원합니다. SQL과 Java 변환은 이미 존재하는 가상 테이블에 기록할 수 있습니다.
버전과 증분 지원 조회
Dataset Preview의 Details에서 다음 항목을 확인합니다.
| 항목 | 의미 |
|---|---|
| Incremental | 지원되는 추가 전용 변경을 증분 파이프라인에서 처리할 수 있는지 |
| Versioning | 원천의 버전으로 변경 여부를 확인하여 불필요한 후속 빌드를 건너뛸 수 있는지 |
원천의 버전 지원과 Foundry 데이터셋의 버전 및 브랜치 기능은 다른 개념입니다. 가상 테이블은 Foundry 데이터셋의 브랜치와 버전 관리 기능을 그대로 제공하지 않습니다.
외부 변경 감지
갱신 감지(Update detection)는 외부에서 관리하고 Foundry에 등록한 입력 가상 테이블의 변경을 주기적으로 확인하는 기능입니다. 파이프라인이나 객체 같은 하위 리소스의 빌드를 시작할 때 사용할 수 있습니다.
Foundry 파이프라인이 만든 출력 가상 테이블은 빌드 정보로 변경을 추적하므로 이 감지가 필요하지 않습니다.
| 원천의 버전 지원 | 감지 동작 |
|---|---|
| 지원 | Delta나 Iceberg 등의 버전을 비교하여 필요한 경우에만 후속 빌드를 시작 |
| 미지원 | 매번 조회를 잠재적인 변경으로 취급. 실제 데이터가 그대로여도 후속 빌드가 발생할 수 있음 |
갱신 감지는 빌드가 언제 시작되는지를 정합니다. 그 빌드를 스냅샷으로 실행할지 증분으로 실행할지는 별도 조건입니다.
가상 테이블의 증분 지원은 현재 추가 전용 변경에 한정됩니다. Delta의 Change Data Feed, Iceberg의 Incremental Reads처럼 소스별 준비 조건도 필요합니다. 원천이 버전을 지원하지 않으면 후속 파이프라인은 스냅샷으로 전체 테이블을 다시 처리해야 합니다.
활성화
갱신 감지는 입력 가상 테이블을 사용하여 하위 테이블, 데이터셋이나 객체를 만든 뒤에 사용할 수 있습니다.
- Dataset Preview에서 가상 테이블을 엽니다.
- 왼쪽의 갱신 감지 영역으로 이동합니다.
- Update detection을 활성화합니다.
- 매시간 또는 매일처럼 조회 일정을 지정합니다.
이후 가상 테이블을 하위 테이블과 데이터셋의 예약 실행 트리거로 사용할 수 있습니다. 해당 가상 테이블 기반 객체는 원천 변경이 감지되면 자동으로 다시 인덱싱합니다.
Ontology Manager에서 가상 테이블을 객체의 기반으로 직접 지정할 수도 있습니다. 원천이 Foundry 밖에서 바뀐다면 갱신 감지를 활성화하여 객체에도 변경을 반영해야 합니다.
동기화 데이터셋과 선택 기준
| 고려 사항 | 가상 테이블의 특성 |
|---|---|
| 저장 중복 | 원천 전체를 먼저 Foundry 데이터셋으로 복사하지 않아 중복 저장을 줄일 수 있음 |
| 하위 리소스 저장 | 파이프라인이 만든 데이터셋이나 객체의 데이터는 Foundry에 저장됨 |
| 전송량 | 지원되는 쿼리는 원천으로 연산을 위임하여 가져올 데이터 양을 줄일 수 있음 |
| 데이터 조회 시점 | 사용할 때 원천을 조회하므로 Foundry의 수집 주기를 기다릴 필요가 없음 |
| 대화형 성능 | Foundry 데이터셋으로 저장한 경우보다 느릴 수 있음 |
| 연산 사용량 | 쿼리 빈도와 형태에 따라 증가할 수 있음. 정기 파이프라인 입력과 빈번한 Contour 대화형 조회는 사용 양상이 다름 |
| 브랜치와 버전 | Foundry 데이터셋의 기능을 그대로 사용할 수 없음 |
큰 테이블의 중복 저장 비용이 중요하거나 외부 저장을 유지해야 할 때 가상 테이블이 유용할 수 있습니다. 데이터셋 동기화와 가상 테이블을 함께 사용할 수도 있습니다.
직접 가상 테이블을 조회하는 것과, 그 결과를 저장한 하위 데이터셋이나 객체를 조회하는 것은 구분합니다. 하위 리소스의 최신 상태는 빌드나 인덱싱 및 갱신 감지 구성에 따라 결정됩니다.
연결과 변환의 제한
- Foundry 워커 소스와 직접 연결 외부 통신 정책이 필요합니다.
- 셀프서비스 프라이빗 링크 정책은 일반적으로 지원하지 않습니다. Palantir 담당자가 구성한 프라이빗 링크는 지원합니다.
- 에이전트 프록시 정책, 버킷 엔드포인트 정책과 에이전트 워커 연결은 지원하지 않습니다.
- 모든 소스나 모든 Foundry 기능에서 가상 테이블 입력을 사용할 수 있는 것은 아닙니다.
use_external_systems데코레이터를 사용하는 변환은 가상 테이블과 함께 사용할 수 없습니다. 소스 기반 외부 연결 변환으로 바꾸거나, 가상 테이블을 읽는 변환과 해당 데코레이터를 사용하는 변환을 나눕니다.