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 por dia.

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

Como funcionam as cotas de operações de tabela

O limite do BigQuery para modificações de tabela por tabela por dia por projeto é fixo, independentemente 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 recarga. Se você exceder o limite de operação da tabela ou a taxa de recarga, os jobs de carregamento vão falhar com um erro quotaExceeded. O limite de jobs de carregamento por dia para envolvidos no projeto é recarregado 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 são contabilizados nas 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 modificações de tabela particionada é aplicado, substituindo o limite de tabela padrão.

Para ficar dentro dos limites diários de operação de tabela, distribua as operações por um período de 24 horas. Por exemplo, se você realizar 25 atualizações, cada uma com 60 operações, poderá executar cerca de 60 operações a cada 58 minutos. Essa abordagem ajuda você a atender ao limite diário. Para monitorar as atualizações de tabela, consulte as visualizações 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 da tabela. 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 tenham sido contabilizadas anteriormente para modificações diárias de tabela e não tenham sido limitadas, mesmo no limite, elas não são 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 ficar dentro do limite diário de operação de tabela do BigQuery, considere estas práticas recomendadas:

  • Realize menos gravações 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 lote ou o 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 o carregamento em tempo real 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 ficar dentro do limite de carregamento diário por projeto do BigQuery, faça o lote de grandes quantidades de dados e carregue-os com menos jobs no BigQuery. As seções a seguir descrevem vários métodos que podem ser usados para carregar dados em lote.

Carregar mais dados para cada job

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

Por exemplo, em vez de executar um job de carregamento separado para cada linha de dados, você pode esperar até acumular várias milhares de linhas de dados em um arquivo, por exemplo, em um arquivo CSV ou JSON, e executar 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 fazer o lote dos arquivos usando curingas com o job de carregamento. Os curingas permitem 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 curingas com o comando bq load ou consultas SQL LOAD DATA.

bq

O exemplo a seguir mostra um bq load comando para carregar dados CSV do Cloud Storage em uma tabela do BigQuery chamada my_target_table. Para selecionar mais de um nome de arquivo de origem, use um curinga com o comando. A flag AUTODETECT determina automaticamente o esquema da tabela com base nos dados de origem no Cloud Storage e pode oferecer suporte a um curinga (*) para carregar vários arquivos que se ajustam a um padrão de nomenclatura específico na tabela do BigQuery.

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

Substitua:

  • PROJECT_ID: o ID do Google Cloud projeto.
  • DATASET_NAME: o nome do conjunto de dados do BigQuery em que você quer carregar os dados.
  • TABLE_NAME: o nome da tabela do BigQuery em que você quer carregar os dados.
  • BUCKET_NAME: o nome do bucket do Cloud Storage que contém os arquivos de origem.
  • OBJECT_PATH_WILDCARD: o caminho para os arquivos CSV no bucket do Cloud Storage. Inclua um curinga (*) para corresponder a vários arquivos. Por exemplo, a string gs://my-bucket/path/to/data/my_prefix_*.csv usa o caractere curinga * para carregar todos os arquivos em gs://my-bucket/path/to/data/ que começam com my_prefix_ e terminam com .csv.

Para ver mais informações, consulte os seguintes tópicos:

SQL

O exemplo a seguir mostra como usar a consulta SQL LOAD DATA query para carregar dados CSV de um bucket do Cloud Storage na tabela do BigQuery. Para selecionar mais de um nome de arquivo de origem, use um curinga com o comando.

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

Substitua:

  • DATASET_NAME: o nome do conjunto de dados do BigQuery em que você quer carregar os dados.
  • TABLE_NAME: o nome da tabela do BigQuery em que você quer carregar os dados.
  • O SOURCE_FORMAT define o tipo de arquivos de origem, por exemplo, CSV ou JSON. Neste exemplo, use CSV.
  • BUCKET_NAME: o nome do bucket do Cloud Storage que contém os arquivos de origem.
  • OBJECT_PATH_WILDCARD: o caminho para os arquivos CSV no bucket do Cloud Storage. Inclua um curinga (*) para corresponder a vários arquivos. Por exemplo, a string gs://my-bucket/path/to/data/my_prefix_*.csv usa o caractere curinga * para carregar todos os arquivos em gs://my-bucket/path/to/data/ que começam com my_prefix_ e terminam com .csv.

Para mais informações, consulte Instruções de carregamento no GoogleSQL.

Carregar 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 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 stream PENDING, em vez de um stream COMMITTED. Quando você usa um stream PENDING, a API armazena temporariamente os 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 Storage Write.

Carregar 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 criados leem de fontes compatíveis, como o Pub/Sub ou o 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 "exatamente uma vez".

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 que você faça o 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 no BigQuery.

Transmitir dados usando a API Storage Write

Use a API Storage Write para transmitir registros em tempo real para o BigQuery com latência mínima. A API Storage Write fornece um protocolo de streaming eficiente que oferece funcionalidades avançadas, como semântica de entrega "exatamente uma vez", detecção de atualização de esquema e upserts de captura de dados alterados (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 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, por exemplo, Pub/Sub ou Apache Kafka. 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 no BigQuery.

Práticas recomendadas para gerenciar tabelas para carregamento

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

Usar tabelas particionadas

O particionamento de tabelas é uma técnica poderosa para gerenciar tabelas grandes no BigQuery, especialmente quando você precisa realizar operações de carregamento de dados frequentes. É possível melhorar significativamente a performance e a relação custo-benefício da tabela dividindo-a em segmentos menores e mais gerenciáveis 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ção de tabela para o BigQuery são aplicadas no nível da partição, e não no nível da tabela. Para tabelas particionadas, um limite separado e maior é aplicado às modificações de partição, que substitui 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 é carregar em lote os dados diários. Por exemplo, é possível reunir todos os dados do dia 2025-09-18 em uma tabela de preparação temporária. Em seguida, no final do dia, execute 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 menos caras.

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 o particionamento de unidade de tempo e de intervalo de números inteiros, consulte Tipos de tabelas particionadas.

Aproveitar a espera exponencial, o truncamento e a instabilidade integrados

A espera exponencial e a nova tentativa integradas são um método de tratamento de erros que ajuda o aplicativo a se recuperar sem problemas quando uma operação falha temporariamente. Essas falhas podem incluir um erro de limite 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 a espera exponencial e a nova tentativa. Eles fazem isso 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 nova tentativa integrada com espera exponencial. Essa lógica processa erros gRPC temporários, 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 tratamento 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.