¿Podemos poner en un ring de boxeo dos tipologías de arquitecturas como son la ingestión de datos mediante BPMs o con eventos? Creo no es acertado ponerlas a competir pero si, podemos explicarlas por separado y afrontar, según nuestras necesidades y/o posibilidades, cual de las arquitecturas podemos llevar a cabo.

También es cierto que muchas veces nos lo encontraremos dado, por ejemplo cuando tenemos delante una aplicación o servicio más tradicional, sea un ERP, un CRM, etc… aquí será muy complejo el poder llegar a un proceso de generación de eventos ya que, seguramente, deberíamos afrontar una transformación casi por completo de la aplicación.

Es por ello que, a continuación, presento una imagen con dos diagramas:

• El primero enfocado a una arquitectura que conecta fuentes de datos, claramente identificadas, y que tras un proceso de workflows o BPMs ingestamos a nuestro sistema de “Streams”.
• El segundo enfocado a un proceso “nativo” de Stream Analytics. Donde un sistema basado en eventos dará distribución de los datos según nos interese.

En este post comentaremos el primero, veamos…

Data Ingestion & Distribution by Apache NiFi

Supongamos que tenemos dos aplicaciones, con dos bases de datos operacionales SQL y también que tenemos identificados nuestros procesos de negocio y como éstos nos permiten construir un proceso basado en workflows para extraer aquellos datos que otros sistemas requieren. Por ejemplo: dashboards de cuadros de mando.

En el siguiente diagrama, que es un “cut” del primero, veremos de izquierda a derecha que tenemos identificadas una série de base de datos y, seguidamente un proceso basado en Apache NiFi. Ésta sección la vamos a llamar “BPM, Business Process Managament” y será la encargada de poder inyectar datos estructurados a nuestra Pipeline de salida.

Apache NiFi

De NiFi ya hemos hablado anteriormente y es bastante simple su utilización, rápidamente nos podemos montar una Pipeline que conecte una fuente de datos con otra, aplicando un proceso de transformación o normalización de datos; para nuestro caso actual será un buen aliado y muy recomendable.

Apache Kafka

Una vez tenemos identificados, como decíamos, las fuentes de datos y conectadas a nuestra Pipeline diseñada en NiFi es la hora de hablar de Apache Kafka, de quien, también, hemos comentado con varios post anteriormente y que sin duda alguna no tiene competidor en su categoría. Kafka nos ayudará a convertir un proceso tradicional de ETL en Streams. Es decir, una vez tengamos clasificadas nuestras entidades, por ejemplo si venimos de un CRM: contactos, incidencias, usuarios, etc… podremos convertirlas a “Streams” mediante la clasificación por Topis que hemos aplicado en Kafka. ¿Cómo lo haremos? Conectando al ouput de Kafka dos posibles soluciones: Apache Samza o Apache Flink.

Streams

Nuestra idea principal es poder aplicar un sucedáneo de la arquitectura Kappa utilizando su modelo para que en vez de usar datos ya almacenados en bases de datos origen, utilizemos flujos de datos o “streams”. Estos Streams los enviaremos mediante un sistema de procesado y los almacenaremos en un otro sistema auxiliar de nuestra capa de servicio. La voluntad será poder consumir datos más cocinados, normalizados, etc…

Antes que nada, realicemos una tabla comparativa entre Apache Samza y Apache Flink, nuestras propuestas, para tomar la mejor decisión en cuanto a necesidades más particulares:

Apache Samza:

Apache Samza es un sistema distribuido de “Stream Processing” y está basado en Apache Kafka para la mensajería como en Hadoop YARN para proporcionar tolerancia a fallos, seguridad, independencia de procesos y gestión de recursos. Sus dos principales características:

• La transmisión se basa en un sistema de verdades construido, principalmente, sobre Apache Kafka y se requiere el manejo de estados.
• Está basado en un sistema API de bajo nivel

Apache Flink:

Apache Flink es un motor de procesamiento de streams o flujos de datos que nos proporciona tanto capacidades de distribución de datos, como de comunicaciones como también a la tolerancia a fallos. Es de alto rendimiento y con el objetivo de estar siempre disponible como preciso. Sus dos principales características:

• La transmisión se basa en un sistema de verdades con compensación de latencia vs rendimiento ajustables.
• Está basado en un sistema API funcional y enriquecida que explota el tiempo de ejecución de la transmisión.

Druid

Druid.io es un almacén de datos (se hace sobre S3 o HDFS) analítico, Open Source, diseñado para poder realizar consultas (JSON) de inteligencia empresarial (OLAP) sobre datos basados en eventos. Druid nos va a proporcionar una ingestión de datos de baja latencia y en tiempo real para una exploración flexible de datos y, también, la agregación rápida de datos.

Druid está inspirado en las BigQuery o PowerDrill de Google y en otras infraestructuras de búsqueda. Mediante la solución, por ejemplo, podremos indexar los datos para crear distintas vistas, almacenar los datos en formato columnar para reaizar tanto agregaciones como filtros y aquí es donde, mediante la conexión anterior vía Streams, daremos un Valor Añadido a nuestra solución global, ya que estaremos “transformando” nuestra capa relacional y/o operacional a eventos y lo podremos gestionar de forma multi-tenancy y nos va a permitir desarrollar aplicaciones analíticas para miles de usuarios concurrentes

Podemos explorar más sobre Druid vs algunas soluciones existentes y quizás, más conocidas, del tipo:

• Druid vs Elastixsearch: http://druid.io/docs/latest/comparisons/druid-vs-elasticsearch.html
• Druid vs Redshift: http://druid.io/docs/latest/comparisons/druid-vs-redshift.html
• Druid vs Spark: http://druid.io/docs/latest/comparisons/druid-vs-spark.html

Visualización con Superset

Superset va a permitir explorar nuestros datos indexados en Druid como crear consultas JSON interactivas que luego podremos usar para dar empowerment a nuestros dashboards.

¿Qué usos podemos darle a Superset? Si estamos utilizando un CRM, como poníamos de ejemplo al inicio del post, podemos utilizar nuestra base de clientes para realizar informes, dashboard de control, etc… específicos para identificar cambios de tendencia en el uso de nuestro producto y/o servicio y comprender mejor el comportamiento del cliente. También, en caso que tenemos un equipo específico de Data Science, podría utilizarlo como BI avanzado para realizar análisis exploratorios de datos en relación con diferentes cohortes de usuarios antes de crear modelos de Machine Learning, etc…

En un siguiente post, comentaremos el segundo caso: Distributed & Real Time Analytics Architecture de forma nativa.

Autor: Joakim Vivas