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

apache beam python

Question

Apache Beam admite múltiples backends de corredor, incluidos Apache Spark y Flink. Estoy familiarizado con Spark / Flink y estoy tratando de ver las ventajas y desventajas de Beam para el procesamiento por lotes.

Al observar el ejemplo de conteo de palabras de Beam , parece que es muy similar a los equivalentes nativos de Spark / Flink, quizás 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:

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

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

Tenga en cuenta que no estoy pidiendo diferencias en los aspectos de transmisión, que están parcialmente cubiertos en esta pregunta y resumidos en este artículo (desactualizados debido a Spark 1.X).

Answer 1

Beam agrega algunas cosas sobre muchos de los motores existentes.

• Unificación por lotes y transmisión. Muchos sistemas pueden manejar tanto lotes como transmisión, pero a menudo lo hacen a través de API separadas. Pero en Beam, el procesamiento por lotes y la transmisión son solo dos puntos en un espectro de latencia, integridad y costo. No hay acantilado de aprendizaje / reescritura de lote a transmisión. Por lo tanto, si escribe una tubería por lotes hoy pero mañana necesita cambiar su latencia, es increíblemente fácil de ajustar. Puedes ver este tipo de viaje en los ejemplos de Mobile Gaming .

• 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 permitir que se filtren los detalles del tiempo de ejecución subyacente. Esto es clave para la portabilidad (ver el siguiente párrafo) y también puede dar a los tiempos de ejecución mucha flexibilidad en cómo se ejecutan. Algo como ParDo fusion (también conocida como composición de funciones) es una optimización bastante básica que la gran mayoría de los corredores ya lo hacen. Todavía se están implementando otras optimizaciones para algunos corredores. Por ejemplo, las API de origen de Beam están diseñadas específicamente para evitar la especificación excesiva del fragmentación dentro de una tubería. En cambio, les dan a los corredores los ganchos correctos 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, mientras más inteligencia podamos incorporar a 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 tubería se puede ejecutar de varias maneras. Y eso significa que no terminas reescribiendo el código cuando tienes que pasar de la instalación local a la nube o de un sistema probado y verdadero a algo de vanguardia. Puede comparar fácilmente las opciones para encontrar la combinación de entorno y rendimiento que mejor se adapte a sus necesidades actuales. Y eso podría ser una mezcla 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 en 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 de un fregadero de cocina!). En cambio, Beam intenta estar a la vanguardia de dónde va el procesamiento de datos, empujando la funcionalidad y sacando 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 interesantes y comunes, pero 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 también influya en las hojas de ruta de varios motores. Por ejemplo, la semántica de los DataStreams de Flink estuvo influenced por el modelo Beam (née Dataflow).
• Esto también significa que las capacidades no siempre serán exactamente las mismas en los diferentes corredores de Beam en un momento dado. Por eso estamos usando una matriz de capacidades para tratar de comunicar claramente el estado de las cosas.