Bei Skyeng nutzen wir Amazon Redshift inklusive paralleler Skalierung, daher fanden wir diesen Artikel von Stefan Gromoll, Gründer von dotgo.com, für intermix.io interessant. Nach der Übersetzung ein kleiner Erfahrungsbericht des Dateningenieurs Daniyar Belkhodzhaev.
ermöglicht die Skalierung durch Hinzufügen neuer Knoten zum Cluster. Die Notwendigkeit, eine Spitzenzahl an Anfragen zu bewältigen, kann zu einer Überversorgung der Knoten führen. Parallelitätsskalierung erhöht im Gegensatz zum Hinzufügen neuer Knoten die Rechenleistung nach Bedarf.
Durch die parallele Skalierung von Amazon Redshift erhalten Redshift-Cluster zusätzliche Kapazität zur Bewältigung von Spitzenanfragevolumina. Es funktioniert, indem es Anfragen in neue „parallele“ Cluster im Hintergrund verschiebt. Anforderungen werden basierend auf der WLM-Konfiguration und den WLM-Regeln weitergeleitet.
Die parallel skalierende Preisgestaltung basiert auf einem Kreditmodell mit einem kostenlosen Kontingent. Über kostenlose Credits hinaus basiert die Zahlung auf der Zeit, die der Parallel Scaling Cluster Anfragen verarbeitet.
Der Autor hat die parallele Skalierung auf einem der internen Cluster getestet. In diesem Beitrag wird er über die Testergebnisse sprechen und Tipps für den Einstieg geben.
Clusteranforderungen
Um die parallele Skalierung nutzen zu können, muss Ihr Amazon-Redshift-Cluster die folgenden Anforderungen erfüllen:
- Plattform: EC2-VPC;
— Knotentyp: dc2.8xlarge, ds2.8xlarge, dc2.large oder ds2.xlarge;
— Anzahl der Knoten: von 2 bis 32 (Einzelknotencluster werden nicht unterstützt).
Akzeptable Anforderungstypen
Die parallele Skalierung ist nicht für alle Arten von Abfragen geeignet. In der ersten Version verarbeitet es nur Leseanfragen, die drei Bedingungen erfüllen:
— SELECT-Abfragen sind schreibgeschützt (obwohl weitere Typen geplant sind);
— Die Abfrage verweist nicht auf eine Tabelle mit dem Sortierstil INTERLEAVED.
– Die Abfrage verwendet Amazon Redshift Spectrum nicht, um auf externe Tabellen zu verweisen.
Um an den Parallel Scaling Cluster weitergeleitet zu werden, muss die Anforderung in die Warteschlange gestellt werden. Darüber hinaus sind für die Warteschlange geeignete Abfragen zulässig wird nicht auf parallel skalierten Clustern ausgeführt.
Warteschlangen und SQA erfordern eine ordnungsgemäße Konfiguration . Wir empfehlen, zunächst Ihr WLM zu optimieren – dadurch wird der Bedarf an paralleler Skalierung reduziert. Und das ist wichtig, denn die parallele Skalierung ist nur für eine bestimmte Anzahl von Stunden kostenlos. AWS behauptet, dass die parallele Skalierung für 97 % der Kunden kostenlos sein wird, was uns zum Thema Preis bringt.
Kosten der Parallelskalierung
AWS bietet ein Credit-Modell für die parallele Skalierung an. Jeder aktive Cluster Sammelt Credits stündlich, bis zu einer Stunde kostenloses Credits für die parallele Skalierung pro Tag.
Sie zahlen nur, wenn Ihre Parallel Scaling Clusters-Nutzung die Menge an Credits übersteigt, die Sie erhalten haben.
Die Kosten werden mit einem On-Demand-Tarif pro Sekunde für einen parallelen Cluster berechnet, der über dem kostenlosen Tarif genutzt wird. Ihnen wird nur die Dauer Ihrer Anfragen in Rechnung gestellt, mit einer Mindestgebühr von einer Minute für jede Aktivierung eines Parallel Scaling Clusters. Der sekundengenaue On-Demand-Tarif wird nach allgemeinen Preisprinzipien berechnet Das heißt, es hängt vom Knotentyp und der Anzahl der Knoten in Ihrem Cluster ab.
Parallele Skalierung starten
Die parallele Skalierung wird für jede WLM-Warteschlange ausgelöst. Gehen Sie zur AWS Redshift-Konsole und wählen Sie im linken Navigationsmenü Workload Management aus. Wählen Sie die WLM-Parametergruppe Ihres Clusters aus dem folgenden Dropdown-Menü aus.
Neben jeder Warteschlange wird eine neue Spalte mit dem Namen „Concurrency Scaling Mode“ angezeigt. Die Standardeinstellung ist „Deaktiviert“. Klicken Sie auf „Bearbeiten“ und Sie können die Einstellungen für jede Warteschlange ändern.
Konfiguration
Die parallele Skalierung funktioniert durch die Weiterleitung entsprechender Anfragen an neue dedizierte Cluster. Neue Cluster haben die gleiche Größe (Typ und Anzahl der Knoten) wie der Hauptcluster.
Die Standardanzahl der für die parallele Skalierung verwendeten Cluster beträgt eins (1), wobei insgesamt bis zu zehn (10) Cluster konfiguriert werden können.
Die Gesamtzahl der Cluster für die parallele Skalierung kann durch den Parameter max_concurrency_scaling_clusters festgelegt werden. Durch Erhöhen des Werts dieses Parameters werden zusätzliche redundante Cluster bereitgestellt.
Überwachung
In der AWS Redshift-Konsole sind mehrere zusätzliche Diagramme verfügbar. Das Diagramm „Maximal konfigurierte Parallelitätsskalierungscluster“ zeigt den Wert von „max_concurrency_scaling_clusters“ im Zeitverlauf an.
Die Anzahl der aktiven Skalierungscluster wird in der Benutzeroberfläche im Abschnitt „Concurrency Scaling Activity“ angezeigt:
Auf der Registerkarte „Abfragen“ gibt es eine Spalte, die angibt, ob die Abfrage im Hauptcluster oder im Parallelskalierungscluster ausgeführt wurde:
Unabhängig davon, ob eine bestimmte Abfrage im Hauptcluster oder über einen parallelen Skalierungscluster ausgeführt wurde, wird sie in stl_query.concurrency_scaling_status gespeichert.
Der Wert 1 gibt an, dass die Abfrage im Parallelskalencluster ausgeführt wurde, während andere Werte angeben, dass sie im Primärcluster ausgeführt wurde.
Beispiel:
Informationen zur Parallelitätsskalierung werden auch in einigen anderen Tabellen und Ansichten gespeichert, z. B. SVCS_CONCURRENCY_SCALING_USAGE. Darüber hinaus gibt es eine Reihe von Katalogtabellen, in denen Informationen zur parallelen Skalierung gespeichert sind.
Ergebnisse
Die Autoren begannen am 18 um etwa 30:00:29.03.2019 Uhr GMT mit der parallelen Skalierung für eine Warteschlange im internen Cluster. Der Parameter max_concurrency_scaling_clusters wurde am 3 um etwa 20:30:00 Uhr auf 29.03.2019 geändert.
Um eine Anforderungswarteschlange zu simulieren, haben wir die Anzahl der Slots für diese Warteschlange von 15 auf 5 reduziert.
Unten finden Sie ein intermix.io-Dashboard-Diagramm, das die Anzahl der ausgeführten und in der Warteschlange stehenden Anfragen nach Reduzierung der Anzahl der Slots zeigt.
Wir sehen, dass die Wartezeit für Anfragen in der Warteschlange gestiegen ist und die maximale Zeit mehr als 5 Minuten beträgt.
Hier sind die relevanten Informationen aus der AWS-Konsole darüber, was in dieser Zeit passiert ist:
Redshift hat je nach Konfiguration drei (3) parallele Skalierungscluster gestartet. Es scheint, dass diese Cluster nicht ausgelastet waren, obwohl viele Anfragen in unserem Cluster in der Warteschlange standen.
Das Nutzungsdiagramm korreliert mit dem Skalierungsaktivitätsdiagramm:
Nach ein paar Stunden überprüften die Autoren die Warteschlange und es sah so aus, als würden 6 Anfragen mit paralleler Skalierung ausgeführt. Außerdem haben wir zwei Anfragen stichprobenartig über die Benutzeroberfläche getestet. Wir haben nicht überprüft, wie diese Werte verwendet werden, wenn mehrere parallele Cluster gleichzeitig aktiv sind.
Befund
Durch die parallele Skalierung kann die Zeit verkürzt werden, die Anfragen bei Spitzenlasten in der Warteschlange verbringen.
Basierend auf den Ergebnissen des Basistests zeigte sich, dass sich die Situation bei den Ladeanfragen teilweise verbessert hat. Allerdings löste die parallele Skalierung allein nicht alle Parallelitätsprobleme.
Dies ist auf Einschränkungen bei den Abfragetypen zurückzuführen, die parallele Skalierung verwenden können. Beispielsweise haben die Autoren viele Tabellen mit verschachtelten Sortierschlüsseln und der größte Teil unserer Arbeitsbelastung besteht aus dem Schreiben.
Obwohl die parallele Skalierung keine universelle Lösung für die Einrichtung von WLM ist, ist die Verwendung dieser Funktion einfach und unkompliziert.
Daher empfiehlt der Autor, es für Ihre WLM-Warteschlangen zu verwenden. Beginnen Sie mit einem parallelen Cluster und überwachen Sie die Spitzenlast über die Konsole, um festzustellen, ob die neuen Cluster vollständig ausgelastet sind.
Da AWS zusätzliche Abfragetypen und Tabellen unterstützt, sollte die parallele Skalierung nach und nach immer effizienter werden.
Kommentar von Daniyar Belkhodzhaev, Skyeng Data Engineer
Auch wir bei Skyeng bemerkten sofort die sich abzeichnende Möglichkeit der Parallelskalierung.
Die Funktionalität ist sehr attraktiv, insbesondere wenn man bedenkt, dass AWS davon ausgeht, dass die meisten Benutzer dafür nicht einmal extra bezahlen müssen.So kam es, dass wir Mitte April eine ungewöhnliche Flut von Anfragen an den Redshift-Cluster erhielten. In dieser Zeit griffen wir häufig auf Parallelitätsskalierung zurück; manchmal arbeitete ein zusätzlicher Cluster 24 Stunden am Tag ohne Unterbrechung.
Dies ermöglichte es, das Warteschlangenproblem zwar nicht vollständig zu lösen, die Situation aber zumindest akzeptabel zu machen.
Unsere Beobachtungen decken sich weitgehend mit den Eindrücken der Jungs von intermix.io.
Außerdem ist uns aufgefallen, dass zwar Anfragen in der Warteschlange warteten, aber nicht alle Anfragen sofort an den Parallelcluster weitergeleitet wurden. Anscheinend geschieht dies, weil der Parallelcluster noch einige Zeit zum Starten benötigt. Dadurch kommt es bei kurzfristigen Spitzenlasten immer noch zu kleinen Warteschlangen und die entsprechenden Alarme haben Zeit zum Auslösen.
Nachdem wir im April ungewöhnliche Belastungen beseitigt hatten, wechselten wir, wie von AWS erwartet, in den gelegentlichen Nutzungsmodus – innerhalb der kostenlosen Norm.
Sie können Ihre Parallelskalierungskosten im AWS Cost Explorer verfolgen. Sie müssen Service – Redshift, Nutzungstyp – CS auswählen, zum Beispiel USW2-CS:dc2.large.Weitere Informationen zu den Preisen finden Sie auf Russisch
Source: habr.com