Gegendruck

Flink nutzt Gegendruck, um die Verarbeitungsgeschwindigkeit einzelner Operatoren anzupassen.

Der Operator kann aus vielen Gründen Schwierigkeiten haben, das Nachrichtenvolumen, das er empfängt, weiter zu verarbeiten. Der Vorgang benötigt möglicherweise mehr CPU Ressourcen, als der Bediener zur Verfügung hat. Der Operator wartet möglicherweise, bis die I/O-Operationen abgeschlossen sind. Wenn ein Operator Ereignisse nicht schnell genug verarbeiten kann, entsteht ein Gegendruck bei den vorgeschalteten Operatoren, die in den langsamen Operator einspeisen. Dies führt dazu, dass die vorgelagerten Operatoren langsamer werden, wodurch sich der Gegendruck zur Quelle weiter ausbreiten kann und die Quelle sich an den Gesamtdurchsatz der Anwendung anpasst, indem sie ebenfalls langsamer wird. Eine ausführlichere Beschreibung von Gegendruck und seiner Funktionsweise finden Sie unter So handhabt Apache Flink™ Gegendruck.

Wenn Sie wissen, welche Operatoren in einer Anwendung langsam sind, erhalten Sie wichtige Informationen, um die Ursache von Leistungsproblemen in der Anwendung zu verstehen. Informationen zum Gegendruck werden über das Flink-Dashboard angezeigt. Um den langsamen Operator zu identifizieren, suchen Sie nach dem Operator mit einem hohen Gegendruckwert, der einer Senke am nächsten ist (im folgenden Beispiel Operator B). Der Operator, der die Langsamkeit verursacht, ist dann einer der nachgeschalteten Operatoren (im Beispiel Operator C). B könnte Ereignisse schneller verarbeiten, gerät jedoch unter Druck, da er die Ausgabe nicht an den langsamen Operator C weiterleiten kann.

A (backpressured 93%) -> B (backpressured 85%) -> C (backpressured 11%) -> D (backpressured 0%)

Sobald Sie den langsamen Operator identifiziert haben, versuchen Sie zu verstehen, warum er langsam ist. Es kann viele Gründe dafür geben, und manchmal ist nicht klar, was das Problem ist. Es kann Tage des Debuggens und Profilings erfordern, um das Problem zu lösen. Im Folgenden sind einige offensichtliche und häufigere Gründe aufgeführt, von denen einige im Folgenden näher erläutert werden:

• Der Operator führt langsame E/A durch, z. B. Netzwerkaufrufe (erwägen Sie stattdessen die Verwendung von AsyncIO).

• Die Daten sind verzerrt und ein Operator empfängt mehr Ereignisse als andere (überprüfen Sie dies, indem Sie sich die Anzahl der eingehenden/ausgehenden Nachrichten einzelner Unteraufgaben (d. h. Instances desselben Operators) im Flink-Dashboard ansehen.

• Es handelt sich um einen ressourcenintensiven Vorgang (wenn es keine Datenverzerrung gibt, sollten Sie bei Arbeit, die an den CPU Arbeitsspeicher gebunden ist, die Skalierung erwägen oder die Skalierung ParallelismPerKPU bei I/O-gebundener Arbeit erhöhen)

• Umfangreiche Protokollierung durch den Operator (reduzieren Sie die Protokollierung auf ein Minimum für Produktionsanwendungen oder erwägen Sie, stattdessen die Debug-Ausgabe an einen Datenstrom zu senden).

Testen des Durchsatzes mit dem Discarding Sink

Die Verwurfsenke ignoriert einfach alle Ereignisse, die sie empfängt, während die Anwendung weiterhin ausgeführt wird (eine Anwendung ohne Senke kann nicht ausgeführt werden). Dies ist sehr nützlich für Durchsatztests, zum Profiling und um zu überprüfen, ob die Anwendung ordnungsgemäß skaliert. Es ist außerdem eine sehr pragmatische Plausibilitätsprüfung, um zu überprüfen, ob die Senken einen Gegendruck erzeugen oder die Anwendung (aber die bloße Überprüfung der Gegendruckmetriken ist oft einfacher und unkomplizierter).

Indem Sie alle Senken einer Anwendung durch eine Verwurfsenke ersetzen und eine Mock-Quelle erstellen, die Daten generiert, die Produktionsdaten ähneln, können Sie den maximalen Durchsatz der Anwendung für eine bestimmte Parallelitätseinstellung messen. Sie können dann auch die Parallelität erhöhen, um sicherzustellen, dass die Anwendung ordnungsgemäß skaliert und keinen Engpass aufweist, der erst bei höherem Durchsatz auftritt (z. B. aufgrund einer verzerrten Datenverteilung).