Cada empresa que ejecuta Snowflake o BigQuery conoce la sensación: la factura mensual llega, es 40% más alta de lo esperado, y nadie puede explicar exactamente por qué. equipos de datos están gastando 10+ horas a la semana modificando manualmente almacenes en lugar de construir tuberías. Ido Arieli Noga, CEO y cofundador de , pasó más de 12 años viviendo dentro de este ciclo, primero gestionando entornos de datos a gran escala en el gobierno, luego como Jefe de Datos en Lightico donde vio Snowflake costos espiral de primera mano. Yuki En esta entrevista, investigaremos por qué se rompe el enfoque predeterminado para escalar la infraestructura de datos, qué están haciendo las cargas de trabajo de la era de la IA con los presupuestos de la nube y cómo la industria necesita repensar la gobernanza del coste de los datos desde el principio. Hola Ido, bienvenido a nuestra serie "Behind the Startup".Has trabajado en el gobierno, DevOps, arquitectura de datos y, finalmente, jefe de datos en Lightico. Ishan Pandey: Mi equipo estaba dedicando el 60% de su tiempo a la infraestructura: tamaño del almacén, costos de combate al fuego, ajuste de consultas que no deberían haber necesitado ajuste. Ido Arieli Noga: Yo sabía que el problema era solucionable. Yo lo había visto hecho en DevOps - empresas como Spot.io construyeron la optimización autónoma para la infraestructura en la nube y funcionó. Lo mismo no existía para las plataformas de datos. Así que contacté con Yakir Daniel, cofundador de Spot.io, le introdujo la idea aplicada a los datos, y inmediatamente lo consiguió. Esa conversación se convirtió en nuestro primer inversor y un fuerte validador. Has hablado con más de 400 equipos de datos en Snowflake, BigQuery y Databricks. Ishan Pandey: La misma frustración, independientemente de la plataforma.Los ingenieros saben que están pagando demasiado.Pueden verlo.Pero arreglarlo requiere una auditoría continua: almacén por almacén, carga de trabajo por carga de trabajo y nadie tiene ancho de banda para eso. Ido Arieli Noga: Las plataformas mismas te dan opciones limitadas.Puedes cambiar el tamaño de un almacén, pero eso es un instrumento descuidado. 
 
 La optimización real ocurre en el nivel de la consulta - cada consulta tiene diferentes requisitos de computación, diferentes patrones de concurrencia, diferentes tiempos. No se puede resolver esto moviendo un deslizador. Necesitas algo que vea cada consulta individualmente y haga la decisión de infraestructura correcta en tiempo real. La optimización real ocurre en el nivel de la consulta - cada consulta tiene diferentes requisitos de computación, diferentes patrones de concurrencia, diferentes tiempos. No se puede resolver esto moviendo un deslizador. Necesitas algo que vea cada consulta individualmente y haga la decisión de infraestructura correcta en tiempo real. Los 200+ proveedores en este espacio generalmente añaden más dashboards.La brecha es algo que actúa - continuamente, en el nivel de la consulta, sin tocar el código de usuario. Dispersión de almacenes, mal uso de ranuras, proliferación de clusters: diferentes plataformas, el mismo problema. Ishan Pandey: Provisionar es fácil. El tamaño correcto es difícil. Un equipo necesita calcular para un nuevo caso de uso, girar algo y seguir adelante.Nadie audita la utilización de docenas de recursos de forma continua - la carga de trabajo cambia cada mes de todos modos. Ido Arieli Noga: Lo vemos de forma consistente: en Snowflake, el 40% de las consultas de almacenes medianos podrían haber sido extra-pequeños. En BigQuery, las reservas de ranuras son rutinariamente 3-4 veces la demanda real. Los ingenieros no son descuidados - simplemente no es un problema que sea tratable manualmente a escala. ¿Cómo se ve una implementación típica, y dónde se corta? Ishan Pandey: Nos sentimos entre la aplicación y la plataforma de datos en el nivel de conexión. vemos cada consulta en tiempo real - tamaño, complejidad, concurrencia, patrón histórico y la enrutamos a una computadora de tamaño adecuado. Ido Arieli Noga: La velocidad de impacto proviene de cuánto espacio de cabeza existe en la mayoría de los entornos. La mayoría de las cuentas están significativamente sobreprovisionadas desde el primer día. 
 
 Angel Studios estuvo en vivo en 54 minutos con un intercambio de cordas de conexión y vio una reducción de costes del 60%. Tenable redujo costes del 33% y recuperó el 25% del tiempo de ingeniería en dos semanas. Angel Studios estuvo en vivo en 54 minutos con un intercambio de cordas de conexión y vio una reducción de costes del 60%. Tenable redujo costes del 33% y recuperó el 25% del tiempo de ingeniería en dos semanas. Donde también no funciona: equipos que ya han invertido mucho en optimización manual, cargas de trabajo altamente irregulares sin patrones estables, o entornos donde la mayor parte del coste es almacenamiento o transferencia de datos en lugar de computación. Su precio es un porcentaje de los ahorros reales - sin ahorros, sin cargo. Eso es raro en SaaS empresarial. ¿Por qué, y cómo aterriza con los CFO? Ishan Pandey: Vino de la convicción.Si el producto funciona, alinearse con el ahorro es honesto.Si no funciona para un entorno específico, no deberíamos estar cargando. Ido Arieli Noga: Con los CFO, la conversación es simple. Realizamos un piloto de 30 días sin coste alguno. Si no generamos ahorros, no hay factura. Esto elimina el riesgo de evaluación por completo. La parte más difícil suele ser la contratación - algunos equipos financieros no tienen un cubo limpio para SaaS basado en resultados. Pero una vez que lo entienden, hace que el acuerdo sea más fácil de aprobar. La experimentación con IA está creando una nueva versión del viejo problema de residuos informáticos. Ishan Pandey: Las cargas de trabajo de IA son exploratorias y a menudo abandonadas.Un equipo ejecuta un experimento, termina o se cancela, y la computadora continúa funcionando. Ido Arieli Noga: Una capa consciente de la carga de trabajo cambia el cálculo. Los equipos pueden aumentar las cargas de trabajo sin la ansiedad de costes habitual porque saben que la infraestructura se ajusta. Eso suena menor, pero elimina un verdadero punto de fricción - usted deja de preguntar "¿podemos darnos el lujo de ejecutar esto?" y comienza a preguntar "¿qué aprendemos de esto?" También da al liderazgo de datos una visibilidad real de dónde va el gasto de la IA - por equipo, tipo de carga de trabajo, resultado. Para un jefe de datos que se ocupa de facturas impredecibles e ingenieros atrapados en el trabajo de infraestructura, tres cosas a revisar esta semana, en cualquier plataforma. Ishan Pandey: Primero, la utilización de la computadora por la ventana del tiempo.La mayoría de los entornos tienen una computadora significativa en horas fuera del pico.Rápido para encontrar, rápido para arreglar. Ido Arieli Noga: Segundo, nivel de recursos vs demanda de consulta real. Treinta días de historial de consultas, agrupados por nivel de computación asignado. Si más del 30% de las consultas se ejecutan muy por debajo de la capacidad de su nivel, tiene un problema de dimensionamiento. Tercero, siempre en los recursos sin carga de trabajo activa. almacenes, aglomerados o reservas de ranuras que nunca se suspenden por completo - generalmente mal configurados o mantenidos vivos por un proceso de fondo. residuos puros, reparables rápidamente. Estás expandiendo más allá de Snowflake a BigQuery y Databricks. ¿Dónde va esta categoría? Ishan Pandey: La visión es una capa de optimización unificada en todas las principales plataformas de datos - no una herramienta Snowflake, no una herramienta de costo. Ido Arieli Noga: En este momento, ejecutar una plataforma de datos sin una capa de optimización significa confiar en los ingenieros para hacer algo que debería ser automatizado. Cinco años más tarde que se verá la misma manera de provisionar el servidor manual se ve hoy - no equivocado, simplemente innecesario. El cambio ya está ocurriendo.La infraestructura de datos es ahora la infraestructura de negocio central. ¡No te olvides de gustar y compartir la historia!

This story contains new, firsthand information uncovered by the writer.

Hot off the press! This story contains factual information about a recent event.

Between Two Computer Monitors: This story includes an interview between the writer and guest/interviewee. 

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - DATA.

2020 - Hacker Noon Contributor of the Year in DATA

Read My Stories

Este audio es producido en el idioma original de la historia!

CEO de Yuki sobre la optimización de costes de datos: por qué su Snowflake y BigQuery Bill es 40% y aumenta debido a la IA

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

State of the Noonion: A New Era For Brands and Writers

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

Liberando el poder de la IA. Una revisión sistemática de técnicas de vanguardia: resumen e introducción

¿Quieres ganar un concurso de redacción de HackerNoon? Esto es lo que recomiendan los ganadores del concurso #crypto-api

State of the Noonion: A New Era For Brands and Writers

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps