Abbiamo eseguito un esperimento da 12.000 dollari per testare il costo e le prestazioni dei warehouse serverless e dei thread simultanei dbt e abbiamo ottenuto risultati inaspettati.
Autore: Jeff Chou, Stewart Bryson
I prodotti SQL Warehouse di Databricks rappresentano un’offerta interessante per le aziende che desiderano semplificare la produzione di query e warehouse SQL. Tuttavia, con l’aumento dell’utilizzo, il costo e le prestazioni di questi sistemi diventano cruciali da analizzare.
In questo blog approfondiamo dal punto di vista tecnico i costi e le prestazioni del loro prodotto di storage SQL serverless utilizzando il benchmark TPC-DI standard del settore. Ci auguriamo che gli ingegneri dei dati e i gestori delle piattaforme dati possano utilizzare i risultati qui presentati per prendere decisioni migliori quando si tratta delle scelte relative all’infrastruttura dati.
Prima di immergerci in un prodotto specifico, facciamo un passo indietro e osserviamo le diverse opzioni disponibili oggi. Databricks offre attualmente 3 diverse opzioni di magazzino:
- SQL classico — Il magazzino più semplice viene eseguito nell’ambiente cloud del cliente
- SQLPro — Prestazioni migliorate e utili per la scienza dei dati esplorativa, viene eseguito all’interno dell’ambiente cloud del cliente
- SQL senza server — Prestazioni “migliori” e il calcolo è completamente gestito da Databricks.
Dal punto di vista dei costi, sia Classic che Pro vengono eseguiti all’interno dell’ambiente cloud dell’utente. Ciò significa che riceverai 2 fatture per l’utilizzo dei databricks: una è il costo puro dei databricks (DBU) e l’altra proviene dal tuo provider cloud (ad esempio la fattura AWS EC2).
Per comprendere veramente il confronto dei costi, diamo un’occhiata a un esempio di ripartizione dei costi di gestione di un piccolo magazzino in base al loro tipi di istanza segnalati:
Nella tabella sopra, esaminiamo anche il confronto dei costi tra costi on-demand e spot. Dalla tabella puoi vedere che l’opzione serverless non ha componenti cloud, perché è tutta gestita da Databricks.
Serverless potrebbe essere conveniente rispetto a Pro, se si utilizzassero tutte le istanze su richiesta. Ma se sono disponibili nodi spot economici, Pro potrebbe essere più economico. Nel complesso, il prezzo per il serverless è abbastanza ragionevole secondo me poiché include anche i costi del cloud, sebbene sia ancora un prezzo “premium”.
Abbiamo incluso anche il cluster di calcolo dei lavori equivalenti, che è l’opzione più economica su tutta la linea. Se i costi ti preoccupano, puoi eseguire query SQL anche nel calcolo dei lavori!
L’opzione serverless di Databricks è una piattaforma di calcolo completamente gestita. Questo è praticamente identico a come Fiocco di neve viene eseguito, in cui tutti i dettagli di calcolo sono nascosti agli utenti. Ad alto livello ci sono pro e contro in questo:
Professionisti:
- Non devi pensare a istanze o configurazioni
- Il tempo di avviamento è molto inferiore rispetto all’avvio di un cluster da zero (5-10 secondi dalle nostre osservazioni)
Contro:
- Le aziende potrebbero avere problemi di sicurezza con tutto il calcolo in esecuzione all’interno di Databricks
- Le aziende potrebbero non essere in grado di sfruttare i propri contratti cloud che potrebbero avere sconti speciali su istanze specifiche
- Nessuna possibilità di ottimizzare il cluster, quindi non sai se le istanze e le configurazioni selezionate da Databricks sono effettivamente adatte al tuo lavoro
- Il calcolo è una scatola nera: gli utenti non hanno idea di cosa sta succedendo o di quali modifiche Databricks sta implementando sotto il cofano, il che potrebbe rendere la stabilità un problema.
A causa della natura intrinseca della scatola nera del serverless, eravamo curiosi di esplorare i vari parametri sintonizzabili che le persone ancora hanno e il loro impatto sulle prestazioni. Quindi entriamo in ciò che abbiamo esplorato:
Abbiamo provato ad adottare un approccio “pratico” a questo studio e a simulare cosa potrebbe fare un’azienda reale quando desidera gestire un magazzino SQL. Da DBT è uno strumento così popolare nel moderno stack di dati, abbiamo deciso di esaminare 2 parametri da analizzare e valutare:
- Dimensioni del magazzino — (‘2X-Piccolo’, ‘X-Piccolo’, ‘Piccolo’, ‘Medio’, ‘Grande’, ‘X-Grande’, ‘2X-Grande’, ‘3X-Grande’, ‘4X-Grande’)
- Discussione DBTS — (‘4’, ‘8’, ’16’, ’24’, ’32’, ’40’, ’48’)
Il motivo per cui abbiamo scelto questi due è che sono entrambi parametri di ottimizzazione “universali” per qualsiasi carico di lavoro ed entrambi influiscono sul lato elaborazione del lavoro. Discussioni DBT in particolare, ottimizza in modo efficace il parallelismo del tuo lavoro mentre attraversa il tuo DAG.
Il carico di lavoro che abbiamo selezionato è quello popolare TPC-DI benchmark, con un fattore di scala pari a 1000. Questo carico di lavoro in particolare è interessante perché in realtà è un’intera pipeline che imita più carichi di lavoro di dati del mondo reale. Ad esempio, di seguito è riportato uno screenshot del nostro DAG DBT, come puoi vedere è piuttosto complicato e la modifica del numero di thread DBT potrebbe avere un impatto qui.
Come nota a margine, Databricks ha un file fantastico repository open source ciò aiuterà a configurare rapidamente il benchmark TPC-DI interamente all’interno di Databricks. (Non l’abbiamo usato poiché stiamo utilizzando DBT).
Per entrare nel dettaglio del modo in cui abbiamo condotto l’esperimento, abbiamo utilizzato Flussi di lavoro di databricks con un tipo di attività dbt come “corridore” per la CLI dbt e tutti i lavori sono stati eseguiti contemporaneamente; non dovrebbero esserci variazioni dovute a condizioni ambientali sconosciute sul lato Databricks.
Ogni lavoro ha creato un nuovo magazzino SQL e lo ha successivamente smontato ed è stato eseguito in schemi univoci nello stesso Unity Catalog. Abbiamo usato il Pacchetto dbt elementare per raccogliere i risultati dell’esecuzione ed eseguire un notebook Python alla fine di ogni esecuzione per raccogliere tali parametri in uno schema centralizzato.
I costi sono stati estratti tramite le tabelle di sistema Databricks, in particolare quelli per l’utilizzo fatturabile.
Prova tu stesso questo esperimento e clona il file Repository Github qui
Di seguito sono riportati i grafici relativi ai costi e al tempo di esecuzione rispetto alle dimensioni del magazzino. Di seguito possiamo vedere che il runtime smette di ridimensionarsi quando si ottengono magazzini di medie dimensioni. Qualunque cosa più grande di un mezzo praticamente non ha avuto alcun impatto sul tempo di esecuzione (o forse era peggio). Questa è una tipica tendenza al ridimensionamento che mostra che il ridimensionamento delle dimensioni dei cluster non è infinito, ma hanno sempre un punto in cui l’aggiunta di più elaborazione fornisce rendimenti decrescenti.
Per gli appassionati di CS là fuori, questo è solo il principio fondamentale di CS: Legge di Amdahl.
Un’osservazione insolita è che il magazzino medio ha sovraperformato le 3 taglie successive (da grande a 2xgrande). Abbiamo ripetuto questo particolare punto dati alcune volte e abbiamo ottenuto risultati coerenti, quindi non è uno strano colpo di fortuna. A causa della natura della scatola nera del serverless, purtroppo non sappiamo cosa succede dietro il cofano e non siamo in grado di fornire una spiegazione.
Poiché il ridimensionamento si ferma a livello medio, possiamo vedere nel grafico dei costi riportato di seguito che i costi iniziano a salire alle stelle dopo la dimensione media del magazzino, perché in pratica si abbandonano macchine più costose mentre il tempo di esecuzione rimane costante. Quindi, stai pagando per una potenza extra senza alcun vantaggio.
Il grafico seguente mostra la variazione relativa del runtime man mano che si cambia il numero di thread e la dimensione del warehouse. Per valori maggiori della linea orizzontale zero, il tempo di esecuzione aumenta (una cosa negativa).
I dati qui sono un po’ rumorosi, ma ci sono alcuni spunti interessanti in base alle dimensioni del magazzino:
- 2x-piccolo — L’aumento del numero di thread in genere allunga l’esecuzione del processo.
- Da X-piccolo a grande — L’aumento del numero di thread in genere aiutava a velocizzare l’esecuzione del lavoro di circa il 10%, sebbene i guadagni fossero piuttosto stabili, quindi continuare ad aumentare il numero di thread non aveva alcun valore.
- 2x-grande — C’era un numero effettivamente ottimale di thread, ovvero 24, come si vede nella chiara linea parabolica
- 3x-grande – ha avuto un picco molto insolito di runtime con un numero di thread pari a 8, perché? Nessun indizio.
Per mettere tutto insieme in un unico grafico completo, possiamo vedere il grafico qui sotto che traccia il costo rispetto alla durata del lavoro totale. I diversi colori rappresentano le diverse dimensioni del magazzino e la dimensione delle bolle corrisponde al numero di thread DBT.
Nel grafico qui sopra vediamo la tendenza tipica secondo cui magazzini più grandi in genere comportano durate più brevi ma costi più elevati. Tuttavia, individuiamo alcuni punti insoliti:
- Il mezzo è il migliore — Dal punto di vista puramente dei costi e dei tempi di esecuzione, il magazzino medio è il miglior magazzino da scegliere
- Impatto dei thread DBT — Per i magazzini più piccoli, la modifica del numero di thread sembrava aver modificato la durata di circa +/- 10%, ma non di molto il costo. Per i magazzini più grandi, il numero di thread ha avuto un impatto significativo sia sui costi che sui tempi di esecuzione.
In sintesi, le nostre 5 principali lezioni apprese sui prodotti Databricks SQL serverless + DBT sono:
- Le regole pratiche sono pessime — Non possiamo semplicemente fare affidamento su “regole pratiche” sulla dimensione del magazzino o sul numero di thread dbt. Esistono alcune tendenze previste, ma non sono coerenti o prevedibili e dipendono interamente dal carico di lavoro e dai dati.
- Enorme varianza – Per gli stessi carichi di lavoro i costi variavano da $ 5 a $ 45 e tempi di esecuzione da 2 minuti a 90 minuti, il tutto a causa delle diverse combinazioni di numero di thread e dimensioni del magazzino.
- La scalabilità serverless ha dei limiti: I magazzini serverless non sono scalabili all’infinito e alla fine i magazzini più grandi smetteranno di fornire qualsiasi accelerazione e finiranno solo per causare un aumento dei costi senza alcun beneficio.
- Medio è ottimo?— Abbiamo trovato il medio Serverless SQL Warehouse ha sovraperformato molti dei magazzini di dimensioni maggiori sia in termini di costi che di durata del lavoro per il benchmark TPC-DI. Non abbiamo idea del perché.
- I cluster di lavoro potrebbero essere più economici — Se i costi rappresentano un problema, il passaggio ai soli lavori standard elaborati con i notebook potrebbe essere sostanzialmente più economico
I risultati qui riportati rivelano che le prestazioni dei sistemi “serverless” a scatola nera possono comportare alcune anomalie insolite. Dato che è tutto dietro le mura di Databrick, non abbiamo idea di cosa stia succedendo. Forse è tutto in esecuzione su giganteschi cluster Spark su Kubernetes, forse hanno accordi speciali con Amazon su determinate istanze? In ogni caso, la natura imprevedibile rende complicato il controllo dei costi e delle prestazioni.
Poiché ogni carico di lavoro è unico in così tante dimensioni, non possiamo fare affidamento su “regole pratiche” o su esperimenti costosi che valgono solo per un carico di lavoro nel suo stato attuale. La natura più caotica del sistema serverless fa sorgere la domanda se questi sistemi necessitino di a sistema di controllo a circuito chiuso per tenerli a bada?
Come nota introspettiva: il modello di business del serverless è davvero avvincente. Supponendo che Databricks sia un’azienda razionale e non voglia diminuire le proprie entrate e voglia ridurre i costi, è necessario porsi la domanda: “Databricks è incentivato a migliorare il calcolo dietro il cofano?”
Il problema è questo: se rendono il serverless 2 volte più veloce, all’improvviso le loro entrate dal serverless diminuiscono del 50%: è una brutta giornata per Databricks. Se riuscissero a renderlo 2 volte più veloce e poi aumentare i costi DBU di 2 volte per contrastare l’accelerazione, rimarrebbero neutrali in termini di entrate (questo è ciò che hanno fatto per Fotone In realtà).
Pertanto Databricks è davvero incentivato a ridurre i costi interni mantenendo i tempi di esecuzione dei clienti più o meno gli stessi. Anche se questo è ottimo per Databricks, è difficile trasmettere all’utente qualsiasi tecnologia di accelerazione serverless che si traduca in una riduzione dei costi.
Sei interessato a saperne di più su come migliorare le pipeline Databricks? Raggiungere Jeff Chou e il resto del Sincronizza squadra.
Fonte: towardsdatascience.com
