Otimizar jobs de carregamento

As estratégias e práticas recomendadas descritas neste documento ajudam a otimizar o carregamento em lote ou o streaming de dados no BigQuery para evitar atingir o limite do número de jobs de carregamento por tabela e por dia.

Como o limite para jobs de carregamento é fixo e não pode ser aumentado, otimize seus jobs estruturando as tabelas com métodos como partições de tabela ou gerenciando os carregamentos com métodos como carregamento em lote ou streaming.

Como funcionam as cotas de operações de tabela

O limite do BigQuery para modificações por tabela por dia por projeto é fixo, independente de as modificações anexarem ou atualizarem dados, ou truncarem a tabela. Esse limite inclui o total combinado de todos os jobs de carregamento, jobs de cópia e jobs de consulta que adicionam ou substituem uma tabela de destino.

Os jobs de carregamento têm uma taxa de reposição. Se você exceder o limite de operações de tabela ou a taxa de recarga, os jobs de carregamento vão falhar com um erro quotaExceeded. O limite no nível do projeto para jobs de carregamento por dia é reabastecido em um período de 24 horas. Quando os jobs de carregamento terminam, a cota disponível diminui. A cota é recarregada gradualmente nas próximas 24 horas. Os jobs de carregamento com falha ainda contam para as cotas por tabela e por projeto. Para mais informações sobre os limites de jobs de carregamento, consulte Jobs de carregamento.

Para tabelas particionadas, um limite separado para tabela particionada particionadas é aplicado, substituindo o limite padrão de tabelas.

Para não ultrapassar os limites diários de operações de tabela, distribua as operações em um período de 24 horas. Por exemplo, se você fizer 25 atualizações, cada uma com 60 operações, será possível executar cerca de 60 operações a cada 58 minutos. Essa abordagem ajuda você a atingir o limite diário. Para monitorar atualizações de tabelas, consulte Visualizações do BigQuery INFORMATION_SCHEMA.

Operações de tabela excluídas da cota

A atualização das informações da tabela (metadados) e o uso de instruções DML não são contabilizados no limite diário de modificação de tabelas. Essa exclusão se aplica a tabelas padrão e particionadas.

Seu projeto pode executar um número ilimitado de instruções DML. Embora as instruções DML fossem contabilizadas nas modificações diárias de tabela e não fossem limitadas, mesmo no limite, isso não acontece mais.

As inserções de streaming também modificam tabelas, mas são regidas por cotas específicas.

Estratégias de carregamento para evitar o limite de operações de tabela

Para não exceder o limite diário de operações de tabela do BigQuery, siga estas práticas recomendadas:

• Faça menos gravações, mas maiores, em vez de muitas pequenas.
• Minimize os jobs de gravação separados na tabela de produção final todos os dias.

Para usar essas práticas recomendadas, faça o carregamento em lote ou por streaming dos dados no BigQuery. A escolha do método de carregamento depende se você precisa carregar grandes volumes de dados em tempo real ou se isso não é uma preocupação. As seções a seguir explicam o carregamento em lote e o streaming de dados em detalhes, incluindo as ferramentas e os serviços que podem ser usados para cada método.

Carregamento em lote

Para não exceder o limite diário de carregamento por projeto do BigQuery, agrupe grandes quantidades de dados e carregue-os com menos jobs no BigQuery. As seções a seguir descrevem vários métodos que você pode usar para carregar dados em lote.

Carregar mais dados para cada job

Em vez de enviar dados para o BigQuery sempre que novas informações ficam disponíveis, colete e carregue tudo usando um único job grande.

Por exemplo, em vez de executar um job de carregamento separado para cada poucas linhas de dados, espere até acumular vários milhares de linhas em um arquivo (por exemplo, CSV ou JSON) e execute um job de carregamento para anexar todos os dados a uma tabela. Essa ação conta como uma operação de tabela, mesmo que o job contenha muito mais dados. É possível agrupar seus arquivos usando caracteres curinga com seu job de carregamento. Com os caracteres curinga, é possível selecionar lotes de arquivos em um diretório para carregar vários arquivos em um único job de carregamento.

O exemplo a seguir mostra como usar caracteres curinga com o comando bq load ou consultas SQL LOAD DATA.

bq load \
  --source_format=CSV \
  --autodetect \
  --project_id=PROJECT_ID \
  DATASET_NAME.TABLE_NAME \
  "gs://BUCKET_NAME/OBJECT_PATH_WILDCARD"

LOAD DATA INTO
DATASET_NAME.TABLE_NAME
FROM FILES (
  format = 'SOURCE_FORMAT',
  uris = ['gs://BUCKET_NAME/OBJECT_PATH_WILDCARD]
  );

Carregamento em lote usando a API BigQuery Storage Write

Para carregar dados em lote no BigQuery, uma opção é usar a API Storage Write diretamente do seu aplicativo com as bibliotecas de cliente da API Google.

A API Storage Write otimiza o carregamento de dados para ficar dentro dos limites da tabela. Para streaming em tempo real de alto volume, use um fluxo PENDING em vez de um fluxo COMMITTED. Quando você usa um stream PENDING, a API armazena temporariamente registros até que você confirme o stream.

Para um exemplo completo de carregamento de dados em lote usando a API Storage Write, consulte Carregar dados em lote usando a API StorageWrite.

Carregamento em lote usando o Dataflow

Se você quiser transmitir, transformar e gravar dados no BigQuery usando pipelines de dados, use o Dataflow. Os pipelines de dados que você cria leem de fontes compatíveis, como Pub/Sub ou Apache Kafka. Também é possível criar um pipeline do Dataflow usando o conector BigQueryIO, que usa a API Storage Write para streaming de dados de alta performance e semântica de execução única.

Para informações sobre como usar o Dataflow para carregar dados em lote no BigQuery, consulte Gravar do Dataflow no BigQuery.

Streaming de dados

Para carregar grandes volumes de dados com atualizações frequentes, recomendamos fazer streaming dos dados no BigQuery. Com o streaming de dados, novos dados são gravados continuamente do aplicativo cliente no BigQuery, uma estratégia que evita atingir o limite de execução de muitos jobs de carregamento. As seções a seguir descrevem vários métodos para transmitir dados para o BigQuery.

Transmitir dados usando a API StorageWrite

Use a API Storage Write para fazer streaming de registros em tempo real para o BigQuery com latência mínima. A API Storage Write oferece um protocolo de streaming eficiente com funcionalidades avançadas, como semântica de entrega exatamente uma vez, detecção de atualização de esquema e upserts de captura de dados de alteração (CDC) de streaming. Além disso, é possível ingerir até 2 TiB por mês sem custos financeiros.

Para informações sobre como usar a API Storage Write, consulte Como fazer streaming de dados usando a API Storage Write.

Transmitir dados usando o Dataflow

Use o Dataflow para criar pipelines de dados que leem de fontes compatíveis, como Pub/Sub ou Apache Kafka. Em seguida, esses pipelines transformam e gravam os dados no BigQuery como destino. É possível criar um pipeline do Dataflow usando o conector BigQueryIO, que usa a API Storage Write.

Para informações sobre como usar o Dataflow para transmitir dados para o BigQuery, consulte Gravar do Dataflow para o BigQuery.

Práticas recomendadas para gerenciar suas tabelas para carregamento

Além de carregar em lote ou transmitir dados para o BigQuery, gerencie suas tabelas das seguintes maneiras para otimizá-las para ingestão de dados.

Usar tabelas particionadas

O particionamento de tabelas é uma técnica eficiente para gerenciar tabelas grandes no BigQuery, principalmente quando você precisa realizar operações frequentes de carregamento de dados. É possível melhorar significativamente o desempenho e o custo-benefício da tabela dividindo-a em segmentos menores e mais fáceis de gerenciar com base em uma data, um carimbo de data/hora ou um número inteiro.

A principal vantagem do particionamento para carregamento de dados é que as cotas diárias de operações de tabela do BigQuery se aplicam no nível da partição, e não da tabela. Para tabelas particionadas, um limite separado e mais alto se aplica a modificações de partição, que substituem o limite de tabela padrão. O limite para tabelas particionadas aumenta muito o número de jobs de carregamento que podem ser executados por dia sem atingir os limites de cota.

Uma estratégia comum e altamente eficaz é o carregamento em lote dos seus dados diários. Por exemplo, é possível reunir todos os dados do dia para 2025-09-18 em uma tabela de preparação temporária. Depois, no fim do dia, você executa um único job para carregar esses dados na partição específica desse dia na tabela de produção principal. Como o BigQuery interage apenas com os dados de uma única partição, essa abordagem mantém os dados bem organizados e torna as operações de carregamento mais rápidas e baratas.

Embora o particionamento seja altamente recomendado para tabelas grandes e em crescimento, é melhor evitá-lo se as partições forem consistentemente menores que 10 GB. Para mais informações, consulte Quando usar o particionamento.

Para saber mais sobre os diferentes métodos de particionamento disponíveis, como particionamento por unidade de tempo e por intervalo de números inteiros, consulte Tipos de tabelas particionadas.

Aproveitar a espera exponencial, o truncamento e a instabilidade integrados

O backoff exponencial e a nova tentativa integrados são um método de tratamento de erros que ajuda seu aplicativo a se recuperar sem problemas quando uma operação falha temporariamente. Essas falhas podem incluir um erro de limitação de taxa (rateLimitExceeded) ou um breve problema de rede (unavailable).

Em um sistema confiável, os workers que recebem tarefas da fila do lado do cliente também usam espera exponencial e nova tentativa. Isso acontece ao chamar o BigQuery, o que cria dois níveis de proteção.

Por exemplo, a biblioteca oficial google-cloud-bigquery-storage para Python inclui lógica de repetição integrada com espera exponencial. Essa lógica processa erros temporários do gRPC, por exemplo, UNAVAILABLE. Na maioria dos casos, não é necessário escrever esse código de nova tentativa. A chamada client.append_rows() processa essas novas tentativas automaticamente.

Esse processamento integrado é um benefício significativo do uso das bibliotecas de cliente oficiais. Você só precisa lidar com erros que não podem ser repetidos, por exemplo, INVALID_ARGUMENT, o que significa que há uma incompatibilidade de esquema.