A Skyeng utilizziamo Amazon Redshift, incluso il ridimensionamento parallelo, quindi abbiamo trovato interessante questo articolo di Stefan Gromoll, fondatore di dotgo.com, per intermix.io. Dopo la traduzione, un po' della nostra esperienza da parte del data engineer Daniyar Belkhodzhaev.
consente il ridimensionamento aggiungendo nuovi nodi al cluster. La necessità di far fronte a un numero massimo di richieste può portare a un provisioning eccessivo dei nodi. Il dimensionamento della concorrenza, invece di aggiungere nuovi nodi, aumenta la potenza di calcolo secondo necessità.
La scalabilità parallela di Amazon Redshift offre ai cluster Redshift capacità aggiuntiva per gestire i picchi di richieste. Funziona spostando le richieste su nuovi cluster “paralleli” in background. Le richieste vengono instradate in base alla configurazione e alle regole WLM.
I prezzi con scalabilità parallela si basano su un modello di credito con un livello gratuito. Al di sopra dei crediti gratuiti, il pagamento si basa sul tempo in cui il Parallel Scaling Cluster elabora le richieste.
L'autore ha testato il ridimensionamento parallelo su uno dei cluster interni. In questo post parlerà dei risultati del test e fornirà suggerimenti su come iniziare.
Requisiti del cluster
Per utilizzare il dimensionamento parallelo, il cluster Amazon Redshift deve soddisfare i seguenti requisiti:
- piattaforma: EC2-VPC;
— tipo di nodo: dc2.8xlarge, ds2.8xlarge, dc2.large o ds2.xlarge;
— numero di nodi: da 2 a 32 (i cluster a nodo singolo non sono supportati).
Tipi di richiesta accettabili
La scalabilità parallela non è adatta a tutti i tipi di query. Nella prima versione elabora solo le richieste di lettura che soddisfano tre condizioni:
— Le query SELECT sono di sola lettura (sebbene siano previste più tipologie);
— la query non fa riferimento a una tabella con lo stile di ordinamento INTERLEAVED;
- La query non utilizza Amazon Redshift Spectrum per fare riferimento a tabelle esterne.
Per essere instradata al Parallel Scaling Cluster, la richiesta deve essere accodata. Inoltre, le query idonee per la coda , non verrà eseguito su cluster su scala parallela.
Le code e l'SQA richiedono una configurazione corretta . Ti consigliamo di ottimizzare prima il tuo WLM: ciò ridurrà la necessità di ridimensionamento parallelo. E questo è importante perché lo scaling parallelo è gratuito solo per un certo numero di ore. AWS afferma che il dimensionamento parallelo sarà gratuito per il 97% dei clienti, il che ci porta alla questione dei prezzi.
Costo del ridimensionamento parallelo
AWS offre un modello di credito per il dimensionamento parallelo. Ogni cluster attivo Accumula crediti ogni ora, fino a un'ora di crediti per scalabilità parallela gratuita al giorno.
Paghi solo quando l'utilizzo dei cluster di scalabilità parallela supera la quantità di crediti ricevuti.
Il costo viene calcolato in base a una tariffa on demand al secondo per un cluster parallelo utilizzato al di sopra della tariffa gratuita. Ti viene addebitata solo la durata delle tue richieste, con un addebito minimo di un minuto ogni volta che viene attivato un Parallel Scaling Cluster. La tariffa on-demand al secondo viene calcolata in base ai principi generali dei prezzi , ovvero dipende dal tipo di nodo e dal numero di nodi nel cluster.
Avvio del ridimensionamento parallelo
Il ridimensionamento parallelo viene attivato per ciascuna coda WLM. Vai alla console AWS Redshift e seleziona Gestione del carico di lavoro dal menu di navigazione a sinistra. Seleziona il gruppo di parametri WLM del tuo cluster dal seguente menu a discesa.
Vedrai una nuova colonna chiamata "Modalità di dimensionamento della concorrenza" accanto a ciascuna coda. L'impostazione predefinita è "Disabilitato". Fai clic su "Modifica" e potrai modificare le impostazioni per ciascuna coda.
Configurazione
La scalabilità parallela funziona inoltrando le richieste appropriate a nuovi cluster dedicati. I nuovi cluster hanno le stesse dimensioni (tipo e numero di nodi) del cluster principale.
Il numero predefinito di cluster utilizzati per la scalabilità parallela è uno (1), con la possibilità di configurare fino a un totale di dieci (10) cluster.
Il numero totale di cluster per la scalabilità parallela può essere impostato dal parametro max_concurrency_scaling_clusters. L'aumento del valore di questo parametro fornisce ulteriori cluster ridondanti.
Monitoraggio
Sono disponibili diversi grafici aggiuntivi nella console AWS Redshift. Il grafico Max Configured Concurrency Scaling Clusters mostra il valore di max_concurrency_scaling_clusters nel tempo.
Il numero di cluster di dimensionamento attivi viene visualizzato nell'interfaccia utente nella sezione "Attività di dimensionamento della concorrenza":
Nella scheda Query è presente una colonna che indica se la query è stata eseguita nel cluster principale o nel cluster con dimensionamento parallelo:
Indipendentemente dal fatto che una determinata query sia stata eseguita nel cluster principale o tramite un cluster di dimensionamento parallelo, viene archiviata in stl_query.concurrency_scaling_status.
Un valore pari a 1 indica che la query è stata eseguita nel cluster su scala parallela, mentre altri valori indicano che è stata eseguita nel cluster primario.
Esempio:
Le informazioni sul ridimensionamento della concorrenza vengono archiviate anche in alcune altre tabelle e viste, come SVCS_CONCURRENCY_SCALING_USAGE. Inoltre, sono presenti numerose tabelle del catalogo che memorizzano informazioni sulla scalabilità parallela.
Giudizio
Gli autori hanno iniziato il dimensionamento parallelo per una coda nel cluster interno alle 18:30:00 GMT circa del 29.03.2019/3/20. Hanno modificato il parametro max_concurrency_scaling_clusters su 30 alle 00:29.03.2019:XNUMX circa del XNUMX/XNUMX/XNUMX.
Per simulare una coda di richieste, abbiamo ridotto il numero di slot per questa coda da 15 a 5.
Di seguito è riportato un grafico della dashboard di intermix.io che mostra il numero di richieste in esecuzione e in coda dopo aver ridotto il numero di slot.
Vediamo che il tempo di attesa per le richieste in coda è aumentato, con un tempo massimo superiore a 5 minuti.
Ecco le informazioni rilevanti dalla console AWS su ciò che è accaduto durante questo periodo:
Redshift ha lanciato tre (3) cluster di scalabilità parallela come configurato. Sembra che questi cluster fossero sottoutilizzati, anche se molte richieste nel nostro cluster erano in coda.
Il grafico di utilizzo è correlato al grafico dell'attività di ridimensionamento:
Dopo alcune ore, gli autori hanno controllato la coda e sembrava che 6 richieste fossero in esecuzione su scala parallela. Abbiamo anche testato in modo casuale due richieste tramite l'interfaccia utente. Non abbiamo verificato come utilizzare questi valori quando sono attivi più cluster paralleli contemporaneamente.
risultati
La scalabilità parallela può ridurre il tempo trascorso dalle richieste in coda durante i picchi di carico.
Dai risultati del test di base è emerso che la situazione con le richieste di caricamento è parzialmente migliorata. Tuttavia, il solo dimensionamento parallelo non ha risolto tutti i problemi di concorrenza.
Ciò è dovuto alle restrizioni sui tipi di query che possono utilizzare la scalabilità parallela. Ad esempio, gli autori hanno molte tabelle con chiavi di ordinamento interleaved e la maggior parte del nostro carico di lavoro è la scrittura.
Sebbene il dimensionamento parallelo non sia una soluzione universale per la configurazione di WLM, l'utilizzo di questa funzionalità è semplice e diretto.
Pertanto, l'autore consiglia di utilizzarlo per le code WLM. Inizia con un cluster parallelo e monitora il carico di picco tramite la console per determinare se i nuovi cluster vengono utilizzati completamente.
Man mano che AWS aggiunge il supporto per ulteriori tipi di query e tabelle, il dimensionamento parallelo dovrebbe diventare gradualmente sempre più efficiente.
Commento di Daniyar Belkhodzhaev, Skyeng Data Engineer
Anche noi di Skyeng abbiamo notato immediatamente la possibilità emergente del ridimensionamento parallelo.
La funzionalità è molto interessante, soprattutto considerando che AWS stima che la maggior parte degli utenti non dovrà nemmeno pagare un extra per averla.È successo che a metà aprile abbiamo avuto un'insolita raffica di richieste al cluster Redshift. Durante questo periodo abbiamo fatto spesso ricorso al Concurrency Scaling; a volte un cluster aggiuntivo lavorava 24 ore su XNUMX senza fermarsi.
Ciò ha permesso, se non di risolvere completamente il problema delle code, almeno di rendere la situazione accettabile.
Le nostre osservazioni coincidono in gran parte con le impressioni dei ragazzi di intermix.io.
Abbiamo inoltre notato che, nonostante vi fossero richieste in attesa in coda, non tutte le richieste venivano immediatamente inoltrate al cluster parallelo. Apparentemente questo accade perché il cluster parallelo impiega ancora tempo per avviarsi. Di conseguenza, durante i picchi di carico a breve termine si formano ancora piccole code e gli allarmi corrispondenti hanno il tempo di attivarsi.
Dopo esserci sbarazzati dei carichi anomali in aprile, come previsto da AWS, siamo entrati nella modalità di utilizzo occasionale, nell'ambito della norma gratuita.
Puoi tenere traccia dei costi di dimensionamento parallelo in AWS Cost Explorer. È necessario selezionare Servizio - Redshift, Tipo di utilizzo - CS, ad esempio USW2-CS:dc2.large.Puoi leggere di più sui prezzi in russo
Fonte: habr.com