Conversación con Juanjo Ojeda

Juanjo Ojeda comenzó su vida laboral en cuanto tuvo edad para ello, en el año 2001, posponiendo su formación académica superior hasta 2010, tras experimentar en diferentes sectores y posiciones. En 2018 se graduó en física teórica en la Universitat de Barcelona (UB) y desde entonces ha centrado sus esfuerzos y energías en comprender cómo el sector tecnológico puede desempeñar un rol estratégico en el desarrollo de las soluciones que deben dar respuesta a los retos del mundo actual, y del futuro…Actualmente es Chief Data Officer en Netquest.

Mientras repasaba tu biografía me ha llamado la atención que estudiaste Física y que además lo hiciste mientras trabajabas en otros proyectos. ¿Qué te llevó a tomar este camino?

En su momento tomé la decisión de emprender mi vida adulta, con todo lo que ello conlleva, de manera precoz. Así que con veintipocos años ya había adquirido cierta inercia en mi periplo laboral, habiéndome posicionado en un trabajo bien remunerado y con bastante responsabilidad. Como te puedes imaginar, esa inercia era difícil de romper, pero una noche de noviembre de 2008 se disipó de golpe. Fue en el momento en que, volviendo de cenar con una amiga, un tipo decidió impactar con su coche contra la moto en la que circulábamos. Durante el largo proceso de recuperación tuve tiempo de replantearme mi situación y reconducir mi vida hacia un entorno más interesante y enriquecedor, donde los retos mentales fueran el día a día. Así pues, decidí empezar por un reto mayúsculo: estudiar física después de años sin coger un libro de texto. Además, debido a que ya me había independizado, tuve que mantener un cierto nivel de ingresos para no tener que cambiar demasiado mi situación personal.

¿Y en qué momento empezaste a desarrollar tu pasión por los datos?

¡Eso me viene de serie! De pequeño ya me fascinaban los ordenadores y la informática en general, así que a los 9 años decidí apuntarme a clases extraescolares, y al poco empecé a experimentar con mi 08086 de segunda mano. Al ver todo lo que se podía hacer con aquella máquina (nada en comparación con la tecnología actual) supe que mi futuro estaría ligado, de una manera u otra, al uso de esas herramientas.

Más tarde, ya en mi primera etapa de vida adulta, empecé a trabajar con bases de datos (MS-Access), macros en Excel y a desarrollar soluciones en Visual Basic, todo muy amateur. Pero ciertamente ese interés, y una cierta habilidad, me permitieron ganarme la vida durante unos años sin tener formación reglada al respecto.

Una vez comencé la carrera de física, mi atracción hacia el mundo Data incrementó exponencialmente. Básicamente empecé a descubrir cosas que iban más allá del uso de bases de datos para hacer presupuestos de obras o gestionar equipos de trabajo. Por ejemplo: quedé impresionado por la teoría de la información, o por el hecho de ver cómo mediante el uso del análisis de datos se pueden inferir propiedades intrínsecas del Universo en el que vivimos. Sin duda esto fue un punto de inflexión en mi pasión por los datos.

Más tarde, justo antes de empezar mi aventura laboral en el sector tecnológico, centré mi atención en las técnicas de Machine Learning y Deep Learning, haciendo el trabajo de final de carrera sobre el impacto de la topología de las redes neuronales en la trasmisión de la información a través de estas.

Entrando ya en el mundo de los Datos, yo te conocí hace unos meses a raíz del proyecto Datalake en Holaluz. Lo primero que quería pedirte es que expongas las grandes diferencias entre un DataLake y un DataWarehouse y la relación entre ambos

Intentaré huir un poco de las definiciones clásicas y explicarlo a mi manera… Haciendo una analogía con el ciclo metabólico, para mí el DataLake (DL) sería el encargado de ingerir los nutrientes, realizar las transformaciones básicas y depositar los subproductos (lípidos, aminoácidos, etc.) en diferentes estados en función de su posterior utilidad. El DataWarehouse (DW) sería la parte responsable de coger los diferentes depósitos de nutrientes y transformarlos en productos útiles, como el ATP en el caso del ciclo de Krebs.

Volviendo a un lenguaje más tecnológico, el DL contendría la información en diferentes estados (cruda, procesada, particionada, etc.) con el objetivo de alimentar los pipelines de datos hacia el DW, donde se dispondría la información en un modelo puramente analítico, listo para ser consumido por los usuarios.

Por tanto, el DL debe ser una herramienta orientada al procesado, organización y fiscalización de los datos de una compañía, TODOS los datos. Mientras que el DW se debe enfocar hacia el uso analítico, donde sólo encontremos los datos útiles para el día a día, y donde la información ya está depurada, validada y consolidada.

Y cuál es el momento en el que una empresa ha de plantearse tener un DataLake. Porque es un proyecto de gran envergadura y diría que no apto para todo el mundo. ¿En qué situaciones lo recomendarías y en cuáles no? 

En sí el concepto de DataLake no debería intimidar a nadie, otra cosa es el nivel de madurez y capacidades que se le quieran exigir. Así pues, desde mi punto de vista, cualquier empresa debería disponer de un DL, aunque sea en su fase más embrionaria, ya que esto la habilita a poder hacer valiosos proyectos de datos en el momento que se requiera.

Por ejemplo, una vez escogida la tecnología/soporte donde almacenar los datos, el simple hecho de definir una buena estructura de carpetas robusta para mantener mínimamente ordenados los ficheros, ya es un primer paso para construir un futuro catálogo de datos y ayuda a tener la información más accesible.

Dicho esto, si no se han hecho los deberes y la infraestructura de datos ha crecido de manera desgobernada, la implementación de los conceptos básicos de un DL puede resultar algo traumática, ya que seguramente implique cambios significativos en la manera que se trabaja con datos y en los procesos productivos pre-DL.

Dime los tres grande DOs y los 3 grandes DON’Ts a la hora de iniciar un proyecto un proyecto de Data Lake

Esto depende mucho del entorno de datos que se quiera atacar, pero se pueden generalizar algunas acciones básicas.

Cosas a hacer:

• Obtener el acuerdo de “toda la compañía” de que realizar un proyecto de las características de un data lake es algo totalmente necesario y que vale la pena invertir en ello. Digo esto porque, en la mayoría de los casos, sin este convencimiento el proyecto puede correr el riesgo de diluirse en las prioridades del día a día y, siendo una cosa que acaba impactando en todas las áreas de la empresa, hay que tener claro su carácter estratégico.

• Identificar los verticales de negocio más críticos para analizar los flujos de datos de estos y planificar implantaciones “end-to-end” de manera incremental. De esta manera se puede empezar a aportar valor desde las primeras etapas del proyecto.

• Definir un stack tecnológico en función de las necesidades a cubrir a nivel de volumetrías, tiempos de ejecución, velocidad de refresco de la información, etc. Lo ideal es que este stack esté acotado y se base en estándares que hayan demostrado su efectividad.

Cosas a evitar:

• No se debería dar rienda suelta a las peticiones de los usuarios de negocio. Se que esto puede resultar impopular, pero debemos afrontar el problema de la diversidad de criterios estableciendo unas guías del buen uso de las herramientas de datos. Es cierto que, para que esto cale entre los usuarios, se debe realizar una tarea de formación al respecto, ya que normalmente los malos hábitos relacionados con este ámbito vienen heredados del anterior sistema que se pretende substituir.

• Intentar atacar el problema de manera monolítica. Es decir, pensar que la solución pasa por una única herramienta. Al tratarse de un problema tan amplio y con tantas casuísticas, debemos pensar de manera modular. Esto también ayuda a poder realizar el proyecto de manera ágil, aportando valor incrementalmente y de manera iterativa.

• Relacionado con el punto anterior, dada la complejidad del reto, no podemos pretender solucionar todos los problemas a la primera. Tenemos que ser flexibles a la hora de establecer los objetivos de cada fase del proyecto e intentar no sentirnos mal por el hecho de generar dosis moderadas de deuda técnica.

¿Y qué tipo de perfiles se necesitan para poner en marcha y mantener de forma correcta un DataLake?

Sin entrar en el número de personas e intentando pensar en un caso muy general, lo ideal sería contar con:

• Data Architect: Encargado de definir la estrategia técnica en base a las necesidades de la compañía. También debería ser la persona de referencia para difundir la cultura del dato y garantizar las buenas prácticas en cada una de las fases del proyecto.

• Data Engineer: Encargado de implementar la solución y de tomar decisiones técnicas relevantes en el desarrollo de cada módulo del proyecto. Deben ser perfiles con conocimiento sobre el stack tecnológico escogido y tener por la mano nociones de infraestructura en el ámbito que convenga (cloud o on-premise).

• Data Analyst: Perfil encargado de analizar la estructura y contenido de los datos a almacenar/procesar. Con su aportación se pueden optimizar los procesos e implementar herramientas de control de calidad y monitorización.

• Business Analyst: Capaz de entender las necesidades de negocio y velar por que la solución técnica propuesta de una correcta respuesta a las mismas. Debe ser el encargado de recoger los requerimientos y tratarlos con el Data Architect. También debería gestionar las expectativas de los equipos de negocio.

En cualquier caso, más allá de los perfiles y responsabilidades del equipo que se encargue del proyecto, creo que lo más importante es la comunicación con los diferentes stakeholders y con los responsables de las diferentes áreas implicadas.

En los últimos tiempos he visto que en muchos foros se recomienda la puesta en marcha de un Data LakeHouse. ¿Cuáles es tu visión al respecto? ¿En qué casos lo recomiendas? 

Antes de nada, he de decir que no soy muy fan de poner nombres ”molones” a las cosas para que tengan más tirada. En este caso, por ejemplo, el llamado Data Lakehouse (DLH) no deja de ser una manera de aprovechar los beneficios de nuevas herramientas (o que han mejorado en los últimos tiempos) para explotar un DL “tradicional”. Es decir, que todo lo que yo considero atribuible a un DL sigue siendo necesario para añadir esa capa de explotación extra que vendría a anticipar lo que luego debería encontrarse en el DW.

Así pues, yo creo que cada problema tiene diferentes posibles soluciones y todo depende de lo que uno quiera invertir en desarrollar la solución, en costes de mantenimiento, infraestructura, etc. Por ejemplo, en AWS habrá casos en los que consultar ficheros parquet almacenados en S3 sea más practico usar Athena (modelo DLH) y en otros tirar de Redshift (modelo DWH), pero en cualquier caso las dos herramientas te permiten atacar el mismo problema con costes y rendimientos diferentes.

Y por lo que veo esto no se acaba aquí. Ahora se habla también de Data Mesh, Data Fabrik, etc. Te quería pedir las grandes diferencias entre todos estas opciones y cuámdo tiene sentido optar por cada uno

Lo dicho anteriormente, todos estos nombres creo que lo único que hacen es alejar a las personas ajenas al gremio de lo que realmente importa, dar soluciones eficientes y adaptadas a cada caso de uso. Es cierto que en la literatura de cada “método” puedes encontrar ideas innovadoras, diferentes a lo establecido en el pasado, pero ciertamente creo que no se trata de un cambio de paradigma o de un salto generacional. Creo que todo lo que se está haciendo ahora mismo en el estado del arte de Data es algo que forma parte de un enfoque similar pero intentando añadir valor en capas que antes ni se contemplaban, por ejemplo, poniendo la información del DWH a disposición de los usuarios mediante el uso de APIs para tener los accesos más controlados e higienizar el uso de las bases de datos.

Resumiendo, y sin ánimo de ofender a nadie, creo nos perdemos mirándonos el ombligo intentando satisfacer necesidades que no tengo claro que sean del todo reales o prioritarias. Es como cuando oigo hablar del 5G y aún tenemos déficits brutales de cobertura en el 4G. Es decir, que me parece muy bien que intentemos modernizar nuestro campo de trabajo, pero creo que ahora mismo estamos dando vueltas sobre la misma idea. Me gustaría que nuestros esfuerzos se centraran más en buscar maneras de mejorar cosas que ahora nos “hacen daño”, como el control de calidad de los datos, herramientas eficientes de gestión de metadatos, etc. Y también poner el foco en el uso de técnicas provenientes de otros ámbitos, como el de la inteligencia artificial.

Termina esta frase. Un/a buen/a Data Architect es…

Difícil de encontrar.

Recientemente te has incorporado a Netquest como Chief Data Officer (CDO). ¿Qué grandes retos y proyectos tienes en los próximos 12 meses?

Ciertamente estoy muy contento y emocionado por empezar esta nueva etapa en Netquest. Al tratarse de una empresa que, mediante la recolección de multitud de datos de actividad online de nuestros panelistas, somos capaces de ofrecer a nuestros clientes una visión 360º de su mercado, ayudándoles a mejorar significativamente y entender las complejas dinámicas de su sector. Por lo tanto, los datos son el propio producto, así que te puedes imaginar el alcance del impacto positivo del trabajo del equipo de Data que dirijo.

A nivel de retos, claramente nos encontramos en una época de crecimiento exponencial del comercio online. Esto hace que para poder tener esa visión 360º que comentaba, necesitemos procesar y analizar unas cantidades ingentes de datos, y eso nos lleva inevitablemente a hablar de Big Data y de Inteligencia Artificial. Así que el próximo año estaremos implementado soluciones cloud para mejorar nuestros productos y sacarle más provecho a los datos que tenemos. ¡Todo un lujo para mí! 

Y si pensamos en los próximos 5-10 años ¿qué grandes cambios podemos esperar en el mundo de los datos?

Como bien sabes, hacer predicciones no es una tarea sencilla, y más en un sector tan cambiante como el de los datos. Lo que sí que es cierto es que podemos hablar de tendencias o necesidades que se están manifestando recientemente, y parece que la tecnología está empezando a recoger el guante para darles respuesta.

Por ejemplo, creo que el Big Data dejará de ser una cosa especial, alejada del data “tradicional”, y que empezaremos a tratar los datos sin tener que cambiar las técnicas en función del volumen de los mismos.

También creo que, de manera parecida a lo que ha pasado en los últimos 5 años con IA, también surgirán herramientas de mano de los grandes del sector para estandarizar y ‘eficientar’ la manera de trabajar con la información, de manera que el valor añadido se produzca más en la capa de entender el problema y sacarles el máximo partido a esas herramientas.

A ti y a mí, además de la pasión por el dato nos une la pasión por la buena música, es decir el  heavy-metal. Podríamos pasarnos horas hablando sobre el Rock Fest o el concierto de Iron Maiden en Barcelona, pero como es una conversación de Data, te voy a pedir tu opinión sobre el impacto de los algoritmos en el mundo de la música. Recientemente, por ejemplo, me topé con un programador que había creado un set de música electrónica con Generative AI.  ¿Crees que podría pasar esto en el mundo del heavy-metal? Es decir que haya algoritmos que compongan un temazo como Fear of The Dark 

¡Me encanta esta pregunta! Actualmente están saltando a la palestra modelos de billones de hiperparámetros capaces de mostrar espectaculares dotes artísticas, como por ejemplo, GPT-3 a la hora de escribir narraciones increíbles o Dall-e renderizando imágenes sorprendentes y que hasta ahora sólo habían podido ser concebidas por la mente humana.

Ahora bien, para entrenar estos modelos se han utilizado datasets repletos de contenido generado por el intelecto humano, por tanto, sus resultados no dejan de ser producto de una interpolación matemática muy compleja. Es decir, que sin quitar mérito a los logros de estas tecnologías, sin tener acceso a los recursos generados por miles de personas brillantes, el resultado sería decepcionante.

Volviendo al tema de la música. En este caso, la propia naturaleza de una pieza musical hace que sea muy factible obtener grandes hits mediante técnicas de Deep Learning, ya que al final el número de grados de libertad a la hora de componer una melodía es finito. Todo se reduce a secuencias de notas, duración de las mismas y ritmo. Por ello, si dispusiéramos de todo el tiempo del Universo para realizar combinaciones estocásticas de estas variables, en algún momento nos acabaríamos topando con genialidades como Fear of the dark. Por lo que si acabamos usando algoritmos que capten cuáles son los valores más satisfactorios para estas variables conseguiremos llegar en poco tiempo al resultado óptimo.

En cualquier caso, una cosa que creo que nunca conseguiremos con la IA es el fenómeno “fan”, el reconocimiento al trabajo duro y a la virtuosidad. Creo que eso no se puede alcanzar con el simple hecho de obtener un resultado óptimo, un producto apetecible… creo que eso va más allá de la lógica y contiene ingredientes socioculturales inherentes al ser humano.