El futuro de las tecnologías de streaming: APACHE FLINK

Históricamente, la mayoría de las empresas que generaban muchos datos tenían que descartarlos, puesto que almacenarlos era costoso y procesarlos algo impensable. Esta situación cambió con la aparición de las primeras tecnologías de almacenamiento Big Data como Hadoop y Cassandra. Hoy en día es posible almacenarlos, pero procesarlos continua siendo una tarea difícil, así que empezaron a surgir otras tecnologías del ecosistema que ayudaban en esta labor: Pig, Hive y, sobre todo, Spark.

Una vez resuelto el problema del procesamiento las empresas se dieron cuenta de que la causa de almacenar tanta cantidad de datos era porque los recibían continuamente en flujos y que el dato iba perdiendo valor según iba pasando el tiempo, por lo que surgieron las soluciones de “streaming”, principalmente Spark Streaming y Storm, y últimamente ha aparecido en escena nuestro protagonista: Apache Flink.

Estos frameworks para el procesamiento de streams debían dar respuesta a nuevos problemas que surgían y que hasta ahora (procesado en batch) no suponían ningún trastorno:

• Las transformaciones y el procesamiento de los datos cuando se encadenan tienen que tener en cuenta que estos llegarán indefinidamente, es decir, no se puede esperar leer todas las líneas para después trocear las palabras y contarlas (por utilizar el ejemplo típico).
• En caso de indisponibilidad de nuestro servicio, tenemos que disponer de mecanismos para no perder ningún dato del flujo. Ahora es necesario separar la parte de adquisición de la de procesamiento y es importante dedicarle especial atención durante el diseño de la plataforma.
• Aparecen los requisitos de tiempo de procesamiento, nuestro programa tiene que ser capaz de asegurar cuál es el tiempo máximo en el que va a devolver un dato, además, relacionado con el punto anterior, aparece el efecto de backpressure, es decir, nuestra cadena de procesamiento tiene que ser capaz de procesar los datos a suficiente velocidad para no saturar las primeras etapas de la cadena de procesamiento.
• En caso de fallo en alguno de los nodos, nuestro framework tiene que asegurarnos que cada evento se procesa siempre y solo una vez (exactly once). Este requisito implica habitualmente costosos mecanismos de sincronización y control de errores. Aunque no es necesario para todas las aplicaciones, para algún tipo de implementaciones puede suponer un grave problema, por ejemplo, una alarma que llega duplicada o, lo que es peor, una alarma que no se registra!

Spark Streaming y Storm han dado solución a estos problemas (al menos a la gran parte), aunque la implementación de Flink parece que ha sido la que mejor ha resuelto estos problemas sin perder capacidad y velocidad de procesamiento.

Sin duda, la gran sorpresa de Flink es su API (Application Programming Interface) para el manejo de eventos temporales: muy fácil de entender y a la vez muy potente. Tiene integrado en el lenguaje aspectos como las ventanas deslizantes, triggers o ventanas “por clave”.

Además, también maneja nativamente temas como qué tiempo de referencia se debe utilizar para ordenar los eventos: ¿Tiempo en que se generó el evento? ¿Cuándo se recibió? o ¿Cuándo se está procesando? Flink permite al desarrollador elegir una de ellas.

Con esta abstracción es muy sencillo desarrollar aplicaciones que manejen eventos en los que hay que tener en cuenta el tiempo y además tienen los requisitos mencionados al principio del artículo.

Artículo redactado por Jose Carlos Baquero y Pablo González, de GMV