¿Cuáles son los beneficios de Apache Beam sobre Spark / Flink para el procesamiento por lotes?

Apache Beam admite múltiples backends de ejecución, incluidos Apache Spark y Flink. Estoy familiarizado con Spark / Flink y estoy tratando de ver los pros / contras de Beam para el procesamiento por lotes.

Mirando el ejemplo del recuento de palabras de Beam , parece que es muy similar a los equivalentes nativos de Spark / Flink, tal vez con una sintaxis un poco más detallada.

Actualmente no veo un gran beneficio de elegir Beam sobre Spark / Flink para tal tarea. Las únicas observaciones que puedo hacer hasta ahora:

• Ventaja: abstracción sobre diferentes backends de ejecución.
• Desventaja: Esta abstracción tiene el precio de tener menos control sobre lo que se ejecuta exactamente en Spark / Flink.

¿Hay mejores ejemplos que destaquen otros pros / contras del modelo Beam? ¿Existe alguna información sobre cómo afecta la pérdida de control al rendimiento?

Tenga en cuenta que no estoy pidiendo diferencias en los aspectos de transmisión, que se tratan en parte en esta pregunta y se resumen en este artículo (obsoleto debido a Spark 1.X).

Hay algunas cosas que Beam agrega a muchos de los motores existentes.

• Unificando lotes y streaming. Muchos sistemas pueden manejar tanto por lotes como por streaming, pero a menudo lo hacen a través de API independientes. Pero en Beam, el lote y la transmisión son solo dos puntos en un espectro de latencia, completitud y costo. No hay acantilado de aprendizaje / reescritura de un lote a una transmisión. Entonces, si escribe una canalización por lotes hoy, pero mañana sus necesidades de latencia cambian, es increíblemente fácil de ajustar. Puede ver este tipo de viaje en los ejemplos de juegos móviles .

• API que aumentan el nivel de abstracción : las API de Beam se centran en capturar las propiedades de sus datos y su lógica, en lugar de dejar que se filtren los detalles del tiempo de ejecución subyacente. Esto es clave para la portabilidad (consulte el párrafo siguiente) y también puede brindar a los tiempos de ejecución mucha flexibilidad en la forma en que se ejecutan. Algo como la fusión de ParDo (también conocida como composición de funciones) es una optimización bastante básica que la gran mayoría de los corredores ya hacen. Todavía se están implementando otras optimizaciones para algunos corredores. Por ejemplo, las API de origen de Beamestán construidos específicamente para evitar la sobreespecificación de la fragmentación dentro de una tubería. En cambio, brindan a los corredores los ganchos adecuados para reequilibrar dinámicamente el trabajo en las máquinas disponibles. Esto puede marcar una gran diferencia en el rendimiento al eliminar esencialmente los fragmentos rezagados. En general, cuanto más inteligencia podamos desarrollar en los corredores, mejor estaremos. Incluso el ajuste manual más cuidadoso fallará a medida que cambien los datos, el código y los entornos.

• Portabilidad entre tiempos de ejecución. : Debido a que las formas de datos y los requisitos de tiempo de ejecución están perfectamente separados, la misma canalización se puede ejecutar de varias formas. Y eso significa que no terminas reescribiendo el código cuando tienes que pasar de un sistema local a la nube o de un sistema probado y verdadero a algo de vanguardia. Puede comparar opciones fácilmente para encontrar la combinación de entorno y rendimiento que mejor se adapte a sus necesidades actuales. Y eso podría ser una combinación de cosas: procesar datos confidenciales en las instalaciones con un corredor de código abierto y procesar otros datos en un servicio administrado en la nube.

Diseñar el modelo Beam para que sea una abstracción útil para muchos motores diferentes es complicado. Beam no es la intersección de la funcionalidad de todos los motores (¡demasiado limitada!) Ni la unión (¡demasiado fregadero!). En cambio, Beam intenta estar a la vanguardia de hacia dónde se dirige el procesamiento de datos, tanto introduciendo funcionalidad como extrayendo patrones de los motores de tiempo de ejecución.

• Keyed State es un gran ejemplo de funcionalidad que existía en varios motores y permitía casos de uso comunes e interesantes, pero que originalmente no se podía expresar en Beam. Recientemente ampliamos el modelo Beam para incluir una versión de esta funcionalidad de acuerdo con los principios de diseño de Beam .
• Y viceversa, esperamos que Beam influya también en las hojas de ruta de varios motores. Por ejemplo, la semántica de DataStreams de Flink se vio influenciada por el modelo Beam (de soltera Dataflow).
• Esto también significa que las capacidades no siempre serán exactamente las mismas en diferentes corredores Beam en un momento dado. Por eso estamos usando la matriz de capacidades para intentar comunicar claramente el estado de las cosas.