A otimização de custos no BigQuery começa por um fato incômodo: no modelo sob demanda, você paga por cada byte que a query lê, não pela resposta que ela devolve. Segundo a documentação oficial de preços do BigQuery, a análise sob demanda custa USD 6,25 por TiB processado, com o primeiro 1 TiB de cada mês gratuito e um mínimo de 10 MB por consulta. Uma única query sem filtro sobre uma tabela grande consome essa cota gratuita em segundos, e é por isso que times rodando Google BigQuery em escala veem a fatura crescer mais rápido do que os próprios dados.
A maior parte das contas fora de controle não tem a ver com excesso de usuários. Ela vem de um design de tabela que obriga o BigQuery a ler muito mais do que a consulta precisa. O mesmo dashboard que atualiza a cada dez minutos pode custar centavos ou centenas de dólares por mês, dependendo só de como as tabelas por trás estão organizadas, um padrão comum quando o dashboard é construído antes do modelo de dados estar pronto.
Este guia percorre as três alavancas que mais mexem na fatura do BigQuery: particionamento, clustering e BI Engine. Juntas, elas atacam o problema pelas duas pontas, reduzindo os bytes que cada query lê e cacheando os dados que os dashboards acessam repetidamente. A escolha da plataforma em si é outra discussão, que tratamos ao comparar BigQuery, Redshift e Snowflake.
Por que o custo do BigQuery escala: o modelo de bytes lidos
O BigQuery sob demanda cobra por dados processados, então o custo de uma query é função de quanto da tabela ela precisa abrir. Consulte um dia dentro de três anos de histórico e, sem o design correto, o BigQuery ainda lê os três anos inteiros. Essa é a ineficiência central por trás da maioria das faturas surpresa, e é a razão pela qual decisões de engenharia de dados tomadas na criação da tabela ecoam em todo custo posterior.
A saída é dar ao BigQuery uma forma de pular os dados de que ele não precisa. Duas técnicas de layout físico fazem exatamente isso, e um terceiro serviço cacheia os dados quentes para que leituras repetidas parem de tocar o armazenamento. Escolher bem aqui é a mesma disciplina que separa um data warehouse enxuto de um caro.
Como implementar o particionamento para podar dados
O particionamento divide a tabela em segmentos que o BigQuery consegue ler ou pular de forma independente. Quando a query filtra pela coluna de particionamento, o motor descarta toda partição fora do filtro e nunca a lê, o que é a maior alavanca isolada para cargas de série temporal, comuns em qualquer pipeline de ingestão de dados.
Conforme a documentação de tabelas particionadas do Google, o BigQuery oferece três abordagens. O particionamento por coluna de tempo divide por uma coluna DATE, TIMESTAMP ou DATETIME, com granularidade por hora, dia, mês ou ano. O particionamento por tempo de ingestão atribui as linhas automaticamente pela hora de carga. E o particionamento por faixa de inteiros agrupa linhas por intervalos de uma coluna INTEGER. Qual usar depende de como as queries filtram a tabela, uma decisão de modelagem que se encaixa numa prática madura de engenharia de dados.
Duas cotas importam na prática. Uma tabela suporta até 10.000 partições, valor elevado a partir do teto anterior de 4.000, o que cobre mais de 27 anos de partições diárias. Já um único job de carga ou consulta toca no máximo 4.000 partições por vez, então backfills em massa precisam ser feitos em lotes. Ao se aproximar do limite da tabela, torne a granularidade mais grossa, por exemplo migrando de partições diárias para mensais, um trade-off que vale planejar junto à sua estratégia de warehouse.
A proteção mais eficaz é exigir um filtro de partição na tabela. Essa configuração rejeita qualquer query que omita a coluna de particionamento, de modo que ninguém dispara sem querer uma varredura de todo o histórico. É uma regra pequena de governança que se paga sozinha, no mesmo espírito das checagens que mantêm uma operação de dados previsível dentro de uma boa estratégia multicloud.
Como implementar o clustering para pular blocos
O clustering ordena os dados dentro de cada partição por até quatro colunas que você escolhe. O BigQuery guarda esses dados ordenados em blocos e registra a faixa de valores de cada bloco, então uma query que filtra por uma coluna de cluster lê apenas os blocos que podem conter correspondências. Ele atua dentro das partições, e é por isso que as duas técnicas se somam tão bem, uma combinação familiar a quem já enfrentou o erro mais comum em projetos de dados.
O clustering não tem limite de cardinalidade, então colunas de alta cardinalidade como user_id, product_sku ou order_id são chaves de cluster ideais, o oposto do que o particionamento resolve bem. A ordem também conta: liste as colunas de cluster da mais filtrada para a menos filtrada, porque a poda de blocos é mais eficaz na coluna inicial. São esses detalhes que transformam uma configuração genérica de data warehouse em uma enxuta.
As duas alavancas respondem perguntas diferentes, e a tabela abaixo mapeia quando cada uma se encaixa, um raciocínio próximo ao que usamos ao implementar Business Intelligence com sucesso.
| Dimensão | Particionamento | Clustering |
|---|---|---|
| O que faz | Pula partições inteiras | Pula blocos ordenados dentro das partições |
| Melhor tipo de coluna | Data ou inteiro de baixa cardinalidade | Alta cardinalidade (user_id, sku) |
| Número de colunas | Uma chave de particionamento | Até quatro colunas |
| Limite rígido | 10.000 partições por tabela | Sem limite de cardinalidade |
| Estimativa de custo antes de rodar | Bytes exatos | Estimativa é um teto |
Uma ressalva: com clustering, a estimativa de bytes processados que o BigQuery mostra antes de rodar é um teto, já que a poda de blocos acontece na execução. O particionamento, por outro lado, dá uma estimativa exata de antemão, uma diferença útil na hora de projetar gastos ao longo de um pipeline de dados inteiro.
Como o BI Engine acelera dashboards e reduz o custo de leitura
Particionamento e clustering encolhem cada varredura, enquanto o BI Engine ataca a outra metade do problema: as mesmas queries rodando repetidamente. O BI Engine é um serviço de análise em memória que cacheia os dados mais usados e processa estágios de query compatíveis com um motor vetorizado. Quando um estágio é servido pelo cache do BI Engine, ele lê zero byte do armazenamento, então a parte de leitura daquela query não gera cobrança sob demanda, um ganho real para as cargas repetitivas por trás de boa parte dos relatórios de Business Intelligence.
Você o habilita criando uma reserva em uma região e definindo o tamanho dela, cobrada por GB de memória por hora até o máximo atual de 250 GiB, segundo a documentação do BI Engine do Google. Looker Studio, Looker e qualquer ferramenta sobre a API do BigQuery herdam a aceleração de forma transparente quando existe uma reserva no mesmo projeto e região, sem reescrever query, o que faz dele um encaixe natural na discussão de qual ferramenta de BI escolher.
O BI Engine se encaixa em dashboards com alta frequência de atualização e conjuntos quentes e previsíveis, onde uma reserva pequena compensa um grande volume de varreduras repetidas. Ele é menos útil para exploração ad-hoc sobre dados frios, então o movimento inteligente é dimensionar a reserva contra o uso real em vez de chutar, a mesma abordagem medida que mantém uma arquitetura eficiente conforme a operação cresce, algo central em qualquer projeto de engenharia de dados.
As três alavancas se compõem: particione para podar o histórico, faça clustering para pular blocos dentro do dia que você manteve, e reserve capacidade de BI Engine para os dashboards que batem nessas tabelas o dia todo. Nenhuma delas é bala de prata sozinha, e a mistura certa depende dos seus padrões de query, da sua cadência de atualização e de quanto do gasto vem de dashboards versus exploração. Na BIX Tecnologia trabalhamos com múltiplas soluções de dados, nuvem e engenharia, então o objetivo é sempre a arquitetura que serve à sua carga, não um template, uma postura que aplicamos seja a plataforma BigQuery ou Snowflake.
Se a sua empresa está vendo o custo do BigQuery subir e quer um design de tabela e uma estratégia de BI Engine que se sustentem em produção, nossos especialistas podem ajudar a estruturar a melhor arquitetura para o seu contexto. Fale com a nossa equipe e transforme controle de custo em decisão de arquitetura, não em surpresa no fim do mês. ⬇️
O que é otimização de custos no BigQuery? É a prática de reduzir o que você paga em queries e armazenamento cortando os bytes que cada consulta lê. No modelo sob demanda, o Google cobra USD 6,25 por TiB processado após uma cota mensal gratuita de 1 TiB, então as principais alavancas são particionamento, clustering e BI Engine, que podam dados e cacheiam leituras quentes.
Qual a diferença entre particionamento e clustering no BigQuery? O particionamento divide a tabela em segmentos (em geral por data) que o BigQuery pula quando a query filtra pela coluna de partição, e uma tabela permite até 10.000 partições. O clustering ordena os dados dentro de cada partição por até quatro colunas e descarta blocos que não podem casar. Particionamento serve para colunas de data de baixa cardinalidade; clustering serve para colunas de alta cardinalidade como user_id, e os dois funcionam melhor juntos.
Como o BI Engine reduz o custo do BigQuery? O BI Engine é um cache em memória que serve estágios de query compatíveis sem ler o armazenamento, então esses estágios não geram cobrança de varredura sob demanda. Você paga por GB de memória reservada por hora. Ele é mais econômico para dashboards com atualizações frequentes sobre dados quentes, e acelera Looker Studio e Looker de forma transparente quando há uma reserva no mesmo projeto e região.
Preciso sempre usar particionamento e clustering juntos? Nem sempre, depende dos padrões de query. Use particionamento quando as consultas filtram por data ou por um inteiro de baixa cardinalidade, e acrescente clustering quando elas também filtram por colunas de alta cardinalidade dentro dessas partições. Para tabelas pequenas, abaixo de cerca de 1 GB, o overhead pode superar a economia, então a escolha é situacional, não automática.
Como estimar o custo de uma query no BigQuery antes de rodar? O BigQuery mostra os bytes que a query vai processar no validador de consultas antes de executá-la, e você multiplica esse valor pela tarifa sob demanda de USD 6,25 por TiB. A estimativa é exata para tabelas particionadas e um teto para tabelas com clustering, já que a poda de blocos é resolvida na execução.
