Introducción a las tablas de objetos

En este documento, se describen tablas de objetos, que son tablas de solo lectura sobre objetos de datos no estructurados que residen en Cloud Storage.

Las tablas de objetos te permiten analizar datos no estructurados en Cloud Storage. Puedes hacer análisis con funciones remotas o hacer inferencias mediante BigQuery ML y, luego, unir los resultados de estas operaciones con el resto de tus datos estructurados en BigQuery.

Al igual que las tablas de BigLake, las tablas de objetos usan la delegación de acceso, que separa el acceso a la tabla de objetos del acceso a los objetos de Cloud Storage. Se usa una conexión externa asociada con una cuenta de servicio para conectarse a Cloud Storage, por lo que solo tienes que otorgar a los usuarios acceso a la tabla de objetos. Esto te permite aplicar la seguridad a nivel de fila y administrar a qué objetos tienen acceso los usuarios.

Esquema de tabla de objetos

Una tabla de objetos proporciona un índice de metadatos sobre los objetos de datos no estructurados en un bucket de Cloud Storage especificado. Cada fila de la tabla corresponde a un objeto y las columnas de la tabla corresponden a metadatos de objeto generados por Cloud Storage, incluidos metadatos personalizados.

Una tabla de objetos también contiene una seudocolumna data que representa el contenido del archivo en bytes sin procesar, que se propaga de forma automática cuando se crea la tabla de objetos. La función ML.DECODE_IMAGE usa esta seudocolumna cuando ejecutas inferencias en los datos de imágenes. No puedes incluir la seudocolumna data en las consultas y no aparece como parte del esquema de la tabla de objetos.

En la siguiente tabla, se describe el esquema fijo que usan las tablas de objetos:

Nombre del campo	Tipo	Modo	Descripción
`uri`	STRING	NULLABLE	`uri`: El identificador uniforme de recursos (URI) del objeto en el formato `gs://bucket_name/[folder_name/]object_name`
`generation`	INTEGER	NULLABLE	La generación de este objeto, que identifica la versión del objeto.
`content_type`	STRING	NULLABLE	El Content-Type de los datos del objeto, que identifica el tipo de contenido multimedia que es. Si un objeto se almacena sin un tipo de contenido, se entrega como application/octet-stream.
`size`	INTEGER	NULLABLE	La longitud de conteido de los datos en bytes.
`md5_hash`	STRING	NULLABLE	El hash MD5 de los datos, codificado mediante base64. Para obtener más información sobre el uso del hash MD5, consulta los metadatos del objeto de Cloud Storage.
`updated`	TIMESTAMP	NULLABLE	La última vez que se modificaron los metadatos del objeto.
`metadata`	RECORD	REPEATED	Metadatos personalizados del objeto. Cada metadato se representa como un par clave-valor en el secundario `(metadata.)name` y los campos `(metadata.)value` del campo `metadata`.
`(metadata.)name`	STRING	NULLABLE	Clave en una entrada de metadatos individual.
`(metadata.)value`	STRING	NULLABLE	Valor en una entrada de metadatos individual.

Las filas en una tabla de objetos son similares a las siguientes:

------------------------------------------------------------------------------------------------------------------------------------------------
|  uri                 | generation | content_type | size  | md5_hash   | updated                        | metadata...name | metadata...value  |
—-----------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/a.jpeg | 165842…    | image/jpeg   | 26797 | 8c33be10f… | 2022-07-21 17:35:40.148000 UTC | null            | null              |
—-----------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/b.bmp  | 305722…    | image/bmp    | 57932 | 44eb90cd1… | 2022-05-14 12:09:38.114000 UTC | null            | null              |
—-----------------------------------------------------------------------------------------------------------------------------------------------

Casos de uso

Puedes consultar los metadatos en una tabla de objetos de la misma manera en que lo harías con cualquier otra tabla de BigQuery. Sin embargo, el caso de uso principal para las tablas de objetos es hacer que los datos no estructurados sean accesibles para el análisis. Puedes usar BigQuery ML para ejecutar inferencias en tablas de objetos de imagen con modelos de TensorFlow, TensorFlow Lite y PyTorch. También puedes usar funciones remotas para analizar datos no estructurados de la manera que Por ejemplo, podrías crear una función remota que te permita analizar imágenes mediante Cloud Vision o una que te permita extraer metadatos de documentos PDF mediante Apache Tika.

En la siguiente tabla, se describen los puntos de integración que puedes usar para hacer el aprendizaje automático en los datos de tablas de objetos:

Integración	Descripción	Caso práctico	Instructivo
Modelos importados de BigQuery ML	Importa modelos de TensorFlow, TensorFlow Lite o ONNX a BigQuery ML para ejecutar inferencias locales en BigQuery.	Usas modelos personalizados o de código abierto que se ajustan a las limitaciones compatibles.	Instructivo: Ejecuta la inferencia en una tabla de objeto mediante un modelo de vector de atributos
Funciones de Cloud Run	Usa Cloud Functions para llamar a servicios o modelos alojados. Esta es la integración más genérica.	Aloja tus modelos en Compute Engine, Google Kubernetes Engine o en otra infraestructura de clientes.
La función `ML.ANNOTATE_IMAGE`	Usa la API de Cloud Vision para anotar imágenes.	Deseas anotar imágenes con un modelo previamente entrenado de la API de Vision.	Anota imágenes con la función `ML.ANNOTATE_IMAGE`
La función `ML.PROCESS_DOCUMENT`	Usa la API de Document AI para extraer estadísticas de documentos.	Deseas usar procesadores de documentos previamente entrenados o personalizados de Document AI.	Procesa documentos con la función `ML.PROCESS_DOCUMENT`
La función `ML.TRANSCRIBE`	Usa la API de Speech-to-Text para transcribir archivos de audio.	Quieres usar reconocedores de voz previamente entrenados o personalizados para Speech-to-Text.	Transcribe archivos de audio con la función `ML.TRANSCRIBE`

Puedes crear una vista o una tabla a partir de los resultados de tu análisis si deseas unir tus resultados con otros datos estructurados. Por ejemplo, la siguiente declaración crea una tabla basada en los resultados de inferencia:

CREATE TABLE my_dataset.my_inference_results AS
SELECT uri, content_type, vision_feature
FROM ML.PREDICT(
  MODEL my_dataset.vision_model,
  SELECT ML.DECODE_IMAGE(data) AS vision_input
  FROM my_dataset.object_table
);

Después de crear la tabla, puedes unirla con otras tablas en función de los campos de metadatos estándar o personalizados, como se muestra a continuación:

SELECT a.vision_feature, a.uri, b.description
FROM my_dataset.my_inference_results a
JOIN my_dataset.image_description b
ON a.uri = b.uri;

También puedes crear un índice de búsqueda para potenciar las búsquedas sobre los resultados de tu análisis. Por ejemplo, la siguiente instrucción crea un índice de búsqueda sobre los datos extraídos de los archivos PDF:

CREATE SEARCH INDEX my_index ON pdf_text_extract(ALL COLUMNS);

Luego, puedes usar el índice para encontrar lo que necesites en esos resultados:

SELECT * FROM pdf_text_extract WHERE SEARCH(pdf_text, 'Google');

Ventajas

El análisis de datos no estructurados de forma nativa en BigQuery proporciona los siguientes beneficios:

Reduce el esfuerzo manual, ya que te permite automatizar los pasos de procesamiento previo, como el ajuste de los tamaños de las imágenes para los requisitos del modelo.
Te permite usar la interfaz de SQL simple y familiar para trabajar con datos no estructurados.
Te ayuda a ahorrar costos mediante el uso de ranuras existentes de BigQuery en lugar de tener que aprovisionar nuevas formas de procesamiento.

URLs firmadas

Para obtener acceso a los datos representados por un objeto, genera una URL firmada. Puedes usar la URLs firmada para ver directamente los datos del objeto y también pasar las URLs firmadas a las funciones remotas para permitirles trabajar con datos de tablas de objetos.

Usa la función EXTERNAL_OBJECT_TRANSFORM para generar URLs firmadas, como se muestra en el siguiente ejemplo:

SELECT uri, signed_url
FROM EXTERNAL_OBJECT_TRANSFORM(TABLE `mydataset.myobjecttable`, ['SIGNED_URL']);

Esto muestra resultados similares a la siguiente:

---------------------------------------------------------------------------------------------------
|  uri                 | signed_url                                                               |
—--------------------------------------------------------------------------------------------------
| gs://mybucket/a.docx | https://storage.googleapis.com/mybucket/a.docx?X-Goog-Signature=abcd&... |
—-------------------------------------------------------------------------------------------------
| gs://mybucket/b.pdf  | https://storage.googleapis.com/mybucket/b.pdf?X-Goog-Signature=wxyz&...  |
—--------------------------------------------------------------------------------------------------

Las URLs firmadas generadas a partir de tablas de objetos permiten que cualquier usuario o procedimiento que las posea pueda leer los objetos correspondientes. Las URL firmadas se vencen después de 6 horas. Para obtener más información, consulta URLs firmadas de Cloud Storage.

Control de acceso

Las tablas de objetos se compilan sobre BigLake, por lo que usan una conexión externa basada en una cuenta de servicio para acceder a los datos de Cloud Storage. Esto separa el acceso a la tabla del acceso al almacén de objetos subyacente mediante la delegación de acceso. Otorgas a la cuenta de servicio permisos para acceder a los datos y metadatos de los objetos y mostrarlos en la tabla. Puedes otorgar permisos a los usuarios solo en la tabla, en la que puedes controlar el acceso a los datos mediante la Identity and Access Management (IAM) y la seguridad a nivel de fila.

Las tablas de objetos varían de otras tablas que usan la delegación de acceso, ya que tener acceso a una fila de una tabla de objetos confiere el acceso al contenido del archivo subyacente. Si bien un usuario no puede acceder al objeto directamente, puede generar una URL firmada que le permita ver el contenido del archivo. Por ejemplo, si el usuario tiene acceso a la fila de la tabla de objetos que representa el archivo de imagen flower.jpg, puede generar una URL firmada para mostrar el archivo y ver que es una foto de una margarita.

Establecer una política de acceso a nivel de fila en una tabla de objetos restringe el acceso de un usuario o grupo a los metadatos del objeto en las filas elegidas y, también, a los objetos representados por esas filas. Por ejemplo, con la siguiente declaración, se le otorga a la usuario Alice solo acceso a las filas que representan objetos creados antes del 25 de junio de 2022:

CREATE ROW ACCESS POLICY before_20220625
ON my_dataset.my_object_table
GRANT TO ("user:alice@example.com")
FILTER USING (updated < TIMESTAMP("2022-06-25"));

Con esta política de acceso a nivel de fila implementada, los siguientes resultados son verdaderos para Alice:

Ejecutar la consulta SELECT * FROM my_dataset.my_object_table; solo muestra las filas que tienen un valor updated antes del 25 de junio de 2022.
La ejecución de la inferencia en my_dataset.my_object_table solo muestra predicciones para los objetos que tienen un valor updated anterior al 25 de junio de 2022.
La generación de URLs firmadas para my_dataset.my_object_table solo crea URLs para objetos que tienen un valor updated anterior al 25 de junio de 2022.

También puedes restringir el acceso a las filas de la tabla de objetos mediante metadatos personalizados. Por ejemplo, la siguiente declaración restringe el grupo users para acceder solo a las filas en las que el objeto se etiquetó para indicar que no contiene información de identificación personal:

CREATE ROW ACCESS POLICY no_pii
ON my_dataset.my_object_table
GRANT TO ("group:users@example.com")
FILTER USING (ARRAY_LENGTH(metadata)=1
AND metadata[OFFSET(0)].name="no_pii")

Modelo de seguridad

Por lo general, los siguientes roles de la organización participan en la administración y el uso de las tablas de objetos:

Administradores de data lakes. Estos administradores suelen gestionar las políticas de Identity and Access Management (IAM) en los buckets y objetos de Cloud Storage.
Administradores de almacenes de datos. Estos administradores suelen crear, borrar y actualizar tablas.
Analistas de datos. Por lo general, los analistas leen datos y ejecutan consultas.

Los administradores de data lakes son responsables de crear conexiones y compartirlas con administradores de almacenes de datos. A su vez, los administradores de almacenes de datos crean tablas, establecen controles de acceso adecuados y comparten las tablas con los analistas de datos.

Archivos de objetos admitidos

Puedes crear una tabla de objetos sobre cualquier tipo y tamaño de archivo de datos no estructurados, y puedes crear funciones remotas para trabajar con cualquier tipo de datos no estructurados. Sin embargo, para hacer inferencias con BigQuery ML, una tabla de objetos solo puede estar en archivos de imagen que cumplan con varios requisitos de tamaño y tipo. Para obtener más información, consulta Limitaciones.

Almacenamiento en caché de metadatos para rendimiento

Puedes usar metadatos almacenados en caché para mejorar el rendimiento de la inferencia y otros tipos de análisis en tablas de objetos. El almacenamiento de metadatos en caché es muy útil en los casos en que la tabla de objetos hace referencia a grandes cantidades de objetos. Los metadatos incluyen nombres de archivo, información de partición y metadatos físicos de archivos, como recuentos de filas. Puedes elegir si deseas habilitar o no el almacenamiento de metadatos en caché en una tabla. Las consultas con una gran cantidad de archivos y con filtros de partición de subárbol se benefician más del almacenamiento de metadatos en caché.

Si no habilitas el almacenamiento de metadatos en caché, las consultas en la tabla deben leer la fuente de datos externa para obtener metadatos de objeto. Leer estos datos aumenta la latencia de la consulta, ya que enumerar millones de archivos de la fuente de datos externa puede tardar varios minutos. Si habilitas el almacenamiento de metadatos en caché, las consultas pueden evitar la enumeración de archivos de la fuente de datos externa y pueden particionar y reducir los archivos más rápido.

Hay dos propiedades que controlan esta característica:

La inactividad máxima especifica cuándo las consultas usan metadatos almacenados en caché
El modo de almacenamiento de metadatos en caché especifica cómo se recopilan los metadatos

Cuando tienes habilitado el almacenamiento de metadatos en caché, debes especificar el intervalo máximo de inactividad de metadatos que es aceptable para las operaciones en la tabla. Por ejemplo, si especificas un intervalo de 1 hora, las operaciones en la tabla usan metadatos almacenados en caché si se actualizaron en la última hora. Si los metadatos almacenados en caché son más antiguos que eso, la operación recurre a la recuperación de metadatos desde Cloud Storage. Puedes especificar un intervalo de inactividad de entre 30 minutos y 7 días.

Puedes actualizar la caché de forma automática o manual:

Para las actualizaciones automáticas, la caché se actualiza a un intervalo definido por el sistema, que suele estar entre 30 y 60 minutos. Actualizar la caché de forma automática es una buena estrategia si los archivos de Cloud Storage se agregan, borran o modifican a intervalos aleatorios. Si necesitas controlar el momento de la actualización, por ejemplo, para activarla al final de un trabajo de extracción, transformación y carga, usa la actualización manual.
En el caso de las actualizaciones manuales, ejecuta el procedimiento del sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para actualizar la caché de metadatos en una programación que cumpla con tus requisitos. Actualizar la caché de forma manual es una buena estrategia si se agregan, se borran o se modifican los archivos en Cloud Storage, a intervalos conocidos, por ejemplo, como resultado de una canalización.

Si emites varias actualizaciones manuales simultáneas, solo una tendrá éxito.

La caché de metadatos vence después de 7 días si no se actualiza.

Las actualizaciones de caché manuales y automáticas se ejecutan con la prioridad de consulta INTERACTIVE.

Si eliges usar actualizaciones automáticas, te recomendamos que crees una reserva y, luego, una asignación con un tipo de trabajo BACKGROUND para el proyecto que ejecuta los trabajos de actualización de caché de metadatos. Esto evita que los trabajos de actualización compitan con las consultas de los usuarios por recursos y que puedan fallar si no hay suficientes recursos disponibles para ellos.

Debes considerar cómo interactuarán los valores del intervalo de inactividad y el modo de almacenamiento de metadatos en caché antes de configurarlos. Considera los siguientes ejemplos:

Si actualizas la caché de metadatos de una tabla de manual y estableces el intervalo de inactividad en 2 días, debes ejecutar el procedimiento del sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE cada 2 días o menos si deseas operaciones en la tabla para usar metadatos almacenados en caché.
Si actualizas de foma automática la caché de metadatos de una tabla y estableces el intervalo de inactividad en 30 minutos, es posible que algunas de las operaciones para la tabla lean desde Cloud Storage si los metadatos La actualización de la caché lleva más tiempo del período habitual de 30 a 60 minutos.

Para obtener información sobre los trabajos de actualización de metadatos, consulta la vista INFORMATION_SCHEMA.JOBS, como se muestra en el siguiente ejemplo:

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

Para obtener más información, consulta Almacenamiento en caché de metadatos.

Para obtener más información sobre cómo configurar opciones de almacenamiento en caché de metadatos, consulta Crea tablas de objetos.

Limitaciones

Las tablas de objetos son de solo lectura, ya que se asignan a objetos de datos no estructurados en Cloud Storage. No puedes modificar una tabla de objetos ni modificar los datos de una tabla de objetos.
La asistencia para tablas de objetos no está disponible en SQL heredado ni en otros entornos de nube, como AWS y Microsoft Azure.
Si deseas hacer inferencias con BigQuery ML, el modelo y la tabla de objetos que usas deben cumplir con los requisitos descritos en Limitaciones.
Las consultas que incluyen tablas de objetos no pueden acceder a más de 10 GB de metadatos de objetos. Por ejemplo, si una consulta accede a 100 TB de una combinación de columnas de metadatos en tablas de objetos y datos de objetos a través de URLs firmadas, solo 10 GB de esos 100 TB pueden ser de las columnas de metadatos.
Las tablas de objetos están sujetas a las mismas limitaciones que todas las demás tablas externas de BigQuery. Para obtener más información, consulta Cuotas.
Las consultas sobre tablas de objetos están sujetas a las mismas limitaciones que todas las demás consultas de BigQuery. Para obtener más información, consulta Cuotas.
Las funciones remotas que procesan datos no estructurados de tablas de objetos están sujetas a las mismas limitaciones que todas las demás funciones remotas.
Las URLs firmadas generadas para los objetos en una tabla de objetos vencen después de 6 horas, que es el límite de tiempo de ejecución de la consulta.
La inferencia con BigQuery ML no es compatible con los precios según demanda o con la edición Estándar.
Las siguientes funciones no son compatibles con los precios según demanda o con la edición Estándar:

Costos

Los costos se asocian con los siguientes aspectos de las tablas de objetos:

Consulta las tablas.
Actualiza la caché de metadatos.

Si tienes reservas de ranuras, no se te cobra por consultar tablas externas. En cambio, se consumen las ranuras para estas consultas.

En la siguiente tabla, se muestra cómo tu modelo de precios afecta la en que se aplican estos costos:

	Precios según demanda	Ediciones Standard, Enterprise y Enterprise Plus
Consultas	Se te facturará por los bytes procesados por consultas de usuarios.	Las ranuras en asignaciones de reservas con un tipo de trabajo `QUERY` se consumen durante el tiempo de consulta.
Actualiza de manual la caché de metadatos.	Se te facturará por los bytes procesados para actualizar la caché.	Las ranuras en asignaciones de reservas con un tipo de trabajo `QUERY` se consumen durante la actualización de la caché.
Actualiza de foma automática la caché de metadatos.	Se te facturará por los bytes procesados para actualizar la caché.	Las ranuras en asignaciones de reservas con un tipo de trabajo `BACKGROUND` se consumen durante la actualización de la caché. Si no hay reservas `BACKGROUND` disponibles para actualizar la caché de metadatos, BigQuery usa de forma automática ranuras en reservas `QUERY` en su lugar si utilizas la edición Enterprise o Enterprise Plus.

También se te cobra por el almacenamiento y el acceso a los datos mediante Cloud Storage, Amazon S3 y Azure Blob Storage, con sujeción a los lineamientos de precios de cada producto.

Usa tablas de objetos con Analytics Hub

Las tablas de objstos son compatibles con Analytics Hub. Los conjuntos de datos que contienen tablas de objetos se pueden publicar como listas de Analytics Hub. Los suscriptores de Analytics Hub pueden suscribirse a estas listas, que aprovisionan un conjunto de datos de solo lectura, llamado conjunto de datos vinculados, en su proyecto. Los suscriptores pueden consultar todas las tablas en el conjunto de datos vinculado, incluidas todas las tablas de objetos. Para obtener más información, consulta Suscríbete a una ficha.

¿Qué sigue?

Aprende a crear una tabla de objetos.
Aprende a ejecutar inferencias en tablas de objetos de imagen.
Aprende a analizar tablas de objetos mediante funciones remotas.