Algumas ou todas as informações nesta página podem não se aplicar ao Cloud de Confiance da S3NS. Consulte Diferenças do Google Cloud para saber mais.

O Google usa tecnologia de IA na tradução de conteúdos para seu idioma de preferência. As traduções com IA podem ter erros.

Consultas globais

Com as consultas globais, é possível executar consultas SQL que fazem referência a dados armazenados em mais de uma região. Por exemplo, é possível executar uma consulta global que mescla 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 para seu projeto e se você tem as permissões necessárias para executá-las.

Ativar consultas globais

Para ativar as 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 o projeto que está executando a consulta.
Para permitir que as consultas globais copiem dados de uma região, defina o argumento enable_global_queries_data_access como true nessa região para o projeto que contém os dados.
Sempre que sua consulta acessa tabelas remotas, essas opções são verificadas.
As consultas globais podem ser executadas em um projeto e extrair dados de outras regiões de outro projeto.

Exemplo: configuração entre projetos

O exemplo a seguir mostra como executar uma consulta em um projeto que acessa uma tabela em outro projeto.

Suponha que você tenha um projeto query_project executando jobs na região us-central1 e queira executar uma consulta que acesse uma tabela data_project.dataset.my_table localizada na região europe-west1:

SET @@location='us-central1';
SELECT
  *
FROM
  `query_project.dataset.my_table`
  JOIN `data_project.dataset.my_other_table` USING id;

Para que essa consulta global seja executada, é preciso fazer a seguinte configuração:

É necessário ativar a execução de consultas globais no projeto (query_project) na região que está executando uma consulta global (us-central1):
```
ALTER PROJECT `query_project`
SET OPTIONS (
`region-us-central1.enable_global_queries_execution` = TRUE
)
```
É necessário ativar a cópia de dados por consultas globais do projeto que contém os dados (data_project) para a região dele (europe-west1):
```
ALTER PROJECT `data_project`
SET OPTIONS (
`region-europe-west1.enable_global_queries_data_access` = TRUE
)
```

Para criar e usar visualizações que contêm tabelas remotas, os mesmos princípios se aplicam: o projeto que executa as consultas precisa ter o enable_global_queries_execution ativado.

Essas operações ALTER PROJECT precisam ser executadas separadamente, porque se referem a projetos e regiões diferentes. Pode levar alguns 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:

Crie um papel personalizado, por exemplo, "Executor de consultas globais do BigQuery".
Adicione bigquery.jobs.createGlobalQuery a esse papel.
Atribua esse papel aos usuários ou às 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 vai tentar executar uma consulta global. Se você não especificar o local em que a consulta será executada, o BigQuery vai selecionar automaticamente o local com base nos locais das tabelas referenciadas. Para mais informações, consulte Escolher um local. Os dados referenciados pela consulta que não estão no local selecionado são copiados para ele.

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

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

Escolha um local

Para configurar onde a consulta global será executada, especifique um local. Ao decidir um local de execução para a consulta global, considere o seguinte:

Residência de dados:as consultas globais copiam temporariamente os dados de um local para outro. Se a organização tiver requisitos de residência de dados e você não quiser que seus dados saiam de um determinado local, defina o local da consulta como esse local.
Custos de transferência de dados e desempenho: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.

Por exemplo, você tem uma loja on-line e mantém uma lista dos seus produtos no local us-central1, mas as transações ficam na região us-south1. Se houver mais transações do que produtos no catálogo, execute a consulta na região us-south1.
Reservas e capacidade de computação:especifique o local da consulta para controlar quais reservas ou slots regionais processam a consulta.

Se você não especificar um local manualmente, o BigQuery vai determinar automaticamente o local de execução com base nos seguintes critérios:

Para consultas de linguagem de modificação de dados (DML) (instruções INSERT, UPDATE e DELETE), o local da tabela de destino é selecionado como o local de execução.
Para consultas de linguagem de definição de dados (DDL), como instruções CREATE TABLE AS SELECT, o local em que o recurso é criado ou modificado é selecionado como o local de execução.
Para consultas com uma tabela de destino especificada, o local da tabela de destino é selecionado como o local de execução.
Para todas as outras consultas, o local de execução é selecionado arbitrariamente como um dos locais dos conjuntos de dados referenciados.

Noções básicas sobre 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 para um local. Veja a seguir uma abstração do fluxo de trabalho de consulta global realizado pelo BigQuery:

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 locais referenciados pela consulta são remotos.
Executar uma subconsulta em cada região remota para coletar os dados necessários para concluir a consulta na região principal.
Copie esses dados de locais remotos para o local principal.
Salvar os dados em tabelas temporárias no local principal por 24 horas. Para resultados de subconsultas menores que 10 GiB, os dados podem ser armazenados em cache para reutilização, evitando a transferência entre regiões.
Executar uma consulta final com todos os dados coletados no local principal.
Retorne os resultados da consulta.

O BigQuery tenta minimizar a quantidade de transferência de dados 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. Basta 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 as consultas globais em um pequeno subconjunto de dados e confirme se os dados são transferidos apenas quando necessário.

Observabilidade

Para monitorar consultas globais e inspecionar a execução delas em várias regiões, use os seguintes métodos:

Histórico de jobs

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

API REST de jobs

Quando você chama o método jobs.get, o recurso Job retornado contém os seguintes campos no objeto JobStatistics:

statistics.globalQueryRemoteRegions: uma matriz de strings que representa as regiões remotas de onde uma consulta global acessa dados. Esse campo é preenchido apenas para jobs de consulta global pai na região de execução principal. Ele fica vazio para jobs de consulta global filhos e consultas de região única.
statistics.parentGlobalQueryJob: um objeto JobReference (projectId, jobId, location) que identifica o job de consulta global pai. Esse campo é preenchido apenas para jobs de consulta global filhos (subconsultas remotas e jobs de cópia entre regiões) executados em regiões remotas em nome de uma consulta global. Ele não é definido para jobs de consulta global pai e consultas de região única.

Registros de auditoria

Nos Registros de auditoria do Cloud, o objeto BigQueryAuditMetadata contém os seguintes campos no objeto JobStats:

jobStats.globalQueryRemoteRegions: uma matriz de strings que representa as regiões remotas acessadas pela consulta. Esse campo é preenchido apenas para jobs de consulta global pai na região de execução principal.
jobStats.parentGlobalQueryJobId: O ID da tarefa do job de consulta global pai. Esse campo é preenchido para jobs filhos executados em regiões remotas.
jobStats.parentGlobalQueryJobLocation: o local do job de consulta global pai. Esse campo é preenchido para jobs filhos executados em regiões remotas.

Encontrar jobs filhos remotos para uma consulta global

Para encontrar todos os jobs filhos remotos associados a uma consulta global pai, consulte os registros de auditoria usando a Análise de dados de registros ou um conjunto de dados de coletor de registros exportado:

SELECT
  timestamp,
  proto_payload.audit_log.resource_name AS resource_name,
  JSON_VALUE(proto_payload.audit_log.metadata.jobChange.job.jobConfig.queryConfig.query) AS query
FROM
  `PROJECT_ID.LOG_DATASET._AllLogs`
WHERE
  JSON_VALUE(proto_payload.audit_log.metadata.jobChange.job.jobStats.parentGlobalQueryJobId) = 'PARENT_JOB_ID';

Substitua:

PROJECT_ID: é seu ID do projeto no Google Cloud.
LOG_DATASET: o conjunto de dados vinculado do BigQuery para a Análise de Dados de Registros ou o conjunto de dados de destino do coletor de registros.
PARENT_JOB_ID: o ID da tarefa do job de consulta global pai.

Visualizações INFORMATION_SCHEMA

É possível consultar as visualizações INFORMATION_SCHEMA.JOBS e INFORMATION_SCHEMA.JOBS_TIMELINE para inspecionar metadados de consultas globais. A coluna global_query_info contém os seguintes campos:

parent_job_id: o ID do job de consulta global pai na região principal. Esse campo é preenchido para subconsultas filhas e jobs de cópia executados em regiões remotas.
parent_job_location: o local do job de consulta global pai.
remote_regions: uma matriz de regiões remotas referenciadas pela consulta. Esse campo é preenchido para o job de consulta global pai na região principal.

Identificar consultas globais em uma região principal

Para encontrar todas as consultas globais executadas em uma região principal e ver quais regiões remotas foram referenciadas, consulte a visualização INFORMATION_SCHEMA.JOBS na região principal:

SELECT
  job_id,
  creation_time,
  query,
  total_bytes_billed,
  global_query_info.remote_regions
FROM
  `region-REGION`.INFORMATION_SCHEMA.JOBS
WHERE
  ARRAY_LENGTH(global_query_info.remote_regions) > 0;

Substitua REGION pela região em que a consulta global foi executada, como us-central1.

Encontrar jobs filhos remotos para uma consulta global

Para encontrar todos os jobs filhos remotos associados a uma consulta global pai, consulte a visualização INFORMATION_SCHEMA.JOBS na região remota:

SELECT
  job_id,
  project_id,
  job_type,
  statement_type,
  total_bytes_billed,
  total_slot_ms
FROM
  `region-REMOTE_REGION`.INFORMATION_SCHEMA.JOBS
WHERE
  global_query_info.parent_job_id = 'PARENT_JOB_ID';

Substitua:

REMOTE_REGION: a região remota em que a subconsulta filha ou o job de cópia foi executado, como europe-west1.
PARENT_JOB_ID: o ID da tarefa do job de consulta global pai.

Desativar consultas globais

Para desativar as consultas globais no seu projeto ou organização, use o 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 proibir 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 alguns 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 de replicação de dados.
O custo de armazenamento de dados copiados de regiões remotas para a região principal (por 24 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

As consultas globais não são compatíveis com o Assured Workloads.
As consultas globais não são compatíveis com endpoints regionais.
As consultas globais não são compatíveis com o modo sandbox.
As consultas globais têm uma latência maior do que as consultas de região única devido ao tempo necessário para transferir dados entre regiões.
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 é cobrado pela replicação de dados.
Uma única consulta global pode acessar até 10 tabelas remotas por região.
As tabelas temporárias criadas em regiões remotas como parte da execução de consultas globais só serã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, conjunto de dados ou nível de projeto) for global. Para garantir que as tabelas temporárias remotas sejam sempre protegidas usando CMEK, defina uma chave KMS padrão para o projeto que executa consultas globais na região remota.
Não há suporte para visualizações autorizadas e rotinas autorizadas globais (quando uma visualização ou rotina em um local é autorizada a acessar um conjunto de dados em outro local). Em vez disso, crie visualizações autorizadas na região em que os dados estão localizados e consulte as visualizações autorizadas usando consultas globais.
Não há suporte para visualizações materializadas em consultas globais.
Não é possível consultar colunas com tipo RANGE com consultas globais.
Não é possível consultar pseudocolunas, como _PARTITIONTIME, com consultas globais.
Não é possível consultar colunas usando nomes de coluna flexíveis com consultas globais.
Se a consulta global fizer referência a colunas STRUCT, nenhum pushdown será aplicado a subconsultas remotas. Para otimizar o desempenho, crie uma visualização na região remota que filtre colunas STRUCT e retorne apenas os campos necessários como colunas individuais.
Os detalhes 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 você encontra no histórico de jobs. O código da tarefa de um job de cópia criado por uma consulta global tem o código da tarefa do job de consulta como prefixo.
As consultas globais só são compatíveis com o Data Studio quando estão encapsuladas em uma visualização e configuradas para usar as credenciais do leitor.