A Skyengnél az Amazon Redshiftet használjuk, beleértve a párhuzamos skálázást is, ezért érdekesnek találtuk Stefan Gromoll, a dotgo.com alapítójának cikkét az intermix.io számára. A fordítás után egy kis tapasztalatunk Daniyar Belkhodzhaev adatmérnöktől.
lehetővé teszi a méretezést új csomópontok hozzáadásával a fürthöz. A csúcsszámú kérés megbirkózása a csomópontok túlzott kiépítéséhez vezethet. A párhuzamossági skálázás az új csomópontok hozzáadásával szemben szükség szerint növeli a számítási teljesítményt.
Az Amazon Redshift párhuzamos skálázása további kapacitást biztosít a Redshift-fürtök számára a csúcsforgalom kezelésére. Úgy működik, hogy a kéréseket új „párhuzamos” fürtökbe helyezi át a háttérben. A kérések a WLM konfigurációja és szabályai alapján kerülnek továbbításra.
A párhuzamos skálázási árképzés egy ingyenes szinttel rendelkező hitelmodellre épül. Az ingyenes kreditek felett a fizetés a Parallel Scaling Cluster kérések feldolgozásának időpontján alapul.
A szerző párhuzamos skálázást tesztelt az egyik belső klaszteren. Ebben a bejegyzésben a teszteredményekről fog beszélni, és tippeket ad az induláshoz.
Klaszter követelmények
A párhuzamos skálázás használatához az Amazon Redshift fürtnek meg kell felelnie a következő követelményeknek:
- felület: EC2-VPC;
- csomópont típusa: dc2.8xlarge, ds2.8xlarge, dc2.large vagy ds2.xlarge;
— csomópontok száma: 2 és 32 között (az egycsomópontos fürtök nem támogatottak).
Elfogadható kéréstípusok
A párhuzamos skálázás nem alkalmas minden típusú lekérdezéshez. Az első verzióban csak azokat az olvasási kéréseket dolgozza fel, amelyek három feltételnek eleget tesznek:
— A SELECT lekérdezések csak olvashatók (bár több típust terveznek);
— a lekérdezés nem hivatkozik INTERLEAVED rendezési stílusú táblára;
- A lekérdezés nem használja az Amazon Redshift Spectrumot külső táblákra való hivatkozáshoz.
A párhuzamos skálázási fürthöz való továbbításhoz a kérést sorba kell helyezni. Ezenkívül a várólistára alkalmas lekérdezések , nem fut párhuzamos léptékű klasztereken.
A várólisták és az SQA megfelelő konfigurációt igényelnek . Javasoljuk, hogy először optimalizálja a WLM-et – ez csökkenti a párhuzamos skálázás szükségességét. Ez pedig azért fontos, mert a párhuzamos skálázás csak bizonyos számú órán keresztül ingyenes. Az AWS azt állítja, hogy a párhuzamos skálázás az ügyfelek 97%-a számára ingyenes lesz, ami elvezet minket az árképzés kérdéséhez.
A párhuzamos skálázás költsége
Az AWS hitelmodellt kínál a párhuzamos skálázáshoz. Minden aktív klaszter Óránként felhalmozza a krediteket, naponta legfeljebb egy óra ingyenes párhuzamos skálázási kreditet.
Csak akkor kell fizetnie, ha a párhuzamos skálázási fürtök használata meghaladja a kapott jóváírások összegét.
A költséget a másodpercenkénti igény szerinti díjszabással számítják ki egy párhuzamos klaszter esetében, amelyet a szabad díjszabás felett használnak. Csak a kérelmek időtartamára kell fizetnie, minimum egy perc díjat minden párhuzamos skálázási fürt aktiválásakor. A másodpercenkénti igény szerinti díjszabás az általános árképzési elvek alapján kerül kiszámításra , vagyis a csomópont típusától és a fürtben lévő csomópontok számától függ.
Párhuzamos skálázás indítása
A párhuzamos skálázás minden WLM-sorhoz aktiválódik. Lépjen az AWS Redshift konzolra, és válassza a Workload Management lehetőséget a bal oldali navigációs menüben. Válassza ki a fürt WLM-paramétercsoportját a következő legördülő menüből.
Az egyes sorok mellett megjelenik egy új oszlop, melynek neve "Concurrency Scaling Mode". Az alapértelmezett a "Letiltva". Kattintson a "Szerkesztés" gombra, és módosíthatja az egyes sorok beállításait.
Configuration
A párhuzamos skálázás úgy működik, hogy a megfelelő kéréseket új dedikált fürtökhöz továbbítja. Az új fürtök mérete (a csomópontok típusa és száma) megegyezik a fő klaszterével.
A párhuzamos skálázáshoz használt fürtök alapértelmezett száma egy (1), és összesen tíz (10) fürt konfigurálható.
A párhuzamos skálázáshoz szükséges fürtök teljes száma a max_concurrency_scaling_clusters paraméterrel állítható be. A paraméter értékének növelése további redundáns klasztereket eredményez.
megfigyelés
Számos további grafikon is elérhető az AWS Redshift konzolon. A Max. Concurrency Scaling Clusters diagram megjeleníti a max_concurrency_scaling_clusters értékét az idő függvényében.
Az aktív skálázási fürtök száma a felhasználói felületen, a „Concurrency Scaling Activity” részben jelenik meg:
A Lekérdezések lapon van egy oszlop, amely jelzi, hogy a lekérdezést a fő fürtben vagy a párhuzamos skálázási fürtben hajtották végre:
Függetlenül attól, hogy egy adott lekérdezést a fő fürtben vagy párhuzamos skálázási fürtön keresztül hajtottak végre, az stl_query.concurrency_scaling_status fájlban tárolódik.
Az 1-es érték azt jelzi, hogy a lekérdezés a párhuzamos léptékű fürtben, míg a többi érték azt jelzi, hogy az elsődleges fürtben került végrehajtásra.
Példa:
A párhuzamossági skálázási információkat néhány más tábla és nézet is tárolja, például az SVCS_CONCURRENCY_SCALING_USAGE. Ezenkívül számos katalógustábla található, amelyek a párhuzamos skálázással kapcsolatos információkat tárolják.
Álláspontja
A szerzők 18. 30. 00-én hozzávetőleg 29.03.2019:3:20-kor kezdték meg a párhuzamos skálázást a belső fürt egyik sorában. A max_concurrency_scaling_clusters paramétert 30-ra módosították 00. 29.03.2019. XNUMX-én körülbelül XNUMX:XNUMX:XNUMX-kor.
Egy kérési sor szimulálásához 15-ről 5-re csökkentettük a sor réseinek számát.
Az alábbiakban egy intermix.io irányítópult diagramja látható, amely a helyek számának csökkentése után futó és sorban állási kérelmek számát mutatja.
Úgy látjuk, hogy a sorban lévő kérések várakozási ideje megnőtt, a maximális idő több mint 5 perc.
Íme az AWS-konzolról származó releváns információk az idő alatt történtekről:
A Redshift három (3) párhuzamos skálázási klasztert indított el a konfigurált módon. Úgy tűnik, hogy ezek a fürtök kihasználatlanok voltak, annak ellenére, hogy a fürtünkben sok kérés sorba állt.
A használati grafikon korrelál a skálázási tevékenység grafikonjával:
Néhány óra elteltével a szerzők ellenőrizték a sort, és úgy tűnt, hogy 6 kérés fut párhuzamos skálázással. Két kérést is véletlenszerűen teszteltünk a felhasználói felületen keresztül. Nem ellenőriztük, hogyan kell használni ezeket az értékeket, ha egyszerre több párhuzamos klaszter aktív.
Álláspontja
A párhuzamos skálázás csökkentheti a kérések sorban töltött idejét a csúcsterhelések idején.
Az alapteszt eredményei alapján kiderült, hogy részben javult a helyzet a kérések betöltésével kapcsolatban. A párhuzamos skálázás önmagában azonban nem oldott meg minden párhuzamossági problémát.
Ennek oka a párhuzamos skálázást használó lekérdezések típusaira vonatkozó korlátozások. Például a szerzőknek sok táblájuk van átlapolt rendezési kulcsokkal, és a munkaterhelésünk nagy része az írás.
Bár a párhuzamos skálázás nem univerzális megoldás a WLM beállítására, ennek a funkciónak a használata egyszerű és egyértelmű.
Ezért a szerző azt javasolja, hogy használja a WLM-várólistákhoz. Kezdje egy párhuzamos fürttel, és figyelje a csúcsterhelést a konzolon keresztül annak megállapításához, hogy az új fürtök teljes mértékben kihasználva vannak-e.
Ahogy az AWS további lekérdezéstípusokat és táblákat is támogat, a párhuzamos skálázásnak fokozatosan egyre hatékonyabbá kell válnia.
Daniyar Belkhodzhaev, Skyeng adatmérnök megjegyzése
Mi a Skyengnél is azonnal észrevettük a párhuzamos skálázás felbukkanó lehetőségét.
A funkcionalitás nagyon vonzó, különös tekintettel arra, hogy az AWS becslései szerint a legtöbb felhasználónak nem is kell külön fizetnie érte.Történt, hogy április közepén szokatlanul sok kérés érkezett a Redshift klaszterhez. Ebben az időszakban gyakran folyamodtunk a Concurrency Scalinghoz, néha egy további fürt a nap 24 órájában, megállás nélkül működött.
Ez lehetővé tette, ha nem is teljesen megoldani a problémát a sorokkal, de legalább a helyzetet elfogadhatóvá tenni.
Megfigyeléseink nagyrészt egybeesnek az intermix.io srácainak benyomásaival.
Azt is észrevettük, hogy bár voltak kérések a sorban, nem minden kérés került azonnal továbbításra a párhuzamos fürtbe. Nyilvánvalóan ez azért történik, mert a párhuzamos fürt elindítása még mindig időbe telik. Emiatt a rövid távú csúcsterhelések idején továbbra is kis sorban állunk, és a megfelelő riasztásoknak van idejük kioldani.
Áprilisban megszabadulva az abnormális terhelésektől, az AWS elvárásainak megfelelően alkalmi használati módba léptünk - a szabad normán belül.
Az AWS Cost Explorer alkalmazásban nyomon követheti párhuzamos skálázási költségeit. Ki kell választania a Service - Redshift, a Usage Type - CS lehetőséget, például USW2-CS:dc2.large.Az árakról bővebben oroszul olvashat
Forrás: will.com