Hay un barullo bastante grande con algunas de las nuevas palabras clave laborales de moda, y en concreto con tres de ellas que contienen la palabra Data. En el post de hoy intentaré explicar, de forma muy sucinta, la diferencia entre un data scientist, un data engineer, y un data analyst.
Escribo este post porque con frecuencia veo confusión en el uso de los mismos, incluso en ofertas de empleo – lo que es especialmente grave. Me sucedió hace poco que me llamaron de una empresa para saber si me interesaría cambiar de proyecto y yo estoy muy contento donde me hallo ahora mismo, pero no voy a descartar una opción antes de oirla en detalle, porque nunca se sabe.
El asunto es que a pesar de que dijeron buscamos velocidad, cuando me describieron las funciones resultan que lo que buscaban era tocino. Yo me dedico a la velocidad, pero no al tocino, así que no llegó muy lejos aquella conversación. Intentemos, aunque sea simplificando mucho las descripciones (¡un párrafo por rol!), que eso no se repita.
Data Scientist
Está implicado en el desarrollo de modelos matemáticos y algoritmos para explotar datos y obtener nueva información de ellos. Esto requiere conocimiento de bases de datos, ya que es de esas bases de datos de las que hay que extraer información que serán procesados o actuarán como entrada a nuestro modelo matemático. Nociones básicas de programación para implementar versiones básicas de los modelos y los algoritmos desarrollados también son clave.
Conocimientos clave: matemáticas, SQL, Python, R.
Data Engineer
Está implicado en el desarrollo del software que ha de procesar los datos tanto que actuarán de entrada a los desarrollos de los data scientist como de almacenar la salida procesada, el resultado del trabajo. Es de los tres roles que tratamos hoy el que más se alinea con el puesto de desarrollador de software de toda la vida, si bien es un desarrollador de software con conocimientos en sistemas de big data.
Conocimientos clave: Scala, Python, Hadoop (y toda la utillería habitual de big data), Spark.
Data Analyst
Es un rol más próximo al desarrollo de negocio. Su función es interpretar datos (también los datos de salida de los sistemas desarrollados por los Scientist y los Engineer) y extraer a partir de ellos conclusiones e implicaciones para el mundo real que faciliten la toma de decisiones de negocio correctas.
Conocimientos clave: estadística, software de generación de reports (Tableau, Qlikview), hojas de cálculo, algo de SQL.
Muy de acuerdo en la confusión que hay y se agradece el post.
Echo a faltar un par de responsabilidades o funciones (no sé muy bien como llamarlas):
1) el que se encarga de analizar/decidir/iterar qué algoritmo aplicar en cada problema. Donde yo lo ubicaría sería en el rol de data scientist y probablemente ya lo estés incluyendo ahí aunque a mí no me queda claro.
2) el que conoce el «dominio» de negocio y es el que sabe qué plantear el problema a resolver, decir qué parámetros son relevantes, mejor interpreta resultados, y sobre todo, sabe identificar las «features» (perdón pero no sé como traducirlo*) y el contexto de los datos en bruto. El que más se le parece de los tres roles es el de Data Analyst pero en mi opinión es algo más.
Saludos
(*) Como «feature» me refiero a variables calculadas/derivadas de los datos en bruto que permiten acelerar/optimizar los modelos/algoritmos aplicados o incluso habilitar modelos/algoritmos que no serían posibles con sólo los datos en bruto.
Varios ejemplos triviales del mundo retail físico (que es donde hemos empezado a hacer nuestros primeros pinitos en el tema):
– Los datos de ventas en un sábados son un día especial y hay que tenerlo en cuenta.
– No es lo mismo las ventas en periodo normal o en periodo rebajas.
– Una bajada de ventas en una tienda concreta se puede deber a una falta de stock.
– La sensibilidad a factores exógenos: el clima es muy típico, pero hay más y hay que saber identificarlos.
– Un problema típico es encontrar el mejor momento para empezar los descuentos (si te anticipas perderás margen, y si vas tarde te quedará stock y tendrás que ponerlo en un outlet posiblemente a pérdidas) – ¿qué datos o combinación de ellos me permiten estimar ese momento óptimo? y no menos importante ¿Cúales no?
– ¿Cómo segmentar los productos/puntos de venta?
– ¿Cómo influye la cadena logística en la venta?
…
Muchas gracias por tu comentario, Luis. Como ya maticé a alguien ayer en un tuic, el post lo escribí rápido y lo publiqué de un tirón, para no dejarlo en borrador infinitamente. Tengo pendiente ampliar explicando lo que se pide a un Data Architect, pero a ver si esta noche me da tiempo :D
Sobre tus cuestiones:
¡Gracias de nuevo!