FILE-Typ und unstrukturierte Daten

Important

Dieses Feature befindet sich in der Betaversion. Arbeitsbereichsadministratoren können den Zugriff auf dieses Feature über die Vorschauseite steuern. Siehe Manage Azure Databricks Previews.

Der Typ FILE speichert eine kontrollierte Referenz auf eine unstrukturierte Datei mit Metadaten wie Pfad und Größe. Verwenden Sie FILE Spalten im Unity-Katalog, um Dokumente, Bilder und Audiodateien neben strukturierten Daten zu speichern.

Mit FILE MANAGED Spalten speichert Unity Catalog Kopien der Dateien und verwaltet sie zusammen mit der Tabelle: Durch das Löschen von Zeilen werden die referenzierten Dateien für die Garbage Collection freigegeben, sodass die Tabelle und ihre Dateien synchron bleiben.

Für die Typreferenz siehe FILE Typ.

Das folgende Diagramm zeigt eine FILE Spalte namens video, die auf Fahrclips verweist, neben strukturierten Spalten wie der Route, Szenenbeschreibung und Gefahrenlabel:

Eine Tabelle mit Antriebsclips, bei der die Videospalte ein DATEI-Typ ist. Jede Zeile koppelt strukturierte Spalten (Clip-ID, Route, Szenenbeschreibung, Gefahrenetikett und Einbettung) mit einer Videodatei-Referenz, die ein Vorschaubild und eine Größe wie 1,8 GB zeigt.

FILE-Metadaten und Speicher

Für jede Zeile speichert der Typ FILE Metadaten und einen verwalteten Link zur gespeicherten Datei. Ein FILE Wert enthält uri, size, content_type, und checksum Metadatenfelder. Metadaten-Abfragen erfordern keine vollständigen Dateilesungen, was die Abfrageleistung verbessert.

Sie können Werte an ai_parse_document übergeben, z. B. an die -Funktion und an FILE.

Das folgende Diagramm zeigt ein Beispiel für eine verwaltete Spalte FILE , die Pfad- und Größenmetadaten sowie Verweise auf die gespeicherten Dateien enthält:

Die Clips-Tabelle, in der die Videospalte als DATEI-Typ gespeichert ist, dargestellt als Paar aus Pfad und Größe. Pfeile verbinden jede Zeile mit ihrer Datei im Speicher und veranschaulichen eine verwaltete Referenz zwischen der Tabelle und den Dateien.

Zugriff auf Metadaten und Inhalte

Ein Wert besteht aus zwei Teilen, und der FILE Zugang zu jedem wird unterschiedlich geregelt:

  • Dateimetadaten (uri, size, content_type, und checksum) werden in den eigenen Datendateien der Tabelle gespeichert. Jeder, der SELECT auf dem Tisch liegen hat, kann es lesen.
  • Der Inhalt der Dateien bleibt im Lager. Zum Lesen ist der Zugriff auf die Datei READ VOLUME auf dem zugrunde liegenden Volume für FILE EXTERNAL oder der Zugriff sowohl auf die Tabelle als auch auf das Volume erforderlich, das dem FileSpace für FILE MANAGED zugrunde liegt.

Das Umwandeln eines FILE-Werts in BINARY oder STRING, das Übergeben an eine KI-Funktion oder UDF und die Vorschau in der Ergebnistabelle lesen allesamt Dateiinhalte. Da die Metadaten Teil der Tabelle sind, sind der Pfad und die Größe einer Datei für jeden sichtbar, der die Tabelle abfragen kann, auch ohne Zugriff auf den Inhalt.

Um Dateien in Abfrageergebnissen vorzusehen, siehe Vorschaudateien in den FILE-Spalten.

Warum FILE statt BINARY oder STRING verwenden

Die folgende Tabelle beschreibt die Herausforderungen beim Umgang mit großen unstrukturierten Dateien mit BINARY oder STRING Typen:

Spaltentyp Description Diagramm
BINARY Materialisiert das vollständige Objekt für jede Lesung, selbst wenn man nur Metadaten wie Dateigröße oder Pfad benötigt. Dies führt zu unnötigen Berechnungen und langsamen Abfragen. Die Clips-Tabelle mit einer als BINARY gespeicherten Videospalte. Die Rohbytes jedes mehrere Gigabyte großen Videos werden direkt in der Spalte gespeichert.
STRING Speichert einen Dateipfad ohne Metadaten, wie etwa Größe oder Versionsinformationen, und ohne kontrollierte Verbindung zwischen Tabelle und Datei. Wenn eine andere Arbeitslast die Datei entfernt, enthält die Tabelle veraltete Informationen. Wenn du eine Tabellenzeile entfernst, bleibt die referenzierte Datei im Speicher, bis du sie manuell entfernst. Die Clips-Tabelle mit der als STRING-Pfad gespeicherten Spalte „video“, z. B. s3://.../NW-0142. Ein Pfad verweist nicht mehr auf eine Datei im Volume, was zeigt, dass STRING-Pfade nicht garantieren, dass Dateien existieren und dass die Governance nicht verknüpft ist.

Prüfsummen

Das Feld checksum ist ein Integritätstoken für die Bytes der Datei, in der Form <prefix>:<digest>. Nutze es, um Dateien zu vergleichen oder zu überprüfen, ob sich eine Datei nicht verändert hat. Leser ignorieren eine Prüfsumme mit einem nicht anerkannten Präfix.

Eine Checksumme ist nicht immer verfügbar. to_file Funktion, create_file Funktion und copy_file Funktion füllen die Prüfsumme aus, wenn der Objektspeicher ein ETAGFormular zurückgibt. list_files Tabellenwerte Funktionen und read_files tabellenwertige Funktionen füllen die Prüfsumme nicht aus.

Das Feld checksum verwendet eines der folgenden Präfixe:

Präfix Digest-Codierung Description
ETAG Opaque Das eTag des Objektspeichers für die gesamte Datei. Unverändert vom Store bereitgestellt, nur für Gleichheitsvergleiche verwendet und nicht neu berechenbar.
MD5 Hex in Kleinbuchstaben Ein MD5-Digest (RFC 1321), 32 Hexzeichen.
CRC32 Hex in Kleinbuchstaben Eine CRC32-Prüfsumme (RFC 2083), 8 Hexzeichen.
CRC32C Hex in Kleinbuchstaben Eine CRC32C-Prüfsumme (RFC 3385), 8 Hexzeichen.
SHA-256 Hex in Kleinbuchstaben Ein SHA-256-Digest (RFC 6234), 64 Hexzeichen.

Zum Beispiel sieht eine MD5-Prüfsumme so MD5:d41d8cd98f00b204e9800998ecf8427eaus, und ein objektspeichernder eTag sieht aus wie ETAG:"686897696a7c876b7e", einschließlich der umgebenden doppelten Anführungszeichen, die vom Objektspeicher zurückgegeben werden.

Wählen Sie zwischen FILE und BINARY

Die folgende Tabelle vergleicht die Optionen für die Arbeit mit unstrukturierten Dateien:

Spaltentyp Werte Anwendungsfall
FILE Eine kontrollierte Referenz auf eine Datei plus Metadaten (uri, size, content_type, checksum). Verwendung zur Verwaltung und Verarbeitung unstrukturierter Dateien zusammen mit strukturierten Daten sowie zur Weitergabe von Dateien an integrierte und KI-Funktionen.
BINARY Die Rohbytes einer Datei, direkt in einer Spalte. Verwendung für kleine Objekte (standardmäßig bis zu 64 KB), die direkt in der Datendatei gespeichert sind. Das ist nützlich, wenn man einen geringen Metadaten-Overhead und eine vereinfachte Dateiverwaltung benötigt. Verwenden Sie dies zum Beispiel, um Vorschaubilder direkt zusammen mit den Zeilendaten zu speichern.

FILE MANAGED und FILE EXTERNAL

Der Typ FILE unterstützt zwei Ansätze zur Verwaltung der Dateien:

  • FILE MANAGED Spalten kopieren Dateien in verwalteten Speicher. Die Berechtigungen werden vereinfacht und über die Tabelle verwaltet. Wenn Sie Zeilen löschen oder sie aktualisieren, um auf andere Dateien zu referenzieren, werden die unreferenzierten Dateien für die Garbage Collection geeignet, sodass die Tabelle und ihre Dateien synchron bleiben. Verwenden Sie diesen Ansatz für Arbeitslasten, die über eine Tabelle auf Dateien zugreifen, wie ML-Training oder Retrieval-Augmented Generation (RAG), sowie für Dateien, die von externen Quellen importiert wurden. Für Erfassungsmuster lesen Sie Dateien als DATEI-Typ erfassen.
  • FILE EXTERNAL Spalten beziehen sich auf bestehende Dateien in einem Unity-Katalog-Volume. Die Dateien sind durch Unity-Katalog-Volume-Berechtigungen gesichert, aber ihr Lebenszyklus wird nicht von Unity Catalog verwaltet und sie werden nicht kopiert. Verwenden Sie diesen Ansatz, wenn Sie Dateien referenzieren müssen, ohne Daten zu verschieben oder Werkzeuge zu stören, die von einem bestehenden Volume lesen.

Azure Databricks empfiehlt FILE MANAGED für Workloads, die von Dateiberechtigungen und integrierter Compliance profitieren: Der Zugriff auf jede Datei erfolgt über die Tabelle, die sie referenziert, und das Löschen von Zeilen macht die referenzierten Dateien für die Garbage Collection geeignet. Verwenden Sie FILE EXTERNAL, wenn Dateien an ihren vorhandenen Volumepfaden verbleiben müssen, damit Tools, die sie außerhalb der Tabelle lesen, darauf zugreifen können.

Bei Abfragen gibt es keinen Unterschied zwischen verwalteten und externen Dateien.

Das folgende Diagramm zeigt, wie der FILE Typ Ihren Code mit Dateien im Cloud-Objektspeicher verbindet:

Diagramm der FILE-Typ-Architektur. Python-, SQL-, Scala- und UDF-Clients arbeiten mit einem einzigen DATEI-Typ, der Metadaten liest, ohne Dateibytes abzurufen. FILE MANAGED speichert Dateien in einem FileSpace, in dem der Zugriff auf Tabellenebene geregelt ist und das Löschen von Zeilen Dateien für die Garbage Collection berechtigt macht. FILE EXTERNE referenziert Dateien auf ihren bestehenden Pfaden in einem UC-Volume, die durch Volume-Berechtigungen geregelt werden. Beide Modi speichern Dateien in Cloud-Objektspeichern wie S3, ADLS oder Google Cloud Storage.

FILE MANAGED

FILE MANAGED Spalten speichern Kopien von Dateien in einem FileSpaceUnity-Katalog-Volume, das Sie für die Tabelle als verwalteten Speicher deklarieren. Ihr Lebenszyklus ist an die Tabellen gebunden, die auf sie verweisen: Das Löschen von Zeilen macht die referenzierten Dateien für die Garbage Collection geeignet, sodass die Tabelle und ihre Dateien synchron bleiben.

Die folgenden Verhaltensweisen gelten für FILE MANAGED:

  • Das Deklarieren von FileSpace erfordert die Tabelleneigenschaft databricks.filespace-preview.
  • Das Lesen oder Schreiben einer verwalteten Datei erfordert Zugriff sowohl auf die Tabelle als auch auf das Volumen, das das FileSpaceunterstützt.
  • Automatische Garbage Collection von unreferenzierten Dateien wird in der Beta nicht unterstützt.

Unstrukturierte Dateien, die in externen Quellen wie SharePoint, Google Drive, OneDrive und SFTP gespeichert sind, müssen als verwaltete Dateien importiert werden, bevor Sie sie mit Funktionen wie ai_parse_document Funktion und benutzerdefinierten Funktionen (UDFs) verwenden können. Für Erfassungsmuster lesen Sie Dateien als DATEI-Typ erfassen.

Um verwaltete Dateien zu verwenden, erstellen Sie eine Tabelle mit einer Spalte FILE MANAGED und deklarieren Sie ein Volumen als die FileSpace , indem Sie die databricks.filespace-preview Tabelleneigenschaft auf einen Volumenpfad setzen:

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

Vollständige Beispiele finden Sie in den folgenden FILE MANAGED Beispielen.

FILE MANAGED-Beispiele

Um eine Tabelle mit einer Spalte FILE MANAGED zu erstellen:

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

Um eine FILE MANAGED Spalte zu einer bestehenden Tabelle hinzuzufügen, setze die databricks.filespace-preview Tabelleneigenschaft vor dem Hinzufügen der Spalte, wie im folgenden Code:

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

ALTER TABLE reports ADD COLUMN attachment FILE MANAGED;

Das Hinzufügen einer FILE MANAGEDSpalte zu einer Tabelle ohne FileSpace schlägt fehl.

Lösche von unreferenzierten verwalteten Dateien

Da automatische Garbage Collection nicht unterstützt wird, lösche unreferenzierte Dateien selbst. Das folgende Notebook findet die Dateien in einem FileSpace, auf die keine Tabellenversion verweist, und löscht sie optional:

FileType-Speicherbereinigungs-Notebook

Notebook abrufen

FILE EXTERNAL

FILE EXTERNAL Spalten sind Verweise auf Dateien, die bereits in einem Unity-Katalog-Volume existieren.

Wenn du die erforderlichen Rechte auf dem Volume hast, kannst du diese Dateien aktualisieren oder löschen. Databricks empfiehlt, unveränderliche Dateien zu verwenden. Eine Tabellenberechtigung macht die Dateimetadaten verfügbar, aber das Lesen der Bytes der Datei erfordert auch das READ VOLUME-Privileg auf dem zugrunde liegenden Datenträger.

Eine externe Datei weist jede Tabellenzeile auf eine Datei auf ihrem bestehenden Pfad in einem Unity-Catalog-Volume zu:

Ein Diagramm eines UC-Volumens mit Versuchsdateien, die in Phasenordnern organisiert und einer Spalte EXTERNAL FILE zugeordnet sind. Jede Tabellenzeile verweist über ihren Volumenpfad auf eine Datei und ergänzt strukturierte Spalten wie Kohorte und Studienphase.

FILE EXTERNAL-Beispiele

Um eine Tabelle mit einer Spalte FILE EXTERNAL zu erstellen:

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

Um eine FILE EXTERNAL Spalte zu einer bestehenden Tabelle hinzuzufügen:

ALTER TABLE documents ADD COLUMN file FILE EXTERNAL;

Um eine Tabelle aus einem Volume zu erstellen und zu füllen, wobei jeder Datei eindeutige IDs zugewiesen werden:

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

Vergleich von Governance und Lebenszyklus

Die folgende Tabelle vergleicht, wie FILE EXTERNAL und FILE MANAGED den Dateizugriff steuern und den Datei-Lebenszyklus handhaben:

Spaltentyp FILE MANAGED FILE EXTERNAL
Dateizugriffskontrolle Sie werden durch Tabellen- und Volumenberechtigungen geregelt, wie SELECT etwa auf der Tabelle und READ VOLUME auf dem Volumen. Gesteuert durch volumenbasierte Berechtigungen wie READ VOLUME.
Lebenszyklus und Garbage Collection Dateien sind mit den Zeilen verknüpft, die sie referenzieren. Durch das Löschen dieser Zeilen werden die Dateien für die Garbage Collection freigegeben. Automatische Garbage Collection wird nicht unterstützt. Du verwaltest die Dateien selbst. Das Löschen einer Tabellenzeile beeinflusst nicht die zugrundeliegende Datei im Volume.

FILE-Typ-Anwendungsfälle

Sowohl verwaltete als auch externe FILE Typen adressieren folgende Herausforderungen bei Anwendungsfällen mit unstrukturierten Daten:

Herausforderung Unterstützter FILE Typ Benefits
Dateien sind zu groß, um als BINARY inline gespeichert zu werden. FILE MANAGED oder FILE EXTERNAL Eine Spalte speichert eine Referenz, sodass eine Datei nur gelesen wird, wenn eine KI-Funktion oder UDF sie verarbeitet.FILE Dadurch wird vermieden, dass große Objekte direkt in der Tabelle materialisiert werden.
Getrennter Lebenszyklus und Governance zwischen Dateisystem und Tabelle FILE MANAGED Azure Databricks verknüpft den Lebenszyklus jeder Datei an die Tabelle, sodass das Löschen von Zeilen die Dateien für die Bereinigung geeignet macht, anstatt verwaiste Dateien im Speicher zu lassen.
Gleichzeitige Arbeitslasten, bei denen Dateien am selben Ort bleiben müssen FILE EXTERNAL Dateien bleiben auf ihren bestehenden Volumenpfaden und werden vom Lebenszyklus der Tabelle nicht beeinflusst, sodass andere Tools, die dieselben Dateien lesen, nicht gestört werden.

Nächste Schritte

  • Last updated on