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

apache-storm apache-flink (3)

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 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.

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, lo que parece conceptualmente mucho más similar.

He encontrado this (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, Fabian Hueske mismo 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 ligera 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 la API y su "estrategia de tolerancia a fallas más ligera"?

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 agregación o relacionadas con el estado solo podrían 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 a la secuencia de datos (p. ej., addSpolt()/addBolt() ) en Storm.
API de alto nivel . Funciones (por ejemplo, Mapa, Ventana, Unirse en el nivel 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 fallas . 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.

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 buffer 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. Este conjunto de diapositivas y la talk 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 estrictas sobre el tiempo que le lleva 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.