Foto de Rob Wicks no Unsplash
Introdução
As edições do BigQuery trouxeram aos clientes novos modelos de precificação e mudanças relevantes nos modelos já existentes.
Na DoiT, trabalhamos com vários clientes para construir sistemas bem arquitetados, usar serviços de nuvem com eficiência e otimizar custos. Com as mudanças no BigQuery, muitos clientes nos procuraram querendo reduzir custos de computação e avaliando a transição do 'On-Demand' para o novo modelo, a 'Standard Edition'.
O conteúdo a seguir mostra os passos para avaliar se a transição compensa em custo e como executá-la e monitorá-la.
O código SQL referenciado neste post requer acesso a estas INFORMATION_SCHEMA views: JOBS_BY_PROJECT, JOBS_TIMELINE_BY_PROJECT, RESERVATION_CHANGES_BY_PROJECT.
Pré-requisitos para acesso às tabelas:roles/bigquery.resourceViewer(em nível de projeto)
O essencial sobre a reserva da Standard Edition
A Standard Edition, uma oferta baseada em computação (Slot hours), se destaca entre as demais opções baseadas em computação por ser por projeto (semelhante ao On-Demand), e não no nível da organização.
A principal vantagem é o acesso ao autoscaling a baixo custo e sem nenhum compromisso: "O BigQuery ajusta dinamicamente os slots conforme o aumento ou a redução do seu workload." ( Introduction to slots autoscaling )
As principais diferenças entre On-Demand e Standard Edition são:
1. Unidades de cobrança: o On-Demand cobra pelo volume de dados escaneados, enquanto a Standard Edition usa um modelo de slot/hora.
2. Disponibilidade dos slots: no On-Demand, os slots são considerados "hot" e ficam disponíveis na hora. Já na Standard Edition, o AutoScaler identifica a capacidade de slots necessária para os jobs de query antes de alocá-los (cerca de 10 segundos de atraso), o que afeta a latência das queries.
3. Máximo de slots disponíveis: 2.000 slots no On-Demand e 1.600 slots na Standard Edition.
\[1\] Checklist de features e limitações da Standard
O primeiro passo é verificar a compatibilidade do seu projeto com a Standard Edition. Olhe com atenção a lista de features destacadas e tenha clareza sobre o que ela permite e o que restringe:
Há uma comparação completa e detalhada aqui: BigQuery editions features.
\[2\] Analise o uso dos workloads
Depois de avaliar features e restrições, o próximo passo é estimar custos de acordo com o perfil do projeto: voltado a I/O ou a CPU (Slot). Na view INFORMATION_SCHEMA.JOBS, esses dados ficam em total_bytes_billed(I/O) e total_slot_ms (CPU).
O objetivo é comparar o gasto com dados escaneados e o gasto estimado com uso de slots. Calcular o gasto baseado em I/O é simples, pois é a soma do custo de todas as queries. Já a estimativa baseada em slots fica um pouco abaixo do real, porque não considera o comportamento do autoscaler (bucket de 100 slots e downscaling apenas após o mínimo de um minuto). Para corrigir essa diferença, aplicamos um multiplicador de 1,5 sobre a estimativa baseada em slots.
A tabela abaixo compara os custos mensais usando a razão entre o custo em Slots e o On-Demand, indicando a variação estimada de custo na transição do On-Demand para a Standard Edition.
Razão abaixo de 100 indica possível redução de custo; acima de 100, possível aumento.
Por exemplo:
Gasto mensal do cliente — O On-Demand é mais caro
Gasto mensal do cliente — O On-Demand é mais barato
Código para gerar a tabela acima: BigQuery OnDemand vs. SE.sql
Como a Standard Edition tem menos features que a On-Demand, o recomendado é continuar no On-Demand quando a razão fica, em geral, acima de 75%. A economia esperada tende a ser pequena e ainda há perda de funcionalidades.
\[3\] Configuração de máximo de slots
A Standard Edition exige uma única configuração: o máximo de slots, que funciona como o teto do AutoScaling.
Como definir a configuração ideal?
Não existe uma fórmula única que sirva para todo mundo: o parâmetro provavelmente vai precisar de ajustes depois da configuração inicial, dependendo do padrão do seu workload e de como você quer balancear custo e performance.
Uma forma de chegar a um valor inicial é com a fórmula a seguir:
Identifique o percentil 90 (P90) das horas, no período selecionado, em que o uso de slots passou de 100 (configuração básica) e arredonde para o múltiplo de 100 mais próximo, para cima.
Configuração máxima baseada na hora P90 do período selecionado
Exemplo de código para definir o máximo inicial: BQ SE max configuration.sql
Criar reserva
Há um guia passo a passo bem documentado para criar uma reserva: Get started with reservations.
Selecione Standard Edition, defina o 'max Slots' e escolha a região ou multi-região correta — caso contrário, a reserva não funciona direito.
\[4\] Monitoramento de performance e avaliação de custo
Impacto na performance
Para acompanhar a performance da sua aplicação, colete métricas como tempo de processamento dos jobs e tempo de resposta de queries ad-hoc antes da migração e compare com os resultados pós-migração. Vale comunicar os usuários do BigQuery sobre as mudanças esperadas e ouvir o que eles têm a dizer.
Você pode avaliar a performance pelo lado do sistema usando os Administrative resource charts, abordados na próxima seção.
Benefícios de custo
Para avaliar o custo-benefício, revise seus gastos no dashboard de billing diário. Na seção de billing, escolha o SKU Analysis e Standard Edition.
A tabela abaixo soma, em intervalos de uma hora, a alocação total de slots e os custos estimados. Com essas informações, dá para calcular de forma aproximada o custo real com base nas ações do autoscaler.
Exemplo de código: Standard Edition cost estimation.sql
Distribuição estimada de custo por hora
\[5\] Tunning
Ajustar a Standard Edition é mexer no máximo de slots para ganhar performance (aumentando os slots) ou reduzir custos (diminuindo os slots). A meta é um sistema bem balanceado, em que os recursos não fiquem subutilizados nem superalocados.
Monitorar a eficiência do seu workload mostra se o sistema está balanceado, subutilizado ou superdimensionado. Você consegue isso observando os Administrative resource charts ou consultando direto as INFORMATION_SCHMEA views.
Administrative resource charts:
Os admins do BigQuery acompanham o uso de Slots da organização e a performance dos jobs do BigQuery ao longo do tempo. Esses gráficos ficam na seção 'Monitoring' da barra lateral do BigQuery, com várias visualizações para responder a diferentes perguntas. Para conhecer essas funcionalidades, consulte o guia sobre administrative resource charts.
- Análise de uso de slots: use a métrica P90 ou P99 para examinar a relação entre o uso de slots e a alocação (que inclui "baseline + Autoscaled slots") e o tempo necessário para escalar para cima ou para baixo.
Uso de Slots
O gráfico acima usa dados da RESERVATION_CHANGES_BY_PROJECT``view, que traz informações sobre alterações de reserva.
A tabela abaixo mostra a alocação de slots e o tempo até a próxima mudança (escalonamento para cima ou para baixo). A métrica 'allocated_slots' representa a quantidade de slots atribuídos em um determinado momento até que ocorra um novo 'UPDATE', enquanto 'Estimated total slots' representa a alocação geral ao longo do período.
Exemplo de código: Monitor BQ edition autoscaling.sql
Alocações reais de slots com duração
- Concorrência de jobs: para entender gargalos do sistema, observe a métrica 'pending jobs'.
Pending Jobs
- Performance dos jobs: monitore jobs com alta latência usando o percentil 90 (P90)
Latência dos jobs
Resumo e recomendação
Em cenários com bursts ou picos, podem existir abordagens mais adequadas do que esta, exigindo análise mais aprofundada. Mesmo assim, as ferramentas mostradas trazem insights valiosos durante essa análise.
A transição depende, principalmente, do tipo de uso nos projetos: focado em I/O (que torna o 'On-Demand' mais caro) ou em CPU (que encarece a 'Standard Edition').
O Google recomenda a Standard Edition principalmente para projetos de pesquisa e desenvolvimento: "Por exemplo, a Standard Edition é ideal para workloads ad-hoc, de desenvolvimento e de testes."
Como o termo 'workload de produção' varia de cliente para cliente, alguns podem considerar usar a Standard Edition até em workloads de produção de ETL/ELT. Isso é aceitável se as limitações da edição forem atendidas (em especial o SLA de 99,9), se a carga ficar estável ao longo do tempo e se nenhum usuário final se importar com a latência das queries.
Agora que você já conhece o processo, faça o teste e nos conte como foi.