Introdução às consultas contínuas

As consultas contínuas do BigQuery são instruções SQL executadas continuamente para permitir a análise dos dados recebidos no BigQuery em tempo real. Você pode usar consultas contínuas para tarefas urgentes, como gerar insights imediatos, aplicar inferência de machine learning (ML) em tempo real e replicar dados para outras plataformas. Com esse recurso, é possível usar o BigQuery como um mecanismo de tratamento de dados orientado a eventos para a lógica de decisão nos aplicativos.

Destinos e fontes de dados compatíveis

É possível gravar ou exportar as linhas de saída produzidas por uma consulta contínua para os seguintes destinos:

• Tabelas do BigQuery
• Tabelas gerenciadas do Apache Iceberg
• Tópicos do Pub/Sub
• Tabelas do Bigtable
• Tabelas do Spanner

As consultas contínuas podem processar dados que foram gravados em tabelas padrão do BigQuery ou tabelas gerenciadas do Apache Iceberg usando um dos seguintes métodos:

• A API BigQuery Storage Write (gRPC)
• A API BigQuery Storage Write (REST)
• Carregamento em lote
• A instrução DML INSERT
• Modificar instruções de linguagem de manipulação de dados (DML), como DELETE, UPDATE e MERGE, ao exportar dados para o Pub/Sub.
• Gravações dos resultados de uma consulta em lote em uma tabela permanente
• Grava os resultados de uma consulta contínua do BigQuery em uma tabela permanente.
• Uma assinatura do Pub/Sub BigQuery
• Gravações do Dataflow no BigQuery
• Grava do Datastream no BigQuery usando o modo de gravação somente anexar.

O diagrama a seguir mostra fluxos de trabalho comuns de consulta contínua:

Casos de uso

Veja alguns casos de uso comuns em que convém usar consultas contínuas:

• Serviços personalizados de interação com o cliente: use a IA generativa para criar mensagens personalizadas para cada interação com o cliente.
• Detecção de anomalias: crie soluções que permitam realizar detecção de anomalias e ameaças em dados complexos em tempo real, para que você possa reagir a problemas mais rapidamente.
• Pipelines personalizáveis baseados em eventos: use a integração de consulta contínua com o Pub/Sub para acionar aplicativos downstream com base nos dados recebidos.
• Aprimoramento de dados e extração de entidades: use consultas contínuas para realizar aprimoramento e transformação de dados em tempo real usando funções SQL e modelos de ML.
• ETL (extrair, transformar e carregar) reverso: execute ETL reverso em tempo real em outros sistemas de armazenamento mais adequados para veiculação de aplicativos de baixa latência. Por exemplo: analisar ou aprimorar dados de eventos gravados no BigQuery; e, em seguida, fazer streaming para o Bigtable, Spanner ou tabelas gerenciadas do Apache Iceberg para veiculação do aplicativo.
• Acionamento de agentes autônomos: acione pipelines de dados agênticos em tempo real com base em eventos complexos detectados em streams de dados em tempo real. Para ver um exemplo, consulte o codelab Criar um agente de dados orientado por eventos com o BigQuery e o Kit de Desenvolvimento de Agente (ADK).
• Monitoramento autônomo de agentes: desenvolva monitoramento e alertas automatizados em tempo real para interações agênticas em tempo real usando o plug-in de análise de agentes do BigQuery, que transmite todos os dados de trace do agente, uso de ferramentas e registros operacionais diretamente para o BigQuery para uma observabilidade profunda da sua força de trabalho de IA.

Funcionalidade compatível

As seguintes operações são aceitas em consultas contínuas:

• Execução de instruções INSERT para gravar dados de uma consulta contínua em uma tabela do BigQuery ou em uma tabela gerenciada do Iceberg.

• Execução de instruções EXPORT DATA para publicar a saída de consultas contínuas em tópicos do Pub/Sub.

  As consultas contínuas que exportam dados para o Pub/Sub precisam ser executadas usando uma conta de serviço. Para mais informações, consulte Exportar dados para o Pub/Sub.

  A partir de um tópico do Pub/Sub, é possível usar os dados com outros serviços, como análise de streaming usando o Dataflow, ou usando os dados em um fluxo de trabalho do Application Integration.

• Execução de instruções EXPORT DATA para exportar dados do BigQuery para tabelas Bigtable. Para mais informações, consulte Exportar dados para o Bigtable.

• Execução de instruções EXPORT DATA para exportar dados do BigQuery para tabelas do Spanner. Para mais informações, consulte Exportar dados para o Spanner (ETL reverso).

• Chamando as seguintes funções de IA generativa:

  • AI.GENERATE

  • AI.GENERATE_TEXT

    • Essa função exige que você tenha um modelo remoto do BigQuery ML em um modelo da Gemini Enterprise Agent Platform.

• Chamar as seguintes funções de IA:

  • ML.UNDERSTAND_TEXT
  • ML.TRANSLATE

  Essas funções exigem que você tenha um modelo remoto do BigQuery ML em uma API de IA do Google Cloud.

• Normalizar dados numéricos usando a função ML.NORMALIZER.

• Análise e processamento de dados JSON, incluindo suporte para funções JSON e desaninhamento JSON.

• Usar funções do GoogleSQL sem estado, por exemplo, funções de conversão. Em funções sem estado, cada linha é processada independentemente de outras linhas na tabela.

• Usar operações com estado, como JOINs, agregações e agregações de janela. Nas operações com estado, o estado dos dados ingeridos é retido em várias linhas ou intervalos de tempo para calcular um resultado preciso.

• Usar a função de histórico de alterações APPENDS para processar dados anexados de um momento específico em tabelas padrão do BigQuery ou tabelas gerenciadas do Apache Iceberg.

• Usar a função do histórico de alterações CHANGES para processar dados alterados, incluindo adições e mutações, de um momento específico ao exportar dados para o Pub/Sub. No entanto, CHANGES não é compatível com o uso de uma operação com estado ou com a consulta de tabelas gerenciadas do Iceberg.

• Consultar visualizações, desde que a consulta SQL subjacente da visualização seja uma consulta contínua válida.

Operações com estado compatíveis

Visualizar

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

Para solicitar suporte ou enviar feedback sobre esse recurso, envie um e-mail para [e-mail].

As operações com estado permitem que as consultas contínuas realizem análises complexas que exigem a retenção de informações em várias linhas ou intervalos de tempo. Enquanto as funções sem estado processam cada linha de forma independente, as operações com estado mantêm o estado dos dados ingeridos para oferecer suporte a funções como JOINs, agregações e agregações de janela. Esse recurso permite correlacionar eventos de diferentes streams ou calcular métricas ao longo do tempo, como uma média de 30 minutos, armazenando os dados necessários na memória enquanto a consulta é executada.

As consultas contínuas aceitam as seguintes operações com estado:

• JOINs
• Agregações e janelas
• UNION ALL

Autorização

Os tokens de acesso doGoogle Cloud que são usados quando jobs de consulta contínua têm um time to live (TTL) de dois dias quando são gerados por uma conta de usuário. Portanto, esses jobs param de ser executados após dois dias. Os tokens de acesso gerados pelas contas de serviço podem ser executados por mais tempo, mas ainda precisam aderir ao tempo de execução máximo da consulta. Para mais informações, consulte Executar uma consulta contínua usando uma conta de serviço.

Locais

Para uma lista de regiões com disponibilidade, consulte Locais de consulta contínua do BigQuery.

Limitações

As consultas contínuas estão sujeitas às seguintes limitações:

• O estado dos dados ingeridos é mantido apenas para as operações com estado específicas no pré-lançamento. Embora as consultas contínuas agora sejam compatíveis com alguns tipos de JOINs, agregações e agregações de janela, elas são restritas a operações com estado específicas. Nem todos os tipos de operações com estado são compatíveis.

• Não é possível usar os seguintes recursos de SQL em uma consulta contínua, a menos que eles estejam listados como uma operação com estado compatível:

  • Os seguintes operadores de consulta:

    • PIVOT
    • UNPIVOT
    • TABLESAMPLE

  • Operadores de conjunto de consulta, exceto UNION ALL.

  • A instrução SELECT DISTINCT

  • As subconsultas EXISTS ou NOT EXISTS

  • CTEs recursivos

  • Funções definidas pelo usuário

  • Chamadas de função de janela

  • Funções do BigQuery ML que não sejam as listadas em Funcionalidades compatíveis

  • Instruções de linguagem de definição de dados (DDL, na sigla em inglês)

  • Instruções de linguagem de manipulação de dados (DML, na sigla em inglês) exceto INSERT.

  • Instruções de linguagem de controle de dados (DCL, na sigla em inglês)

  • Instruções EXPORT DATA que não segmentam o Bigtable, o Pub/Sub ou o Spanner.

  • Linguagem processual

  • Instruções sobre depuração

• As consultas contínuas não são compatíveis com as seguintes fontes de dados:

  • Tabelas externas.
  • Visualizações de esquema de informações.
  • Tabelas curinga.
  • Dados de upsert de captura de dados alterados (CDC).
  • Visualizações materializadas.
  • Visualizações em que a consulta SQL subjacente usa recursos não compatíveis, como funções definidas pelo usuário, tabelas externas ou tabelas com CDC ativada.

• As consultas contínuas não são compatíveis com os recursos de segurança column- e no nível da linha.

• A saída de uma consulta contínua está sujeita às cotas e aos limites inerentes do serviço de destino para o qual a saída está sendo exportada.

• Ao exportar dados para o Bigtable, o Spanner ou os endpoints de local do Pub/Sub, só é possível segmentar recursos do Bigtable, do Spanner ou do Pub/Sub que estejam no mesmo limite regional do Google Cloud que o conjunto de dados do BigQuery que contém a tabela que você está consultando. Essa restrição não se aplica ao exportar dados para endpoints globais do Pub/Sub. Para mais informações sobre como exportar para uma política de roteamento de perfil de aplicativo do Bigtable, consulte Considerações de localização.

• Não é possível executar uma consulta contínua em uma tela de dados.

• Não é possível modificar o SQL usado em uma consulta contínua enquanto o job da consulta contínua está em execução. Para mais informações, consulte Modificar o SQL de uma consulta contínua.

• Se um job de consulta contínua ficar atrasado no processamento de dados recebidos e tiver uma atraso na marca d'água de saída de mais de 48 horas, ele vai falhar. É possível executar a consulta novamente e usar a função do histórico de alterações APPENDS ou CHANGES para retomar o processamento a partir do momento em que você interrompeu o job de consulta contínua anterior. Para mais informações, consulte Iniciar uma consulta contínua de um momento específico.

• Uma consulta contínua configurada com uma conta de usuário pode ser executada por até dois dias. Uma consulta contínua configurada com uma conta de serviço pode ser executada por até 150 dias. Quando o tempo máximo de execução da consulta é atingido, ela falha e para de processar os dados recebidos.

• Embora as consultas contínuas sejam criadas usando os recursos de confiabilidade do BigQuery, podem ocorrer problemas temporários ocasionais. Problemas podem levar a um reprocessamento automático da consulta contínua, o que pode resultar em dados duplicados na saída da consulta contínua. Projete seus sistemas downstream para lidar com esses cenários.

Limitações de reserva

• Você precisa criar uma reserva da edição Enterprise ou Enterprise Plus com um tipo de atribuição CONTINUOUS para executar consultas contínuas. As consultas contínuas não aceitam o modelo de faturamento de computação on demand.
• Quando você cria uma atribuição de reserva de CONTINUOUS, a reserva associada é limitada a no máximo 500 slots. Para solicitar um aumento desse limite, entre em contato com [e-mail].
• Não é possível criar uma atribuição de reserva que usa um tipo de trabalho diferente na mesma reserva como uma atribuição de reserva de consulta contínua.

• O BigQuery determina o número de consultas contínuas que podem ser executadas simultaneamente por projeto com base no tamanho configurado da atribuição de reserva que usa o tipo de serviço CONTINUOUS. Para aceitar novos jobs, o BigQuery exige um limite de 10 slots por job de consulta contínua. A consulta não consome necessariamente todos os 10 slots durante a execução normal. Esse limite garante que cada consulta contínua em execução mantenha capacidade de computação de referência suficiente para lidar com picos repentinos no volume de dados recebidos sem atrasos ou comprometimento do processamento de baixa latência.

  Para garantir que suas consultas sejam aceitas sem atingir os limites de simultaneidade, recomendamos o uso do escalonamento automático de slots. Com o escalonamento automático, o uso geral de slots será escalonado dinamicamente com base na demanda real de recursos. É possível configurar uma reserva de valor de referência menor e definir um limite máximo de escalonamento automático que cubra confortavelmente o limite de 10 slots por consulta para as consultas simultâneas esperadas.

• Ao executar várias consultas contínuas usando a mesma reserva, jobs individuais podem não dividir os recursos disponíveis de maneira justa, já que são definidos pela imparcialidade do BigQuery.

Escalonamento automático de slots

As consultas contínuas podem usar o escalonamento automático de slots para escalonar dinamicamente a capacidade alocada para acomodar sua carga de trabalho. À medida que a carga de trabalho das consultas contínuas aumenta ou diminui, o BigQuery ajusta dinamicamente os slots.

Depois que uma consulta contínua começa a ser executada, ela escuta ativamente os dados recebidos, o que consome recursos de slot. Embora uma reserva com uma consulta contínua em execução não reduzir escala vertical para zero slots, uma consulta contínua inativa que está principalmente detectando dados recebidos deve consumir uma quantidade mínima de slots, normalmente cerca de 1 slot.

Compartilhamento de slots inativos

As consultas contínuas podem usar o compartilhamento de slots inativos para compartilhar recursos de slots não utilizados com outras reservas e tipos de serviço.

• Uma atribuição de reserva de CONTINUOUS ainda é necessária para executar uma consulta contínua e não pode depender apenas de slots inativos de outras reservas. Portanto, uma atribuição de reserva CONTINUOUS requer um valor de referência de slot diferente de zero ou uma configuração de escalonamento automático de slot diferente de zero.
• Somente slots de valor de referência ociosos ou slots confirmados de uma atribuição de reserva CONTINUOUS podem ser compartilhados. Os slots com escalonamento automático não podem ser compartilhados como slots inativos para outras reservas.

Preços

As consultas contínuas podem usar o escalonamento fluido do BigQuery.

As consultas contínuas usam Preços de computação de capacidade do BigQuery, que são medidos em slots. Para executar consultas contínuas, é preciso ter uma reserva que use a edição Enterprise ou Enterprise Plus e uma atribuição de reserva que usa o tipo de job CONTINUOUS.

O uso de outros recursos do BigQuery, como ingestão de dados e armazenamento, é cobrado conforme as taxas mostradas nos Preços do BigQuery.

O uso de outros serviços que recebem resultados de consulta contínua ou que são chamados durante o processamento de consultas é cobrado de acordo com as taxas publicadas para esses serviços. Para os preços de outros serviços do Google Cloud usados pelas consultas contínuas, consulte os seguintes tópicos:

• Preços do Bigtable
• Preços do Pub/Sub
• Preços do Spanner
• Preços da Agent Platform

Como estimar os requisitos de capacidade de slot

Como cada carga de trabalho é diferente, geralmente não é possível fazer uma estimativa exata de slots para consultas contínuas com antecedência. A quantidade de slots exigida pelas consultas contínuas depende de uma combinação de vários fatores:

• O número de consultas contínuas em execução simultânea.
• A complexidade da instrução SQL.
• O uso de funções de processamento com estado, incluindo durações de janela, JOINs e agregações.
• A taxa ou velocidade dos dados recebidos.
• A estrutura e o tamanho dos dados que estão sendo ingeridos.

Conceitualmente, é possível estimar o requisito total de slots como uma função da carga de trabalho de consulta contínua:

Slots estimados ≈ Número de consultas contínuas x ∑ (Taxa de dados x Complexidade da consulta)

Como o consumo real de slots depende muito da sua carga de trabalho e dos padrões de dados, o método mais preciso para estimar o custo é monitorar um job em execução. É possível medir o pico de uso de slots de uma execução de consulta contínua isolada usando as visualizações INFORMATION_SCHEMA. Para instruções detalhadas e consultas de exemplo para acompanhar o uso de slots ao longo do tempo, consulte Ver informações de consumo de slots.

A seguir

Tente criar uma consulta contínua.