5 Lezioni apprese da Testing Databricks SQL Serverless + DBT

5 Lezioni apprese dal Testing di Databricks SQL Serverless + DBT

Abbiamo eseguito un esperimento da $12K per testare il costo e le prestazioni degli entiér senza server e dei thread concorrenti di dbt e ottenuto risultati imprevisti.

Di: Jeff Chou, Stewart Bryson

I prodotti del Data Warehouse SQL di Databricks sono un’offerta interessante per le aziende che vogliono ottimizzare le loro query SQL di produzione e i loro data warehouse. Tuttavia, man mano che l’uso aumenta, il costo e le prestazioni di questi sistemi diventano cruciali da analizzare.

In questo blog approfondiamo tecnicamente il costo e le prestazioni del loro prodotto serverless Data Warehouse SQL utilizzando il benchmark TPC-DI standard del settore. Speriamo che gli ingegneri dati e i responsabili delle piattaforme dati possano utilizzare i risultati presentati qui per prendere decisioni migliori quando si tratta di scelte infrastrutturali dei dati.

Quali sono le offerte dei Data Warehouse SQL di Databricks?

Prima di approfondire un prodotto specifico, diamo un’occhiata alle diverse opzioni disponibili oggi. Databricks attualmente offre 3 diverse opzioni di data warehouse:

• Esplorando gli algoritmi di flusso di rete canale efficientemente le informazioni
• Come le GPU dei videogiochi hanno portato all’intelligenza artificiale
• Questo articolo AI propone ‘MotionDirector’ un approccio all’intelligenza artificiale per personalizzare il movimento e l’aspetto dei video.

• SQL Classic: Data warehouse più semplice, eseguito nell’ambiente cloud del cliente
• SQL Pro: Migliorata velocità e adatto per la data science esplorativa, eseguito nell’ambiente cloud del cliente
• SQL Serverless: “Migliore” prestazione e il calcolo è completamente gestito da Databricks.

Da un punto di vista dei costi, sia la versione classica che quella Pro vengono eseguite nell’ambiente cloud dell’utente. Ciò significa che si riceveranno 2 fatture per l’utilizzo di Databricks: una per il costo puro di Databricks (DBU) e l’altra dal proprio fornitore di cloud (ad es. AWS EC2 bill).

Per comprendere realmente il confronto dei costi, analizziamo solo un esempio della suddivisione dei costi di esecuzione su un magazzino Small basato sui tipi di istanze riportate:

Nella tabella sopra, analizziamo anche il confronto dei costi on-demand rispetto ai prezzi spot. Dalla tabella si può vedere che l’opzione serverless non ha un componente cloud, poiché tutto è gestito da Databricks.

Serverless potrebbe essere conveniente in termini di costi rispetto alla versione Pro, se si utilizzano solo istanze on-demand. Tuttavia, se ci sono disponibili nodi spot a buon mercato, allora Pro potrebbe essere più conveniente. In generale, il prezzo per il serverless è abbastanza ragionevole secondo me, poiché include anche i costi cloud, anche se è comunque un prezzo “premium”.

Includiamo anche il cluster di calcolo equivalenti dei lavori, che è l’opzione meno costosa in generale. Se il costo è una preoccupazione per te, puoi eseguire anche le query SQL nei lavori di calcolo!

Vantaggi e svantaggi di Serverless

L’opzione serverless di Databricks è una piattaforma di calcolo completamente gestita. Questo è praticamente identico a come funziona Snowflake, dove tutti i dettagli di calcolo sono nascosti agli utenti. A grandi linee ci sono dei vantaggi e degli svantaggi a questo riguardo:

Vantaggi:

• Non devi pensare a istanze o configurazioni
• Il tempo di avvio è molto inferiore rispetto all’avvio di un cluster da zero (da 5 a 10 secondi secondo le nostre osservazioni)

Svantaggi:

• Le aziende potrebbero avere problemi di sicurezza con tutto il calcolo eseguito all’interno di Databricks
• Le aziende potrebbero non essere in grado di sfruttare i contratti cloud che potrebbero avere sconti speciali su istanze specifiche
• Nessuna possibilità di ottimizzare il cluster, quindi non si sa 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 quali modifiche Databricks sta implementando sotto il cofano, il che potrebbe causare problemi di stabilità.

A causa della natura intrinsecamente black box del serverless, eravamo curiosi di esplorare i vari parametri regolabili che le persone hanno ancora e il loro impatto sulle prestazioni. Quindi vediamo cosa abbiamo esplorato:

Configurazione dell’esperimento

Abbiamo cercato di adottare un approccio “pratico” a questo studio e simulare ciò che potrebbe fare un’azienda reale quando desidera eseguire un magazzino SQL. Dato che DBT è uno strumento così popolare nel moderno stack di dati, abbiamo deciso di esaminare 2 parametri per valutare e analizzare:

• Dimensione del magazzino – [‘2X-Piccolo’, ‘X-Piccolo’, ‘Piccolo’, ‘VoAGI’, ‘Grande’, ‘X-Grande’, ‘2X-Grande’, ‘3X-Grande’, ‘4X-Grande’]
• DBT Threads – [‘4’, ‘8’, ’16’, ’24’, ’32’, ’40’, ’48’]

Il motivo per cui abbiamo scelto questi due parametri è che entrambi sono “universalmente” parametri di ottimizzazione per qualsiasi carico di lavoro e entrambi influiscono sul lato di calcolo del lavoro. In particolare, i DBT threads regolano efficacemente il parallelismo del tuo lavoro mentre si sposta attraverso il tuo DAG.

Il carico di lavoro selezionato è il popolare benchmark TPC-DI, con un fattore di scala di 1000. Questo carico di lavoro è interessante perché è effettivamente un intero flusso di dati che imita i carichi di lavoro dei dati del mondo reale. Ad esempio, uno screenshot del nostro DBT DAG è qui sotto, come puoi vedere è piuttosto complicato e cambiare il numero di DBT threads potrebbe avere un impatto qui.

A proposito, Databricks ha un fantastico repository open source che ti aiuterà a configurare rapidamente il benchmark TPC-DI all’interno di Databricks. (Non l’abbiamo usato perché stiamo utilizzando DBT).

Per entrare nel dettaglio di come abbiamo eseguito l’esperimento, abbiamo utilizzato i Flussi di lavoro di Databricks con un tipo di attività dbt come “runner” per dbt CLI, e tutti i lavori sono stati eseguiti contemporaneamente; non dovrebbe esserci alcuna variazione dovuta a condizioni ambientali non note dal lato di Databricks.

Ogni lavoro ha creato un nuovo magazzino SQL e lo ha distrutto successivamente ed è stato eseguito in schemi unici nello stesso Catalogo Unity. Abbiamo utilizzato il pacchetto Elementary dbt per raccogliere i risultati di esecuzione e abbiamo eseguito un notebook Python alla fine di ogni esecuzione per raccogliere tali metriche in uno schema centralizzato.

I costi sono stati estratti tramite le tabelle di sistema di Databricks, in particolare quelle per l’Utilizzo Fatturabile.

Prova tu stesso questo esperimento e clona il repository Github qui

Risultati

Sotto sono riportati i grafici di costo e tempo di esecuzione rispetto alla dimensione del magazzino. Possiamo vedere che il tempo di esecuzione smette di scalare quando si raggiungono dimensioni di magazzino VoAGI. Dimensioni più grandi di un magazzino VoAGI non influivano praticamente sul tempo di esecuzione (o forse lo peggioravano). Questa è una tipica tendenza di scalabilità che mostra come la dimensione del cluster non sia infinita, in quanto in qualche momento l’aggiunta di più calcoli fornisce rendimenti decrescenti.

Per gli appassionati di CS, questo è solo il fondamentale principio di CS – Legge di Amdahl.

Una osservazione insolita è che il magazzino VoAGI ha superato i successivi 3 taglie più grandi (grande a 2xlarge). Abbiamo ripetuto questo particolare punto dati diverse volte e ottenuto risultati consistenti, quindi non si tratta di un caso strano. A causa della natura a scatola nera del serverless, sfortunatamente non sappiamo cosa sta succedendo sotto il cofano e non siamo in grado di dare una spiegazione.

Poiché la scalabilità si ferma a VoAGI, possiamo vedere nel grafico dei costi qui sotto che i costi iniziano a salire alle stelle dopo la dimensione del magazzino VoAGI, perché fondamentalmente stai utilizzando macchine più costose mentre il tempo di esecuzione rimane costante. Quindi, stai pagando per una potenza extra senza alcun beneficio.

Il grafico qui sotto mostra la variazione relativa del tempo di esecuzione al variare del numero di thread e delle dimensioni del magazzino. Per valori superiori alla linea orizzontale zero, il tempo di esecuzione è aumentato (cosa negativa).

I dati qui sono un po’ rumorosi, ma ci sono alcune interessanti intuizioni in base alle dimensioni del magazzino:

• 2x-small – Aumentare il numero di thread di solito faceva durare più a lungo il lavoro.
• X-small a grande – Aumentare il numero di thread di solito ha aiutato a far funzionare il lavoro circa il 10% più velocemente, anche se i guadagni erano piuttosto piatti, quindi continuare ad aumentare il numero di thread non aveva alcun valore.
• 2x-large – C’era un numero ottimale effettivo di thread, che era 24, come si può vedere nella chiara linea parabolica
• 3x-large – ha avuto un picco molto insolito nel tempo di esecuzione con un conteggio dei thread di 8, perché? Nessuna idea.

Per mettere tutto insieme in un unico grafico completo, possiamo vedere il grafico qui sotto che rappresenta il costo rispetto alla durata del lavoro totale. I diversi colori rappresentano le diverse dimensioni del magazzino, e le dimensioni delle bolle rappresentano il numero di thread DBT.

Nel grafico sopra vediamo la tendenza tipica che i magazzini più grandi portano generalmente a durate più brevi ma costi più elevati. Tuttavia, notiamo alcuni punti insoliti:

• VoAGI è il migliore – Dal punto di vista del costo e della durata, VoAGI è il magazzino migliore da scegliere
• Impatto dei thread DBT – Per i magazzini più piccoli, cambiare il numero di thread sembrava avere modificato la durata di circa +/- 10%, ma non tanto il costo. Per i magazzini più grandi, il numero di thread ha influenzato sia il costo che il tempo di esecuzione in modo piuttosto significativo.

Conclusione

In sintesi, le nostre 5 principali lezioni apprese sui prodotti Databricks SQL serverless + DBT sono:

1. Le regole empiriche sono sbagliate – Non possiamo semplicemente fare affidamento su “regole empiriche” sulla dimensione del magazzino o sul numero di thread dbt. Alcune tendenze previste esistono, ma non sono consistenti o prevedibili e dipendono interamente dal tuo carico di lavoro e dai dati.
2. Enorme varianza – Per gli stessi carichi di lavoro i costi variavano da $5 – $45, e i tempi di esecuzione da 2 minuti a 90 minuti, tutto a causa di diverse combinazioni di numero di thread e dimensione del magazzino.
3. La scalabilità serverless ha limiti – I magazzini serverless non si scalano all’infinito e alla fine i magazzini più grandi cesseranno di fornire qualsiasi accelerazione e finiranno solo per causare costi aumentati senza alcun beneficio.
4. VoAGI è fantastico ? – Abbiamo scoperto che il VoAGI Serverless SQL Warehouse ha superato molte delle dimensioni dei magazzini più grandi sia in termini di costo che di durata del lavoro per il benchmark TPC-DI. Non abbiamo idea del perché.
5. I cluster dei lavori possono essere i più economici – Se i costi sono un problema, passare semplicemente a un calcolo dei lavori standard con i notebook può essere notevolmente più economico

I risultati riportati qui rivelano che le prestazioni dei sistemi black box “serverless” possono causare alcune anomalie insolite. Poiché tutto avviene dietro le quinte di Databrick, non abbiamo idea di cosa stia succedendo. Forse tutto sta funzionando su giganteschi cluster Spark su Kubernetes, forse hanno accordi speciali con Amazon su determinate istanze? In ogni caso, la natura imprevedibile rende difficile controllare costi e prestazioni.

Poiché ogni carico di lavoro è unico in così tante dimensioni, non possiamo fare affidamento su “regole empiriche” o su costosi esperimenti che valgono solo per un carico di lavoro nel suo stato attuale. La natura più caotica dei sistemi serverless solleva la domanda se questi sistemi abbiano bisogno di un sistema di controllo a loop chiuso per tenerli a bada?

Come nota introspettiva, il modello di business del serverless è veramente convincente. Supponendo che Databricks sia una business razionale e non voglia diminuire il proprio fatturato, e che voglia ridurre i propri costi, bisogna chiedersi: “Databricks è incentivato a migliorare il calcolo sottostante?”

Il problema è questo: se rendono il serverless 2 volte più veloce, all’improvviso il loro fatturato dal serverless diminuisce del 50% – sarebbe una giornata molto brutta per Databricks. Se potessero renderlo 2 volte più veloce e poi aumentare i costi delle DBU di 2 volte per controbilanciare l’accelerazione, rimarrebbero revenue neutral (in realtà è quello che hanno fatto per Photon).

Quindi Databricks ha davvero l’incentivo a ridurre i propri costi interni mantenendo i tempi di esecuzione dei clienti invariati. Mentre questo è ottimo per Databricks, è difficile trasferire all’utente qualsiasi tecnologia di accelerazione serverless che comporti una riduzione dei costi.

Se sei interessato a saperne di più su come migliorare le tue pipeline Databricks, contatta Jeff Chou e il resto del Sync Team.

Risorse

• Prova tu stesso questo esperimento e clona il repository Github qui

Contenuti correlati

• Perché le tue pipeline di dati hanno bisogno di un controllo a loop chiuso con feedback
• Valgono la pena i cluster Databricks con istanze Photon e Graviton?
• L’autoscaling di Databricks è efficiente in termini di costi?
• Presentando Gradient – L’ottimizzazione Databricks resa facile