El real-time es un requisito imprescindible en muchos casos de uso.
JOSÉ RAMÓN HERVÁS | 08/02/2019
La gran mayoría de los que nos dedicamos al Big Data nos habremos iniciado en este mundo habiendo escuchado el discurso de las famosas V’s. Tres eran en sus inicios: volumen, variedad y velocidad; que pasaron a ser cuatro, valor, gracias al aprendizaje automático. Y que en algún lado ya hablan de hasta 10, ¡órdago a la grande!. Tranquilos, no, no voy a volver a explicarlas.
De las tres V’s iniciales, y por las que surgió toda esta nueva corriente o tecnología, la que mayor evolución ha sufrido seguramente en estos últimos años haya sido la velocidad. Bajo las primeras plataformas de Apache Hadoop la idea de velocidad venía asociada a, en caso de tener que acelerar el procesamiento (¡ay! aquellas funciones map y reduce ¡qué tiempos!), aumentar el número de nodos para repartir la carga y ser capaces, por lo tanto, de procesar la información en un menor tiempo.
Pero la realidad o demanda del negocio de hoy en día impedía el paso a producción de muchos de los casos de uso implementados, o por implementarse, en esta tecnología. El por qué, pues muy sencillo. Ejemplo, no se puede tardar en analizar una transacción online y devolver un resultado más allá de unos míseros milisegundos, ya no hablo ni incluso de hacerlo en near-real-time. Los usuarios hoy en día nos hemos acostumbrado a la inmediatez. Hemos normalizado el hecho de tener o querer saberlo todo ahora, no ya unos minutos después, ni apenas unos segundos puede llegar a valer.
Para tratar de resolver este tipo de requerimientos surgieron diferentes proyectos sobre Hadoop o lo que se conoce como su ecosistema. Por ejemplo, HBase, NoSQL de tipo clave-valor construida sobre el HDFS de Hadoop que facilita el acceso y/o escritura en tiempo real de datos gracias a su baja latencia. Bien es verdad que sí resolvía ciertos problemas como podía ser la consulta en tiempo real de métricas o KPIs que pudieran mostrarse a posteriori en un cuadro de mandos. Pero tampoco era ni es suficiente.
Así, grandes corporaciones dieron vida a proyectos internos que acabarían por hacerse públicos y convirtiéndose en proyectos top de Apache. Un ejemplo, año 2011 LinkedIn y Apache Kafka. Sistema de almacenamiento con mínima latencia que permite la recolección de cualquier tipo de información garantizando la disponibilidad del dato, la tolerancia a fallos y la escalabilidad de la plataforma. Eso en sus inicios, porque ahora disponen de todo un ecosistema propio a su alrededor: Kafka Streams, Schema Registry... (I’m loving it).
Al mismo tiempo surgían otros proyectos dentro del marco de la investigación. Proyectos H2020 como pudo ser Stratosphere que pretendían desarrollar la próxima generación de herramientas analíticas o de procesamiento streaming. Proyecto que en 2014 acabaría por convertirse en la tecnología que hoy conocemos como Apache Flink.
De esta forma, disponiendo de diferentes herramientas de un tipo u otro, acabó por definirse lo que se conoce como arquitectura Lambda a finales del 2013. Arquitectura que mezcla el procesamiento batch con una capa de velocidad para ayudar a resolver los problemas con este requerimiento.
Pero dicha arquitectura presenta diversas cuestiones. La principal: ¿es necesario mantener, con todo lo que conlleva, el código de dos complejos sistemas distribuidos y que deban obtener el mismo resultado?
¿Por qué no mejorar el sistema en su conjunto y tratar cualquier información como un stream de datos? Así es como surge la idea de la arquitectura Kappa allá por el 2014.
Ésta se compone en primer lugar de una capa de almacenamiento, Apache Kafka, que además de continuar recolectando datos, sea flexible a la hora de poder cargar conjuntos de datos los cuales puedan ser reprocesados las veces que hagan falta a continuación.
Una segunda capa analítica o de procesamiento streaming, ej. Apache Flink, que soporte el manejo de información asíncrona, es decir, diferenciar entre el momento en que la información fue generada, event time, momento en el que se recibe en nuestros sistemas, ingestion time, y momento en el que la estamos procesando, processing time.
Y por último, una capa de servicio que disponga de los resultados o de la información procesada, así como de la información original o raw data. Aquí existe una mayor libertad a la hora de tener que elegir una tecnología o herramienta, es más, podrían llegar a convivir varias resolviendo cada una de ellas una determinada necesidad. En caso de estudiar, por ejemplo, las relaciones entre nuestros clientes, elegiremos una NoSQL orientada a grafos. Mientras que en casos de trazabilidad de nuestra mercancía o stock, en los que debemos obtener el histórico de su localización y/o su jerarquía, recomendaremos el uso de una NoSQL de tipo documental. Y si tuviéramos que medir y recuperar KPI’s de nuestro negocio, optaríamos seguramente por una del tipo clave-valor y a ser posible en memoria (no, tranquilos, HBase no, pero sí por ejemplo una Redis).
Desde Treelogic apostamos casi desde su nacimiento por este tipo de arquitectura en nuestros proyectos de investigación para a posteriori trasladar nuestro conocimiento a los clientes desde mediados de 2015. Actualmente estamos centrados en agilizar nuestros despliegues gracias a los emergentes orquestadores (Kubernetes) de imágenes o contenedores (Docker).
BIG DATA EN TIEMPOS DE KUBERNETES
La contenerización de aplicaciones ha proporcionado un método idóneo para la investigación, desarrollo y producción del software. ¿Cómo se adecúan las herramientas Big Data a este mundo?
ARQUITECTURAS TREELOGIC BIG DATA
Los millones de datos que se generan actualmente en la era digital no servirían de nada sin sistemas que canalicen toda esa información. El conjunto de tecnologías que permite el tratamiento masivo de ese conjunto de datos es lo que se conoce como Big Data.
DEEP LEARNING, APRENDIZAJE PROFUNDO
Desde que en la década de los años 50 se comenzó a hablar de Inteligencia Artificial, no se ha parado de investigar, avanzar y desarrollar este tipo de tecnología. Su principal objetivo reside en poder dotar a sistemas informáticos y digitales de procesos que imiten el funcionamiento del cerebro humano.
LA APROXIMACIÓN TREELOGIC: WE DEAL WITH DATA
Uno de los principales objetivos que tenemos en Treelogic, para cualquiera de nuestros proyectos, es ayudar al cliente a descubrir cómo los datos otorgan valor a su negocio.
LA REVOLUCIÓN DEL INTERNET DE LAS COSAS
El Internet de las cosas, o IoT por sus siglas en inglés, engloba cualquier dispositivo que se conecte a la red y se comunique con otros objetos digitales, como una nevera, un termostato o la alarma de seguridad de nuestro hogar.