Guia introdutório sobre otimizações de custo e desempenho no BigQuery
O problema
Imagine que sua empresa roda vários datasets no BigQuery e, há um mês, você incluiu um novo time de analistas para fazer consultas. Numa manhã, enquanto toma seu café (ou chá, porque não queremos discriminar ninguém), chega a fatura do GCP e você descobre que seus custos de análise e armazenamento no BQ subiram 5.000%. Bem provável que você cuspa a bebida na hora e faça a maior bagunça no teclado e no monitor. Este artigo vai te ajudar a corrigir, ou até evitar, essa situação chata, mostrando alguns métodos para otimizar seus custos no BigQuery.
Acertando o básico
Antes de mexer nos custos do BigQuery, você precisa fazer alguns preparativos e ter um conhecimento básico de pré-requisitos.
Vou abordar tudo isso nesta primeira parte da série. Com o básico dominado e os preparativos prontos, é só seguir direto para a Parte 2 e adiante para colocar as otimizações em prática.
Veja o que você precisa saber sobre slots do BigQuery, modelos de preço e os fatores que determinam os custos:
Slots
No coração da computação do BigQuery existe um conceito chamado slot. Um slot é simplesmente uma vCPU com um pouco de memória atrelada — como uma mini-VM dedicada ao processamento do BigQuery. Quando você executa uma consulta no BigQuery, ela é processada em um conjunto de slots alocados. Em teoria, quanto mais slots alocados e disponíveis, mais rápido suas consultas rodam.
Um slot executa praticamente qualquer ação que apareça no processo de um job do BigQuery.
Shuffle Slots
Dentro do BigQuery, uma tarefa não documentada que os slots executam é o shuffling dos dados. Até 60% dos slots alocados ao seu projeto podem atuar como shuffle slots a qualquer momento.
Em termos bem simples, shuffling é redistribuir os dados processados para um novo local, para que a etapa atual ou a próxima do plano de execução rode mais rápido. O white paper do Google sobre a arquitetura do BigQuery traz uma visão mais profunda de como o shuffling funciona. Ele ajuda a consulta a rodar de forma mais eficiente, mas usa slots valiosíssimos em operações que não fazem a execução da consulta avançar diretamente.
Modelos de preço
Hoje o BigQuery tem dois modelos de preço distintos: on-demand ou flat-rate.
Preço on-demand
O modelo padrão é o on-demand, que aloca 2.000 slots para suas consultas e mais um pool, com quantidade não divulgada, de slots para loads, cópias de tabelas e jobs de extração. À medida que sobram slots no BigQuery em geral, o pool de 2.000 slots pode crescer, mas isso não é garantido, então não conte com isso. Para referência, o máximo que já vi foi cerca de 3.500 slots em rajadas curtas.
Nesse modelo, você paga uma taxa fixa de US$ 5 por TB de dados escaneados pelas consultas.
Para muitas organizações, esse é o principal motor dos custos do BigQuery.
Preço flat-rate
O preço flat-rate (ou por slots) define um valor fixo para o escaneamento no BigQuery, com possível impacto no desempenho. Ele faz isso limitando o número de slots disponíveis ao que você compra antecipadamente e eliminando o preço de US$ 5 por TB escaneado.
Os slots (incluindo os Flex Slots, que abordo mais adiante) são sempre comprados em blocos de 100. Os slots padrão (ou seja, não-Flex) são adquiridos dentro de um commitment de um mês ou um ano. Vale lembrar: depois que uma reserva é comprada, não dá para cancelar facilmente. Um commitment mensal pode virar anual, mas o caminho inverso não é possível.
Existe uma situação meio espinhosa sobre o que acontece quando um commitment termina, que difere entre os dois e já mudou algumas vezes. Por isso, vou só linkar a documentação do Google sobre commitments mensais e commitments anuais, para o caso de mudar de novo. Recomendo fortemente criar eventos no calendário para te avisarem com bastante antecedência do término, assim você reage na hora certa.
Dito isso, no modelo flat-rate seus slots podem ser ampliados, ou totalmente substituídos, por um pool adicional chamado Flex Slots. Os Flex Slots são idênticos em capacidade e função aos slots normais, mas oferecem a opção de um commitment mais curto e flexível, com tempo mínimo de 60 segundos. Atingido esse mínimo, você pode cancelar a reserva a qualquer momento e os slots somem. Isso permite escalar para cima e para baixo conforme a necessidade. Em geral, são úteis quando há demanda por mais slots em períodos curtos, como picos de uso ou quando um job particularmente pesado está rodando e poderia consumir todos os slots de uma reserva. Um exemplo clássico é o varejo na Black Friday ou na Cyber Monday, os maiores dias de compras dos Estados Unidos.
No momento em que escrevo, 100 slots custam US$ 2.000 num commitment mensal e US$ 1.700 por mês num commitment anual. Então, para igualar o desempenho do on-demand, você precisaria comprar vinte blocos de 100 slots, o que daria US$ 40.000 por mês no commitment mensal ou US$ 34.000 por mês no anual. Por isso, em geral, não vale a pena comprar 2.000 slots, a menos que você esteja gastando pelo menos esse valor em custos de escaneamento no BigQuery.
O plano para determinar os custos
Antes de partir para a otimização de custos, você precisa analisar os dados de uso do(s) seu(s) projeto(s). Para isso, é preciso ter acesso aos dados de consultas dos seus projetos/datasets.
Uma observação rápida para alinhar expectativas: estou abordando isso já na primeira parte da série para que possa ser feito desde já e comece a registrar dados de uso, caso você não leia várias partes de uma vez (ou em pé). É a partir da Parte 3 que os frutos desse trabalho realmente começam a ser colhidos.
Existem dois métodos: audit log sinks e as tabelas INFORMATION_SCHEMA.
O audit log sink é o método preferido, pois os dados são bem mais ricos e cobrem múltiplos projetos, datasets e regiões. Mas, se ainda não estiver habilitado, leva um tempo até populá-lo conforme os jobs vão rodando no BigQuery. Vale notar que existe um pequeno custo associado ao audit log sink, na forma de armazenamento no BigQuery para os dados.
Já as views do INFORMATION_SCHEMA já existem em cada dataset, projeto e região, mas, ao contrário do audit log sink, cada combinação de dataset e região tem seu próprio conjunto dessas tabelas, então as consultas podem precisar ser executadas várias vezes. Há também algumas informações ausentes nas tabelas do INFORMATION_SCHEMA que existem nas tabelas do audit log; alguns exemplos estão documentados como comentários nas queries SQL mais adiante neste artigo, onde elas não casarão 1 para 1 com as queries do audit log sink.
Se for usar o método INFORMATION_SCHEMA, pode pular a próxima seção sobre como configurar o audit log sink, porque seus dados já existem. Há um detalhe aqui: os dados coletados no audit log sink são mais ricos do que os fornecidos pelas views do INFORMATION_SCHEMA. O ponto negativo é que, ao configurá-lo, ele só passa a registrar dados a partir daquele momento, então os workloads regulares precisarão rodar por algum tempo antes de os dados estarem prontos para uso. Esse prazo depende muito dos workloads em execução e do que é considerado "normal" para a frequência com que eles rodam.
Observação: se você é cliente DoiT atualmente e usa o dashboard BigQuery Lens na nossa Cloud Management Platform (CMP), o Audit Log Sink já está configurado no seu ambiente. Recomendo usá-lo para as operações descritas nestes artigos. Você encontra mais informações aqui.
O nome totalmente qualificado do dataset será
Se for o seu caso, pode pular a próxima seção.
Configurando o Audit Log Sink
Se você optou por usar as views INFORMATION_SCHEMA em vez de um Audit Log sink, pule esta seção.
A seguir, as instruções de como configurar um Audit Log Sink. O ideal é executar esses comandos no seu localhost ou no Cloud Shell, com o gcloud CLI configurado para usar o projeto onde você quer armazenar o dataset.
Primeiro, execute o comando a seguir, atualizando o nome do sink, o ID do projeto e o nome do dataset:
gcloud logging sinks create <Sink Name> bigquery.googleapis.com/projects/<Project ID>/datasets/<Dataset Name> \ — use-partitioned-tables \
— log-filter=’protoPayload.metadata."@type"="type.googleapis.com/google.cloud.audit.BigQueryAuditMetadata"’
Depois de executado, o comando exibirá uma service account criada para esse fim. Copie o e-mail completo dessa service account em uma anotação.
Em seguida, você concederá à service account recém-criada o papel BigQuery Editor em cada projeto que usa o BigQuery. Como sempre na nuvem, há várias formas de fazer isso, então incluo as 3 mais comuns: por projeto, em uma organização inteira e em uma pasta dentro de uma organização.
Para obter o ID do projeto, da pasta e da organização, basta acessar o "seletor de projetos" no topo do console do GCP, onde há uma coluna de ID com o identificador necessário do recurso.
Por projeto:
gcloud projects add-iam-policy-binding <Project ID> \
— member=<Service Account> — role=roles/bigquery.dataEditor
Em uma organização:
gcloud organizations add-iam-policy-binding <Organization ID> \
— -member=<Service Account> — role=roles/bigquery.dataEditor
Em uma pasta:
gcloud resource-manager folders add-iam-policy-binding <Folder ID> \
— -member=<Service Account> — role=roles/bigquery.dataEditor
A partir desse ponto, os dados de consultas começarão a ser armazenados no dataset especificado acima. Para ter uma boa quantidade de dados depois disso, espere pelo menos alguns dias, ou algumas semanas para os melhores resultados. Quanto mais tempo de coleta a partir do uso normal, melhor — assim dá para identificar picos ou padrões de uso.
Views do INFORMATION_SCHEMA
As views INFORMATION_SCHEMA já existem em cada dataset, projeto e região, mas, diferentemente do audit log sink, cada combinação de dataset e região tem seu próprio conjunto dessas tabelas, então as consultas podem precisar ser executadas várias vezes. As views INFORMATION_SCHEMA omitem algumas informações que estão nas tabelas do audit log. Os exemplos estão documentados como comentários nas queries SQL mais adiante na série, onde elas não vão se alinhar com precisão às queries do audit log sink.
O benefício das views INFORMATION_SCHEMA é que os dados já existem, mesmo que você não tenha configurado o sink.
Próximos passos
Isso encerra a primeira parte desta série e serve de base para os métodos descritos no restante dela.