Introducción a las tablas de objetos

En este documento se describen las 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 sin estructurar en Cloud Storage. Puedes realizar análisis con funciones remotas o inferencias con BigQuery ML y, a continuación, combinar 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 desacopla el acceso a la tabla de objetos del acceso a los objetos de Cloud Storage. Una conexión externa asociada a una cuenta de servicio se usa para conectarse a Cloud Storage, por lo que solo tienes que conceder a los usuarios acceso a la tabla de objetos. De esta forma, puedes aplicar la seguridad a nivel de fila y gestionar 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 sin estructurar de un segmento de Cloud Storage especificado. Cada fila de la tabla corresponde a un objeto, y las columnas de la tabla corresponden a los metadatos del objeto generados por Cloud Storage, incluidos los metadatos personalizados.

Una tabla de objetos también contiene una pseudocolumna data que representa el contenido del archivo en bytes sin formato, que se rellena automáticamente cuando se crea la tabla de objetos. La pseudocolumna se usa con la función ML.DECODE_IMAGE cuando se ejecuta la inferencia en datos de imagen. No puedes incluir la pseudocolumna 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 utilizan las tablas de objetos:

Las filas de una tabla de objetos tienen un aspecto similar al siguiente:

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|  uri                 | generation | content_type | size  | md5_hash   | updated                        | metadata...name | metadata...value  | ref.uri              | ref.version | ref.authorizer | ref.details                                              |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/a.jpeg | 165842…    | image/jpeg   | 26797 | 8c33be10f… | 2022-07-21 17:35:40.148000 UTC | null            | null              | gs://mybucket/a.jpeg | 12345678    | us.conn        | {"gcs_metadata":{"content_type":"image/jpeg","md5_hash"… |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
| gs://mybucket/b.bmp  | 305722…    | image/bmp    | 57932 | 44eb90cd1… | 2022-05-14 12:09:38.114000 UTC | null            | null              | gs://mybucket/b.bmp  | 23456789    | us.conn        | {"gcs_metadata":{"content_type":"image/bmp","md5_hash"…  |
—----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Casos prácticos

Puedes consultar los metadatos de una tabla de objetos de la misma forma que consultarías cualquier otra tabla de BigQuery. Sin embargo, el caso práctico principal de 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 casi cualquier forma que quieras. Por ejemplo, puedes crear una función remota que te permita analizar imágenes con Cloud Vision o extraer metadatos de documentos PDF con Apache Tika.

En la siguiente tabla se describen los puntos de integración que puede usar para aplicar aprendizaje automático a los datos de la tabla de objetos:

Puedes crear una vista o una tabla a partir de los resultados de tu análisis si quieres combinar los resultados con otros datos estructurados. Por ejemplo, la siguiente instrucción crea una tabla basada en los resultados de la 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
);

Una vez creada la tabla, puede combinarla con otras tablas en función de 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 puede crear un índice de búsqueda para realizar búsquedas en los resultados de su análisis. Por ejemplo, la siguiente instrucción crea un índice de búsqueda sobre los datos extraídos de archivos PDF:

CREATE SEARCH INDEX my_index ON pdf_text_extract(ALL COLUMNS);

Después, puedes usar el índice para encontrar lo que necesites en esos resultados:

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

Ventajas

Analizar datos sin estructurar de forma nativa en BigQuery ofrece las siguientes ventajas:

• Reduce el esfuerzo manual al permitirte automatizar los pasos de preprocesamiento, como ajustar los tamaños de las imágenes a los requisitos del modelo.
• Te permite usar la interfaz SQL que ya conoces para trabajar con datos no estructurados.
• Te ayuda a ahorrar costes utilizando los slots de BigQuery que ya tienes en lugar de tener que aprovisionar nuevas formas de computación.

URL firmadas

Para acceder a los datos representados por un objeto, genera una URL firmada. Puede usar la URL firmada para ver directamente los datos del objeto y también pasar URLs firmadas a funciones remotas para que puedan trabajar con los datos de la tabla de objetos.

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

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

Se devolverán resultados similares a los siguientes:

---------------------------------------------------------------------------------------------------
|  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 tenga lea los objetos correspondientes. Las URLs firmadas generadas caducan al cabo de 6 horas. Para obtener más información, consulta URLs firmadas de Cloud Storage.

Control de acceso

Las tablas de objetos se basan en BigLake, por lo que usan una conexión externa basada en una cuenta de servicio para acceder a los datos de Cloud Storage. De esta forma, se desacopla el acceso a la tabla del acceso al almacén de objetos subyacente mediante la delegación de acceso. Concede permisos a la cuenta de servicio para acceder a los datos y metadatos de los objetos y mostrarlos en la tabla. Solo puedes conceder permisos a los usuarios en la tabla, donde puedes controlar el acceso a los datos mediante la gestión de identidades y accesos (IAM) y la seguridad a nivel de fila.

Las tablas de objetos se diferencian de otras tablas que usan la delegación de acceso en que, al tener acceso a una fila de una tabla de objetos, se obtiene acceso al contenido del archivo subyacente. Aunque un usuario no puede acceder al objeto directamente, sí 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 imagen de una margarita.

Si se define una política de acceso a nivel de fila en una tabla de objetos, se restringe el acceso de un usuario o un grupo a los metadatos de los objetos de las filas seleccionadas, así como a los objetos representados por esas filas. Por ejemplo, la siguiente instrucción concede al usuario Alice acceso solo a las filas que representan objetos creados antes del 25 de junio del 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, se cumplen las siguientes condiciones para Alice:

• Al ejecutar la consulta SELECT * FROM my_dataset.my_object_table; solo se devuelven las filas que tienen un valor updated anterior al 25 de junio del 2022.
• Si ejecutas la inferencia en my_dataset.my_object_table, solo se devuelven predicciones de los objetos que tengan un valor updated anterior al 25 de junio del 2022.
• Al generar URLs firmadas para my_dataset.my_object_table, solo se crean URLs para objetos que tengan un valor de updated anterior al 25 de junio del 2022.

También puede restringir el acceso a las filas de la tabla de objetos mediante metadatos personalizados. Por ejemplo, la siguiente instrucción restringe el acceso del grupo users a las filas en las que el objeto se haya etiquetado como que no contiene información personal identificable:

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

Los siguientes roles de la organización suelen participar en la gestión y el uso de tablas de objetos:

• Administradores de lagos de datos. Estos administradores suelen gestionar las políticas de gestión de identidades y accesos (IAM) en los segmentos y objetos de Cloud Storage.
• Administradores de almacenes de datos. Estos administradores suelen crear, eliminar y actualizar tablas.
• Analistas de datos. Los analistas suelen leer datos y ejecutar consultas.

Los administradores de lagos de datos son responsables de crear conexiones y compartirlas con los administradores de almacenes de datos. A su vez, los administradores del almacén de datos crean tablas, definen los controles de acceso adecuados y comparten las tablas con los analistas de datos.

Archivos de objeto admitidos

Puedes crear una tabla de objetos sobre cualquier tipo y tamaño de archivo de datos sin estructurar, así como funciones remotas para trabajar con cualquier tipo de datos sin estructurar. Sin embargo, para realizar inferencias con BigQuery ML, una tabla de objetos solo puede contener archivos de imagen que cumplan varios requisitos de tamaño y tipo. Para obtener más información, consulta Limitaciones.

Almacenamiento en caché de metadatos para mejorar el rendimiento

Puede usar metadatos almacenados en caché para mejorar el rendimiento de las inferencias y otros tipos de análisis en tablas de objetos. El almacenamiento en caché de metadatos es especialmente útil en los casos en los que la tabla de objetos hace referencia a un gran número de objetos. BigQuery usa CMETA como sistema de metadatos distribuido para gestionar tablas grandes de forma eficiente. CMETA proporciona metadatos pormenorizados a nivel de columna y de bloque, a los que se puede acceder a través de tablas del sistema. Este sistema ayuda a mejorar el rendimiento de las consultas optimizando el acceso y el procesamiento de los datos. Para acelerar aún más el rendimiento de las consultas en tablas grandes, BigQuery mantiene una caché de metadatos. Los trabajos de actualización de CMETA mantienen esta caché actualizada.

Los metadatos incluyen nombres de archivo, información de partición y metadatos físicos de archivos, como el número de filas. Puedes elegir si quieres habilitar el almacenamiento en caché de metadatos en una tabla. Las consultas con un gran número de archivos y con filtros de partición de Apache Hive son las que más se benefician del almacenamiento en caché de metadatos.

Si no habilita el almacenamiento en caché de metadatos, las consultas en la tabla deben leer la fuente de datos externa para obtener los metadatos del objeto. La lectura de estos datos aumenta la latencia de las consultas. Listar millones de archivos de la fuente de datos externa puede llevar varios minutos. Si habilitas el almacenamiento en caché de metadatos, las consultas pueden evitar enumerar archivos de la fuente de datos externa y pueden particionar y eliminar archivos más rápidamente.

El almacenamiento en caché de metadatos también se integra con la gestión de versiones de objetos de Cloud Storage. Cuando se rellena o se actualiza la caché, se capturan los metadatos en función de la versión activa de los objetos de Cloud Storage en ese momento. Por lo tanto, las consultas con el almacenamiento en caché de metadatos habilitado leen los datos correspondientes a la versión específica del objeto almacenado en caché, aunque se publiquen versiones más recientes en Cloud Storage. Para acceder a los datos de las versiones de objetos actualizadas posteriormente en Cloud Storage, es necesario actualizar la caché de metadatos.

Hay dos propiedades que controlan esta función:

• Antigüedad máxima especifica cuándo las consultas usan metadatos almacenados en caché.
• El modo de caché de metadatos especifica cómo se recogen los metadatos.

Si tienes habilitada la caché de metadatos, puedes especificar el intervalo máximo de obsolescencia de los metadatos que se acepta para las operaciones en la tabla. Por ejemplo, si especificas un intervalo de 1 hora, las operaciones en la tabla usarán los metadatos almacenados en caché si se han actualizado en la última hora. Si los metadatos almacenados en caché son anteriores a esa fecha, la operación recurre a la recuperación de metadatos de Cloud Storage. Puedes especificar un intervalo de antigüedad entre 30 minutos y 7 días.

Cuando habilitas el almacenamiento de metadatos en caché para tablas de BigLake o de objetos, BigQuery activa tareas de actualización de la generación de metadatos. Puedes actualizar la caché de forma automática o manual:

• En el caso de las actualizaciones automáticas, la caché se actualiza a intervalos definidos por el sistema, normalmente entre 30 y 60 minutos. Actualizar la caché automáticamente es una buena opción si los archivos de Cloud Storage se añaden, eliminan 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.

• Para las actualizaciones manuales, ejecuta el procedimiento del sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para actualizar la caché de metadatos según una programación que se ajuste a tus necesidades. Actualizar la caché manualmente es una buena opción si los archivos de Cloud Storage se añaden, eliminan o modifican a intervalos conocidos, por ejemplo, como resultado de una canalización.

  Si emite varias actualizaciones manuales simultáneas, solo se completará una.

La caché de metadatos caduca al cabo de 7 días si no se actualiza.

Tanto las actualizaciones de caché manuales como las automáticas se ejecutan con la prioridad de consulta INTERACTIVE.

Usar reservas de BACKGROUND

Si decides usar las actualizaciones automáticas, te recomendamos que crees una reserva y, a continuación, una asignación con el tipo de tarea BACKGROUND para el proyecto que ejecute las tareas de actualización de la caché de metadatos. Con las reservas de BACKGROUND, las tareas de actualización usan un grupo de recursos específico, lo que evita que compitan con las consultas de los usuarios y que puedan fallar si no hay suficientes recursos disponibles.

Aunque el uso de un grupo de ranuras compartido no conlleva ningún coste adicional, el uso de BACKGROUND reservas proporciona un rendimiento más constante al asignar un grupo de recursos específico y mejora la fiabilidad de los trabajos de actualización y la eficiencia general de las consultas en BigQuery.

Antes de definir los valores del intervalo de obsolescencia y del modo de almacenamiento en caché de metadatos, debes tener en cuenta cómo interactuarán. Ten en cuenta los siguientes ejemplos:

• Si actualizas manualmente la caché de metadatos de una tabla y estableces el intervalo de obsolescencia en 2 días, debes ejecutar el procedimiento del sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE cada 2 días o menos si quieres que las operaciones de la tabla usen metadatos almacenados en caché.
• Si actualizas automáticamente la caché de metadatos de una tabla y estableces el intervalo de obsolescencia en 30 minutos, es posible que algunas de tus operaciones en la tabla lean de Cloud Storage si la actualización de la caché de metadatos tarda más de lo habitual (entre 30 y 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 definir las opciones de almacenamiento en caché de metadatos, consulta Crear tablas de objetos.

Limitaciones

• Las tablas de objetos son de solo lectura, ya que se asignan a objetos de datos sin estructurar en Cloud Storage. No puede modificar una tabla de objetos ni los datos de una tabla de objetos.
• La compatibilidad con tablas de objetos no está disponible en SQL antiguo ni en otros entornos de nube, como Amazon Web Services (AWS) y Microsoft Azure.
• Si quieres realizar inferencias con BigQuery ML, el modelo y la tabla de objetos que utilices deben cumplir los requisitos descritos en la sección 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 de tablas de objetos y datos de objetos a través de URLs firmadas, solo 10 GB de esos 100 TB pueden proceder 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 en 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 de una tabla de objetos caducan al cabo de 6 horas, que es el límite de tiempo de ejecución de consultas.
• La inferencia con BigQuery ML no se admite con los precios bajo demanda ni con la edición Standard.

• Las siguientes funciones no se admiten con los precios bajo demanda ni con la edición Estándar:

  • ML.CONVERT_COLOR_SPACE
  • ML.CONVERT_IMAGE_TYPE
  • ML.RESIZE_IMAGE

• Las tablas de objetos tienen un máximo de 60 millones de filas. Para participar en un lanzamiento de vista previa que aumente el número máximo de filas a 300 millones, rellena este formulario de solicitud.

Costes

Los costes están asociados a los siguientes aspectos de las tablas de objetos:

• Consultar las tablas.
• Actualizar la caché de metadatos.

Si tienes reservas de ranuras, no se te cobrará por consultar tablas externas. En su lugar, se consumen slots para estas consultas.

En la siguiente tabla se muestra cómo influye tu modelo de precios en la forma en que se aplican estos costes:

También se te cobrará por el almacenamiento y el acceso a los datos de Cloud Storage, Amazon S3 y Azure Blob Storage, según las directrices de precios de cada producto.

Usar tablas de objetos con la función de compartir de BigQuery

Las tablas de objetos son compatibles con la función de compartir de BigQuery (antes Analytics Hub). Los conjuntos de datos que contienen tablas de objetos se pueden publicar como fichas compartidas. Los suscriptores que comparten pueden suscribirse a estas fichas, que proporcionan un conjunto de datos de solo lectura, denominado conjunto de datos vinculado, en su proyecto. Los suscriptores pueden consultar todas las tablas del conjunto de datos vinculado, incluidas todas las tablas de objetos. Para obtener más información, consulta Suscribirse a una ficha.

Siguientes pasos

• Consulta cómo crear una tabla de objetos.
• Consulte cómo usar tablas de objetos para mantener las columnas ObjectRef en tablas estándar.
• Consulta cómo ejecutar inferencias en tablas de objetos de imagen.
• Consulta cómo analizar tablas de objetos mediante funciones remotas.