Ve Skyengu používáme Amazon Redshift, včetně paralelního škálování, a tak nás zaujal tento článek Stefana Gromolla, zakladatele dotgo.com, pro intermix.io. Po překladu trochu našich zkušeností od datového inženýra Daniyara Belkhodzhaeva.
umožňuje škálování přidáním nových uzlů do clusteru. Potřeba vypořádat se se špičkovým počtem požadavků může vést k nadměrnému poskytování uzlů. Concurrency Scaling, na rozdíl od přidávání nových uzlů, zvyšuje výpočetní výkon podle potřeby.
Paralelní škálování Amazon Redshift poskytuje clusterům Redshift další kapacitu pro zpracování špičkových objemů požadavků. Funguje tak, že požadavky přesouvá do nových „paralelních“ clusterů na pozadí. Požadavky jsou směrovány na základě konfigurace a pravidel WLM.
Ceny paralelního škálování jsou založeny na úvěrovém modelu s bezplatnou úrovní. Nad bezplatnými kredity je platba založena na době, kdy Parallel Scaling Cluster zpracovává požadavky.
Autor testoval paralelní škálování na jednom z interních clusterů. V tomto příspěvku bude mluvit o výsledcích testů a dá tipy, jak začít.
Požadavky na klastr
Chcete-li používat paralelní škálování, váš cluster Amazon Redshift musí splňovat následující požadavky:
- plošina: EC2-VPC;
- typ uzlu: dc2.8xlarge, ds2.8xlarge, dc2.large nebo ds2.xlarge;
— počet uzlů: od 2 do 32 (jednouzlové clustery nejsou podporovány).
Přijatelné typy požadavků
Paralelní škálování není vhodné pro všechny typy dotazů. V první verzi zpracovává pouze požadavky na čtení, které splňují tři podmínky:
— SELECT dotazy jsou pouze pro čtení (ačkoli je plánováno více typů);
— dotaz neodkazuje na tabulku se stylem řazení INTERLEAVED;
- Dotaz nepoužívá Amazon Redshift Spectrum k odkazování na externí tabulky.
Aby byl požadavek směrován do Parallel Scaling Cluster, musí být zařazen do fronty. Navíc dotazy vhodné pro frontu , nepoběží na clusterech s paralelním měřítkem.
Fronty a SQA vyžadují správnou konfiguraci . Nejprve doporučujeme optimalizovat váš WLM – tím se sníží potřeba paralelního škálování. A to je důležité, protože paralelní škálování je zdarma jen po určitý počet hodin. AWS tvrdí, že paralelní škálování bude pro 97 % zákazníků zdarma, čímž se dostáváme k otázce cenotvorby.
Náklady na paralelní škálování
AWS nabízí kreditní model pro paralelní škálování. Každý aktivní shluk Akumuluje kredity každou hodinu, až jednu hodinu bezplatných kreditů pro paralelní škálování denně.
Platíte pouze tehdy, když vaše využití Parallel Scaling Clusters překročí počet kreditů, které jste obdrželi.
Cena se vypočítává rychlostí za sekundu na vyžádání pro paralelní cluster, který se používá nad volnou rychlostí. Účtujeme vám pouze dobu trvání vašich požadavků, přičemž minimální poplatek činí jednu minutu pokaždé, když je aktivován Parallel Scaling Cluster. Sazba za sekundu na vyžádání se vypočítává na základě obecných cenových zásad , to znamená, že záleží na typu uzlu a počtu uzlů ve vašem clusteru.
Spuštění paralelního škálování
Paralelní škálování se spouští pro každou frontu WLM. Přejděte na konzolu AWS Redshift a v levé navigační nabídce vyberte Workload Management. Z následující rozevírací nabídky vyberte skupinu parametrů WLM vašeho clusteru.
U každé fronty uvidíte nový sloupec nazvaný "Concurrency Scaling Mode". Výchozí nastavení je "Zakázáno". Klikněte na "Upravit" a můžete změnit nastavení pro každou frontu.
Konfigurace
Paralelní škálování funguje tak, že se příslušné požadavky předávají novým vyhrazeným clusterům. Nové clustery mají stejnou velikost (typ a počet uzlů) jako hlavní cluster.
Výchozí počet klastrů používaných pro paralelní škálování je jeden (1), s možností konfigurovat celkem až deset (10) klastrů.
Celkový počet klastrů pro paralelní škálování lze nastavit parametrem max_concurrency_scaling_clusters. Zvýšením hodnoty tohoto parametru získáte další redundantní shluky.
Sledování
V konzole AWS Redshift je k dispozici několik dalších grafů. Graf Max Concurrency Scaling Clusters zobrazuje hodnotu max_concurrency_scaling_clusters v průběhu času.
Počet aktivních škálovacích clusterů je zobrazen v uživatelském rozhraní v sekci „Činnost škálování souběžnosti“:
Na kartě Dotazy je sloupec, který označuje, zda byl dotaz proveden v hlavním clusteru nebo v clusteru paralelního škálování:
Bez ohledu na to, zda byl konkrétní dotaz proveden v hlavním clusteru nebo prostřednictvím clusteru pro paralelní škálování, je uložen v stl_query.concurrency_scaling_status.
Hodnota 1 znamená, že dotaz byl proveden v paralelním clusteru škálování, zatímco ostatní hodnoty označují, že byl proveden v primárním clusteru.
Příklad:
Informace o souběžném škálování jsou také uloženy v některých dalších tabulkách a pohledech, jako je SVCS_CONCURRENCY_SCALING_USAGE. Kromě toho existuje řada katalogových tabulek, které ukládají informace o paralelním škálování.
výsledky
Autoři zahájili paralelní škálování pro jednu frontu v interním clusteru přibližně v 18:30:00 GMT dne 29.03.2019. března 3. Změnili parametr max_concurrency_scaling_clusters na hodnotu 20 přibližně ve 30:00:29.03.2019 dne XNUMX. března XNUMX.
Abychom simulovali frontu požadavků, snížili jsme počet slotů pro tuto frontu z 15 na 5.
Níže je graf řídicího panelu intermix.io zobrazující počet spuštěných požadavků a ve frontě po snížení počtu slotů.
Vidíme, že se prodloužila doba čekání na požadavky ve frontě, přičemž maximální doba je více než 5 minut.
Zde jsou relevantní informace z konzoly AWS o tom, co se během této doby stalo:
Redshift spustil tři (3) paralelní škálovací clustery podle konfigurace. Zdá se, že tyto clustery byly nedostatečně využívány, přestože mnoho požadavků v našem clusteru bylo ve frontě.
Graf využití koreluje s grafem aktivity škálování:
Po pár hodinách autoři zkontrolovali frontu a vypadalo to, že při paralelním škálování běží 6 požadavků. Prostřednictvím uživatelského rozhraní jsme také náhodně testovali dva požadavky. Nekontrolovali jsme, jak tyto hodnoty použít, když je aktivních několik paralelních clusterů najednou.
Závěry
Paralelní škálování může snížit čas, který požadavky stráví ve frontě během špičkového zatížení.
Na základě výsledků základního testu se ukázalo, že se situace s načítáním požadavků částečně zlepšila. Samotné paralelní škálování však nevyřešilo všechny problémy souběžnosti.
Důvodem je omezení typů dotazů, které mohou používat paralelní škálování. Autoři mají například mnoho tabulek s prokládanými klíči řazení a většinu naší práce tvoří psaní.
Přestože paralelní škálování není univerzálním řešením pro nastavení WLM, použití této funkce je jednoduché a přímočaré.
Proto jej autor doporučuje používat pro vaše fronty WLM. Začněte s jedním paralelním clusterem a sledujte špičkové zatížení prostřednictvím konzoly, abyste zjistili, zda jsou nové clustery plně využívány.
Jak AWS přidává podporu pro další typy dotazů a tabulek, paralelní škálování by mělo být postupně stále efektivnější.
Komentář od Daniyara Belkhodzhaeva, datového inženýra Skyeng
My ve Skyengu jsme si také okamžitě všimli vznikající možnosti paralelního škálování.
Funkčnost je velmi atraktivní, zvláště vezmeme-li v úvahu, že AWS odhaduje, že většina uživatelů za ni ani nebude muset připlácet.Stalo se, že v polovině dubna jsme měli neobvyklý nápor požadavků na cluster Redshift. Během tohoto období jsme se často uchýlili k Concurrency Scaling; někdy další cluster fungoval 24 hodin denně bez zastavení.
To umožnilo, když ne zcela vyřešit problém s frontami, tak alespoň učinit situaci přijatelnou.
Naše postřehy se do značné míry shodují s dojmy kluků z intermix.io.
Také jsme si všimli, že ačkoli ve frontě čekaly požadavky, ne všechny požadavky byly okamžitě předány paralelnímu clusteru. Zjevně se to děje proto, že spuštění paralelního clusteru stále trvá. Výsledkem je, že během krátkodobého špičkového zatížení máme stále malé fronty a odpovídající alarmy mají čas se spustit.
Když jsme se v dubnu zbavili abnormálních zátěží, vstoupili jsme, jak AWS očekával, do režimu občasného použití - v rámci bezplatné normy.
Své náklady na paralelní škálování můžete sledovat v AWS Cost Explorer. Musíte vybrat Service - Redshift, Usage Type - CS, například USW2-CS:dc2.large.Více o cenách si můžete přečíst v ruštině
Zdroj: www.habr.com