[Selección de Flink] ¿Cómo solucionar problemas de excepciones de puntos de control?
El sistema distribuido implementa la función de retención del estado global.
① La solución tradicional utiliza un reloj unificado y lo transmite a cada nodo esclavo a través del nodo maestro. Cuando el esclavo lo recibe, registra su estado. Desventajas: punto único de falla, inconsistencia de datos (retraso/falla), inestabilidad del sistema.
② Flink utiliza Barrier como señal de transmisión del punto de control, que es lo mismo que los datos comerciales.
Cada trabajo de Flink tiene un JobManager, y el coordinador de puntos de control en JobManager administra el proceso de puntos de control de todo el trabajo. El usuario establece el intervalo del punto de control a través de env, de modo que el coordinador del punto de control enviará periódicamente barreras de punto de control a cada subtarea de origen.
Cuando una instancia de operador de origen recibe una barrera, suspende su propio procesamiento de datos y luego guarda su estado de datos actualmente almacenado en caché como una instantánea en el almacenamiento especificado. Finalmente, la instancia del operador envía de forma asincrónica una señal de confirmación al coordinador del punto de control, transmite la barrera a todos los operadores posteriores y reanuda su propio procesamiento de datos.
Por analogía, cada operador toma instantáneas continuamente y transmite la barrera aguas abajo hasta que la barrera pasa a la instancia del operador receptor, momento en el cual se determina que la instantánea global está completa.
La interfaz de usuario web de Flink tiene información de monitoreo de puntos de control, incluidas estadísticas e información detallada para cada punto de control. Como se muestra en la figura siguiente, puede ver en el cuadro rojo que un determinado * * * activó 569K puntos de control y luego todas las fallas se completaron con éxito sin fallas.
Como se muestra en la figura siguiente, haga clic en "+" de un punto de control para conocer la información detallada del punto de control.
(1) Confirmado indica cuántas subtareas han confirmado este punto de control. Como se puede ver en la figura, * * * tiene tres operadores, divididos en dos subtareas, y ambas subtareas han completado el reconocimiento.
(2) La última confirmación indica la última hora de confirmación de todas las subtareas.
③ La duración de un extremo a otro indica el tiempo más largo para completar la instantánea entre todas las subtareas; /p>
④El tamaño del estado indica el tamaño del estado del punto de control actual (si es un punto de control incremental, indica el tamaño incremental
⑤El búfer durante la alineación indica cuántos datos se han acumulado); durante la fase de alineación de la barrera (si los datos son demasiado grandes, lo que indirectamente significa que la alineación es lenta);
Como se muestra en la figura siguiente, la interfaz del punto de control de la interfaz de usuario web de Flink no pudo mostrar el punto de control 10432. Haga clic en el signo "+" en la información detallada del punto de control 10423 para obtener la información confirmada y la información confirmada más reciente.
Ver el registro de JobManager jobmanager.log Los registros clave son los siguientes.
Análisis: 10423 es el ID del punto de control, 0 b 60 f 08 BF 8984085 b 59 F8 d 9 BC 74 ce 2e 1 es el ID de la subtarea, 85d 268 E6 FBC 1941185 Fe 4868.
Desde el registro de jobmanager.log anterior, podemos conocer la identificación de la subtarea y la identificación del trabajo, y podemos determinar el administrador de tareas y la ranura.
Como se puede ver en el registro anterior, la subtarea está programada para el contenedor _ E24 _ 1566836790522 _ 8088 _ 04 _ 0155 _ 1 ranura del nombre de host del nodo ABCDE. Luego vaya al taskmanager.log del contenedor _ E24 _ 1566836790522 _ 8088 _ 04 _ 013155 para encontrar el motivo específico de la falla del punto de control.
Si el punto de control más pequeño está desalineado y Flink recibe un punto de control más grande, cancelará el punto de control más pequeño. Los registros de claves son los siguientes.
El registro muestra que el punto de control actual 19 todavía está en la etapa de alineación, se recibió el nivel del punto de control 20 y luego se canceló la tarea posterior del punto de control 19. También se informará a JM que el punto de control actual 19. El puesto de control se ha caído.
Cuando la tarea descendente recibe el nivel cancelado, se imprime el siguiente registro de claves, que indica que la tarea actual ha recibido el mensaje de cancelación de nivel enviado por el nivel ascendente, cancelando así el punto de control correspondiente.
Si el punto de control se completa muy lentamente y no se completa después del tiempo de espera, todo el punto de control también fallará. Por ejemplo, si el punto de control 21 falla debido al tiempo de espera, el registro de claves de jobmanager.log es el siguiente.
Luego abra el registro de nivel de depuración. La instantánea de taskmananger.log se divide en tres fases: antes de que comience la instantánea, la fase de sincronización y la fase asincrónica:
El punto de control es lento. , como el intervalo del punto de control de 1 minuto, más 10 minutos de tiempo extra. Los puntos de control suelen tardar 9 minutos y el tamaño real del estado es mucho mayor de lo esperado.
Una breve introducción al mecanismo de alineación de barrera del punto de control: después de que un operador recibe la barrera n de un flujo de entrada, no puede procesar ningún registro de datos de ese flujo hasta que reciba la barrera n de todas las demás entradas. Como se muestra en la figura siguiente, después de que el operador recibe la barrera n del flujo digital, los datos del flujo digital se colocarán en el búfer de entrada en lugar de procesarse. Antes de que la barrera n del flujo alfabético llegue al operador, el operador envía los datos de la barrera n y el búfer en sentido descendente y toma su propia instantánea al mismo tiempo.
Debido al mecanismo de alineación de la cerca, el operador necesita recibir toda la cerca n aguas arriba antes de tomar una instantánea. Si hay contrapresión o datos sesgados en un trabajo, puede hacer que todos o algunos canales se ralenticen, lo que afecta los tiempos de los puntos de control en general. Como se muestra en la figura siguiente, el volumen de datos de la subtarea y la contrapresión se monitorean a través de la interfaz de usuario web de Flink.
Este artículo presenta un mecanismo de alineación de obstáculos en el punto de control, y solo se puede activar una instantánea cuando el operador recoge obstáculos aguas arriba n. Por ejemplo, StateBackend es RocksDB. Los datos se guardan en RocksDB al comienzo de la instantánea y luego RocksDB se conserva en FS de forma asincrónica. Si la barrera n siempre está desalineada, no comenzará a tomar instantáneas.
Hay dos modos de punto de control: punto de control completo y punto de control incremental. El punto de control completo realizará una copia de seguridad de todo el estado actual en el almacenamiento persistente al mismo tiempo, mientras que el punto de control incremental solo realizará una copia de seguridad del estado que no existe en el último punto de control, por lo que el contenido cargado por el punto de control incremental será relativamente mejor cada vez, en términos de velocidad Habrá mayores ventajas.
Si encuentra que la fase de sincronización es muy lenta a través del registro, puede considerar activar instantáneas asincrónicas para no RocksDBBackend. Si tiene instantáneas asíncronas habilitadas pero aún son lentas, debe usar AsyncProfile para ver la JVM completa.
Para RocksDBBackend, use iostate para verificar la presión en el disco y también verifique el registro de RocksDB de TaskMananger para verificar la sobrecarga total del tiempo de la instantánea.
En la fase asíncrona, TaskManager principalmente realiza una copia de seguridad del estado en el almacenamiento persistente HDFS. Para los que no son RocksDBBackend, el principal cuello de botella proviene de la red. Puede considerar observar las métricas de su red o utilizar iftop para observar el tráfico de red en la máquina correspondiente.
Para RocksDB, los archivos deben leerse localmente y escribirse en el almacenamiento persistente remoto HDFS, por lo que no solo se debe considerar el cuello de botella de la red, sino también el rendimiento del disco local.
La probabilidad de que se produzca este escenario es relativamente pequeña. Cuando la fuente toma la instantánea y envía la barrera aguas abajo, necesita adquirir el bloqueo. Si no sigues agarrando la cerradura, es posible que el punto de control nunca tenga la oportunidad de hacerlo. Si el registro para iniciar el punto de control no se puede encontrar en taskmanager.log donde se encuentra la fuente, puede considerar si este es el caso y puede confirmar aún más el bloqueo a través de jstack.