TL;DR
Hoy muchas empresas usan Snowflake y Databricks en paralelo, y necesitan un solo lugar para hacer seguimiento de lo que cuesta cada una. Además, Databricks es realmente más difícil de optimizar que la mayoría de las plataformas: más servicios, más parámetros de configuración y más formas de que los costos se muevan sin una razón clara. Creamos SELECT para Databricks para darles a los equipos de datos la misma visibilidad de costos y las mismas capacidades de optimización que construimos para Snowflake.
En SELECT hemos tenido el honor de trabajar con más de 250 clientes de Snowflake. Con el tiempo, empezamos a escuchar un pedido recurrente: ¿pueden hacer esto mismo para Databricks?
Esa pregunta fue el punto de partida. Pero hubo otras dos razones que nos empujaron a construir visibilidad y optimización de costos para Databricks, y son las que más pesaron en cómo lo construimos.
El escenario multiplataforma ya es la norma
Entre las cuentas con las que trabajamos, usar Snowflake y Databricks en conjunto se volvió la norma, no la excepción. La división suele tener sentido según los workloads: Snowflake para analítica estructurada y Databricks para cómputo más pesado y ML.
Los equipos que usan ambas plataformas querían poder comparar cómo corren sus workloads en cada una y, además, hacer seguimiento del gasto total de su plataforma de datos en un solo lugar.
Databricks tiene muchos más parámetros que Snowflake
Con Snowflake, la oferta de cómputo es muy simple y fácil de usar. Los usuarios solo necesitan optimizar unos pocos parámetros de configuración en los virtual warehouses.
Databricks es otra historia. Existen múltiples opciones de cómputo y formas de ejecutar workloads (jobs compute, all purpose/interactivo, serverless SQL y más), y cada servicio tiene bastantes más opciones de configuración. El tamaño del clúster, los parámetros de auto-scaling, la selección del tipo de instancia y el uso de instancias Spot son decisiones importantes que impactan tu factura.
Más configuración significa más superficie de optimización. También significa más formas de configurar algo mal y no darte cuenta hasta que los costos ya se movieron.
Lo que sabemos con certeza es que la visibilidad tiene que venir primero. No se puede optimizar lo que no se ve. SELECT para Databricks empieza justo ahí: un desglose claro de a dónde se va cada dólar y qué hay detrás de los cambios a lo largo del tiempo.
Databricks está creciendo rápido dentro de las organizaciones
Databricks comenzó como una plataforma especializada en ML e ingeniería de datos. Hoy va mucho más allá. Cada vez más equipos ejecutan más tipos de workloads en ella, y la adopción dentro de las organizaciones se está acelerando.
La adopción acelerada genera un problema conocido: el gasto crece antes que los procesos para gestionarlo. Los equipos suman workloads, los costos suben y nadie tiene un panorama claro de qué hay detrás hasta que la factura ya es más alta de lo esperado.
Lo vimos pasar con Snowflake. Los equipos lo adoptaron rápido, los costos avanzaron más rápido que la visibilidad, y después vino el trabajo de entender y controlar el gasto. SELECT nació exactamente para ese momento. Lo mismo está pasando ahora con Databricks.
Lo que construimos
SELECT para Databricks les da a los equipos de datos atribución de costos por equipo, workspace, job y workload de consulta. Se puede rastrear cada dólar, los usuarios reciben notificaciones automáticas cuando el gasto aumenta gracias a nuestra detección de anomalías con ML, y pueden investigar la causa raíz de forma automática con nuestro Copilot de IA.
Además de una observabilidad de costos completa, los usuarios pueden reducir automáticamente su gasto en cómputo sin esfuerzo alguno con nuestra función de Automated Savings, que optimiza SQL warehouses, clústeres all-purpose y jobs compute en tiempo real, sin impacto en el rendimiento.
Si quieres verlo en acción, agenda una demo con nosotros en: select.dev/demo.