Armazenamento em cache de metadados

Neste documento, descrevemos como usar o armazenamento em cache de metadados para melhorar o desempenho da consulta em tabelas de objetos e alguns tipos de tabelas do BigLake.

Tabelas de objetos e alguns tipos de tabelas do BigLake podem armazenar em cache informações de metadados sobre arquivos em repositórios de dados externos, por exemplo, o Cloud Storage. Os seguintes tipos de tabelas do BigLake são compatíveis com o armazenamento em cache de metadados:

  • Tabelas do Amazon S3 BigLake
  • Tabelas do BigLake do Cloud Storage

Os metadados incluem nomes de arquivos, informações de particionamento e metadados de arquivos, como contagens de linhas. Você pode escolher se quer ativar o armazenamento em cache de metadados em uma tabela. As consultas com um grande número de arquivos e os filtros de partição do Hive são mais beneficiados com o armazenamento em cache de metadados.

Se você não ativar o armazenamento em cache de metadados, as consultas na tabela precisarão ler a fonte de dados externa para receber os metadados do objeto. A leitura desses dados aumenta a latência da consulta. Listar milhões de arquivos da fonte de dados externa pode levar vários minutos. Se você ativar o armazenamento em cache de metadados, as consultas podem evitar a listagem de arquivos da fonte de dados externa e podem particionar e remover arquivos mais rapidamente.

É possível ativar o armazenamento em cache de metadados em uma tabela do BigLake ou de objeto ao criar a tabela. Para mais informações sobre como criar tabelas de objetos, consulte Criar tabelas de objetos do Cloud Storage. Para mais informações sobre como criar tabelas do BigLake, consulte um dos tópicos a seguir:

Configurações de armazenamento em cache de metadados

Há duas propriedades que controlam o comportamento desse recurso:

  • A inatividade máxima especifica quando as consultas usam metadados armazenados em cache.
  • O modo de cache de metadados especifica como os metadados são coletados.

Quando o armazenamento em cache de metadados está ativado, você especifica o intervalo máximo de inatividade dos metadados que é aceitável para operações na tabela. Por exemplo, se você especificar um intervalo de uma hora, as operações na tabela usarão metadados em cache se eles tiverem sido atualizados na última hora. Se os metadados armazenados em cache forem mais antigos que isso, a operação voltará à recuperação de metadados do armazenamento de dados (Amazon S3 ou Cloud Storage). É possível especificar um intervalo de inatividade entre 30 minutos e 7 dias.

É possível atualizar o cache de maneira automática ou manual:

  • Para atualizações automáticas, o cache é atualizado em um intervalo definido pelo sistema, geralmente entre 30 e 60 minutos. A atualização automática do cache é uma boa abordagem quando os arquivos no repositório de dados são adicionados, excluídos ou modificados em intervalos aleatórios. Se você precisar controlar o tempo da atualização, por exemplo, para acioná-la no final de um job extract-transform-load, use a atualização manual.
  • Para atualizações manuais, execute o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE para atualizar o cache de metadados na programação determinada. Para tabelas do BigLake, é possível atualizar os metadados de maneira seletiva fornecendo subdiretórios do diretório de dados da tabela. Isso permite evitar o processamento desnecessário de metadados. A atualização manual do cache é uma boa abordagem quando os arquivos no repositório de dados são adicionados, excluídos ou modificados em intervalos conhecidos, como a saída de um pipeline.

As atualizações de cache manuais e automáticas são executadas com a prioridade de consulta INTERACTIVE.

Se você optar por usar atualizações automáticas, recomendamos que crie uma reserva e, em seguida, crie umuma tarefaBACKGROUND tipo de job para o projeto que executa os jobs de atualização do cache de metadados. Isso impede que os jobs de atualização compitam com as consultas do usuário por recursos e podem falhar se não houver recursos suficientes disponíveis.

Pense em como os valores do intervalo de inatividade e do modo de armazenamento em cache de metadados vão interagir antes de serem definidos. Confira estes exemplos:

  • Se o cache de metadados de uma tabela estiver configurado para exigir atualizações manuais e o intervalo de inatividade estiver definido como dois dias, será necessário executar o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE a cada dois dias ou menos se você quiser operações na tabela para usar metadados armazenados em cache.
  • Se o cache de metadados de uma tabela for definido para ser atualizado automaticamente e o intervalo de inatividade for definido como 30 minutos, algumas das operações na tabela poderão ser lidas do repositório de dados se a atualização do cache de metadados assumir o lado maior da janela normal de 30 a 60 minutos.

Para mais informações sobre como definir opções de armazenamento em cache de metadados para tabelas do BigLake, consulte Criar tabelas do Amazon S3 BigLake ou Criar tabelas do BigLake do Cloud Storage.

Para mais informações sobre como definir opções de armazenamento em cache de metadados para tabelas de objetos, consulte Criar tabelas de objetos.

Receber informações sobre jobs de atualização do cache de metadados

Para encontrar informações sobre jobs de atualização do cache, consulte a visualização INFORMATION_SCHEMA.JOBS, como mostrado no exemplo a seguir:

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

Usar chaves de criptografia gerenciadas pelo cliente com metadados em cache

Os metadados em cache são protegidos pela chave de criptografia gerenciada pelo cliente (CMEK, na sigla em inglês) usada na tabela a que os metadados em cache estão associados. Pode ser uma CMEK aplicada diretamente à tabela ou uma CMEK que a tabela herdada do conjunto de dados ou projeto.

Se uma CMEK padrão for definida para o projeto ou o conjunto de dados, ou se a CMEK atual do projeto ou conjunto de dados for alterada, isso não afetará as tabelas atuais nem os metadados armazenados em cache. É necessário alterar a chave da tabela para aplicar a nova chave à tabela e aos metadados armazenados em cache.

As CMEKs criadas no BigQuery não se aplicam aos arquivos do Cloud Storage usados pelo BigLake e pelas tabelas de objetos. Para usar a criptografia de ponta a ponta da CMEK, configure CMEKs no Cloud Storage para esses arquivos.

Receber informações sobre o uso do cache de metadados por jobs de consulta

Para receber informações sobre o uso do cache de metadados em um job de consulta, chame o método jobs.get para esse job e confira o campo MetadataCacheStatistics na seção JobStatistics2 do recurso Job. Esse campo fornece informações sobre quais tabelas ativadas em cache de metadados foram usadas pela consulta, se o cache de metadados foi usado pela consulta e, se não, o motivo.

Estatísticas da tabela

Para tabelas do BigLake baseadas em arquivos Parquet, as estatísticas da tabela são coletadas quando o cache de metadados é atualizado. A coleta das estatísticas de tabela acontece durante atualizações automáticas e manuais. Elas são mantidas pelo mesmo período que o cache de metadados.

As estatísticas da tabela coletadas incluem informações de arquivos como contagens de linhas, tamanhos de arquivos físicos e não compactados e cardinalidade das colunas. Ao executar uma consulta em uma tabela do BigLake baseada em Parquet, essas estatísticas são fornecidas ao otimizador de consultas para permitir um melhor planejamento e potencialmente melhorar o desempenho da consulta de alguns tipos. Por exemplo, uma otimização de consulta comum é a propagação de restrição dinâmica, em que o otimizador da consulta infere dinamicamente predicados nas tabelas de fatos maiores em uma mesclagem das tabelas de dimensões menores. Essa otimização pode acelerar as consultas usando esquemas de tabelas normalizadas, mas requer estatísticas de tabela precisas. As estatísticas da tabela coletadas pelo armazenamento em cache de metadados permitem uma maior otimização dos planos de consulta no BigQuery e no Apache Spark.

Limitações

As seguintes limitações se aplicam ao cache de metadados:

  • Se você emitir várias atualizações manuais simultâneas, apenas uma vai ser bem-sucedida.
  • O cache de metadados expira após sete dias se não for atualizado.
  • Se você atualizar o URI de origem de uma tabela, o cache de metadados não será atualizado automaticamente e as consultas subsequentes retornarão dados do cache desatualizado. Para evitar isso, atualize o cache de metadados manualmente. Se o cache de metadados da tabela estiver configurado para ser atualizado automaticamente, será necessário alterar o modo de atualização da tabela para manual, realizar a atualização manual e definir o modo de atualização da tabela novamente para automático.

  • Se você estiver atualizando manualmente o cache de metadados e o conjunto de dados de destino e o bucket do Cloud Storage estiverem em um local regional, especifique explicitamente esse local ao executar chamada de procedimento BQ.REFRESH_EXTERNAL_METADATA_CACHE. É possível fazer isso das seguintes maneiras:

    Console

    1. Acessar a página do BigQuery.

      Acessar o BigQuery

    2. Selecione uma guia no Editor.

    3. Clique em Mais e, depois, em Configurações de consulta.

    4. Na seção Opções avançadas, desmarque a caixa de seleção Seleção automática de local e especifique a região de destino.

    5. Clique em Salvar.

    6. Execute a consulta que contém a chamada de procedimento BQ.REFRESH_EXTERNAL_METADATA_CACHE na guia "Editor".

    bq

    Se você executar a consulta que contém a chamada de procedimento BQ.REFRESH_EXTERNAL_METADATA_CACHE usando bq query, especifique a --location flag de dois minutos.

A seguir