Voltar
Migração do BigQuery para ClickHouse gera economia de 6x e melhora disponibilidade de dados

Bolna migra do BigQuery para ClickHouse, reduzindo custos em 6x e otimizando disponibilidade de dados

Aprofundamento CEVIU

Aprofundamento

A migração da Bolna do BigQuery para o ClickHouse, que resultou em uma redução de 6 vezes nos custos e melhoria expressiva na disponibilidade de dados, mostra como decisões arquiteturais impactam diretamente a engenharia de plataformas. O problema inicial era duplo: custos crescentes no BigQuery, impulsionados por operações de MERGE que varriam tabelas não particionadas para pequenas atualizações, e uma latência de 5 a 15 minutos na entrega dos dados analíticos.

A solução envolveu a realocação da pipeline de dados para PostgreSQL, ClickPipes (baseado em PeerDB) e ClickHouse Cloud. Técnicas como o uso de ReplacingMergeTree no ClickHouse ajudaram na deduplicação. Desafios específicos foram superados: queries diretas com FINAL causavam picos de memória, resolvidos com views materializadas e perfis de usuário com limites de recursos. Para dados JSONB TOASTed ausentes ou antigos, a Bolna configurou REPLICA IDENTITY FULL no PostgreSQL, garantindo que o WAL incluísse a linha completa. A maior economia, porém, veio da camada de aplicação, ao reduzir o volume de CDC (Change Data Capture), escrevendo apenas o estado final das chamadas, não cada atualização intermediária. Essa abordagem evidencia a importância de otimizar a fonte de dados para um pipeline eficiente.

Por que isso importa

Para engenheiros de plataforma e equipes de DevOps, o caso da Bolna sublinha a necessidade de uma visão holística da stack de dados. Otimizar custos não se resume a trocar um banco de dados por outro; é preciso entender os padrões de acesso e escrita da aplicação. A experiência da Bolna mostra que ajustar a forma como a aplicação interage com o banco de dados (escrevendo apenas o estado final) pode ser mais impactante que a otimização de infraestrutura isoladamente.

A resolução do problema de dados TOASTed JSONB com REPLICA IDENTITY FULL no PostgreSQL é um aprendizado valioso sobre os detalhes da replicação lógica e o gerenciamento de dados complexos. Além da economia, a redução da latência de dados para 1 a 2 minutos representa um ganho operacional crucial, permitindo depuração em tempo real e tomadas de decisão mais rápidas. Isso afeta diretamente a experiência do cliente e a agilidade do negócio.

Linha do tempo

  1. Bolna migra do BigQuery para ClickHouse, reduzindo custos em 6x e otimizando disponibilidade de dados

Perguntas frequentes

Por que o BigQuery se tornou problemático para a Bolna?

O BigQuery se tornou caro e lento para a Bolna devido ao grande volume de dados e ao padrão de uso. Operações de MERGE em uma tabela grande e não particionada, frequentemente atualizada, resultavam em varreduras completas da tabela, elevando os custos de computação. Além disso, a latência de 5 a 15 minutos na disponibilização dos dados de chamadas gerava problemas operacionais e insatisfação.

O que é REPLICA IDENTITY FULL e como ajudou a Bolna?

REPLICA IDENTITY FULL é uma configuração do PostgreSQL que força o envio da linha completa antiga no WAL (Write-Ahead Log) durante atualizações e exclusões. A Bolna usou essa configuração para resolver o problema de dados JSONB TOASTed ausentes ou antigos no ClickHouse. Isso garantia que colunas de grande volume, armazenadas fora da linha principal, fossem sempre replicadas corretamente.

Como a Bolna reduziu o volume de CDC e qual foi o impacto?

A Bolna reduziu o volume de CDC alterando a lógica da aplicação. Em vez de registrar cada mudança de status de uma chamada como uma atualização no PostgreSQL, a aplicação passou a escrever apenas o estado final da chamada. Essa mudança foi a maior responsável pela redução de custos em 6 vezes, diminuindo o volume de dados a serem replicados e a carga sobre os sistemas.

Qual foi a principal melhoria de performance após a migração para ClickHouse?

A principal melhoria foi a drástica redução na latência de dados. Antes, os dados de chamadas levavam de 5 a 15 minutos para estarem disponíveis para análise após o término da ligação. Com a nova arquitetura, essa latência caiu para apenas 1 a 2 minutos, permitindo que os clientes e equipes internas acessem informações críticas quase em tempo real e rodem métricas personalizadas sob demanda.

Fontes

Avalie este artigo:
Categoria
CEVIU DevOps
Publicado
30 de setembro de 2026
Editoria
CEVIU DevOps

Quer receber mais sobre CEVIU DevOps?

Conteúdo curado diariamente, direto no seu e-mail.

Conteúdo curado diariamenteDiversas categoriasCancele quando quiser