Consultas globais

Com as consultas globais, é possível executar consultas SQL que referenciam dados armazenados em mais de uma região. Por exemplo, você pode executar uma consulta global que une uma tabela localizada em us-central1 com uma tabela localizada em europe-central2. Neste documento, explicamos como ativar e executar consultas globais no seu projeto.

Antes de começar

Verifique se as consultas globais estão ativadas no seu projeto e se você tem as permissões necessárias para executá-las.

Ativar consultas globais

Para ativar consultas globais no seu projeto ou organização, use a instrução ALTER PROJECT SET OPTIONS ou ALTER ORGANIZATION SET OPTIONS para mudar a configuração padrão.

  • Para executar consultas globais em uma região, defina o argumento enable_global_queries_execution como true nessa região para um projeto em que a consulta é executada.
  • Para permitir que consultas globais copiem dados de uma região, defina o argumento enable_global_queries_data_access como true nessa região para um projeto em que os dados estão armazenados.
  • As consultas globais podem ser executadas em um projeto e extrair dados de outras regiões de outro projeto.

O exemplo a seguir mostra como modificar essas configurações no nível do projeto. Imagine que você queira executar consultas globais na região REGION_1 do projeto PROJECT_1_ID e extrair dados de REGION_2 no projeto PROJECT_2_ID:

ALTER PROJECT `PROJECT_1_ID`
SET OPTIONS (
  `region-REGION_1.enable_global_queries_execution` = true
);
ALTER PROJECT `PROJECT_2_ID`
SET OPTIONS (
  `region-REGION_2.enable_global_queries_data_access` = true
);

Substitua:

  • PROJECT_1_ID: o nome do projeto em que as consultas globais serão executadas.
  • REGION_1: a região em que as consultas globais serão executadas.
  • PROJECT_2_ID: o nome do projeto de onde as consultas globais vão extrair dados.
  • REGION_2: a região de onde as consultas globais vão extrair dados.

Pode levar vários minutos para que a mudança entre em vigor.

Permissão necessária

Para executar uma consulta global, é necessário ter a permissão bigquery.jobs.createGlobalQuery. O papel de administrador do BigQuery é o único papel predefinido que contém essa permissão. Para conceder permissão para executar consultas globais sem conceder o papel de administrador do BigQuery, siga estas etapas:

  1. Crie um papel personalizado, por exemplo, "Executor de consultas globais do BigQuery".
  2. Adicione bigquery.jobs.createGlobalQuery a esse papel.
  3. Atribua esse papel aos usuários ou contas de serviço selecionados.

Consultar dados

Para executar uma consulta global, escreva uma consulta SQL como se os dados estivessem em um único local. Se os dados referenciados pela consulta estiverem armazenados em mais de um local, o BigQuery tentará executar uma consulta global. Em alguns casos, o BigQuery seleciona automaticamente o local da consulta. Caso contrário, especifique o local em que a consulta será executada. Os dados referenciados pela consulta que não estão no local selecionado são copiados para lá.

O exemplo a seguir é executado como uma consulta global que une tabelas de dois conjuntos de dados diferentes armazenados em dois locais diferentes:

SELECT id, tr_date, product_id, price FROM us_dataset.transactions
UNION ALL
SELECT id, tr_date, product_id, price FROM europe_dataset.transactions

Seleção automática de local

Nos casos a seguir, o local em que uma consulta precisa ser executada é determinado automaticamente e não pode ser alterado:

  • As consultas de linguagem de modificação de dados (instruções INSERT, UPDATE e DELETE) são sempre executadas em um local da tabela de destino.
  • Consultas de linguagem de definição de dados, como a instrução CREATE TABLE AS SELECT, são sempre executadas no local em que um recurso é criado ou modificado.
  • As consultas com uma tabela de destino especificada sempre são executadas no local em que a tabela de destino está.

Escolha um local

Em geral, você decide onde as consultas globais são executadas. Para tomar essa decisão, considere o seguinte:

  • As consultas globais copiam temporariamente dados de um local para outro. Se a organização tiver requisitos de residência de dados e você não quiser que os dados do local A saiam dele, defina o local da consulta como A.

  • Para minimizar a quantidade de dados transferidos entre locais e reduzir o custo da consulta, execute-a na região em que a maioria dos dados consultados está armazenada.

Imagine que você tenha uma loja on-line e mantenha uma lista de produtos no local us-central1, mas as transações sejam na região us-south1. Se houver mais transações do que produtos no catálogo, execute a consulta na região us-south1.

Entender as consultas globais

Para executar consultas globais de maneira eficiente e econômica, é importante entender o mecanismo por trás da execução delas.

Para usar dados que residem em locais diferentes, eles precisam ser replicados em um único local. Confira a seguir uma abstração do fluxo de trabalho de consulta global realizado pelo BigQuery:

  1. Determine onde a consulta precisa ser executada, seja pela declaração do usuário ou automaticamente. Esse local é chamado de principal, e todos os outros referenciados pela consulta são remotos.
  2. Execute uma subconsulta em cada região remota para coletar os dados necessários para concluir a consulta na região principal.
  3. Copie esses dados de locais remotos para o local principal.
  4. Salve os dados em tabelas temporárias no local principal por 8 horas.
  5. Execute uma consulta final com todos os dados coletados no local principal.
  6. Retorne os resultados da consulta.

O BigQuery tenta minimizar a quantidade de dados transferidos entre regiões. Veja o exemplo a seguir.

SET @@location = 'EU';
SELECT
  t1.col1, t2.col2
FROM
  eu_dataset.table1 t1
  JOIN us_dataset.table2 t2 using col3
WHERE
  t2.col4 = 'ABC'

O BigQuery não precisa replicar toda a tabela t2 dos EUA para a UE. É suficiente transferir apenas as colunas solicitadas (col2 e col3) e apenas as linhas que correspondem à condição WHERE (t2.col4 = 'ABC'). No entanto, esses mecanismos, conhecidos como pushdowns, dependem da estrutura da consulta e, às vezes, a quantidade de dados transferidos pode ser grande. Recomendamos que você teste consultas globais em um pequeno subconjunto de dados e confirme que os dados só serão transferidos quando necessário.

Observabilidade

Para conferir o texto da consulta enviado à região remota, verifique o histórico de jobs. O job remoto tem o mesmo ID da consulta original, com um sufixo _xregion adicional.

Desativar consultas globais

Para desativar as consultas globais no seu projeto ou organização, use ALTER PROJECT SET OPTIONS statement ou ALTER ORGANIZATION SET OPTIONS statement para mudar a configuração padrão.

  • Para desativar as consultas globais em uma região, defina o argumento enable_global_queries_execution como false ou NULL nessa região.
  • Para impedir que consultas globais copiem dados de uma região, defina o argumento enable_global_queries_data_access como false ou NULL nessa região.

O exemplo a seguir mostra como desativar consultas globais no nível do projeto:

ALTER PROJECT PROJECT_ID
SET OPTIONS (
  `region-REGION.enable_global_queries_execution` = false,
  `region-REGION.enable_global_queries_data_access` = false
);

Substitua:

  • PROJECT_ID: o nome do projeto a ser alterado.
  • REGION: o nome da região em que as consultas globais serão desativadas

Pode levar vários minutos para que a mudança entre em vigor.

Preços

O custo de uma consulta global consiste nos seguintes componentes:

  • O custo de computação de cada subconsulta em locais remotos, com base no seu modelo de preços nesses locais
  • O custo de computação da consulta final na região em que ela é executada, com base no seu modelo de preços nessa região
  • O custo de copiar dados entre locais diferentes, de acordo com os preços da replicação de dados
  • O custo de armazenamento dos dados copiados de regiões remotas para a região principal (por 8 horas), de acordo com os preços de armazenamento

Cotas

Para informações sobre cotas relacionadas a consultas globais, consulte Jobs de consulta.

Limitações

  • Os detalhes da execução e o gráfico de execução de uma consulta não mostram o número de bytes processados e transferidos de locais remotos. Essas informações aparecem nos jobs de cópia, que podem ser encontrados no histórico de jobs. O ID de um job de cópia criado por uma consulta global tem o ID do job de consulta como prefixo.
  • Consultas globais não são compatíveis com o modo sandbox
  • As consultas globais têm uma latência maior do que as de uma única região devido ao tempo necessário para transferir dados entre regiões.
  • As consultas globais não usam cache para evitar a transferência de dados entre regiões.
  • Não é possível consultar pseudocolunas, como _PARTITIONTIME, com consultas globais.
  • Não é possível consultar colunas usando nomes de colunas flexíveis com consultas globais.
  • Ao referenciar as colunas de uma tabela do BigLake em uma cláusula WHERE, não é possível usar os literais RANGE ou INTERVAL.
  • As visualizações autorizadas e rotinas autorizadas globais não são compatíveis (quando uma visualização ou rotina em um local tem autorização para acessar um conjunto de dados em outro local).
  • Não há suporte para visualizações materializadas em consultas globais.
  • Se a consulta global fizer referência a colunas STRUCT, nenhum pushdown será aplicado a subconsultas remotas. Para otimizar a performance, crie uma visualização na região remota que filtre as colunas STRUCT e retorne apenas os campos necessários como colunas individuais.
  • As consultas globais não são executadas de forma atômica. Nos casos em que a replicação de dados é bem-sucedida, mas a consulta geral falha, você ainda recebe uma cobrança pela replicação de dados.
  • As tabelas temporárias criadas em regiões remotas como parte da execução de consultas globais só são criptografadas usando chaves de criptografia gerenciadas pelo cliente (CMEK) se uma chave CMEK configurada para criptografar os resultados da consulta global (em uma tabela, um conjunto de dados ou um projeto) for global. Para garantir que as tabelas temporárias remotas estejam sempre protegidas com a CMEK, defina uma chave KMS padrão para o projeto que executa consultas globais na região remota.
  • As consultas globais não são compatíveis com o Assured Workloads.
  • É possível consultar no máximo 10 tabelas por região em uma consulta global.