real time - Tormenta pico pico pendiente
real-time apache-storm (3)
Esta es una pregunta sobre cómo funciona el pico de la tormenta de pendiente. Actualmente tengo un pico que lee un archivo y emite una tupla para cada línea en el archivo (sé que storm no es la mejor solución para tratar archivos, pero no tengo una opción para este problema). Establecí el pico máximo pendiente a 50k para acelerar cuántas tuplas entran en la topología para ser procesadas. Sin embargo, veo que este número no tiene ningún efecto en la topología. Veo todos los registros en un archivo que se emite cada vez. Supongo que esto podría deberse a un bucle que tengo en el método nextTuple que emite todos los registros en un archivo. Entonces, mi pregunta es ¿Storm simplemente deja de llamar a la siguiente tupla para la tarea del pico cuando se alcanza el pico máximo pendiente? ¿Significa esto que solo debería emitir una tupla cada vez que se llame nextTuple?
¡Exactamente! Storm solo puede limitar su pico con el siguiente comando, así que si transmite todo cuando recibe el primer siguiente, Storm no tiene forma de estrangular su pico.
Los desarrolladores de Storm recomiendan emitir una sola tupla con un siguiente comando. El marco Storm luego acelerará su pico según sea necesario para cumplir con el requisito de "máximo pico pendiente". Si está emitiendo un gran número de tuplas, puede agrupar sus emisiones en un máximo de una décima parte de su pico máximo pendiente, para darle a Storm la posibilidad de acelerar.
Las topologías de tormenta tienen un parámetro de pico máximo pendiente. El valor máximo de la boquilla pendiente para una topología se puede configurar a través de la configuración "topology.max.spout.pending" en el archivo yaml de configuración de topología. Este valor pone un límite a la cantidad de tuplas que pueden estar en vuelo, es decir, aún no se ha recuperado o fallado, en una topología de Storm en cualquier momento. La necesidad de este parámetro proviene del hecho de que Storm utiliza ZeroMQ para enviar tuplas de una tarea a otra. Si el lado del consumidor de ZeroMQ no puede mantenerse al día con la tasa de tupla, entonces la cola de ZeroMQ comienza a construirse. Finalmente, las tuplas se agotan en el pico y se vuelven a reproducir en la topología, lo que aumenta la presión en las colas. Para evitar este caso de falla patológica, Storm le permite al usuario poner un límite en la cantidad de tuplas que están en vuelo en la topología. Este límite tiene efecto en una base por tarea y no en un nivel de topología. ( source ) Para los casos en que las boquillas no son confiables, es decir, no emiten un ID de mensaje en sus tuplas, este valor no tiene efecto. Uno de los problemas a los que se enfrentan continuamente los usuarios de Storm es encontrar el valor correcto para este parámetro de pico de pico máximo. Un valor muy pequeño puede fácilmente destruir la topología y un valor suficientemente grande puede sobrecargar la topología con un gran número de tuplas hasta el punto de causar fallas y repeticiones. Los usuarios tienen que pasar por varias iteraciones de implementaciones de topología con diferentes valores de pico de salida máximo para encontrar el valor que mejor se adapte a ellos.
Una solución es crear la cola de entrada fuera del método nextTuple y lo único que se debe hacer en nextTuple es encuestar la cola y emitir. Si está procesando varios archivos, el método nextTuple también debe verificar si el resultado de sondear la cola es nulo y, en caso afirmativo, restablecer atómicamente el archivo de origen que está llenando su cola.