Ya en un anterior post comentamos un caso de Arquitectura en “Streams” no nativa, es decir, obteniendo datos transaccionales o operativos los convertiamos en “Streams” mediante una Pipeline para poder analizarlos mediante un sistema Distribuido. Hoy, presentamos un sistema Distributed Real-Time Stream Processing nativo, veamos dos ejemplos de arquitectura, entre los cuales, uno nos será muy próximo.

Real Time Analytics Architecture

En el siguiente Diagrama tenemos el caso que vamos a explicar:

Partimos de unas aplicaciones o Microservicios que hemos diseñado y, a su vez, que hemos diseñado con un sistema de eventos; también, podríamos estar ingestando logs pero ahora vamos a ver aplicaciones que gestionan eventos y que nos informaran por cada cambio que tienen origen o destino en nuestra aplicación.

Nuestra aplicación, mediante un sistema push, informará de aquellos cambios de información que le están sucediendo, informará a un broker Kafka donde ya se clasificará mediante Topics para, seguidamente, poder ingestarlo según estipulemos.

Como ya comentamos en posts anteriores, Kafka nos va a permitir tener no solamente una clasificación previa a la ingestión sinó también un sistema de buffer para que en caso de tener puntas de envío de información poder asumirlo con crecimiento horizontal y un Alto throughput de ingesta.

Tras Kafka podemos tener varios sistemas, para especializarlos según las necesidades, en el Diagrama podemos ver dos:

Druid

Comentábamos en el post anterior que Druid.io es un almacén de datos analítico basado en S3 o HDFS y diseñado para poder realizar consultas mediante formato de texto ligero JSON 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 agregación rápida de datos.

Un buen post para poder montar un Cluster Druid en AWS lo encontramos en: https://andresgomezfrr.github.io/datadocs/druid/. Hasta que no tengamos el nuestro…

Hive HDFS

En este caso, a diferencia del post anterior, es que de forma nativa introduciremos los datos que nos vendrán ordenados por Kafka directamente a nuestro Hadoop. Realmente nuestra puerta de entrada será Apache Hive, sistema de ficheros distribuido de Hadoop que nos facilitará enormemente el poder trabajar con los datos introducidos. Su funcionamiento es sencillo, a través de querys SQL/HiveQL podremos lanzar consultas, que posteriormente, podremos traducir a MapReduce. Hive nos ayudará en esta tarea que no es simple. Para los que necesitamos ponerle nombre a las cosas, podemos ver este componente como un datawarehouse.

Fast Data at ING

A diferencia del post anterior, éste es realmente nativo pero una vez tenemos la información introducida dentro de nuestro sistema el funcionamiento es casi similar y es por eso que, ahora, pasaremos a comentar un caso real que tiene bastante parecido a lo comentado, en un siguiente post, el tercero de éste entregable, presentaremos la PoC realizada para que se pueda jugar. Ahora, veamos el ejemplo de ING:

En éste primer diagrama podemos ver un mapa conceptual de la Arquitectura, dónde tiene mucho parecido justo con nuetras anterior explicación. Un conjunto de aplicaciones que mediante la generación de eventos se comunican con un sistema distribuido de streams que, finalmente, otra aplicación recoge y gestiona. Seguidamente, un conjunto de orígenes de datos, mayormente SQL y mediante un sistema de Pipeline ingestan datos a un Data Store centralizado donde un sistema de Big Data se conecta y genera las nuevas informaciones. Ahora, veamos la parte lógica, quizás más interesante para nosotros:

Básicamente el diagrama que acabamos de ver es, varias veces, el proceso de stream que hemos comentado. De izquierda a derecha podemos ir viendo los pasos que se realiza para is ingestando la información como a su vez, darle valor y limpieza a la misma. Primero tenemos un conjunto de fuente productoras de información que ingestan a un sistema Kafka los eventos generados, Flink mediante un conjunto de business rules realiza una limpieza de las mismas como, también, ingesta en un sistema de Metadata aquellos datos que irán construyendo el catálogo de datos para poder generar índices de información que complementarán nuestro sistema y nos facilitarán búsquedas, por ejemplo. Éste sistema de Metadata está basado en Apache Atlas, también comentado anteriormente.

Toda la información, sea RAW o Normalizada va a parar a un Data Lake, que será el repositorio de la información para que los entornos de Big Data se puedan conectar y generen nueva información. La Pipeline tiene varias iteraciones seguramente debido a las necesidades de negocio pero, en realidad, el sistema parece ser el mismo que vuelve a analizar los datos, seguramente con unas nuevas reglas de negocio para, a la salida, entregar a los consumidores sólo aquellos datos releventas.

Realmente un caso de uso interesante ya que contempla el uso de varios sistemas como son:

• Apache Kafka
• Apache Flink
• Apache Atlas
• Data Lake

Si queréis tener más información sobre el caso presentado podéis ver la siguiente presentación de Bas Geerdink, IT Manager Fast Data Analytics at ING.

Autor: Joakim Vivas