Typ pliku i dane nieustrukturyzowane

Important

Ta funkcja jest dostępna w wersji beta. Administratorzy obszaru roboczego mogą kontrolować dostęp do tej funkcji ze strony Podglądy . Zobacz Zarządzanie wersjami zapoznawczami usługi Azure Databricks.

Typ ten FILE przechowuje uporządkowaną referencję do pliku nieustrukturyzowanego, z metadanymi takimi jak ścieżka i rozmiar. Używaj FILE kolumn w Unity Catalog do przechowywania dokumentów, obrazów i nagrań audio obok danych strukturalnych.

Aby uzyskać informacje o typie, zobacz FILE typ.

Poniższy diagram przedstawia kolumnę FILE o nazwie, video która odnosi się do klipów jazdy obok ustrukturyzowanych kolumn, takich jak trasa, opis scen i etykieta zagrożeń:

Tabela klipów sterujących, gdzie kolumna wideo jest typem PLIKU. Każdy wiersz łączy kolumny strukturalne (identyfikator klipu, trasa, opis sceny, etykieta hazardu oraz osadzenie) z referencją pliku wideo, która pokazuje miniaturę i rozmiar np. 1,8 GB.

Metadane i przechowywanie pliku FILE

Dla każdego wiersza FILE typ przechowuje metadane oraz uporządkowany link do pliku w pamięci. Wartość FILE obejmuje uripola size, , content_type, oraz checksum metadanych. Zapytania metadanych nie wymagają pełnego odczytu plików, co poprawia wydajność zapytań.

Możesz przekazywać FILE wartości do funkcji AI, takich jak ai_parse_document funkcja, oraz do funkcji definiowanych przez użytkownika (UDF).

Poniższy diagram przedstawia przykładową kolumnę zarządzaną FILE , zawierającą metadane ścieżek i rozmiarów oraz odniesienia do plików znajdujących się w pamięci:

Tabela klipów z kolumną wideo zapisaną jako typ PLIKU, wyświetlana jako para ścieżki i rozmiaru. Strzałki łączą każdy wiersz z jego plikiem w pamięci, ilustrując uporządkowaną referencję między tabelą a plikami.

Dlaczego używać FILE zamiast BINARY lub STRING

Poniższa tabela opisuje wyzwania związane z obsługą dużych, nieustrukturyzowanych plików z BINARY typami lub STRING typami:

Typ kolumny Description Diagram
BINARY Materializuje cały obiekt przy każdym odczytie, nawet gdy potrzebujesz tylko metadanych, takich jak rozmiar pliku czy ścieżka. Skutkuje to niepotrzebnymi obliczeniami i wolnymi zapytaniami. Tabela klipów z kolumną wideo zapisaną jako BINARY. Surowe bajty każdego wielogigabajtowego wideo są materializowane w kolumnie w linii.
STRING Przechowuje ścieżkę pliku bez metadanych, takich jak rozmiar czy informacje o wersji, oraz bez uregulowanego połączenia między tabelą a plikiem. Jeśli inne obciążenie usunie plik, tabela zawiera nieaktualne informacje. Jeśli usuniesz wiersz tabeli, plik z referencjami pozostaje w pamięci do czasu usunięcia ręcznie. Tabela klipów z kolumną wideo zapisaną jako ścieżka STRING, np. s3://.../NW-0142. Jedna ścieżka nie rozwiązuje się już do pliku w woluminie, co pokazuje, że ścieżki łańcuchowe nie gwarantują istnienia plików i że zarządzanie jest niepowiązane.

Sum kontrolnych

Pole checksum to token integralności dla bajtów pliku o postaci <prefix>:<digest>. Użyj go do porównania plików lub weryfikacji, że dane się nie zmieniły. Czytelnicy ignorują sumę kontrolną z nierozpoznanym przedrostkiem.

Suma kontrolna nie zawsze jest dostępna. to_file funkcja, create_file funkcja i funkcja wypełniają copy_file sumę kontrolną, gdy magazyn obiektów zwraca .ETAG list_files Funkcja tabelowa i read_files tabelowa nie wypełniają sumy kontrolnej.

Pole używa checksum jednego z następujących prefiksów:

prefiks Kodowanie digest Description
ETAG Opaque ETag magazynu obiektów dla całego pliku. Dostarczane dosłownie przez sklep, używane wyłącznie do porównania równości, a nie do ponownego obliczania.
MD5 Mała litera hex Skrót MD5 (RFC 1321), 32 znaki sześciokątne.
CRC32 Mała litera hex Suma kontrolna CRC32 (RFC 2083), 8 znaków sześciokątnych.
CRC32C Mała litera hex Suma kontrolna CRC32C (RFC 3385), 8 znaków szestekowych.
SHA-256 Mała litera hex Digest SHA-256 (RFC 6234), 64 znaki szesteksię.

Na przykład suma kontrolna MD5 wygląda jak MD5:d41d8cd98f00b204e9800998ecf8427e, a eTag magazynu obiektowego jak ETAG:"686897696a7c876b7e", wraz z otaczającymi podwójnymi cudzysłowami zwracanymi przez magazyn obiektów.

Wybierz pomiędzy FILE i BINARY

Poniższa tabela porównuje opcje pracy z plikami nieustrukturyzowanymi:

Typ kolumny Values Przypadek użycia
FILE Uporządkowane odniesienie do pliku, plus metadane (uri, size, content_type, ). checksum Zastosowanie do zarządzania i przetwarzania plików nieustrukturyzowanych wraz ze strukturyzowanymi danymi oraz do przekazywania plików do wbudowanych i AI funkcji.
BINARY Surowe bajty pliku, wpisane w kolumnę. Zastosowanie dla małych obiektów (domyślnie do 64 KB) przechowywanych bezpośrednio w pliku danych. To przydatne, gdy potrzebujesz niskiego narzutu metadanych i uproszczonego zarządzania plikami. Na przykład użyj tego do przechowywania miniatur w linii z danymi wiersza.

PLIK ZEWNĘTRZNY i ZARZĄDZANY PLIKAMI

Typ ten FILE wspiera dwa podejścia do zarządzania plikami:

  • FILE EXTERNAL kolumny odnoszą się do istniejących plików w tomie katalogu Unity. Pliki są zabezpieczone uprawnieniami woluminów Unity Catalog, ale ich cykl życia nie jest zarządzany przez Unity Catalog i nie są kopiowane. Stosuj takie podejście, gdy musisz odwołać się do plików bez przenoszenia danych lub zakłócania narzędzi odczytujących z istniejącego woluminu.
  • FILE MANAGED Kolumny kopiują pliki do zarządzanej pamięci. Ustaw właściwość tabeli databricks.filespace-preview na zarządzaną ścieżkę woluminów, aby Unity Catalog mógł używać jako magazyn. Stosuj to podejście, gdy chcesz uproszczonych uprawnień, które są zarządzane przez tabelę dla obciążeń uzyskujących dostęp do plików tylko przez tabelę, takich jak trening ML lub generowanie generowane przez pobieranie (RAG). Aby poznać wzorce pobierania, zobacz pliki Ingest jako typ PLIKU.

W przypadku zapytań nie ma różnicy między plikami zewnętrznymi a zarządzanymi.

Poniższy diagram pokazuje, jak typ FILE łączy Twój kod z plikami w chmurze obiektowej:

Schemat architektury typu FILE. Interfejsy klienckie, takie jak Python, SQL, Scala i UDF, działają z jednym typem PLIKU, który obsługuje leniwe ładowanie. Typ ten ma dwie wersje: FILE EXTERNAL, gdzie system plików zarządza cyklem życia, oraz FILE MANAGED, gdzie UC optymalizuje zarządzanie przez tabelę. Pliki zewnętrzne mapują się na wolumin, który jest zarządzany na poziomie woluminów, a pliki zarządzane do przestrzeni plików, która jest zarządzana na poziomie tabeli, zarówno w chmurze obiektowej, takiej jak S3, ADLS czy Google Cloud Storage.

FILE EXTERNAL

FILE EXTERNAL kolumny to odniesienia do plików, które już istnieją w woluminie Unity Catalog.

Jeśli masz wymagane uprawnienia na woluminie, możesz je aktualizować lub usuwać. Databricks zaleca używanie plików niezmiennych. Przyznanie tabeli ujawnia metadane pliku, ale odczyt bajtów pliku wymaga READ VOLUME również uprawnień na bazowym woluminie.

Zewnętrzny plik mapuje każdy wiersz tabeli na plik na jego istniejącej ścieżce w woluminie Unity Catalog:

Schemat wolumin UC zawierający pliki próbne zorganizowane pod folderami faz, przypisane do kolumny EXTERNAL FILE. Każdy wiersz tabeli odnosi się do pliku według ścieżki woluminacyjnej i dodaje kolumny strukturalne, takie jak Kohorta i Faza Badania.

przykłady FILE EXTERNAL

Aby utworzyć tabelę z kolumną FILE EXTERNAL :

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

Aby dodać kolumnę FILE EXTERNAL do istniejącej tabeli:

ALTER TABLE documents ADD COLUMN file FILE EXTERNAL;

Aby utworzyć i zapłynąć tabelę z woluminu, przypisując każdemu plikowi unikalne identyfikatory:

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

FILE MANAGED

FILE MANAGED kolumny przechowują kopie plików w FileSpace, woluminie Unity Catalog, który deklarujesz, aby tabela służyła jako zarządzana pamięć masowa. Ich cykl życia jest powiązany z tabelami, które się do nich odnoszą.

Następujące zachowania dotyczą :FILE MANAGED

  • Deklarowanie wymaga FileSpace własności databricks.filespace-preview tabeli.
  • Odczyt lub zapis pliku zarządzanego wymaga dostępu zarówno do tabeli, jak i woluminu, który wspiera .FileSpace
  • Automatyczne zbieranie śmieci z plików bez referencji nie jest obsługiwane.

Pliki nieustrukturyzowane przechowywane w zewnętrznych źródłach, takich jak SharePoint, Google Drive, OneDrive i SFTP, muszą być pobierane jako pliki zarządzane, zanim można ich używać z funkcjami takimi jak ai_parse_document funkcje i funkcje zdefiniowane przez użytkownika (UDF). Aby poznać wzorce pobierania, zobacz pliki Ingest jako typ PLIKU.

Aby użyć plików zarządzanych, stwórz tabelę z kolumną FILE MANAGED i zadeklaruj wolumin FileSpace , ustawiając właściwość tabeli databricks.filespace-preview na ścieżkę woluminu:

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

Pełne przykłady można znaleźć w poniższych FILE MANAGED przykładach. Cykl życia plików w a FileSpace jest powiązany z wierszami, które do nich odwołują. Usunięcie tych wierszy sprawia, że pliki kwalifikują się do zbierania śmieci.

przykłady FILE MANAGED

Aby utworzyć tabelę z kolumną FILE MANAGED :

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

Aby dodać kolumnę FILE MANAGED do istniejącej tabeli, ustaw właściwość tabeli databricks.filespace-preview przed dodaniem kolumny, tak jak w następującym kodzie:

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

ALTER TABLE reports ADD COLUMN attachment FILE MANAGED;

Dodanie kolumny FILE MANAGED do tabeli, która nie ma FileSpace błędów.

Porównanie zarządzania i cyklu życia

Poniższa tabela porównuje, jak i FILE MANAGED jak FILE EXTERNAL zarządzać dostępem do plików oraz zarządzać cyklem życia plików:

Typ kolumny FILE EXTERNAL FILE MANAGED
Kontrola dostępu do plików Regulowane przez uprawnienia woluminacyjne, takie jak READ VOLUME. Regulowane przez uprawnienia do tabeli i woluminu, takie jak SELECT na stole i READ VOLUME na woluminie.
Cykl życia i zbieranie śmieci Sam zarządzasz plikami. Usunięcie wiersza tabeli nie wpływa na plik bazowy w woluminie. Pliki są powiązane z wierszami, które się do nich odnoszą. Usunięcie tych wierszy sprawia, że pliki kwalifikują się do zbierania śmieci. Automatyczne zbieranie śmieci nie jest obsługiwane.

Przypadki użycia typu FILE

Zarówno typy zewnętrzne, jak i zarządzane FILE odpowiadają na następujące wyzwania dotyczące przypadków użycia danych nieustrukturyzowanych:

Wyzwanie Typ wspierany FILE Benefits
Pliki zbyt duże, by przechowywać je inline jako BINARY FILE MANAGED lub FILE EXTERNAL Kolumna przechowuje FILE referencję, więc plik jest odczytywany tylko wtedy, gdy funkcja AI lub UDF go przetwarza. To zapobiega materializowaniu dużych obiektów w linii na stole.
Rozłączony cykl życia i zarządzanie między systemem plików a tabelą FILE MANAGED Azure Databricks wiąże cykl życia każdego pliku z tabelą, więc usunięcie wierszy sprawia, że pliki kwalifikują się do czyszczenia, zamiast zostawiać osierocone pliki w pamięci.
Równoczesne obciążenia wymagające pozostania plików w tym samym miejscu FILE EXTERNAL Pliki pozostają na swoich obecnych ścieżkach woluminów, nie wpływając na cykl życia tabeli, więc inne narzędzia czytające te same pliki nie są zakłócane.

Następne kroki

  • Last updated on