A HomeChef domou os custos do Snowflake e espalhou a consciência de custos pelo time de analytics

O SELECT entregou visibilidade imediata de custos e insights de otimização que as ferramentas internas da HomeChef não ofereciam. A configuração levou apenas 30 minutos. A integração profunda do SELECT com o dbt e o detalhamento completo de custos permitiram ao time identificar rapidamente oportunidades de otimização de alto impacto entre seus mais de 1.200 modelos dbt, oferecendo a visibilidade que antes só era possível com dashboards customizados.

A HomeChef migrou do EMR para o Snowflake cinco anos atrás, inicialmente usando-o para alimentar dashboards no Looker com atualizações diárias em batch via dbt, em uma configuração estável e econômica. Tudo mudou quando a HomeChef passou a usar o Snowflake para sustentar cada vez mais workloads operacionais. Saíram de queries executadas uma vez por dia para queries a cada 15 minutos. Quando se faz muitos upserts em tabelas de churn, o gasto com Snowflake sobe muito rápido. O aumento foi de praticamente uma ordem de magnitude, quase do dia para a noite.

Antes do SELECT, a HomeChef montou um monitoramento interno de custos com coleta incremental do histórico de queries, segregação de warehouses para acompanhar gastos por ambiente dbt e dashboards customizados em Looker. A solução caseira funcionava para o monitoramento de rotina, mas virava um problema quando surgiam novos cenários. Adicionar funcionalidades exigia abrir PRs com novas dimensões nas tabelas e métricas nos dashboards, e as análises ad-hoc eram lentas por causa da estrutura complexa de metadados do Snowflake. A inércia e o atrito eram altos. Conforme o conjunto de recursos que usavam dentro do Snowflake crescia, era como aprender um novo dataset esotérico a cada vez.

Quando os custos dispararam, a HomeChef precisava de visibilidade imediata sobre o que estava puxando o gasto. Em 30 minutos, já estavam rodando com o SELECT. O profundo conhecimento do SELECT sobre o ecossistema dbt e a visibilidade abrangente de custos tornaram a transição fluida, dispensando as soluções caseiras.

A HomeChef alcançou reduções expressivas de custo atacando primeiro as questões de armazenamento (com 20% de economia) e, em seguida, usando o SELECT para identificar oportunidades de otimização de performance que renderam outros 40%. Com mais de 1.200 modelos dbt, identificar manualmente os alvos de otimização seria inviável. O detalhamento de custos e os insights de performance do SELECT permitiram que o time concentrasse esforços onde teria o maior impacto. O SELECT funcionou tanto como ferramenta de identificação de alvos quanto como panóptico de monitoramento das otimizações de performance.

O SELECT mudou a postura da HomeChef: de apagar incêndios reativamente para um monitoramento proativo. Hoje o Devin começa todo dia de trabalho com uma olhada rápida no SELECT. Ele pega o café, confere os pipes e, em seguida, abre o SELECT. Em dois ou três minutos, ele já tem uma noção do que está acontecendo na conta Snowflake no dia. Essa rotina permite detectar cedo anomalias, novos workloads e picos de custo antes que virem problemas maiores. Ele consegue acompanhar mudanças de uso ao longo do tempo e identificar novos casos de uso não previstos, o que permite ao time de business analytics conversar diretamente com esses usuários finais.

Talvez a mudança cultural mais importante tenha sido os analytics engineers passarem a pensar em otimização durante o desenvolvimento, e não depois do deploy. Em sessões de pareamento usando insights do SELECT, o time como um todo aprendeu princípios de otimização de queries. Hoje, os analytics engineers já otimizam a performance proativamente antes de abrir pull requests. Os AEs agora avisam de cara: "olha, esse aqui vai ser caro", e dizem "reduzi o runtime disso de X para Y antes de abrir o PR porque sabia que essa window function ia me matar". Igualmente importante, o SELECT ajuda a decidir quando não otimizar, evitando esforço desperdiçado em modelos de baixo impacto.