La Data Web

¡Hola a todos! Bienvenidos a La Data Web y a este nuevo post relacionado a visualizaciones customizadas.

Me presento, soy Jonathan Muñoz y trabajo hace aproximadamente 2 años en Pi Data Strategy & Consulting como BI & Analytics Consultant, y además hace 3 años que me encuentro inmerso en el mundo de los datos.

Me gusta mucho la música, toco la guitarra en mis tiempos libres y me encanta viajar. En un futuro espero seguir creciendo en este apasionante mundo llamado Big Data porque creo fervientemente que los datos bien representados y con el significado apropiado aportan valor a la toma de decisiones de cualquier individuo u organización.

¡Pero hasta aquí la presentación! Vamos a los que nos compete hoy. En esta oportunidad vamos a tratar un requerimiento puntual que me tocó desarrollar con un usuario para el cual trabajé. Este artículo nos ayudará a pintar una línea entre dos líneas en un mismo gráfico que quedan cortadas por ser distintas medidas de análisis como por ejemplo "monto actual" y "Predicción" para así poder mejorar la experiencia del usuario.

Hace tiempo vengo encontrándome con fallas de modelado en las que las personas rompen la direccionalidad de dos tablas o más por factores que pueden ser resueltos de otro modo. También casos de múltiples tablas de fecha.

Ciertamente una de las reglas de oro al modelar es mantener las direccionalidades "simples", es decir, evitar el "ida y vuelta". Este tipo de dirección podría funcionar en casos muy puntuales de modelos estrella bien definidos, pero si mi modelo tiene copos de nieve o es multi estrella podría complicarse. Aún más si no tenemos un modelo definido con la teoría y solo cargamos tablas. Al igual que el many-to-many no controlado puede ocasionar problemas, la dirección importa y podría provocar ambigüedad en el modelo (cuando las relaciones comienzan a desactivarse porque hay múltiples caminos a un número o el número no se filtra como esperamos porque los filtros direccionados rompen las reglas de negocio).

Otra situación recurrente surge si necesitamos trackear algún valor por una fecha distinta, tenemos soluciones viables más estables que crear muchas tablas fechas. Hablo de la posibilidad de usar una relación inactiva.

En varias oportunidades me crucé con grandes modelos que tienen varias tablas de hecho. Lo cierto es que no siempre esas tablas van a compartir las mismas dimensiones y trabajar al mismo nivel de detalle. El caso más común que puede ocurrirnos es cuando la granularidad de fechas es distinta. Hace tiempo me vengo encontrando con dudas de cómo organizar el modelo cuando sucede eso. Tenemos tablas de hecho a detalle de día, otras a mes y otras a años. El problema es que luego quieren combinar los gráficos comparando valores y con cierto challenge que yo suelo hacer muchas soluciones propuestas no saben cómo resolver esta problemática.

Este artículo va a mostrar lo que NO se debe hacer del punto de vista de data modeling para comparar los valores en un gráfico y lo que SI debemos hacer para relacionar las distintas granularidades en nuestro modelo manteniendo la multi-estrella lo más liviana posible.

Hace no mucho tiempo Power bi ha incorporado soporte para la lectura de archivos Parquet evitando la creación de enormes funciones en power query para intentar llegar a dichos datos. La parte más atractiva de la extensión es leerla desde un Azure Data Lake puesto que sería más probable que los datos estuvieran almacenados allí.

Recientemente un compañero tuvo un inconveniente para conectarlo de forma tradicional y nativa. El "combinar" automático de Power Query no funcionaba. Fue entonces como llegue a una segunda forma de combinar los archivos parquet de una única tabla. 

Éste artículo muestra como conectarnos a archivos parquet de un Azure Data Lake Gen2 en una carpeta que representa una sola tabla en dos formas distintas.

Hace un tiempo que se me viene presentando requerimientos de personas no tan afines a Power Bi pero si al análisis de datos más duro que va directo con lenguajes de programación como Python y R. 

Los pedidos pasan por poder fácilmente llegar a los datos de modelos tabulares completamente funcionales para respuestas o análisis adhoc que se solicitan en el momento. Naturalmente el pedido solía resultar en comentarles que podía correr Python desde el interior de Power Bi Desktop, exportar sus datos, etc. Todo eso puede ser una solución preventiva pero no creo que se compare a la nueva posibilidad de la API que ahora esta disponible (GA) en Power Bi.

Éste artículo relata las restricciones del request y como formarlo desde el lenguaje de programación Python formando un Pandas DataFrame.