Almacenamiento de metadatos en caché

En este documento, se describe cómo usar el almacenamiento en caché de metadatos para mejorar las consultas en tablas de objetos y algunos tipos de tablas de BigLake.

Las tablas de objetos y algunos tipos de tablas de BigLake pueden almacenar en caché información de metadatos sobre archivos en almacenes de datos externos, por ejemplo, Cloud Storage. Los siguientes tipos de tablas de BigLake admiten el almacenamiento de metadatos en caché:

  • Tablas de BigLake de Amazon S3
  • Tablas de BigLake de Cloud Storage
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.

Puedes habilitar el almacenamiento de metadatos en caché en una tabla de BigLake o de objetos cuando creas la tabla. Para más información sobre la creación de tablas de objetos, ve a Crea tablas de objetos de Cloud Storage. Para obtener más información sobre cómo crear tablas de BigLake, consulta uno de los siguientes temas:

Configuración de almacenamiento de metadatos en caché

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 el almacén de datos (Amazon S3 o 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 almacén de datos 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. Para las tablas de BigLake, puedes actualizar los metadatos de forma selectiva si proporcionas subdirectorios del directorio de datos de tablas. Esto te permite evitar el procesamiento de metadatos innecesario. Actualizar la caché de forma manual es una buena estrategia si se agregan, se borran o se modifican los archivos en el almacén de datos, 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 el almacén de datos si los metadatos La actualización de la caché lleva más tiempo del período habitual de 30 a 60 minutos.

Obtén información sobre los trabajos de actualización de caché de metadatos

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;

Usa claves de encriptación administradas por el cliente con metadatos almacenados en caché

Los metadatos almacenados en caché están protegidos por la clave de encriptación administrada por el cliente (CMEK) que se usa para la tabla con la que están asociados los metadatos almacenados en caché. Puede ser una CMEK que se aplica directamente a la tabla o una CMEK que hereda la tabla del conjunto de datos o del proyecto.

Si se configura una CMEK predeterminada para el proyecto o el conjunto de datos, o si se cambia la CMEK existente del proyecto o conjunto de datos, esto no afectará las tablas existentes o sus metadatos almacenados en caché. Debes cambiar la clave de la tabla para aplicar la clave nueva a la tabla y a sus metadatos almacenados en caché.

Las CMEK creadas en BigQuery no se aplican a los archivos de Cloud Storage que usan BigLake y las tablas de objetos. Para obtener la encriptación de CMEK de extremo a extremo, configura las CMEK en Cloud Storage para esos archivos.

Obtén información sobre el uso de la caché de metadatos para trabajos de consulta

Para obtener información sobre el uso de caché de metadatos para un trabajo de consulta, llama al método jobs.get para ese trabajo y observa el campo MetadataCacheStatistics en la sección JobStatistics2 del recurso Job. Este campo proporciona información sobre qué tablas habilitadas para la caché de metadatos usó la consulta, si la caché de metadatos usó la consulta y, si no, por qué.

Estadísticas de la tabla

En las tablas de BigLake basadas en archivos Parquet, las estadísticas de la tabla se recopilan cuando se actualiza la caché de metadatos. La recopilación de estadísticas de tablas se hace durante las actualizaciones automáticas y manuales, y las estadísticas se conservan durante el mismo período que la caché de metadatos.

Las estadísticas de tablas recopiladas incluyen información de archivos, como recuentos de filas, tamaños de archivos físicos y sin comprimir y cardinalidad de columnas. Cuando ejecutas una consulta en una tabla de BigLake basada en Parquet, estas estadísticas se proporcionan al optimizador de consultas para permitir una mejor planificación de consultas y, potencialmente, mejorar el rendimiento para algunos tipos de consultas. Por ejemplo, una optimización de consulta común es la propagación de restricciones dinámicas, en la que el optimizador de consultas infiere predicados de forma dinámica en las tablas de hechos más grandes en una unión de las tablas de dimensiones más pequeñas. Si bien esta optimización puede acelerar las consultas mediante el uso de esquemas de tablas normalizados, requiere estadísticas de tablas precisas. Las estadísticas de tablas recopiladas por el almacenamiento de metadatos en caché permiten una mayor optimización de los planes de consultas en BigQuery y Apache Spark.

Limitaciones

Las siguientes limitaciones se aplican a la caché de metadatos:

  • 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.
  • Si actualizas el URI de origen de una tabla, la caché de metadatos no se actualiza de forma automática y las consultas posteriores muestran datos de la caché desactualizada. Para evitar esto, actualiza la caché de metadatos de forma manual. Si la caché de metadatos de la tabla está configurada para actualizarse de forma automática, debes cambiar el modo de actualización de la tabla a manual, hacer la actualización manual y, luego, volver a configurar el modo de actualización de la tabla al modo automático.

  • Si actualizas manualmente la caché de metadatos, y el conjunto de datos de destino y el bucket de Cloud Storage están en una ubicación regional, debes especificarla explícitamente cuando ejecutes la llamada de procedimiento BQ.REFRESH_EXTERNAL_METADATA_CACHE. Puedes hacerlo de una de las siguientes maneras:

    Console

    1. Ve a la página de BigQuery.

      Ir a BigQuery

    2. Selecciona una pestaña en el Editor.

    3. Haz clic en Más y, luego, en Configuración de consulta.

    4. En la sección Opciones avanzadas, anula la selección de la casilla de verificación Selección automática de ubicación y, luego, especifica la región de destino.

    5. Haz clic en Guardar.

    6. Ejecuta la consulta que contiene la llamada de procedimiento BQ.REFRESH_EXTERNAL_METADATA_CACHE en esa pestaña del Editor.

    bq

    Si ejecutas la consulta que contiene la llamada de procedimiento BQ.REFRESH_EXTERNAL_METADATA_CACHE mediante bq query, asegúrate de especificar la marca --location.

¿Qué sigue?