Tipo de archivo y datos no estructurados

Importante

Esta característica se encuentra en su versión beta. Los administradores del área de trabajo pueden controlar el acceso a esta característica desde la página Vistas previas . Consulte Administrar versiones preliminares de Azure Databricks.

El FILE tipo almacena una referencia gobernada a un archivo no estructurado, con metadatos como ruta y tamaño. Utiliza FILE columnas en el Catálogo de Unity para almacenar documentos, imágenes y audio junto con datos estructurados.

Para la referencia tipográfica, véase FILE tipo.

El siguiente diagrama muestra una FILE columna llamada video que hace referencia a los clips de conducción junto a columnas estructuradas como ruta, descripción de escena y etiqueta de peligro:

Una tabla de clips de conducción donde la columna de vídeo es un tipo ARCHIVO. Cada fila empareja columnas estructuradas (ID de clip, ruta, descripción de escena, etiqueta de peligro y incrustación) con una referencia de archivo de vídeo que muestra una miniatura y un tamaño como 1,8 GB.

Metadatos y almacenamiento de ARCHIVO

Para cada fila, el FILE tipo almacena metadatos y un enlace regulado al archivo almacenado. Un FILE valor incluye uri, size, content_type, y checksum campos de metadatos. Las consultas de metadatos no requieren lecturas completas de archivos, lo que mejora el rendimiento de las consultas.

Puedes pasar FILE valores a funciones de IA, como ai_parse_document la función, y a funciones definidas por el usuario (UDFs).

El siguiente diagrama muestra un ejemplo de columna gestionada FILE , que contiene metadatos de ruta y tamaño y referencias a los archivos almacenados:

La tabla de clips con la columna de vídeo almacenada como tipo ARCHIVO, mostrada como un par de ruta y tamaño. Las flechas vinculan cada fila a su archivo en almacenamiento, ilustrando una referencia gobernada entre la tabla y los archivos.

¿Por qué usar FILE en lugar de BINARY o STRING?

La siguiente tabla detalla los desafíos al manejar archivos no estructurados grandes con BINARY o STRING tipos:

Tipo de columna Descripción Diagrama
BINARY Materializa el objeto completo en cada lectura, incluso cuando solo necesitas metadatos como el tamaño o la ruta del archivo. Esto resulta en cálculos innecesarios y consultas lentas. La tabla de clips con la columna de vídeo almacenada como BINARY. Los bytes en bruto de cada vídeo de varios gigabytes se materializan en línea en la columna.
STRING Almacena una ruta de archivo sin metadatos, como información de tamaño o versión, y sin enlace regulado entre la tabla y el archivo. Si otra carga de trabajo elimina el archivo, la tabla tiene información obsoleta. Si eliminas una fila de tabla, el archivo referenciado permanece almacenado hasta que lo eliminas manualmente. La tabla de clips con la columna de vídeo almacenada como un camino STRING, como s3://.../NW-0142. Una ruta ya no se resuelve a un archivo en el volumen, lo que muestra que las rutas de cadenas no garantizan la existencia de archivos y que la gobernanza no está vinculada.

Sumas de comprobación

El checksum campo es un token de integridad para los bytes del archivo, de la forma <prefix>:<digest>. Úsala para comparar archivos o verificar que no haya cambiado. Los lectores ignoran una suma de comprobación con un prefijo no reconocido.

No siempre hay una suma de comprobación disponible. to_file función, create_file función y copy_file función pueblan la suma de comprobación cuando el almacén de objetos devuelve un ETAGarchivo . list_files La función con valores de tabla y read_files la función con valores en tabla no completan la suma de comprobación.

El checksum campo utiliza uno de los siguientes prefijos:

Prefijo Codificación por digest Descripción
ETAG Opaque El eTag del object store para todo el archivo. Suministrado literalmente por la tienda, usado solo para comparación de igualdad, y no recomputable.
MD5 Hexágono minúsculo Un resumen MD5 (RFC 1321), 32 caracteres hexadecimales.
CRC32 Hexágono minúsculo Una suma de comprobación CRC32 (RFC 2083), 8 caracteres hexadecimales.
CRC32C Hexágono minúsculo Una suma de comprobación CRC32C (RFC 3385), 8 caracteres hexadecimales.
SHA-256 Hexágono minúsculo Un resumen SHA-256 (RFC 6234), 64 caracteres hexadecimales.

Por ejemplo, una suma de comprobación MD5 se parece MD5:d41d8cd98f00b204e9800998ecf8427ea , y una etiqueta de objeto de almacenamiento de objetos se muestra ETAG:"686897696a7c876b7e"a , incluyendo las comillas dobles que la rodea devueltas por el almacén de objetos.

Seleccione entre FILE y BINARY

La siguiente tabla compara las opciones para trabajar con archivos no estructurados:

Tipo de columna Values Caso de uso
FILE Una referencia gobernada a un archivo, más metadatos (uri, size, content_type, checksum). Úsalos para gestionar y procesar archivos no estructurados junto con datos estructurados, y para pasar archivos a funciones integradas y de IA.
BINARY Los bytes en bruto de un archivo, en línea en una columna. Úsalo para objetos pequeños (hasta 64 KB por defecto) almacenados directamente en el archivo de datos. Esto es útil cuando necesitas una baja sobrecarga de metadatos y una gestión de archivos simplificada. Por ejemplo, úsalo para almacenar miniaturas en línea con los datos de fila.

ARCHIVO EXTERNO y ARCHIVO GESTIONADO

El FILE tipo soporta dos enfoques para gestionar los archivos:

  • FILE EXTERNAL las columnas hacen referencia a archivos existentes en un volumen del Catálogo de Unity. Los archivos están protegidos por permisos de volumen del Catálogo de Unity, pero su ciclo de vida no es gestionado por el Catálogo de Unity y no se copian. Utiliza este enfoque cuando necesites referenciar archivos sin mover datos ni interrumpir herramientas que leen desde un volumen existente.
  • FILE MANAGED las columnas copian archivos a almacenamiento gestionado. Establece la databricks.filespace-preview propiedad de la tabla en una ruta de volumen gestionado para que el Catálogo de Unity la use como almacenamiento. Utiliza este enfoque cuando quieras permisos simplificados que se gestionen a través de la tabla para cargas de trabajo que solo acceden a archivos a través de una tabla, como entrenamiento de aprendizaje automático o generación aumentada por recuperación (RAG). Para patrones de ingestión, véase archivos Ingest como el tipo de archivo.

Para consultas, no hay diferencia entre archivos externos y gestionados.

El siguiente diagrama muestra cómo el FILE tipo conecta tu código con archivos en almacenamiento de objetos en la nube:

Diagrama de la arquitectura de tipos de archivo. Las interfaces cliente como Python, SQL, Scala y UDFs funcionan con un único tipo de ARCHIVO que soporta cargas perezosas. El tipo tiene dos variantes: FILE EXTERNAL, donde el sistema de archivos gestiona el ciclo de vida, y FILE MANAGED, donde UC optimiza la gobernanza a través de la tabla. Los archivos externos se mapean a un volumen externo que se rige a nivel de volumen, y los archivos gestionados se mapean a un FileSpace que se rige a nivel de tabla, tanto en almacenamiento en la nube como S3, ADLS o Google Cloud Storage.

FILE EXTERNAL

FILE EXTERNAL las columnas son referencias a archivos que ya existen en un volumen del Catálogo de Unity.

Si tienes los privilegios necesarios sobre el volumen, puedes actualizar o eliminar estos archivos. Databricks recomienda usar archivos inmutables. Una concesión de tabla expone los metadatos del archivo, pero leer los bytes del archivo también requiere el READ VOLUME privilegio sobre el volumen subyacente.

Un archivo externo asigna cada fila de tabla a un archivo en su ruta existente en un volumen del Catálogo de Unity:

Un diagrama de un volumen UC que contiene archivos de prueba organizados bajo carpetas de fase, mapeado a una columna ARCHIVO EXTERNO. Cada fila de la tabla hace referencia a un archivo por su ruta de volumen y añade columnas estructuradas como Cohorte y Fase de estudio.

ejemplos de FILE EXTERNAL

Para crear una tabla con una FILE EXTERNAL columna:

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

Para añadir una FILE EXTERNAL columna a una tabla existente:

ALTER TABLE documents ADD COLUMN file FILE EXTERNAL;

Para crear y rellenar una tabla desde un volumen, asignando IDs únicos a cada archivo:

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

FILE MANAGED

FILE MANAGED las columnas almacenan copias de archivos en un FileSpace, un volumen de Unity Catalog que declaras para que la tabla lo use como almacenamiento gestionado. Su ciclo de vida está ligado a las tablas que los referencian.

Los siguientes comportamientos se aplican a FILE MANAGED:

  • Declarar el FileSpace requiere la databricks.filespace-preview propiedad de la tabla.
  • Leer o escribir un archivo gestionado requiere acceso tanto a la tabla como al volumen que respalda el FileSpacearchivo .
  • No se permite la recolección automática de archivos sin referencia.

Los archivos no estructurados almacenados en fuentes externas como SharePoint, Google Drive, OneDrive y SFTP deben ser ingeridos como archivos gestionados antes de poder usarlos con funciones como ai_parse_document funciones como funciones y funciones definidas por el usuario (UDFs). Para patrones de ingestión, véase archivos Ingest como el tipo de archivo.

Para usar archivos gestionados, crea una tabla con una FILE MANAGED columna y declara un volumen como el FileSpace estableciendo la databricks.filespace-preview propiedad de la tabla como una ruta de volumen:

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

Para ejemplos completos, véanse los siguientes FILE MANAGED ejemplos. El ciclo de vida de los archivos en un FileSpace está ligado a las filas que los referencian. Eliminar esas filas hace que los archivos sean elegibles para la recogida de basura.

ejemplos de FILE MANAGED

Para crear una tabla con una FILE MANAGED columna:

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

Para añadir una FILE MANAGED columna a una tabla existente, establece la propiedad de tabla databricks.filespace-preview antes de añadir la columna, como en el siguiente código:

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

ALTER TABLE reports ADD COLUMN attachment FILE MANAGED;

Añadir una FILE MANAGED columna a una tabla que no FileSpace tiene fallos.

Gobernanza y comparación del ciclo de vida

La siguiente tabla compara cómo FILE EXTERNAL y FILE MANAGED gobiernan el acceso a archivos y gestionan el ciclo de vida del archivo:

Tipo de columna FILE EXTERNAL FILE MANAGED
Control de acceso a archivos Regido por permisos de volumen, como READ VOLUME. Regido por permisos de tabla y volumen, como los SELECT de la tabla y READ VOLUME del volumen.
Ciclo de vida y recolección de elementos no utilizados Tú gestionas los archivos. Eliminar una fila de tabla no afecta al archivo subyacente en el volumen. Los archivos están vinculados a las filas que los referencian. Eliminar esas filas hace que los archivos sean elegibles para la recogida de basura. No se soporta la recogida automática de basura.

Casos de uso tipo FILE

Tanto los tipos externos como gestionados FILE abordan los siguientes desafíos para casos de uso utilizando datos no estructurados:

Desafío Tipo soportado FILE Benefits
Archivos demasiado grandes para almacenarlos en línea como BINARY FILE MANAGED o FILE EXTERNAL Una FILE columna almacena una referencia, por lo que un archivo solo se lee cuando una función de IA o un UDF lo procesa. Esto evita que los objetos grandes se materialifiquen en línea en la mesa.
Ciclo de vida y gobernanza desconectados entre el sistema de archivos y la tabla FILE MANAGED Azure Databricks vincula el ciclo de vida de cada archivo a la tabla, así que eliminar filas hace que los archivos sean elegibles para limpieza en lugar de dejar archivos huérfanos en almacenamiento.
Cargas de trabajo concurrentes que requieren que los archivos permanezcan en la misma ubicación FILE EXTERNAL Los archivos permanecen en sus rutas de volumen existentes, sin verse afectadas por el ciclo de vida de la tabla, por lo que otras herramientas que leen los mismos archivos no se ven interrumpidas.

Pasos siguientes

  • Last updated on