FILE-type en ongestructureerde data

Important

Deze functie bevindt zich in de bètaversie. Werkruimtebeheerders kunnen de toegang tot deze functie beheren vanaf de pagina Previews . Zie Azure Databricks previews beheren.

Het FILE type slaat een beheerde verwijzing op naar een ongestructureerd bestand, met metadata zoals pad en grootte. Gebruik FILE kolommen in de Unity Catalog om documenten, afbeeldingen en audio op te slaan naast gestructureerde data.

Met FILE MANAGED kolommen slaat Unity Catalog kopieën van de bestanden op en beheert deze met de tabel: het verwijderen van rijen maakt de gerefereerde bestanden geschikt voor garbage collection, zodat de tabel en de bestanden synchroon blijven.

Voor de typereferentie, zie FILE type.

Het volgende diagram toont een FILE kolom met de naam video die verwijst naar rijclips, naast gestructureerde kolommen zoals route, scenebeschrijving en gevarenlabel:

Een tabel met rijclips waarbij de videokolom van het type BESTAND is. Elke rij koppelt gestructureerde kolommen (clip-ID, route, scènebeschrijving, gevarenlabel en een embedding) aan een videobestandsverwijzing die een miniatuurweergave toont en een grootte van bijvoorbeeld 1,8 GB.

FILE-metadata en opslag

Voor elke rij slaat het FILE type metadata en een bestuurde link naar het bestand in opslag op. Een FILE waarde bevat uri, size, content_type, en checksum metadatavelden. Metadata-query's vereisen geen volledige bestandslezingen, wat de queryprestaties verbetert.

Je kunt waarden doorgeven FILE aan AI-functies, zoals ai_parse_document functie, en aan door de gebruiker gedefinieerde functies (UDF's).

Het volgende diagram toont een voorbeeld van een beheerde FILE kolom, met metadata van paden en grootte en verwijzingen naar de bestanden in opslag:

De tabel met clips, met de videokolom opgeslagen als een type FILE, weergegeven als een paar van pad en grootte. Pijlen koppelen elke rij aan het bestand in de opslag, waarmee een beheerde verwijzing tussen de tabel en de bestanden wordt geïllustreerd.

Toegang tot metadata en inhoud

Een FILE waarde bestaat uit twee delen, en de toegang tot elk wordt anders geregeld:

  • Bestandsmetadata (uri, size, content_type, en checksum) wordt opgeslagen in de eigen databestanden van de tabel. Iedereen met SELECT op tafel kan het lezen.
  • De inhoud van bestanden blijft in opslag. Het lezen ervan vereist toegang tot het bestand: READ VOLUME op het onderliggende volume voor FILE EXTERNAL, of toegang tot zowel de tabel als het volume dat de FileSpace voor FILE MANAGED ondersteunt.

Het converteren van een FILE-waarde naar BINARY of STRING, het doorgeven ervan aan een AI-functie of UDF en het weergeven van een voorbeeld ervan in de resultaattabel lezen allemaal de inhoud van het bestand. Omdat de metadata deel uitmaakt van de tabel, zijn het pad en de grootte van een bestand zichtbaar voor iedereen die de tabel kan opvragen, zelfs zonder toegang tot de inhoud.

Om bestanden te bekijken in queryresultaten, zie Voorbeeldbestanden in de kolommen FILE.

Waarom FILE gebruiken in plaats van BINARY of STRING

De volgende tabel beschrijft de uitdagingen bij het omgaan met grote ongestructureerde bestanden met BINARY of STRING types:

Kolomtype Description Diagram
BINARY Materialiseert het volledige object voor elke lezing, zelfs als je alleen metadata nodig hebt zoals de bestandsgrootte of het pad. Dit resulteert in onnodige berekeningen en trage zoekopdrachten. De tabel met clips, met de videokolom opgeslagen als BINARY. De ruwe bytes van elke video van meerdere gigabytes worden rechtstreeks in de kolom opgeslagen.
STRING Slaat een bestandspad op zonder metadata, zoals grootte of versie-informatie, en zonder bestuurde link tussen de tabel en het bestand. Als een andere werklast het bestand verwijdert, bevat de tabel verouderde informatie. Als je een tabelrij verwijdert, blijft het gerefereerde bestand opgeslagen totdat je het handmatig verwijdert. De tabel clips, waarin de videokolom als STRING-pad is opgeslagen, zoals s3://.../NW-0142. Eén pad verwijst niet langer naar een bestand in het volume, wat aantoont dat STRING-paden niet garanderen dat bestanden bestaan en dat governance losstaat van de bestanden.

Controlesommen

Het checksum veld is een integriteitstoken voor de bytes van het bestand, van de vorm <prefix>:<digest>. Gebruik het om bestanden te vergelijken of te controleren of een bestand niet is veranderd. Lezers negeren een checksum met een niet-herkend voorvoegsel.

Een checksum is niet altijd beschikbaar. to_file functie, create_file functie, en copy_file functie vullen de checksum in wanneer de objectopslag een ETAG terugstuurt. list_files Tabelwaarde functie en read_files tabelwaarde functie vullen de controlesum niet.

Het checksum veld maakt gebruik van een van de volgende voorvoegsels:

voorvoegsel Hashcodering Description
ETAG Opaque De eTag van de objectstore voor het hele bestand. Letterlijk geleverd door de winkel, alleen gebruikt voor gelijkheidsvergelijking en niet herberekenbaar.
MD5 Kleine hex Een MD5-digest (RFC 1321), 32 hex-tekens.
CRC32 Kleine hex Een CRC32-checksum (RFC 2083), 8 hex-tekens.
CRC32C Kleine hex Een CRC32C-checksum (RFC 3385), 8 hex-tekens.
SHA-256 Kleine hex Een SHA-256 digest (RFC 6234), 64 hex-tekens.

Bijvoorbeeld, een MD5-checksum ziet eruit als MD5:d41d8cd98f00b204e9800998ecf8427e, en een object-store eTag als ETAG:"686897696a7c876b7e", inclusief de omliggende dubbele quotes die door de objectopslag worden teruggegeven.

Kies tussen FILE en BINARY

De volgende tabel vergelijkt de opties voor het werken met ongestructureerde bestanden:

Kolomtype Values Gebruiksituatie
FILE Een gereguleerde verwijzing naar een bestand, plus metadata (uri, size, content_type, ). checksum Gebruik voor het beheren en verwerken van ongestructureerde bestanden naast gestructureerde data, en het doorgeven van bestanden aan ingebouwde en AI-functies.
BINARY De ruwe bytes van een bestand, inline in een kolom. Gebruik voor kleine objecten (standaard tot 64 KB) die direct in het databestand zijn opgeslagen. Dit is handig wanneer je weinig metadata-overhead en vereenvoudigd bestandsbeheer nodig hebt. Gebruik dit bijvoorbeeld om miniaturen in lijn met rijgegevens op te slaan.

BESTANDSBEHEER en EXTERN BESTAND

Het FILE type ondersteunt twee benaderingen voor het beheren van de bestanden:

  • FILE MANAGED kolommen kopiëren bestanden naar beheerde opslag. Rechten worden vereenvoudigd en beheerd via de tabel. Wanneer je rijen verwijdert of bijwerkt om naar andere bestanden te verwijzen, komen de niet-gerefereerde bestanden in aanmerking voor garbage collection, zodat de tabel en de bestanden synchroon blijven. Gebruik deze aanpak voor workloads die bestanden via een tabel benaderen, zoals ML-training of retrieval-augmented generation (RAG), en voor bestanden die van externe bronnen zijn ingevoerd. Voor invoerpatronen, zie Ingest-bestanden als het BESTANDSTYPE.
  • FILE EXTERNAL kolommen verwijzen naar bestaande bestanden in een Unity Catalog-volume. De bestanden zijn beveiligd met volumerechten van Unity Catalog, maar hun levenscyclus wordt niet beheerd door Unity Catalog en ze worden niet gekopieerd. Gebruik deze aanpak wanneer je bestanden moet refereren zonder data te verplaatsen of tools te verstoren die van een bestaand volume lezen.

Azure Databricks beveelt FILE MANAGED aan voor workloads die profiteren van bestandsniveau-permissies en ingebouwde compliance: toegang tot elk bestand wordt geregeld via de tabel die ernaar verwijst, en het verwijderen van rijen maakt de gerefereerde bestanden geschikt voor garbage collection. Gebruik FILE EXTERNAL wanneer bestanden op hun bestaande volumepaden moeten blijven voor tools die ze buiten de tabel lezen.

Voor queries is er geen verschil tussen beheerde en externe bestanden.

Het volgende diagram laat zien hoe het FILE type je code verbindt met bestanden in cloudobjectopslag:

Diagram van de FILE-type architectuur. Python-, SQL-, Scala- en UDF-clients werken met één FILE-type dat metadata leest zonder bestandsbytes op te halen. FILE MANAGED slaat bestanden op in een FileSpace waar toegang op tabelniveau wordt gereguleerd en het verwijderen van rijen bestanden geschikt maakt voor garbage collection. FILE EXTERNAL verwijst naar bestanden op hun bestaande paden in een UC-volume, geregeld door volumerechten. Beide modi slaan bestanden op in cloudobjectopslag zoals S3, ADLS of Google Cloud Storage.

FILE MANAGED

FILE MANAGED kolommen slaan kopieën van bestanden op in een FileSpace, een Unity Catalog-volume dat je voor de tabel aanduidt om te gebruiken als beheerde opslag. Hun levenscyclus is gekoppeld aan de tabellen die naar hen verwijzen: het verwijderen van rijen maakt de gerefereerde bestanden geschikt voor garbage collection, zodat de tabel en de bestanden synchroon blijven.

De volgende gedragingen gelden voor:FILE MANAGED

  • Het declareren van FileSpace vereist de databricks.filespace-preview tabeleigenschap.
  • Het lezen of schrijven van een beheerd bestand vereist toegang tot zowel de tabel als het volume dat ten grondslag ligt aan FileSpace.
  • Automatisch opschonen van bestanden waarnaar niet wordt verwezen, wordt niet ondersteund in de bètaversie.

Ongestructureerde bestanden die zijn opgeslagen in externe bronnen zoals SharePoint, Google Drive, OneDrive en SFTP moeten als beheerde bestanden worden ingevoerd voordat je ze kunt gebruiken met functies zoals ai_parse_document functie en gebruikersgedefinieerde functies (UDF's). Voor invoerpatronen, zie Ingest-bestanden als het BESTANDSTYPE.

Om beheerde bestanden te gebruiken, maak je een tabel met een FILE MANAGED kolom aan en declareer je een volume als de FileSpace door de databricks.filespace-preview tabeleigenschap in te stellen op een volumepad:

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

Voor volledige voorbeelden, zie de volgende FILE MANAGED voorbeelden.

voorbeelden van FILE MANAGED

Om een tabel met een FILE MANAGED kolom te maken:

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

Om een FILE MANAGED kolom toe te voegen aan een bestaande tabel, stel je de databricks.filespace-preview tabeleigenschap in voordat je de kolom toevoegt, zoals in de volgende 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;

Het toevoegen van een FILE MANAGED kolom aan een tabel zonder FileSpace faalt.

Verwijder beheerde bestanden zonder referenties

Omdat automatische opschoning niet wordt ondersteund, moet je bestanden waarnaar niet wordt verwezen zelf verwijderen. Het volgende notitieboekje vindt de bestanden in een FileSpace waar geen tabelversie naar verwijst, en verwijdert ze optioneel:

FileType-garbagecollectionnotebook

Notebook krijgen

FILE EXTERNAL

FILE EXTERNAL kolommen zijn referenties naar bestanden die al bestaan in een Unity Catalog-volume.

Als je de vereiste rechten op het volume hebt, kun je deze bestanden bijwerken of verwijderen. Databricks raadt aan om onveranderlijke bestanden te gebruiken. Een table grant maakt de bestandsmetadata bloot, maar het lezen van de bytes van het bestand vereist ook het READ VOLUME privilege op het onderliggende volume.

Een extern bestand koppelt elke tabelrij aan een bestand op het bestaande pad in een Unity Catalog-volume:

Een diagram van een UC-volume met trialbestanden georganiseerd onder fasemappen, gekoppeld aan een kolom EXTERNAL FILE. Elke tabelrij verwijst naar een bestand via het volumepad en voegt gestructureerde kolommen toe zoals Cohort en Study Phase.

voorbeelden van FILE EXTERNAL

Om een tabel met een FILE EXTERNAL kolom te maken:

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

Om een FILE EXTERNAL kolom toe te voegen aan een bestaande tabel:

ALTER TABLE documents ADD COLUMN file FILE EXTERNAL;

Om een tabel te maken en te vullen vanuit een volume, waarbij unieke ID's aan elk bestand worden toegewezen:

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

Vergelijking van bestuur en levenscyclus

De volgende tabel vergelijkt hoe FILE EXTERNAL en FILE MANAGED bestandstoegang regelen en de levenscyclus van bestanden afhandelen:

Kolomsoort FILE MANAGED FILE EXTERNAL
Bestandstoegangscontrole Geregeld door tabel- en volumerechten, zoals SELECT op de tabel en READ VOLUME op het volume. Beheerd door volumemachtigingen, zoals READ VOLUME.
Levenscyclus en garbagecollectie Bestanden zijn gekoppeld aan de rijen die ernaar verwijzen. Het verwijderen van die rijen maakt de bestanden geschikt voor garbage collection. Automatisch opschonen wordt niet ondersteund. Je beheert de bestanden zelf. Het verwijderen van een tabelrij beïnvloedt het onderliggende bestand in het volume niet.

FILE-type gebruikssituaties

Zowel beheerde als externe FILE types behandelen de volgende uitdagingen voor use cases met ongestructureerde data:

Uitdaging Ondersteund FILE type Benefits
Bestanden te groot om inline op te slaan als BINARY FILE MANAGED of FILE EXTERNAL Een FILE kolom slaat een referentie op, dus een bestand wordt alleen gelezen wanneer een AI-functie of UDF het verwerkt. Dit voorkomt dat grote objecten in de tabel worden gematerialiseerd.
Losgekoppelde levenscyclus en governance tussen het bestandssysteem en de tabel FILE MANAGED Azure Databricks koppelt de levenscyclus van elk bestand aan de tabel, waardoor het verwijderen van rijen de bestanden geschikt maakt voor opruiming in plaats van verweesde bestanden in opslag te laten.
Gelijktijdige workloads waarbij bestanden op dezelfde locatie moeten blijven FILE EXTERNAL Bestanden blijven op hun bestaande paden op het volume, zonder dat de levenscyclus van de tabel daarop van invloed is, zodat andere tools die dezelfde bestanden lezen niet worden onderbroken.

Volgende stappen 

  • Last updated on