Use o ClickHouse para reduzir custos de BigQuery e Looker - Parte 1

Esta é uma série de vários artigos sobre o tema, dividida em partes lógicas para configurar esse processo. Como há muitas condições do tipo "if-then-else" envolvidas, devido à complexidade do ecossistema e da tecnologia, decidi separar o artigo em partes distintas para não sobrecarregar o conteúdo. A primeira parte traz a maior parte da teoria, e a segunda foca em uma implementação básica.

De cara, para quem ainda não conhece, o ClickHouse é um data warehouse concorrente do BigQuery. Seu grande diferencial é ser um datastore de altíssimo desempenho, capaz de executar operações bem mais rápido do que outros data warehouses do mercado. Isso o torna ideal para armazenar e servir dados a workloads que fazem consultas constantes, como ferramentas de BI do tipo Looker.

Este artigo foi escrito com a assistência técnica do nosso parceiro Aiven, líder em ofertas DBaaS, que orgulhosamente hospeda um serviço gerenciado de ClickHouse. Para deixar tudo completo, também incluí detalhes do ClickHouse, que oferece seu próprio serviço gerenciado.

O BigQuery é uma plataforma excelente para análises em larga escala ou workloads de ML e costuma ser conectado a ferramentas de BI como o Looker para visualização e geração de relatórios. Infelizmente, ao executar queries para esse tipo de trabalho, é comum esbarrar em problemas de desempenho por limitações de recursos ou por restrições de recursos motivadas pelo custo. E há ainda o gorila enorme (e às vezes irritado) na sala: o custo por query cobrado pelo BigQuery.

Além disso, depois dos recentes aumentos de preço por query, o BigQuery ficou mais caro, principalmente quando conectado a uma ferramenta que faz consultas constantes nos dados. Por isso, muitos clientes estão buscando formas de reduzir o custo dos seus workloads e descobrindo algo que os Customer Reliability Engineers da DoiT International já vêm pregando há anos: as ferramentas de BI são uma das maiores - se não a maior - fontes de custo no BigQuery e um dos principais alvos para otimização.

No Google Next 2023, na minha apresentação (a gravação foi removida, infelizmente, mas os slides continuam disponíveis), propus um tema sobre otimização de custos que vários clientes nossos já aplicaram com excelentes resultados: tirar do BigQuery certos workloads caros, em especial os intensivos em computação, e migrá-los para outras ferramentas mais baratas e mais adequadas ao propósito.

Em linha direta com essa ideia, proponho neste artigo um método alternativo de apresentação de dados, usando o data warehouse ClickHouse como uma camada de "cache e entrega" entre o BigQuery e ferramentas de BI, como o Looker. Ou seja, workloads de relatórios e visualização podem sair do BigQuery e ir para uma plataforma mais barata e com melhor desempenho.

Observação importante: estou usando o ClickHouse aqui, mas isso poderia ser feito tranquilamente com outras ferramentas e bancos de dados, conforme a necessidade. Estou usando o ClickHouse porque ele funciona muito bem para entregar dados rapidamente a ferramentas de visualização e vejo esse cenário com frequência suficiente para justificar este artigo.

Ultimamente, você deve ter visto bastante anúncio no LinkedIn ou em outros sites afirmando que o ClickHouse é mais barato ou mais rápido que o BigQuery. As mentes brilhantes por trás dessa campanha estão capitalizando justamente em cima dos fundamentos do conceito que proponho neste artigo. Nossos arquitetos de dados aqui na DoiT International têm visto em escala como as mudanças de preço estão afetando uma grande fatia dos clientes do GCP e, ao mesmo tempo, têm criado formas inovadoras de ajudá-los a economizar.

O ClickHouse é um data warehouse "na mesma linha" do BigQuery, mas com algumas mudanças arquiteturais importantes que diferenciam os dois. Ele é construído sobre uma arquitetura mais monolítica, centrada em "módulos" definidos pelo usuário, que aumentam muito o desempenho. Graças a essa infraestrutura modular, ele pode ser bem mais performático em diversas tarefas do que o BigQuery ou outras soluções de data warehousing do mercado.

Esta citação da PostHog resume bem:

"A diferença de desempenho entre o BigQuery e o ClickHouse pode ser imensa. O BigQuery pode levar dezenas de segundos para executar uma query. O ClickHouse, se bem ajustado, consegue executar a mesma query em terabytes de dados com desempenho abaixo de um segundo."

"Elementar, meu caro Watson, para economizar custos" - Sherlock Holmes (com um toque moderno para a nuvem)

A resposta é economia de custos! Bem, sendo mais realista: economia potencial de custos.

Isso acontece porque você está consultando um data warehouse que não cobra pelo uso de queries e tem uma taxa fixa, ou seja, dá para consultar tudo o que os recursos permitirem sem pagar por uso.

Neste artigo, vou usar a oferta de serviço gerenciado de ClickHouse da Aiven como referência de preços. Foi com esse serviço que testei tudo o que está descrito aqui, e eles tornaram muito simples conectar o ClickHouse, e suas outras ofertas, ao seu ambiente GCP.

Os planos business da Aiven começam em cerca de US$ 500/mês no nível startup e cerca de US$ 2.000/mês no nível business, dando os pontos de preço que vamos usar para mostrar se isso é viável ou não para o seu ambiente.

Existem alguns pontos de equilíbrio para que essa solução faça sentido do ponto de vista de custo.

Atenção: se você gasta menos de US$ 500/mês com BigQuery ou com sua ferramenta de visualização, há uma boa chance de isso não trazer redução de custos; por outro lado, há uma chance enorme de trazer melhorias consideráveis de desempenho.

Considerando os pontos de preço de US$ 500 e US$ 2.000 da Aiven, isso corresponde a 1 TiB e 321 TiB (320 TiB + 1 TiB do nível gratuito) de dados processados por mês no modelo de preços on-demand do BigQuery. Você também pode rodar esta query [1] no projeto que executa os jobs da sua ferramenta de BI.

Como referência comparativa, o ClickHouse oferece planos com componente de autoscaling e instâncias um pouco maiores por preços bem competitivos. Dependendo do dimensionamento e das necessidades de desenvolvimento/produção, pode ser uma alternativa mais barata.

Para o BigQuery Editions, não existe um valor direto que indique o ponto de equilíbrio, porque o Editions usa um autoscaler que é, na prática, uma escala variável de preços. O método mais fácil é rodar a query mencionada acima [1] no projeto onde o Looker faz queries, para calcular os custos aproximados do Looker.

Observação sobre essa query:

Talvez seja necessário ajustar a regex ou substituí-la totalmente pelo nome da sua service account do Looker para obter custos precisos, especialmente se você usa uma service account fora do padrão ou várias delas.

Depois de calcular esse valor, você consegue determinar se o preço está acima ou abaixo dos limites de US$ 500 e US$ 2.000 mencionados acima. Além disso, se desempenho for uma preocupação, pode valer o custo extra para não ter que esperar 20 segundos até um dashboard do Looker exibir dados em tempo real.

O plano aqui é "replicar" os dados entre o BigQuery e o ClickHouse e, em seguida, conectar qualquer ferramenta de BI com queries pesadas - ou qualquer outra ferramenta nessa pegada - ao ClickHouse. Em tese, isso elimina os custos por query associados ao BigQuery e reduz seus custos de forma significativa, já que você passa a usar um ativo de preço fixo para suas consultas.

Isso também serve se você precisa de capacidade de query em tempo real ou bem mais rápida. Afinal, o ClickHouse pode ser um motor de queries MUITO mais performático quando ajustado corretamente.

Sempre há primeiros passos quando você vai fazer algo que pode te economizar bastante dinheiro, e este processo não é exceção.

A primeira coisa a determinar é quanto de dado e quais tabelas a sua ferramenta de BI consome do BigQuery. Essa é uma afirmação bem genérica e não é um problema trivial de resolver no BigQuery, mas, como já mostrei outras vezes, estou disponibilizando uma query para ajudar nisso aqui[2]. Atenção: esta query pode custar bastante, então confira a estimativa na UI do BQ antes de executá-la.

O segundo item da lista é o mais detalhado dos dois: fazer um diagnóstico do seu processo de ingestão. Você vai precisar entender o que "faz a engrenagem girar" e analisar como os dados são ingeridos hoje no BigQuery. O motivo é que vamos modificar isso para "dividir" os dados entre o BigQuery e a instância recém-criada do ClickHouse, propagando os dados para os dois.

Para encerrar esta primeira parte, quero dar orientações sobre dimensionamento e criação da instância do ClickHouse que será usada ao longo do restante da série.

Tendo feito várias migrações de BigQuery -> * (algum outro sistema de banco de dados), me perguntam com frequência como escolher o dimensionamento correto do banco de destino. A resposta infeliz que descobri é que não existe, de fato, um método à prova de balas para isso.

Já fiz exercícios analisando os dados extraídos do BigQuery em queries, o volume de cache hits e o uso de slots, mas a verdade é que o BigQuery é um sistema tão diferente da maioria dos outros bancos de dados por aí que não dá para fazer uma comparação justa. Nesses exercícios, descobri que dá para chegar lá, mas o BigQuery não emite algumas métricas necessárias, como dados únicos consultados ou CPU/memória usados pelos slots.

Dito isso, esses exercícios me mostraram uma coisa: comece sempre com pelo menos 8 GB de RAM para um banco em que você faz queries básicas com regularidade; e, se for um banco de visualização realmente em produção, com mais de 10 usuários executando queries computacionalmente pesadas ao longo do dia, então 16 GB é o mínimo. À medida que a complexidade das queries cresce, adicionar mais CPUs ajuda, mas uma máquina com duas CPUs é um bom ponto de partida, independentemente do workload, já que memória é muito mais importante que CPU para a maioria das capacidades de query.

Seguindo essa orientação, eu começaria uma prova de conceito com uma instância bem pequena, como o nível hobbyist da Aiven ou a instância de desenvolvimento do ClickHouse, para colocar tudo em pé e depois escalar conforme necessário para fazer o right-sizing.

Em vez de fazer um passo a passo completo aqui, que inevitavelmente vai ficar desatualizado quando a UI mudar, vou apenas linkar diretamente para a documentação da Aiven sobre o assunto.

O primeiro passo é criar uma conta na Aiven, conforme aqui.

O segundo passo é criar uma VPC na Aiven, conforme aqui, e fazer o peering com a sua VPC do GCP, conforme aqui.

O próximo passo é criar o serviço ClickHouse, conforme aqui. Isso pode levar alguns minutos, então pegue um café ou um chá enquanto espera.

Verifique se está funcionando usando o container Docker ou a ferramenta CLI dentro da sua VPC com peering e, então, você já estará pronto para começar a usar.

Como acima, vou apenas linkar para a documentação do fornecedor, já que qualquer coisa que eu escrever aqui vai inevitavelmente ficar desatualizada quando algo mudar no futuro.

Aqui está o guia de início rápido do fornecedor sobre como criar uma instância.

Eu recomendaria configurar o GCP Private Service Connect para a sua instância do ClickHouse, conforme aqui. Isso garante o mais alto nível de segurança e o mínimo de configuração para usar a sua instância.

Esta parte foi apenas uma introdução básica ao que estamos fazendo com este plano. Na próxima seção, vou abordar como colocar seus dados no ClickHouse e configurar a replicação entre ele e o BigQuery.