Arquitecturas de Análisis de Big Data Francisco Javier Cervigon Ruckauer

Arquitecturas de Análisis de Big Data

Arquitecturas híbridas para big data

1.Como se ha explicado en la sección anterior, existen dos grandes estrategias a seguir para el análisis de big data: el procesado de datos por lotes (batch) o el procesado de flujos de datos (streaming). Cada aproximación tiene sus propias ventajas e inconvenientes:

• El procesado por lotes es más sencillo de diseñar, puesto que siempre se dispone de los datos almacenados a nuestra disposición y se pueden volver a procesar tantas veces como sea necesario. Sin embargo, el procesado de todos los datos almacenados puede requerir mucho tiempo, más de lo que el usuario que consume los resultados está dispuesto a esperar.
• El procesado de flujos de datos es más complicado de diseñar, puesto que los datos no se pueden almacenar (van “pasando por delante” mientras se analizan). El sistema debe ser robusto frente a posibles fallos, definiendo cómo se puede recuperar de los mismos. A cambio, el procesado es más ágil y la respuesta más rápida, pero normalmente el análisis abarca solo una fracción de los datos (el flujo de información que se haya analizado hasta ese punto).

2.Por tanto, cada estrategia tiene ventajas e inconvenientes. La pregunta ahora es: ¿se pueden combinar de algún modo las dos estrategias obteniendo lo mejor de cada una? La respuesta es sí: ese es el propósito de las llamadas arquitecturas híbridas para análisis de big data. 3.Existen dos tipos de arquitecturas híbridas para análisis de big data. La primera:

Es la llamada arquitectura lambda, impulsada, entre otros, por Nathan Marz [Marz 2015]. La forma de trabajar con esta arquitectura es la siguiente:

• Se captura un flujo de datos con el que se alimenta tanto a un sistema de procesado de flujos de datos como a un sistema de procesado de datos por lotes. El primero analiza los datos del flujo conforme llegan, actualizando de inmediato los resultados que coloca en una base de datos. Esta base de datos es la interfaz encargada de resolver las consultas de los clientes del sistema.
• Por otra parte, el sistema de procesado por lotes almacena los datos del flujo progresivamente. Al llegar a un determinado punto (cada día, cada 12h, etc.) lanza un análisis completo sobre todos los datos recopilados por el sistema hasta ese momento. Es de esperar que este análisis requiera mucho más tiempo de ejecución que el nivel superior (streaming). Una vez concluido, los resultados se vuelcan también a la base de datos.
• La ventaja de esta aproximación es clara: por un lado, se actualizan los resultados rápidamente con la capa streaming. Por otro, la capa batch va almacenando todos los datos recibidos, lo que garantiza que no habrá pérdidas de información en caso de fallos en la capa streaming.
• Sin embargo, esta aproximación, muy popular en la actualidad, tiene un grave inconveniente: hay que diseñar, implementar y mantener el código software dos veces. Una vez para la tecnología de la capa streaming y otra para la tecnología de la capa batch. Normalmente, se trata de entornos de desarrollo distintos. Por tanto, cualquier cambio en el código de uno de ellos se tiene que trasladar al otro para mantener la consistencia de todo el sistema (garantizando que los dos niveles analizan los datos del mismo modo). El esfuerzo necesario para conseguir esto es muy alto.

4.La alternativa propuesta por otros especialistas, como Jay Kreps de LinkedIn , es la llamada arquitectura kappa

• 
  
• En este caso, solo se usa un tipo de estrategia de procesado: el procesado de flujo de datos. ¿Cómo se consigue entonces almacenar los datos obtenidos hasta ahora? La clave es que la persistencia de datos la debe proporcionar el sistema de cola de entrada de datos. Ciertas tecnologías para este fin, como Apache Kafka, pueden configurarse para que actúen como un gran almacén que va acumulando los datos recibidos hasta un cierto punto (todos los datos del último mes, o de los últimos tres meses). Para ello, hay que dotarle de suficiente espacio de almacenamiento en el sistema de computación.
• Cada vez que se quiera realizar un análisis, se lanza un nuevo trabajo en el entorno streaming. Ese trabajo dejará su resultado en una tabla de la base de datos que atiende las consultas de usuarios.
• Si se quiere cambiar algún detalle del análisis, se lanza un nuevo trabajo de procesado de flujo de datos. Se puede hacer esto porque la cola de entrada de datos está guardando el histórico de datos recibidos. Idealmente, se le otorgan más recursos para que el análisis avance más rápido que el trabajo original. Cuando el nuevo trabajo alcance al original, se descarta el primero (junto con sus resultados) y permanece el más actual.
• La ventaja respecto a la arquitectura lambda es que solo hay que diseñar, implementar y mantener código software en un solo entorno de desarrollo (el de la tecnología de procesado de flujos de datos que se elija).

5.Estas son las dos arquitecturas híbridas para análisis de big data más populares en la actualidad. Sin embargo, no se trata en absoluto de un problema cerrado, sino que continúan surgiendo nuevas tecnologías y diseños que intentan mejorar estas propuestas.

Laboratorio de análisis vs. análisis en producción

Dentro del análisis de big data, con frecuencia se pone el foco en las tecnologías o los métodos estadísticos empleados para llevarlo a cabo. Sin embargo, hay un factor importante que en muchas ocasiones pasa desapercibido y que está relacionado con el entorno de trabajo dentro del cual se lleva a cabo el análisis. Así se distinguen dos grandes entornos:

• Laboratorio de análisis: en el laboratorio de análisis los analistas y científicos de datos normalmente llevan a cabo trabajo exploratorio y muchas pruebas. El principal objetivo es conocer mejor los datos, entender el significado de toda la información disponible, comprobar la veracidad y precisión de los datos obtenidos (que no existan datos faltantes, etc.). Además, también suelen tomar muestras de los datos para aplicar sobre ellos una gran variedad de modelos estadísticos con distintos fines (predicción, explicación, inferencia estadística, etc.). En el laboratorio existe un entorno de pruebas, en el que los científicos de datos pueden trabajar con cierta libertad, sin usuarios que estén continuamente enviando consultas o solicitando análisis sobre los datos. Se deben probar muchos modelos y alternativas hasta encontrar algunas opciones que funcionen.
  
• Análisis en sistemas en producción: en el análisis de big data en sistemas en producción, que tienen que estar operativos 24 horas al día todos los días de la semana, los profesionales se enfrentan a lo que se denomina analítica operacional. Aquí ya no hay margen de error, ni se pueden efectuar pruebas o experimentos. Todos los pasos de procesamiento y análisis de datos ya han sido cuidadosamente definidos y comprobados. En este entorno, las soluciones de análisis de big data se empaquetan en forma de servicios que funcionan continuamente, atendiendo a usuarios finales o colaborando constantemente en sistemas de toma de decisiones, detección de riesgos, predicción, etc.
  
• Herramientas y tecnologías: en muchos casos, las herramientas y tecnologías empleadas en cada uno de estos dos entornos también son diferentes. En el caso del laboratorio de análisis de datos, se suelen emplear lenguajes de programación como R o Python, así como bibliotecas estándar en estos y otros lenguajes, y entornos que implementan una gran variedad de modelos de análisis y predicción. En el caso de análisis en sistemas en producción, los procesos de tratamiento y análisis de datos (llamados pipelines), se suelen definir en lenguajes de programación muy maduros y con más larga trayectoria en este tipo de entornos como Java, o se reescriben directamente en lenguajes que proporcionen el más alto rendimiento como C++.
• Nuevas tecnologías: sin embargo, algunas nuevas tecnologías para análisis de big data como Apache Spark vienen a cerrar esta brecha entre el laboratorio y el entorno de producción. Spark> ofrece un entorno unificado para desarrollo de soluciones de análisis de big data que garantiza que el código generado en el entorno de laboratorio se puede desplegar casi de forma directa (con mínimos cambios) en un entorno en producción, con sistemas distribuidos que cuenten con muchos más nodos, memoria y espacio de almacenamiento que el entorno de pruebas. Tecnologías como Spark suponen un hito de innovación muy importante en el análisis de big data, al reducir los costes de desarrollo de soluciones, puesto que eliminan o reducen en gran medida los cambios que se deben realizar para convertir una solución del entorno de laboratorio en un producto o servicio fiable y eficienth apto para un sistema en producción.

Francisco Javier Cervigon Ruckauer