Introduccion
Decidí analizar un artículo que describe algunos detalles interesantes del procesamiento de transmisión exactamente una vez: exactamente una vez . El hecho es que algunos autores entienden los términos de manera muy extraña. El análisis del artículo nos permitirá aclarar muchos detalles más profundamente, porque La identificación de inconsistencias y rarezas le permite experimentar más plenamente los conceptos y el significado.
Empecemos
Análisis
Todo comienza muy bien:
El procesamiento de flujo de eventos distribuidos se ha convertido en un tema cada vez más candente en el área de Big Data. Los motores de procesamiento de flujo (SPE) notables incluyen Apache Storm, Apache Flink, Heron, Apache Kafka (Kafka Streams) y Apache Spark (Spark Streaming). Una de las características más notables y ampliamente discutidas de los SPE es su semántica de procesamiento, con "exactamente una vez" siendo uno de los más buscados y muchos SPE afirman proporcionar semántica de procesamiento "exactamente una vez".
Es decir, el procesamiento de datos es extremadamente importante, etc., y el tema en discusión es exactamente una vez. Hablemos de ello.
Sin embargo, existe una gran cantidad de malentendidos y ambigüedades que rodean qué es exactamente "exactamente una vez", qué implica y qué significa realmente cuando las SPEs individuales afirman proporcionarlo.
De hecho, es muy importante entender qué es. Para hacer esto, sería bueno dar la definición correcta antes de un razonamiento extenso. ¿Y quién soy yo para dar tan malditos consejos?
Discutiré cómo la semántica de procesamiento "exactamente una vez" difiere entre muchos SPEs populares y por qué "exactamente una vez" puede describirse mejor como efectivamente una vez
Inventar nuevos términos es, por supuesto, una tarea importante. Me encanta esta cosa yo mismo. Solo por esto, se necesita justificación. Intentemos encontrarlo.
No describiré las cosas obvias como gráficos de procesamiento dirigido, etc. Los lectores pueden leer el artículo original por su cuenta. Además, para el análisis de estos detalles son irrelevantes. Solo daré una foto:
A continuación, hay una descripción de la semántica:
- A lo sumo una vez, es decir No más de una vez. Con la aparente obviedad, este comportamiento es extremadamente difícil de garantizar en escenarios de nivel límite como fallas, interrupción de la conectividad de la red y más. Pero para el autor todo es simple:
- Al menos una vez, es decir al menos una vez El esquema es más complejo. Y el rastrillo se puede recoger más:
- Exactamente una vez. ¿Qué es exactamente una vez?
Se garantiza que los eventos serán procesados "exactamente una vez" por todos los operadores en la aplicación de transmisión, incluso en el caso de varias fallas.
Es decir La garantía de procesamiento exactamente una vez es cuando se ha producido el procesamiento "exactamente una vez".
Siente el poder de la determinación? Para reformular: el procesamiento una vez es cuando el procesamiento ocurre "una vez". Bueno, sí, también dice que esta garantía debe preservarse en caso de fallas. Pero para los sistemas distribuidos, esto es algo obvio. Y las comillas insinúan que algo está mal aquí. Definir con comillas sin explicar lo que esto significa es una señal de un enfoque profundo y reflexivo.
La siguiente es una descripción de cómo implementar dicha semántica. Y aquí me gustaría hablar con más detalle.
Por lo general, se utilizan dos mecanismos populares para lograr la semántica de procesamiento "exactamente una vez".
- Instantánea distribuida / verificación de estado
- Entrega de eventos al menos una vez más deduplicación de mensajes
Si el primer mecanismo con respecto a las instantáneas y los puntos de control no genera preguntas, bueno, excepto por algunos detalles como la eficiencia, entonces hay pequeños problemas con el segundo que el autor ignoró.
Por alguna razón, se entiende que un controlador solo puede ser determinista. En el caso de un controlador no determinista, cada reinicio posterior dará, en términos generales, otros valores y estados de salida, lo que significa que la deduplicación no funcionará, porque Los valores de salida serán diferentes. Por lo tanto, el mecanismo general será mucho más complicado que el descrito en el artículo. O, francamente, tal mecanismo es incorrecto.
Sin embargo, pasamos a lo más delicioso:
¿Es exactamente una vez realmente exactamente una vez?
Ahora reexaminemos lo que la semántica de procesamiento "exactamente una vez" realmente garantiza al usuario final. La etiqueta "exactamente una vez" es engañosa al describir lo que se hace exactamente una vez.
Se dice que es hora de reconsiderar este concepto, ya que Hay algunas inconsistencias.
Algunos podrían pensar que "exactamente una vez" describe la garantía para el procesamiento de eventos en el que cada evento en la secuencia se procesa solo una vez. En realidad, no hay SPE que pueda garantizar exactamente el procesamiento una vez. Garantizar que la lógica definida por el usuario en cada operador solo se ejecute una vez por evento es imposible ante fallas arbitrarias, porque la ejecución parcial del código de usuario es una posibilidad siempre presente.
Estimado autor, vale la pena recordar cómo funcionan los procesadores modernos. Cada procesador en proceso realiza una gran cantidad de etapas paralelas. Además, hay ramas en las que el procesador comienza a realizar acciones incorrectas si el predictor de ramas está equivocado. En este caso, las acciones se revierten. Por lo tanto, el procesador puede ejecutar el mismo código dos veces, ¡incluso si no se han producido fallas!
El lector atento exclamará de inmediato: porque el escape es importante, y no cómo se realiza. Exactamente! Lo que importa es lo que sucedió como resultado, no cómo sucedió realmente. Si el resultado es como si sucediera exactamente una vez, entonces eso significa que sucedió exactamente una vez. No encontrar? Y todo lo demás es cáscara, irrelevante. Los sistemas son complejos, y las abstracciones resultantes crean solo la ilusión de ejecución de cierta manera. Nos parece que el código se ejecuta secuencialmente, instrucción por instrucción, que primero lee, luego escribe y luego una nueva instrucción. Pero esto no es así, todo es mucho más complicado. Y la esencia de las abstracciones correctas es mantener la ilusión de garantías simples y comprensibles, sin profundizar en cada momento, cuando necesita asignar valores a una variable.
Y todo el problema de este artículo radica en el hecho de que exactamente una vez es una abstracción que le permite crear aplicaciones sin pensar en duplicados y valores perdidos. Que todo estará bien, incluso en caso de caída. Y no hay necesidad de inventar nuevos términos para esto.
El código de ejemplo en el artículo demuestra claramente una falta de comprensión de cómo escribir controladores:
Map (Event event) { Print "Event ID: " + event.getId() Return event }
Se invita al lector a reescribir independientemente el código para no repetir los errores del autor del artículo.
Entonces, ¿qué garantiza SPEs cuando reclaman semántica de procesamiento "exactamente una vez"? Si no se puede garantizar que la lógica del usuario se ejecute exactamente una vez, ¿qué se ejecuta exactamente una vez? Cuando los SPE afirman una semántica de procesamiento "exactamente una vez", lo que en realidad dicen es que pueden garantizar que las actualizaciones al estado administrado por SPE se envíen solo una vez a una tienda de back-end duradera.
El usuario no necesita una garantía de la ejecución física del código. Sabiendo cómo funciona el procesador, es fácil concluir que esto no es posible. Lo principal es la ejecución lógica exactamente una vez, como si no hubiera fallas en absoluto. Atraer los conceptos de "comprometerse con el almacén de datos" solo agrava la falta de comprensión del autor de las cosas básicas, porque hay implementaciones de tal semántica sin la necesidad de una confirmación.
Para obtener más información, puede leer brevemente mi artículo: Procesamiento de datos competitivos heterogéneos en tiempo real estrictamente una vez .
En otras palabras, el procesamiento de un evento puede ocurrir más de una vez, pero el efecto de ese procesamiento solo se refleja una vez en el almacén de estado de back-end duradero.
Que haya una "tienda de estado de back-end duradera" para el usuario es absolutamente violeta. Solo el efecto del procesamiento es importante, es decir Consistencia y valores de salida en todo el intervalo de procesamiento de datos de transmisión. Vale la pena señalar que para algunas tareas no es necesario tener una tienda de estado de back-end duradera, y sería bueno garantizar exactamente una vez.
Aquí en Streamlio, hemos decidido que efectivamente, una vez, es el mejor término para describir esta semántica de procesamiento.
Un ejemplo típico de entrada estúpida de conceptos: escribiremos algunos ejemplos y argumentos largos para un párrafo completo, y al final agregaremos que "definimos este concepto". La precisión y claridad de las definiciones provocan una respuesta emocional realmente vívida.
Conclusiones
El malentendido de la esencia de las abstracciones conduce a una distorsión del significado original de los conceptos existentes y la posterior creación de nuevos términos desde cero.
[1] Exactamente una vez NO es exactamente lo mismo .
[2] Procesamiento de datos competitivos heterogéneos en tiempo real estrictamente una vez .