Arquitecturas Fast Data para el procesado masivo de datos en tiempo real


El volumen y la velocidad a la que se generan los datos en la actualidad supone todo un reto a las organizaciones, pero a la vez es una oportunidad para ellas si son capaces de transformarse para ser capaz de analizarlos y extraer valor en tiempo y forma. Las tecnologías Fast Data son la evolución natural de las arquitecturas Big Data, donde ya no solo es importante ser capaz de procesar y analizar grandes volúmenes de datos, sino de hacerlo a la velocidad que se generan. Esto puede suponer una ventaja competitiva, ya que te puede permitir reaccionar mucho más rápido a los cambios, detectar los problemas a tiempo y ser capaz de solucionarlos de manera mucho más temprana.

Fruto de nuestro trabajo y experiencia con los clientes, en GFT hemos desarrollado una Arquitectura de Referencia Fast Data. Esta arquitectura se trata de una guía de las piezas funcionales que debería contener una solución Fast Data, así como el stack tecnológico que permitiría implementarla. Como se puede ver en el diagrama de a continuación, para cada pieza funcional damos un abanico que tecnologías que permitirían adaptaros a diferentes escenarios o plataformas.

En concreto, en este post vamos a mostrar una implementación de esta arquitectura de Referencia para un caso de análisis de precios de acciones de bolsa en tiempo real. Para esta implementación hemos tratado de aunar el estado del arte en cuanto a tecnologías Fast Data: Nifi, Flink, Elasticsearch y Kibana.

Ingestion Layer:

Para la capa de ingestión hemos seleccionado Apache Nifi, ya que aporta una serie de ventajas a nuestro juicio:

  • Interfaz Web de Usuario: misma experiencia de usuario para el diseño, desarrollo, control y monitorización.
  • Altamente configurable: el flujo de ingestión es totalmente configurable a través de cajas predefinidas de un catálogo que te permite interactuar con un conjunto muy amplio de fuentes y destinos (REST, SFTP, HDFS, Elasticsearch, etc..). Adicionalmente, puedes realizar fine tunning en las garantías de entregas, rendimiento y latencias, lo que permite adaptarte a tu volumetría y tiempos de respuesta.
  • Flujo de datos: te permite visualizar la secuencia de pasos por los que pasan tus datos end-to-end, desde el sistema origen al destino.
  • Extensibilidad: Puedes construir tus propios componente s para realizar transformaciones ad-hoc o incorporar fuentes/destinos propios que no existan en el catálogo.
  • Seguridad: permite conexiones SSL, SSH, HTTPS, encriptación de contenido, etc.

 

Para el canal de distribución de datos hemos elegido apache Apache Kafka, ya que es el estándar de facto en cuanto a sistemas de mensajería de suscripción por su baja latencia, alta escalabilidad y tolerancia a fallos. Ofrece la siguiente funcionalidad

  • Publicar datos: permite a aplicaciones distribuidas publicar datos en tiempo real a los canales Kafka, también llamados Tópicos.
  • Consumir datos: permite a los sistemas suscribirse a los Tópicos consumir datos en tiempo real.
  • Conectores: ofrece un catálogo de conectores, que están englobados en Kafka Connect, que te permite de manera muy cómoda ingestar datos a tópicos de Kafka o enviar datos desde tópicos de Kafka a otros sistemas.
  • Procesado: finalmente Kafka también incluye un componente para procesado de datos en tiempo real llamado Kafka Streams, que no hemos utilizado en la implementación que estamos mostrando, que ofrece muy baja latencia y permite aplicar transformación de datos.

 

Processing Layer

Para la capa de procesado hemos seleccionado Apache Flink por ser uno de los frameworks nativos para procesado en Real Time más potentes y con una funcionalidad más completa. Las principales ventajas que aporta son:

  • Procesamiento nativo en tiempo real: Apache Flink nació con el objetivo de ofrecer un framework de procesamiento a nivel de eventos con latencias por debajo del segundo. Esto ha permitido que también permita implementar arquitecturas kappa, donde usando este mismo framework también se puedan procesar datos batch.
  • Semántica exacly-once: implementa la garantía de entrega más avanzada que asegura que los mensajes serán procesados una y solo una vez, independientemente de caídas de los nodos o de las fuentes/destino de los datos.
  • Ventanas: ofrece una riqueza muy amplia en la definición de ventanas para agregación de datos en streaming.
  • Modelos temporales: soporta llevar a cabo el procesamiento basado en el tiempo del evento (Event Time), tiempo de ingestión del evento (Event Time) o tiempo de procesado del evento (Process Time). Esto da mucha versatilidad para adaptarte a las necesidades de tu caso de uso.

 

Storage Layer

El almacenamiento los hemos llevado a cabo en Elasticsearch, una solución NoSQL para la gestión de documentos indexados. Sus principales características son:

  • Indices Invertidos: Los documentos se indexan por su contenido y no por el id del mismo. De este modo, el contenido es dividido en palabras, llamados términos y todos ellos son registrados referenciando al documento que los contiene. De este modo se permite búsqueda textual completa, que podríamos asimilar a la funcionalidad de Google de búsqueda.
  • Near-real time: el mayor coste es en el almacenamiento, también llamado indexación. En un cluster distribuido puede tardar segundos desde que un documento es indexado hasta que es visible en todo el cluster.
  • ELK Stack: actualmente se integra en un stack que es mucho más que un motor de almacenamiento. Los principales Este stack engloba, entre otros, agentes para la recolección de datos (Beats), una herramienta de ingestión que permite realizar tratamientos de datos sencillos (Logstash), Elasticsearch y Kibana que veremos a continuación

 

Visualization Layer

Kibana es la herramienta que permite realizar en tiempo real analítica de datos y visualización sobre datos almacenados en elastic. Sus principales características son:

  • Inspección de los datos: Proporciona una herramienta para poder realizar consultas sobre los datos basado en la sintaxis Lucene, aunque en las últimas versiones ya soporta consultas SQL Like. Estas búsquedas pueden ser textuales, definir rangos de fechas, seleccionar que campos de tu esquema quieres visualizar, etc.
  • Visualización: permite al usuario definir cuadros de mando dinámicos que se actualizan en tiempo real. Estos dashboards incluyen una variada amalgama de gráficos (gráficos de barras, líneas, tartas, mapas, etc.)
  • Herramienta de desarrollo: proporciona una herramienta integrada en la UI que permite interaccionar con el API Rest de manera amigable.

Para más detalle arquitecturas Fast Data, ponte en contacto con nosotros o echa un vistazo a un webinar que hicimos en GFT recientemente donde, entre otras cosas, vimos de manera práctica la implementación de una arquitectura Fast Data gracias a las últimas tecnologías y cómo usando Kafka, Flink y ELK, se puede explorar y analizar datos de acciones en tiempo real de forma sencilla.