Во Skyeng користиме Amazon Redshift, вклучително и паралелно скалирање, така што овој напис од Стефан Громол, основач на dotgo.com, за intermix.io ни беше интересен. По преводот, малку од нашето искуство од инженерот за податоци Данијар Белкхоџаев.
овозможува скалирање со додавање на нови јазли во кластерот. Потребата да се справиме со максималниот број на барања може да доведе до прекумерно обезбедување на јазли. Скалирањето на истовременост, за разлика од додавањето нови јазли, ја зголемува компјутерската моќ по потреба.
Паралелното скалирање на Amazon Redshift им дава дополнителен капацитет на кластерите на Redshift за справување со максималниот волумен на барања. Работи со преместување на барањата во нови „паралелни“ кластери во позадина. Барањата се упатуваат врз основа на конфигурацијата и правилата на WLM.
Паралелното скалирање на цените се заснова на кредитен модел со слободно ниво. Над бесплатните кредити, плаќањето се заснова на времето кога Кластерот за паралелно скалирање ги обработува барањата.
Авторот тестирал паралелно скалирање на еден од внатрешните кластери. Во овој пост, тој ќе зборува за резултатите од тестот и ќе даде совети како да започнете.
Барања за кластери
За да користите паралелно скалирање, вашиот кластер Amazon Redshift мора да ги исполнува следниве барања:
- платформа: EC2-VPC;
— тип на јазол: dc2.8xlarge, ds2.8xlarge, dc2.large или ds2.xlarge;
- број на јазли: од 2 до 32 (групите со еден јазол не се поддржани).
Прифатливи типови барања
Паралелното скалирање не е погодно за сите видови прашања. Во првата верзија, тој обработува само барања за читање кои задоволуваат три услови:
— SELECT барањата се само за читање (иако се планираат повеќе видови);
— барањето не упатува на табела со стил на сортирање INTERLEAVED;
- Барањето не користи Amazon Redshift Spectrum за референца на надворешни табели.
За да се пренасочи до кластерот за паралелно скалирање, барањето мора да се стави во редица. Дополнително, барањата што ги исполнуваат условите за редот , нема да работи на кластери од паралелна скала.
Редиците и SQA бараат соодветна конфигурација . Препорачуваме прво да го оптимизирате вашиот WLM - ова ќе ја намали потребата за паралелно скалирање. И ова е важно бидејќи паралелното скалирање е бесплатно само одреден број часови. AWS тврди дека паралелното скалирање ќе биде бесплатно за 97% од клиентите, што нè доведува до прашањето за цените.
Трошоци за паралелно скалирање
AWS нуди кредитен модел за паралелно скалирање. Секој активен кластер Акумулира кредити на час, до еден час бесплатни кредити за паралелно скалирање дневно.
Плаќате само кога користењето на кластерите за паралелно скалирање го надминува износот на кредитите што сте ги добиле.
Трошокот се пресметува по стапка на барање во секунда за паралелен кластер што се користи над бесплатната стапка. Се наплаќа само за времетраењето на вашите барања, со минимална наплата од една минута секој пат кога ќе се активира кластер за паралелно скалирање. Стапката на барање во секунда се пресметува врз основа на општите принципи на цени , односно, зависи од типот на јазол и бројот на јазли во вашиот кластер.
Стартување на паралелно скалирање
Паралелното скалирање се активира за секоја редица WLM. Одете во конзолата AWS Redshift и изберете Управување со оптоварување од левото мени за навигација. Изберете ја групата параметри WLM на вашиот кластер од следното паѓачко мени.
До секоја редица ќе видите нова колона наречена „Режим на скалирање на конкуренција“. Стандардно е „Оневозможено“. Кликнете на „Уреди“ и можете да ги промените поставките за секоја редица.
Конфигурација
Паралелното скалирање функционира со препраќање соодветни барања до нови посветени кластери. Новите кластери имаат иста големина (тип и број на јазли) како и главниот кластер.
Стандардниот број на кластери што се користат за паралелно скалирање е еден (1), со можност за конфигурирање до вкупно десет (10) кластери.
Вкупниот број на кластери за паралелно скалирање може да се постави со параметарот max_concurrency_scaling_clusters. Зголемувањето на вредноста на овој параметар обезбедува дополнителни непотребни кластери.
Мониторинг
Постојат неколку дополнителни графикони достапни во конзолата AWS Redshift. Графиконот Max Configured Concurrency Scaling Clasters ја прикажува вредноста на max_concurrency_scaling_clusters со текот на времето.
Бројот на активни кластери за скалирање се прикажува во корисничкиот интерфејс во делот „Активност за скалирање на едновремено“:
Во табулаторот Queries, постои колона што покажува дали барањето е извршено во главниот кластер или во кластерот за паралелно скалирање:
Без оглед на тоа дали одредено барање е извршено во главниот кластер или преку паралелен кластер за скалирање, тоа се чува во stl_query.concurrency_scaling_status.
Вредноста 1 покажува дека барањето е извршено во кластерот на паралелна скала, додека другите вредности укажуваат дека е извршено во примарниот кластер.
Пример:
Информациите за скалирање на истовремено се зачувуваат и во некои други табели и прикази, како што е SVCS_CONCURRENCY_SCALING_USAGE. Покрај тоа, постојат голем број табели на каталози кои складираат информации за паралелното скалирање.
Наоди
Авторите започнаа паралелно скалирање за една редица во внатрешниот кластер приближно во 18:30 часот по Гринич на 00 година. Го сменија параметарот max_concurrency_scaling_cluters на 29.03.2019 во приближно 3:20 часот на 30 година.
За да симулираме редица за барање, го намаливме бројот на слотови за оваа редица од 15 на 5.
Подолу е графикон на контролната табла intermix.io кој го прикажува бројот на барања кои се извршуваат и чекаат во редот по намалувањето на бројот на слотови.
Гледаме дека времето на чекање за барања во редот е зголемено, при што максималното време е повеќе од 5 минути.
Еве ги релевантните информации од конзолата AWS за тоа што се случило во ова време:
Redshift лансираше три (3) паралелни кластери за скалирање како што е конфигурирано. Се чини дека овие кластери беа недоволно искористени, иако многу барања во нашиот кластер беа наредени.
Графикот на употреба е во корелација со графикот на активноста на скалирање:
По неколку часа, авторите ја проверуваа редицата и се чинеше дека 6 барања се извршуваат со паралелно скалирање. Исто така, по случаен избор тестиравме две барања преку корисничкиот интерфејс. Не проверивме како да ги користиме овие вредности кога се активни неколку паралелни кластери одеднаш.
Наоди
Паралелното скалирање може да го намали времето поминато на барањата во редот за време на најголемите оптоварувања.
Врз основа на резултатите од основниот тест, се покажа дека состојбата со барањата за вчитување е делумно подобрена. Сепак, самото паралелно скалирање не ги реши сите проблеми со истовременост.
Ова се должи на ограничувањата за типовите барања што можат да користат паралелно скалирање. На пример, авторите имаат многу табели со испреплетени копчиња за сортирање, а најголемиот дел од нашиот обем на работа е пишување.
Иако паралелното скалирање не е универзално решение за поставување на WLM, користењето на оваа функција е едноставно и едноставно.
Затоа, авторот препорачува да го користите за вашите редици WLM. Започнете со еден паралелен кластер и следете го максималното оптоварување низ конзолата за да одредите дали новите кластери се целосно искористени.
Како што AWS додава поддршка за дополнителни типови прашања и табели, паралелното скалирање треба постепено да станува сè поефикасно.
Коментар од Данијар Белкхоџаев, инженер за податоци на Skyeng
Ние во Skyeng, исто така, веднаш ја забележавме можноста за паралелно скалирање.
Функционалноста е многу привлечна, особено ако се земе предвид дека AWS проценува дека повеќето корисници дури и нема да мора да плаќаат дополнително за тоа.Така се случи во средината на април да имаме необичен бран барања до кластерот Redshift. Во овој период, ние често прибегнувавме кон скалирање на истовремено; понекогаш дополнителен кластер работеше 24 часа на ден без запирање.
Тоа овозможи, ако не целосно да се реши проблемот со редиците, тогаш барем ситуацијата да биде прифатлива.
Нашите набљудувања во голема мера се совпаѓаат со впечатоците на момците од intermix.io.
Исто така, забележавме дека иако имаше барања кои чекаа во редот, не сите барања беа веднаш препратени во паралелниот кластер. Очигледно ова се случува бидејќи на паралелниот кластер сè уште му треба време да започне. Како резултат на тоа, при краткорочни врвни оптоварувања сè уште имаме мали редици, а соодветните аларми имаат време да се активираат.
Откако се ослободивме од абнормални оптоварувања во април, ние, како што очекуваше AWS, влеговме во режим на повремена употреба - во рамките на бесплатната норма.
Можете да ги следите вашите трошоци за паралелно скалирање во AWS Cost Explorer. Треба да изберете Service - Redshift, Usage Type - CS, на пример USW2-CS:dc2.large.Можете да прочитате повеќе за цените на руски јазик
Извор: www.habr.com