Un espacio para compartir ideas, tutoriales, automatizaciones y experiencias reales de trabajo con plataformas de datos y analítica. Artículos y notas sobre datos, Power BI, Fabric, Azure y automatización.
Ciertamente a pesar de que Power Bi es un simple "Lector de Datos" por así llamarlo, es decir que no puede tener una ingesta de datos, tiene un característica muy interesante que nos permitiría simular o engañar al usuario para obtener ese comportamiento. Estoy hablando de un lugar donde seleccionar valores de un determinado rango para simular diversos escenarios de medidas, interactuar con la variable como una segmentación y visualizar y cuantificar diferentes valores clave de los informes.
La característica son los parámetros, mejor llamado en ingles "What if parameters". Vamos a ver como aplicarlo.
Power Bi viene por defecto, valga la redundancia, con un defecto de modelado llamado "Auto date/time". Ésta es una opción de Power Bi Desktop o de un archivo en particular que se encuentra bajo la opción Data Load con título Time Intelligence.
¿Por qué no es un buena opción?
Pues para responder ésto primero veamos de que se trata. Para ello voy a mostrar un imagen de un modelo clásico y sencillo de Adventure Works conectado con DAX Studio. Veamos que tablas tenemos cargadas en el modelo.
Como pueden ver tenemos las tablas clásicas del modelo junto con unas adicionales de nombre "LocalDataTable_XXX". Éstas son Tablas Fecha que fueron creadas automáticamente por Power Bi por tener activada la opción mencionada. Auto date/time va a generar una nueva tabla en nuestro modelo por cada columna de tipo fecha que tengamos en el modelo. Cada una de éstas columnas se relacionará a una "LocalDataTable_XXX" para tener desagregados como Año/Trimestre/Mes/Día como así también para ejecutar cálculos de time intelligence.
Recién ahora podemos responder porqué es tan malo tenerlo cargado. La realidad es que depende el caso, si simplemente tenemos un Power Bi de una tabla para responder sencillos escenarios no habría problemas. El problema surge cuando tenemos varios requerimientos que responder que involucran un modelado. Una de las primeras reglas de modelado consiste en tener una tabla fecha que nos permita relatar hechos en el tiempo o inteligencia de fechas. Siempre que éste sea el caso crearíamos nuestra propia dimensión fecha. Por lo tanto, si tenemos un modelo con muchas dimensiones que tienen fechas como fecha de nacimiento, fecha de vencimiento de producto, entre otras. Las mismas van a generar tablas automáticas por todo el modelo haciéndolo cada vez más pesado en tamaño y en performance.
Espero que el consejo les sea útil para reducir el tamaño de esos archivos enormes y mejorar sus modelados.
Algo que muchas veces no se tiene en cuenta hasta el final es la implementación de la puerta de enlace. La mayoría de los proyectos de Power Bi suele tomar datas de fuentes On Premise (locales) llevadas al servicio de Power Bi en su portal web.
Ahora bien una cosa es construir un informe hermoso en Power Bi Desktop y otra es tenerlo funcionando en un portal donde los datos fluyan cada día. La realidad es que si colocamos nuestro informe en un portal web con datos locales en nuestros servidores necesitamos de otro programa. Un programa que sirva como puente entre mis datos locales y ese portal viajando por canales privados automáticamente. Aquí es donde aparece el famoso On Premise Data Gateway.
El programa puede estar instalado en cualquier computadora que tenga visibilidad de los datos en la intranet (al igual que nuestro Power Bi Desktop al momento de construir). Pueden encontrarlo sencillamente en éste enlace.
Aun que muchas veces instalemos programas dando siguiente siguiente siguiente, siempre es bueno conocer más detalles del mismo. En este caso vamos a conocer los puertos por donde viaja la Puerta de Enlace de Power Bi mejor conocida como On Premise Data Gateway.
Esta información es necesaria en caso que tenemos limitaciones corporativas configuradas en la red o administremos la misma. El gateway solo necesitará puertos de salida.
La puerta de enlace se comunica con Azure Service Bus mediante una dirección IP junto con un nombre de dominio completo (FQDN). Si fuerza a la puerta de enlace a comunicarse a través de HTTPS, usará estrictamente solo FQDN y no se comunicará mediante el uso de direcciones IP.
En la siguiente lista se describen los FQDN que usa la puerta de enlace:
Newsletter
Recibí nuevos artículos en tu correo
Suscribite para enterarte de nuevas publicaciones, tutoriales y novedades sobre nuestros artículos y herramientas.