Hos Skyeng bruger vi Amazon Redshift, inklusive parallel skalering, så vi fandt denne artikel af Stefan Gromoll, grundlægger af dotgo.com, til intermix.io interessant. Efter oversættelsen, lidt af vores erfaring fra dataingeniør Daniyar Belkhodzhaev.
tillader skalering ved at tilføje nye noder til klyngen. Behovet for at klare et spidsbelastningsantal af anmodninger kan føre til overforsyning af noder. Samtidig skalering, i modsætning til at tilføje nye noder, øger computerkraften efter behov.
Amazon Redshift parallel skalering giver Redshift-klynger ekstra kapacitet til at håndtere spidsbelastningsvolumener. Det fungerer ved at flytte anmodninger til nye "parallelle" klynger i baggrunden. Anmodninger dirigeres baseret på WLM-konfiguration og regler.
Parallel skaleringsprissætning er baseret på en kreditmodel med et gratis niveau. Over gratis kreditter er betalingen baseret på det tidspunkt, hvor Parallel Scaling Cluster behandler anmodninger.
Forfatteren testede parallel skalering på en af de interne klynger. I dette indlæg vil han fortælle om testresultaterne og give tips til, hvordan du kommer i gang.
Klyngekrav
For at bruge parallel skalering skal din Amazon Redshift-klynge opfylde følgende krav:
- platform: EC2-VPC;
— node type: dc2.8xlarge, ds2.8xlarge, dc2.large eller ds2.xlarge;
— antal knudepunkter: fra 2 til 32 (enkelt node-klynger understøttes ikke).
Acceptable anmodningstyper
Parallel skalering er ikke egnet til alle typer forespørgsler. I den første version behandler den kun læseanmodninger, der opfylder tre betingelser:
— SELECT-forespørgsler er skrivebeskyttede (selvom der er planlagt flere typer);
— forespørgslen refererer ikke til en tabel med sorteringsstilen INTERLEAVED;
- Forespørgslen bruger ikke Amazon Redshift Spectrum til at referere til eksterne tabeller.
For at blive dirigeret til Parallel Scaling Cluster skal anmodningen stå i kø. Derudover forespørgsler, der er kvalificerede til køen , vil ikke køre på klynger i parallel skala.
Køer og SQA kræver korrekt konfiguration . Vi anbefaler at optimere din WLM først - dette vil reducere behovet for parallel skalering. Og det er vigtigt, fordi parallel skalering kun er gratis i et vist antal timer. AWS hævder, at parallel skalering vil være gratis for 97 % af kunderne, hvilket bringer os til spørgsmålet om prisfastsættelse.
Omkostninger ved parallel skalering
AWS tilbyder en kreditmodel til parallel skalering. Hver aktive klynge Akkumulerer kreditter hver time, op til en times gratis parallelle skaleringskreditter om dagen.
Du betaler kun, når dit forbrug af Parallel Scaling Clusters overstiger mængden af kreditter, du har modtaget.
Omkostningerne beregnes med en on-demand rate pr. sekund for en parallel klynge, der anvendes over den frie sats. Du debiteres kun for varigheden af dine anmodninger, med en minimumsafgift på et minut hver gang en Parallel Scaling Cluster aktiveres. On-demand-raten pr. sekund beregnes ud fra generelle prissætningsprincipper , det vil sige, at det afhænger af nodetypen og antallet af noder i din klynge.
Lancering af parallel skalering
Parallel skalering udløses for hver WLM-kø. Gå til AWS Redshift-konsollen og vælg Workload Management fra venstre navigationsmenu. Vælg din klynges WLM-parametergruppe fra den følgende rullemenu.
Du vil se en ny kolonne kaldet "Concurrency Scaling Mode" ud for hver kø. Standard er "Deaktiveret". Klik på "Rediger", og du kan ændre indstillingerne for hver kø.
Konfiguration
Parallel skalering fungerer ved at videresende passende anmodninger til nye dedikerede klynger. Nye klynger har samme størrelse (type og antal noder) som hovedklyngen.
Standardantallet af klynger, der bruges til parallel skalering, er én (1), med mulighed for at konfigurere op til i alt ti (10) klynger.
Det samlede antal klynger til parallel skalering kan indstilles af parameteren max_concurrency_scaling_clusters. Forøgelse af værdien af denne parameter giver yderligere redundante klynger.
overvågning
Der er flere yderligere grafer tilgængelige i AWS Redshift-konsollen. Diagrammet Max Configured Concurrency Scaling Clusters viser værdien af max_concurrency_scaling_clusters over tid.
Antallet af aktive skaleringsklynger vises i brugergrænsefladen i afsnittet "Samtidig skaleringsaktivitet":
På fanen Forespørgsler er der en kolonne, der angiver, om forespørgslen blev udført i hovedklyngen eller i den parallelle skaleringsklynge:
Uanset om en bestemt forespørgsel blev udført i hovedklyngen eller gennem den parallelle skaleringsklynge, gemmes den i stl_query.concurrency_scaling_status.
En værdi på 1 indikerer, at forespørgslen blev udført i parallelskala-klyngen, mens andre værdier angiver, at den blev udført i den primære klynge.
Eksempel:
Oplysninger om samtidighedsskalering er også gemt i nogle andre tabeller og visninger, såsom SVCS_CONCURRENCY_SCALING_USAGE. Derudover er der en række katalogtabeller, der gemmer information om parallel skalering.
Fund
Forfatterne startede parallel skalering for én kø i den interne klynge ca. kl. 18:30:00 GMT den 29.03.2019/3/20. Ændrede parameteren max_concurrency_scaling_clusters til 30 ca. kl. 00:29.03.2019:XNUMX den XNUMX/XNUMX/XNUMX.
For at simulere en anmodningskø reducerede vi antallet af pladser for denne kø fra 15 til 5.
Nedenfor er et intermix.io-dashboarddiagram, der viser antallet af forespørgsler, der kører og står i kø efter at have reduceret antallet af slots.
Vi ser, at ventetiden på forespørgsler i køen er steget, med den maksimale tid på mere end 5 minutter.
Her er de relevante oplysninger fra AWS-konsollen om, hvad der skete i løbet af denne tid:
Redshift lancerede tre (3) parallelle skaleringsklynger som konfigureret. Det ser ud til, at disse klynger blev underudnyttet, selvom mange anmodninger i vores klynge stod i kø.
Brugsgrafen korrelerer med skaleringsaktivitetsgrafen:
Efter et par timer tjekkede forfatterne køen, og det så ud til, at 6 anmodninger kørte med parallel skalering. Vi testede også tilfældigt to anmodninger gennem brugergrænsefladen. Vi har ikke kontrolleret, hvordan man bruger disse værdier, når flere parallelle klynger er aktive på én gang.
Fund
Parallel skalering kan reducere den tid, anmodninger tilbringer i køen under spidsbelastninger.
Baseret på resultaterne af basistesten viste det sig, at situationen med indlæsningsanmodninger er delvist forbedret. Parallel skalering alene løste dog ikke alle samtidighedsproblemer.
Dette skyldes begrænsninger på de typer forespørgsler, der kan bruge parallel skalering. For eksempel har forfatterne mange tabeller med indflettede sorteringsnøgler, og det meste af vores arbejdsbyrde er at skrive.
Selvom parallel skalering ikke er en universel løsning til opsætning af WLM, er brugen af denne funktion enkel og ligetil.
Derfor anbefaler forfatteren at bruge det til dine WLM-køer. Start med en parallel klynge, og overvåg spidsbelastningen gennem konsollen for at afgøre, om de nye klynger udnyttes fuldt ud.
Efterhånden som AWS tilføjer understøttelse af yderligere forespørgselstyper og tabeller, bør parallel skalering gradvist blive mere og mere effektiv.
Kommentar fra Daniyar Belkhodzhaev, Skyeng Data Engineer
Vi hos Skyeng bemærkede også straks den nye mulighed for parallel skalering.
Funktionaliteten er meget attraktiv, især i betragtning af at AWS vurderer, at de fleste brugere ikke engang skal betale ekstra for det.Det skete sådan, at vi i midten af april havde en usædvanlig byge af anmodninger til Redshift-klyngen. I denne periode har vi ofte tyet til Concurrency Scaling; nogle gange arbejdede en ekstra klynge 24 timer i døgnet uden at stoppe.
Dette gjorde det muligt, om ikke helt at løse problemet med køer, så i det mindste at gøre situationen acceptabel.
Vores observationer falder stort set sammen med indtrykkene fra gutterne fra intermix.io.
Vi lagde også mærke til, at selvom der ventede anmodninger i køen, blev ikke alle forespørgsler straks videresendt til den parallelle klynge. Tilsyneladende sker dette, fordi den parallelle klynge stadig tager tid at starte. Som følge heraf har vi under kortvarige spidsbelastninger stadig små køer, og de tilsvarende alarmer når at udløse.
Efter at have sluppet unormale belastninger i april, gik vi, som AWS forventede, ind i lejlighedsvis brug - inden for den frie norm.
Du kan spore dine omkostninger til parallel skalering i AWS Cost Explorer. Du skal vælge Service - Redshift, Usage Type - CS, for eksempel USW2-CS:dc2.large.Du kan læse mere om priser på russisk
Kilde: www.habr.com