En este post os queremos contar una de las características de nuestro software Datenea, la plataforma de Inteligencia Artificial y Machine Learning que busca incrementar la gobernanza, la reproducibilidad y la visibilidad de los proyectos de Data Science. Pero antes, queremos explicar la razón detrás de una de sus características principales: la capa de acceso a datos transparente para los data scientists y data engineers.
Variedad de los datos
Desde que se empezó a teorizar sobre cuáles eran las características de los proyectos «Big Data», una de las principales ha sido la variedad de los datos. Generalmente, se entiende que, en proyectos de este tipo, tenemos muchas fuentes de información y que, puesto que el origen no es controlable, cada una tiene sus formatos y, en demasiadas ocasiones, sus propias semánticas. Incluso cuando uno pensaría que los campos de estos orígenes hacen referencia a una misma entidad real.
También se habla de variedad de datos cuando nos referimos al almacenamiento y procesamiento de datos estructurados y no estructurados, aunque no es la vertiente que abordaremos en este post.
Hoy en día, esta característica asociada normalmente a los procesos de arquitectura e ingeniería de datos, también es extensible al momento en el que se van a explotar estos datos, es decir, proyectos de Data Science en el que interviene el análisis estadístico o el entrenamiento de modelos para la toma predictiva de decisiones. En esta situación, uno podría pensar que el proceso completo detrás de un proyecto con datos es algo así:
Es claro en este diagrama la variedad: muchos datos, procedentes de muchos orígenes sin ningún tipo de coordinación. A menudo, y es una práctica que recomendamos activamente en PiperLab, las compañías invierten para desarrollar procesos que les permitan ingestar esta información en un Data Lake, de manera que puedan reutilizar y reaprovechar el esfuerzo de tratar esta variedad después en múltiples proyectos de Data Science.
Sin embargo, este esquema no es realmente así: ya sea atacando a las fuentes de datos de origen o ya tratadas en un Data Lake, «lo que hacen los data scientists y data engineers» no es un monolito: se compone de múltiples subprocesos y tareas que podríamos categorizar así:
- Tareas de extracción de información
- Preprocesamiento y data quality de datos
- Análisis descriptivos
- Generación de variables
- Entrenamiento de modelos y evaluación de resultados
- Desarrollo de software sobre los modelos
- Automatización y puesta en producción
Estas familias de tareas, realmente, pueden tener un número alto de instancias según el proyecto: por ejemplo, típicamente, no hacemos un único análisis descriptivo sino que realizamos distintos análisis para estudiar distintas vertientes y dimensiones del problema que estamos tratando; o no solamente entrenamos una tipología de modelos predictivos, sino que, para un mismo problema, puede haber distintas soluciones. En definitiva, un proyecto de data science es, en realidad, un conjunto de tareas relacionadas entre ellas… ¿relacionadas exactamente cómo? Por datos.
También por otros objetos, como puede ser un modelo pero, sobre todo, por datos. Lo que genera una tarea lo aprovecha la siguiente, y lo que genera esta, lo hace la siguiente y así sucesivamente. Esto implica que, además, estas relaciones son de dependencia, esto es, la segunda utiliza unos datos que genera la primera y, por tanto, su éxito dependerá en gran medida de que la primera cumpla sus objetivos. Es decir que el esquema real se parecería más a lo siguiente:
En definitiva, un proyecto de data science es, en realidad, un conjunto de tareas relacionadas entre ellas… ¿relacionadas exactamente cómo? Por datos.
Esto sucede en todos los proyectos de Data Science, es algo normal ya que, desde el punto de vista de desarrollo es más sencillo estructurar los procesos por módulos, tareas, y abordar cada aspecto funcional del proyecto por separado, son estrategias de «divide y vencerás». Pero, como ya hemos visto, existe dentro de los proyectos, de forma no visible, toda una cadena de valor de los datos, que se van depurando y enriqueciendo con los distintos procesos. Si no somos capaces de estandarizar cómo hacemos esto dentro del proyecto nos acabaremos enfrentando a otro problema de «variedad» de datos, esta vez, interno y que hemos provocado inconscientemente nosotros mismos. La cuestión es, ¿cómo gestionan todas estas interdependencias los equipos de datos? ¿Existe en tu empresa una forma estándar de hacerlo, que sea visible, trazable y reproducible?
Existe dentro de los proyectos, de forma no visible, toda una cadena de valor de los datos, que se van depurando y enriqueciendo con los distintos procesos. ¿cómo gestionan todas estas interdependencias los equipos de datos?
Nuestro software: Datenea
En PiperLab, nos hemos enfrentado a este problema desde hace 7 años, reflejando en nuestra metodología las mejores prácticas para mitigar los riesgos que de esta situación se puedan derivar. Por ello, Datenea, la plataforma de Inteligencia Artificial y Machine Learning que hemos desarrollado para mejorar la gobernanza de los proyectos de datos, permite estandarizar las interdependencias entre tareas, creando una capa de abstracción de información que permita al data scientist tratar con los datos del proyecto de una forma transparente, tanto con los orígenes, como con los productos intermedios que se originan.
Para un data scientist que utiliza Datenea, leer un dato, esté donde esté, ya sea un origen o un resultado de una tarea, es simplemente hacer un «get» y guardarlo es simplemente hacer un «save». Esto implica una disminución enorme de la complejidad subyacente en los proyectos, incrementando la productividad. Además, esta característica es clave para poder realizar pipelines de datos robustos, trazables y reproducibles que, desde ya mismo, puedes definir sobre Datenea. Pero eso lo dejaremos para otro post.
