Como reduzir em mais de 90% seu custo de armazenamento no Google BigQuery
Estratégias simples para manter seu custo de cloud dentro do orçamento planejado
Não é novidade para ninguém que a quantidade de dados gerados cresceu exponencialmente nos últimos anos e cada vez mais se tornam não só essenciais para a operação mas também um ativo para as empresas. De forma similar, é de conhecimento geral que a máxima “Não há almoço grátis” se aplica nesse caso, com o crescimento da quantidade de informações surge a necessidade de armazenar os dados, seja em nuvem, em um data center ou até mesmo no ártico.
Nesse artigo vamos nos concentrar no ambiente do Google Cloud Platform, utilizando as seguintes tecnologias:
- Apache Airflow
- Google BigQuery
- Google Cloud Storage
O problema que nos motivou foi:
Como reduzir os custos de armazenamento no Google Cloud Bigquery?
Existem diversas estratégias para isso.
A mais simples é a configuração de expiração na partição das tabelas, desta forma, após o período configurado, os dados simplesmente serão apagados automaticamente.
Apesar de ser uma estratégia interessantíssima, principalmente para dados que não exigem persistência, sabemos que algumas informações não podem ser “jogadas fora” afinal, os dados são um ativo da empresa.
Com isso em mente, uma alternativa encontrada foi utilizar o Google Cloud Storage, e o motivo é simples, os dados podem ser compactados através da exportação dos dados, conforme exemplo abaixo:
Se você não deseja utilizar o próprio BigQuery para fazer a exportação, uma alternativa é a utilização do gcloud conforme exemplo:
Aqui temos alguns pontos interessantes para serem levados em consideração.
O primeiro deles é que podemos incluir o conceito de hive partitions, através do dt={data} no exemplo.
O segundo é que existem quotas de exportação feitas via jobs de exportação, atualmente o valor é de 50TB ou 100.000 exports/dia, mas jobs feitos por SQL, ou seja, com o EXPORT DATA direto no BigQuery, funcionam mesmo que você exceda os limites de 50TB uma vez que utiliza seus slots (no caso de flat rate pricing).
Se você tem interesse em detalhes sobre os custos do BigQuery e do Storage, as documentações podem ajudar. Um outro aliado à sua causa é o Google Cloud Pricing Calculator.
Uma vez que os dados estão guardados, compactados, surge a dúvida:
Como conseguimos acessar esses dados no Storage em caso de necessidade?
Existem diversas alternativas para isso. Vamos nos concentrar nas duas mais simples:
1 — Retornar os dados para o BigQuery através de um LoadJob
A principal vantagem fazer um LoadJob e voltar os dados para o BigQuery é que seu poder de processamento será maior. Todas as consultas, processamentos, alterações serão mais rápidos. Porém há de se lembrar que agora não pagaremos apenas uma, mas sim duas vezes pela mesma informação. Por isso é recomendável que seja feito de forma temporária.
2 — Conectar os dados como uma Tabela Externa
Nesse caso os dados ficarão acessíveis para qualquer pessoa que queira consultar, desde que a mesma possua os acessos, como se fosse uma tabela normal. E qual a pegadinha? Como os dados estão no Storage, pode exigir um tempo maior nas consultas.
Mas lembra que falamos das hives partitions no exemplo anterior? Elas podem ajudar nesse caso. Basta, no momento da exportação, criar um sistema de partições que faça sentido e separar em ‘pastas’ no storage, colocar o caminho para essas pastas nas configurações de partição na hora da criação da tabela externa e seus dados serão consultados mais rapidamente.
Agora que entendemos os princípios básicos e algumas de nossas opções chegou a parte de criar a automação do processo, afinal de contas, ninguém gosta de fazer tarefas repetitivas, não é mesmo? A solução que encontramos foi o Apache Airflow com a inclusão de algumas etapas extras em nosso pipeline de dados.
Não entraremos em detalhes de infraestrutura, mas um bom ponto de partida para criação do ambiente do Airflow dentro do GCP pode ser tanto a documentação oficial quanto este artigo publicado no medium do Apache Airflow.
Caso opte por utilizar uma DAG separada para o export, o que você precisa fazer é simplesmente adicionar uma etapa com o TriggerDagRunOperator em seu pipeline:
Se há necessidade de validação dos jobs de exportação, é necessário fazer uma pequena edição no operador BigQueryToGCSOperator. Desta forma teremos o retorno do job_id que, utilizado por meio de XComs, valida o job, conforme código abaixo:
Caso o sucesso da task seja suficiente para você, basta usar o operador BigQueryToGCSOperator e pular a etapa “check_job”.
Com o código acima, teremos a seguinte DAG:
Na etapa “check” verificamos a existência da tabela e validamos os dados, após a decisão temos dois caminhos a serem seguidos:
1 — A tabela existe e os dados estão corretos.
Caso isso seja verdade, o próximo passo é limpar o bucket (caso tenha exportação falha). Após esse processo, realizamos a exportação dos dados, verificamos se o job foi executado com sucesso e, por fim, apagamos a tabela.
2 — A tabela não existe ou os dados estão incorretos.
A DAG é encerrada. Caso faça sentido, é possível incluir alertas ou forçar falhas nessas etapas.
Não menos importante, chegamos na seguinte pergunta:
E qual foi o resultado de tudo isso?
Nesse cenário apresentado, os dados armazenados eram:
80.000 GiB em LongTerm
45.000 GiB em Active Storage
Após a compressão, esses dados têm tamanho aproximado de 11.000 GiB, ou seja, uma redução de ~91%. Lembrando que os resultados podem variar de acordo com os seus dados.
A redução do custo pode ser ainda maior caso você aplique políticas de Lifecycle em seus dados. O Archive pode custar até ~20x menos que o armazenamento padrão, mas, existem custos quando esses dados forem acessados.
Portanto, como última mensagem, tenha a calculadora de preços sempre em mãos para entender qual o melhor cenário para você e seu negócio!
Espero que tenham gostado. Se acredita que as alterações podem ajudar em seu negócio, eu adoraria receber algum feedback, fique à vontade para me enviar uma mensagem no LinkedIn!
Gostaria de agradecer aos meus colegas de trabalho, em especial ao Rafael Santa Cruz Teixeira, um dos idealizadores do projeto, por todo apoio ao longo do desenvolvimento!
Quer publicar seu conteúdo no blog FinOps Brazil? Convidamos você para dividir sua experiência! Clique aqui e saiba como ajudar na missão de difundir a prática de FinOps. : )
