¿Cuáles son las principales diferencias entre Flink y Storm?

Question

¿Cuáles son las principales diferencias entre Flink y Storm?

Flink ha sido comparado con Spark, que, como yo lo veo, es la comparación incorrecta porque compara un sistema de procesamiento de eventos de 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 vs. una estrategia de procesamiento de eventos por lotes, incluso a una "escala" más pequeña en el caso de Samza. Pero me gustaría saber cómo Flink se compara con Storm, que parece conceptualmente mucho más similar a se.

He encontrado este (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 Spark o HadoopMR, pero no se mencionan ni se hace 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 un peso más ligero estrategia de tolerancia a fallos para proporcionar garantías de procesamiento de una sola vez."

Todo eso es un poco escaso para mí y no entiendo del todo el punto. Puede alguien explicar qué problema(s)?) con stream processing en Storm is (are?) exactamente resuelto por Flink? ¿A qué se refiere Hueske por los problemas de API y su "estrategia de tolerancia a fallos más liviana"?

100

apache-flink apache-storm flink-streaming

Author: Fabian Hueske, 2015-06-08

Source

2 answers

Añadiendo a la respuesta de Fabian Hueske:

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

Contrapresión: El tiempo de ejecución de streaming de Flink se comporta bien cuando diferentes operadores se ejecutan a diferentes velocidades, porque los operadores descendentes contrapresión a los operadores ascendentes muy bien aunque la capa de red gestiona los grupos de búferes.
Estado definido por el usuario: Flink permite a los programas mantener un estado personalizado en sus operadores. Ese estado puede participar realmente en el checkpointing para la tolerancia a fallos, proporcionando garantías de una sola vez para el estado personalizado definido por el usuario. Vea este ejemplo de una máquina de estados definida por el usuario dentro de un operador, que está constantemente checkpointed junto con el flujo de datos.
Ventanas de transmisión: Las ventanas de transmisión y las agregaciones de ventanas son un componente crucial para el análisis de flujos de datos. Flink viene con un sistema de ventanas bastante potente que admite muchos tipos de Windows.

37

Author: Stephan Ewen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-06-23 10:15:40

score 150 · Accepted Answer

Descargo de responsabilidad: Soy un committer 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 framework para el procesamiento unificado de secuencias y lotes. El tiempo de ejecución de Flink admite de forma nativa ambos dominios debido a las transferencias de datos canalizadas 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 pueden ser opcionalmente se ejecuta mediante el bloqueo de transferencias de datos.

Apache Spark es un framework que también soporta procesamiento por lotes y stream. La API por lotes de Flink se ve bastante similar y aborda casos de uso similares a Spark, pero difiere en el funcionamiento interno. Para el streaming, ambos sistemas siguen enfoques muy diferentes (mini-lotes vs. streaming) 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 más similar motor de procesamiento de flujo a Flink.

Llegando a la pregunta original, Apache Storm es un procesador de flujo de datos sin capacidades por lotes. De hecho, el motor canalizado de Flink internamente se ve un poco similar a Storm, es decir, las interfaces de las tareas paralelas de Flink son similares a los pernos de Storm. Storm y Flink tienen en común que apuntan al procesamiento de flujos 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 el funcionalidad de un bolts con uno o más lectores y recopiladores, la API DataStream de Flink proporciona funciones como Map, GroupBy, Window y Join. Gran parte de esta funcionalidad debe implementarse manualmente cuando se usa Storm. Otra diferencia son el procesamiento de la semántica. 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 un marcador de este tipo, comprueba su estado interno. Cuando un marcador fue recibido por todos los sumideros de datos, el marcador (y todos los registros que han sido procesados antes) son confirmados. En caso de fallo, todos los operadores de fuentes se restablecen a su estado cuando vieron el último marcador confirmado y el procesamiento continúa. Este enfoque marcador-punto de control es más ligero que los reconocimientos de nivel récord de Storm. Este conjunto de diapositivas y el correspondiente talk discuten el enfoque de procesamiento de streaming de Flink, incluyendo la tolerancia a fallos, el punto de verificación y el manejo de estados.

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

La latencia ajustable de Flink se refiere a la forma en que Flink envía registros de una tarea a otra. Dije antes, ese Flink utiliza transferencias de datos canalizadas y reenvía registros tan pronto como se producen. Para la eficiencia, estos registros se recopilan en un búfer que se envía a través de la red una vez que está llena o se cumple un cierto umbral 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 utilizar para dar garantías duras sobre el tiempo que toma un registro de entrar a salir de un programa porque esto también depende del tiempo de procesamiento dentro de las tareas y el número de transferencias de red, entre otras cosas.