February 28, 2024
En este afán por ser independientes como profesionales de los datos, lo primero que se nos ocurre (en acento estadounidense, «nuestro» suena como «R») es construir el conjunto completo por nuestra cuenta, con Python. Cualquiera usa Scala, Python o R. El problema es común: estos lenguajes son fantásticos para trabajar con datos; tienen muchas bibliotecas gratuitas disponibles para datos que básicamente están destruyendo viejos modelos propietarios, como el monopolio que alguna vez tuvo Matlab. Pero no son tan brillantes para construir un servicio completo.
Tenga en cuenta que no estoy diciendo que esto no sea posible, solo estoy señalando que ninguna empresa de alta tecnología ha creado ninguna solución PWA completa con Python (ni los otros lenguajes mencionados). Es cierto que puedes visualizar análisis atractivos con Shiny, Streamlit o Dash de Plotly, puedes crear una API REST con Flask, pero no se trata de una verdadera independencia de principio a fin, solo un poco más de autonomía, por lo que la carga de trabajo general se desplaza pero no se reduce. No hay ningún caso de éxito aparte de las publicaciones de blog de Medium que solo muestran algunas facetas de creación de prototipos. Profundicemos en el tema.
Plotly es probablemente la biblioteca de visualización más asombrosa con la que he trabajado. Además, tienen otra biblioteca llamada Dash, que permite a cualquiera crear una aplicación web, ¡con Python! Parece ser la solución de datos que la gente estaba esperando. Sin embargo, hay un inconveniente clave: aún necesita ingenieros de software para crear su aplicación de datos.
Ya no necesitas un front-end que hable un idioma diferente, pero es necesario conocer o aprender la tecnología front-end: callbacks, input, output, etc. (programado con Python, sí)
y aún hay que construir la arquitectura de almacenamiento de datos y todas las DevOps para que todo funcione (o pagar a Plotly para que te ayude con esta última parte). Plotly significa más libertad para los desarrolladores de Python; libertad con la que todos hemos soñado, pero no la suficiente libertad para crear aplicaciones de datos.
Mira esta otra imagen: todavía necesitas un back-end y DevOps con Streamlit o Plotly Dash y un desarrollador de Python tiene que pasar por toda la curva de aprendizaje del front-end (convirtiéndose eventualmente en un pseudo front-end). La ventaja es que se reduce prácticamente un perfil para crear una aplicación de datos y el ingeniero de datos gana autonomía.
Streamlit ofrece paneles fáciles de prototipar: no son realmente atractivos, no son el tipo de aplicaciones de datos que realmente puedas vender o compartir con ese 40% del mercado que quiere compartir datos con sus clientes. Seamos claros: ya no hablamos de compartir los resultados con los demás, sino de productos de datos. Para que los datos avancen como área, necesitamos tener productos basados en datos, y esto requiere compartir los resultados de una manera profesional, con las últimas tecnologías de back-end y front-end. Es bueno compartir Streamlit con tus amigos y convencer a tu jefe de que invierta más recursos, pero está lejos de ser una verdadera oferta para crear una aplicación de datos que puedas vender.
El problema con Shiny es el mismo. Por lo tanto, uno acaba teniendo que pasar por una dura curva de aprendizaje para obtener esa autonomía, y aun así no se trata de una autonomía total; todavía le falta una pierna para correr.
Las herramientas de inteligencia empresarial, como Tableau o PowerBI, se suelen utilizar como última opción a la hora de crear un producto de aplicación de datos. No pueden escalar, no pueden ofrecer una experiencia de usuario real a sus clientes (piense en la diferencia entre navegar por Google Analytics y usar su última aplicación de Tableau).
No necesita ingenieros para las herramientas de BI, pero pueden ser utilizadas por pocos usuarios simultáneamente y crecen de forma lineal con el tamaño de su departamento de datos (necesita el doble de analistas de datos para ofrecer el doble de aplicaciones de BI). Básicamente, se necesita un ejército de analistas de datos y ordenadores del tamaño de un edificio para probar algo así. Eventualmente (cuando das servicio a más de 10 clientes) se convierte en el menos rentable de todos los escenarios.
Son herramientas de uso interno y no se pueden crear productos de datos a partir de ellas (si entendemos los productos de datos como activos que podrían venderse a escala). El trabajo manual para mantener los paneles actualizados, adaptarlos y modificarlos solo se amplía de forma lineal en función del número de analistas de datos de que disponga. Además, el resultado solo se puede ofrecer a un número reducido de usuarios antes de que el coste de su arquitectura aumente y se lleve cualquier beneficio posible.
Descargar este post en PDF para tenerlo cuando quieras
