TL;DR
Molte aziende oggi utilizzano Snowflake e Databricks in parallelo e hanno bisogno di un unico punto in cui monitorare i costi di entrambe le piattaforme. Databricks, inoltre, è oggettivamente più difficile da ottimizzare rispetto alla maggior parte delle piattaforme: più servizi, più parametri di configurazione, più modi in cui i costi possono variare senza una ragione chiara. Abbiamo creato SELECT per Databricks per offrire ai team dati le stesse funzionalità di visibilità e ottimizzazione dei costi che abbiamo sviluppato per Snowflake.
In SELECT abbiamo avuto l'onore di collaborare con oltre 250 clienti Snowflake. Con il passare del tempo, abbiamo iniziato a ricevere una richiesta ricorrente: potete fare la stessa cosa anche per Databricks?
Quella domanda è stata il punto di partenza. Ma altri due fattori hanno continuato a spingerci verso la creazione di funzionalità di visibilità e ottimizzazione dei costi per Databricks, e contano ancora di più per il modo in cui le abbiamo effettivamente costruite.
Il multi-piattaforma è ormai la norma per la maggior parte dei team
Tra gli account con cui lavoriamo, utilizzare Snowflake e Databricks insieme è diventata la norma, non l'eccezione. La suddivisione di solito ha senso rispetto ai workloads: Snowflake per l'analisi su dati strutturati, Databricks per il compute più pesante e il machine learning.
I team che usano entrambe le piattaforme volevano poter confrontare l'esecuzione dei workloads sulle due piattaforme e monitorare la spesa totale della propria piattaforma dati in un unico posto.
Databricks ha molte più leve di Snowflake
Con Snowflake, l'offerta di compute è molto semplice e immediata da usare. I virtual warehouse hanno solo pochi parametri di configurazione che gli utenti devono ottimizzare.
Databricks è tutta un'altra storia. Esistono diverse opzioni di compute e modalità di esecuzione dei workloads (jobs compute, all purpose/interactive, serverless SQL e altro ancora) e ogni servizio offre molte più opzioni di configurazione. La dimensione del cluster, i parametri di auto-scaling, la scelta del tipo di istanza e l'utilizzo delle istanze Spot sono tutte decisioni significative che incidono sulla fattura.
Più configurazione significa più margine di ottimizzazione. Ma anche più modi per configurare male qualcosa e non accorgersene finché i costi non sono già cambiati.
Una cosa è certa: la visibilità deve venire prima di tutto. Non si può ottimizzare ciò che non si vede. SELECT per Databricks parte proprio da qui: una visione chiara di dove finiscono realmente i soldi e di cosa determina le variazioni nel tempo.
Databricks sta crescendo rapidamente all'interno delle organizzazioni
Databricks è nato come piattaforma specializzata per il machine learning e il data engineering, ma oggi è andato ben oltre. Sempre più team vi eseguono un numero crescente di tipologie di workloads e l'adozione all'interno delle organizzazioni sta accelerando.
Un'adozione rapida genera un problema ben noto: la spesa cresce prima dei processi necessari a gestirla. I team aggiungono workloads, i costi salgono e nessuno ha un quadro chiaro di cosa li stia determinando finché la fattura non è già più alta del previsto.
Lo abbiamo visto accadere con Snowflake. I team lo hanno adottato rapidamente, i costi sono cresciuti più in fretta della visibilità e poi è iniziato il lavoro per comprendere e controllare la spesa. SELECT è nato esattamente per quel momento. Lo stesso sta succedendo ora con Databricks.
Cosa abbiamo costruito
SELECT per Databricks offre ai team dati l'attribuzione dei costi per team, workspace, job e workload di query. Ogni singolo dollaro può essere tracciato, gli utenti possono ricevere notifiche automatiche sugli aumenti di spesa grazie al nostro rilevamento delle anomalie basato su ML e indagarne poi automaticamente la causa principale con il nostro Copilot AI.
Oltre a una ricca osservabilità dei costi, gli utenti possono ridurre automaticamente la spesa di compute senza alcuno sforzo grazie alla nostra funzionalità Automated Savings, che ottimizza in tempo reale SQL Warehouse, cluster all-purpose e jobs compute, senza alcun impatto sulle prestazioni.
Se desidera vederlo in azione, prenoti un appuntamento con noi su: select.dev/demo.