Snowflake Gen2 Warehouses: ¿la velocidad justifica el costo extra?

Los Gen2 warehouses aprovechan el hardware más rápido que ofrecen los proveedores de nube subyacentes (AWS, GCP). Además, el equipo de Snowflake incorporó optimizaciones de software específicas para los Gen2 warehouses que se traducen en mejoras adicionales de rendimiento y costo. Casi todas las consultas se verán beneficiadas por las mejoras de hardware, pero ciertos workloads ganarán aún más gracias a las optimizaciones de software.

Por ahora, los Gen2 Warehouses tienen disponibilidad limitada, aunque esperamos que se liberen en más regiones muy pronto. Consulta aquí si Gen2 ya está disponible en tu región.

Mejoras de hardware

Los Gen2 virtual warehouses de Snowflake corren sobre la infraestructura de cómputo de tu proveedor de nube, como instancias EC2 o máquinas virtuales. Con el tiempo, esos proveedores van actualizando sus instancias con hardware más nuevo. AWS, por ejemplo, lanzó hace poco los procesadores Graviton4 basados en ARM. Si bien Snowflake no revela el hardware exacto que usa, es razonable asumir que aprovecha las opciones más recientes de cada proveedor. Estas mejoras incluyen lecturas más rápidas en disco local, mayor rendimiento de CPU y más throughput de red, lo que se traduce en mejor desempeño de consultas desde el primer momento.

Mejoras de software

Snowflake también reportó varias optimizaciones de software específicas que aceleran los workloads de DML (es decir, jobs que hacen merge o update de datos en tablas), además de ciertas consultas complejas.

Como veremos en los resultados de nuestro análisis, estas mejoras de software son probablemente las responsables de algunas de las mayores ganancias de rendimiento.

Como los Gen2 warehouses corren sobre hardware más nuevo y potente, son más caros. En la tabla de Precios a continuación (fuente) se ve que los Gen2 warehouses cuestan 35% más en AWS y GCP, y 25% más en Azure.

Esto tiene implicaciones importantes que conviene considerar antes de hacer el cambio. Aunque las consultas corran más rápido, hay que asegurarse de que la reducción del tiempo de cómputo compense el aumento de costo. Para complicar más el panorama, la mayoría configura sus warehouses para que se suspendan tras 60 segundos de inactividad. Eso significa que pagarás el costo más alto durante ese tiempo muerto, y conviene incluirlo en tu análisis.

Cálculo del punto de equilibrio

Como las consultas corren más rápido en Gen2 y se factura un precio más alto por menos tiempo, el cálculo del punto de equilibrio es:

Reducción de tiempo requerida (%) = 1 - (1 / Factor de aumento de precio)

En Azure se requiere una reducción del 20% en el tiempo activo del warehouse para llegar al punto de equilibrio.

• 1 - (1 / 1.25) = 0.20

En AWS se requiere una reducción del 25.9% en el tiempo activo del warehouse para llegar al punto de equilibrio.

• 1 - (1 / 1.35) = 0.259

El benchmarking lo hice en AWS. Por lo tanto, para mantenernos neutrales en costo, el rendimiento tiene que mejorar al menos un 25.9%.

No olvides el período mínimo de facturación de 1 minuto

Ten presente que cada vez que un warehouse se reanuda, se cobran 60 segundos. Así que si una consulta pasa de 30 segundos en Gen1 a 15 segundos en Gen2, no estás ahorrando: estás pagando más. Tú decides si la mejora de rendimiento vale el costo adicional.

El escenario ideal de ahorro: workloads que corren más de 1 minuto Y ahorran más que el porcentaje del punto de equilibrio mencionado arriba.

La tabla a continuación resume este concepto.

Crear un nuevo Gen2 warehouse, o convertir uno existente a Gen2, es muy sencillo: basta con pasar el parámetro resource_constraint en la sentencia create o alter. Aquí tienes un ejemplo de cada uno:

-- create new
CREATE OR REPLACE WAREHOUSE my_wh
WAREHOUSE_SIZE = MEDIUM
RESOURCE_CONSTRAINT = STANDARD_GEN_2;

-- alter existing
ALTER WAREHOUSE legacy_wh
SET RESOURCE_CONSTRAINT = STANDARD_GEN_2;

Snowflake incluye una base de datos de muestra con el dataset TCP-H, definido por el Transaction Processing Performance Council para hacer benchmarking de workloads analíticos.

En Snowflake encontrarás estos schemas dentro de la base de datos snowflake_sample_data:

• TPCH_SF1
• TPCH_SF10
• TPCH_SF100
• TPCH_SF1000

SF significa Scale Factor. SF10 es 10 veces más grande que SF1, y así sucesivamente. Probamos varios tipos de workloads sobre SF10, SF100 y SF1000.

Cubrimos tres escenarios principales de benchmarking:

1. dbt: construir un proyecto dbt compuesto íntegramente por modelos de tipo Table y tests. La idea es ver si los proyectos dbt, tan usados en Snowflake, son buenos candidatos para los Gen2 warehouses.
2. Consultas select: aquí imitamos lo que ocurriría en una herramienta de BI u otras aplicaciones de cara al usuario.
3. Workloads DML: actualizar o hacer merge de datos nuevos en Snowflake es un workload habitual de los equipos de data engineering. Probamos varios escenarios DML (updates, merges, etc.) para entender el impacto.

dbt

Setup

Hicimos un fork y actualizamos un proyecto dbt existente que trabaja con los datasets TCPH de Snowflake. Nuestro repo está aquí.

Corrimos el proyecto dbt sin restricciones contra cada dataset usando warehouses de distintos tamaños y comparamos Gen1 vs Gen2. Usamos warehouses más pequeños para datos más pequeños y más grandes para datos más grandes, para simular un escenario realista.

Cada iteración se construyó en un schema nuevo para evitar el caching y guardar los resultados de cada prueba por separado. Cada build corre 16 modelos de tabla y 43 tests de datos (dbt build --exclude tag:merge-test).

Resultados

Estos fueron los resultados:

El trabajo de este proyecto dbt corresponde aproximadamente a un 97% de consultas CTAS (modelos de tabla) y un 3% de tests dbt (consultas select simples).

A partir de esto, para los modelos de tabla de dbt en este proyecto específico, la ganancia de rendimiento no siempre alcanza para justificar el 35% adicional de costo.

También vale la pena mencionar que el warehouse 4XL Gen2 tuvo un tiempo de arranque en frío muy largo, de más de 5 minutos, mientras que el 4XL Gen1 arrancó de inmediato. Como no se cobra el tiempo de reanudación del warehouse, lo descontamos del resultado pre-arrancando el warehouse antes de ejecutar dbt. Los tiempos de aprovisionamiento del warehouse normalmente no son un problema en jobs ETL nocturnos, pero conviene tenerlo en mente.

Sentencias select simples

Corrimos una muestra de consultas select sobre los datasets TPCH para simular lo que pasaría en una herramienta de BI u otras aplicaciones de cara al usuario. Las consultas exactas están enlazadas en la tabla. Estos fueron los resultados:

La consulta "Select, Aggreage" se encuentra aquí.

La consulta "Select, join, aggregate" se encuentra aquí.

Estas sentencias select muestran ganancias enormes de rendimiento y todas ahorran dinero en Gen2 medidas por segundo. Hay que considerar que, como estas consultas de cara al usuario deben ser rápidas, nos topamos con el matiz del período mínimo de facturación de Snowflake. Si las consultas corren menos de 60 segundos y/o el warehouse queda inactivo por períodos largos (algo común en herramientas de BI), sigue siendo recomendable Gen1, a menos que tu prioridad sea la velocidad pura y puedas absorber el costo extra.

También vale mencionar que los Gen2 warehouses abren la puerta a reducir el tamaño del warehouse. Por ejemplo, si los tiempos de consulta se reducen a la mitad con Gen2, pero los costos suben porque el tiempo inactivo se vuelve más caro, podrías bajar el tamaño del warehouse a la mitad, mantener el mismo rendimiento a menor costo y lograr ahorros significativos.

DML: Update de tablas grandes

Los updates de esta sección son todos updates simples del tipo update table <tbl> set column <col> = value. Cabe destacar que, aunque se actualice una sola columna, Snowflake tiene que reescribir toda la micro-partición de esa fila. Así que, en la práctica, estos dos comandos requieren la misma cantidad de "trabajo" por parte de Snowflake:

update orders_table set customer_id=5 where order_id=1;
update orders_table set customer_id=5, amount=22.05, order_date='2025-05-01',
<many columns>
where order_id=1;

Aquí corrimos tres escenarios:

• Un update sin cláusula where sobre 6 mil millones de filas.
• Update selectivo sobre la misma tabla, donde solo se actualizan 2.4 millones de filas (0.04% de la tabla).
• Update de una sola fila.
• Las sentencias SQL se encuentran aquí.

Los resultados me parecen bastante concluyentes: los Gen2 warehouses son muy buenos en updates filtrados, probablemente gracias a las optimizaciones de software específicas que liberó Snowflake.

Analicemos un poco más a fondo la consulta con -79% de delta de costo para entender por qué la mejora es tan grande.

¡La captura muestra una reducción del 99% en bytes escritos!

(0.16 GB – 16.56 GB) / 16.56 GB = -99%

DML: Consultas merge

Setup

A diferencia de los updates simples anteriores, las consultas Merge actualizan registros en el destino con base en registros de una fuente. En este caso se usa un join para actualizar los registros coincidentes e insertar los nuevos.

Las consultas merge con n% de filas actualizadas son modelos incrementales de dbt. Se corren ejecutando dbt run -s pre_merge+ y editando el filtro de row limit en la línea 22. Simulan una situación incremental real, donde solo una fracción de los datos es nueva o se actualiza. Para cambiar el % de datos actualizados, modificamos esta línea y corremos el modelo + el modelo incremental downstream.

Las tareas "Merge, todas las filas actualizadas" provienen de esta consulta, que actualiza cada fila de los datos.

Ten en cuenta que el dataset SF10 tiene unos 60 millones de filas y SF100 unos 600 millones.

Resultados

Los resultados anteriores muestran de forma concluyente que las consultas merge que actualizan una cantidad pequeña de registros tienen una mejora de rendimiento mayor que los merges sin restricciones.

La evidencia está en el perfil de la consulta, que revela varios detalles llamativos. Primero, la comunicación de red bajó significativamente del 41% al 13%. Es probable que este cambio se deba a la drástica reducción en bytes escritos: de 1.6GB a apenas 4.65MB. Esto sugiere que Snowflake puede haber mejorado la compresión u optimizado cómo se transmiten los datos por la red. Como ambas consultas solo actualizan 100 filas, esto refuerza la idea de que Gen2 incluye optimizaciones específicas para escribir datos de forma más eficiente.

Una anomalía

La única anomalía (en la penúltima fila, que muestra apenas un 1% de ahorro) es muy interesante porque Snowflake indica que se escribieron un 99.5% menos bytes. Hay varias explicaciones posibles, entre ellas throttling de S3 y velocidad de red.

Todos los resultados anteriores se muestran medidos por segundo. Pero como mencionamos antes, el tiempo inactivo después de que terminan de correr las consultas también pesa. Modelemos un escenario simple. En la tabla a continuación asumimos que Gen2 puede correr una consulta en un 50% menos de tiempo que Gen1. Es una suposición muy generosa, pero la mantenemos simple. Supongamos también un auto-suspend configurado en 60 segundos. Eso nos da:

Obviamente, mientras más tiempo corra el workload, menor es el impacto. La tabla a continuación da una idea de cómo se reduce este impacto a medida que aumenta la duración de la consulta:

Este fenómeno se puede expresar como una función:

% tiempo inactivo = [segundos de auto suspend] / ([Tiempo de consulta] + [segundos de auto suspend])

Para los clientes de Snowflake que buscan optimizar el rendimiento, el impacto del tiempo inactivo es insignificante comparado con el costo de tener a un data engineer afinando consultas y gastando más créditos en el proceso. Aun así, hay que tenerlo en cuenta.

Revisión de los resultados agregados

Revisar resultados agregados puede ser engañoso porque depende mucho de cuántas consultas corrimos en cada categoría y tamaño de warehouse. Además, oculta que consultas específicas dentro de una categoría pueden arrojar resultados muy distintos al agregado.

A pesar de eso, sigue siendo útil mirar los datos agregados porque dejan claro que el cambio en costo y rendimiento varía bastante.

Abajo encontrarás los resultados de las pruebas anteriores, consolidados para una revisión sencilla.

La lección, creo, es experimentar siempre con tu propio dataset para ver cómo se comporta Gen2 en tus casos de uso específicos. Como con la mayoría de las cosas en la nube, es muy difícil decir qué herramienta es universalmente más barata o mejor: siempre depende del caso de uso.

Pero hay algunas conclusiones clave:

• Ahora tenemos una palanca de cero esfuerzo que puedes usar para acelerar consultas y, por lo general, reducir el costo.
• Las consultas select simples estuvieron entre las de mejor desempeño en nuestras pruebas, con un ahorro del 26% en costo.
  • Eso sí: pueden terminar siendo más caras si corren sobre warehouses no saturados por menos del período mínimo de facturación.
  • Considera que puede estar perfectamente bien pagar 10% más (digamos, US$10K extra al año) por una mejora del 20% sin esfuerzo para todos tus usuarios de negocio. Piensa cuánto te tomaría hacer esas optimizaciones de rendimiento por tu cuenta.
• Gen2 es muy superior a Gen1 para updates dirigidos y consultas select simples que involucran full table scans.
• Gen2 no es necesariamente más barato para tus modelos de tabla típicos de dbt. Esto probablemente se debe a la reescritura de todas las particiones de los datos usando "create or replace table as". Sin embargo, podría ser más barato y más rápido en modelos incrementales que involucran sentencias merge.

Creo que un gran caso de uso para los Gen2 warehouses es cuando tu warehouse actual está saturado y estás pensando en subir de tamaño, digamos de Medium a Large. En lugar de pasar a Large, donde los créditos cuestan 100% más, prueba subir a Gen2 Medium y paga solo 35% más por cada crédito. En lo personal, estoy empezando a pensar en Gen2 como medio escalón entre cada tamaño de warehouse.

• El ahorro total fue del 2%, pero está fuertemente sesgado por los dos workloads más grandes.
• Excluyendo a los dos mayores consumidores de créditos, el ahorro total es del 7%.

Al comentar nuestros resultados con alguien de Snowflake, nos dijo algo que nos resonó: "Lo único que un benchmark te dice es qué tan rápido corrió el benchmark". Hay muchos factores a considerar sobre cómo esto impactará tu workload de producción.

• Falta de concurrencia: los benchmarks corren, en su mayoría, sobre warehouses no saturados, donde la concurrencia no es un problema.
• Ruido transitorio: la misma consulta corrida bajo las mismas condiciones puede variar alrededor de un 10% hacia arriba o hacia abajo si se ejecuta en otro momento, debido a la variabilidad natural de la infraestructura de nube subyacente (problemas transitorios, throttling del servicio AWS S3, etc.).

Recomendamos correr Gen2 sobre workloads puntuales durante un período de tiempo, una semana por ejemplo, para ver el impacto real en costo en tu entorno.

En SELECT queremos construir un enfoque de benchmarking más robusto y científico. Imaginamos un escenario en el que Python ejecute la misma consulta varias veces contra el mismo dataset usando distintos warehouses. Eso nos permitirá tener un tamaño de muestra mayor, donde cada resultado individual tenga menos peso en el promedio. ¡Mantente atento!

¡Nos encantaría conocer tu experiencia con los Gen2 warehouses! Escríbenos y cuéntanos cualquier hallazgo interesante o historia de ahorro.

Jeff es Consultor de Data y Analytics con más de 15 años de experiencia automatizando insights y usando datos para controlar procesos de negocio. Desde el lado tecnológico, se especializa en Snowflake + dbt + Tableau. Desde el lado del negocio, tiene experiencia en Servicios Públicos, Ensayos Clínicos, Publishing, CPG y Manufactura. Escríbele cuando quieras a [email protected].

Ian Whitestone·Co-fundador y CEO de SELECT

Ian es Co-fundador y CEO de SELECT, una plataforma SaaS de gestión y optimización de costos para Snowflake. Antes de fundar SELECT, Ian pasó 6 años liderando equipos full stack de data science e ingeniería en Shopify y Capital One. En Shopify, lideró los esfuerzos para optimizar el data warehouse y aumentar la observabilidad de costos.