Agente de FinOps open-source ataca o desperdício em consultas SQL no BigQuery

O FinOps em questão é o BigQuery FinOps Agent (BQ FinOps Agent), um sistema multiagente open-source para otimizar consultas SQL no BigQuery. O artigo que o descreve é um texto de blog, escrito por quem desenvolveu a ferramenta, e não uma documentação oficial do projeto. A premissa do autor é que o custo alto quase sempre vem dos usuários: poucas queries mal escritas podem processar centenas de gigabytes, e treinamento e documentação dificilmente fazem dezenas ou centenas de pessoas seguirem boas práticas.

O fluxo tem etapas definidas. O Input Agent separa a query do contexto opcional informado pelo usuário. O Metadata Agent lista as tabelas referenciadas e coleta esquema, particionamento, chaves primárias e estrangeiras, colunas de clustering, número de linhas e bytes, tipo de tabela e a query por trás de views e views materializadas. Ele também mede o custo base em bytes processados, em geral só com dry-run, sem faturar bytes. Depois o agente procura antipadrões, como SELECT * e falta de filtro de partição, e reescreve a query com base nos metadados e em recomendações do Google. A validação compara bytes processados e esquema de saída entre a versão original e a nova. Se houver erro de execução ou esquema diferente, a query volta ao agente otimizador, que pode revisar até três vezes. No fim, o usuário recebe um relatório com a redução de bytes, a nova query, as mudanças aplicadas e avisos.

No teste do autor, uma query sobre o dataset público de corridas de táxi (receita por região de embarque e forma de pagamento) processava quase 14 GB. O assistente Gemini do próprio editor do BigQuery, após várias tentativas e com prompt detalhado, chegou a uma query de 6,4 GB. O artigo não informa aqui o resultado numérico do agente no mesmo teste. A ferramenta foi feita em Python com o Agent Development Kit (ADK) e pode ser implantada no GCP e no Gemini Enterprise. Instalação e uso ficam em um repositório no GitHub, que o material não identifica com precisão. Como limitação, os resultados vêm de um teste simples feito pelo próprio autor, sem avaliação independente.

Para quem opera BigQuery com muitos analistas, a ideia de validar a economia com dry-run e conferir o esquema antes de entregar a query ataca o ponto fraco dos assistentes genéricos: sugestões que quebram ou não reduzem bytes. Vale tratar como prova de conceito. A query do artigo para listar as consultas mais caras do projeto é um bom ponto de partida para medir o ganho no seu ambiente antes de adotar.