5 tendencias clave en Big Data e Inteligencia Artificial

 

Si habéis estado pendientes de nuestras redes sociales, ya sabéis que la semana pasada participamos en Big Data Spain 2018, una de las tres conferencias de referencia en Europa sobre Big Data, Inteligencia Artificial, tecnologías Cloud y Transformación Digital.

Con más de 1600 asistentes y más de 90 ponentes durante dos días, la 7ª edición programó una apretada agenda con cuatro tracks en paralelo de presentaciones sobre tecnología y negocio en torno al Big Data, de las que nuestros compañeros Rafael Martínez y Agustín Cañas no han perdido detalle. Ahora que están de vuelta, nos resumen algunas de las principales tendencias y movimientos en los campos de Big Data e Inteligencia Artificial.

 

1. El software libre es un must

Una de las primeras claves que hemos constatado es que numerosas compañías que tradicionalmente habían basado su negocio en el desarrollo de soluciones propietarias y cerradas, han entendido que acercarse al mundo del software libre es necesario. Ya sea mediante la incorporación de herramientas open source a sus soluciones (Kafka, Elastic, Redis, Avro, Spark, entre otras); o bien abriendo algunas partes de sus desarrollos -por ejemplo, en forma de repositorios GitHub-, para transmitir una imagen más nítida de comunidad y transparencia. Este acercamiento coincide con la apuesta que están realizando las nuevas compañías del sector (e.g. Databricks, Data Artisans, Confluent o Redis Labs) y de las que han hablado en sus charlas Alok Singh o Aljoscha Krettek, entre otros.

Conscientes de las ventajas de este modelo, en los últimos tiempos Gradiant -siempre que las políticas de propiedad y privacidad de los proyectos lo permitan- está colaborando en proyectos de software libre, además de publicar módulos, librerías o contenedores de interés para la comunidad.

 

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