¿Cuál es la diferencia principal entre Flink y Storm?


137

Flink se ha comparado con Spark , que, según yo lo veo, es la comparación incorrecta porque compara un sistema de procesamiento de eventos en ventana con micro lotes; Del mismo modo, no tiene mucho sentido para mí comparar Flink con Samza. En ambos casos, compara una estrategia de procesamiento de eventos en tiempo real frente a un lote, incluso si se trata de una "escala" más pequeña en el caso de Samza. Pero me gustaría saber cómo se compara Flink con Storm, que conceptualmente parece mucho más similar.

He encontrado esto (Diapositiva # 4) documentando la diferencia principal como "latencia ajustable" para Flink. Otra pista parece ser un artículo de Slicon Angle que sugiere que Flink se integra mejor en un mundo de Spark o HadoopMR, pero no se mencionan ni hacen referencia a detalles reales. Finalmente, el propio Fabian Hueske señala en una entrevista que "En comparación con Apache Storm, la funcionalidad de análisis de flujo de Flink ofrece una API de alto nivel y utiliza una estrategia de tolerancia a fallas más liviana para proporcionar garantías de procesamiento exactamente una vez".

Todo eso es un poco escaso para mí y no entiendo bien el punto. ¿Alguien puede explicar qué problema (s) con el procesamiento de flujo en Storm es (son?) Resuelto exactamente por Flink? ¿A qué se refiere Hueske por los problemas de API y su "estrategia de tolerancia a fallas más liviana"?


2
Tenga en cuenta que Apache Spark (el foco de la pregunta vinculada) no es lo mismo que Apache Storm (esta pregunta aquí), por lo tanto, no, esto no es un duplicado.
fnl

Respuestas:


213

Descargo de responsabilidad : soy un confirmador de Apache Flink y miembro de PMC y solo estoy familiarizado con el diseño de alto nivel de Storm, no con sus componentes internos.

Apache Flink es un marco para el flujo unificado y el procesamiento por lotes. El tiempo de ejecución de Flink admite de forma nativa ambos dominios debido a las transferencias de datos canalizados entre tareas paralelas que incluyen barajamientos canalizados. Los registros se envían inmediatamente de las tareas de producción a las tareas de recepción (después de ser recopilados en un búfer para la transferencia de red). Los trabajos por lotes se pueden ejecutar opcionalmente mediante el bloqueo de transferencias de datos.

Apache Spark es un marco que también admite el procesamiento por lotes y por secuencias. La API por lotes de Flink se ve bastante similar y aborda casos de uso similares a los de Spark, pero difiere en lo interno. Para la transmisión, ambos sistemas siguen enfoques muy diferentes (mini lotes frente a la transmisión), lo que los hace adecuados para diferentes tipos de aplicaciones. Yo diría que comparar Spark y Flink es válido y útil, sin embargo, Spark no es el motor de procesamiento de flujo más similar a Flink.

Volviendo a la pregunta original, Apache Storm es un procesador de flujo de datos sin capacidades por lotes. De hecho, el motor canalizado de Flink se parece internamente a Storm, es decir, las interfaces de las tareas paralelas de Flink son similares a los tornillos de Storm. Storm y Flink tienen en común que su objetivo es el procesamiento de flujo de baja latencia mediante transferencias de datos canalizadas. Sin embargo, Flink ofrece una API de más alto nivel en comparación con Storm. En lugar de implementar la funcionalidad de los tornillos con uno o más lectores y recolectores, la API DataStream de Flink proporciona funciones como Map, GroupBy, Window y Join. Mucha de esta funcionalidad debe implementarse manualmente cuando se usa Storm. Otra diferencia es la semántica de procesamiento. Storm garantiza el procesamiento al menos una vez, mientras que Flink proporciona exactamente una vez. Las implementaciones que dan estas garantías de procesamiento difieren bastante. Mientras que Storm usa reconocimientos a nivel de registro, Flink usa una variante del algoritmo Chandy-Lamport. En pocas palabras, las fuentes de datos inyectan marcadores periódicamente en el flujo de datos. Cada vez que un operador recibe dicho marcador, controla su estado interno. Cuando todos los receptores de datos reciben un marcador, el marcador (y todos los registros que se han procesado antes) se confirman. En caso de falla, todos los operadores de fuentes se restablecen a su estado cuando vieron el último marcador comprometido y el procesamiento continúa. Este enfoque de marcador-punto de control es más liviano que los reconocimientos a nivel de registro de Storm. Esta Las fuentes de datos inyectan marcadores periódicamente en el flujo de datos. Cada vez que un operador recibe dicho marcador, controla su estado interno. Cuando todos los receptores de datos reciben un marcador, el marcador (y todos los registros que se han procesado antes) se confirman. En caso de falla, todos los operadores de fuentes se restablecen a su estado cuando vieron el último marcador comprometido y el procesamiento continúa. Este enfoque de marcador-punto de control es más liviano que los reconocimientos a nivel de registro de Storm. Esta Las fuentes de datos inyectan marcadores periódicamente en el flujo de datos. Cada vez que un operador recibe dicho marcador, controla su estado interno. Cuando todos los receptores de datos reciben un marcador, el marcador (y todos los registros que se han procesado antes) se confirman. En caso de falla, todos los operadores de fuentes se restablecen a su estado cuando vieron el último marcador comprometido y el procesamiento continúa. Este enfoque de marcador-punto de control es más liviano que los reconocimientos a nivel de registro de Storm. Esta Todos los operadores de fuentes se restablecen a su estado cuando vieron el último marcador confirmado y el procesamiento continúa. Este enfoque de marcador-punto de control es más liviano que los reconocimientos a nivel de registro de Storm. Esta Todos los operadores de fuentes se restablecen a su estado cuando vieron el último marcador confirmado y el procesamiento continúa. Este enfoque de marcador-punto de control es más liviano que los reconocimientos a nivel de registro de Storm. Estael conjunto de diapositivas y la charla correspondiente discuten el enfoque de procesamiento de transmisión de Flink, incluida la tolerancia a fallas, la verificación de puntos y el manejo del estado.

Storm también ofrece una API de alto nivel exactamente una vez llamada Trident. Sin embargo, Trident se basa en mini lotes y, por lo tanto, es más similar a Spark que a Flink.

La latencia ajustable de Flink se refiere a la forma en que Flink envía registros de una tarea a otra. Dije antes, que Flink usa transferencias de datos canalizadas y envía registros tan pronto como se producen. Para mayor eficiencia, estos registros se recopilan en un búfer que se envía a través de la red una vez que está lleno o se alcanza un cierto límite de tiempo. Este umbral controla la latencia de los registros porque especifica la cantidad máxima de tiempo que un registro permanecerá en un búfer sin ser enviado a la siguiente tarea. Sin embargo, no se puede usar para dar garantías sólidas sobre el tiempo que le toma a un registro entrar y salir de un programa porque esto también depende del tiempo de procesamiento dentro de las tareas y del número de transferencias de red, entre otras cosas.


2
¡Muchas gracias de hecho! Un punto abierto tal vez, si puedo molestarlo una vez más: ¿De qué se trata este problema de "latencia ajustable"? Parece que podría ser bastante relevante dado que diferentes dominios de aplicación tendrán diferentes requisitos a este respecto. ¿Puedes explicar lo que esto implica, al menos en términos de Flink?
fnl

66
Claro, extendí mi respuesta y discutí la latencia ajustable. Avísame si tienes más preguntas.
Fabian Hueske

¿Flink permite cambios "activos" en el flujo de trabajo de DAG, como se puede implementar, por ejemplo, usando Erlang? ES DECIR. ¿Se puede cambiar el DAG durante el tiempo de ejecución?
Thomas Browne el

1
El intercambio de código activo no es posible. Sin embargo, puede mantener el estado de una aplicación como punto de rescate. El punto de guardado se puede usar para iniciar una aplicación modificada. Esto se puede hacer mientras la aplicación original aún se está ejecutando, de modo que la salida se pueda voltear en algún momento. Tenga en cuenta que las aplicaciones no pueden modificarse arbitrariamente al reanudar desde un punto de rescate existente.
Fabian Hueske

1
La ventaja interesante y enorme de Flink es la capacidad de ejecutar Apache Beam con API de nivel aún más alto. Es uno de los corredores más ricos y completos para Beam.
Piotr Gwiazda

47

Agregando a la respuesta de Fabian Hueske:

Flink también mejora en Storm también de las siguientes maneras:

  • Contrapresión: el tiempo de ejecución de transmisión de Flink se comporta bien cuando diferentes operadores se ejecutan a diferentes velocidades, porque los operadores en sentido descendente contraprestan muy bien a los operadores en sentido ascendente, aunque la capa de red gestiona las agrupaciones de almacenamiento intermedio.

  • Estado definido por el usuario: Flink permite que los programas mantengan un estado personalizado en sus operadores. Ese estado en realidad puede participar en los puntos de verificación para la tolerancia a fallas, proporcionando garantías de una sola vez para el estado personalizado definido por el usuario. Vea este ejemplo de una máquina de estado definida por el usuario dentro de un operador, que se verifica constantemente junto con el flujo de datos.

  • Ventanas de transmisión: las ventanas de ventanas y las agregaciones de ventanas son un elemento fundamental para el análisis de las transmisiones de datos. Flink viene con un sistema de ventanas bastante potente que admite muchos tipos de ventanas.


2
En cuanto a su primer punto, Storm se comporta bien bajo contrapresión a partir de 1.0 (publicado en abril de 2016)
Colin Nichols

La contrapresión de tormenta puede mitigarse utilizando la propiedad "spout_max_pending". Establece un umbral para las tuplas máximas que pueden estar presentes en un surtidor pendiente de confirmación. La boquilla no consumirá más tuplas en el futuro hasta que ocurra el ack.
Aman Garg

3

Basado en mi experiencia de Storm and Flink. Siento que estas herramientas pueden resolver el mismo problema con diferentes enfoques. Storm puede combinar todas las características de Flink mencionadas por @Stephan Ewen con API interna (es decir, spolts y bolts ) y API Trident ahora. Alguien afirma que Trident es un estilo de mini lote, mientras que creo que la mayoría de las aplicaciones complejas con estado o agregación solo pueden depender del procesamiento por lotes con estilo de ventana. Así que solo enumero algunas diferencias principales aquí sin decir cuál es mejor.

  • Estilo de desarrollo . orientado a la informática (p. ej., operador encadenable) en Flink vs. orientado al flujo de datos (p. ej., addSpolt()/addBolt()) en Storm.
  • API de alto nivel . Funciones (por ejemplo, Mapa, Ventana, Unirse en el nivel de Streaming) en Flink vs. Ventana nativa y Trident en Storm.
  • Procesamiento de mensajes garantizado (GMP, es decir, exactamente una vez ) . Punto de control con conector de confirmación de dos fases (p. Ej., KafkaConsumer) en Flink vs. Tuple-tree con la máquina de estado externa o Trident en Storm.
  • Tolerancia a fallos . Marcador-punto de control en Flink vs. record-level-ACK en Storm.
  • Arquitectura interna . Abstracción simple y paralelismo relativo (por ejemplo, ranura para cada subproceso considerado con núcleos de CPU) en Flink frente a abstracciones multicapa (por ejemplo, ranura para cada JVM como trabajador en supervisor y cada supervisor puede tener muchos trabajadores) en Storm.

3

Descargo de responsabilidad: soy un empleado de Cloudera, uno de los principales partidarios de Storm y (pronto) Flink.

Funcional

Ya se han presentado muchos buenos puntos técnicos. Un resumen muy breve de lo más destacado:

  • Tanto Flink como Storm pueden procesar por evento
  • Storm no parece admitir eventos fuera de la caja
  • Storm no ha eliminado el soporte SQL de la etapa experimental

No funcional

  • Muchos clientes encontraron Storm (demasiado) difícil de usar
  • La adopción de Storm se ralentizó, y la comunidad de Flink ahora parece ser más activa que Storm
  • Flink todavía tiene que ponerse al día (por ejemplo, ejemplos documentados), pero en general se ha puesto al día en casi todas las áreas que pueda pensar

Conclusión

Cloudera ha anunciado recientemente la desaprobación de Storm (en HDP). Y simultáneamente Flink fue anunciado como su sucesor.

Entonces, si tiene casos de uso en tormenta, por supuesto, continuarán funcionando. Pero para los nuevos casos de uso, buscaría en Flink u otros motores de transmisión.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.