5 tendencias clave en Big Data e Inteligencia Artificial

2. Ingeniería de software para aplicaciones de Machine Learning

El proceso de desarrollo de soluciones de Machine Learning tiene similitudes con los procesos de ingeniería de software, pero también grandes diferencias que complican algunas de las fases típicas que vemos en el ciclo de vida de los productos software (requisitos, análisis, diseño, implementación, testing, integración y despliegue, mantenimiento…). Como explicó Joey Frazee de Databricks, «en Machine Learning podemos y debemos considerar las mismas fases pero siempre teniendo en cuenta las particularidades en cada caso». Lo resume hablando de “un mismo proceso, pero con descripciones diferentes”.

En esta línea, existe una tendencia hacia la mejora y simplificación del proceso para el desarrollo de productos de machine learning y una preocupación en la comunidad por empezar a realizar procesos más cercanos a la ingeniería de software, así como por definir con claridad las necesidades de los equipos de data science y su integración y colaboración con los equipos de ingeniería de software ya presentes en las empresas. En lo que se refiere a la fases de implementación, usamos notebooks de manera intensiva para exploración de datos y pruebas de concepto, pero una vez establecida la base buscamos otras alternativas para el desarrollo de modelos listos para producción. Por otro lado, en las fases de despliegue y testing, damos especial importancia a la monitorización de métricas que permitan mejorar la calidad del modelo y el despliegue. En este sentido, podemos destacar aquí los trabajos relacionados con uno de los principales frameworks para procesamiento stateful sobre flujos de datos, Apache Flink.

Figura. Monitorización para procesos con Apache Flink. Proyecto SIMPLIFY

3. Simplificar el proceso de Machine Learning

Como mencionamos anteriormente, el desarrollo de soluciones de Machine Learning es un proceso complejo que obliga a abordar retos que van más allá de los que nos encontramos en el desarrollo de software. Matei Zaharia, de Databricks, estableció como principales diferencias:

• En ML hay una miríada de herramientas para cubrir las distintas fases del proceso
• Es difícil hacer un seguimiento de los experimentos
• Es difícil reproducir los resultados
• Las soluciones de ML son difíciles de desplegar

Por todo ello, es habitual acuñar frases como “escribir código de ML no es la parte difícil del ciclo de vida de las soluciones de ML”. Teniendo esto cuenta, hay una clara tendencia hacia el uso de contenedores y orquestadores (Docker, Kubernetes) y a la construcción de plataformas que simplifiquen y soporten diferentes etapas del ciclo de vida (e.g. Kubeflow, Google; MLflow, Databricks; Mesosphere DC/OS, Mesosphere) o que, al menos, puedan facilitar el proceso mediante, por ejemplo, la exportación de modelos (e.g. con PFA – Portable Format for Analytics), la construcción de pipelines (e.g. Nussknacker, Kubeflow Pipelines) o con estrategias de despliegue más sencillas.

En Gradiant hemos trabajado también en esta línea de simplificación del proceso y usamos de manera intensiva contenedores Docker (Gradiant Docker repo) y orquestadores como Kubernetes (tanto para aplicaciones de ML como para otro tipo de soluciones). Un ejemplo de este trabajo podemos verlo en los proyectos ITBox o HOSPITEC. Por otro lado, referente a nuestra experiencia con plataformas “integrales”, podemos destacar el caso de PNDA, plataforma de la que somos contribuidores, concretamente en el framework red-pnda, el cual ofrece una alternativa ligera con un conjunto mínimo de componentes. Aunque está orientada al análisis de redes, la plataforma PNDA ofrece una plataforma open source escalable lo suficientemente genérica como para poder realizar análisis también en otros contextos Big Data.

4. APIs ‘SQL-like’, al alza

Proporcionar APIs de tipo SQL se está convirtiendo también en una tendencia de gran valor para los desarrolladores de sistemas de procesamiento streaming Big Data, ya que simplifica mucho las tareas de implementación de pipelines de datos, que podían resultar tediosas para muchos y más difíciles de mantener. En esta edición del Big Data Spain hemos podido ver los interesantes ejemplos de Flink y Kafka.

Apache Flink ha incorporado las APIs relacionales Table API & SQL sobre las APIs core (DataSet y DataStream) con el objetivo de acercarse a una “gran unificación” donde el motor de procesamiento se adapte a la carga de trabajo integrando de forma transparente fuentes de datos batch y streaming con una misma sintaxis y semántica. En el caso de KSQL (Streaming SQL for Apache Kafka), es posible realizar consultas sobre un stream de datos y utilizar los métodos habituales de SQL (CREATE TABLE, SELECT, FROM, GROUP BY, JOIN, etc), eliminando prácticamente la programación de código. Con esta evolución, Confluent ofrece una nueva ventana al mundo del procesado de streams que complementa a Kafka Streams y se dirige principalmente a ingenieros y analistas de datos.

Los casos de uso de nuestros proyectos de ML más recientes han hecho que en Gradiant seamos usuarios intensivos de este tipo de APIs con diferentes frameworks. Podemos destacar el trabajo con la interfaz KSQL en el marco del proyecto IRMAS, Unidad Mixta de Investigación con Telefónica.

5. Bases de datos de grafos

Las bases de datos orientadas a grafos siguen expandiéndose y consolidan su posición para arquitecturas Big Data en las que se requiere explorar datos con relaciones many-to-many o navegar por jerarquías altamente conectadas. En tales casos conviene saber primero qué tipo de base de datos de grafos necesitamos:

• LPG (Labeled Property Graph): más genéricas y flexibles, escalables y fáciles de recorrer, aunque menos interoperables y peor orientadas a esquemas. Son idóneas para aplicar técnicas de graph mining. Ejemplos de este tipo son Neo4j y TigerGraph.
• RDF (Resource Description Framework): apropiadas para la representación de datos semánticos estructurados en forma de triples, en general ofrecen unas prestaciones inferiores. Ejemplos de este tipo son AllegroGraph y GraphDB.
• Multi-model (document, key-value): también flexibles aunque quizás menos optimizadas para análisis de grafos, y en ocasiones demasiado ligadas a una compañía en concreto. Ejemplos de este tipo son ArangoDB, Azure Cosmos DB o Amazon Neptune.

Como estableció Ian Robinson en su charla sobre Amazon Neptune, este tipo de bases de datos pueden usarse para muy diversos casos de uso pero en la actualidad es común encontrarlas para abordar análisis de redes sociales, motores de recomendación, detección del fraude o grafos de conocimiento. Gradiant ha utilizado este tipo de bases de datos para el análisis de redes sociales (proyectos VIGÍA y ATENEA).

Otros temas de interés

Machine Learning y Edge computing

En el contexto actual, donde estamos rodeados de dispositivos inteligentes conectados, es importante saber complementar la inteligencia de dichos dispositivos (edge intelligence) con la que se pueda obtener de la nube (cloud intelligence). Precisamente, la Internet de las cosas (IoT), es la convergencia entre la información perimetral (edge computing), la nube (cloud computing) y la inteligencia artificial. En esta línea, tiene sentido el desarrollo de algoritmos que decidan dinámicamente cuándo invocar a la nube o al propio dispositivo y que permitan coordinar las predicciones e inferencias llegadas desde ambas ubicaciones.

En Gradiant llevamos trabajando en IoT desde los inicios y en los últimos años hemos enfocado nuestro expertise en la industria y el sector primario. En la actualidad, tenemos varios proyectos abiertos de IoT y edge computing para dicho ámbito.

Ensembles de ML

Los ensembles combinan varios modelos de ML para mejorar la capacidad predictiva de los algoritmos. Están también en pleno auge y se utilizan ampliamente en aprendizaje supervisado, fundamentalmente con algoritmos de clasificación, siendo el bagging (p.ej. random forest) y el boosting (p.ej. gradient boosted trees) dos de los enfoques habituales. La idea es combinar modelos de aprendizaje débiles para conseguir un modelo de aprendizaje fuerte que proporcione un mejor rendimiento global, reduciendo el error de generalización y aumentando la precisión de predicción. De cara al futuro, es interesante saber que la misma lógica utilizada en ensembles de clasificadores puede aplicarse también a otras técnicas, como las técnicas de aprendizaje no supervisado (clustering), o de selección de características.

En Gradiant venimos utilizando este tipo de técnicas desde hace tiempo. Por ejemplo, el uso de ensembles nos permitió obtener un resultado destacado en la competición de Kaggle para el reto de Bosch.

Democratización del ML

Llevando al extremo la simplificación del proceso, Google está trabajando en la automatización total ofreciendo herramientas que permiten crear modelos de ML personalizados con un esfuerzo mínimo y sin apenas conocimientos avanzados. Cloud AutoML, con sus sabores AutoML Translation, Natural Language y Vision, son las primeras pruebas de ello. En este marco de “democratización” es importante también destacar su reciente lanzamiento del AI Hub, un “catálogo” para descubrir, compartir y desplegar soluciones AI (incluyendo pipelines end-to-end, notebooks Jupyter, módulos Tensorflow y otros recursos).

La computación cuántica

La computación cuántica está todavía en fases muy tempranas, sin embargo se hace evidente que el campo de la AI y el ML pueden ser los grandes beneficiados. El hecho de usar qbits (múltiples estados) en lugar de bits (estado binario) puede acelerar enormemente algunas de las operaciones que realizan los ordenadores actuales y, a partir de ellas, acelerar de forma exponencial muchos de los algoritmos que se usan actualmente en ML. IBM está trabajando de forma intensiva en este campo desde hace algunos años y tiene ya funcionando ordenadores cuánticos a los que accede con Qiskit, un framework open source modular para su programación.

Charlas

• Alok Singh, IBM CODAIT. How to build high performing weighted XGBoost ML model for real life imbalance dataset
• Aljoscha Krettek, Data Artisans. The Evolution of (Open Source) Data Processing
• Matei Zaharia, Databricks. MLflow: Accelerating the Machine Learning Lifecycle
• Manish Gupta, Redis Labs. Charting Zero Latency Future with Redis
• Paco Nathan, Derwen, Inc. AI Adoption in Enterprise
• Catherine Zhou, Codeacademy. Building a Data Science team from scratch
• Joey Frazee, Databricks. The lifecycle of machine learning & artificial intelligence
• Israel Herraiz, Google. Notebooks are not enough: how to deliver machine learning products without getting killed
• Holden Karau, Google. Big Data w/Python on Kubernetes (PySpark on K8s)
• Nick Pentreath, IBM CODAIT. Productionizing ML Pipelines with PFA
• Aljoscha Krettek, Data Artisans. The Evolution of (Open Source) Data Processing
• Kai Wähner, Confluent. KSQL – The Open Source SQL Streaming Engine for Apache Kafka
• George Anadiotis, Linked Data Orchestration. The year of the graph: do you really need a graph database?
• Ian Robinson, Amazon Web Services. Get Connected – Building Connected Data Applications with Amazon Neptune
• Pablo Peris, Carlos de Huerta, Microsoft. Machine Learning on The Edge
• Verónica Bolón-Canedo, University of A Coruña. Two heads are better than one: Ensemble methods for the win?
• Elisa Martín, IBM Spain. AI, central element of the Information Systems in the next decade
• Denis Jannot, Mesosphere. All you need to build secure ML pipelines and cloud native applications
• Maciek Próchniak, TouK. Stream processing for analysts with Flink and Nussknacker

Autores: Agustín Cañas Rodríguez, Codirector del área de Sistemas Inteligentes y Rafael P. Martínez Álvarez, Responsable Técnico de Big Data Analytics