В 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 Clusters показва стойността на max_concurrency_scaling_clusters във времето.
Броят на активните клъстери за мащабиране се показва в потребителския интерфейс в раздела „Дейност за мащабиране на едновременност“:
В раздела Заявки има колона, указваща дали заявката е била изпълнена в основния клъстер или в клъстера за паралелно мащабиране:
Независимо дали конкретна заявка е била изпълнена в главния клъстер или чрез клъстер за паралелно мащабиране, тя се съхранява в stl_query.concurrency_scaling_status.
Стойност 1 показва, че заявката е била изпълнена в клъстера с паралелен мащаб, докато други стойности показват, че е била изпълнена в основния клъстер.
Пример:
Информацията за мащабиране на едновременност също се съхранява в някои други таблици и изгледи, като SVCS_CONCURRENCY_SCALING_USAGE. Освен това има редица каталожни таблици, които съхраняват информация за паралелно мащабиране.
резултати
Авторите започнаха паралелно мащабиране за една опашка във вътрешния клъстер в приблизително 18:30:00 GMT на 29.03.2019 г. Промениха параметъра max_concurrency_scaling_clusters на 3 в приблизително 20:30:00 на 29.03.2019 г.
За да симулираме опашка за заявки, ние намалихме броя на слотовете за тази опашка от 15 на 5.
По-долу има диаграма на таблото за управление на intermix.io, показваща броя на изпълняваните заявки и на опашка след намаляване на броя на слотовете.
Виждаме, че времето за изчакване на заявки в опашката се е увеличило, като максималното време е повече от 5 минути.
Ето съответната информация от конзолата на AWS за случилото се през това време:
Redshift стартира три (3) паралелни клъстера за мащабиране, както е конфигурирано. Изглежда, че тези клъстери са били недостатъчно използвани, въпреки че много заявки в нашия клъстер са поставени на опашка.
Графиката на използване корелира с графиката на активността на мащабиране:
След няколко часа авторите провериха опашката и изглеждаше, че 6 заявки се изпълняват при паралелно мащабиране. Също така тествахме на случаен принцип две заявки през потребителския интерфейс. Не сме проверили как да използваме тези стойности, когато няколко паралелни клъстера са активни едновременно.
Данни
Паралелното мащабиране може да намали времето, което заявките прекарват в опашката по време на пикови натоварвания.
Въз основа на резултатите от основния тест се оказа, че ситуацията с заявките за зареждане се е подобрила частично. Въпреки това, паралелното мащабиране само по себе си не решава всички проблеми с паралелността.
Това се дължи на ограниченията върху типовете заявки, които могат да използват паралелно мащабиране. Например, авторите имат много таблици с подредени ключове за сортиране и по-голямата част от работата ни е писане.
Въпреки че паралелното мащабиране не е универсално решение за настройка на WLM, използването на тази функция е просто и ясно.
Затова авторът препоръчва да го използвате за вашите WLM опашки. Започнете с един паралелен клъстер и наблюдавайте пиковото натоварване през конзолата, за да определите дали новите клъстери се използват напълно.
Тъй като AWS добавя поддръжка за допълнителни типове заявки и таблици, паралелното мащабиране трябва постепенно да става все по-ефективно.
Коментар от Данияр Белходжаев, Skyeng Data Engineer
Ние от Skyeng също веднага забелязахме възникващата възможност за паралелно мащабиране.
Функционалността е много привлекателна, особено като се има предвид, че AWS изчислява, че повечето потребители дори няма да трябва да плащат допълнително за нея.Случи се така, че в средата на април имахме необичаен поток от заявки към клъстера Redshift. През този период често прибягвахме до скалиране на паралелност; понякога допълнителен клъстер работеше 24 часа на ден без спиране.
Това даде възможност, ако не напълно да се реши проблемът с опашките, то поне да се направи ситуацията приемлива.
Нашите наблюдения до голяма степен съвпадат с впечатленията на момчетата от intermix.io.
Забелязахме също, че въпреки че имаше заявки, чакащи в опашката, не всички заявки бяха незабавно препратени към паралелния клъстер. Очевидно това се случва, защото паралелният клъстер все още отнема време, за да стартира. В резултат на това по време на краткосрочни пикови натоварвания все още имаме малки опашки и съответните аларми имат време да се задействат.
След като се отървахме от необичайни натоварвания през април, ние, както очакваше AWS, влязохме в режим на случайна употреба - в рамките на безплатната норма.
Можете да проследявате разходите си за паралелно мащабиране в AWS Cost Explorer. Трябва да изберете Service - Redshift, Usage Type - CS, например USW2-CS:dc2.large.Можете да прочетете повече за цените на руски език
Източник: www.habr.com