Colocação em cache de metadados para tabelas externas

Este documento descreve como usar o armazenamento em cache de metadados (também conhecido como indexação de metadados de colunas) para melhorar o desempenho das consultas em tabelas de objetos e alguns tipos de tabelas do BigLake.

As tabelas de objetos e alguns tipos de tabelas BigLake podem colocar em cache informações de metadados sobre ficheiros em repositórios de dados externos, por exemplo, o Cloud Storage. Os seguintes tipos de tabelas do BigLake suportam o armazenamento em cache de metadados:

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

Os metadados incluem nomes de ficheiros, informações de partição e metadados para ficheiros, como contagens de linhas. Pode optar por ativar ou não a colocação em cache de metadados numa tabela. As consultas com um grande número de ficheiros e com filtros de partição do Hive beneficiam mais da colocação em cache de metadados.

Se não ativar a colocação em cache de metadados, as consultas na tabela têm de ler a origem de dados externa para obter os metadados de objetos. A leitura destes dados aumenta a latência da consulta. A listagem de milhões de ficheiros da origem de dados externa pode demorar vários minutos. Se ativar a colocação em cache de metadados, as consultas podem evitar a apresentação de ficheiros da origem de dados externa e podem particionar e reduzir ficheiros mais rapidamente.

Pode ativar o armazenamento em cache de metadados numa tabela de objetos ou do BigLake quando cria a tabela. Para mais informações sobre a criação de tabelas de objetos, consulte Crie tabelas de objetos. Para mais informações sobre como criar tabelas do BigLake, consulte um dos seguintes tópicos:

Definições de colocação em cache de metadados

Existem duas propriedades que controlam o comportamento desta funcionalidade:

  • O tempo máximo de desatualização especifica quando as consultas usam metadados em cache.
  • O modo de cache de metadados especifica como os metadados são recolhidos.

Quando tem a colocação em cache de metadados ativada, especifica o intervalo máximo de obsolescência dos metadados que é aceitável para operações na tabela. Por exemplo, se especificar um intervalo de 1 hora, as operações na tabela usam metadados em cache se tiverem sido atualizados na última hora. Se os metadados em cache forem mais antigos, a operação recorre à obtenção de metadados do repositório de dados (Amazon S3 ou Cloud Storage). Pode especificar um intervalo de desatualização entre 30 minutos e 7 dias.

Pode optar por atualizar a cache de forma automática ou manual:

  • Para as atualizações automáticas, a cache é atualizada a um intervalo definido pelo sistema, normalmente entre 30 e 60 minutos. A atualização automática da cache é uma boa abordagem se os ficheiros no repositório de dados forem adicionados, eliminados ou modificados em intervalos aleatórios. Se precisar de controlar a sincronização da atualização, por exemplo, para acionar a atualização no final de uma tarefa de extração, transformação e carregamento, use a atualização manual.
  • Para atualizações manuais, executa o BQ.REFRESH_EXTERNAL_METADATA_CACHE procedimento do sistema para atualizar a cache de metadados na programação que determinar. Para tabelas BigLake, pode atualizar os metadados seletivamente indicando subdiretórios do diretório de dados da tabela. Esta abordagem permite-lhe evitar o processamento desnecessário de metadados. A atualização manual da cache é uma boa abordagem se os ficheiros no repositório de dados forem adicionados, eliminados ou modificados a intervalos conhecidos, por exemplo, como resultado de um pipeline.

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

Se optar por usar atualizações automáticas, recomendamos que crie uma reserva e, em seguida, crie uma atribuição com um BACKGROUNDtipo de tarefa para o projeto que executa as tarefas de atualização da cache de metadados. Isto impede que as tarefas de atualização concorram com as consultas dos utilizadores por recursos e, potencialmente, falhem se não existirem recursos suficientes disponíveis para as mesmas.

Deve considerar a forma como os valores do intervalo de desatualização e do modo de colocação em cache de metadados interagem antes de os definir. Considere os seguintes exemplos:

  • Se a cache de metadados de uma tabela estiver definida para exigir atualizações manuais e o intervalo de desatualização estiver definido para 2 dias, tem de executar o procedimento do sistema BQ.REFRESH_EXTERNAL_METADATA_CACHE a cada 2 dias ou menos se quiser que as operações na tabela usem metadados em cache.
  • Se a cache de metadados de uma tabela estiver definida para ser atualizada automaticamente e o intervalo de desatualização estiver definido para 30 minutos, algumas das operações na tabela podem ler a partir do arquivo de dados se a atualização da cache de metadados demorar mais tempo do que o habitual intervalo de 30 a 60 minutos.

Para mais informações sobre a definição de opções de colocação em cache de metadados para tabelas BigLake, consulte os artigos Crie tabelas externas do BigLake do Amazon S3 ou Crie tabelas externas do BigLake para o Cloud Storage.

Para mais informações sobre como definir opções de colocação em cache de metadados para tabelas de objetos, consulte o artigo Crie tabelas de objetos.

Receba informações sobre tarefas de atualização da cache de metadados

Para encontrar informações sobre tarefas de atualização da cache de metadados, consulte a vista INFORMATION_SCHEMA.JOBS, conforme mostrado no exemplo seguinte:

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;

Use chaves de encriptação geridas pelo cliente com metadados em cache

Os metadados em cache estão protegidos pela chave de encriptação gerida pelo cliente (CMEK) usada para a tabela à qual os metadados em cache estão associados. Pode ser uma CMEK aplicada diretamente à tabela ou uma CMEK que a tabela herda do conjunto de dados ou do projeto.

Se for definida uma CMEK predefinida para o projeto ou o conjunto de dados, ou se a CMEK existente para o projeto ou o conjunto de dados for alterada, isto não afeta as tabelas existentes nem os respetivos metadados em cache. Tem de alterar a chave da tabela para aplicar a nova chave à tabela e aos respetivos metadados em cache.

As CMEKs criadas no BigQuery não se aplicam aos ficheiros do Cloud Storage usados pelo BigLake e pelas tabelas de objetos. Para obter a encriptação CMEK ponto a ponto, configure as CMEK no Cloud Storage para esses ficheiros.

Obtenha informações sobre a utilização da cache de metadados através de tarefas de consulta

Para obter informações sobre a utilização da cache de metadados para uma tarefa de consulta, chame o método jobs.get para essa tarefa e consulte o campo MetadataCacheStatistics na secção JobStatistics2 do recurso Job. Este campo fornece informações sobre as tabelas com a cache ativada de metadados que foram usadas pela consulta, se a cache de metadados foi usada pela consulta e, se não foi, o motivo.

Estatísticas da tabela

Para tabelas do BigLake baseadas em ficheiros Parquet, as estatísticas da tabela são recolhidas quando a cache de metadados é atualizada. A recolha de estatísticas das tabelas ocorre durante as atualizações automáticas e manuais, e as estatísticas são mantidas durante o mesmo período que a cache de metadados.

As estatísticas da tabela recolhidas incluem informações de ficheiros, como a contagem de linhas, os tamanhos dos ficheiros físicos e não comprimidos, e a cardinalidade das colunas. Quando executa uma consulta numa tabela BigLake baseada em Parquet, estas estatísticas são fornecidas ao otimizador de consultas para permitir um melhor planeamento de consultas e, potencialmente, melhorar o desempenho das consultas para alguns tipos de consultas. Por exemplo, a propagação de restrições dinâmicas é uma otimização de consultas comum, em que o otimizador de consultas infere dinamicamente predicados nas tabelas de factos maiores numa junção a partir das tabelas de dimensões mais pequenas. Embora esta otimização possa acelerar as consultas através da utilização de esquemas de tabelas normalizados, requer estatísticas de tabelas precisas. As estatísticas das tabelas recolhidas 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 aplicam-se à cache de metadados:

  • Se emitir várias atualizações manuais em simultâneo, apenas uma é bem-sucedida.
  • A cache de metadados expira após 7 dias se não for atualizada.
  • Se atualizar o URI de origem de uma tabela, a cache de metadados não é atualizada automaticamente, e as consultas subsequentes devolvem dados da cache obsoleta. Para evitar esta situação, atualize manualmente a cache de metadados. Se a cache de metadados da tabela estiver definida para atualização automática, tem de alterar o modo de atualização da tabela para manual, fazer a atualização manual e, em seguida, definir novamente o modo de atualização da tabela para automático.

  • Se estiver a atualizar manualmente a cache de metadados e o conjunto de dados de destino e o contentor do Cloud Storage estiverem numa localização regional, tem de especificar explicitamente esta localização quando executar a chamada de procedimento BQ.REFRESH_EXTERNAL_METADATA_CACHE. Pode fazê-lo de uma das seguintes formas:

    Consola

    1. Aceda à página do BigQuery.

      Aceda ao BigQuery

    2. Selecione um separador no editor.

    3. Clique em Mais e, de seguida, clique em Definições de consulta.

    4. Na secção Opções avançadas, desmarque a caixa de verificação Seleção automática de localizações e, de seguida, especifique a região de destino.

    5. Clique em Guardar.

    6. Execute a consulta que contém a chamada de procedimento BQ.REFRESH_EXTERNAL_METADATA_CACHE nesse separador do editor.

    bq

    Se executar a consulta que contém o BQ.REFRESH_EXTERNAL_METADATA_CACHEprocedimento de chamada através debq query, certifique-se de que especifica a flag --location.

O que se segue?