FILE 타입과 비정형 데이터

Important

이 기능은 베타 버전으로 제공됩니다. 작업 영역 관리자는 미리 보기 페이지에서 이 기능에 대한 액세스를 제어할 수 있습니다. Azure Databricks 미리 보기 관리를 참조하세요.

이 타입은 FILE 경로와 크기와 같은 메타데이터를 포함한 비구조화 파일에 대한 거버넌스된 참조를 저장합니다. Unity 카탈로그의 열을 사용하여 FILE 문서, 이미지, 오디오를 구조화된 데이터와 함께 저장하세요.

컬럼의 경우 FILE MANAGED , Unity Catalog는 파일의 복사본을 저장하고 테이블로 관리합니다: 행을 삭제하면 참조된 파일이 가비지 컬렉션 대상이 되어 테이블과 파일이 동기화된 상태를 유지합니다.

타입 참조에 대해서는 타입을 참조하세요FILE.

다음 다이어그램은 video라는 이름의 FILE 열이 주행 클립을 참조하고, 경로, 장면 설명, 위험 라벨과 같은 구조화된 열과 함께 표시되는 모습을 보여줍니다:

비디오 열이 FILE 타입인 운전 클립 표입니다. 각 행은 구조화된 열(클립 ID, 경로, 장면 설명, 위험 라벨, 임베딩)과 썸네일, 1.8GB와 같은 크기를 보여주는 비디오 파일 참조를 쌍으로 제공합니다.

FILE 메타데이터 및 저장 공간

각 행마다 타입은 FILE 메타데이터와 저장소에 있는 파일에 대한 거버넌스된 링크를 저장합니다. 값에는 FILE , uri, size, 그리고 content_type 메타데이터 필드가 포함됩니다checksum. 메타데이터 쿼리는 전체 파일 읽기가 필요 없어 쿼리 성능이 향상됩니다.

FILE 값을 AI 함수(예: ai_parse_document 함수)와 사용자 정의 함수(UDF)에 전달할 수 있습니다.

다음 도표는 경로 및 크기 메타데이터와 저장소 내 파일에 대한 참조를 포함하는 관리 FILE 열의 예시를 보여줍니다:

클립 테이블과 비디오 열이 FILE 타입으로 저장되며, 경로와 크기 쌍으로 표시됩니다. 화살표는 각 행을 저장소 내 파일로 연결하며, 테이블과 파일 간의 규칙된 참조를 나타냅니다.

메타데이터 및 내용 접근

값은 FILE 두 부분으로 나뉘며, 각 부분에 대한 접근은 다르게 관리됩니다:

  • 파일 메타데이터(uri, size, content_type, , ) checksum는 테이블의 자체 데이터 파일에 저장됩니다. 테이블 위에 있는 SELECT은 누구나 읽을 수 있습니다.
  • 파일 내용은 보관 상태로 보관됩니다. 이를 읽으려면 FILE EXTERNAL의 경우 기반 볼륨에 있는 파일 READ VOLUME에 대한 액세스 권한이 필요하거나, FILE MANAGED의 경우 FileSpace를 지원하는 테이블과 볼륨 모두에 대한 액세스 권한이 필요합니다.

BINARY 값을 STRING 또는 FILE로 캐스팅하거나, AI 함수 또는 UDF에 전달하거나, 결과 테이블에서 미리 보면 모두 파일 내용을 읽습니다. 메타데이터가 테이블의 일부이기 때문에, 파일의 경로와 크기는 내용에 접근하지 않아도 테이블을 조회할 수 있는 누구나 볼 수 있습니다.

쿼리 결과에서 파일을 미리보기 원하시면 FILE 열의 미리보기 파일을 참조하세요.

왜 BINARY나 STRING 대신 FILE을 사용하나요?

다음 표는 BINARY 또는 STRING 유형의 대용량 비정형 파일을 처리할 때의 어려움을 자세히 설명합니다:

열 형식 Description 도표
BINARY 파일 크기나 경로 같은 메타데이터만 필요해도 매번 읽을 때마다 전체 객체를 물질화합니다. 이로 인해 불필요한 계산과 느린 쿼리가 발생합니다. 클립 테이블과 비디오 열은 BINARY로 저장됩니다. 각 수기가바이트 비디오의 원시 바이트는 열에 인라인으로 구현됩니다.
STRING 파일 경로만 저장하며, 크기나 버전 정보와 같은 메타데이터는 저장하지 않고, 테이블과 파일 사이에 관리되는 링크도 없습니다. 다른 워크로드가 파일을 삭제하면 테이블에 오래된 정보가 남아 있습니다. 테이블 행을 제거하면, 참조된 파일은 수동으로 제거할 때까지 저장소에 남아 있습니다. 영상 열이 STRING 경로로 저장되는 클립 테이블, 예를 들어 s3://.../NW-0142 같은 경우입니다. 한 경로는 더 이상 볼륨 내 파일로 해결되지 않아, 문자열 경로가 파일 존재를 보장하지 않으며 거버넌스가 해제됨을 보여줍니다.

체크섬

checksum 필드는 <prefix>:<digest> 형식의 파일 바이트에 대한 무결성 토큰입니다. 파일을 비교하거나 파일이 변경되지 않았는지 확인하는 데 사용하세요. 리더는 인식되지 않은 접두사가 있는 체크섬을 무시합니다.

체크섬이 항상 제공되는 것은 아닙니다. to_file 함수, create_file 함수, copy_file 함수 는 객체 저장소가 .을 반환 ETAG할 때 체크섬을 채웁니다. list_files 테이블 값 함수 와 read_files 테이블 값 함수 는 체크섬을 채우지 않습니다.

이 필드는 checksum 다음 접두사 중 하나를 사용합니다:

프리픽스 다이제스트 인코딩 Description
ETAG Opaque 전체 파일에 대한 객체 저장소의 eTag입니다. 매장에서 원문 그대로 제공하며, 동등 비교용으로만 사용되고 재계산 불가능합니다.
MD5 소문자 16진수 MD5 다이제스트(RFC 1321), 32개의 육진수 문자.
CRC32 소문자 16진수 CRC32 체크섬(RFC 2083), 8개의 육진수 문자.
CRC32C 소문자 16진수 CRC32C 체크섬(RFC 3385), 8개의 16진수 문자.
SHA-256 소문자 16진수 SHA-256 다이제스트(RFC 6234), 64개의 16진수 문자.

예를 들어, MD5 체크섬은 MD5:d41d8cd98f00b204e9800998ecf8427e와 같고, 객체 저장소 eTag는 객체 저장소가 반환한 바깥쪽 큰따옴표를 포함하여 ETAG:"686897696a7c876b7e"와 같습니다.

FILE와 BINARY 중에서 선택합니다

다음 표는 비구조화 파일 작업 옵션을 비교합니다:

열 형식 가치들 사용 사례
FILE 파일에 대한 거버넌스가 적용된 참조와 메타데이터(uri, size, content_type, checksum). 비구조화 파일을 구조화된 데이터와 함께 관리하고 처리하며, 내장 및 AI 함수에 파일을 전달하는 데 사용됩니다.
BINARY 파일의 원시 바이트를 열에 인라인으로 배치한 것입니다. 데이터 파일에 직접 저장된 작은 객체(기본값은 최대 64 KB)에 사용됩니다. 메타데이터 오버헤드가 적고 파일 관리를 간소화할 때 유용합니다. 예를 들어, 이 기능을 사용해 썸네일을 행 데이터와 일렬로 저장할 수 있습니다.

관리되는 파일 및 외부 파일

이 유형은 FILE 파일 관리를 위한 두 가지 방식을 지원합니다:

  • FILE MANAGED 열은 파일을 관리 저장소로 복사합니다. 권한은 단순화되어 테이블을 통해 관리됩니다. 행을 삭제하거나 다른 파일을 참조하도록 업데이트하면, 참조되지 않은 파일들이 가비지 컬렉션 대상이 되어 테이블과 그 파일들이 동기화됩니다. 이 접근법은 ML 훈련이나 검색 증강 생성(RAG)과 같이 테이블을 통해 파일에 접근하는 작업과 외부 소스에서 인제스트된 파일에 사용됩니다. 수집 패턴은 파일을 FILE 유형으로 수집을 참조하세요.
  • FILE EXTERNAL 열은 Unity 카탈로그 볼륨 내 기존 파일을 참조합니다. 파일들은 Unity 카탈로그 볼륨 권한으로 보호되지만, 생명주기는 Unity 카탈로그에서 관리하지 않으며, 복사되지도 않습니다. 데이터를 이동하거나 기존 볼륨에서 읽는 도구를 방해하지 않고 파일을 참조해야 할 때 이 방식을 사용하세요.

Azure Databricks는 파일 수준 권한과 내장 준수 기능이 필요한 워크로드에 대해 권장합니다FILE MANAGED: 각 파일에 대한 접근은 해당 파일을 참조하는 테이블을 통해 관리되며, 행을 삭제하면 참조된 파일이 가비지 컬렉션 대상이 됩니다. 테이블 밖에서 파일을 읽는 도구들이 기존 볼륨 경로에 머물러야 할 때 사용 FILE EXTERNAL 하세요.

쿼리의 경우, 관리 파일과 외부 파일 간에 차이가 없습니다.

다음 다이어그램은 이 유형이 FILE 클라우드 오브젝트 저장소의 파일과 코드를 어떻게 연결하는지 보여줍니다:

FILE 타입 아키텍처의 다이어그램. Python, SQL, Scala, UDF 클라이언트는 파일 바이트를 가져오지 않고 메타데이터를 읽는 단일 파일 타입을 사용합니다. FILE MANAGED는 파일을 테이블 수준에서 관리하는 FileSpace에 저장하며, 행을 삭제하면 파일이 가비지 컬렉션 대상이 됩니다. 파일 외부는 UC 볼륨 내 기존 경로에서 파일을 참조하며, 볼륨 권한에 의해 관리됩니다. 두 모드 모두 S3, ADLS, 구글 클라우드 저장소와 같은 클라우드 객체 저장소에 파일을 저장합니다.

FILE MANAGED

FILE MANAGED 열은 테이블이 관리형 스토리지로 사용하도록 지정한 Unity 카탈로그 볼륨인 FileSpace에 있는 파일의 복사본을 저장합니다. 이들의 수명 주기는 해당 테이블에 묶여 있습니다: 행을 삭제하면 참조된 파일이 가비지 컬렉션 대상이 되어 테이블과 파일이 동기화된 상태를 유지합니다.

다음 행동들이 적용됩니다 FILE MANAGED:

  • 를 FileSpace 선언하려면 테이블 속성이 필요합니다 databricks.filespace-preview .
  • 관리 파일을 읽거나 쓰려면 테이블과 이를 뒷받 FileSpace침하는 볼륨 모두에 접근할 수 있어야 합니다.
  • 베타에서는 참조되지 않은 파일의 자동 가비지 컬렉션을 지원하지 않습니다.

SharePoint, Google Drive, OneDrive, SFTP와 같은 외부 소스에 저장된 비정형 파일은 ai_parse_document 함수 및 사용자 정의 함수(UDF)와 같은 기능에서 사용하려면 먼저 관리형 파일로 수집되어야 합니다. 수집 패턴에 대해서는 파일을 FILE 유형으로 수집을 참조하세요.

관리형 파일을 사용하려면 FILE MANAGED 열이 있는 테이블을 만들고, databricks.filespace-preview 테이블 속성을 볼륨 경로로 설정하여 볼륨을 FileSpace로 선언하세요:

'databricks.filespace-preview' = '/Volumes/<catalog>/<schema>/<volume_name>/<optional_path>'

완전한 예시는 다음 FILE MANAGED 예시들을 참조하세요.

FILE MANAGED 예제

열이 있는 FILE MANAGED 테이블을 만들려면:

CREATE TABLE reports (id BIGINT, file FILE MANAGED)
  TBLPROPERTIES ('databricks.filespace-preview' = '/Volumes/my_catalog/my_schema/my_managed_volume/');

기존 테이블에 열을 추가 FILE MANAGED 하려면, 다음 코드와 함께 열을 추가하기 전에 테이블 속성을 설정 databricks.filespace-preview 하세요:

ALTER TABLE reports SET TBLPROPERTIES ('databricks.filespace-preview' = '/Volumes/my_catalog/my_schema/my_managed_volume/');

ALTER TABLE reports ADD COLUMN attachment FILE MANAGED;

FileSpace이 없는 테이블에 FILE MANAGED 열을 추가하면 실패합니다.

참조되지 않은 관리 파일 삭제

자동 가비지 컬렉션은 지원되지 않으니, 참조되지 않은 파일을 직접 삭제하세요. 다음 노트북은 FileSpace에서 어느 테이블 버전에서도 참조되지 않는 파일을 찾아내고, 선택적으로 삭제합니다:

파일 유형 가비지 컬렉션 노트북

노트북 받기

FILE EXTERNAL

FILE EXTERNAL 열은 이미 Unity 카탈로그 볼륨에 존재하는 파일에 대한 참조입니다.

볼륨에 필요한 권한이 있다면 이 파일들을 업데이트하거나 삭제할 수 있습니다. Databricks에서는 변경 불가능한 파일을 사용하는 것을 권장합니다. 테이블 부여는 파일 메타데이터를 노출하지만, 파일의 바이트를 읽으려면 기본 볼륨에 대한 권한이 필요합니다 READ VOLUME .

외부 파일은 각 테이블 행을 Unity 카탈로그 볼륨 내 기존 경로에 있는 파일로 매핑합니다:

임상 시험 파일이 단계별 폴더 아래에 정리되어 EXTERNAL FILE 열에 매핑된 UC 볼륨의 다이어그램입니다. 각 테이블 행은 볼륨 경로로 파일을 참조하며, Cohort와 Study Phase와 같은 구조화된 열을 추가합니다.

FILE EXTERNAL 예제

열이 있는 FILE EXTERNAL 테이블을 만들려면:

CREATE TABLE documents (id BIGINT, file FILE EXTERNAL);

기존 테이블에 열을 추가 FILE EXTERNAL 하려면:

ALTER TABLE documents ADD COLUMN file FILE EXTERNAL;

볼륨에서 테이블을 생성하고 채우기 위해, 각 파일에 고유 ID를 할당하려면:

CREATE TABLE documents AS
  SELECT monotonically_increasing_id() AS id, file
  FROM list_files('/Volumes/samples/sec/contracts/');

거버넌스 및 생애주기 비교

다음 표는 FILE MANAGED와 FILE EXTERNAL가 파일 액세스를 제어하고 파일 수명 주기를 처리하는 방식을 비교합니다:

열 형식 FILE MANAGED FILE EXTERNAL
파일 접근 제어 테이블의 SELECT 및 볼륨의 READ VOLUME와 같은 테이블 및 볼륨 권한에 의해 제어됩니다. .와 같은 READ VOLUME볼륨 권한에 의해 제어됩니다.
수명 주기 및 가비지 수집 파일은 그것을 참조하는 행에 묶여 있습니다. 그 행들을 삭제하면 파일이 가비지 컬렉션 대상이 됩니다. 자동 가비지 컬렉션은 지원되지 않습니다. 직접 파일을 관리하세요. 테이블 행을 삭제해도 볼륨 내 기본 파일에 영향을 주지 않습니다.

FILE 타입 사용 사례

관리 방식과 외부 FILE 유형 모두 비정형 데이터를 사용하는 사용 사례에서 다음과 같은 도전 과제를 해결합니다:

과제 지원되는 FILE 유형 Benefits
인라인으로 저장할 수 없을 만큼 큰 파일 BINARY FILE MANAGED 또는 FILE EXTERNAL 열은 FILE 참조를 저장하므로, AI 함수나 UDF가 처리할 때만 파일을 읽습니다. 이렇게 하면 테이블 내에서 큰 물체가 일렬로 나타나는 것을 방지할 수 있습니다.
파일 시스템과 테이블 간의 분리된 라이프사이클과 거버넌스 FILE MANAGED Azure Databricks는 각 파일의 수명 주기를 테이블에 연결해, 행을 삭제하면 파일이 저장소에 고아 파일로 남는 대신 정리 대상이 되도록 합니다.
파일이 같은 위치에 있어야 하는 동시 작업 부하 FILE EXTERNAL 파일은 기존 볼륨 경로에 머물며 테이블 수명 주기에 영향을 받지 않기 때문에, 같은 파일을 읽는 다른 도구들이 방해받지 않습니다.

다음 단계

  • Last updated on