La Data Web

¡Villano a la vista! 

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:

Una extraordinaria posibilidad se presentó en Power Bi hace unos meses. Ésta increíble característica nos permite llegar a un completo SelfService Bi con Power Bi lo cual antes era incompleto. Para podes nutrirnos de un Bi de Auto Servicio primero es necesario conocer cómo construir una capa semántica:

https://blog.ladataweb.com.ar/power-bi-capa-semantica/

Contexto

Hace tiempo que Power Bi puede establecer una conexión dinámica a un conjunto de datos compartido en el servicio de Power BI y crear muchos informes diferentes del mismo conjunto de datos. Esto significa que puede crear el modelo de datos perfecto en Power BI Desktop y publicarlo en el servicio Power BI. A continuación, usted y otros usuarios pueden crear varios informes diferentes (en archivos .pbix independientes) a partir de ese mismo modelo de datos común y guardarlos en distintas áreas de trabajo. Esta característica se denomina "Conexión dinámica al servicio Power BI". Si bien esto parecería que da por resuelto el conecto que buscamos, la realidad es que tiene una gran limitación. Solo es posible publicar el contenido a la misma área de trabajo. Éste problema hace imposible que cada quien pueda construir sus tableros dado que se volvía insostenible el area de trabajo donde se encontraba el conjunto porque se llenaba de reportes y paneles confusos para todos los involucrados.

¿Qué es self-service Bi?

Bi de Autoservicio. Permite a usuarios finales conectarse a un conjunto de datos limpio, manipulado y semánticamente modificado con nomenclaturas de negocio para poder construir informes de forma sencilla a gusto del usuario final.

Para poder liberar la posibilidad a los usuarios que creen sus propios informes es necesario construir una capa semántica que los ayude a identificar categorías y valores con nombres sencillos para el negocio.

A continuación algunas prácticas para construir la capa.