Hos Skyeng bruker vi Amazon Redshift, inkludert parallell skalering, så vi fant denne artikkelen av Stefan Gromoll, grunnlegger av dotgo.com, for intermix.io interessant. Etter oversettelsen, litt av vår erfaring fra dataingeniør Daniyar Belkhodzhaev.
tillater skalering ved å legge til nye noder til klyngen. Behovet for å takle et høyt antall forespørsler kan føre til overforsyning av noder. Samtidig skalering, i motsetning til å legge til nye noder, øker datakraften etter behov.
Amazon Redshift-parallell skalering gir Redshift-klynger ekstra kapasitet til å håndtere høye forespørselsvolumer. Det fungerer ved å flytte forespørsler til nye "parallelle" klynger i bakgrunnen. Forespørsler rutes basert på WLM-konfigurasjon og regler.
Parallell skaleringsprising er basert på en kredittmodell med et gratis nivå. Over gratis kreditter er betalingen basert på tiden Parallel Scaling Cluster behandler forespørsler.
Forfatteren testet parallell skalering på en av de interne klyngene. I dette innlegget vil han snakke om testresultatene og gi tips om hvordan du kommer i gang.
Klyngekrav
For å bruke parallell skalering må Amazon Redshift-klyngen oppfylle følgende krav:
- plattform: EC2-VPC;
— nodetype: dc2.8xlarge, ds2.8xlarge, dc2.large eller ds2.xlarge;
- antall noder: fra 2 til 32 (enkeltnodeklynger støttes ikke).
Akseptable forespørselstyper
Parallell skalering er ikke egnet for alle typer søk. I den første versjonen behandler den bare leseforespørsler som tilfredsstiller tre betingelser:
— SELECT-spørringer er skrivebeskyttet (selv om flere typer er planlagt);
— spørringen refererer ikke til en tabell med sorteringsstilen INTERLEAVED;
- Spørringen bruker ikke Amazon Redshift Spectrum for å referere til eksterne tabeller.
For å bli rutet til Parallel Scaling Cluster, må forespørselen stå i kø. I tillegg spørringer som er kvalifisert for køen , vil ikke kjøre på klynger i parallell skala.
Køer og SQA krever riktig konfigurasjon . Vi anbefaler å optimalisere WLM først – dette vil redusere behovet for parallell skalering. Og dette er viktig fordi parallell skalering kun er gratis i et visst antall timer. AWS hevder at parallell skalering vil være gratis for 97 % av kundene, noe som bringer oss til spørsmålet om prissetting.
Kostnader ved parallell skalering
AWS tilbyr en kredittmodell for parallell skalering. Hver aktive klynge Akkumulerer studiepoeng hver time, opptil én time gratis parallellskaleringspoeng per dag.
Du betaler kun når bruken av Parallel Scaling Clusters overstiger kredittbeløpet du har mottatt.
Kostnaden beregnes med en etterspørselssats per sekund for en parallellklynge som brukes over den frie satsen. Du belastes kun for varigheten av forespørslene dine, med en minimumsavgift på ett minutt hver gang en Parallell Scaling Cluster aktiveres. Etterspørselsraten per sekund beregnes basert på generelle prisprinsipper , det vil si at det avhenger av typen node og antall noder i klyngen din.
Lanserer parallell skalering
Parallell skalering utløses for hver WLM-kø. Gå til AWS Redshift-konsollen og velg Workload Management fra venstre navigasjonsmeny. Velg klyngens WLM-parametergruppe fra følgende rullegardinmeny.
Du vil se en ny kolonne kalt "Concurrency Scaling Mode" ved siden av hver kø. Standard er "Deaktivert". Klikk "Rediger" og du kan endre innstillingene for hver kø.
Konfigurasjon
Parallell skalering fungerer ved å videresende passende forespørsler til nye dedikerte klynger. Nye klynger har samme størrelse (type og antall noder) som hovedklyngen.
Standard antall klynger som brukes for parallell skalering er én (1), med muligheten til å konfigurere opptil ti (10) klynger totalt.
Det totale antallet klynger for parallell skalering kan angis av parameteren max_concurrency_scaling_clusters. Å øke verdien av denne parameteren gir ekstra redundante klynger.
overvåking
Det er flere tilleggsgrafer tilgjengelig i AWS Redshift-konsollen. Diagrammet Max Configured Concurrency Scaling Clusters viser verdien av max_concurrency_scaling_clusters over tid.
Antall aktive skaleringsklynger vises i brukergrensesnittet i delen "Samtidig skaleringsaktivitet":
I kategorien Spørringer er det en kolonne som angir om spørringen ble utført i hovedklyngen eller i den parallelle skaleringsklyngen:
Uansett om en bestemt spørring ble utført i hovedklyngen eller gjennom en parallellskaleringsklynge, lagres den i stl_query.concurrency_scaling_status.
En verdi på 1 indikerer at spørringen ble utført i den parallelle skala-klyngen, mens andre verdier indikerer at den ble utført i den primære klyngen.
Eksempel:
Samtidig skaleringsinformasjon lagres også i noen andre tabeller og visninger, for eksempel SVCS_CONCURRENCY_SCALING_USAGE. I tillegg er det en rekke katalogtabeller som lagrer informasjon om parallell skalering.
Funn
Forfatterne startet parallell skalering for én kø i den interne klyngen ca. kl. 18:30:00 GMT 29.03.2019. Endret parameteren max_concurrency_scaling_clusters til 3 ca. kl. 20:30:00 29.03.2019.
For å simulere en forespørselskø reduserte vi antallet plasser for denne køen fra 15 til 5.
Nedenfor er et intermix.io-dashborddiagram som viser antall forespørsler som kjører og står i kø etter å ha redusert antall spor.
Vi ser at ventetiden på forespørsler i køen har økt, med maksimal tid på over 5 minutter.
Her er relevant informasjon fra AWS-konsollen om hva som skjedde i løpet av denne tiden:
Redshift lanserte tre (3) parallelle skaleringsklynger som konfigurert. Det ser ut til at disse klyngene ble underutnyttet, selv om mange forespørsler i klyngen vår sto i kø.
Bruksgrafen korrelerer med skaleringsaktivitetsgrafen:
Etter noen timer sjekket forfatterne køen og det så ut som 6 forespørsler kjørte med parallell skalering. Vi testet også to forespørsler tilfeldig gjennom brukergrensesnittet. Vi har ikke sjekket hvordan du bruker disse verdiene når flere parallelle klynger er aktive samtidig.
Funn
Parallell skalering kan redusere tiden forespørsler bruker i køen under toppbelastninger.
Basert på resultatene fra basistesten viste det seg at situasjonen med lasteforespørsler har blitt delvis bedre. Parallell skalering alene løste imidlertid ikke alle samtidighetsproblemer.
Dette skyldes restriksjoner på hvilke typer spørringer som kan bruke parallell skalering. For eksempel har forfatterne mange tabeller med sammenflettede sorteringsnøkler, og det meste av arbeidsmengden vår er skriving.
Selv om parallell skalering ikke er en universell løsning for å sette opp WLM, er det enkelt og greit å bruke denne funksjonen.
Derfor anbefaler forfatteren å bruke den til WLM-køene dine. Start med en parallell klynge og overvåk toppbelastningen gjennom konsollen for å finne ut om de nye klyngene blir fullt utnyttet.
Ettersom AWS legger til støtte for flere spørringstyper og tabeller, bør parallell skalering gradvis bli mer og mer effektiv.
Kommentar fra Daniyar Belkhodzhaev, Skyeng Data Engineer
Vi i Skyeng la også umiddelbart merke til muligheten for parallell skalering.
Funksjonaliteten er veldig attraktiv, spesielt med tanke på at AWS anslår at de fleste brukere ikke engang trenger å betale ekstra for det.Det skjedde slik at i midten av april hadde vi en uvanlig mengde forespørsler til Redshift-klyngen. I denne perioden brukte vi ofte samtidighetsskalering; noen ganger jobbet en ekstra klynge 24 timer i døgnet uten å stoppe.
Dette gjorde det mulig, om ikke å fullstendig løse problemet med køer, så i det minste å gjøre situasjonen akseptabel.
Våre observasjoner sammenfaller i stor grad med inntrykkene til gutta fra intermix.io.
Vi la også merke til at selv om det var forespørsler som ventet i køen, ble ikke alle forespørsler umiddelbart videresendt til den parallelle klyngen. Tilsynelatende skjer dette fordi den parallelle klyngen fortsatt tar tid å starte. Som et resultat har vi under kortvarige toppbelastninger fortsatt små køer, og de tilsvarende alarmene rekker å utløses.
Etter å ha blitt kvitt unormale belastninger i april, gikk vi, som AWS forventet, inn i sporadisk bruksmodus - innenfor gratisnormen.
Du kan spore parallelle skaleringskostnader i AWS Cost Explorer. Du må velge Service - Redshift, Usage Type - CS, for eksempel USW2-CS:dc2.large.Du kan lese mer om priser på russisk
Kilde: www.habr.com