Evaluación y prueba de concepto de tecnologías de procesado en streaming y tiempo real (III): RTS DataTorrent y Apache Apex

Continuamos con nuestra serie de posts sobre tecnologías streaming. En esta ocasión nos centraremos en el motor de streaming de código abierto Apache Apex, su proyecto hermano Apache Malhar (una biblioteca de conectores para Apex) y el paquete comercial RTS DataTorrent (basado en Apex/Malhar). En este post analizaremos las características de estas herramientas y sus puntos fuertes y débiles a partir de una prueba de concepto (PoC).

Descripción

Apache Apex es un sistema de procesamiento unificado para batch y streaming, nativo de YARN, pero con especial foco en el procesamiento en tiempo real.

De más alto nivel tenemos Apache Malhar, un proyecto para la creación de una biblioteca de operadores sobre Apache Apex.

Por su parte, RTS DataTorrent es un producto comercial de DataTorrent, que incluye un motor de procesamiento, herramientas de control, ingesta, monitorización y dtAssemble. Este último, un sistema de programación gráfica basado en flujos pensado para data scientists.

Historia

En sus inicios, RTS DataTorrent se creó como un producto comercial, siendo una de las primeras aplicaciones nativas de YARN. En 2015, su núcleo (Apex) y una biblioteca (Malhar) fueron lanzados como proyectos de código abierto por su compañía, DataTorrent.

Evaluación

Apache Apex y Malhar parecen estar bastante bien diseñados. La idea de hacer un DAG (grafo dirigido acíclico) explícito a través de nodos de conexión y la naturaleza modular de sus, así denominados, operadores(módulos conectables que implementan una cierta lógica o se conectan a un sistema externo determinado) hace que la construcción de los flujos sea muy sencilla con el soporte de herramientas visuales. Los operadores también están diseñados para garantizar la tolerancia a fallos, la actualización dinámica de propiedades y soporte de particionados de datos. La aplicación es nativa de YARN, lo que limita su integración.

Aunque Apache Apex está luchando con el resto de sistemas de procesamiento streaming para alcanzar mayores cuotas de mercado, parece que se están realizando más esfuerzos en la creación y venta de la plataforma que en sus partes de código abierto. En la evaluación hemos observado que la documentación escasea, la comunidad tiene poca actividad y es difícil encontrar ejemplos y, en general, soporte.

Con el tiempo, veremos si su adopción crece o se reduce a los usuarios reales de RTS.

En la primera y segunda parte de esta serie podrás encontrar la comparativa en más detalle con otros sistemas de real time streaming

Apache Apex

El desarrollo es fácil y claro, ya que la tarea del desarrollador es simplemente implantar lógica comercial en los operadores y conectarlos mediante un interfaz gráfico. Los operadores son reutilizables por naturaleza.

Sin embargo, las pruebas nos dejaron con la impresión de que Apache Apex no ha sido tratada tan cuidadosamente como su plataforma comercial, mostrando una falta de documentación (especialmente en algunos operadores de Malhar) y ejemplos. Por ello, es indispensable tener el conector para tu fuente externa. En concreto con Kafka, hay muchas opciones de configuración y documentación, pero es posible que otros conectores no tengan tanta suerte. En concreto, tuvimos serios problemas con el operador de conexión ElasticSearch.

RTS

RTS viene con un sandbox que se puede descargar gratis. Se ha probado y ofrece una interfaz completa y operativa para las aplicaciones. Requiere 8 GB de RAM como mínimo (6 GB como mínimo para aplicaciones ligeras).

Una aplicación RTS se puede construir de dos maneras distintas:

• A través del código, generando un .apa (al estilo uberjar) y cargándolo en el RTS.
• Via dtAssemble, una herramienta gráfica para crear workflows a través de una biblioteca de operadores (similar a NiFi o StreamSets), orientada a permitir que los data scientists creen workflows de manera autónoma.

Hemos probado ambas opciones y han funcionado bien.

Cuando se ejecuta, la pestaña de monitoreo de una aplicación en ejecución muestra algo como esto:

Se puede ver en tiempo real los datos de supervisión sobre el proceso (la ventana de tiempo cambia a medida que avanza el proceso):

La plataforma parece ser un producto aceptable para el procesamiento de alto rendimiento en tiempo real. Al tener el núcleo abierto (Apex y Malhar) y observar que la plataforma RTS se basa en YARN (también de código abierto), reduce el bloqueo del proveedor para adoptarlo en un proyecto.

Sin embargo, todavía parece ser un esfuerzo de una empresa y no una gran comunidad. Por eso hay que tener cuidado de adoptarlo, más aun teniendo en cuenta los muchos contendientes en el campo de real time streaming.

Además, Apache Beam también puede usar Apex como runner. Entonces, si no se va a usar ningún RTS, utilizar Apex via Beam podría ser una opción muy recomendable.