På Skyeng använder vi Amazon Redshift, inklusive parallell skalning, så vi fann den här artikeln av Stefan Gromoll, grundare av dotgo.com, för intermix.io intressant. Efter översättningen, lite av vår erfarenhet från dataingenjören Daniyar Belkhodzhaev.
tillåter skalning genom att lägga till nya noder i klustret. Behovet av att hantera ett toppantal förfrågningar kan leda till överprovisionering av noder. Samtidig skalning, i motsats till att lägga till nya noder, ökar beräkningskraften efter behov.
Amazon Redshift parallell skalning ger Redshift-kluster ytterligare kapacitet för att hantera toppvolymer för begäranden. Det fungerar genom att flytta förfrågningar till nya "parallella" kluster i bakgrunden. Förfrågningar dirigeras baserat på WLM-konfiguration och regler.
Parallell skalningsprissättning baseras på en kreditmodell med en gratis nivå. Ovanför gratiskrediter baseras betalningen på den tid då Parallel Scaling Cluster bearbetar förfrågningar.
Författaren testade parallell skalning på ett av de interna klustren. I det här inlägget kommer han att prata om testresultaten och ge tips på hur du kommer igång.
Klusterkrav
För att använda parallell skalning måste ditt Amazon Redshift-kluster uppfylla följande krav:
- plattform: EC2-VPC;
— nodtyp: dc2.8xlarge, ds2.8xlarge, dc2.large eller ds2.xlarge;
— antal noder: från 2 till 32 (enkla nodkluster stöds inte).
Godtagbara förfrågningstyper
Parallell skalning är inte lämplig för alla typer av frågor. I den första versionen behandlar den bara läsbegäranden som uppfyller tre villkor:
— SELECT-frågor är skrivskyddade (även om fler typer är planerade);
— frågan refererar inte till en tabell med sorteringsstilen INTERLEAVED.
- Frågan använder inte Amazon Redshift Spectrum för att referera till externa tabeller.
För att kunna dirigeras till Parallell Scaling Cluster måste begäran ställas i kö. Dessutom frågor som är kvalificerade för kön , kommer inte att köras på kluster i parallell skala.
Köer och SQA kräver korrekt konfiguration . Vi rekommenderar att du optimerar din WLM först - detta minskar behovet av parallell skalning. Och detta är viktigt eftersom parallell skalning endast är gratis under ett visst antal timmar. AWS hävdar att parallell skalning kommer att vara gratis för 97 % av kunderna, vilket för oss till frågan om prissättning.
Kostnad för parallell skalning
AWS erbjuder en kreditmodell för parallell skalning. Varje aktivt kluster Ackumulerar poäng varje timme, upp till en timmes gratis parallellskalningspoäng per dag.
Du betalar bara när din användning av Parallel Scaling Clusters överstiger mängden krediter du har fått.
Kostnaden beräknas till en beställningstakt per sekund för ett parallellt kluster som används över den fria taxan. Du debiteras endast för varaktigheten av dina förfrågningar, med en minimiavgift på en minut varje gång ett Parallell Scaling Cluster aktiveras. Beställhastigheten per sekund beräknas utifrån allmänna prissättningsprinciper , det vill säga det beror på typen av nod och antalet noder i ditt kluster.
Lanserar parallell skalning
Parallell skalning utlöses för varje WLM-kö. Gå till AWS Redshift-konsolen och välj Workload Management från den vänstra navigeringsmenyn. Välj ditt klusters WLM-parametergrupp från följande rullgardinsmeny.
Du kommer att se en ny kolumn som heter "Concurrency Scaling Mode" bredvid varje kö. Standardinställningen är "Inaktiverad". Klicka på "Redigera" så kan du ändra inställningarna för varje kö.
konfiguration
Parallell skalning fungerar genom att vidarebefordra lämpliga förfrågningar till nya dedikerade kluster. Nya kluster har samma storlek (typ och antal noder) som huvudklustret.
Standardantalet kluster som används för parallell skalning är ett (1), med möjlighet att konfigurera upp till totalt tio (10) kluster.
Det totala antalet kluster för parallell skalning kan ställas in med parametern max_concurrency_scaling_clusters. Att öka värdet på denna parameter ger ytterligare redundanta kluster.
övervakning
Det finns flera ytterligare grafer tillgängliga i AWS Redshift-konsolen. Diagrammet Max Configured Concurrency Scaling Clusters visar värdet av max_concurrency_scaling_clusters över tiden.
Antalet aktiva skalningskluster visas i användargränssnittet i avsnittet "Samtidig skalningsaktivitet":
På fliken Frågor finns det en kolumn som anger om frågan kördes i huvudklustret eller i det parallella skalningsklustret:
Oavsett om en viss fråga exekveras i huvudklustret eller genom ett parallellskalningskluster, lagras den i stl_query.concurrency_scaling_status.
Ett värde på 1 indikerar att frågan exekverades i det parallella skalklustret, medan andra värden indikerar att den exekveras i det primära klustret.
Exempel:
Samtidighetsskalningsinformation lagras också i vissa andra tabeller och vyer, som SVCS_CONCURRENCY_SCALING_USAGE. Dessutom finns det ett antal katalogtabeller som lagrar information om parallell skalning.
Resultat
Författarna startade parallell skalning för en kö i det interna klustret cirka 18:30:00 GMT den 29.03.2019/3/20. Ändrade parametern max_concurrency_scaling_clusters till 30 cirka 00:29.03.2019:XNUMX den XNUMX/XNUMX/XNUMX.
För att simulera en förfrågningskö minskade vi antalet platser för denna kö från 15 till 5.
Nedan är ett intermix.io instrumentpanelsdiagram som visar antalet förfrågningar som körs och köar efter att antalet platser har minskats.
Vi ser att väntetiden för förfrågningar i kön har ökat, med maximal tid på mer än 5 minuter.
Här är relevant information från AWS-konsolen om vad som hände under den här tiden:
Redshift lanserade tre (3) parallella skalningskluster som konfigurerats. Det verkar som om dessa kluster var underutnyttjade, även om många förfrågningar i vårt kluster stod i kö.
Användningsdiagrammet korrelerar med skalningsaktivitetsdiagrammet:
Efter några timmar kontrollerade författarna kön och det såg ut som att 6 förfrågningar kördes med parallell skalning. Vi testade också slumpmässigt två förfrågningar via användargränssnittet. Vi har inte kontrollerat hur man använder dessa värden när flera parallella kluster är aktiva samtidigt.
Resultat
Parallell skalning kan minska den tid som förfrågningar spenderar i kön under toppbelastningar.
Baserat på resultaten från grundtestet visade det sig att situationen med lastningsförfrågningar delvis har förbättrats. Enbart parallell skalning löste dock inte alla samtidighetsproblem.
Detta beror på begränsningar för vilka typer av frågor som kan använda parallell skalning. Till exempel har författarna många tabeller med interfolierade sorteringsnycklar, och det mesta av vår arbetsbörda är att skriva.
Även om parallell skalning inte är en universell lösning för att ställa in WLM, är det enkelt och okomplicerat att använda den här funktionen.
Därför rekommenderar författaren att du använder den för dina WLM-köer. Börja med ett parallellt kluster och övervaka toppbelastningen genom konsolen för att avgöra om de nya klustren utnyttjas fullt ut.
Eftersom AWS lägger till stöd för ytterligare frågetyper och tabeller, bör parallell skalning gradvis bli mer och mer effektiv.
Kommentar från Daniyar Belkhodzhaev, Skyeng Data Engineer
Vi på Skyeng märkte också omedelbart den framväxande möjligheten till parallell skalning.
Funktionaliteten är mycket attraktiv, särskilt med tanke på att AWS uppskattar att de flesta användare inte ens behöver betala extra för det.Det hände så att vi i mitten av april hade en ovanlig uppsjö av förfrågningar till Redshift-klustret. Under denna period tog vi ofta till Concurrency Scaling, ibland arbetade ett extra kluster 24 timmar om dygnet utan att stanna.
Detta gjorde det möjligt, om inte att helt lösa problemet med köer, så åtminstone att göra situationen acceptabel.
Våra observationer sammanfaller till stor del med intrycken av killarna från intermix.io.
Vi märkte också att även om det fanns förfrågningar som väntade i kön så skickades inte alla förfrågningar omedelbart vidare till det parallella klustret. Tydligen händer detta eftersom parallellklustret fortfarande tar tid att starta. Som ett resultat har vi under kortvariga toppbelastningar fortfarande små köer, och motsvarande larm hinner utlösas.
Efter att ha blivit av med onormala belastningar i april gick vi, som AWS förväntat, in i ett tillfälligt användningsläge - inom den fria normen.
Du kan spåra dina parallella skalningskostnader i AWS Cost Explorer. Du måste välja Service - Redshift, Usage Type - CS, till exempel USW2-CS:dc2.large.Du kan läsa mer om priser på ryska
Källa: will.com