Storage Billing Model — Otimização de custos no BigQuery a nível de Organização

Tratando-se de dados, você certamente já ouviu alguma variação de “Armazenamento é barato, processamento é caro”.

De fato, dependendo do volume de dados e de onde se armazena, o custo é relativamente barato, quando comparado ao custo de processamento. No entanto, isso não quer dizer que seja necessariamente desprezível.

E não sendo desprezível, que tal reduzir ainda mais a conta?

Entra em cena o Storage Billing Model

Até o fim de 2021, o armazenamento em BigQuery era cobrado considerando bytes lógicos. Agora, existe a possibilidade de alterar o modelo de cobrança de um dataset para considerar bytes físicos. Importante notar que nada muda no armazenamento em si, apenas no modelo de precificação. As grandes diferenças entre os modelos PHISICAL e LOGICAL são:

• LOGICAL cobra por bytes de Time Travel, PHISICAL não
• PHISICAL considera os dados em formato comprimido, LOGICAL não
• Byte por byte, PHISICAL é mais caro que LOGICAL

Alterando o modelo de cobrança

Atenção: Alterar o Storage Billing Model de um dataset é uma operação irreversível!

Para realizar a alteração, basta um simples patch no dataset:

from googleapiclient import discovery

dataset_service = discovery.build("bigquery", "v2").datasets()
dataset_service.patch(projectId="project_id", datasetId="dataset_id", 
                      body={"storageBillingModel":"PHYSICAL"}).execute()

Mas, cuidado! Nem sempre vale a pena alterar o Storage Billing Model para PHISICAL , em particular quando há DMLs executados na sua tabela que alterem muitos dados, pelo alto custo com Time Travel. Esse custo pode chegar a anular os ganhos com a precificação em cima dos bytes comprimidos.

Definindo quando alterar

Para garantir que estamos tomando a melhor decisão, é necessário primeiro criar uma base com o histórico de storage de todas as tabelas, tanto lógico quanto físico.

A opção mais precisa, por enquanto, requer varrer todas as tabelas da organização.

Para cada tabela, basta fazer um request da entidade

from googleapiclient import discovery

for table in tables:
bq_service = discovery.build('bigquery', 'v2')
table_metadata = bq_service.tables().get(projectId="project_id", 
                                         datasetId="dataset_id", 
                                         tableId="table_id").execute()

E, com os dados necessários, armazená-los em algum lugar (o próprio BigQuery é um excelente candidato)

metadata_to_track = {}

metadata_to_track["numActiveLogicalBytes"] = int(table_metadata["numActiveLogicalBytes"])
metadata_to_track["numLongTermLogicalBytes"] = int(table_metadata["numLongTermLogicalBytes"])
metadata_to_track["numActivePhysicalBytes"] = int(table_metadata["numActivePhysicalBytes"])
metadata_to_track["numLongTermPhysicalBytes"] = int(table_metadata["numLongTermPhysicalBytes"])

É importante notar que o armazenamento de cada tabela pode variar durante o dia. Portanto, é recomendado agendar a varredura pelo menos duas vezes por dia. Quanto mais varreduras você fizer, mais confiante estará na sua tomada de decisão. Se sua organização for grande o suficiente, certamente existirão tabelas com padrões de atualização não-convencionais. Cabe a você determinar o quanto quer se preocupar com elas.

Agora, munido do histórico de armazenamento, é necessário obter o custo. Se sua organização possuir algum desconto, obtenha no console do Google Cloud os preços. Caso contrário, utilize a tabela de preços.

Tabela de custos de Armazenamento no BigQuery

Agora, basta definir uma regra de quando migrar um dataset para o modelo PHISICAL . Por exemplo, você pode seguir o seguinte procedimento, para cada dataset ainda no modelo LOGICAL :

1. Definir um período: por exemplo, 31 dias
2. Considerar apenas datasets que existam desde o início do período selecionado
3. Para cada varredura no período definido, estimar o custo que o dataset teria em cada modelo de cobrança
4. Alterar o modelo de cobrança para PHISICAL apenas se, em todas as as varreduras, essa for a opção mais econômica

Em diversas organizações, a alteração cuidadosa do Storage Billing Model de datasets gerou uma redução de mais de 60% no custo de armazenamento do BigQuery. E na sua? Quanto conseguiu economizar?

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. : )