HomeChef mette sotto controllo i costi di Snowflake e trasforma la cultura del costo nel team di analytics

SELECT ha offerto da subito quella visibilità sui costi e quegli insight di ottimizzazione che gli strumenti interni di HomeChef non erano in grado di garantire. Il setup ha richiesto appena 30 minuti. L'integrazione profonda con dbt e l'analisi dettagliata dei costi hanno permesso al team di individuare rapidamente le opportunità di ottimizzazione ad alto impatto sui loro oltre 1.200 modelli dbt, garantendo la stessa visibilità che prima si erano costruiti con dashboard personalizzate.

HomeChef è migrata da EMR a Snowflake cinque anni fa, utilizzandolo inizialmente per alimentare le dashboard Looker con aggiornamenti batch giornalieri di dbt, in una configurazione stabile ed efficiente sul fronte dei costi. Tutto è cambiato quando HomeChef ha iniziato a usare Snowflake per un numero crescente di workloads operativi. Da query eseguite una volta al giorno si è passati a query ogni 15 minuti. Quando si fanno tanti upsert su tabelle di churn, la spesa Snowflake può crescere molto in fretta. Da un giorno all'altro, di fatto, hanno registrato un aumento di un ordine di grandezza.

Prima di SELECT, HomeChef aveva costruito un sistema interno di monitoraggio dei costi basato sull'estrazione incrementale della cronologia delle query, sulla separazione dei warehouse per tracciare la spesa degli ambienti dbt e su dashboard Looker personalizzate. La soluzione fatta in casa funzionava per il monitoraggio di routine, ma diventava problematica quando emergevano nuove criticità. Aggiungere funzionalità significava aprire PR per inserire nuove dimensioni nelle tabelle e nuove misure nelle dashboard, mentre le analisi ad-hoc erano lente a causa della complessa struttura dei metadati di Snowflake. L'inerzia e l'attrito erano elevati. Man mano che cresceva il ventaglio di funzionalità Snowflake utilizzate, di fatto ogni volta dovevano imparare un nuovo dataset esoterico.

Quando i costi sono esplosi, HomeChef aveva bisogno di visibilità immediata sulle voci che trainavano la spesa. In appena 30 minuti sono riusciti a rendere SELECT operativo. La profonda conoscenza dell'ecosistema dbt e la visibilità completa sui costi di SELECT hanno reso la transizione fluida, eliminando la necessità di soluzioni interne.

HomeChef ha ottenuto riduzioni di costo significative affrontando innanzitutto le criticità di storage (con un risparmio del 20%) e usando poi SELECT per individuare opportunità di ottimizzazione delle performance pari a un ulteriore 40%. Con oltre 1.200 modelli dbt, individuare manualmente gli obiettivi di ottimizzazione sarebbe stato impossibile. L'analisi dei costi e gli insight sulle performance di SELECT hanno permesso al team di concentrare gli sforzi dove avrebbero avuto il massimo impatto. SELECT è stato al tempo stesso lo strumento per identificare gli obiettivi e il panopticon di monitoraggio per le ottimizzazioni delle performance.

SELECT ha trasformato l'approccio di HomeChef: dal firefighting reattivo al monitoraggio proattivo. Devin ora apre ogni giornata di lavoro con una rapida occhiata a SELECT. Si prende il caffè, dà un'occhiata alle pipe e poi controlla SELECT. Gli bastano due o tre minuti per farsi un'idea, ogni giorno, di cosa succede nel loro ambiente Snowflake. Questa routine consente di intercettare per tempo anomalie, nuovi workloads e picchi di costo prima che diventino problemi seri. Può osservare come cambia l'utilizzo nel tempo e capire se emergono nuovi casi d'uso non previsti, permettendo al team di business analytics di lavorare direttamente con quegli utenti finali.

Il cambiamento culturale forse più significativo è stato vedere gli analytics engineers iniziare a ragionare in termini di ottimizzazione già durante lo sviluppo, e non dopo il deploy. Grazie alle sessioni di pairing basate sugli insight di SELECT, l'intero team ha assimilato i principi di ottimizzazione delle query. Oggi gli analytics engineers ottimizzano le performance prima ancora di inviare le pull request. Gli AE ora anticipano: "attenzione, questa sarà costosa" e dichiarano "ho portato il runtime di questa query da X a Y prima di aprire la PR, perché sapevo che questa window function mi avrebbe massacrato". Altrettanto importante, SELECT aiuta a capire quando non ottimizzare, evitando di sprecare energie su modelli a basso impatto.