Amazon Redshift პარალელური სკალირების სახელმძღვანელო და ტესტის შედეგები

Skyeng-ში ჩვენ ვიყენებთ Amazon Redshift-ს, პარალელური სკალირების ჩათვლით, ამიტომ საინტერესოდ მივიჩნიეთ Stefan Gromoll-ის, dotgo.com-ის დამფუძნებლის ეს სტატია intermix.io-სთვის. თარგმანის შემდეგ, ცოტაოდენი ჩვენი გამოცდილება მონაცემთა ინჟინერი დანიარ ბელხოჯაევისგან.

Amazon Redshift არქიტექტურა სკალირების საშუალებას იძლევა კლასტერში ახალი კვანძების დამატებით. მოთხოვნის მაქსიმალური რაოდენობის დაკმაყოფილების აუცილებლობამ შეიძლება გამოიწვიოს კვანძების გადაჭარბებული უზრუნველყოფა. Concurrency Scaling, განსხვავებით ახალი კვანძების დამატებისა, ზრდის გამოთვლის სიმძლავრეს საჭიროებისამებრ.

Amazon Redshift-ის პარალელური მასშტაბირება Redshift კლასტერებს აძლევს დამატებით შესაძლებლობებს პიკური მოთხოვნის მოცულობის დასამუშავებლად. ის მუშაობს მოთხოვნების ფონზე ახალ „პარალელურ“ კლასტერებზე გადატანით. მოთხოვნები განლაგებულია WLM კონფიგურაციისა და წესების საფუძველზე.

პარალელური სკალირების ფასები ეფუძნება საკრედიტო მოდელს უფასო იარუსით. უფასო კრედიტების ზემოთ, გადახდა ეფუძნება იმ დროს, როდესაც პარალელური მასშტაბის კლასტერი ამუშავებს მოთხოვნებს.

ავტორმა გამოსცადა პარალელური სკალირება ერთ-ერთ შიდა კლასტერზე. ამ პოსტში ის ისაუბრებს ტესტის შედეგებზე და მოგცემთ რჩევებს, თუ როგორ უნდა დაიწყოთ.

კლასტერული მოთხოვნები

პარალელური სკალირების გამოსაყენებლად, თქვენი Amazon Redshift კლასტერი უნდა აკმაყოფილებდეს შემდეგ მოთხოვნებს:

- პლატფორმა: EC2-VPC;
- კვანძის ტიპი: dc2.8xlarge, ds2.8xlarge, dc2.large ან ds2.xlarge;
- კვანძების რაოდენობა: 2-დან 32-მდე (ერთი კვანძის კლასტერები არ არის მხარდაჭერილი).

მისაღები მოთხოვნის ტიპები

პარალელური სკალირება არ არის შესაფერისი ყველა ტიპის მოთხოვნისთვის. პირველ ვერსიაში ის ამუშავებს მხოლოდ წაკითხულ მოთხოვნებს, რომლებიც აკმაყოფილებენ სამ პირობას:

— SELECT მოთხოვნები არის მხოლოდ წაკითხვადი (თუმცა დაგეგმილია მეტი ტიპის);
— შეკითხვა არ მიუთითებს ცხრილზე INTERLEAVED დახარისხების სტილით;
- მოთხოვნა არ იყენებს Amazon Redshift Spectrum-ს გარე ცხრილების მითითებისთვის.

პარალელური სკალირების კლასტერში გადასაყვანად მოთხოვნა უნდა დადგეს რიგში. გარდა ამისა, მოთხოვნები, რომლებიც შეესაბამება რიგში SQA (მოკლე შეკითხვის დაჩქარება), არ იმუშავებს პარალელური მასშტაბის კლასტერებზე.

რიგები და SQA საჭიროებენ შესაბამის კონფიგურაციას Redshift სამუშაო დატვირთვის მართვა (WLM). ჩვენ გირჩევთ პირველ რიგში თქვენი WLM-ის ოპტიმიზაციას - ეს შეამცირებს პარალელური მასშტაბირების საჭიროებას. და ეს მნიშვნელოვანია, რადგან პარალელური სკალირება უფასოა მხოლოდ გარკვეული რაოდენობის საათის განმავლობაში. AWS ამტკიცებს, რომ პარალელური სკალირება უფასო იქნება მომხმარებელთა 97%-ისთვის, რაც ფასების საკითხამდე მიგვიყვანს.

პარალელური სკალირების ღირებულება

AWS გთავაზობთ საკრედიტო მოდელს პარალელური მასშტაბისთვის. თითოეული აქტიური კლასტერი Amazon RedShift აგროვებს კრედიტებს საათობრივად, ერთ საათამდე უფასო პარალელური სკალირების კრედიტებს დღეში.

თქვენ იხდით მხოლოდ მაშინ, როდესაც თქვენი პარალელური სკალირების კლასტერების გამოყენება აღემატება მიღებული კრედიტების რაოდენობას.

ღირებულება გამოითვლება წამში მოთხოვნის კურსით პარალელური კლასტერისთვის, რომელიც გამოიყენება უფასო ტარიფის ზემოთ. თქვენ ჩამოგეჭრებათ მხოლოდ თქვენი მოთხოვნების ხანგრძლივობისთვის, მინიმალური გადასახადი ერთი წუთით ყოველ ჯერზე პარალელური სკალირების კლასტერის გააქტიურებისას. წამში მოთხოვნის განაკვეთი გამოითვლება ზოგადი ფასების პრინციპების საფუძველზე Amazon RedShift, ანუ, ეს დამოკიდებულია კვანძის ტიპზე და თქვენს კლასტერში კვანძების რაოდენობაზე.

პარალელური სკალირების გაშვება

პარალელური მასშტაბირება ხდება თითოეული WLM რიგისთვის. გადადით AWS Redshift კონსოლზე და აირჩიეთ სამუშაო დატვირთვის მართვა მარცხენა ნავიგაციის მენიუდან. აირჩიეთ თქვენი კლასტერის WLM პარამეტრების ჯგუფი შემდეგი ჩამოსაშლელი მენიუდან.

ყოველი რიგის გვერდით ნახავთ ახალ სვეტს სახელწოდებით "კონკურენტული სკალირების რეჟიმი". ნაგულისხმევი არის "გამორთული". დააწკაპუნეთ "რედაქტირებაზე" და შეგიძლიათ შეცვალოთ პარამეტრები თითოეული რიგისთვის.

კონფიგურაცია

პარალელური მასშტაბირება მუშაობს შესაბამისი მოთხოვნების ახალ გამოყოფილ კლასტერებზე გაგზავნით. ახალ კლასტერებს აქვთ იგივე ზომა (კვანძების ტიპი და რაოდენობა), როგორც მთავარ კლასტერს.

კლასტერების ნაგულისხმევი რაოდენობა, რომლებიც გამოიყენება პარალელური მასშტაბებისთვის არის ერთი (1), ათი (10) კლასტერამდე კონფიგურაციის შესაძლებლობით.
კლასტერების მთლიანი რაოდენობა პარალელური მასშტაბისთვის შეიძლება დაყენდეს max_concurrency_scaling_clusters პარამეტრით. ამ პარამეტრის მნიშვნელობის გაზრდა უზრუნველყოფს დამატებით ზედმეტ კლასტერებს.

მონიტორინგი

არსებობს რამდენიმე დამატებითი გრაფიკი ხელმისაწვდომი AWS Redshift კონსოლში. Max Configured Concurrency Scaling Clusters დიაგრამა აჩვენებს max_concurrency_scaling_clusters-ის მნიშვნელობას დროთა განმავლობაში.

აქტიური სკალირების კლასტერების რაოდენობა ნაჩვენებია მომხმარებლის ინტერფეისში, სექციაში „თანადროვე სკალირების აქტივობა“:

Queries ჩანართში არის სვეტი, რომელიც მიუთითებს, მოთხოვნა შესრულდა მთავარ კლასტერში თუ პარალელური მასშტაბირების კლასტერში:

იმისდა მიუხედავად, კონკრეტული მოთხოვნა შესრულდა მთავარ კლასტერში თუ პარალელური სკალირების კლასტერის მეშვეობით, ის ინახება stl_query.concurrency_scaling_status-ში.

მნიშვნელობა 1 მიუთითებს, რომ მოთხოვნა შესრულდა პარალელური მასშტაბის კლასტერში, ხოლო სხვა მნიშვნელობები მიუთითებს, რომ იგი შესრულდა პირველად კლასტერში.

მაგალითი:

კონკურენტულობის სკალირების ინფორმაცია ასევე ინახება ზოგიერთ სხვა ცხრილებსა და ხედებში, როგორიცაა SVCS_CONCURRENCY_SCALING_USAGE. გარდა ამისა, არსებობს მთელი რიგი კატალოგი ცხრილები, რომლებიც ინახავს ინფორმაციას პარალელური მასშტაბის შესახებ.

დასკვნები

ავტორებმა დაიწყეს პარალელური სკალირება ერთი რიგისთვის შიდა კლასტერში დაახლოებით 18:30:00 GMT 29.03.2019/3/20. შეცვალეს max_concurrency_scaling_clusters პარამეტრი 30-ზე დაახლოებით 00:29.03.2019:XNUMX XNUMX/XNUMX/XNUMX.

მოთხოვნის რიგის სიმულაციისთვის, ჩვენ შევამცირეთ ამ რიგის სლოტების რაოდენობა 15-დან 5-მდე.

ქვემოთ მოცემულია intermix.io დაფის დიაგრამა, რომელიც გვიჩვენებს სლოტების რაოდენობის შემცირების შემდეგ გაშვებული მოთხოვნების რაოდენობას და რიგში.

ჩვენ ვხედავთ, რომ მოთხოვნის ლოდინის დრო რიგში გაიზარდა, მაქსიმალური დრო 5 წუთზე მეტია.

აქ არის შესაბამისი ინფორმაცია AWS კონსოლიდან იმის შესახებ, თუ რა მოხდა ამ დროის განმავლობაში:

Redshift-მა გაუშვა სამი (3) პარალელური მასშტაბირების კლასტერი, როგორც კონფიგურირებული იყო. როგორც ჩანს, ეს კლასტერები არასაკმარისად იყო გამოყენებული, მიუხედავად იმისა, რომ ჩვენს კლასტერში ბევრი მოთხოვნა იყო რიგში.

გამოყენების გრაფიკი კორელაციაშია სკალირების აქტივობის გრაფიკთან:

რამდენიმე საათის შემდეგ ავტორებმა რიგს გადაამოწმეს და ჩანდა, რომ 6 მოთხოვნა პარალელურად სკალირებაზე მუშაობდა. ჩვენ ასევე შემთხვევით გამოვცადეთ ორი მოთხოვნა მომხმარებლის ინტერფეისის საშუალებით. ჩვენ არ შევამოწმეთ როგორ გამოვიყენოთ ეს მნიშვნელობები, როდესაც რამდენიმე პარალელური კლასტერი ერთდროულად აქტიურია.

დასკვნები

პარალელურმა სკალირებამ შეიძლება შეამციროს რიგზე გატარებული მოთხოვნები პიკური დატვირთვის დროს.

საბაზისო ტესტის შედეგებზე დაყრდნობით აღმოჩნდა, რომ მოთხოვნის ჩატვირთვასთან დაკავშირებით მდგომარეობა ნაწილობრივ გაუმჯობესდა. თუმცა, მხოლოდ პარალელური მასშტაბირება არ გადაჭრის ყველა კონკურენტულ პრობლემას.

ეს გამოწვეულია მოთხოვნების ტიპების შეზღუდვით, რომლებსაც შეუძლიათ გამოიყენონ პარალელური მასშტაბირება. მაგალითად, ავტორებს აქვთ მრავალი ცხრილი ერთმანეთთან დალაგებული კლავიშებით და ჩვენი დატვირთვის უმეტესი ნაწილი წერაა.

მიუხედავად იმისა, რომ პარალელური მასშტაბირება არ არის უნივერსალური გადაწყვეტა WLM-ის დასაყენებლად, ამ ფუნქციის გამოყენება მარტივი და მარტივია.

ამიტომ, ავტორი გირჩევთ გამოიყენოთ იგი თქვენი WLM რიგებისთვის. დაიწყეთ ერთი პარალელური კლასტერით და დააკვირდით პიკს დატვირთვას კონსოლის მეშვეობით, რათა დაადგინოთ, არის თუ არა ახალი კლასტერების სრულად გამოყენება.

ვინაიდან AWS ამატებს მხარდაჭერას დამატებითი შეკითხვის ტიპებისა და ცხრილებისთვის, პარალელური მასშტაბირება თანდათან უფრო და უფრო ეფექტური უნდა გახდეს.

კომენტარი დანიარ ბელხოჯაევისგან, Skyeng Data Engineer-ისგან

ჩვენ Skyeng-ში ასევე მაშინვე შევამჩნიეთ პარალელური მასშტაბირების შესაძლებლობა.
ფუნქციონალობა ძალიან მიმზიდველია, განსაკუთრებით იმის გათვალისწინებით, რომ AWS-ის შეფასებით, მომხმარებელთა უმეტესობას არც კი მოუწევს ამაში დამატებითი გადახდა.

მოხდა ისე, რომ აპრილის შუა რიცხვებში ჩვენ გვქონდა მოთხოვნათა უჩვეულო ნაკადი Redshift კლასტერთან. ამ პერიოდში ხშირად მივმართავდით Concurrency Scaling-ს; ზოგჯერ დამატებითი კლასტერი მუშაობდა 24 საათის განმავლობაში გაჩერების გარეშე.

ამან შესაძლებელი გახადა თუ არა მთლიანად რიგებით პრობლემის მოგვარება, მაშინ მაინც ვითარება მისაღები ყოფილიყო.

ჩვენი დაკვირვებები დიდწილად ემთხვევა intermix.io-ს ბიჭების შთაბეჭდილებებს.

ჩვენ ასევე შევამჩნიეთ, რომ მიუხედავად იმისა, რომ იყო მოთხოვნები რიგში, ყველა მოთხოვნა არ იყო დაუყოვნებლივ გადაგზავნილი პარალელურ კლასტერში. როგორც ჩანს, ეს იმიტომ ხდება, რომ პარალელურ კლასტერს ჯერ კიდევ დრო სჭირდება დასაწყებად. შედეგად, მოკლევადიანი პიკური დატვირთვების დროს ჩვენ ჯერ კიდევ გვაქვს მცირე რიგები და შესაბამისი სიგნალიზაცია აქვს დრო ამოქმედდეს.

აპრილში არანორმალური დატვირთვებისგან თავის დაღწევის შემდეგ, ჩვენ, როგორც AWS ველოდით, შევედით შემთხვევითი გამოყენების რეჟიმში - უფასო ნორმის ფარგლებში.
თქვენ შეგიძლიათ თვალყური ადევნოთ თქვენი პარალელური სკალირების ხარჯებს AWS Cost Explorer-ში. თქვენ უნდა აირჩიოთ Service - Redshift, Usage Type - CS, მაგალითად USW2-CS:dc2.large.

ფასების შესახებ მეტი შეგიძლიათ წაიკითხოთ რუსულ ენაზე აქ.

წყარო: www.habr.com