Tipo di file e dati non strutturati

Importante

Questa funzionalità è in versione beta. Gli amministratori dell'area di lavoro possono controllare l'accesso a questa funzionalità dalla pagina Anteprime . Vedere Gestire le anteprime di Azure Databricks.

Il FILE tipo memorizza un riferimento governato a un file non strutturato, con metadati come percorso e dimensione. Usa FILE le colonne nel Catalogo Unity per memorizzare documenti, immagini e audio insieme a dati strutturati.

Con FILE MANAGED le colonne, Unity Catalog memorizza copie dei file e le gestisce con la tabella: eliminando le righe, i file citati sono idonei per la raccolta della spazzatura, così la tabella e i suoi file rimangono sincronizzati.

Per il riferimento tipografico, vedi FILE tipo.

Il diagramma seguente mostra una FILE colonna denominata video che fa riferimento a clip di guida, insieme a colonne strutturate come percorso, descrizione della scena ed etichetta di pericolo:

Una tabella di clip di guida in cui la colonna video è di tipo FILE. Ogni riga abbina colonne strutturate (ID clip, percorso, descrizione della scena, etichetta di pericolo e un embedding) con un riferimento a file video che mostra una miniatura e una dimensione come 1,8 GB.

Metadati e memorizzazione del file

Per ogni riga, il FILE tipo memorizza i metadati e un collegamento regolato al file in archiviazione. Un valore FILE include i campi di metadati uri, size, content_type e checksum. Le query di metadati non richiedono letture complete dei file, migliorando le prestazioni delle query.

Puoi passare FILE valori a funzioni IA, come ai_parse_document funzioni, e a funzioni definite dall'utente (UDF).

Il diagramma seguente mostra un esempio di colonna gestita FILE , contenente metadati di percorso e dimensione e riferimenti ai file in archiviazione:

La tabella clips con la colonna video memorizzata come tipo FILE, mostrata come coppia di percorso e dimensione. Le frecce collegano ogni riga al relativo file nell'archiviazione, illustrando un riferimento gestito tra la tabella e i file.

Accesso a metadati e contenuti

Un valore ha due parti, e l'accesso FILE a ciascuna è governato in modo diverso:

  • I metadati dei file (uri, size, content_type, e checksum) sono memorizzati nei file dati della tabella stessa. Chiunque abbia SELECT sul tavolo può leggerlo.
  • Il contenuto dei file resta in deposito. Per leggerli è necessario accedere al file: READ VOLUME sul volume sottostante per FILE EXTERNAL, oppure accesso sia alla tabella che al volume che supporta il FileSpace per FILE MANAGED.

Convertire un valore FILE in BINARY o STRING, passarlo a una funzione AI o UDF e visualizzarlo nella tabella dei risultati leggono il contenuto del file. Poiché i metadati fanno parte della tabella, il percorso e la dimensione di un file sono visibili a chiunque possa interrogare la tabella, anche senza accesso al contenuto.

Per visualizzare i file in anteprima nei risultati delle query, vedi File di anteprima nelle colonne FILE.

Perché usare FILE invece di BINARY o STRING

La seguente tabella dettaglia le difficoltà nella gestione di file non strutturati di grandi dimensioni con BINARY o STRING tipi:

Tipo di colonna Description Diagram
BINARY Materializza l'oggetto completo per ogni lettura, anche quando servono solo metadati come la dimensione o il percorso del file. Questo comporta calcoli inutili e richieste lente. La tabella dei filmati con la colonna video memorizzata in formato BINARY. I byte grezzi di ogni video di diversi gigabyte vengono materializzati direttamente nella colonna.
STRING Memorizza un percorso di file senza metadati, come informazioni di dimensione o versione, e senza un collegamento governato tra la tabella e il file. Se un altro carico di lavoro rimuove il file, la tabella ha informazioni obsolete. Se rimuovi una riga di tabella, il file citato rimane in archiviazione finché non lo rimuovi manualmente. La tabella dei clip con la colonna video memorizzata come percorso di tipo STRING, ad esempio s3://.../NW-0142. Uno dei percorsi non punta più a un file nel volume, a dimostrazione del fatto che i percorsi memorizzati come stringhe non garantiscono l'esistenza dei file e che la governance risulta scollegata.

Checksum

Il checksum campo è un token di integrità per i byte del file, della forma <prefix>:<digest>. Usalo per confrontare i file o verificare che un file non sia cambiato. I lettori ignorano un checksum con un prefisso non riconosciuto.

Un checksum non è sempre disponibile. to_file funzione, create_file funzione e copy_file funzione compilano la somma di controllo quando l'archivio oggetti restituisce un ETAG. list_files La funzione a valori di tabella e read_files la funzione a valori di tabella non popolano il checksum.

Il checksum campo utilizza uno dei seguenti prefissi:

Prefisso Codifica del digest Description
ETAG Opaque L'eTag dello store oggetti per l'intero file. Fornito parola per parola dal store, usato solo per il confronto di uguaglianza e non ricalcolabile.
MD5 Esadecimale minuscolo Un digest MD5 (RFC 1321), 32 caratteri esadecimali.
CRC32 Esadecimale minuscolo Un checksum CRC32 (RFC 2083), 8 caratteri esadecimali.
CRC32C Esadecimale minuscolo Un checksum CRC32C (RFC 3385), 8 caratteri esadecimali.
SHA-256 Esadecimale minuscolo Un digest SHA-256 (RFC 6234), 64 caratteri esadecimali.

Ad esempio, un checksum MD5 ha un aspetto simile a MD5:d41d8cd98f00b204e9800998ecf8427e, e un eTag di un archivio di oggetti ha un aspetto simile a ETAG:"686897696a7c876b7e", incluse le virgolette doppie circostanti restituite dall’archivio di oggetti.

Seleziona tra FILE e BINARY

La tabella seguente confronta le opzioni per lavorare con file non strutturati:

Tipo di colonna Values Caso di utilizzo
FILE Un riferimento regolato a un file, più i metadati (uri, size, content_type, checksum). Utilizzato per gestire ed elaborare file non strutturati insieme a dati strutturati, e per passare file a funzioni integrate e di IA.
BINARY I byte grezzi di un file, in linea in una colonna. Utilizzare per piccoli oggetti (fino a 64 KB di default) memorizzati direttamente nel file dati. Questo è utile quando hai bisogno di un basso overhead di metadati e una gestione dei file semplificata. Ad esempio, usa questo per memorizzare miniature in linea con i dati della riga.

FILE GESTITO e FILE ESTERNO

Il FILE tipo supporta due approcci per la gestione dei file:

  • FILE MANAGED le colonne copiano i file nella memoria gestita. I permessi sono semplificati e gestiti tramite la tabella. Quando elimini le righe o le aggiorni per fare riferimento a file diversi, i file non referenziati diventano idonei per la raccolta della spazzatura, così la tabella e i suoi file rimangono sincronizzati. Utilizzare questo approccio per carichi di lavoro che accedono ai file tramite una tabella, come l'addestramento ML o la generazione aumentata al recupero (RAG), e per file ingeriti da fonti esterne. Per i modelli di ingestione, vedi i file Ingest come tipo FILE.
  • FILE EXTERNAL le colonne fanno riferimento a file esistenti in un volume del Catalogo Unity. I file sono protetti dai permessi di volume del Catalogo Unity, ma il loro ciclo di vita non è gestito dal Catalogo Unity e non vengono copiati. Usa questo approccio quando hai bisogno di fare riferimento ai file senza spostare dati o interrompere strumenti che leggono da un volume esistente.

Azure Databricks raccomanda FILE MANAGED per carichi di lavoro che beneficiano di permessi a livello di file e conformità integrata: l'accesso a ogni file è regolato tramite la tabella che lo riferisce, e eliminare le righe rende i file referenziati idonei per la raccolta dei rifiuti. Usa FILE EXTERNAL quando i file devono rimanere nei percorsi del volume esistenti per essere letti dagli strumenti al di fuori della tabella.

Per le query, non c'è differenza tra file gestiti ed esterni.

Il diagramma seguente mostra come il FILE tipo collega il tuo codice ai file nello storage di oggetti cloud:

Diagramma dell'architettura dei tipi FILE. I client Python, SQL, Scala e UDF lavorano con un unico tipo di file che legge i metadati senza dover recuperare byte del file. FILE MANAGED memorizza i file in un FileSpace dove l'accesso è regolato a livello di tabella e la cancellazione delle righe rende i file idonei per la raccolta della spazzatura. FILE EXTERNAL riferisce i file sui loro percorsi esistenti in un volume UC, regolati dai permessi del volume. Entrambe le modalità memorizzano file in archiviazione cloud di oggetti come S3, ADLS o Google Cloud Storage.

FILE MANAGED

FILE MANAGED colonne memorizzano copie dei file in un FileSpace, un volume di Unity Catalog che dichiari affinché la tabella lo utilizzi come storage gestito. Il loro ciclo di vita è legato alle tabelle che li riferiscono: eliminare le righe rende i file citati idonei per la raccolta della spazzatura, così la tabella e i suoi file rimangono sincronizzati.

I seguenti comportamenti si applicano a FILE MANAGED:

  • Dichiarare il FileSpace richiede la databricks.filespace-preview proprietà della tabella.
  • La lettura o la scrittura di un file gestito richiede l'accesso sia alla tabella sia al volume che sottende il FileSpace
  • La raccolta automatica dei file non referenziati non è supportata in Beta.

I file non strutturati archiviati in origini esterne come SharePoint, Google Drive, OneDrive e SFTP devono essere acquisiti come file gestiti prima di poter essere utilizzati con funzioni come ai_parse_document funzione e funzioni definite dall'utente (UDF). Per i modelli di ingestione, vedi i file Ingest come tipo FILE.

Per utilizzare i file gestiti, crea una tabella con una colonna FILE MANAGED e dichiara un volume come FileSpace impostando la proprietà della tabella databricks.filespace-preview su un percorso di volume:

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

Per esempi completi, vedi i seguenti FILE MANAGED esempi.

FILE MANAGED esempi

Per creare una tabella con una FILE MANAGED colonna:

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

Per aggiungere una FILE MANAGED colonna a una tabella esistente, imposta la proprietà della databricks.filespace-preview tabella prima di aggiungere la colonna, come nel seguente codice:

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

ALTER TABLE reports ADD COLUMN attachment FILE MANAGED;

L'aggiunta di una colonna FILE MANAGED a una tabella che non ha FileSpace non riesce.

Elimina i file gestiti non referenziati

Poiché la raccolta automatica dei rifiuti non è supportata, elimina tu stesso i file senza riferimenti. Il seguente notebook individua i file in un FileSpace a cui non fa riferimento alcuna versione della tabella e, facoltativamente, li elimina:

Blocco disegni di raccolta dei rifiuti FileType

Ottieni il notebook

FILE EXTERNAL

FILE EXTERNAL le colonne sono riferimenti a file già esistenti in un volume del Catalogo Unity.

Se hai i privilegi necessari sul volume, puoi aggiornare o eliminare questi file. Databricks consiglia di usare file immutabili. Una concessione di tabella espone i metadati del file, ma la lettura dei byte del file richiede anche il READ VOLUME privilegio sul volume sottostante.

Un file esterno mappa ogni riga di tabella a un file sul suo percorso esistente in un volume del Catalogo Unity:

Un diagramma di un volume UC contenente file di prova organizzati sotto cartelle di fase, mappato su una colonna FILE ESTERNO. Ogni riga della tabella fa riferimento a un file tramite il suo percorso di volume e aggiunge colonne strutturate come Cohort e Study Phase.

FILE EXTERNAL esempi

Per creare una tabella con una FILE EXTERNAL colonna:

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

Per aggiungere una FILE EXTERNAL colonna a una tabella esistente:

ALTER TABLE documents ADD COLUMN file FILE EXTERNAL;

Per creare e popolare una tabella da un volume, assegnando ID unici a ciascun file:

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

Confronto tra governance e ciclo di vita

La tabella seguente confronta come FILE MANAGED e FILE EXTERNAL regolano l'accesso ai file e gestiscono il ciclo di vita dei file:

Tipo di colonna FILE MANAGED FILE EXTERNAL
Controllo di accesso ai file Regolati dai permessi di tabella e volume, come quelli SELECT sulla tabella e READ VOLUME sul volume. Regolati da permessi di volume, come READ VOLUME.
Ciclo di vita e Garbage Collection I file sono legati alle righe che li richiamano. Eliminare quelle righe rende i file idonei per la raccolta dei rifiuti. La raccolta automatica dei rifiuti non è supportata. Gestisci i file da solo. Eliminare una riga di tabella non influisce sul file sottostante nel volume.

Casi d'uso di tipo FILE

Sia i tipi gestiti che quelli esterni FILE affrontano le seguenti sfide per i casi d'uso che utilizzano dati non strutturati:

Sfida Tipo supportato FILE Benefits
File troppo grandi per essere archiviati in linea come BINARY FILE MANAGED oppure FILE EXTERNAL Una FILE colonna memorizza un riferimento, quindi un file viene letto solo quando una funzione AI o un UDF lo elabora. Questo evita che oggetti grandi si materializzino in fila nel tavolo.
Ciclo di vita e governance scollegati tra il file system e la tabella FILE MANAGED Azure Databricks collega il ciclo di vita di ogni file alla tabella, quindi eliminare le righe rende i file idonei alla pulizia invece di lasciare file orfani in archiviazione.
Carichi di lavoro concorrenti che richiedono che i file restino nella stessa posizione FILE EXTERNAL I file rimangono nei loro percorsi di volume esistenti, non influenzati dal ciclo di vita della tabella, quindi altri strumenti che leggono gli stessi file non vengono disturbati.

Passaggi successivi

  • Last updated on