Resistencia

Flink utiliza la resistencia para adaptar la velocidad de procesamiento de los operadores individuales.

El operador puede tener dificultades para seguir procesando el volumen de mensajes que recibe por muchas razones. La operación puede requerir más CPU recursos de los que dispone el operador. Es posible que el operador espere a que se completen las operaciones de E/S. Si un operador no puede procesar los eventos con la suficiente rapidez, se genera una resistencia en los operadores de las fases anteriores, lo que repercute en el operador lento. Esto provoca que los operadores de las fases anteriores reduzcan la velocidad, lo que puede propagar aún más la resistencia a la fuente y hacer que la fuente se adapte al rendimiento general de la aplicación, al reducir también la velocidad. Puede encontrar una descripción más detallada de la resistencia y su funcionamiento en Cómo maneja Apache Flink™ la resistencia.

Saber qué operadores de una aplicación son lentos le proporciona información crucial para comprender la causa raíz de los problemas de rendimiento en la aplicación. La información sobre la resistencia se expone a través del panel de control de Flink. Para identificar al operador lento, busque al operador con un valor de resistencia alto que esté más cerca de un receptor (el operador B en el siguiente ejemplo). El operador que provoca la lentitud es entonces uno de los operadores de una fase posterior (en el ejemplo, el operador C). B podría procesar los eventos más rápido, pero enfrenta resistencia, ya que no puede reenviar la salida al operador C que realmente está lento.

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

Una vez que haya identificado al operador lento, intente entender por qué es lento. Puede haber una infinidad de razones y, a veces, no es obvio cuál es el problema y su solución puede requerir días de depuración y creación de perfiles. Las siguientes son algunas razones obvias y más comunes, algunas de las cuales se explican con más detalle a continuación:

• El operador realiza operaciones de I/O lentas, por ejemplo, llamadas de red (considere usar AsyncIO en su lugar).

• Hay un sesgo en los datos y un operador recibe más eventos que otros (compruébelo observando la cantidad de mensajes que entran y salen de las subtareas individuales (es decir, instancias del mismo operador) en el panel de control de Flink.

• Es una operación que requiere muchos recursos (si no hay un sesgo en los datos, considere la posibilidad de ampliarla para el trabajo limitado a CPU /memoria o ParallelismPerKPU aumentarla para el trabajo vinculado a la E/S)

• Registro exhaustivo por parte del operador (reduzca el registro al mínimo para la aplicación de producción o, en su lugar, considere enviar los resultados de la depuración a un flujo de datos).

Probando el rendimiento con el disipador de descartes

El receptor de descarte simplemente ignora todos los eventos que recibe mientras sigue ejecutando la aplicación (una aplicación sin ningún receptor no se ejecuta). Esto resulta muy útil para realizar pruebas de rendimiento, crear perfiles y comprobar si la aplicación se está escalando correctamente. También es un control de estado muy pragmático para comprobar si los receptores están causando la resistencia o la aplicación (pero comprobar las métricas de resistencia suele ser más fácil y sencillo).

Al sustituir todos los receptores de una aplicación por un receptor de descarte y crear una fuente simulada que genere datos que se parezcan a los de producción, se puede medir el rendimiento máximo de la aplicación para una configuración de paralelismo determinada. A continuación, también puede aumentar el paralelismo para comprobar que la aplicación se escala correctamente y que no presenta ningún cuello de botella que solo surja a medida que aumenta el rendimiento (por ejemplo, debido al sesgo de datos).