TL;DR
Muitas empresas hoje usam Snowflake e Databricks lado a lado e precisam de um único lugar para acompanhar o custo das duas plataformas. O Databricks também é, de fato, mais difícil de otimizar do que a maioria das plataformas. Mais serviços, mais parâmetros de configuração, mais maneiras de os custos mudarem sem um motivo claro. Criamos o SELECT para Databricks para dar aos times de dados a mesma visibilidade de custos e os mesmos recursos de otimização que construímos para o Snowflake.
Na SELECT, tivemos a honra de trabalhar com mais de 250 clientes de Snowflake. Com o tempo, começamos a ouvir um pedido recorrente: vocês conseguem fazer isso para o Databricks também?
Essa pergunta foi o ponto de partida. Mas outros dois fatores continuaram nos empurrando na direção de construir visibilidade de custos e otimização para o Databricks — e eles pesam ainda mais na forma como de fato construímos o produto.
Multiplataforma é a realidade da maioria dos times hoje
Entre as contas com que trabalhamos, rodar Snowflake e Databricks juntos virou regra, não exceção. A divisão geralmente faz sentido para os workloads: Snowflake para análises estruturadas, Databricks para compute mais pesado e trabalho de ML.
Os times que usam as duas plataformas queriam comparar a execução de workloads em ambas e também acompanhar o gasto total da plataforma de dados em um só lugar.
O Databricks tem muito mais parâmetros que o Snowflake
No Snowflake, a oferta de compute é muito simples e fácil de usar. Há só alguns parâmetros de configuração nos virtual warehouses que os usuários precisam otimizar.
O Databricks é uma história completamente diferente. Existem várias opções de compute e formas de rodar workloads (jobs compute, all purpose/interactive, serverless SQL, entre outras), e cada serviço tem muito mais opções de configuração. Tamanho do cluster, parâmetros de auto-scaling, escolha do tipo de instância e uso de instâncias Spot são decisões importantes que afetam sua fatura.
Mais configuração significa mais superfície de otimização. Também significa mais formas de configurar algo errado e só perceber quando os custos já mudaram.
O que sabemos com certeza é que a visibilidade precisa vir primeiro. Não dá para ajustar o que você não enxerga. O SELECT para Databricks começa por aí: um detalhamento claro de para onde o dinheiro está indo de verdade e o que está causando as mudanças ao longo do tempo.
O Databricks está crescendo rápido dentro das organizações
O Databricks começou como uma plataforma especializada em ML e engenharia de dados. Já passou muito desse ponto. Mais times estão rodando mais tipos de workloads nele, e a adoção dentro das organizações está acelerando.
Adoção rápida cria um problema conhecido. O gasto cresce antes dos processos para gerenciá-lo. Os times adicionam workloads, os custos sobem e ninguém tem uma visão clara do que está por trás disso até a fatura já estar mais alta do que o esperado.
Vimos isso acontecer com o Snowflake. Os times adotaram a plataforma rapidamente, os custos cresceram mais rápido que a visibilidade e só então começou o trabalho de entender e controlar o gasto. O SELECT foi criado exatamente para esse momento. A mesma coisa está acontecendo agora com o Databricks.
O que construímos
O SELECT para Databricks oferece aos times de dados atribuição de custos por time, workspace, job e workload de query. Cada dólar pode ser rastreado, os usuários recebem notificações automáticas de aumentos de gasto por meio da nossa detecção de anomalias com ML e, em seguida, podem investigar automaticamente a causa raiz com nosso Copilot de IA.
Além de uma observabilidade de custos completa, os usuários podem reduzir automaticamente o gasto com compute, sem nenhum esforço, com nosso recurso de Automated Savings, que otimiza SQL warehouses, clusters all-purpose e jobs compute em tempo real, sem impacto na performance.
Quer ver na prática? Agende um horário com a gente em: select.dev/demo.