Retos en la evolución tecnológica en Uptime Analytics – Hasta el momento

Una de las ventajas de trabajar en una start-up es la posibilidad de tener una mayor cantidad de espacios, comparado con una empresa tradicional, para experimentar con diferentes tipos de tecnologías, frameworks y/o librerías, todo con el objetivo de resolver de la forma más costo eficiente los retos en la prestación de los servicios que ofrecemos.

En Uptime Analytics hemos pasado varias veces por las fases de ideación, prototipado y producto. En el último ciclo ejecutado nos concentramos en la idea de ofrecer una solución como servicio de analítica descriptiva y predictiva para hornos industriales de principio a fin.  Dicha solución incluye la recolección de datos en sitio, el almacenamiento de los datos “en bruto”, pasando por su transformación y cargue en un modelo de datos propio del dominio de hornos industriales, hasta la presentación y explotación de los datos a través de objetos descriptivos y predictivos accesibles a través de una interfaz gráfica web responsive.

En la fase de prototipado el objetivo es poder probar lo más rápido posible la idea, validarla con clientes actuales y con prospectos, por lo tanto, la herramienta principal utilizada es la plataforma de Qlik. Esta herramienta es utilizada principalmente por dos razones: desarrollo rápido que nos permite cubrir múltiples componentes de la solución, y debido a que contamos con expertos dentro de la empresa en el uso de la herramienta. Ahora bien, para la parte de recolección de datos desde la fuente, en etapa de prototipo lo clave es poder contar con los datos, por lo tanto lo que se busca es extraer los datos manualmente en algún formato no propietario, normalmente en formato CSV.

En la fase de producto el objetivo es convertir el prototipo en un servicio escalable, reproducible entre clientes y operacional. En menor o mayor medida cada uno de los componentes de la solución cumplen con todos o alguno de los elementos anteriormente mencionados, revisemos cada uno de ellos:

  • Recolección de los datos en sitio: la meta es automatizar lo que previamente es una tarea manual y dispendiosa, lo logramos a través de la combinación de nuestro Signal Hub que se instala en las plantas del cliente, y servicios de recolección y almacenamiento local (en caso de pérdida de conectividad). El tema aquí es que debido a las diferencias entre clientes es difícil contar con un producto de caja que cubra todas las necesidades. Nos hemos encontrado con esquemas de extracción común usando Modbus-RTU/TCP, hasta escenarios más complejos donde el dato reside en sistemas con estructuras de datos propietarios, pasando por escenarios en los cuales ha sido necesario crear circuitos especializados para leer pulsos eléctricos. En el corto plazo queremos ir consolidando los diferentes esquemas de recolección que nos hemos encontrado y crear una librería reutilizable de código para ser usado en los próximos clientes.
    Tanto en la fase de prototipado como en la fase de producto hemos mantenido una combinación de AWS DynamoDB y AWS S3, para almacenar los datos “en bruto” que se obtienen de las plantas del cliente.
  • Tareas programadas: como se mencionó anteriormente, en la fase de prototipado se desarrollan usando la plataforma de Qlik, pero en la fase de producto se desarrollan usando Apache Airflow como nuestra plataforma de ETL. ¿Porque el cambio? Contar con un mayor pool de personas disponibles para desarrollar ETL’s en el mercado (el requerimiento básico para desarrollar es que conozcan Python), y el no requerir costos de licenciamiento para su uso.
    Al igual que el componente anterior, las ETL’s varían entre cliente/fuente de datos aunque en menor medida que la recolección de datos, en este caso ha sido posible diseñar y desarrollar librerías estándar que permitan escalar más rápidamente la adquisición de nuevos clientes; aunque todavía hay temas por seguir evolucionado, las bases definidas y desarrolladas son lo suficientemente sólidas para seguir creciendo.
    En el mediano plazo tenemos contemplado experimentar con esquemas de streaming.
  • Modelo de datos estándar de hornos industriales: para este componente los prototipos funcionales también fueron desarrollados usando la plataforma de Qlik, pero ahora estamos usando bases de datos optimizadas para datos de series de tiempo, y que adicionalmente también brindan la facilidad de combinarla con datos en estructura relacional tradicional para almacenar datos categóricos que brindan contexto a los datos que se visualizan. ¿Por qué el cambio? En esencia, las mismas del punto anterior, con la salvedad de que no es necesario conocer Python, sino tener conocimientos en SQL.
    Con el objetivo de manejar y explotar grandes volúmenes de datos contamos con bases de datos especializadas en analítica a gran escala, las cuales estamos en proceso de pruebas y evaluación, por ejemplo, Apache Druid.

  • Tableros con objetos descriptivos y predictivos: este es el cambio más grande de cara a nuestros clientes, decidimos movernos a una plataforma de visualización usando diferentes componentes open source, que nos ofrecieran la flexibilidad para agregar nuevas capacidades sin depender de un tercero, hiciera uso de tecnologías abiertas y modernas (Flask, React) y permitiera a nuestros clientes la capacidad de hacer análisis con los datos depurados y procesados de manera independiente a Uptime Analytics de forma costo-eficiente.

Otro elemento importante que tenemos presente en nuestra evolución arquitectónica es el desarrollar la capacidad (tecnología, proceso, conocimiento) para poder utilizar los componentes arquitectónicos descritos hasta el momento como base para futuras líneas de solución orientadas a otros tipos de equipos industriales como generadores eléctricos, transformadores, motores de combustión, entre otros.

Como se ha visto hasta el momento hacemos uso extensivo de varios proyectos open source, por lo tanto, también es importante mencionar nuestra intención de ser “good citizen” en el mundo open source, a través de aportes al código fuente, documentación, participación en meetups, entre otros. Lo anterior es importante porque creemos que al participar activamente en este tipo de comunidades se construye un vínculo donde ambas partes nos beneficiamos, lo cual al final nos permite ofrecer una oferta de valor más robusta a nuestros clientes.

Por último, hasta el momento he dejado a un lado el entrenamiento y ejecución de modelos predictivos desde el punto de vista tecnológico, este tema será objeto de un próximo post.

Autor: Omar Ashton – CTO en Uptime Analytics