Realizamos un experimento de 12.000 dólares para probar el costo y el rendimiento de los almacenes sin servidor y los subprocesos simultáneos de dbt, y obtuvimos resultados inesperados.

Por: Jeff Chou, Stewart Bryson

Los productos de almacén SQL de Databricks son una oferta atractiva para las empresas que buscan optimizar sus almacenes y consultas SQL de producción. Sin embargo, a medida que aumenta el uso, el análisis del costo y el rendimiento de estos sistemas se vuelve crucial.

En este blog, profundizamos técnicamente en el costo y el rendimiento de su producto de almacén SQL sin servidor mediante la utilización del punto de referencia TPC-DI estándar de la industria. Esperamos que los ingenieros de datos y los administradores de plataformas de datos puedan utilizar los resultados presentados aquí para tomar mejores decisiones en lo que respecta a sus opciones de infraestructura de datos.

Antes de sumergirnos en un producto específico, demos un paso atrás y veamos las diferentes opciones disponibles en la actualidad. Databricks ofrece actualmente 3 opciones diferentes de almacén:

• SQL clásico — El almacén más básico, se ejecuta dentro del entorno de nube del cliente.
• SQLPro — Rendimiento mejorado y bueno para la ciencia de datos exploratoria, se ejecuta dentro del entorno de nube del cliente
• SQL sin servidor – «Mejor» rendimiento y Databricks administra completamente el proceso.

Desde una perspectiva de costos, tanto el clásico como el profesional se ejecutan dentro del entorno de nube del usuario. Lo que esto significa es que recibirá 2 facturas por el uso de sus databricks: una es su costo puro de Databricks (DBU) y la otra es de su proveedor de nube (por ejemplo, la factura de AWS EC2).

Para comprender realmente la comparación de costos, veamos un ejemplo de desglose de costos de funcionamiento en un almacén pequeño en función de su tipos de instancia reportados:

En la tabla anterior, también analizamos la comparación de costos entre los costos bajo demanda y los costos al contado. Puede ver en la tabla que la opción sin servidor no tiene ningún componente de nube, porque todo está administrado por Databricks.

La tecnología sin servidor podría ser rentable en comparación con la versión profesional, si utilizara todas las instancias bajo demanda. Pero si hay nodos spot baratos disponibles, entonces Pro puede ser más barato. En general, en mi opinión, el precio de la versión sin servidor es bastante razonable, ya que también incluye los costos de la nube, aunque sigue siendo un precio «premium».

También incluimos el clúster de computación de trabajos equivalente, que es la opción más barata en todos los ámbitos. Si le preocupa el costo, ¡también puede ejecutar consultas SQL en el cálculo de trabajos!

La opción sin servidor de Databricks es una plataforma informática totalmente administrada. Esto es prácticamente idéntico a cómo Copo de nieve se ejecuta, donde todos los detalles informáticos están ocultos para los usuarios. A alto nivel, esto tiene ventajas y desventajas:

Ventajas:

• No tienes que pensar en instancias o configuraciones.
• El tiempo de puesta en marcha es mucho menor que el de iniciar un clúster desde cero (entre 5 y 10 segundos según nuestras observaciones).

Contras:

• Las empresas pueden tener problemas de seguridad con toda la computación que se ejecuta dentro de Databricks
• Es posible que las empresas no puedan aprovechar sus contratos de nube, que pueden tener descuentos especiales en instancias específicas.
• No hay capacidad para optimizar el clúster, por lo que no sabe si las instancias y configuraciones seleccionadas por Databricks son realmente buenas para su trabajo.
• El cálculo es una caja negra: los usuarios no tienen idea de lo que está sucediendo o qué cambios está implementando Databricks bajo el capó, lo que puede hacer que la estabilidad sea un problema.

Debido a la naturaleza inherente de la caja negra de la tecnología sin servidor, teníamos curiosidad por explorar los diversos parámetros ajustables que las personas todavía tienen y su impacto en el rendimiento. Así que vayamos a lo que exploramos:

Intentamos adoptar un enfoque «práctico» para este estudio y simular lo que podría hacer una empresa real cuando quisiera ejecutar un almacén SQL. Desde DBT es una herramienta tan popular en la pila de datos moderna, decidimos observar 2 parámetros para barrer y evaluar:

• Tamaño del almacén — [‘2X-Small’, ‘X-Small’, ‘Small’, ‘Medium’, ‘Large’, ‘X-Large’, ‘2X-Large’, ‘3X-Large’, ‘4X-Large’]
• Hilo DBTs — [‘4’, ‘8’, ‘16’, ‘24’, ‘32’, ‘40’, ‘48’]

La razón por la que elegimos estos dos es que ambos son parámetros de ajuste «universales» para cualquier carga de trabajo y ambos impactan el lado informático del trabajo. Hilos DBT en particular, ajuste de manera efectiva el paralelismo de su trabajo a medida que se ejecuta a través de su DAG.

La carga de trabajo que seleccionamos es la popular. TPC-DI punto de referencia, con un factor de escala de 1000. Esta carga de trabajo en particular es interesante porque en realidad es un proceso completo que imita más cargas de trabajo de datos del mundo real. Por ejemplo, a continuación se muestra una captura de pantalla de nuestro DBT DAG, como puede ver, es bastante complicado y cambiar la cantidad de subprocesos DBT podría tener un impacto aquí.

Como nota al margen, Databricks tiene una fantástico repositorio de código abierto eso ayudará a configurar rápidamente el punto de referencia TPC-DI dentro de Databricks por completo. (No usamos esto porque estamos ejecutando DBT).

Para profundizar en cómo ejecutamos el experimento, utilizamos Flujos de trabajo de ladrillos de datos con un tipo de tarea de dbt como «ejecutor» para la CLI de dbt, y todos los trabajos se ejecutaron simultáneamente; no debería haber ninguna variación debido a condiciones ambientales desconocidas en el lado de Databricks.

Cada trabajo creó un nuevo almacén SQL y luego lo derribó, y se ejecutó en esquemas únicos en el mismo catálogo de Unity. Usamos el Paquete dbt elemental para recopilar los resultados de la ejecución y ejecutó un cuaderno de Python al final de cada ejecución para recopilar esas métricas en un esquema centralizado.

Los costos se extrajeron a través de las tablas del sistema Databricks, específicamente aquellos para el uso facturable.

Pruebe este experimento usted mismo y clone el Repositorio de Github aquí

A continuación se muestran los gráficos de costo y tiempo de ejecución frente al tamaño del almacén. Podemos ver a continuación que el tiempo de ejecución deja de escalar cuando se obtienen almacenes de tamaño mediano. Cualquier cosa más grande que un medio prácticamente no tuvo impacto en el tiempo de ejecución (o tal vez fue peor). Esta es una tendencia de escala típica que muestra que el tamaño del clúster de escala no es infinito, siempre tienen algún punto en el que agregar más computación proporciona rendimientos decrecientes.

Para los entusiastas de la informática, este es solo el principio fundamental de la informática: Ley Amdahls.

Una observación inusual es que el almacén mediano superó a los siguientes 3 tamaños superiores (de grande a 2xgrande). Repetimos este dato en particular varias veces y obtuvimos resultados consistentes, por lo que no es una casualidad extraña. Debido a la naturaleza de caja negra de la tecnología sin servidor, lamentablemente no sabemos qué sucede bajo el capó y no podemos dar una explicación.

Debido a que el escalamiento se detiene en el tamaño medio, podemos ver en el gráfico de costos a continuación que los costos comienzan a dispararse después del tamaño de almacén mediano, porque básicamente estás lanzando máquinas más caras mientras el tiempo de ejecución permanece constante. Por lo tanto, está pagando por caballos de fuerza adicionales sin ningún beneficio.

El siguiente gráfico muestra el cambio relativo en el tiempo de ejecución a medida que cambiamos la cantidad de subprocesos y el tamaño del almacén. Para valores mayores que la línea horizontal cero, el tiempo de ejecución aumentó (algo malo).

Los datos aquí son un poco ruidosos, pero hay algunas ideas interesantes basadas en el tamaño del almacén:

• 2x-pequeño — Aumentar el número de subprocesos normalmente hacía que el trabajo durara más.
• X-pequeño a grande — Aumentar el número de subprocesos generalmente ayudaba a que el trabajo se ejecutara aproximadamente un 10 % más rápido, aunque las ganancias fueron bastante planas, por lo que seguir aumentando el número de subprocesos no tenía ningún valor.
• 2x-grande — Había un número óptimo real de subprocesos, que era 24, como se ve en la línea parabólica clara
• 3x-grande — tuvo un pico muy inusual en el tiempo de ejecución con un número de subprocesos de 8, ¿por qué? Ninguna pista.

Para reunir todo en un gráfico completo, podemos ver el gráfico a continuación que muestra el costo frente a la duración del trabajo total. Los diferentes colores representan los diferentes tamaños de almacén y el tamaño de las burbujas es la cantidad de hilos DBT.

En el gráfico anterior vemos la tendencia típica de que los almacenes más grandes suelen dar lugar a duraciones más cortas pero a costes más elevados. Sin embargo, detectamos algunos puntos inusuales:

• Medio es lo mejor — Desde una perspectiva puramente de costos y tiempo de ejecución, el almacén medio es el mejor para elegir
• Impacto de los hilos DBT — Para los almacenes más pequeños, cambiar el número de subprocesos parecía haber cambiado la duración en aproximadamente +/- 10%, pero no mucho el costo. Para los almacenes más grandes, la cantidad de subprocesos afectó significativamente tanto al costo como al tiempo de ejecución.

En resumen, nuestras cinco principales lecciones aprendidas sobre los productos Databricks SQL serverless + DBT son:

1. Las reglas generales son malas — No podemos simplemente confiar en “reglas generales” sobre el tamaño del almacén o el número de subprocesos dbt. Existen algunas tendencias esperadas, pero no son consistentes ni predecibles y dependen completamente de su carga de trabajo y sus datos.
2. Gran variación – Para exactamente las mismas cargas de trabajo, los costos oscilaron entre $ 5 y $ 45 y los tiempos de ejecución de 2 minutos a 90 minutos, todo debido a diferentes combinaciones de cantidad de subprocesos y tamaño del almacén.
3. El escalado sin servidor tiene límites: Los almacenes sin servidor no se escalan infinitamente y, con el tiempo, los almacenes más grandes dejarán de proporcionar velocidad y solo terminarán provocando mayores costos sin ningún beneficio.
4. ¿El medio es genial?—Encontramos el Medio Serverless SQL Warehouse superó a muchos de los tamaños de almacén más grandes tanto en costo como en duración del trabajo para el punto de referencia TPC-DI. No tenemos idea de por qué.
5. Los grupos de empleo pueden ser más baratos — Si los costos son una preocupación, cambiar a tareas estándar de computación con computadoras portátiles puede ser sustancialmente más económico.

Los resultados aquí presentados revelan que el rendimiento de los sistemas «sin servidor» de caja negra puede provocar algunas anomalías inusuales. Como todo está detrás de los muros de Databrick, no tenemos idea de lo que está sucediendo. ¿Quizás todo se esté ejecutando en clústeres gigantes de Spark en Kubernetes, tal vez tengan ofertas especiales con Amazon en ciertos casos? De cualquier manera, la naturaleza impredecible dificulta el control de costos y desempeño.

Debido a que cada carga de trabajo es única en tantas dimensiones, no podemos confiar en “reglas generales” ni en experimentos costosos que solo son válidos para una carga de trabajo en su estado actual. La naturaleza más caótica de los sistemas sin servidor plantea la pregunta de si estos sistemas necesitan una sistema de control de circuito cerrado para mantenerlos a raya?

Como nota introspectiva, el modelo de negocio sin servidor es realmente convincente. Suponiendo que Databricks es un negocio racional y no quiere disminuir sus ingresos, y quiere reducir sus costos, uno debe hacerse la pregunta: «¿Está Databricks incentivado a mejorar la computación interna?»

El problema es este: si hacen que la tecnología sin servidor sea 2 veces más rápida, entonces, de repente, sus ingresos por esta tecnología caen en un 50%; ese es un muy mal día para Databricks. Si pudieran hacerlo 2 veces más rápido y luego aumentar los costos de DBU 2 veces para contrarrestar la aceleración, entonces permanecerían neutrales en cuanto a ingresos (esto es lo que hicieron para Fotón de hecho).

Por lo tanto, Databricks está realmente incentivado a reducir sus costos internos y al mismo tiempo mantener los tiempos de ejecución de los clientes más o menos iguales. Si bien esto es excelente para Databricks, es difícil transmitir al usuario cualquier tecnología de aceleración sin servidor que resulte en una reducción de costos.

¿Está interesado en obtener más información sobre cómo mejorar sus canalizaciones de Databricks? Llegar a Jeff Chou y el resto del Equipo de sincronización.