Comparación de tormenta, chispa y Flink
1. Tolerancia a fallos
Spark se basa en el mecanismo de punto de control para lograr la tolerancia a fallos. Siempre que la ejecución del lote se suspenda antes de la operación doCheckpoint, el lote se recalculará por completo.
La tolerancia a fallas de Storm se logra a través del mecanismo de confirmación. Cada perno o pico enviará un mensaje de confirmación al perno de confirmación después de procesar un dato. Cuando todos los nodos hayan procesado los datos, lo hará. Desde todos los nodos, el procesamiento de un dato es exitoso. Storm puede garantizar que no se perderán datos, pero solo puede garantizar que se perderá al menos un dato, asegurando así que no se pierdan datos. Además, dado que es necesario analizar cada dato, la tolerancia a fallos es costosa. Storm Trident se basa en micro lotes para lograr una semántica exactamente una vez.
Flink utiliza el algoritmo Chandy-Chandy-Lamport para realizar instantáneas distribuidas asincrónicas, que son esencialmente puntos de control. Como se muestra en la figura siguiente, Flink inserta regularmente barreras en el flujo de datos. Estas barreras dividen los datos en varias partes pequeñas. Cuando la barrera fluye hacia el operador, el operador verificará inmediatamente la pequeña parte de los datos correspondientes a la barrera. y La barrera se pasa aguas abajo (las operaciones de punto de control son asincrónicas y no interrumpen el procesamiento de datos), y un punto de control completo no se completa hasta que todos los operadores de sumideros hayan completado sus puntos de control. En caso de falla, flink se recuperará desde el último punto de control completo.
El mecanismo de puntos de control de Flink es muy liviano, los obstáculos no interrumpen el flujo de la corriente y las operaciones de puntos de control son asincrónicas. En segundo lugar, en comparación con Storm, que requiere confirmación para cada dato, Flink es un punto de control de lotes pequeños y el costo de tolerancia a fallas es relativamente bajo. strong>
Spark es un cálculo de nivel micro-batch, varias optimizaciones se realizan muy bien y su rendimiento también es el mayor. Sin embargo, vale la pena mencionar que los cálculos con estado (como el operador updateStateByKey) requieren RDD adicionales para mantener el estado, por lo que la sobrecarga es mayor y el impacto en el rendimiento es mayor.
El mecanismo de tolerancia a fallas de Storm requiere confirmación para cada dato, por lo que la sobrecarga de tolerancia a fallas tiene un gran impacto en el rendimiento, y el rendimiento incluso disminuirá en un 70%.
El mecanismo de tolerancia a fallas de Flink es más liviano, tiene menos impacto en el rendimiento y tiene algunos mecanismos de optimización en gráficos y programación, lo que permite a Flink lograr un mayor rendimiento.
La siguiente figura muestra los puntos de referencia de Storm y Flink desde el sitio web de Flink. La siguiente figura muestra la prueba de referencia entre Storm y Flink. Podemos ver que después de activar el mecanismo de tolerancia a fallas de confirmación, el rendimiento de Storm disminuyó significativamente. El rendimiento de flink no cambia mucho cuando se activa y desactiva el punto de control, lo que demuestra que el mecanismo de tolerancia a fallas de flink no es costoso. En comparación con el punto de referencia en el sitio web oficial, también probamos el rendimiento y el resultado fue que el rendimiento de flink fue 3,5 veces mayor que el de storm. Después de eliminar el cuello de botella del ancho de banda de los clústeres de kafka y flink, el rendimiento de flink en sí aumentó en. 1,6 veces.
02 Latencia
Spark se implementa en base al procesamiento de microlotes, lo que mejora el rendimiento a expensas de la latencia. Normalmente, la latencia de la chispa es del orden de unos pocos segundos.
storm es una implementación de transmisión nativa que puede alcanzar fácilmente decenas de milisegundos de latencia, la latencia más baja entre múltiples marcos.
Storm Trident se implementa en base al procesamiento de microlotes y tiene una alta latencia.
flink también es una implementación de transmisión nativa que puede alcanzar latencias de alrededor de 100 milisegundos.
La siguiente figura es un punto de referencia que compara la latencia de flink y storm, proporcionado por el sitio web de flink. Ambos 99 datos se procesaron dentro de 55 milisegundos de latencia, un rendimiento excelente.
3. Resumen
Comparación completa de las funciones, tolerancia a fallos y rendimiento de Spark, Storm y Flink (resumen como se muestra a continuación)