HomeChef ha domato i costi di Snowflake e reso il team di analytics più consapevole della spesa

SELECT ha fornito una visibilità immediata sui costi e insight di ottimizzazione che gli strumenti interni di HomeChef non offrivano. La configurazione ha richiesto appena 30 minuti. La profonda integrazione di SELECT con dbt e la ripartizione completa dei costi hanno permesso al team di individuare rapidamente le opportunità di ottimizzazione a maggiore impatto tra gli oltre 1.200 modelli dbt, garantendo al contempo quella visibilità che prima ottenevano solo costruendo dashboard personalizzate.

HomeChef è migrata da EMR a Snowflake cinque anni fa, utilizzandolo inizialmente per alimentare dashboard Looker con aggiornamenti batch giornalieri di dbt: una configurazione stabile ed economica. Tutto è cambiato quando HomeChef ha iniziato a usare Snowflake per un numero sempre maggiore di workloads operativi. Si è passati dall'eseguire query una volta al giorno a eseguirle ogni 15 minuti. Quando si effettuano molti upsert su tabelle di churn, la spesa su Snowflake può crescere molto rapidamente. L'azienda ha registrato un aumento di circa un ordine di grandezza praticamente da un giorno all'altro.

Prima di SELECT, HomeChef aveva costruito un monitoraggio interno dei costi basato sulla raccolta incrementale della cronologia delle query, sulla separazione dei warehouse per tracciare la spesa degli ambienti dbt e su dashboard Looker personalizzate. La soluzione interna funzionava per il monitoraggio di routine, ma diventava problematica quando emergevano nuove criticità. Aggiungere funzionalità richiedeva pull request 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 il set di funzionalità utilizzate in Snowflake si ampliava, il team si trovava di fatto a imparare ogni volta un nuovo dataset esoterico.

Quando i costi sono schizzati, HomeChef aveva bisogno di visibilità immediata su cosa stesse generando la spesa. In 30 minuti il team era operativo con SELECT. La profonda conoscenza dell'ecosistema dbt da parte di SELECT e la visibilità completa sui costi hanno reso la transizione fluida, eliminando la necessità di soluzioni sviluppate internamente.

HomeChef ha ottenuto riduzioni significative dei costi affrontando prima i problemi di storage (con un risparmio del 20%) e utilizzando poi SELECT per individuare opportunità di ottimizzazione delle performance per un ulteriore 40%. Con oltre 1.200 modelli dbt, identificare manualmente i target di ottimizzazione sarebbe stato impossibile. La ripartizione 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 individuare i target e il panopticon di monitoraggio per le ottimizzazioni delle performance.

SELECT ha trasformato l'approccio di HomeChef, passando dallo spegnere incendi in modo reattivo a un monitoraggio proattivo. Devin inizia ora ogni giornata di lavoro con una rapida revisione su SELECT. Prende il caffè, dà un'occhiata alle pipeline e poi controlla SELECT. Gli bastano due o tre minuti per farsi un'idea di cosa sta succedendo ogni giorno nel loro ambiente Snowflake. Questa routine consente di individuare tempestivamente anomalie, nuovi workloads e picchi di costo prima che diventino problemi seri. Può osservare come cambia l'utilizzo nel tempo e capire se ci sono 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 che gli analytics engineer hanno iniziato a considerare l'ottimizzazione durante lo sviluppo, anziché dopo il deployment. Attraverso sessioni di pairing basate sugli insight di SELECT, l'intero team ha appreso i principi dell'ottimizzazione delle query. Ora gli analytics engineer ottimizzano proattivamente le performance prima di inviare le pull request. Oggi gli AE anticipano con un "attenzione, questa sarà costosa" e dicono "ho ridotto il tempo di esecuzione da X a Y prima di aprire la PR, perché sapevo che questa window function mi avrebbe messo in difficoltà". Altrettanto importante, SELECT aiuta a capire quando non ottimizzare, evitando sforzi inutili su modelli a basso impatto.