Consultas globais

Visualizar

Este produto ou recurso está sujeito aos "Termos das Soluções Pré-GA" na seção "Termos Gerais de Serviço" dos Termos Específicos de Serviço. Os produtos e recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

Observação: para receber suporte ou enviar feedback sobre esse recurso em pré-lançamento, entre em contato com [e-mail].

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 o projeto em execução da consulta.
• 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 o projeto que contém os dados.
• Sempre que sua consulta acessar tabelas remotas, essas opções serã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 com êxito, é necessário fazer a seguinte configuração:

1. É necessário ativar a execução de consultas globais no projeto (query_project) na região que executa uma consulta global (us-central1):

   ALTER PROJECT `query_project`
   SET OPTIONS (
   `region-us-central1.enable_global_queries_execution` = TRUE
   );

2. É 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, já que se referem a projetos e regiões diferentes. 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 essa função.
3. Atribua este 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 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 nas 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 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

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 e desempenho da transferência: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 de produtos no local us-central1, mas mantém as transações 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 a processam.

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 manipulação de dados (DML, na sigla em inglês) (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.

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 local. Confira a seguir uma abstração do fluxo de trabalho de consulta global realizado pelo BigQuery:

1. Determine onde a consulta deve 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 24 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ó são transferidos quando necessário.

Observabilidade

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

Histórico de jobs

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.

API REST Jobs

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

• statistics.global_query_remote_regions: 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 principais na região de execução principal. Ele fica vazio para jobs de consulta global filhos e consultas de região única.
• statistics.parent_global_query_job: um objeto JobReference (projectId, jobId, location) que identifica a tarefa de consulta global principal. 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 principal e consultas de região única.

Registros de auditoria

Em 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 só é preenchido para jobs de consulta global principais na região de execução principal.
• jobStats.parentGlobalQueryJobId: o ID do job de consulta global principal. Esse campo é preenchido para jobs filhos executados em regiões remotas.
• jobStats.parentGlobalQueryJobLocation: o local do job de consulta global principal. 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 principal, 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 registros ou o conjunto de dados de destino do coletor de registros.
• PARENT_JOB_ID: o ID do job de consulta global principal.

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 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

• 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.
• As consultas globais não são compatíveis com o modo sandbox.
• As consultas globais não são compatíveis com endpoints regionais.
• 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 do tipo RANGE com consultas globais.
• Não é possível consultar colunas usando nomes de colunas flexíveis com consultas globais.
• Não é possível consultar visualizações INFORMATION_SCHEMA de uma região remota em uma consulta global.
• 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). Em vez disso, crie visualizações autorizadas na região em que seus dados estão localizados e consulte essas visualizações com consultas globais.
• Visualizações materializadas em consultas globais estão indisponíveis.
• 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 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 padrão do KMS para o projeto que executa consultas globais na região remota.
• As consultas globais não são compatíveis com o Assured Workloads.
• Uma única consulta global pode acessar até 10 tabelas remotas por região.
• As consultas globais só são compatíveis com o Data Studio quando estão envolvidas em uma visualização e configuradas para usar as credenciais do leitor.