Como reduzimos o custo do BigQuery no Banco Carrefour
por Queziane Marques - Arquiteta de Dados no Banco Carrefour e Alexander Sica - Engenheiro de Dados na GAVB.
O conceito de FinOps, ou Operações Financeiras, vem ganhando destaque à medida que as organizações buscam otimizar os custos associados às operações na nuvem. FinOps é uma prática que promove a colaboração entre as equipes de finanças, operações e engenharia para garantir uma gestão eficaz dos custos da nuvem. Essa abordagem enfatiza a transparência, a responsabilidade e a agilidade na gestão dos recursos de nuvem, permitindo uma compreensão clara dos gastos e possibilitando a tomada de decisões embasada em informações sobre como esses recursos são alocados e utilizados. Nesse artigo, iremos contar como o Banco Carrefour aplicou o conceito de FinOps na sua plataforma de dados.
No final de 2022, o Banco Carrefour iniciou o processo de construção de uma plataforma de dados moderna, e foi escolhido o BigQuery para compor o nosso Data Lakehouse. Em uma dinâmica com a participação de todos os membros da equipe de dados, decidimos batizar a plataforma com o nome de Téssera. A palavra tem origem no grego “τέσσερα” e significa “quatro”, que por sua vez deriva do latim “tessera” e era usada para designar vários objetos quadrados ou cúbicos, como dados.
Ao longo dos meses, a Téssera cresceu organicamente com a ingestão contínua de novas fontes de dados e com a construção de novos produtos de dados dentro do BigQuery. Em março de 2023, os custos de processamento dispararam abruptamente, fazendo-se necessária uma investigação. O time de Arquitetura de Dados dedicou-se a estudar e identificar os processos responsáveis pelo ônus financeiro gerado e iniciou um trabalho fundamental para a otimização de custos.
No gráfico a seguir, gerado a partir da informação de custo de processamento de dados no ambiente de produção da Téssera, é possível identificar uma queda constante após março de 2023, evidenciando que tivemos sucesso nas nossas iniciativas de redução de custo. Vem com a gente descobrir como isso foi possível!
Sobre a diferença de custo entre modelos de faturamento
O BigQuery oferece dois modelos de faturamento para processamento de dados:
- On-demand: modelo de faturamento baseado no número de bytes processados por cada consulta.
- Capacity pricing: modelo de faturamento baseado na capacidade computacional utilizada para executar cada consulta, medida em slots (CPUs virtuais), ao longo do tempo de execução.
A plataforma Téssera foi desenvolvida considerando que o modelo de custo adotado seria o on-demand. As consultas, portanto, visavam sempre a leitura da menor quantidade possível de bytes, independentemente da complexidade computacional.
Nas análises realizadas, verificamos que cerca de 90% do custo estava concentrado no processamento de 10% das tabelas existentes. O custo era elevado pois eram escaneados vários terabytes de dados. Não havia, contudo, possibilidade de reduzir a quantidade de bytes lidos. Consideramos, então, a mudança do modelo de custo para o baseado em capacidade computacional.
A princípio, o modelo flat-rate parecia desvantajoso. A reserva mínima para esse modelo era de 500 slots, ao custo mensal de $10,000. Incrementos de 100 slots poderiam ser adicionados ao custo de $2,000, considerando as regiões dos Estados Unidos. Como alternativa, poderíamos usar os flex-slots¹, que permitiam a reserva de slots sob demanda. A mudança para o novo modelo envolvia a criação de mecanismos para o gerenciamento automatizado dessas reservas, que deveriam ser ativadas e desativadas mediante a demanda, a fim de otimizar os custos.
Durante esse processo de análise (em 29 de março de 2023, mais precisamente), a GCP anunciou um novo modelo de faturamento baseado em capacidade computacional, chamado de BigQuery Editions². No mesmo anúncio, também foi comunicado que os preços do modelo de custo on-demand seriam aumentados em 25% em um futuro próximo.
Passamos, então, a avaliar a mudança já para esse novo modelo. A mudança para o BigQuery Editions se mostrou ainda mais vantajosa. Com ela, não seria necessário desenvolver o mecanismo de gerenciamento da reserva, pois o BigQuery Editions já conta com um autoscaling³.
O BigQuery Editions oferece três edições: Standard, Enterprise e Enterprise Plus. Os detalhes e diferenças entre cada edição podem ser melhor estudados na documentação. A edição escolhida pelo nosso time foi a Enterprise.
Além de selecionar a edição, também precisamos definir a quantidade de slots que serão utilizados. A Google disponibiliza as consultas para auxiliar nessa tomada de decisão.
A consulta abaixo calcula a média de slots utilizados, por exemplo⁴:
SELECT
SUM(total_slot_ms) / (1000 * 60 * 60 * 24 * 7) AS avg_slots
FROM
`region-us`.INFORMATION_SCHEMA.JOBS
WHERE
-- Filter by the partition column first to limit the amount of data scanned.
-- Eight days allows for jobs created before the 7 day end_time filter.
creation_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 8 DAY) AND CURRENT_TIMESTAMP()
AND job_type = 'QUERY'
AND statement_type != 'SCRIPT'
AND end_time BETWEEN TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND CURRENT_TIMESTAMP();Além da média, também é interessante identificar os picos de uso, a fim de não impactar no desempenho do processamento, o que pode ser feito a partir da consulta abaixo⁵:
SELECT
project_id,
job_id,
reservation_id,
EXTRACT(DATE FROM creation_time) AS creation_date,
TIMESTAMP_DIFF(end_time, start_time, SECOND) AS job_duration_seconds,
job_type,
user_email,
total_bytes_billed,
-- Average slot utilization per job is calculated by dividing total_slot_ms by the millisecond duration of the job
SAFE_DIVIDE(job.total_slot_ms,(TIMESTAMP_DIFF(job.end_time, job.start_time, MILLISECOND))) AS job_avg_slots,
query,
-- Determine the max number of slots used at ANY stage in the query.
-- The average slots might be 55. But a single stage might spike to 2000 slots.
-- This is important to know when estimating number of slots to purchase.
MAX(SAFE_DIVIDE(unnest_job_stages.slot_ms,unnest_job_stages.end_ms - unnest_job_stages.start_ms)) AS jobstage_max_slots,
-- Check if there's a job that requests more units of works (slots). If so you need more slots.
-- estimated_runnable_units = Units of work that can be scheduled immediately.
-- Providing additional slots for these units of work accelerates the query,
-- if no other query in the reservation needs additional slots.
MAX(unnest_timeline.estimated_runnable_units) AS estimated_runnable_units
FROM `region-us`.INFORMATION_SCHEMA.JOBS AS job
CROSS JOIN UNNEST(job_stages) as unnest_job_stages
CROSS JOIN UNNEST(timeline) AS unnest_timeline
WHERE project_id = 'my_project'
AND statement_type != 'SCRIPT'
AND DATE(creation_time) BETWEEN DATE_SUB(CURRENT_DATE(), INTERVAL 7 DAY) AND CURRENT_DATE()
GROUP BY 1,2,3,4,5,6,7,8,9,10
ORDER BY job_id;Também é possível obter estimativas através do Estimador de Slots do BigQuery⁶.
Escolhemos o tamanho da nossa reserva baseado na quantidade máxima de slots que precisávamos para alguns jobs. Como mencionado anteriormente, o BigQuery Editions faz o escalonamento automático de slots⁷, ou seja, quando a plataforma está ociosa ou com pouca carga, apenas os slots necessários são alocados, reduzindo significativamente os custos.
Dentro do Grupo Carrefour Global, fomos o primeiro caso de uso a realizar essa migração, feita em 06 de abril de 2023. Foi o primeiro passo realizado para redução de custos de processamento.
Sobre a diferença de custo entre regiões
A diferença de custos de processamento na nuvem pode ser muito discrepante entre uma região e outra, e isso se deve a diversos fatores como impostos, custo de infraestrutura, escassez de recursos, além do custo adicional devido a flutuações de conversão de moeda, caso o pagamento não seja feito em dólares.
No Banco Carrefour, os dados eram processados na região southamerica-east1, que fica em São Paulo. Para o modelo de faturamento on-demand, o custo dessa região é 80% superior ao custo na multi-região US.
Mas, por que estávamos em São Paulo? Havia uma incerteza sobre a necessidade de que os dados fossem armazenados e processados em servidores brasileiros. Em conjunto com outros times do Banco, constatamos que não há essa obrigação, o que motivou a mudança para uma região mais econômica. Mantivemos a eficiência, reduzimos o custo e permanecemos em compliance com as legislações.
Escolhemos a multirregião dos Estados Unidos, no novo modelo de faturamento baseado em capacidade, BigQuery Editions Enterprise for US. Para comparação, o preço do slot-hour⁸ na região southamerica-east1 é cerca de 56% mais caro.
A migração entre regiões foi feita em maio de 2023. Em uma semana de trabalho, conseguimos migrar todos os dados e todas as esteiras de dados para a nova região.
Sobre o grande impacto de pequenas mudanças
Pudemos notar de imediato uma melhoria substancial nos custos assim que as mudanças no modelo de faturamento e de migração de região foram implementadas.
Analisando o custo do modelo atual e o custo do modelo anterior, identificamos que gastamos cerca de 20 slot-hour para cada TB (terabyte) processado (essa proporção é específica para o nosso cenário e vai variar de acordo com as consultas executadas).
Fazendo as contas
Abaixo, temos a tabela de preços referente a setembro de 2023:
Considerando a nossa proporção de computação/TB, nosso custo foi de R$ 6,80 por TB processado (20 x R$ 0,34). Se comparado ao modelo e região anteriores, nosso custo seria de R$ 64,17.
A diferença é impressionante. Nosso custo hoje é aproximadamente 90% menor do que seria se não tivéssemos realizado as mudanças mencionadas anteriormente.
Esse impacto demonstra a eficácia das alterações implementadas, que foram feitas de maneira ágil e executadas com excelência. Também é relevante destacar a importância da prontidão na tomada de decisão. Com autonomia, conhecimento e recursos técnicos, pudemos colocar em prática mudanças em um curtíssimo espaço de tempo.
Sobre otimização de processos
Após conduzirmos as mudanças no modelo de faturamento e de migração de região, que resultou em uma redução de custos imediata, passamos a olhar cuidadosamente e minuciosamente para as nossas esteiras de dados para enxergar novas oportunidades de melhoria.
O objetivo deste trabalho era identificar potenciais alterações que trouxessem redução de custos. Com a migração de região, também passamos a ter acesso a recursos que ainda não estavam disponíveis na região antiga.
Durante esse processo, identificamos a possibilidade de eliminar por completo um conjunto de dados. Explicamos: era utilizado um conjunto de dados para armazenar os dados crus e outro para armazenar os dados mascarados fisicamente.
Para atender os requisitos de conformidade e proteção de dados pessoais, adotamos uma abordagem mais avançada: o mascaramento dinâmico de dados⁹. Agora, o mascaramento acontece de acordo com o tagueamento da coluna e do nível de permissão de cada usuário.
Dataset com dados mascarados fisicamente [C̶H̶I̶R̶R̶I̶O̶N̶] deletado! Com a exclusão, reduzimos o custo de armazenamento e de processamento dessa camada adicional.
Sobre a diferença entre o custo de armazenamento lógico e físico
Inicialmente, focamos todos os nossos esforços na diminuição dos custos relacionados ao processamento de dados, devido ao destaque que essa linha tinha em nosso dashboard de billing do projeto Téssera. Quando olhávamos para a próxima linha relacionada aos custos do BigQuery, que era a de armazenamento, não nos trazia preocupações, já que a impressão era de que o custo de armazenamento era bem menor do que o custo de processamento de dados.
Após todo o trabalho anterior, as linhas entre processamento e armazenamento inverteram-se e, agora, tornaram-se o foco de trabalho de otimização. Coincidentemente a Google anunciou um novo modelo de faturamento para armazenamento do BigQuery, chamado de armazenamento físico¹⁰.
O BigQuery oferece dois modelos de faturamento para armazenamento de dados (lógico e físico), além de ter um tipo de cobrança diferente dependendo do tempo em que os dados são armazenados (chamados de armazenamento ativo e armazenamento de longo prazo).
É possível verificar se o armazenamento físico pode trazer benefícios para o seu cenário utilizando uma consulta de comparação entre o custo de cada um dos modelos de faturamento. Fizemos esse levantamento e identificamos a oportunidade de redução de custos de armazenamento em surpreendentes 80%.
Fizemos, então, a alteração dos datasets para o armazenamento físico. Aplicamos uma monitoria para validar se o armazenamento físico mantêm-se vantajoso, uma vez que o BigQuery oferece a flexibilidade de fazer a troca entre os tipos de armazenamento, em um intervalo de 14 dias.
Sobre gerenciamento e monitoramento de custos
Para o acompanhamento do dia a dia, criamos um dashboard de monitoramento de custos de processamento de consultas e de armazenamento de tabelas no BigQuery.
Nele, temos visibilidade de quais tabelas, consultas e usuários estão gerando mais despesas na plataforma. Com base nesses dados, podemos tomar medidas para conter os gastos ou identificar novas oportunidades de melhoria.
A implementação desse dashboard de monitoramento de custos representa um dos passos mais importantes na gestão financeira, pois oferece clareza sobre os gastos associados aos produtos de dados que sobem para o ambiente de produção da Téssera.
O dashboard oferece transparência, permitindo que as equipes compreendam como suas ações impactam diretamente as finanças do projeto, promovendo um nível de consciência que visa manter a sustentabilidade financeira. Isso capacita todas as partes envolvidas a tomar decisões fundamentadas na otimização de recursos, visando a redução de desperdícios e garantindo a eficiência e a estabilidade econômica da plataforma de dados a longo prazo.
O dashboard foi construído no Looker Studio, utilizando, principalmente, dados da view INFORMATION_SCHEMA.JOBS¹¹.
Sobre treinamento e capacitação do time
Para fortalecer a atuação da equipe, em relação ao novo ambiente que estamos construindo, foi desenvolvida uma trilha de aprendizagem com foco na introdução à GCP. Isso permitiu aos colaboradores do Banco Carrefour não apenas adquirirem conhecimentos sobre o novo ambiente, mas também desenvolverem suas habilidades, enfrentando um desafio relacionado a consultas mais eficientes. Essa ação tem um impacto direto na conscientização do público, contribuindo para a redução de custos e o uso eficiente dos recursos.
Os cinco primeiros a concluírem o desafio de forma bem-sucedida foram premiados com uma medalha virtual personalizada, que reflete a identidade visual da nossa Jornada dos Dados, uma parceria entre o Banco Carrefour e a Consultoria Atra. Além disso, todos aqueles que completaram os quatro módulos da trilha de aprendizagem e o desafio final de dados receberam brindes personalizados e certificados. 🏅🏆
Sobre as oportunidades de melhorias
Continuamos mapeando oportunidades para melhorar a plataforma, reduzindo os custos e/ou melhorando a performance.
Em nossa lista de trabalho, já temos como tarefa o (re)particionamento de tabelas e da clusterização de outras. Além das análises das métricas dos jobs executados, também recebemos essas recomendações no Hub de Recomendação¹² que indica quais mudanças podem ser realizadas e qual seria o impacto estimado.
Além disso, seguimos atentos às novidades e novas funcionalidades da ferramenta, sempre buscando otimizar cada vez mais a nossa plataforma.
O que achou deste artigo? Você já utiliza o BigQuery em seu trabalho?
Aqui, em nossa equipe de Dados & Analytics do Banco Carrefour, gostamos muito de compartilhar informações e nos conectar com a comunidade de dados! Compartilhe conosco suas impressões, interaja no botão “clap” ou registre suas dúvidas sobre o conteúdo na seção de comentários. E se quiser que abordemos algum outro tema por aqui, é só nos informar. Aproveite também para seguir o nosso perfil no Medium. Estamos à disposição! 😄
Até a próxima e que a força dos dados esteja com vocês! #GOdata 🎲📊💙
NOTAS:
¹ Introducing BigQuery Flex Slots for unparalleled flexibility and control
² New BigQuery editions: flexibility and predictability for your data cloud
³ Introduction to slots autoscaling
⁴ https://cloud.google.com/bigquery/docs/information-schema-jobs#calculate_average_slot_utilization
⁶ https://cloud.google.com/bigquery/docs/slot-estimator
⁷ https://cloud.google.com/bigquery/docs/slots-autoscaling-intro
⁸ medida básica de faturamento definido como um único slot sendo utilizado por uma consulta por uma hora
⁹ Introdução ao mascaramento de dados
¹⁰ Reducing BigQuery physical storage cost with new billing model
¹¹ https://cloud.google.com/bigquery/docs/information-schema-jobs
