Important
這項功能位於 測試版 (Beta) 中。 工作區管理員可以從 「預覽 」頁面控制對此功能的存取。 請參閱 管理 Azure Databricks 預覽。
此 FILE 型別儲存一個受控的非結構化檔案參考，並包含路徑與大小等元資料。 在 Unity 目錄中使用 FILE 欄位來存放文件、圖片和音訊，並列結構化資料。
有了 FILE MANAGED 欄位，Unity Catalog 會儲存檔案的副本並用表格來管理：刪除列後，參考的檔案才有資格進行垃圾回收，因此表格和檔案會保持同步。
關於類型參考，請參見 FILE 類型。
下圖顯示一個 FILE 命名 video 欄位，與結構化欄位如路線、場景描述及危險標籤並列：
FILE 元資料與儲存
對於每個資料列，FILE 類型會儲存中繼資料，以及指向儲存體中該檔案的受控連結。 一個 FILE 值包含 uri、 size、 content_type和 checksum 元資料欄位。 元資料查詢不需要完整讀取檔案，提升查詢效能。
你可以將數值傳FILE給 AI 函式，例如 functionai_parse_document，以及使用者定義函數（UDF）。
下圖顯示一個受管理的 FILE 欄位範例，其中包含路徑和大小中繼資料，以及對儲存體中檔案的參照：
元資料與內容存取
一個 FILE 價值分為兩部分，且對每個部分的存取方式不同：
- 檔案中繼資料（
uri、、content_typesizechecksum和 ）會儲存在資料表本身的資料檔案中。 任何桌上有SELECT的人都可以讀取其內容。 - 檔案內容會保留在儲存空間。 若要讀取它們，需要存取
FILE EXTERNAL所在基礎磁碟區上的檔案：READ VOLUME，或同時存取資料表以及作為FILE MANAGED的FileSpace後端的磁碟區。
將 FILE 值轉換為 BINARY 或 STRING、傳遞給 AI 函式或 UDF，以及在結果表中預覽，皆會讀取其檔案內容。 由於中繼資料是資料表的一部分，即使無法存取內容，任何能查詢資料表的人都能看到檔案的路徑與大小。
要預覽查詢結果中的檔案，請參見「 FILE 欄位中的預覽檔案」。
為什麼要用 FILE 而不是 BINARY 或 STRING
下表詳細說明處理大型非結構化檔案時BINARYSTRING的挑戰：
| 欄位類型 | Description | 圖表 |
|---|---|---|
BINARY |
每次讀取時都會將整個物件實體化，即使你只需要檔案大小或路徑等中繼資料。 這導致不必要的計算和緩慢的查詢。 |
|
STRING |
儲存一個沒有元資料（如大小或版本資訊）的檔案路徑，且資料表與檔案之間沒有受控的連結。 如果其他工作負載移除該檔案，該資料表的資訊會過時。 如果你移除某一列資料表，該參考檔案會一直存在儲存空間，直到你手動移除為止。 |
|
校驗
欄位 checksum 是檔案位元組的完整性標記，形式 <prefix>:<digest>為 。 用它來比較檔案或確認檔案沒有變動。 讀取器會忽略帶有未識別前綴的校驗碼。
校驗碼並不總是有。 to_file 函式、create_file 函式以及 函式會在物件儲存體傳回 時填入校驗和。
list_files table-valued 函式 和 read_files table-valued函式 不會填入校驗和。
該 checksum 欄位使用以下其中一個前綴：
| 前綴 | 摘要編碼 | Description |
|---|---|---|
ETAG |
Opaque | 物件儲存的 eTag 是整個檔案的。 由商店逐字提供，僅用於平等比較，且不可重新計算。 |
MD5 |
小寫十六進位 | MD5摘要（RFC 1321），包含32個十六進位字元。 |
CRC32 |
小寫十六進位 | 一個 CRC32 校驗碼（RFC 2083），8 個十六進位字元。 |
CRC32C |
小寫十六進位 | 一個 CRC32C 校驗碼（RFC 3385），8 個十六進位字元。 |
SHA-256 |
小寫十六進位 | 一個 SHA-256 摘要（RFC 6234），64 個十六進位字元。 |
例如，MD5 校驗碼看起來像 MD5:d41d8cd98f00b204e9800998ecf8427e，而物件儲存體的 eTag 則看起來像 ETAG:"686897696a7c876b7e"，其中包含物件儲存體回傳的前後雙引號。
選擇 FILE 和 BINARY 之間的項目
下表比較了處理非結構化檔案的各種選項：
| 欄位類型 | 價值 | 應用案例 |
|---|---|---|
FILE |
一個受控的檔案參考，加上元資料（uri， size， content_typechecksum， ）。 |
用於管理及處理非結構化檔案和結構化資料，並將檔案傳遞給內建函式和 AI 函式。 |
BINARY |
檔案的原始位元組，內嵌在欄位中。 | 用於直接儲存在資料檔中的小型物件（預設最高可達 64 KB）。 當你需要低元資料負擔和簡化檔案管理時，這很有用。 例如，可以用它來儲存與列資料相連的縮圖。 |
受管理檔案和外部檔案
此 FILE 類型支援兩種檔案管理方式：
-
FILE MANAGED欄位將檔案複製到管理儲存空間。 權限會透過表格進行簡化與管理。 當你刪除列或更新資料列以參考不同檔案時，未被引用的檔案就有資格進行垃圾回收，因此資料表和檔案會保持同步。此方法適用於透過資料表存取檔案的工作負載，例如機器學習訓練或檢索增強生成（RAG），以及從外部來源擷取的檔案。 如需了解擷取模式，請參閱 以 FILE 類型擷取檔案。 -
FILE EXTERNAL欄位則指向 Unity 目錄卷中現有的檔案。 檔案是由 Unity Catalog 的磁碟權限保護，但它們的生命週期不由 Unity Catalog 管理，也不會被複製。 當你需要參考檔案而不移動資料或干擾從現有磁碟區讀取工具時，請使用此方法。
Azure Databricks 建議FILE MANAGED適合需要檔案層級權限與內建合規性的工作負載：每個檔案的存取權由參考資料表管理，刪除資料列後，該檔案才有資格進行垃圾回收。 當檔案必須保留在其現有的磁碟區路徑中，以供在資料表外部讀取這些檔案的工具使用時，請使用 FILE EXTERNAL。
查詢時，管理檔案與外部檔案沒有差別。
下圖顯示此類型如何透過 FILE 將你的程式碼連結至雲端物件儲存中的檔案：
FILE MANAGED
FILE MANAGED 資料行會將檔案副本儲存在 FileSpace 中；FileSpace 是一個為供資料表作為受控儲存體而宣告的 Unity Catalog 磁碟區。 它們的生命週期與參考資料表綁定：刪除資料列後，被參考的檔案有資格進行垃圾回收，因此資料表與檔案保持同步。
以下行為適用於 FILE MANAGED：
- 宣告
FileSpace需要databricks.filespace-preview資料表屬性。 - 讀取或寫入受管理檔案，需要同時存取資料表，以及作為
FileSpace後端的磁碟區。 - Beta 版不支援對未被參照的檔案進行自動垃圾回收。
儲存在 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 table 屬性再新增欄位，如下程式碼所示：
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 中沒有任何資料表版本參考的檔案，並可選擇刪除這些檔案：
FileType 垃圾回收筆記本
FILE EXTERNAL
FILE EXTERNAL 欄位是對已存在於 Unity Catalog 磁碟區中的檔案的參照。
如果你擁有該卷所需的權限，就可以更新或刪除這些檔案。 Databricks 建議你使用不可變檔案。 資料表授權會暴露檔案元資料，但讀取檔案位元組也需要對底層磁碟區擁有 READ VOLUME 權限。
外部檔案會將每個資料表資料列對應至 Unity Catalog 磁碟區中其現有路徑上的檔案：
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 MANAGEDFILE 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 |
檔案會保留在現有的磁碟區路徑中，不受資料表生命週期的影響，因此其他會讀取相同檔案的工具也不會受到干擾。 |