¿Por qué mi primera consulta de dbt o Spark del día tarda una eternidad?

"Primera consulta lenta" significa algo completamente distinto según sea un warehouse de Snowflake suspendido despertando o un cluster de EMR terminado aprovisionando nodos nuevos desde cero.

Qué sacrifica realmente el auto-suspend

Los warehouses de Snowflake/BigQuery, y los clusters de EMR/Databricks configurados para terminar al estar inactivos, se suspenden específicamente para dejar de facturar cómputo que nadie está consultando - eso es un control de costos deliberado y real, no un descuido. El trade-off es que la siguiente consulta tras el período inactivo paga por traer ese cómputo de vuelta, en vez de correr contra algo ya caliente.

Qué tan grande es realmente el cold start

Reanudar un warehouse suspendido de Snowflake o BigQuery suele ser de un solo dígito de segundos. Un cluster de EMR o Databricks terminado es un orden de magnitud completamente distinto - minutos para aprovisionar nodos nuevos desde cero. "La primera consulta del día es lenta" significa algo muy distinto según qué capa realmente se enfrió, y la solución para una no hace nada por la otra.

Las dos soluciones reales, y su costo real

Una consulta keep-warm programada - un SELECT 1 trivial en un cron justo antes de la primera carga de trabajo real - cambia un costo de cómputo pequeño y predecible por eliminar el cold start; solo tiene sentido si ese costo es genuinamente menor que lo que ahorraba el auto-suspend. La alternativa, alargar el timeout de auto-suspend, paga un costo de inactividad mayor en general en vez de uno pequeño y dirigido.