dbt
Nível médioPor que minha primeira query do dbt ou Spark do dia demora uma eternidade?
O auto-suspend é um controle de custo real, não um bug - mas significa que a primeira query depois do tempo ocioso paga para acordar algo, e quanto depende inteiramente do que realmente dormiu.
"Primeira query lenta" significa algo completamente diferente dependendo se é um warehouse Snowflake suspenso acordando ou um cluster EMR terminado provisionando nós novos do zero.
O que o auto-suspend realmente sacrifica
Warehouses Snowflake/BigQuery, e clusters EMR/Databricks configurados para terminar quando ociosos, suspendem especificamente para parar de cobrar por computação que ninguém está consultando - isso é um controle de custo deliberado e real, não um descuido. A troca é que a próxima query depois do tempo ocioso paga para trazer essa computação de volta, em vez de rodar contra algo já quente.
Quão grande o cold start realmente é
Retomar um warehouse Snowflake ou BigQuery suspenso costuma ser segundos de um dígito só. Um cluster EMR ou Databricks terminado é uma ordem de magnitude completamente diferente - minutos para provisionar nós novos do zero. "A primeira query do dia está lenta" significa algo bem diferente dependendo de qual camada realmente esfriou, e a solução para uma não faz nada pela outra.
As duas soluções reais, e seu custo de verdade
Uma query keep-warm agendada - um SELECT 1 trivial num cron bem antes da primeira carga de trabalho real - troca um custo de computação pequeno e previsível por eliminar o cold start; só faz sentido se esse custo for genuinamente menor do que o auto-suspend estava economizando. A alternativa, alongar o timeout do auto-suspend, paga um custo de ociosidade maior em geral em vez de um pequeno e direcionado.
Veja como isso fica no seu próprio pipeline.
Envie um event log real do Spark, um run_results.json do dbt ou uma exportação de métricas do Flink e receba recomendações concretas, para aprovar antes de aplicar - não mais uma regra geral.