Melhores práticas para economizar utilizando o BigQuery
Esse artigo mostrará dicas e hacks para economizar muito dinheiro utilizando o serviço do Google — e que servem para outros bancos de dados que operam na nuvem
O BigQuery é uma tecnologia de armazenamento de dados SaaS (Software as a Service) executado na infraestrutura do Google Cloud. Foi projetado para armazenar e analisar tabelas com bilhões de linhas através da linguagem de programação SQL. O BigQuery é extremamente útil para executar consultas rápidas, obter insights em tempo real e realizar simples análises e previsões.
Neste artigo pretendo mostrar alguns pontos considerados no cálculo do Google e compartilhar algumas dicas que minimizam esse valor e geram melhor desempenho.
E onde estão os custos?
Nem tudo que fazemos no BigQuery é cobrado. Exportar, copiar, deletar e particionar tabelas são exemplos de ações sem custos. Já o armazenamento e o processamento de dados são cobrados pelo Google.
Armazenamento
Antes de começar, vale destacar que os custos podem sofrer pequenas variações dependendo de onde os dados estão alocados geograficamente. Os exemplos a seguir levarão em conta servidores localizados nos Estados Unidos.
As tabelas armazenadas são divididas em duas categorias: armazenamento ativo e armazenamento de longo prazo.
- Tabelas dentro da categoria armazenamento ativo são aquelas que foram modificadas nos últimos 90 dias.
- Tabelas dentro da categoria armazenamento de longo prazo são aquelas que não foram modificadas nos últimos 90 dias e seu preço de armazenamento é metade do valor em comparação ao armazenamento ativo.
Na imagem abaixo temos os valores mensais (em dólar americano) pelo armazenamento por tabela dependendo da categoria em que está classificada. Obviamente, o custo da tabela também depende de seu tamanho.
Processamento
Na maioria das vezes, a maior parte dos custos é originado das consultas realizadas. O Google cobra $5,00 por Terabyte processado. Isso significa que uma consulta de 10 TB, por exemplo, gera um custo de $50 ($5 x 10 TB).
Armazene apenas pelo tempo necessário
Como vimos anteriormente, existe um custo para armazenar as tabelas no BigQuery. Por esse motivo, é importante se desfazer de dados desnecessários o quanto antes. Vai criar uma tabela apenas para uma análise? Configure sua data de validade. Dessa forma, ela vai ser deletada na data definida e você não precisará se preocupar com os custos envolvidos.
Para isso, podemos clicar em “Edit Details” na tabela:
E definir uma data de validade:
Selecione apenas as colunas necessárias
É muito mais fácil simplesmente usar o SELECT * para realizar uma consulta, mas essa prática deve ser evitada uma vez que todas as colunas da tabela são lidas. Seu objetivo é apenas fazer uma rápida visualização da tabela? Use o “PREVIEW” (ao lado da aba “DETAILS”, na primeira imagem do item anterior). É de graça e o resultado será o mesmo. Se você precisa fazer a consulta (para exportar os dados posteriormente, por exemplo) selecione apenas as colunas necessárias. O custo da consulta será calculado baseando-se apenas nas colunas selecionadas.
Para exemplificar, vou utilizar uma tabela chamada transactions do dataset crypto_bitcoin_cash do projeto bigquery-public-data, que é público aos usuários. Essa tabela possui 17 colunas e mais de 350 milhões de linhas.
Supondo que eu só precise de duas colunas: block_hash e input_value, a consulta ficaria da seguinte forma:
O custo seria pouco mais de 3% do valor inicial! Uma economia muito alta, principalmente se pensarmos no longo prazo.
LIMIT não limita o custo
A cláusula LIMIT (utilizada para retornar um número X de linhas), ao contrário do que muitos pensam, não tem impacto no custo de uma consulta. Mesmo se quisermos retornar apenas os dez primeiros registros de uma tabela, o uso do LIMIT não irá evitar que a tabela inteira seja lida. Se o objetivo é apenas retornar algumas linhas da tabela, uma boa alternativa é a cláusula TABLESAMPLE.
Na imagem abaixo, temos uma consulta buscando as primeiras dez linhas e podemos perceber que o processamento será de 835 GiB, mesmo valor visto anteriormente ao processar a tabela completa:
Utilizando a cláusula TABLESAMPLE para buscar apenas 1% das linhas da tabela, temos uma redução para 8,4 GiB:
Utilize o tipo mais barato
Os tamanhos para cada tipo de dado são diferentes e não pensar nisso ao criar novas tabelas ocasiona um custo maior. A tabela abaixo mostra os tipos de dados e seus respectivos tamanhos em bytes:
Agora, vamos comparar o processamento de duas consultas: na primeira, retornamos apenas uma coluna do tipo INTEGER (8 bytes), enquanto que na segunda retornamos uma coluna que possui exatamente a mesma informação, porém com o tipo BOOLEAN (1 byte).
O custo, como era de se esperar, é oito vezes maior! Dessa forma, sempre devemos tomar cuidado ao criar campos binários. Ao invés de valores do tipo STRING como “Sim” e “Não” ou valores numéricos 1 e 0, o ideal é uma coluna com tipo booleano. Muitas vezes os tipos NUMERIC e BIGNUMERIC também são mal utilizados já que os registros não ocupam a capacidade máxima e converter para INTEGER ou FLOAT é uma boa prática.
Calcule o valor da consulta
Até agora não vimos o impacto em dólar de cada consulta que estamos realizando e, aliás, fica extremamente cansativo fazer essa conversão (de processamento para dólar) a cada consulta feita. A boa notícia é que existem algumas extensões que podem ser instaladas no próprio Google Chrome que fazem esse cálculo pra gente. BigQuery Expected Costs, BigQuery Easy e BigQuery Mate são alguns exemplos, mas indico a superQuery, que além de fazer essa continha pra gente, também tem outras funcionalidades e uma UI limpa e moderna. Utilizando essa extensão, podemos ver que a nossa query custa $4,08:
Outra alternativa é utilizar a Calculadora de Preços do Google Cloud Platform, onde você insere as informações e o programa calcula o valor. Também é possível estimar custos em outros serviços, como o Cloud Storage e o Vertex AI.
Particione suas tabelas
Criar tabelas particionadas pode auxiliar na redução do custo de processamento, de armazenamento e melhorar o desempenho de uma consulta.
Particionar nada mais é do que dividir a tabela em blocos a partir de uma coluna. Supondo que particionemos nossa tabela baseando-se num campo de data, serão criados blocos diferentes para cada mês.
Dessa forma, quando for realizada uma consulta apenas para determinado mês, só serão lidos registros daquele mês em questão (e não mais da tabela inteira). Além disso, o custo de armazenamento será feito por bloco, ou seja, se determinado bloco não foi modificado há mais de 90 dias, o custo será inferior a outro bloco modificado mais recentemente.
E caso você se interesse por esse tema e esteja em busca de novos desafios profissionais dentro de um ambiente bacana para se desenvolver, a RD Station tem várias oportunidades abertas, cada uma com um desafio diferente :)
