Según un informe reciente de la nube de marketing de IBM, «el 90 por ciento de los datos del mundo actual se han creado sólo en los dos últimos años, creando 2.5 quintillones de bytes de datos cada día – y con la aparición de nuevos dispositivos, sensores y tecnologías, la tasa de crecimiento de los datos probablemente se acelerará aún más».
Técnicamente esto significa que nuestro mundo de procesamiento de Big Data va a ser más complejo y más desafiante. Y muchos casos de uso (por ejemplo, los anuncios de aplicaciones móviles, la detección de fraudes, la reserva de taxis, la monitorización de pacientes, etc.) necesitan el procesamiento de datos en tiempo real, a medida que llegan los datos, para tomar decisiones rápidas y procesables. Por este motivo, el procesamiento de flujos distribuidos se ha hecho muy popular en el mundo del Big Data.

Hoy en día existen varios marcos de streaming de código abierto. Curiosamente, casi todos ellos son bastante nuevos y han sido desarrollados sólo en los últimos años. Así que es muy fácil para una persona nueva confundirse en la comprensión y la diferenciación entre los marcos de streaming. En este post hablaré primero de los tipos y aspectos del Stream Processing en general y luego compararé los frameworks de Streaming de código abierto más populares: Flink, Spark Streaming, Storm, Kafka Streams. Intentaré explicar cómo funcionan (brevemente), sus casos de uso, puntos fuertes, limitaciones, similitudes y diferencias.

Qué es el Streaming/Procesamiento de flujos :
La definición más elegante que he encontrado es : un tipo de motor de procesamiento de datos que está diseñado con conjuntos de datos infinitos en mente. Nada más.

A diferencia del procesamiento por lotes donde los datos están limitados con un inicio y un final en un trabajo y el trabajo termina después de procesar esos datos finitos, el Streaming está destinado a procesar datos ilimitados que vienen en tiempo real de forma continua durante días, meses, años y para siempre. Como tal, al estar siempre destinado a estar en funcionamiento, una aplicación de streaming es difícil de implementar y más difícil de mantener.

Aspectos Importantes del Procesamiento de Stream:

Hay algunas características y términos importantes asociados con el procesamiento de Stream que debemos conocer para entender los puntos fuertes y las limitaciones de cualquier marco de Streaming :

• Garantías de Entrega :
  Significa cuál es la garantía de que, pase lo que pase, un registro particular entrante en un motor de streaming será procesado. Puede ser Atleast-once (será procesado al menos una vez incluso en caso de fallos) , Atmost-once (puede no ser procesado en caso de fallos) o Exactly-once (será procesado una y exactamente una vez incluso en caso de fallos) . Obviamente, Exactamente-una vez es deseable, pero es difícil de lograr en los sistemas distribuidos y viene en las compensaciones con el rendimiento.
• Tolerancia a los fallos :
  En caso de fallos como los fallos de los nodos, los fallos de la red, etc, el marco debe ser capaz de recuperarse y debe comenzar a procesar de nuevo desde el punto en que lo dejó. Esto se logra a través de checkpointing el estado de streaming a algún almacenamiento persistente de vez en cuando. por ejemplo, checkpointing kafka offsets a zookeeper después de obtener el registro de Kafka y el procesamiento de la misma.
• Gestión de Estado :
  En caso de requisitos de procesamiento de estado donde tenemos que mantener algún estado (e.Por ejemplo, el recuento de cada palabra vista en los registros), el marco debe ser capaz de proporcionar algún mecanismo para preservar y actualizar la información de estado.
• Rendimiento :
  Esto incluye la latencia (lo rápido que un registro puede ser procesado), el rendimiento (registros procesados/segundo) y la escalabilidad. La latencia debe ser la mínima posible, mientras que el rendimiento debe ser el máximo posible. Es difícil conseguir ambas cosas al mismo tiempo.
• Características avanzadas : Procesamiento de tiempo de eventos, marcas de agua, ventanas
  Estas son características necesarias si los requisitos de procesamiento de flujos son complejos. Por ejemplo, el procesamiento de registros basado en el momento en que se generó en la fuente (procesamiento de tiempo de eventos). Para saber más en detalle, por favor lea estos posts de lectura obligada por el chico de Google Tyler Akidau : parte1 y parte2.
• Madurez :
  Importante desde el punto de vista de la adopción, es bueno si el marco ya está probado y la batalla probada a escala por las grandes empresas. Es más probable que obtenga un buen apoyo de la comunidad y ayuda en stackoverflow.

Dos tipos de procesamiento de flujos:

Ahora siendo conscientes de los términos que acabamos de discutir, es fácil entender que hay 2 enfoques para implementar un marco de Streaming:

Streaming nativo :
También conocido como Streaming nativo. Significa que cada registro entrante se procesa tan pronto como llega, sin esperar a otros. Hay algunos procesos de ejecución continua (que llamamos como operadores/tareas/pernos dependiendo del framework) que se ejecutan para siempre y cada registro pasa a través de estos procesos para ser procesado. Ejemplos : Storm, Flink, Kafka Streams, Samza.

Micro-batching :
También conocido como Fast Batching. Significa que los registros entrantes cada pocos segundos se agrupan y luego se procesan en un solo mini lote con un retraso de pocos segundos. Ejemplos: Spark Streaming, Storm-Trident.

Ambos enfoques tienen algunas ventajas y desventajas.
El Streaming nativo se siente natural ya que cada registro se procesa tan pronto como llega, lo que permite al marco lograr la mínima latencia posible. Pero también significa que es difícil lograr la tolerancia a fallos sin comprometer el rendimiento, ya que para cada registro, tenemos que rastrear y comprobar una vez procesado. Además, la gestión del estado es fácil, ya que hay procesos de larga duración que pueden mantener el estado requerido con facilidad.

El micro-batching, por otro lado, es todo lo contrario. La tolerancia a los fallos es gratuita, ya que se trata esencialmente de un lote, y el rendimiento también es elevado, ya que el procesamiento y la comprobación se realizan de una sola vez para un grupo de registros. Pero tendrá un coste de latencia y no se sentirá como un flujo natural. Además, la gestión eficiente del estado será un reto a mantener.

Streaming Frameworks One By One:

Storm :
Storm es el hadoop del mundo del streaming. Es el framework de streaming de código abierto más antiguo y uno de los más maduros y fiables. Es un verdadero streaming y es bueno para casos de uso basados en eventos simples. He compartido detalles sobre Storm en profundidad en estos posts: parte1 y parte2.

Ventajas:

• Muy baja latencia, verdadero streaming, maduro y alto rendimiento
• Excelente para casos de uso de streaming no complicados

Desventajas

• No hay gestión de estados
• No hay características avanzadas como procesamiento de tiempo de eventos, agregación, windowing, sesiones, marcas de agua, etc
• Garantía de una sola vez

Spark Streaming :

Spark ha surgido como verdadero sucesor de hadoop en el procesamiento Batch y el primer framework que soporta completamente la arquitectura Lambda (donde se implementan tanto Batch como Streaming; Batch para la corrección, Streaming para la velocidad). Es inmensamente popular, maduro y ampliamente adoptado. Spark Streaming viene gratis con Spark y utiliza micro batching para el streaming. Antes de la versión 2.0, Spark Streaming tenía serias limitaciones de rendimiento, pero con la nueva versión 2.0+, se llama streaming estructurado y está equipado con muchas buenas características como la gestión de memoria personalizada (como flink) llamada tungsteno, marcas de agua, soporte de procesamiento de tiempo de eventos, etc. Además, el streaming estructurado es mucho más abstracto y en la versión 2.3.0 existe la opción de cambiar entre el modo de micro-partida y el de streaming continuo. El modo de Streaming Continuo promete dar una latencia inferior a la de Storm y Flink, pero todavía está en una fase inicial con muchas limitaciones en las operaciones.

Ventajas:

• Soporta la arquitectura Lambda, viene gratis con Spark
• Alto rendimiento, bueno para muchos casos de uso en los que no se requiere sub-latencia
• Tolerancia a fallos por defecto debido a la naturaleza de microlotes
• Simple de usar APIs de nivel superior
• Gran comunidad y mejoras agresivas
• Exactamente una vez

Desventajas

• No es verdadero streaming, no es adecuado para requisitos de baja latencia
• Demasiados parámetros que ajustar. Difícil de acertar. He escrito un post sobre mi experiencia personal mientras afinaba Spark Streaming
• Sin estado por naturaleza
• Se queda por detrás de Flink en muchas características avanzadas

Flink :

Flink también es de origen académico similar a Spark. Mientras que Spark procede de la UC Berkley, Flink procede de la Universidad TU de Berlín. Al igual que Spark, también soporta la arquitectura Lambda. Pero la implementación es bastante opuesta a la de Spark. Mientras que Spark es esencialmente un lote con Spark streaming como micro-batching y caso especial de Spark Batch, Flink es esencialmente un verdadero motor de streaming tratando el lote como caso especial de streaming con datos acotados. Aunque las APIs de ambos frameworks son similares, no tienen ninguna similitud en las implementaciones. En Flink, cada función como map,filter,reduce,etc se implementa como un operador de larga duración (similar a Bolt en Storm)

Flink parece un verdadero sucesor de Storm como Spark sucedió a Hadoop en batch.

Ventajas:

• Líder de la innovación en el panorama del Streaming de código abierto
• Primer marco de streaming verdadero con todas las características avanzadas como procesamiento de tiempo de eventos, marcas de agua, etc
• Baja latencia con alto rendimiento, configurable según las necesidades
• Ajuste automático, sin demasiados parámetros que afinar
• Exactamente una vez
• Consiguiendo una gran aceptación por parte de grandes empresas a escala como Uber,Alibaba.

Desventajas

• Un poco tarde en el juego, hubo falta de adopción inicialmente
• La comunidad no es tan grande como la de Spark pero está creciendo a un ritmo rápido ahora
• No se conoce la adopción del lote de Flink por ahora, sólo es popular para el streaming.

Kafka Streams :

Kafka Streams , a diferencia de otros frameworks de streaming, es una librería ligera. Es útil para el streaming de datos desde Kafka , haciendo la transformación y luego enviando de nuevo a kafka. Podemos entenderla como una librería similar a Java Executor Service Thread pool, pero con soporte incorporado para Kafka. Se puede integrar bien con cualquier aplicación y funcionará fuera de la caja.

Debido a su naturaleza de peso ligero, puede ser utilizado en la arquitectura de tipo microservicios. No hay coincidencia en términos de rendimiento con Flink, pero además no necesita un clúster separado para funcionar, es muy práctico y fácil de desplegar y empezar a trabajar . Internamente utiliza el grupo de consumidores de Kafka y trabaja en la filosofía de registro de Kafka.
Este post explica a fondo los casos de uso de Kafka Streams vs Flink Streaming.

Una de las principales ventajas de Kafka Streams es que su procesamiento es Exactamente Una vez de extremo a extremo. Es posible porque tanto el origen como el destino, ambos son Kafka y desde la versión 0.11 de Kafka lanzada alrededor de junio de 2017, se soporta Exactly once. Para habilitar esta característica, sólo tenemos que habilitar una bandera y funcionará fuera de la caja. Para más detalles compartidos aquí y aquí.

Ventajas:

• Librería muy ligera, buena para microservicios, aplicaciones IOT
• No necesita cluster dedicado
• Hereda todas las características buenas de Kafka
• Soporta Stream joins, internamente utiliza rocksDb para mantener el estado.
• Exactly Once ( Kafka 0.11 en adelante).

Desventajas

• Se acopla estrechamente con Kafka, no se puede utilizar sin Kafka en la imagen
• Muy nuevo en la etapa de infancia, aún no se ha probado en las grandes empresas
• No para el trabajo pesado como Spark Streaming,Flink.

Samza :

Cubriré Samza en breve. Samza desde 100 pies parece similar a Kafka Streams en el enfoque. Hay muchas similitudes. Ambos marcos han sido desarrollados por los mismos desarrolladores que implementaron Samza en LinkedIn y luego fundaron Confluent donde escribieron Kafka Streams. Ambas tecnologías están estrechamente acopladas con Kafka, toman los datos en bruto de Kafka y luego devuelven los datos procesados a Kafka. Utilizan la misma filosofía de Kafka Log. Samza es una especie de versión escalada de Kafka Streams. Mientras que Kafka Streams es una biblioteca destinada a los microservicios, Samza es el procesamiento de clúster de pleno derecho que se ejecuta en Yarn.
Ventajas :

• Muy bueno en el mantenimiento de grandes estados de la información (bueno para el caso de uso de los flujos de unión) utilizando rocksDb y kafka log.
• Tolerante a fallos y de alto rendimiento usando las propiedades de Kafka
• Una de las opciones a considerar si ya se está usando Yarn y Kafka en el pipeline de procesamiento.
• Buen ciudadano de Yarn
• Baja latencia , Alto rendimiento , maduro y probado a escala

Desventajas :

• Totalmente acoplado con Kafka y Yarn. No es fácil de usar si cualquiera de estos no en su tubería de procesamiento.
• Atleast-una garantía de procesamiento. No estoy seguro si soporta exactamente una vez ahora como Kafka Streams después de Kafka 0.11
• Falta de características avanzadas de streaming como Watermarks, Sessions, triggers, etc

Comparación de Streaming Frameworks:

Podemos comparar tecnologías sólo con ofertas similares. Aunque Storm, Kafka Streams y Samza parecen ahora útiles para casos de uso más sencillos, la verdadera competencia está clara entre los pesos pesados con las últimas características: Spark vs Flink

Cuando hablamos de comparación, generalmente tendemos a pedir: Muéstrame los números 🙂

El benchmarking es una buena forma de comparar sólo cuando ha sido realizado por terceros.

Por ejemplo uno de los antiguos benchmarking era este.
Pero esto fue en tiempos antes de Spark Streaming 2.0 cuando tenía limitaciones con RDDs y el proyecto tungsteno no estaba en su lugar.
Ahora con el lanzamiento de Structured Streaming post 2.0 , Spark Streaming está tratando de ponerse al día mucho y parece que va a haber una dura lucha por delante.

Recientemente la evaluación comparativa se ha convertido en una especie de pelea de gatos abierta entre Spark y Flink.

Spark había hecho recientemente una comparación de benchmarking con Flink a la que los desarrolladores de Flink respondieron con otro benchmarking tras el cual los chicos de Spark editaron el post.

Es mejor no creer en el benchmarking hoy en día porque incluso un pequeño ajuste puede cambiar completamente los números. Nada mejor que probar y testear nosotros mismos antes de decidir.
A día de hoy, es bastante obvio que Flink está liderando el espacio de Streaming Analytics, con la mayoría de los aspectos deseados como exactamente una vez, el rendimiento, la latencia, la gestión del estado, la tolerancia a fallos, las características avanzadas, etc.

Estos han sido posibles gracias a algunas de las verdaderas innovaciones de Flink como las instantáneas de peso ligero y la gestión de la memoria personalizada fuera de la pila.
Una preocupación importante con Flink era la madurez y el nivel de adopción hasta hace algún tiempo, pero ahora empresas como Uber, Alibaba, CapitalOne están utilizando Flink streaming a escala masiva certificando el potencial de Flink Streaming.

Recientemente, Uber abrió su último marco de análisis de Streaming llamado AthenaX que está construido sobre el motor Flink. En este post, han discutido cómo trasladaron sus análisis de streaming de STorm a Apache Samza y ahora a Flink.

Un punto importante a tener en cuenta, si ya te has dado cuenta, es que todos los frameworks de streaming nativos como Flink, Kafka Streams, Samza que soportan la gestión de estados utilizan RocksDb internamente. RocksDb es único en el sentido de que mantiene el estado persistente localmente en cada nodo y tiene un alto rendimiento. Se ha convertido en una parte crucial de los nuevos sistemas de streaming. He compartido información detallada sobre RocksDb en uno de los posts anteriores.

Cómo elegir el mejor marco de streaming :

Esta es la parte más importante. Y la respuesta honesta es: depende 🙂
Es importante tener en cuenta que ningún marco de procesamiento puede ser una bala de plata para todos los casos de uso. Cada marco tiene algunas fortalezas y algunas limitaciones también. Sin embargo, con un poco de experiencia, compartirá algunos puntos para ayudar en la toma de decisiones:

1. Depende de los casos de uso:
   Si el caso de uso es simple, no hay necesidad de ir por el último y más grande marco si es complicado de aprender e implementar. Depende mucho de cuánto estemos dispuestos a invertir para cuánto queremos a cambio. Por ejemplo, si se trata de un simple sistema de alertas basado en eventos del tipo IOT, Storm o Kafka Streams están perfectamente bien para trabajar.
2. Consideraciones futuras:
   Al mismo tiempo, también tenemos que tener una consideración consciente sobre cuáles serán los posibles casos de uso futuros? ¿Es posible que las demandas de características avanzadas como el procesamiento de tiempo de eventos, la agregación, las uniones de flujo, etc puede venir en el futuro? Si la respuesta es sí o puede ser, entonces es mejor seguir adelante con los marcos de streaming avanzados como Spark Streaming o Flink. Una vez que se ha invertido e implementado en una tecnología, es difícil y muy costoso cambiarla después. Por ejemplo, en la empresa anterior teníamos una tubería Storm en funcionamiento desde hace 2 años y estaba funcionando perfectamente bien hasta que llegó un requisito para unificar los eventos entrantes y sólo informar de los eventos únicos. Esto exigía una gestión de estados que no está soportada por Storm. Aunque lo implementé usando un hashmap en memoria basado en el tiempo, pero tenía la limitación de que el estado desaparecería al reiniciar. Además, dio problemas durante estos cambios que he compartido en uno de los mensajes anteriores. El punto que estoy tratando de hacer es, si tratamos de implementar algo por nuestra cuenta que el marco no proporciona explícitamente, estamos obligados a golpear problemas desconocidos.
3. Existing Tech Stack :
   Un punto más importante es considerar la pila de tecnología existente. Si la pila existente tiene Kafka en su lugar de extremo a extremo, entonces Kafka Streams o Samza podría ser más fácil de encajar. Del mismo modo, si la tubería de procesamiento se basa en la arquitectura Lambda y Spark Batch o Flink Batch ya está en su lugar, entonces tiene sentido considerar Spark Streaming o Flink Streaming. Por ejemplo, en uno de mis proyectos anteriores ya tenía Spark Batch en el pipeline y cuando llegó el requisito de streaming, fue bastante fácil elegir Spark Streaming que requería casi el mismo conjunto de habilidades y base de código.

En resumen, si entendemos las fortalezas y limitaciones de los frameworks junto con nuestros casos de uso bien, entonces es más fácil elegir o al menos filtrar las opciones disponibles. Por último, siempre es bueno tener POCs una vez que se han seleccionado un par de opciones. Todo el mundo tiene diferentes gustos después de todo.

Conclusión :

El espacio de Streaming de Apache está evolucionando a un ritmo tan rápido que este post podría ser obsoleto en términos de información en un par de años. Actualmente Spark y Flink son los pesos pesados que lideran desde el frente en términos de desarrollos, pero algún chico nuevo todavía puede venir y unirse a la carrera. Apache Apex es uno de ellos. También hay soluciones propietarias de streaming que no he cubierto como Google Dataflow. Mi objetivo de este post era ayudar a alguien que es nuevo en el streaming para entender, con un mínimo de jerga, algunos conceptos básicos de streaming junto con los puntos fuertes, las limitaciones y los casos de uso de los frameworks de streaming de código abierto populares. Espero que el post haya sido útil de alguna manera.

¡Feliz Streaming!

Puedes seguirme en Linkedin y Quora