Apache Spark 2.4: hacia la analítica de datos unificada

Una de las complejidades en la aplicación de la Inteligencia Artificial a escala está en la disparidad de sistemas y tecnologías que se han de emplear e integrar, además de las divisiones organizativas que suelen aparecer entre los ingenieros de sistemas y los científicos de datos. Para eliminar obstáculos es necesario unificar los datos y la IA en lo que se conoce como Unified Analytics o analítica de datos unificada, uniendo de manera simplificada y nativa las tecnologías de Big Data para el procesamiento de datos con las tecnologías de inteligencia artificial. De esta manera es posible construir de manera más eficiente (tanto a nivel tecnológico como económico) potentes pipelines de datos que extraigan la información de distintas fuentes y que permitan la preparación de conjuntos de datos etiquetados para la generación de modelos de predicción o clasificación; y además poderlo hacer de manera iterativa re-alimentando o re-entrenando los modelos sobre conjuntos de datos masivos. Además, una plataforma de análisis unificada permite que tanto ingenieros como científicos de datos trabajen eficazmente en todo el ciclo de vida de desarrollo a producción y mantenimiento.

La versión 2.4 de Apache Spark ha sido liberada hace un par de semanas y trae importantes mejoras cuyo detalle se puede encontrar en sus release notes.

Una de las nuevas funcionalidades más importantes que trae esta versión es un nuevo modo de planificación, el Barrier Execution Mode, que permite implementar entrenamiento en modo distribuido (multi-nodo) para modelos de Deep Learning dentro de Jobs de Spark. Este es un hito importante de cara a avanzar con el análisis unificado ya que esta nueva nueva funcionalidad permite enlazar pipelines de datos gestionadas por un motor de analytics unificado (Spark) con los nuevos frameworks de AI como TensorFlow, MXNet, etc.

Para poder hacer esto posible se ha tenido que diseñar este nuevo modo de planificación ya que el modelo de ejecución en Spark está basado en un grafo acíclico (DAG) y cualquier tarea en una de las etapas de ejecución no depende de ninguna otra, es decir, las tereas son independientes y no hay un modelo síncrono de coordinación entre todas; además, si una tarea dentro de una etapa falla la tarea se vuelve a re-arrancar, pero no se reinician todas. Pero en los frameworks de IA de tipo DDL (Distributed Deep Learning) con entrenamiento multi-nodo (como Horovod o Distributed TensorFlow), los workers empiezan al mismo tiempo y hay unos mecanismos específicos de comunicación o paso de mensajes y datos entre los antecesores y los predecesores que son generalmente síncronos y además existe una fuerte coordinación entre las distintas tareas. Con el Barrier Execution Mode, Spark lanza todas las tareas correspondientes a la fase de entrenamiento multimodo del modelo al mismo tiempo e implementa funciones de tipo AllReduce o AllAggregate sobre RDDs que permiten para cada iteración sumar, agregar todos los gradientes en las n capas del modelo de DL utilizando n GPUs en paralelo y hacer el broadcast de éstos de las capas superiores mientras se siguen computando los gradientes de las capas inferiores. Además, Spark también soporta tolerancia a fallos en este nuevo modo de planificación de manera que, si una tarea falla en plena ejecución, Spark aborta todas las tareas pertenecientes a la etapa donde se produce el fallo y volvería a arrancar la etapa (arrancando todas las tareas al mismo tiempo de nuevo).

Siendo la comunidad consciente de que la realidad es que la inteligencia artificial necesita del Big Data para que los modelos de Deep Learning puedan escalar en rendimiento, han surgido proyectos para unificar ambos mundos (como TensorFlowOnSpark, TensorFrames, SparkFlow, CaffeOnSpark, BigDL, etc.) pero ninguno es nativo.

Se podría decir que esta funcionalidad de Apache Spark podría marcar un antes y un después, especialmente en lo relativo al diseño de soluciones de infraestructura ya que permitirá la implantación y utilización de clústeres híbridos de Big Data + AI con nodos basados en computación heterogénea; y es que, hasta ahora era muy común tener dos clústers distintos: uno para la parte de datos (Big Data) donde se ejecutan las fases de ingesta, extracción de diversas fuentes, transformación, adaptación de datos al modelo, y carga de los datos (al modelo) y otro clúster, de GPUs distribuidas, donde se realiza el entrenamiento y validación de los modelos con la mayor rapidez posible.  No obstante, este ha sido el primer paso importante para unificar el estado del arte en IA y Big Data bajo Apache Spark y ofrecer una solución de Unifyed Analytics,y para ello ha nacido el proyecto Hydrogen. Mas información en la sesión del SPARK+AI Summit de este año.

Aún queda camino por recorrer para, por ejemplo, implementar un interface optimizado para el intercambio de datos entre Spark y los frameworks de AI (Spark Project Improvement Proposal - SPIP: JIRA SPARK-24579), o implementar los cambios necesarios para que Spark pueda utilizar aceleradores hardware (CPUs, GPUs, FPGAs o TPUs) con nodos de computación heterogénea (un clúster heterogéneo) y sepa cómo planificar tareas en aquellos nodos ejecutores que tienen este tipo de aceleradores hardware de una manera inteligente, incluso cómo planificar varias tareas sobre el mismo nodo utilizando varias de sus GPUs en paralelo (JIRAs SPARK-24615 y SPARK-26104). Se espera que la versión 3.0 de Apache Spark ya incluya todo esto.

Largest Euro Hadoop Cluster Uses Huawei Servers