La mediana es una médida de tendencia central que nos va a ayudar a abrir los ojos cuando nos encontremos con datos que puedan estar sesgado. Es como una media aritmética mejorada para casos en los que los datos no parezcan una montannita.
Así que antes de ponerte a calcular la media de algo, deberías visualizar que forma tienen estos datos. Si ya has decidido que la media no te sirve o simplemente quieres comparar la media y la mediana y no sabes como calcular esta última
Primero, la parte fácil.
Como calcular la media de una columna en SQL
AVG(columna)
Ejemplo
SELECT AVG(columna) FROM tabla
Como calcular la mediana de una columna usando SQL
Aquí la cosa ya se complica un poco más. Así que tenemos que tirar de definición de mediana.
percentile_disc(0.5) WITHIN GROUP (ORDER BY columna) AS mediana
Vamos a desmenuzar que es lo que estamos haciendo:
La mediana es el igual al percentil 50, es decir lo que queda justo en la mitad de todos nuestros datos. Esto ya explica el percentile_disc y el (0.5)
Otra cosa que tenemos que tener en cuenta es que para calcular la mediana necesitamos tener ordenados nuestros datos por ellos vamos a usar el ORDER BY.
Finalmente, queremos renombrar la columna como mediana. Así que AS mediana
Ejemplo práctico con media y mediana eb una sentencia SQL
SELECT categoria, avg(precio) AS media, percentile_disc(0.5) WITHIN GROUP (ORDER BY precio) AS mediana FROM producto GROUP BY categoria ORDER BY avg(precio);
En mi último equipo tuvimos que encargarnos de hacer desde cero todo el sistema de reporting de la unidad, desde la investigación de nuevas métricas usando metodologías user experience research como entrevistas y focus group a crear todo el sistema de eventos en AWS, la ETL pipeline y el dashboarding y reporting en Python. Y todo esto usando metodologías Agile. No veas que converaciones teniamos más frikis de vez en cuando sobre métricas, calidad de los datos y performance.
Yo por mi parte además me llevaba muy bien con el depatamento de Devops o Reliability Engineering que eran los que usaban Kubernetes, Dockers y bases de datos, y todo lo que tenía que ver con PaaS (Platform as a Service). Y uno de mis compas le encantaba explicar lo que aprendía sobre analytics y tenía super paciencia al explicarlo. Eso me llevó a aprender sobre la existencia de balanceadores, la posibilidad de tener el backup en dos ´nubes´ diferentes o el reporting en Prometheus
Como firme defensora de trabajar en Agile en equipos multidisciplinares y diversos hay una cosa que no me terminaba de encajar al principio. Explicar a los programadores que había que testear los datos y que la definition of done no era la misma para los analistas que para los programadores nos trajo al equipo muchos dolores de cabeza y conversaciones metafísicas. Y mucho ensayo-error hasta encontrar la mejor metodología, donde tanto analistas como ingenieros tuvieramos nuestros requerimientos requeridos.El mayor problema era que tras meses implementando algo y darlo por finalizado, debíamos mejorarlo, o las necesidades de los usuarios cambiaban o nos mandaban hacer un análisis adhoc. Todo esto significó que tuvimos que aprender a trabajar juntos, y a su vez desaprendimos a trabajar como lo haciamos antes. Eso es lo bonito de Agile.
Y si llevamos todo mi largo comentario a metodología de Big Data e Inteligencia Artificial y la posiblidad de hacer todo esto en la nube podemos encontrarnos que este problema lo van a tener todas las empresas Data-Driven. Son mucho los equipos de desarrollo de software que se encuentran en esta tesitura, y por ello sólo era cuestión de tiempo que apareciera un nuevo manifiesto - DataOps.
DataOps o DevOps
DataOps toma la forma de su primo los DevOps, y lo que pretenden es que se integre esa mejora continua en los datos, mejorando así además la calidad de estos. Así que no, no se dan por finalizadas las tareas tan facilmente como ocurre en otros equipos de software, igualmente que los DevOps tienen que mantener operativa la plataforma 24/7. Como comenta IBM en su artículo en Data y Analytics hay una gran diversidad que operaciones a realizar y aunque todos sean con data, requieren de diferentes procesos y herramientas. (´Big Data Workloads are Diverse.´)
El DataOps manifiesto en castellano
El manifiesto empieza al igual que el Agile Manifiesto con las siguientes afirmaciones
Personas e interacciones en lugar de procesos y herramientas
Soluciones de analítica eficientes en lugar de documentación comprensiva
Colaboración con el consumidor en lugar de negociaciones contractuales
Experimentación, interacción y retroalimentación en lugar de un diseño extensivo directo
Titularidad multidisciplinar de las operaciones en lugar de responsabilidades aisladas.
La traducción del manifiesto la puedes encontrar en el siguiente enlace, cuenta con 18 puntos que van desde la formación de los equipos, a la calidad de los datos y la necesidad de procesos de retroalimentación para la mejora continua. Están bastante claros, así que no vale la pena que los detalle aquí. https://www.dataopsmanifesto.org/dataops-manifesto.html?lang=es .
Métricas para medir el Performance de tu equipo de Analítica o Data team
