LaDataWeb

Blog comunitario de la suite de analítica de Microsoft de la mano de Power Platform y Azure Data Platform.  @ignacho_07

[ibarrau]

[Fabric] Intro a Real-Time Analytics

¿Alguna vez les pidieron que sus tableros muestren información en tiempo real? estoy muy seguro que así fue. En caso de que no les haya pasado, déjenme decirle que son unos afortunados.

El tema de real-time suele ocurrir seguido en el mundo de la analítica, pero... ¿es realmente necesario? la respuesta claramente es "depende". En este artículo damos el primer vistazo a una solución de real time pasando por los ítems de la suite que provee Microsoft Fabric y rompemos mitos contando cuando creemos que la solución amerita y cuando no debería.

Vamos a comenzar como nos gusta hacer en ladataweb, definiendo ¿qué es Fabric Real time analtics?

Una solución de extremo a extremo basado en un conjunto de ítems que dan un servicio que permite a los usuarios de tu organización extraer información y visualizar sus datos en movimiento. Con datos en movimiento, nos referimos a lo que sucede en el ahora. Una solución para escenarios en los que es necesario responder a eventos a medida que se producen, procesar datos que fluyen continuamente o analizar registros. Tanto si se trata de gigabytes como de petabytes, todos los datos de la organización que se mueve convergen en un Hub en Tiempo Real.

Los ítems que provee la suite de Fabric para real-time son:

Event Stream: permite incorporar eventos en tiempo real a Fabric, transformarlos y enrutarlos a varios destinos sin escribir ningún código. (el interlocutor)

Event House: proporcionan una solución para controlar y analizar grandes volúmenes de datos, especialmente en escenarios en los que se necesita análisis y exploración en tiempo real. Están diseñadas para controlar flujos de datos en tiempo real de forma eficaz (nuestro storage)

Activator: un motor de detección de eventos sin código y de baja latencia que desencadena automáticamente acciones cuando se detectan patrones o condiciones específicos en orígenes de datos. (trigger de alertas)

Real-Time Dashboards: Un panel es una colección de iconos, opcionalmente organizados en páginas, donde cada icono tiene una consulta subyacente y una representación visual. Las consultas se ejecutan al visualizar en tiempo real contra el event house.

¿Cuándo usar?

Los usuarios siempre van a estar encantados con la idea de tener información en tiempo real de lo que sea. El usuario elige el ya y ahora. Sin embargo, no siempre tiene sentido, escala y vale la pena la inversión el ejecutar un proyecto de real time. Estos son algunos ejemplos que espero los ayuden a afinar la necesidad.

La solución mágica

No existe una única forma de aplicar real-time. Si buscamos por internet podremos rápidamente darnos cuenta que hay distintos tipos de soluciones. Cito rápidamente 3 que aparecieron cuando busqué para darles de ejemplo

Solución con Azure: utiliza recursos de azure como interlocutor o almacenamiento de la solución, recurso Event Hub o Azure Stream Analytics.

Spart streaming frame: usa un frame propio de spark que esta adaptado para real time. Puede modificarse constantemente en el lakehouse ser leído.

Fabric real time: se nutre de los ítems de la suite para generar una solución que reciba, transforme y manda los datos a un dashboard.

No siempre usaremos todos los componentes en todos los escenarios, sino que dependiendo lo que necesitemos, nuestra solución se ajustaría. Nuestro ejemplo fue utilizado durante eventos de principios del 2026 para que los usuarios interactúen con un juego simple. En dicho desarrollo no usamos todos los elementos de Fabric y nos nutrimos de algunos de Azure. Veamos la arquitectura:

Durante el evento teníamos un juego estilo trivia deployado en un sitio web llamado "Desafío VAR". Cuando los usuarios terminaban de jugar, calculaba los puntajes y ejecutaba un backend (Azure Function) para enviar datos al Event Stream de Fabric para procesarlos. El EventStream podría transformar los datos y enviarlos a una base de datos KQL creada en el Event House. Desde allí podemos crear un Power Bi o conectar uno desde desktop estilo direct query. Este informe se mostraba en una pantalla reflejando los puntajes en tiempo real y las preferencias de respuestas. Vamos paso a paso.

1- Llamada al flujo

No voy a mostrar nuestro desarrollo web completo, simplemente mencionar que el back end de la web utilizar una librería de python de azure para event hubs que funciona con Fabric. Hoy event stream no tiene una API, sino que cuenta con SDKs disponibles para distintos lenguajes de programación.

2- Event Stream

Para crear uno basta con simplemente ponerle el nombre.

Lo primero con este componente será definir un origen, Get Data. Verán distintas opciones que les permite conectar a un origen para traer los eventos (Azure event hub, IoT, Kafka, CDC en bases de datos, etc), en nuestro caso definimos realizarlo más personalizado y seleccionamos la opción "Custom endpoint". Las opciones abren un wizard que los acompaña a configurar. Luego de crearlo podemos ver las formas y credenciales de interacción:

Como pueden apreciar, el custom endpoint nos permite conectarnos como si fuera un Event Hub, AMQP protocol o Kafka. También podemos elegir la forma de autenticación, en mi caso elegí SAS Key Authentication y ahí tengo las credenciales para mi backend que usaría el SDK de Event Hub.

NOTA: Si queres leer más del SDK de python podes verlo aquí: https://learn.microsoft.com/en-us/python/api/overview/azure/eventhub-readme?view=azure-python

NOTA: Si quieren entrar en más detalles de Custom Endpoint pueden seguir su lectura aquí: https://learn.microsoft.com/es-es/fabric/real-time-intelligence/event-streams/add-source-custom-app?pivots=basic-features&wt.mc_id=DP-MVP-5004778

Las cajitas del medio y salida nos van a permitir ver logs y el fluir de los datos en tiempo real. Event Stream también nos permite añadir operaciones.

3- Event House

Para el destino del Event Stream creamos un Event House en el área de trabajo. Al crearlo nos crea por defecto un KQL Database. Podemos usar esa u otra que creemos. También tiene compatibilidades para utilizar un Lakehouse. Fíjense como aparece la base por defecto al abrirlo.

Teniendo creada la Base, volvemos al Event Stream para conectarlo como salida del flujo. No hace falta que creemos una tabla o definamos un esquema. La tabla seguirá la estructura que formemos y enviemos desde el Event Stream.

Desde la base podremos ver un vistazo de los datos de tablas o crear consultas (KQL Queryset) tanto en KQL como en SQL (tiene sus limitaciones)

Como todo en Fabric esta interconectado, los datos almacenados en algún almacenamiento corresponden al onelake y podemos leerlos desde las herramientas de cómputo como Notebooks o PowerBi.

Aquí también podemos hacer shortcuts o crear vistas materializadas para conectarnos a una visión manipulada de lo que tiene una tabla como origen en tiempo real de nuestro informe.

NOTA: Una vista materializada es una consulta de agregación sobre una tabla de origen o sobre otra vista materializada. Representa una única instrucción summarize

4- Dashboard

Nosotros, como somos fanáticos de Power Bi, preferimos hacer un informe ahí y no en los Realtime Dashboards que provee para tener mayor flexibilidad. Sea creándolo desde la web en Fabric o desde Power Bi Desktop (recomiendo).

Desde la Base KQL

Desde Desktop:

La conexión se genera tipo direct query. Esto nos habla de una constancia y cache de actualización, pero no es suficiente para real-time porque nuestro informe quedará congelado a menos que manualmente un usuario presione F5. Para utilizarlo de panel de tiempo real, vamos a configurar el formato de la página del reporte de Power Bi. En la opción Page Refresh o Actualización de página.

Aquí solía estar la opción de generar una actualización cada X segundos. Ahora tenemos una opción más robusta, creamos una regla para no estar actualizando si o si cada vez. Configuramos que cada 4 segundos revise si el COUNT(PartitionId) ha cambiado. Si cambia, refresca las visuales. Esta opción de actualización es para las visualizaciones. De esa forma al cumplirse la regla, nuestras visuales se actualizan y dinámicamente tendremos cambios en los gráficos mostrados en un televisor. ¿Por qué cuatro segundos? simplemente es mi número favorito.

Este es uno de muchísimos ejemplos que podrían surgir sobre Real Time. La idea es que tengan el primer vistazo para conocer la suite y comenzar a tenerla en cuenta en los casos de negocio que le surjan. Siempre es bueno tener un baseline para considerar y luego se profundizará según lo que toque en el escenario.

[ibarrau]

[PowerBi] Efecto mejorar experiencia de usuario para explicar tarjeta

En nuestro blog hemos pasado por muchos métodos de documentación de reportes y modelos semánticos. Lo cierto es que no todos son iguales para las distintas audiencias. A veces con simples efectos bastará para darle al usuario la información que necesita.

En este artículo veremos un efecto que podemos introducir para dar rápidamente información al usuario con solo pasar el mouse por el lugar que desean.

Comienzo aclarando que si bien el título de este artículo dice que vamos a hacer un efecto sobre un tarjeta, en realidad, se puede hacer sobre cualquier visualización. Lo que si recomendamos es hacerlo sobre visualizaciones estáticas, es decir, aquellas que no proveen otra información adicional a lo que se ve sin interacción. Si la visualización provee más información posando el mouse o clickeando, entonces es dinámica. Esto hace a las tarjetas, kpis, y gauges como los candidatos más apropiados.

Seguramente les ha pasado que hay personas preguntando por la definición de un métrica o una tarjeta para enteder lo que hace o cual es el contexto en el cual opera. Para esos escenarios, este efecto podría fortalecer la experiencia del usuario.

Esto da un veloz vistazo a lo que necesitamos que el usuario preste atención. En un resumido texto podemos establecer la fórmula, el concepto, detalles de la construcción (ej, tipos de costos asociados, etc). Veamos como se hace.

Sabiendo que la tarjeta es estática procedemos a poner un objeto por encima, dado que poner el mouse encima de la tarjeta no suele dar información adicional dentro de Power Bi.

Colocamos nuestro botón exactamente encima de la tarjeta. Para la primera parte del efecto, lo volvemos transparente sin texto para el estado "por defecto":

Finalmente cambiamos al estado "on hover" y ponemos el mismo color de fill que la tarjeta posee adicionado un texto:

De ese modo generamos el efecto de tener información adicional al posar el mouse.

Puede ocurrir que el usuario esté acostumbrado a que una tarjeta no produce un efecto y perderse esa información. Aquí es donde entra nuestra creatividad. Podemos poner un tercer objeto que llame la atención. Este objeto estaría entre la capa del botón transparente y la tarjeta para llamar la atención del usuario.

Otra opción sencilla sería agregar un ícono informativo en el botón transparente que llame la atención al usuario para posarse por encima. Esto evitaría sumar visuales y podemos posicionarlo a nuestro gusto jugando con el formato de padding. Algo así:

Espero que el efecto les resulte atractivo y ayude a sus usuarios a comprender mejor los tableros.

[ibarrau]

[DAX] Intro a funciones UDF

Probablemente el lanzamiento más importante de DAX desde sus funciones OFFSET y WINDOWS, hace tiempo Microsoft lanzó la posibilidad de crear funciones de DAX.

Como buen y robusto lenguaje de programación o de consultas a datos, era sumamente necesario que esta posibilidad exista para mejorar los desarrollos de lógicas generales o puntuales de negocio.

Si bien hoy estan preliminares o preview, escribimos este artículo para ponernos al día porque su lanzamiento podría abrir puertas a mejores desarrollos de modelado.

Para comenzar vamos introducirnos en el concepto tal como nos gusta hacer en LaDataWeb.

Microsoft dice: Las funciones definidas por el usuario (UDF) de expresiones de análisis de datos (DAX) permiten empaquetar lógica DAX reutilizable y con parámetros en los modelos, lo que facilita la escritura, el mantenimiento y el uso compartido del código DAX. En lugar de repetir fórmulas entre medidas, columnas calculadas y objetos visuales, las UDF proporcionan flexibilidad de estilo de programación a los modelos semánticos.

Esta vez creo que esta bastante clara la definición que nos deja Microsoft. Podemos pensarla como métodos de programación, procedimientos o funciones de programación.

¿Por qué las usaríamos?

Reusar código. Tal como las variables nos ayudan a evitar computo en una medida. Las funciones podrían hacerlo en muchas medidas

La mayoría de los lenguajes tienen funciones. No podría quedarse atrás DAX si quiere avanzar como lenguaje. Pensemos que SQL M ya lo tenían.

Para evitar soluciones atadas con alambre. Se usaban calculation groups para adaptarlo pero no podías ponerle parámetros y no tenía la mejor performance

Antes de comenzar cabe aclarar que aún están en preview o versión preliminar. Entonces debemos activarlas desde el menú de opciones:

Las funciones pueden definir un valor de entrada que llamamos parámetro y deben establecen un valor de salida o retorno. El retorno puede ser un escalar o una tabla. La función se ejecuta en el contexto de evaluación original. ¿Qué quiere decir esto? Esto significa que son códigos que suceden dentro del lugar donde lo escribimos y no antes. Si llamamos una función en una medida, sucede en el mismo contexto que el código de la medida.

El código puede acceder al contexto de filas o filtro

El código no puede ser evaluado hasta que es ejecutado

Las funciones pueden llamar otras funciones

No permiten recursividad. No podemos llamarlas entre si de forma circular sino lineal.

Las podemos encontrar en la vista de relaciones como indica la siguiente imagen:

Veamos como se definen:

NombreFuncion = ( N o ningún parámetro ) => Resultado de la expresion

Entonces podríamos hacer algo simple como multiplicar dos nros

ValorXValor = (a , b) => a * b

Esa función simple la podríamos usar en una tradicional expresión para multiplicar fila por fila como precio * cantidad de facturas:

No olvidemos definir una descripción para facilitar su uso tanto para nosotros como para quien edite el modelo de datos.

Podemos visualizarlas de distintos lugares. Por supuesto, desde la vista de relaciones. Se suman dos lugares más. Podemos verlas desde la DAX query view:

Claro que el otro lugar es desde la poderosa TMDL View que todo lo ve, basta con arrastrar la función al canva:

En esta vista también se puede apreciar la descripción.

Demos un paso más y veamos el funcionamientos de los parámetros. Existen dos tipos de parámetros, los valores y las expresiones:

Valores

= (a : VAL ) => CALCULATE ( a, columna = "rojo")

VAL valor por defecto. Evaluados en el contexto donde llamamos a la función. Significa que el parámetro es calculado antes de ingresar a la función. Son como variables pre calculadas en una medida.

Expresiones

= (a : EXPR ) => CALCULATE ( a, columna = "rojo")

Evaluados dentro en la ejecución de la función. El parámetro que llega a la función es un código, es decir, es pasado como una expresión que se calcula en la función. Esto significa que el parámetro se calculará cada vez que la mencionamos en nuestra función.

Veamos el resultado de ambas funciones llamadas desde una medida simple que haga lo mismo para que comprendan la diferencia de ejecución de los parámetros.

Medida = Funcion ( [SalesAmount] , [SalesCost] )

Como pueden apreciar, la función de valor esta totalmente ignorando el pedido de filtrar por rojo dado que el parámetro ya tiene el valor evaluado y calculado. Por eso va restando Montos y Costos fila por fila. La función que usa la expresión como parámetro es lo contrario, intentará ejecutar el parámetro dentro del contexto del calculate y ejecutar el filtro de color = rojo. Por esta razón, en cada fila resta 116.013,39 - Costo fila por fila. Calculate pisa el contexto de filtros y asume ese valor para todos los colores.

Podemos utilizar ambos combinados en una sola función pero, a modo de buena práctica, recomiendo aclarar en el nombre del parámetro si es una expresión y sino asumir valor:

= (aExpr : EXPR, b : VAL ) =>

Retornos

Lo que la función devuelve también puede variar. Los ejemplos que vimos hasta ahora fueron para devolver un escalar, es decir, un número resultado. Sin embargo, una de las devoluciones más poderosas que podemos obtener es una tabla. Podríamos utilizarlas como filtros. Veamos un ejemplo. Tenemos una función que nos calcula las ventas para el TOP 10 de clientes que más compran.

Ahora bien. Puede que en el negocio se utilice mucho visualizar sobre la audiencia del top 10 de clientes que más compran pero de distintos resultados. Tal vez buscan también cuantos productos se llevan esos 10 clientes, cuantos gastos nos generan, cuanto margen dan, cuanto... Distintos cálculos pero siempre sobre los 10 clientes con mayores ventas. Esa tabla resultante que se filtra podría ser una función:

Fuimos un poco más allá pusimos un parámetro para definir sobre que universo de clientes queremos trabajar. Con esta función podríamos ejecutar cualquier medida contra el top X de clientes con más ventas y quedaría muy simple:

Esto nos abre una puerta a automatización de código que antes no teníamos. Ahora podemos replantearnos si el código que escribimos para reutilizar es una función exclusiva para este modelo o si es independiente de un modelo, es decir que podría funcionar en cualquier modelo. Por ejemplo, TopNCustomers, es una función exclusiva para ese modelo porque necesito una tabla Customer y medida SalesAmount para que funcione. A diferencia de ValorXValor, que podría funcionar en cualquier modelo.

En esta búsqueda reutilizar, la comunidad se está adelantando de la mano de SQLBI. Crearon un sitio donde podamos compartir bloques de código a modo de librería que pueden encontrar aquí:

https://daxlib.org/

Otro ejemplo simple que les comparto que utilizo mucho es una tradicional medida de semáforo para formato condicional. Si ustedes ya tienen los colores preferidos para formatos condicionales, entonces tomen este ejemplo. Veamos la función:

La función nos permite enviar por parámetro una expresión a resolverse y dos valores. Los valores se usarán para delimitar los colores del semáforo. Entonces pintar nuestra tabla nunca fue más simple, por ejemplo pintemos el margen de rentabilidad por 30% y 50%.

Color margin = Semaforo([Margin], 0.30, 0.50)

Miren que simple queda y podríamos ejecutar cualquier medida que tengamos valores de semáforo para pintar y sus delimitadores.

De forma más compleja para pintar la rentabilidad promedio de un producto según sus precentiles 25 y 75. Los percentiles agrandan la fórmula pero no perdamos el foco que con una función tenemos la medida y los límites super simple.

Luego ponemos el formato a la tabla y podríamos verla:

Esta función podría reutilizarse entre varios archivos de Power Bi. No necesariamente funciona con este modelo únicamente, sino que es un estándar. De eso se trata la página de SQLBI, de funciones que podamos reutilizar.

Como siempre decimos en LaDataWeb, la creatividad es su límite, pueden llevarlo al límite con sus requerimientos e ideas. Por supuesto, aquí esta el archivo de PowerBi en mi GitHub. Esperamos haberlos ayudado a desprender ideas.

[ibarrau]

[SimplePBI-Ops] Framework para trabajar Power Bi con repo y CICD

Hace tiempo que la comunidad busca por todos lados alternativas para que los proyectos de Power Bi tengan un buen control de versiones de sus cambios históricos y sea posible una estrategia de despliegue que soporte ambientes. La realidad es que la comunidad fue muy creativa y logró buenas alternativas con lo que había en su momento.

Sin embargo, hoy es el mejor tiempo para realizar estas prácticas. El lanzamiento de guardar Power Bi como proyecto y las posibilidades que nacieron con Fabric nos dieron las mejores puertas.

En este artículo, mostraremos como configurar una Github Action para despliegues automáticos de Power Bi sin necesidad de capacidad Fabric.

Nos alegra muchísimo poder escribir este artículo compartiendo una nueva herramienta de LaDataWeb que ya pueden encontrar en nuestro sitio: https://www.ladataweb.com.ar/tools.html

Comencemos alineando conceptos, tal como nos gusta hacer en La Data Web.

¿Qué es un Repositorio?

Un repositorio de código pueden pensarlo como un sistema de almacenamiento de archivos, similar a una carpeta que ven en su sistema operativo, con la principal diferencia que rastrea y gestiona todos los cambios, archivos e historial de desarrollo. Permite a los programadores guardar versiones, revertir cambios, colaborar simultáneamente y mantener un registro seguro. Esto significa que si cambiamos una medida y lo mandamos al repositorio, generamos una nueva version del archivo con la nueva medida y si queremos alguna vez ver como era el modelo sin esa medida, podemos ver la version antigua.

¿Qué es CICD?

Significa integración y despliegue continuo. Es una metodología (hoy catalogada en la disciplina DevOps) que automatiza las etapas de desarrollo, pruebas y despliegue de software, permitiendo entregas más rápidas y fiables. CI integra cambios (combinar cambios de equipo) y CD automatiza su envío a producción (un área de trabajo), eliminando procesos manuales y reduciendo errores humanos.

¿Para qué hacemos esto?

Podríamos decir que para trabajar en equipo sobre un mismo modelo (podemos mergear código), delimitar etapas de pruebas para validación de requerimientos, que se publiquen solo los reportes, etc.

Inicio

Para poder desarrollar esto podemos y pudimos en el tiempo aplicar distintas prácticas. Con lo que hoy tenemos hay dos conceptos que son innegables:

Desarrollos de reportes o modelos semánticos guardados como Proyecto. Power Bi Desktop tiene ahora "Guardar como Proyecto" que permite guardar el código y no un archivo binario. Esto permite guardar archivos de código que pueden ser combinables si muchos modifican al mismo tiempo. A su vez no guardan los datos, entonces son muy livianos para trabajar.

Separación de ambientes (Prod, Test, Dev) en áreas de trabajo. Las áreas son nuestros entornos de implementación y las branches de los repositorios tienen los entornos a deployar en cada área.

No podemos ignorar lo que las grandes nos invitan a realizar. Hoy Microsoft provee un enfoque orientado a Fabric. Bajo una licencia por capacidad somos capaces de realizar integraciones con repositorios git (Articulos Github o Azure DevOps) para el control de versiones. Luego nos invita a usar Deployment Pipelines para cambiar entre etapas. Esta es una buena alternativa para ítems de Fabric pero para SOLO PowerBi, me resulta incomoda por lo siguiente:

Require una capacidad de Fabric

Estamos obligados a usar Github o Azure DevOps

La dirección de Commits no es unidireccional, si se puede editar de atrás para adelante, corre riesgo la solución: Desktop → Branch Feature → Branch Prod ↔ Workpace

Los deployment pipelines requiren su cuidado y mantenimiento

Solución sugerida - Framework SimplePBI-Ops

Mi idea es remover esas barreras cuando trabajamos solo con Power Bi. El Framework SimplePBI-Ops permite:

Construir soluciones robustas compatibles con TMSL y TMDL

Trabajar en equipo sobre un mismo proyecto

No necesita capacidad, solo power bi pro

De fondo es un proyecto abierto con Python, podrían usarse tecnologías como gitlab, bitbucket, jenkings, etc.

La dirección del commit es uni direccional: Desktop → Branch Feature → Branch Prod → Workpace

Reduce las licencias pro para desarrolladores

La solución que voy a mostrar esta orientada a Github, pero si son curiosos todo esto apunta a un proyecto libre para llevarlo a otra plataforma.

Paso 0 - setear permisos para usar la API

Si no sabes de que hablo, podes ver éste artículo:

https://blog.ladataweb.com.ar/post/740398550344728576/seteo-powerbi-rest-api-por-primera-vez

Los permisos delegados requeridos son:

Item ReadWrite

Datasets ReadWrite

Reports ReadWrite

Workspaces Read

Paso 1 - Orden en PowerBi Service

Delimitar tus áreas de trabajo con un Sufijo que describa el entorno. Si nuestra área de trabajo es "Ventas". Creamos tres áreas, "Ventas_Dev", "Ventas_Test" y "Ventas_Prod". Para prod podríamos no tener el sufijo de forma que sea más amigable a los usuarios. Ejemplo "DeployedApps":

El sufijo puede ser el que quieran, si es " dev" recuerden que es espacio+dev.

Paso 2 - Orden en el repositorio

Ordenar tu repositorio bajo un esquema de carpetas alineado a tus Workspaces sin el sufijo:

La idea es tener una carpeta contenedora "Workspaces" con los nombres de área y lo que vamos a alinear con lo que hay en el servicio. Como indica la imagen la estructura es:

- Workspaces --- DeployedApps ------Roger Federer.Report ------Roger Federer.SemanticModel ------ .... --- Ventas ------AnalisisVentas.Report ------AnalisisVentas.SemanticModel ------ ....

Si mantenemos esta estructura, el framework de SimplePBI-Ops se encargaría de capturar cambios que ocurran dentro de workspaces en carpetas que terminen en "Report" o "SemanticModel" y luego deploarlos en una área de trabajo que lleve el nombre que pusimos, ej: Ventas, en el ambiente correcto (delimitado con el sufijo)

Paso 3 - Crear github action

Para configurarlo crearemos un archivo.yml para cada entorno que coincida con una branch del repositorio, es decir, archivos dev.yml, test.yml y main.yml (en caso que usen la rama por defecto para prod). Cuando creamos un archivo .yml en la siguiente ubicación, estamos creando la acción.

"root/.github/workflows/archivo.yml"

No hace falta que seamos expertos en este código, sino basta en entender las pocas líneas que pegaremos. El archivo tendrá un código bastante simple.

Comienza con "ON" delimitando la branch para detectar los cambios (puede ser dev, test, prod, main, master, etc) y la carpeta que contiene las áreas que arriba la delimitamos como "Workspaces".

Sigue con "JOBS" ejecutando un paso contra una ejecución sin servidor de linux llamando al proecto de LaDataWeb llamado SimplePBI-Ops con variables de entorno.

Paso 4 - Parámetros y secretos

Deploy_Env: es el sufijo de nuestro entorno. Por ejemplo yo tenía DeployedApps y DeployedApps_Dev en mi PowerBi Service. Cuando capture cambios de desarrollo (archivo dev.yml) en mi Branch "dev" voy a poner esto en "_Dev". Cuando este sobre el archivo prod.yml, voy a poner branch en main (porque el default es mi producción) y enviar el deploy_env vacío porque se llama "DeployedApps" sin sufijo.

Tenant_id: id de la organización en Azure tomado de la app registrada para service principal

App_id: id de cliente o app en Azure tomado de la app registrada para service principal.

Secret_key: valor del secreto creado en la app de azure registrada para service principal.

Estas variables son críticas no puede estar expuestas por seguridad. Dejamos el código con ese ${{ secrets.variable }} que dice ahí y nos dirigimos a la configuración de nuestro repositorio.

Una vez creadas el código las leerá de ahi y no podemos ver su valor de nuevo.

Paso 5 - Probar

Ya esta todo listo para usar. Si se modifica manualmente o con power bi desktop un archivo dentro de una carpeta .report o .semanticmodel. El flujo lo va a detectar y deployar el código de ese archivo. Pueden comprobarlo en Actions:

Al solo deployar código, no ocurre esto que pasaba antes que si mi PBIX estaba viejo, pisaba los datos actuales del servicio. Aquí solamente aparecen los cambios. No hay necesidad de ejecutar una actualización de datos a menos que ustedes específicamente lo requieran.

¿Qué esta ocurriendo en realidad?

Lo que en realidad ocurre es que al ejecutarse un push, se activa un trigger que captura cambios y los registra. Ese registro se envía a un python script que lee puntualmente que ítem debe deployar. Reúne la información necesaria (workspaces id, semantic models id, etc) para efectuar el deploy.

Esto podrían ejecutarlo desde cualquier lado. Si les interesa indagar más aún con el framework en otra tecnología o ejecutar otros pasos en medio, pueden contactarme o leer su código abierto en el repositorio que llaman en el yaml:

https://github.com/ladataweb/SimplePBI-Ops

Espero que esto los ayude a mejorar sus flujos de trabajo en equipo y deploys continuos.

[ibarrau]

[PowerBi] Descargar reporte o modelo semantico via API como proyecto TMDL

Guardar Power Bi Desktop como proyecto es la nueva tendencia y el futuro al que queremos llegar. No es una moda, sino una forma robusta de persistir el código de forma íntegra que nos permite utilizar mejores prácticas como versionado.

Sabemos como hacerlo desde power bi desktop, pero como hacemos si queremos obtenerlo desde Fabric o Power Bi Service. Tal vez aún tenemos muchos archivos pbix dando vueltas o inclusive lo perdimos al original. Puede que querramos iniciarnos convirtiendo muchos archivos en este estado, pero abrir uno por uno no es viable. Necesitamos automatizar este proceso.

En este artículo veremos como podemos descargar un report o modelo semántico desplegado en todos sus archivos de proyecto utilizando la Fabric/PowerBi Rest API y la librería SimplePBI de python.

Para poder comenzar con esta solución primero necesitamos conocer un poco la Fabric o Power Bi API y tener conocimientos básicos en Python. La solución consiste en delimitar un modelo semántico o reporte en una área de trabajo y ejecutar un sencillo script a una dirección de nuestro entorno local. De ésta forma si descargaramos un reporte y un modelo semántico de un informe de, digamos, Roger Federer, veríamos algo así en nuestro entorno:

SI nunca usaste la API y no sabes de lo que hablo, tenes dos formas de utilizarla, logueando con service principal o tus credenciales permitidas por un administrador. En estos dos artículos podes introducirte:

https://blog.ladataweb.com.ar/post/740398550344728576/seteo-powerbi-rest-api-por-primera-vez

https://blog.ladataweb.com.ar/post/805200234319937536/usa-powerbi-api-con-tus-credenciales-y-simplepbi

SimplePBI ha trabajado para que la experiencia sea super sencilla y funcione en casos que normalmente descargar archivo pbix no funcionaría (incremental refresh).

Veamos cuando simple sería nuestro código:

Iniciamos cargando los objetos de la librería, delimitando las variables de conexión del service principal y creamos los objetos de las categorías de API que vamos a utilizar.

El resto es super sencillo, solo nos resta llamar el método declarando un path local de descarga y una sola línea de código:

sem.save_semantic_model_definition_local("xxxxxx", "xxxxxx", path)

De la misma forma podemos llamar el método de reporte:

rep.save_report_definition_local("xxxxxx", "xxxxxx", path, report_connection=None)

La operación de reportes suele tardar un poco más que la de modelos. Los reportes están atados a la cantidad de páginas y visuales en tiempo de descarga porque genera más archivos.

Con reportes hay que tener presente un parámetro especial para delimitar si queremos que nuestro archivo pbir apunte al modelo semántico en Fabric (live connection) o si preferimos que lo busque en nombrereporte.SemanticModel. Por defecto el none asume conectarse al modelo semántico en el portal de Fabric. Si quisieramos que no haga live connection sino más bien que busque dentro de la carpeta su modelo, habría que agregar un parámetro:

rep.save_report_definition_local("xxxxxx", "xxxxxx", path, report_connection="Import")

Esta solución podría ayudarnos a sincronizar una área de trabajo completa. Podríamos listar los reportes o modelos semánticos de una área de trabajo. Iterar los elementos. Guardar todos los ítems en una carpeta. Idealmente sería una carpeta "Workspaces/[Nombre Area de trabajo]" dentro de un repositorio Git.

De esa forma podríamos versionar toda una área de trabajo muy rápidamente. De igual manera a los reportes

Corriendo esos dos bucles en menos de un minuto podría tener mi área de trabajo lista para versionar en un repo.

NOTA: al descargar una área completa, debemos tener precaución en los informes. Si tenemos mezcla de informes importados y live connection, entonces vamos a tener que ejecutar acciones más manuales para esos casos individuales que sean minoría.

Así es como podemos descargar reportes y modelos semánticos como si fueran guardados como proyecto desde Fabric o Power Bi con una línea utilizando la Fabric/PowerBi Rest API y la librería de python SimplePBI.

[ibarrau]

[PowerBi] Automatizar exportación de informe a PDF con Power Automate

Si hay algo que aman los usuarios es exportar. Exportar imágenes, excel, presentaciones, pdf, etc. En algunos casos podemos potenciar nuestras soluciones si la combinamos con otra que, en este caso, se dedica a automatizar.

En esta oportunidad, vamos a enfocarnos en como podemos automatizar la exportación de un report a PDF bajo reglas y filtros utilizando Power Automate.

Para quienes no conocen Power Automate, es una herramienta de Microsoft que ayuda a automatizar flujos. Similar a Make, N8N, Zappier y muchas más.

Pre requisito: Una capacidad dedicada. Exportar a PDF un informe automáticamente es una característica de capacidad dedicada.

En este caso, la utilizaremos para exportar a PDF un informe de Power Bi. El informe tiene una dimensión de empresas con transacciones en el tiempo, lo que el usuario deseaba era que automáticamente exporte un informe para cada empresa que pertenece a un grupo específico, en un periodo delimitado.

El requerimiento consiste en que el usuario pueda exportar un pdf para una empresa en un periodo. Las empresas deben pertenecer a un cierto grupo, en este caso "Propiedad = Si", sino no debe exportarlas. La exportación puede ser uno a uno o todas las empresas juntas. Para ello, usaremos la visualización de Power Bi sobre Power Automate.

La visual nos permite acceder a Power Automate dando en los tres puntos y "Edit". Los componentes que usaremos son gratuitos, por lo que una cuenta de EntraID u Office 365 podría utilizarlo.

Lo que vamos a construir es un flujo instantánea a partir de un Botón de Power Bi que se vería así:

Fíjense primero en el menú de filtros y visualizaciones de la derecha. A la visual le hemos puesto dos columnas, empresa y periodo que son las combinaciones que vamos a filtrar en el informe y en el panel de filtros nos aseguramos que solo funcione para las empresas con propiedad igual a Si.

El proceso es bastante simple. Delimitamos un bucle que recorra cada empresa. El apply to each recorrerá la lista de Empresas. Luego por cada una de ellas haremos un export to file que tiene la siguiente característica:

El area, el report, el formato y los filtros. En report level filter las cajas que dice "Power Bi data" tiene el texto acortado. Ahi la herramienta nos permite poner lo que pasamos en la visual. Entonces el primero es "Power Bi data Empresa" y el segundo es "Power Bi data Periodo". De esa forma exportamos a pdf el informe con dichas características. Un archivo PDF por empresa en el periodo delimitado.

Solo restaría definir que hacemos con este archivo. Podríamos guardarlos en sharepoint, one drive, mandar por teams o en este caso enviarlo por correo. La acción de Power Bi botón tiene algunos parametros adicionales que fortalecen la experiencia de usuario como lo es el "User email". La persona que da click a la visual sobre Power Bi. Entonces podríamos disparar los correos para dicho usuario:

Podemos usar información en el subject, body o nombre de archivo para que sea una mejor experiencia.

El resultado podría verse así:

Como habíamos mencionado, no todas las empresas son de propiedad = si. Por ello aunque las seleccionemos en ese filtro, no se creará el pdf al clicker el botón. Solo recorrerá las empresas seleccionadas que cumplan esa condición puesto que las otras no llegarán al flujo que creamos por el filtro en la visual de power automate. Los correos llegarían así:

La visual de power automate no es visible en un export. Entonces, para mejorar la experiencia de usuario podemos crear un bookmark/marcador que oculte la visual de power automate y ponga un botón exactamente igual sin función. Este bookmark normalmente no tendría forma de activarse, pero lo activaremos al hacer el export to file para que quede así:

La configuración del export está basada en IDs que podemos ver en las URL. Por ejemplo, al seleccionar un bookmark del menú en service nuestra URL sería la siguiente:

https://app.powerbi.com/groups/83f0b593-6d09-43c1-8786-1862ed67e38c/reports/fdf4a4eb-1621-40a4-9d8d-2a0c05a671dc/6c8cf0e4e904d1de471d?experience=power-bi&bookmarkGuid=59cb3699ae4d2d3c6260

En la misma encontramos en negrita el id de la página y del bookmark que podemos cargar en el item de power automate bajo su nombre.

Si quisieramos hacer más seguro esto y solo permitirlo a usuarios especificos, podríamos tener una página de exportación oculta y solo permitirle la navegación a usuarios específicos. Entonces el botón que vimos antes, en realidad es solo una navegación a otra página que podría verse así:

Para el botón que nos trae a esta página oculta podemos utilizar de acción de navegación de página una fx a partir de una medida que se vería así:

De ese modo, solo esos dos correos podrían ejecutar una dirección a la página PageExport. Esto puede seguir mejorando si ponemos un tooltip que le diga "usted no tiene permisos" o si generamos una redirección a otra página que le aclare que no tiene permisos para ejecutar la acción.

Y así podemos ir mejorando distintas formas de la experiencia de usuario que no vienen al caso de este posteo. Lo importante aquí es que tenemos un flujo automático para exportar a pdf y enviar por correo un informe de Power Bi para determinados y específicos filtros. Espero que les sirva.

[ibarrau]

Usa PowerBi API con tus credenciales y SimplePBI

Me pregunto cuantas veces las personas habrán querido probar algún script con la Power Bi Rest API. Algo simple y corto. Simplemente probar un request que podría llevar a otro. Ciertamente, dar los primeros pasos para utilizar la power bi rest api puede ser engañosa. Hay que configurar algunas cosas en Azure o hablar con departamento de IT para que lo haga.

SimplePBI nos ayuda a hacer más simple el uso de la API puesto que vuelve sencillos los requests de las operaciones, pero hasta ahora solo podíamos llegar a utilizarla con un service principal registrado en azure. Eso cambiará en este artículo.

SimplePBI es una librería sencilla que facilita el uso de la API REST de Power BI y la API REST de Fabric. Podríamos decir que es un wrapper que facilita escribir código de esas API. Para poder utilizarla y escribir scripts o automatizar procesos es necesario registrar una app en Azure y configurar algunas opciones. Sin embargo, muchas veces me encontré en situaciones que solo necesito obtener datos, validar opciones, correr un loop a partir de una respuesta, exportar un reporte, etc.

Para estos casos que no buscamos implementar un script totalmente productivo, sino comenzar a probar requests o ejecutar algo on demand hemos implementado una nueva forma de login.

Ahora podemos obtener un token que nos permita usar la API con solamente nuestras credenciales y aprobación de la organización. No necesitamos cambiar opciones ni registrar aplicaciones en Azure para probar requests y probar nuestras soluciones o hipótesis.

Veamos que simple que es:

Tryit es una nueva clase de token que abrirá un navegador con la web de login oficial de microsoft y dejará en pausa la consola. SimplePBI solicitará permisos sobre la organización para que sea efectiva la autenticación. Verán algo similar a esto:

Aquí detalla los requests que la librería puede usar de la rest api. SimplePBI tiene términos de servicio y privacidad que pueden leer en los hipervínculos del texto final. Para que otros usuarios además del administrador puedan usarlo, debemos checkear el "Consent on behalf of your organization" para consentir que los usuarios también puedan usar.

Puede que no vean ese cartel debido a que no tengan permisos sobre Entra ID en Azure. En dicho caso verían algo similar a esto:

Esto significa que necesitamos que un Administrador en Azure Entra ID en nuestra organización tiene que aprobar los permisos que SimplePBI-Login solicita para que podamos utilizar este tipo de acceso.

¿Qué sucede al aceptar y como permito a un usuario usarlo?

Damos permiso a que operaciones como "get reports" de la librería SimplePBI puedan ser utilizadas por usuarios específicos del Tenant/Organización. Esto sucede puesto que se crea una Aplicación Empresarial/Enterprise que podemos encontrar en Entra ID:

Dentro de SimplePBI-Login, podemos consentir permisos administrativos en caso de que no hayamos seleccionado el check cuando salió la primera pantalla desde "permisos".

Con eso tendremos la seguridad configurada como Admin de Azure.

Ya aceptado el acceso para que SimplePBI pueda loguear con credenciales en su organización, el navegador simplemente mostrará un mensaje similar a este:

Authentication completed. You can close this window now.

Nuestra consola reanudará para que sigamos escribiendo código como normalmente lo haríamos con la librería. Ejemplo obteniendo áreas de trabajo:

De esta forma ya tenemos el entorno listo. Cada vez que vayamos a probar algo no necesitamos configuraciones en el Tenant ni una App Registrada, basta con un token.Tryit() y loguear en el navegador.

A diferencia del botón TryIt en la documentación de Microsoft. Usando la librería estamos en un entorno donde escribimos código y probamos potenciales scripts y automatizaciones. El botón en la web solo serviría para ver si el request devuelve una cosa o la otra.

A modo de recordatorio dejo el enlace a la documentación de la librería.

[ibarrau]

[DAX] Herramienta para ver linaje de medidas

Ya existiendo Power BI hace 10 años, ha reportes y modelos semánticos en muchas instituciones que fueron creciendo de sobre manera. Los simples excels pasan a modelos estrellas y las medidas de una línea usan cada vez más medidas anidadas.

Si alguna vez tuviste que mantener un modelo así o te toca hoy revisar modelos que no hiciste, seguramente pensaste que era complejo pasar de una medida a la otra buscando que hace cada una.

En este artículo te muestro DAX Measures Lineager. Una web para apreciar de forma visual las relaciones y expresiones de medidas de modelos semánticos.

Comenzamos nuestro camino como nos gusta hacer aquí en La Data Web, con conceptos y definiciones. Veamos que es un linaje y que es la herramienta.

El linaje de una medida es el proceso de rastrear y visualizar el ciclo de vida completo de la medida, desde su origen hasta su destino final. En el proceso puede tener orígenes de tablas o medidas.

DAX Measures Lineager: es una página web desarrollada por nosotros para hacer más simple este camino. También, es una Power Bi External Tool que nos hace el camino fácil hacia el linaje.

Link aquí

¿Cómo cargo mis medidas manualmente?

La herramienta funciona cargando un archivo json o pegando del portapapeles. Lo que vamos a colocar en la herramienta es el resultado de una consulta DAX. En el apartado de ayuda nos vamos a encontrar con la siguiente consulta DAX:

La misma busca todas las dependencias que tiene un objeto "medida" y lo devuelve en formato JSON. So podemos guardarlo en un archivo JSON o seleccionar la fila y copiar (Ctrl+C).

En la web tenemos dos íconos, uno para subirlo y otro para pegar el texto:

En este caso yo por ejemplo pego el contenido:

Esto automáticamente nos cargará el diagrama. Iniciar con una columna de tablas que están pintadas de naranja las otras cajas son las medidas. Para movernos funciona igual que las herramientas de tableros "boards" que existen hoy. Con botón del medio nos movemos. Si clickeamos una medida, nos abre un menú que muestra su lógica pinta las medidas y tablas relacionadas:

Si hay muchos elementos no los encontramos, podemos buscar de dos formas:

Highlight: pinta con Azul las cajas cuyo texto van coincidiendo con el contenido:

Isolate: busca la medida que coincida con el texto todas las relacionadas, eliminando aquellas que no participen del linaje (ideal si es muy grande la cantidad de medidas)

Finalmente tenemos tres botones.

Ajustar la vista, el famoso fit to content para centralizar si nos alejamos mucho en el diagrama.

Descargar la vista actual filtrada a png

Ayuda que nos indica como usar la plataforma

Power Bi External Tool

Para automatizar el proceso y que sea mucho más simple para ustedes hemos creado una external tool. Pueden descargarla aquí. La external tool es un acceso directo que nos abre el navegador con un json de dependencias en el portapapeles. Por esta razón, cuando abramos el navegador y demos click al botón "Start" nos pedirá acceso al portal papeles.

Esto lo pide porque el json de respuesta de dependencias está en el portapapeles. Una vez en permitido el permiso, el navegador lo recordará y el proceso sería muy ágil:

El instalador puede que de una alerta de Windows SmartScreen pero dejenme decirles que pueden confiarlo puesto que solo distribuye 2 archivos en las carpetas de power bi para que aparezca el puntero de la external tool.

Eso es todo. Ojala que les sea útil para revisar estos modelos que tenemos que dar soporte y no los construimos o no recordamos sus linajes.

[ibarrau]

[PowerQuery] Capturar errores durante actualización

¿Quién no ha trabajado en modelos semánticos con orígenes de datos de mucha interacción manual? seguramente hay reportes en casi todas las empresas que tienen algún origen de excel u otra fuente que tiene mucha manipulación. Para estos casos, suele suceder que las actualizaciones tienen fallas muy frecuentes.

Cambian el nombre de una columna, la borran, ponen mal los datos, etc. Todo esto puede romper nuestras actualizaciones programadas. En este artículo, te muestro como evitar que la actualización se rompa y alertes en el reporte que hay un problema en los datos detallando cual es para que los usuarios que cargan los datos puedan tomar ownership en el asunto.

Comenzaremos el post destacando que esta estrategia esta enfocada en escenarios de tableros que tienen mucha manipulación manual y generan errores frecuentemente. Lo que vamos a ver a continuación, no sería necesario en un escenario ideal con datos que provienen de un data warehouse o lakehouse ya procesados y con controles que aseguran que los datos mantengan su formato, tipo y esquema.

El problema surge cuando trabajamos con orígenes manuales. Los usuarios que cargan los datos difícilmente sigan siempre las prácticas recomendadas. Esto afectará las actualizaciones.

La solución implica que las actualizaciones no fallen, sino más bien alerten en el reporte si hay un fallo y que sea posible ver los detalles. El resultado sería algo así:

Solución

Para comenzar veamos nuestro modelo semántico:

Una estrella sencilla y una tabla errores desconectadas. Para construir esto iniciemos ajustando nuestro Transform Data, el espacio de power query para que capture errores. Vamos a armar grupos. Primero vamos a definir a nuestras tablas manuales actuales limpias bajo el grupo de staging. Podemos poner prefijo "stg_". A partir de esa tabla crearemos dos tablas más que la llamen. Una bajo el grupo Dimensiones o Hechos (dependiendo como hayan modelado) y otra bajo errores. Nos quedaría algo así:

Si bien el hecho de Ventas y el Error ERR_Ventas comenzarán igual haciendo de su paso origen STG_Ventas, el segundo paso marcaría la diferencia.

El segundo paso de Ventas será seleccionar todas las columnas y "Quitar filas con errores". Nuestra tabla no fallará porque quitaremos los errores que hayan ocurrido en la limpieza o transformaciones.

El segundo paso de ERR_Ventas será el contrario. Seleccionamos todas las columnas y ponemos "Conservar filas con errores" para analizarlas.

Nuestro Hecho Ventas esta listo. Pero la de errores no. Para poder ajustar la tabla de filas con errores, vamos a utilizar una función personalizada de power query que les dejo a continuación.

La pueden copiar de mi GitHub. La función pivoteará todos los valores de las columnas para buscar los errores y expandirlos dando más información, así también prevendría que falle esa actualización. Para cargarla pueden obtener datos de una consulta en blanco y pegarla.

Gracias a esta función podemos simplemente llamarla y solo nos resolverá darnos una tabla que tenga el nombre de la columna que falla, el valor que esta fallando y mensajes adicionales para dar contexto de la falla.

Si vamos a realizarlo sobre muchas tablas, les sugiero que el último paso sea crear una columna personalizada con el nombre de la tabla. De esa forma podremos unirlas a todas, puesto que tienen el mismo formato, en una sola tabla de errores que se vería así:

Antes de terminar, vamos a dar click derecho en las tablas con prefijo STG y ERR para quitar su carga. "Enable load". Vamos a prevenir que se carguen en nuestro modelo porque confundiría a los usuarios. No es necesario que conozcan esos detalles. El nombre de las tablas saldrá en cursiva si todo se hizo correctamente.

NOTA: Al cargar puede que la combinación de tablas les pida definir el nivel de privacidad de los orígenes, recomiendo usar Organizacional para todas las tablas.

De esta forma tenemos nuestro modelo que captura errores y evita la falla de una actualización. Pero esto no termina aún, falta lo más importante. Lo importante es alertar al usuario al respecto puesto que no vamos a recibir un correo de una falla de carga de datos pero si pueden suceder errores. Para generar el efecto, elegí colocar un botón largo debajo del título y mostrarlo si la tabla errores tiene filas gracias a esta columna:

Luego en el formato de texto del botón le puse en el botón "Fx" para delimitar que use esta medida como texto.

Tan importante como alertar es mostrar porque falló. Esto lo lograremos creando una página oculta a la vista del usuario. La misma solo se accederá con este botón. Sin embargo, para mejorar la experiencia, solo debería ser posible el ingreso si el mensaje sale. Si no tenemos errores y hay un cuadrado blanco, no deberíamos poder tocar el botón e ir a la página de errores vacía. Esto lo conseguiremos con la siguiente medida:

Esta medida la usaremos en el apartado de Acción de nuestro botón. Usaremos la acción de navegación de página y de nuevo el botón "FX" para poner la medida. Nuestra página oculta se llama "Errores", entonces cuando la condición falle y existan errores la función de navegación no intentará ir a "" sino a "Errores". Así el usuario navegará a una página donde podemos poner una tabla que muestre los errores por Tabla:

Así rápidamente el usuario que tiene acceso a los excels puede ver fechas y montos que fallaron. Esos no son parte de ventas ni compras por los errores que menciona. Ahora el usuario puede ir al excel a buscar las fallas para corregirlas.

Eso sería todo. Ojala esto los ayude a los usuarios manuales a involucrarse más en la carga consiente de datos y fomentemos una mejor experiencia de usuario. Pueden encontrar el pbix de ejemplo en este link.

[ibarrau]

[PowerBi] Vertipaq Analyzer para optimizar modelos

Estamos viviendo una época donde hay reportes de power bi por todas partes. Su popularidad creció tanto que las instituciones rebalsan de informes.

Trabajar sobre un tablero nuevo con nuevo requerimiento puede ser muy ordenado cuando ya conocemos las mejores prácticas, pero todo aquello que no se construyó de manera ordenada hoy esta dando vueltas. Para estos modelos creados con menos delicadeza es que hoy escribimos este artículo.

En esta lectura podrán encontrar una herramienta antigua y popular llamada vertipaq analyzer. Conocida para entender del motor tabular de un modelo.

Para comenzar vamos a hacer como nos gusta aquí en LaDataWeb leyendo la definición pero en este caso no es de Microsoft sino nuestra.

Vertipaq Storage es el motor de almacenamiento de modelos tabulares de las plataformas de datos Microsoft que utiliza Power Bi y Analysis Services. Funciona en memoria con un almacenamiento columnar que le da gran performance.

Conociendo que hay ahí escondido en un modelo semántico de Power Bi podemos ver el concepto de la herramienta en cuestión: Vertipaq Analyzer es una herramienta útil para analizar la estructura de almacenamiento de Vertipaq de modelos tabulares de datos en Power Bi o Analysis Services.

Analizar tamaños y características de tablas y columnas es un paso importante para optimizar un modelo de datos. Junto con herramientas como el analizador de buenas prácticas de Tabular Editor y el analizador de columnas o medidas usadas de Measure Killer, Vertipaq Analyzer es la tercera pata de un trío que ayuda a optimizar modelos o encontrar donde está perdiendo mucho poder para performar bien.

Hoy por hoy la herramienta esta integrada en dos external tools, DAX Studio y Tabular Editor 3. Si disponemos una de ellas, podemos comenzar.

Métricas del analizador

Lo primero que haremos será abrir desde el menú de external tools a DAX Studio o Tabular Editor 3. En mi caso voy a mostrarlo en DAX Studio que es gratis. En Tabular Editor 3 esta visible en una pestaña cerca de los mensajes de output.

Luego de abrir DAX Studio en la pestaña avanzada veremos el botón “View Metrics” que desprende una ventana para iniciar el Vertipaq Analyzer

Vertipaq Analyzer no es más que una Matriz de información que podemos abrir y cerrar para conocer más detalles de nuestro modelo. Nos permite navegar analizando tablas, columnas, relaciones, particiones y ver el verdadero valor de tamaño del modelo semántico. Comencemos por el resumen que nos muestra el tamaño del modelo.

Este es el tamaño total que podría levantar en una capacidad dedicada una vez implementado.

Las particiones nos van a permitir ver con más detalles interesantes como el modo de conexión que usamos, las filas, el tamaño comprimido de datos del segmento.

En detalles más finos inclusive veríamos la temperatura que nos puede ayudar a entender en capacidades dedicadas respecto a que esta más reciente en memoria. Claro está que aquí veríamos las particiones que creamos si estuviéramos usando incremental refresh.

Las relaciones pueden darnos un vistazo que no siempre tenemos presente. Las relaciones también tienen un peso que puede hacer la diferencia.

Cada una tiene un peso y las más livianas que podemos crear son entre columnas de tipo entero. Esto puede ayudarnos a repensar el modo en que armamos nuestros claves o IDs para relacionar el modelo.

Para tablas y columnas tenemos mucha información. Tal vez las más influyentes correspondan a comprender el peso de su cardinalidad, total sizing y el % que representa una columna en la tabla o una tabla en la base de datos, puesto que podría ayudarnos a entender mejor donde se va el procesamiento o peso del modelo.

Columnas:

Tablas:

Veamos el concepto de las columnas para comprender mejor:

Cardinality: Cardinalidad del objeto (número de filas de una tabla o número de valores únicos de una columna)

Rows: Número de filas de una tabla, partición o segmento

Data Size: Bytes correspondientes a todos los datos comprimidos en segmentos y particiones. No incluye el diccionario ni las jerarquías de columnas.

Columns Hierarchies Size: Bytes de jerarquías generadas automáticamente para las columnas (utilizadas por MDX).

User Hierarchies Size: Bytes de jerarquías definidas por el usuario

Relationship Size: Bytes de las relaciones entre tablas

Columns Total Size: Bytes de todas las estructuras relacionadas con una columna (suma de Tamaño de Datos, Tamaño del Diccionario y Tamaño de Jerarquías de Columnas)

Dictionary Size: Bytes de las estructuras de diccionario

Table Size: Bytes de una tabla (suma del Tamaño Total de Columnas, Tamaño de Jerarquías de Usuario y Tamaño de Relaciones)

Table Size %: Relación entre el Tamaño Total de Columnas y el Tamaño de la Tabla

Database Size %: Relación entre el Tamaño de la Tabla y el Tamaño total de la base de datos (suma del Tamaño de Tabla de todas las tablas)

Segments #: Número de segmentos

Partitions #: Número de particiones

Columns #: Número de columnas

Encoding: Tipo de codificación de las columnas (HASH/VALOR); muestra "Many" cuando se trata de un grupo de columnas con codificaciones diferentes

RI Violations: Número de relaciones con violaciones de integridad referencial, asignadas a la tabla en el lado uno de la relación de tipo Muchos a Uno (M:1); dicha tabla tiene una fila adicional en blanco

Bid. Filters: Número de relaciones con propagación de filtro bidireccional

MMR: Número de relaciones de cardinalidad muchos a muchos

Con estos valores podríamos tener buenos detalles que nos ayuden para entender si las columnas tienen sus tipos de datos apropiados. Malas asignaciones de tipo de datos pueden dar malos resultados en cardinalidad, tamaños o relaciones. Podemos ver los tamaños reales no comprimidos en total size que podría ayudarnos a definir si realmente una columna es necesaria o no.

Espero que esto los ayude a analizar sus modelos para hallar y entender como es su almacenamiento. Entrar en análisis más fino para entender el peso de cada detalle. Si quieren aprender aún más detalles de esta herramienta recomiendo los videos de los creadores:

ttps://www.youtube.com/watch?v=p8M7TDiXfxU&list=PLU6II7MW-aiI5A2FjtlVx0yVm3AezOjYr

[ibarrau]

[Fabric] Org Apps - Nueva forma de agrupar y compartir

Hace tiempo Fabric ha implementado un componente para compartir ítems. No se si llamarlo la evolución de las PowerBi Apps o si es algo totalmente distinto. Si podríamos decir que tiene el mismo objetivo de entregar valor a los usuarios.

En este artículo, mostramos Org Apps, que son, como pueden crearlas, que licencias necesitamos, que diferencia tienen con las Power Bi Apps y mucho más.

Las Org Apps no son un concepto nuevo en Fabric, entonces... ¿Por qué aún no habíamos escrito al respecto? Lo cierto es que estábamos esperando que se liberen para licencia Power Bi Pro. Comenzaron disponibles solo para capacidad Fabric, pero hoy podemos disfrutarlas con cualquier licencia paga (Trials, Premium per user, Fabric, Pro).

Comencemos como nos gusta aquí en LaDataWeb y leamos la definición que Microsoft da a su componente:

Las aplicaciones del área de trabajo de Power BI han sido reconstruidas para Fabric como un nuevo tipo de elemento. Con las aplicaciones de organización como elementos, puede crear varias aplicaciones de organización por cada área de trabajo. Además, puede administrar las aplicaciones de la organización de la manera en que lo haría con cualquier otro tipo de elemento, desde la creación de una nueva aplicación de organización hasta la administración del acceso, para compartir la aplicación de la organización.

Mucha definición no nos expresa, pero el panorama esta visible. Son un elemento nuevo que podemos crear en una área de trabajo que sirve para compartir a usuarios elementos específicos. Como son un elemento, podemos crear muchos por áreas de trabajo. Los ítems de Fabric que podemos compartir en estas Apps son:

Informe de Power Bi e Informe paginados (Modelo semántico subyacente para un informe en la misma área de trabajo o área de trabajo independiente)

Notebook o Real-Time Dashboard

¿Qué diferencias tiene con Power Bi apps? (Aquí artículo si no las conoces)

Crear y configurar

Para crear una haremos los mismos pasos que cualquier otro ítem. En el menú de nuevo podremos verlas disponible.

NOTA: Si no la ven disponible puede que su administrador de Fabric haya quitado la posibilidad de crearlas en la configuración del tenant.

Esto nos solicitará un nombre. Escribimos un nombre. Lo primero será agregar contenido del área de trabajo dentro de la app para gestionarla.

Al igual que las Apps tradicionales de Power Bi, disponemos de un panel de navegación al cual le podemos crear secciones para agrupar elementos o crear enlaces enlaces:

Lo nuevo a incorporar es "Overview". Este menú crea una página de información general que muestra todo en la aplicación de la organización.

Así mismo podemos configurar el tema. Nos permite cambiar los colores de contorno, imagen/ícono de la app, menú de navegación si es los que abren secciones como árbol +/- o en un menú separado al lado. También nos permite elegir si queres que el menú este colapsado o visible al abrirla. Al terminar la edición podemos ver una Preview de como se vería la App.

En el menú de configuración se nos permite delimitar un nivel de aprobación (endorsement), es decir, añadir una etiqueta de promoción o certificación a la aplicación tal como tienen otros elementos como los modelos semánticos.

Antes de finalizar, guardamos la app. Ya creada, podemos compartirla tal como se realiza con cualquier otro ítem dentro de una área de trabajo. Con la diferencia que contiene otros ítems.

Podemos generar un link que permite acceso a cualquier usuario del tenant o podemos hacerlo usuario por usuario. También allí tenemos el menú de Manage Access para poder ver quienes tienen permisos.

Recordemos que es otro elemento del área de trabajo. Entonces vamos a encontrarlo como la siguiente imagen y también podemos compartirlo así:

En conclusión, llegó un cambio de juego muy importante para compartir nuestro contenido del portal de Fabric con los usuarios para brindar una buena experiencia. Pienso que lo más importante respecto de lo que conocíamos antes es que los ítems no sean una versión copia del original sino un puntero. Esto nos abre la puerta a un total flujo de CICD para trabajar con DevOps en el que luego de automatizar y deployar cambios los usuarios finales dispongan de la última versión de un reporte. A diferencia de las Power Bi Apps que nos obligaron a tocar manualmente el botón "Update/Actualizar app" para llevar los cambios de los elementos al usuario final.

[ibarrau]

MLflow - El Anillo Único de los proyectos de AI

Soy Melina Solovey, gamer de nacimiento, fanática de LoL e ingeniera en Sistemas de Información de la Universidad Tecnológica Nacional desde 2018. Desde hace 8 años recorro el apasionante mundo de los Datos & AI. He participado como mentora en la disciplina. Actualmente, me desempeño como Head of IA en Pi Data Strategy & Consulting. He desarrollado y liderado proyectos de Data Science y Big Data en R, Python y Spark utilizando plataformas como Azure, AWS, IBM o Databricks. 

Hace más de seis años, cuando recién comenzaba mi camino como Data Scientist, conocí MLflow. En ese entonces, la plataforma también estaba en sus primeros pasos. Y aunque era joven, me dio algo que necesitaba desesperadamente: orden. 

¿Qué es MLflow? 

MLflow es una plataforma open source que facilita el ciclo de vida completo de los modelos de machine learning y tiene APIs disponibles en Python, R, Java, REST, CLI, TypeScript. Es una herramienta que permite: 

Trackear experimentos: registrar parámetros, métricas, artefactos y versiones de código.

Versionar modelos: guardar y recuperar modelos entrenados de forma estructurada.

Gestionar entornos: reproducir experimentos con entornos consistentes.

Desplegar modelos: integrar con APIs, servidores o plataformas cloud.

¿Por qué fue un antes y un después? 

Cuando arrancás en ciencia de datos, es fácil perderse entre notebooks, datasets, métricas y modelos que se entrenan y se olvidan. Lo que MLflow me permitió fue: 

Tener trazabilidad de cada experimento.

Comparar resultados de forma clara y visual.

Colaborar con otros equipos sin perder contexto.

Escalar soluciones en plataformas como Azure, AWS o Databricks.

Desde ese momento, MLflow se convirtió en un norte que guio mi forma de trabajar. Lo apliqué en proyectos de regresión, sistemas de recomendación, clasificación de clientes, detección de anomalías y muchos otros desafíos. Hoy, mi equipo lo adopta como una buena práctica estándar, integrándolo en nuestros flujos de trabajo y utilizándolo en proyectos para clientes como herramienta clave para asegurar trazabilidad, reproducibilidad y calidad en cada entrega. 

MLflow en la era de la Gen AI 

Lo más interesante es que MLflow no se quedó en el pasado. Evolucionó. Hoy, también contempla proyectos de GenAI, integrando soporte para modelos de lenguaje, pipelines más complejos y nuevas formas de deployment. 

Para quienes trabajamos en IA, MLflow sigue estando al borde de la ola, adaptándose a las tecnologías emergentes y manteniendo su esencia: dar orden, trazabilidad y escalabilidad. 

¿Cómo empezar con MLflow? 

Si estás dando tus primeros pasos o queres incorporar buenas prácticas en tus proyectos de IA, MLflow es un excelente camino. Acá te dejo una guía rápida para arrancar usando python:

1. Instalación básica Podes instalar MLflow con pip:

pip install mlflow 

2. Tracking de experimentos  En tu script de entrenamiento, podes usar: 

import mlflow with mlflow.start.run(): mlflow.log_param("param_name", value)  mlflow.log_metric("accuracy", score)  mlflow.sklearn.log_model(model, "model") 

3. Interfaz web local Para visualizar tus experimentos (esto abre una interfaz en http://localhost:5000 donde podés explorar tus runs):

mlflow ui 

4. Integración con plataformas MLflow se integra fácilmente con Databricks, Fabric, AWS SageMaker y otras plataformas cloud.

5. Model Registry Si trabajas en equipo, el registro de modelos te permite versionar, aprobar y desplegar modelos de forma colaborativa.

¿Para qué perfiles es útil MLflow? 

MLflow es versátil y puede aportar valor a distintos roles dentro del mundo de los datos: 

Data Scientists: Para trackear experimentos, comparar modelos y mantener orden en el desarrollo. 

Machine Learning Engineers: Para versionar modelos, gestionar entornos y facilitar el deployment. 

AI Engineers: Para integrar modelos de inteligencia artificial, como LLMs, en aplicaciones, optimizar su rendimiento y asegurar su mantenimiento en producción. 

AI Leaders / Tech Leads: Para establecer buenas prácticas, escalar soluciones y facilitar la colaboración entre equipos. 

MLOps / DevOps: Para integrar MLflow en pipelines CI/CD y automatizar procesos de entrenamiento y despliegue. 

QA: Para validar la calidad de los modelos/aplicativos antes de producción, garantizar reproducibilidad y colaborar en la detección de inconsistencias entre entornos. 

Personas que están aprendiendo: Porque enseña desde el inicio cómo trabajar de forma profesional y reproducible. 

Cierre 

Este post es solo el comienzo. En próximas entregas voy a ir profundizando en temas y capacidades puntuales de la herramienta, compartiendo buenas prácticas, ejemplos reales y casos de uso que puedan servir tanto a quienes están empezando como a quienes lideran equipos de IA. 

Porque en este mundo de datos, tener orden y gestión no es opcional. Es esencial. 

Escrito por Melina Solovey

Links principales 

Página oficial: MLflow.org — la visión general, enlaces a docs, blog, comunidad.  

Documentación: MLflow Documentation — guía completa para la versión 3.x.  

API Reference: MLflow API Docs — Python, R, Java, REST, CLI.  

 Links de guías / “getting started” 

“Getting Started” / Introducción rápida: Getting Started with MLflow  

Quickstart de Tracking: MLflow Tracking Quickstart  

[ibarrau]

[PowerBi] Actualizá una sola tabla del modelo semántico

Quien no tuvo un modelo de datos que solo tenía una única tabla de actualización diaria mientras que el resto de las tablas solo cambiaba mensualmente. En estas situaciones suele ser una molestia actualizar diariamente sabiendo que solo una tabla cambia.

Con tantas actualizaciones de características alrededor de Power Bi bajo el ecosistema de Fabric, aparecieron nuevas formas para actualizar una sola partición de una tabla de un modelo semántico.

En este artículo vamos a ver formas de actualizar una sola tabla y partición de un conjunto de datos de Power Bi de distintas maneras.

Existen diversas maneras de actualizar una única tabla de un modelo de datos de Power Bi. Aquí vamos a ver tres de ellas, seguramente hay muchas más con ligeros detalles que cambian. Lo que no cambia es la licencia necesaria para lograrlo. Para poder acceder a una sola partición de una tabla y delimitar una actualización, necesitamos ver el modelo que está en el servicio. Esto es posible únicamente con una licencia por capacidad o premium por usuario. Por el lado de permisos, la cuenta que ejecute el proceso tiene que poder leer y escribir el conjunto de datos.

Lo primero sea la opción que sea, será recolectar el nombre de la partición que vamos a actualizar. Para conocer el nombre de la partición, podemos utilizar una de las bien conocidas external tools como DAX Studio o Tabular Editor. En este caso usé DAX Studio conectando al Workspace y seleccionando mi conjunto de datos. Podemos correr una consulta de información como se indica en esta imagen:

NOTA: Este es un modelo que tiene una sola partición por cada tabla, distinto sería en caso de tener configurado Incremental Refresh.

En este ejemplo, vamos a actualizar la tabla Product de un tradicional Adventure works cuya partición lleva el nombre de Product-4d66dae4-17df-45f6-85ae-6683c7644026.

Veamos las opciones para lograrlo.

1- Enhanced refresh con SimplePBI (Rest API)

Dentro de lo que es el universo de Rest API de microsoft, existe un request de actualización con esteroides. Éste no esta en la lista que se encuentra en Power Bi Rest API pero la librería SimplePBI lo incorporó para que podamos disponerlo. Veamos como ejecutar una actualización de esa tabla con código python. Pueden ejecutarla en cualquier parte que se permita python (local o nube).

El request solicita como mínimo el id de área de trabajo, id de conjunto de datos y los objetos. Las otras opciones son a definición nuestra, por ejemplo si queremos paralelismo o reintentos:

Entonces sencillamente podemos definir esos parámetros como indica la siguiente imagen:

Como pueden apreciar el script es muy simple, todo es bastante convencional salvo los parámetros de objetos y sus particiones.

NOTA: Si nunca usaron la Power Bi Rest API, les dejo éste artículo para comenzar.

Validamos que la ejecución fue exitosa y solo actualizó una tabla con una consulta al modelo desde DAX Studio

Fácilmente identificamos que actualizamos una sola partición.

Aquí más información de Enhanced refresh API: https://learn.microsoft.com/en-us/power-bi/connect-data/asynchronous-refresh

2- Data Pipelines

La segunda forma viene desde un recurso de Fabric. Dentro del canva de los Data Pipelines, existe una actividad llamada "Semantic model refresh" que nos permite correr actualizaciones de modelos semánticos con ciertas configuraciones adicionales.

Veamos la guía de la imágen

Luego de crear la actividad y ponerle nombre, tenemos su configuración en la pestaña de "Settings". Allí lo primero sea crear una conexión en el menú desplegable de "Connection" dirigida a Power Bi Datasets. Puede que parezca raro pero el servicio de Data Pipelines necesita que creemos una conexión al servicio de modelos semánticos de Power Bi. Si no crean la conexión, no podrán ver las tablas del modelo semántico para elegir una sola. Adicionalmente, puede ver que hay opciones similares a la api para configurar por interfaz. Una de ellas es a destacar puesto que suma mucho en una orquestación, me refiero a "Wait on completion". Ese check nos permite esperar a que termine antes de mostrar como completada la actividad.

Validamos la ejecución con DAX Studio nuevamente:

3- Fabric Semantic-links y TMSL

La tercera opción también será dentro de Fabric, esta vez utilizando notebooks. La librería semantic link tiene muchas flexibilidades para ejecutar acciones en Fabric. Entre ellas pude encontrar el llamado tradicional de ejecución de actualizaciones que existe desde Analysis Services con un formato json particular.

NOTA: Si no saben que es y nunca usaron semantic links, pueden comenzar a leerlo en éste artículo.

Para comenzar podemos identificar la partición construyendo una funcion simple con el mismo sempy y tmsl:

Conociendo la partición podemos definir el tradicional script TMSL como siempre lo hizo Analysis Services para llamar un método que lo ejecute:

Validamos con la siguiente imagen que corrió correctamente:

De esa forma completamos la tercera manera de correr una actualización de una sola tabla.

Espero que este artículo les resulte útil para actualizar conjuntos que lleven distintos tiempos de actualizaciones por tabla o incluso si hay grandes tablas pesadas y necesitamos actualizar algunas puntuales por chequeos.

[ibarrau]

[Fabric] Entornos y librerías de código para tus notebooks

Desde sus inicios, Fabric, ha contado con capacidades varias para su código. Entre ellas, la instalación o delimitación de librerías o paquetes personalizados. Podían configurarse desde notebooks o por código. Sin embargo, todo eso fue cambiando hasta llegar a la versión definitiva que conocemos hoy.

En este artículo hablaremos de entornos o environments para conocer como trabajar en notebooks con librerías propias y que otras configuraciones contiene.

Comencemos como nos gusta hacer en LaDataWeb. Veamos la definición de libro, es decir, la que Microsoft dice de su componente:

"El entorno de Microsoft Fabric es un elemento consolidado para toda la configuración de hardware y software. En un entorno puede seleccionar tiempos de ejecución de Spark diferentes, configurar los recursos de proceso, instalar bibliotecas desde repositorios públicos o directorios locales, etc."

Dicho de otro modo, nos permite crear un entorno que combina librerías, archivos y configuraciones de clusters de spark para reutilizarlo en los notebooks de un área de trabajo.

¿Por qué haríamos esto? tal vez necesitamos compartir un archivo en el equipo de desarrollo de librerías o cadenas de código. Puede que conozcamos una librería que resuelve nuestro problema y no esta por defecto. Podríamos necesitar modificar los cómputos de spark para corridas especificas. Éstas y muchas más podrían ser las razones que nos lleven a crear un entorno.

Crear entorno

Podemos ir al hub de creación donde salen todos los items y buscar "Environments".

Luego de seleccionarlo basta con poner un nombre.

En mi caso voy a agregar una librería de python que existe en PyPi y necesito para correr mi código. Esto creará un ítem nuevo en nuestra área de trabajo del tipo entorno. Al abrirlo nos encontramos con lo siguiente:

Aquí podemos identificar fácilmente lo que nos mencionaba la definición:

Librerías: Aquí podremos ver el listado de librerías que contiene Fabric para cada lenguaje detrás de spark, como lo es java (scala), python o R, como así también agregar librerías provenientes de fuentes conocidas como PyPi o propias importando archivos como .whl de paquetes de python.

Cómputos spark: en este apartado podremos habilitar un motor de ejecución nativa. Agregar propiedades de spark manualmente con UI. Configurar el pool de spark y detalles de cambios como core, memory, executor core, executor memory y executor instances. Cabe aclarar que la libertad de configuración para el cómputo la delimita el admin del área de trabajo, admin de la capacidad o admin del tenant. Dependerá que permisos fueron delegados.

Recursos: facilita la capacidad de administrar recursos pequeños durante la fase de desarrollo. Los recursos del entorno de Fabric proporcionan un sistema de archivos que le permite administrar los archivos y las carpetas para compartir. Podríamos dejar un .whl para que sea de acceso y descarga en caso de que otro usuario quiera usarlo en otro entorno.

Nosotros nos enfocaremos en cargar una librería nueva. Entonces daremos click en "Add from PyPI". En la pantalla saldrá un menú desplegable. No se asusten si no ven la librería. Escriban su nombre y si es detectada verán que automáticamente se completa la última versión.

En caso que dejen el proceso a la mitad y tengan que cortar, existe el botón "guardar". Sin embargo, para que el cambio sea efectivo y pueda comenzar a utilizarlas, hay que "publicar". Este proceso toma tiempo. En mi caso, tomó un poco menos de 10 minutos en un F2 para solo esa librería. Quedará una notificación corriendo así:

Cuando el proceso termine, podrán ir a su notebook. Elegir el tipo de notebook en la modalidad de spark que usen, en mi caso pyspark. Al lado verán el botón para seleccionar su entorno. Esto bastaría para que funcione:

Consideraciones

Los entornos son un ítem de Fabric más del área de trabajo. Por lo tanto, se pueden compartir igual que todos los demás. Bajo permisos de lectura, re compartir y escritura. La lectura permite ver la configuración y utilizar el entorno. Re compartir lo dicen las palabras. Escritura permitirá editar la configuración además de usarlo.

Adicionalmente a notebook, los entornos puede ser delimitado para Spark Jobs.

Los entornos pueden configurarse para ser elegidos por defecto en los notebooks o spark jobs del área de trabajo. Basta con ir a las configuraciones del área de trabajo en el aparatado de ingeniería de datos / configuración de spark y seleccionar el entorno por defecto.

Los entornos funcionan para backgrounds de spark. Esto significa que un notebook de python, al día 30 de julio del 2025 no puede utilizar uno de estos entornos.

[ibarrau]

[Fabric] Un agente de IA para hablar de tus datos

Bien sabemos que una buena estrategia para IA esta acompañada previamente de una buena estrategia con tus datos. En una actualidad que revienta de IA vamos a cruzar los mundos con el de datos.

En este artículo aprenderemos a construir un agente, asistente, chat, bot o como quieran decirle para que responderá preguntas basadas en nuestros datos almacenados en Fabric lakehouse, warehouse o semantic models usando Fabric Data Agents.

Antes de iniciarnos en la construcción o proceso, necesitamos comprender los requerimientos previos para poder lograrlo dado que son varios. Les dejo los pre requisitos:

Prerrequisitos

Un recurso de capacidad de Fabric de pago F2 o superior

La configuración del inquilino (tenant settings) de Fabric Data Agents está habilitada.

El switch de Copilot está habilitado en el tenant.

El procesamiento entre ubicaciones geográficas para IA está habilitado (en caso de regiones diferentes entre power bi, capacidades, etc)

El almacenamiento entre ubicaciones geográficas para IA está habilitado (en caso de regiones diferentes entre power bi, capacidades, etc)

Al menos uno de estos: un warehouse, lakehouse, uno o más modelos semánticos de Power BI o una base de datos KQL con datos.

Switch de modelos semánticos de Power BI a través de tenant settings de puntos de conexión XMLA está habilitado para orígenes de datos del modelo semántico de Power BI.

Conceptos

Tal como nos gusta hacer en LaDataWeb comenzaremos definiendo que son los Fabric Data Agents según Microsoft:

Es una característica que le permite crear sus propios sistemas de preguntas y respuestas conversacionales mediante inteligencia artificial generativa. Un agente de datos de Fabric hace que la información de datos sea más accesible y procesable para todos los usuarios de su organización. Con un agente de datos de Fabric, el equipo puede tener conversaciones, con preguntas en inglés sin formato, sobre los datos almacenados en Fabric OneLake y, a continuación, recibir respuestas pertinentes.

Dicho de otro modo es un nuevo ítem, recurso o componente que podemos crear en Fabric que tiene un motor de IA generativa con contexto a datos almacenados en Fabric para responder o conversar frente al usuario. El recurso se presenta en modo de chat.

Ahora, ¿Cómo se diferencia esto de Fabric Copilot? Si bien ambos agentes y copilotos de Fabric usan IA generativa para procesar y razonar los datos, los agentes son altamente configurables. Pueden proporcionar instrucciones y ejemplos personalizados para adaptar su comportamiento a escenarios específicos. Los copilotos, están preconfigurados y estan diseñados para ayudar con tareas dentro de Microsoft Fabric.

Creando nuestro primer agente

Lo primero que haremos será abrir un workspace con capacidad de Fabric y crear un nuevo ítem. Allí encontraremos los agentes de datos:

Solo nos pedirá un nombre para crearlo:

Para poder generar un agente que responda asertivamente, no bastará con apuntar a los lugares que tiene que leer, sino que tendremos que trabajar en un proceso de tres pasos. Veamos la siguiente imágen para guiarnos:

El proceso se realiza de la siguiente manera:

Seleccionar el origen de datos y las tablas que verá nuestra IA según nuestro almacenamiento.

Brindarle instrucciones que pensamos que debería tener presente nuestro agente basados en nuestra experiencia de la audiencia.

Brindar ejemplos de preguntas y respuestas basadas en consultas a datos. Mostrar que texto responde a que código.

Para ver esta nueva característica vamos a construir dos agentes. Por un lado uno que responda a partir de un modelo semántico y por otro lado respondiendo a partir de un lakehouse.

Agente contra modelo semántico

En este caso tengo un tradicional modelo de ventas de adventure works donde voy a involucrar tablas de ventas, productos, categorias, tiendas, clientes y glosario de medidas (métricas y descripciones). Si bien en la definición del producto aclara que esta solo en inglés, las pruebas las vengo haciendo en castellano y las respuestas son aceptables.

Veamos un ejemplo de instrucciones que le di al modelo

Aquí expuse tres tipos de instrucciones. Por un lado, explicarle a que tabla nos referimos cuando hablamos de X palabra. Por otro lado, explicarle que columna o medida buscar cuando estamos hablando venta, costo, etc. Finalmente, material adicional de como debería interactuar como por ejemplo que use la tablafecha cuando necesitamos hablar del tiempo o que puede leer el glosario para definir una medida.

Éstas no son las únicas formas. Hay muchas más. Todo lo que pensemos que aporte a explicar la respuesta que debería buscar a partir de como lo usaría un usuario aporta. Por ejemplo, si sabemos que suele pedirse un determinado análisis como combinación de productos en ventas o comparaciones contra otros periodos. Se podría tranquilamente aclarar como tiene que buscarlo el modelo.

NOTA: Al mes de agosto 2025 los agentes con modelo semántico no permiten configurar ejemplos de consultas DAX. Bastaría con esa configuración

Veamoslo en acción escribiendo "Hola. Podrías decirme cuales son las 2 tiendas que más vendieron en el año 2007"

Fíjense que la respuesta es texto y tiene un pequeño expandir para entender como llega al resultado. Allí podremos chequear la consulta ejecutada contra el origen:

Si validamos contra un reporte veremos que los valores coinciden:

Veamos algo más complejo. Vamos a preguntar "Cuales son los clientes que compraron el último día cargado en la base y que productos se vendieron?"

Como vemos la respuesta es más compleja pero nos muestra todos los clientes que compraron y los dos productos más vendidos.

Recordemos que es crucial tener una buena capa semántica para que el modelo encuentre mejores resultados a las consultas de los usuarios. A mejor capa semántica, menor será el bloque de instrucciones.

Agente contra lakehouse o warehouse

En este ejemplo vamos a asumir que ya seleccionamos las tablas. A diferencia del agente anterior, aquí podemos separar las instrucciones en dos, para la IA y para los orígenes de datos. Las de IA son generales del agente y se envían en cada consulta. Podes usarlas para explicarle al agente cómo abordar una pregunta, que orígenes usar según las preguntas o que términos conceptuales de negocio conocer. Las de orígenes de datos solo se ejecutan cuando el data source es usado para responder. Aquí se puede agregar notas de tablas, columnas, relaciones, esquemas o metadatos. Ejemplo de instrucciones de IA:

Cuando las preguntas sean sobre ladrillos, legos, colores, temas o sets, debes usar la tabla Lego_Sets para responder.

Cuando la pregunta sea sobre música, canciones, artistas, baile, velocidad, energía o popularidad, usa la tabla Spotify_Tracks.

Ejemplo de instrucciones de origen de datos:

El tema, tipo o categoría de un lego normalmente debe responderse con theme_name.

Si el usuario habla sobre el tamaño de un set de lego, se mide con piece_count. Cuantas más piezas tenga, más grande es.

Cuando el usuario hable sobre canciones, se está refiriendo a tracks.

Las tracks se consideran bailables cuando su valor en danceability es mayor a 0.5.

NOTA: esta categoría no esta disponible para semantic models sino que se configurarían todas las instrucciones en la IA

Culminado eso podemos enfocarnos en como se hacen las consultas SQL de ejemplo.

Una vez configurado veamos preguntas de ejemplo:

Presentación

Una vez finalizado el agente, damos en publicar para que esté disponible. Hay distintas formas de presentarlos a los usuarios finales.

La más simple sería compartir el recurso. No olvidemos que el data agent no es distinto a un notebook o reporte de power bi. Podemos darle compartir uno a uno o pueden usarlo usuarios participantes del área de trabajo.

Si queremos integrarlo en otro lugar, hoy Copilot Studio ha liberado nuevas formas de posicionar dichos agentes. Podemos incorporarlos en Azure AI Foundry, Teams, etc. Pueden leer más al respecto aquí: https://learn.microsoft.com/en-us/fabric/data-science/data-agent-microsoft-copilot-studio

Finalmente, para usuarios más avanzados podemos construir el acceso por código. Fabric data agents tiene una SDK en python, lo que permitiría llevarlo a donde querramos siempre y cuando conozcamos de código: https://learn.microsoft.com/en-us/fabric/data-science/fabric-data-agent-sdk

Limitaciones

Fabric Data Agent no admite datos no estructurados (.pdf, .docxo .txt). No se puede usar el agente de datos de Fabric para acceder a recursos de datos no estructurados. Estos recursos incluyen archivos .pdf, .docx o .txt, por ejemplo.

El agente de datos de Fabric no admite actualmente idiomas que no son de inglés. Para obtener un rendimiento óptimo, proporcione preguntas, instrucciones y consultas de ejemplo en inglés.

No se puede cambiar el LLM que usa el agente de datos de Fabric.

Eso sería todo, espero que no haya sido muy extenso y hayan podido conocer la potencia que nos brindan los Fabric Data Agents como gran alternativa para llegar a información a usuarios mediante lenguaje natural. Como siempre, les dejo en mi Github el material de las instrucciones y consultas creadas para estos conjuntos de datos gratuitos del ejemplo de lakehouse que son más completas. Espero que les guste.

[ibarrau]

Detrás de 200 historias de datos

No puedo creer que ya hayamos escrito 200 artículos. Han pasado casi 6-7 años desde el inicio de LaDataWeb que comenzó de una forma y se fue transformando año tras año.

Me gustaría hacer de este artículo una charla con la audiencia sin hablar de tecnología, sino de compartir a corazón abierto la historia de éste proyecto.

Si querés conocer un poco más como nació este proyecto, web, blog, herramientas y más. Te invito a leer este artículo donde expongo algunas intimidades de LaDataWeb.

Una vez me dijeron que es más difícil generar cercanía con un blog que con un canal de YouTube porque te ven y conocen. Conocen el rostro detrás del contenido. Pues he aquí el rostro detrás de LaDataWeb:

Mi nombre es Ignacio Barrau pero mis amigos me llaman "Nacho". Soy de Argentina, de la provincia de Jujuy.

Si bien muchas personas pueden no sentirse tan cercanos a un blog que a un canal, yo si siento cercanas a las personas que me leen. Suelo mirar como interactúan o de donde me visitan. Presto atención a quienes escriben o se suscriben :)

Espero que el artículo sea interesante y no los aburra con tanto texto.

Inicios

Recuerdo que en el año 2018 veía la galería de historias de datos en el foro de la comunidad de Power Bi y pensaba que sería lindo congregar historias así en un sitio. A modo de juego nació la primera versión de LaDataWeb que solo contenía informes de datos abiertos para compartir información de interés. Recién un año más tarde comenzaría lo que hoy conocemos como el "blog". Recuerdo que fue un tiempo de mucha investigación para poder elegir las plataformas y tecnologías que darían vida a este proyecto. La clave fue priorizar mis requerimientos para elegir la que más los cumpliera. De UI rústica pero estable y animada llegaba esta pantalla:

Anécdota: la primera versión se llamaba solo "La Data" como haciendo referencia a algo grande en informal modo de comunicarse. Como decír "no tengo una computadora, sino que tengo LA computadora". Estaba en dominio .tk por gratuito y se cambio al movernos a com.ar porque resulta que existe un diario con el nombre LaData que nos impidió usar el nombre. Sus primeras versiones de reportes de power bi super límitadas visualmente siguen allí.

En segundo lugar llegó el blog. Me gustaría comenzar aclarando que tal como le ocurre a muchas personas que tienen miedo a la exposición de contenido, yo también tenía inseguridades. En abril de 2019 comencé escribiendo con timidez micro artículos con breves tips que ayudaban a solventar dudas puntuales que solían aparecer en el equipo y en la comunidad (foro oficial de power bi). Aún teniendo años de experiencia estaba con un poco de temor. No fue hasta escuchar una charla de Gustavo Arjones en el Jujuy Big Data Summit que empujó a la audiencia explicando que aunque haya muchas personas que sepan más que yo, hay muchas más que no conocen lo que vos sabés y podrían entenderlo mejor con tus palabras. Allí cambie y el blog comenzó a dar artículos técnicos explayando más y más su contenido. Así mismo se reafirmo con el "explicar con mis palabras" que en internet hay mucho, pero mucho en inglés. Aún existiendo el auto traductor quise que el contenido original esté en español y que este lenguaje informal castellano latino sea el protagonista del contenido para que mis palabras sean más familiares en este continente.

Recuerdo: cuando iba a la facultad solía encontrar lógicas y puntos de vista distintos para explicar temas que nos traían los profesores. Mis compañeros decían que tenía regla para todo. Cuando quise comenzar esto, también remonto a compañeros diciendo "estas loco, escribir tan seguido es mucho laburo, ni vas a durar". Otra prueba de que si te gusta lo que haces, aférrate porque hay mucho para florecer.

El blog trajo el primer ícono del espacio:

Con un hexágono, cuando aún no estaba de moda porque después hasta guyinacube lo usaba, me embarqué en este camino.

Inspiración: La inspiración llegaba de clientes y compañeros con necesidad de aprender algunos procederes y teoría de la plataforma que les resultaba complejo en documentación o faltos de ejemplos. Las preguntas eran tan frecuentes que me llevaban a pensar que no había una explicación clara en la web. Para cuando no habían dudas de ese estilo, bastaba con ir a natación y a los 20 minutos de estar en el agua me llegaban ideas de tips visuales o de transformaciones de datos que no habían sido realizados. A veces los lanzaba antes que sqlbi o guyinacube y otras veces los descartaba porque ya se repetían mucho.

Este diseño acompañó mucho tiempo, en temporada 2022/2023 nos enfocaríamos en afinar una interfaz web más limpia y profesional con un nuevo logo. El logo acompañando al personaje pasaría de hexágono a Iglú y la web sería más limpia y sencilla.

El iglú ayudaría a fomentar animaciones más familiares mostrando la casa del personaje y prestándose para hacer imágenes animadas divertidas.

Spoiler Alert: la imagen de fondo del blog de hoy esta transformando al iglú en algo más cercano a la tierra donde nací.

Si algo entrega caricias al corazón, fue encontrar links a artículos por distintas redes o poder apreciar que los accesos a los artículos vengan de otros links referenciados que son solamente búsquedas de Google. Tal como hace power bi weekly en twitter con el blog. Cuando ves que una persona aprende de un contenido o lo usa de base para incluso mejorar la propuesta que entregas, da sentido al esfuerzo que haces con tanta dedicación.

Anécdota: en un tiempo tenía miedo que mi blog fuera algo que leyera la gente y lleve un artículo al Reddit oficial de Power Bi sobre como leer código power query en un repositorio github para tener un versionado desde allí. Era año 2019 y no había encontrado la forma de que service permita el refresh. Aún así lo publiqué para hacer conocer el approach y mostrar la importancia de versionado que necesitabamos en esa época. Seis años más tarde, Power Bi Park tomaría ese artículo y resolvería el problema mostrando como lograrlo en su canal de youtube. El alcance de la comunidad no tiene límites ♥. Podes comprobarlo en los enlaces: - Artículo: https://www.reddit.com/r/PowerBI/comments/ckdk9v/powerquery_call_custom_functions_file_from_github/ - Video (minuto 3:07 muestra): https://www.youtube.com/watch?v=GXFxiEVAmfI

Participación de audiencia

Cuando comencé pensaba que poniendo disqus para comentar era seguridad que me llenarían de comentarios, pero no fue así. Pasó un largo tiempo. Recuerdo cuando llegó el primer comentario a un artículo estaba emocionadísimo de saber que le había llegado a alguien sin que yo se lo hubiera enviado. Pensaba que dijera lo que dijera no me bajaba la alegría. Desde allí, siempre leí con cuidado y respeto y respondí cada comentario que llegó.

En ese tiempo escribía un artículo por semana. Era muy desafiante, lo que me llevó a abrir el espacio y generar comunidad. Fue entonces que una navidad libere un espacio para que gente pudiera compartir. Fue gratificante ver tantos compañeros de trabajo y ex compañeros que se sumaran a LaDataWeb para contribuir sus experiencias en manejo viual de Power Bi, azure data platform, ingeniería de datos, seguridad o inclusive powershell. Era una caricia para mi que otras personas quisieran escribir. Sin embargo, despues de que se normalizara la vida pos pandemia, durante 2023, las personas dejaron de participar y me vi obligado a quitar ese espacio público tras 1 año sin solicitudes de publicación.

Anécdota: a modo de entregar de forma amigable y con cariño comunicarme de forma cercana los anuncios a los lectores nace el ice climber. Aclaro que fui inspirado por Data Goblins que hace entrega con dedicación de sus imágenes. El personaje ayudó en styckers, anuncio de novedades, lanzamientos, newsletter y demás que nos acompaña hoy. Basado en el juego ice climbers de nes (favorito de la consola) y reconstruido en pixel art con distintos tamaño y sin capucha por derechos de autor.

Herramientas

En medio de este proceso me enamoré de compartir conocimiento, de la entrega a la comunidad. Participar de eventos gratuitos, dar charlas, y mantener el foco de artículos en español. Así nacieron dos proyectos, una External tool de calidad de datos «DataQualityReport» y «SimplePBI» una librería de Python como wrapper que permitiera usar con sencillez la Power Bi Rest API. Nunca pensé que la librería se usaría tanto, si bien es sabido que pypi stats tienen mucho robot y números elevados, los valores sorprenden. Inclusive, hoy motivan a seguir armando requests mezclados que no existen directamente en la API y transcender poco a poco a Fabric.

No todo llega a producción: también he tenido desiluciones con proyectos que no vieron la luz del día como un overview de todo lo que hay en el tenant y métricas de uso automáticas porque cuando estaba listos, microsoft anunció el admin workspace llegando primero a lo que tenía listo con documentación y automatización para instalarlo en cualquier tenant que lo requiriera

Conocer la audiencia - Comunidad

En septiembre 2021 (Aniversario) me picó la curiosidad de entender si estaba generando un impacto en la comunidad o si realmente tenía audiencia además de las personas a las que les mandaba manualmente los artículos. Ya habían pasado 2 años y más de 50 artículos. Con miedo a conocer con que me encontraría desplegué google analytics. Para mi sorpresa, tenía 1800 sesiones únicas por mes en distintos países de Latinoamérica (mayoría Argentina), un poco en España y un poco en Estados Unidos. Hoy agradezco a quienes nos leen puesto que son más de 2500 personas mensuales leyendo el blog con la mayor concentración en España y luego en Argentina, Perú y Colombia. Incluso hemos pasado por meses que hubo más de 4000 personas leyendo.

Quise conocer aún más quienes leen. En otro aniversario, en este caso 2023, lancé una suscripción casera buscando conocer a quienes leen para generar comunidad más cercana y llevarles mensajes más personalizados que pudiera enriquecernos en confianza. Así comenzó el registro por correo para recibir un newsletter mensual con novedades de artículos, updates de herramientas y storytelling. Si bien son mucho menos que 3500, me gusta saber que aun que comencé tarde a conocerlos, está en proceso para que sientan más cercanía para escribirme por lo que sea y que crezcamos en comunidad.

Curiosidad: si hay algo impredecible es lo que será más visto de lo compartido. Durante muchos años el artículo más popular fue el que cuenta cómo conectarse a onedrive. Sin embargo, desde el 2023 apareció un campeón indiscutido que es el artículo que muestra cómo diseñar fondos para reportes. Nunca pensé que sería esos. He pasado muchísimas horas con implementaciones, pruebas y estudio de otros que fueron de temas muy técnicos o importantes que poco se habla y así también poco se los leyó.

Cerrando

Este espacio es un viaje hermoso que estoy transitando y me abrió conversaciones con referentes increíbles que nunca pensé conocer. Me trajo posibilidades de educación y consultorías que entregué con mucha dedicación. Así mismo, fue responsable de recibir premio como Microsoft MVP en data platform durante 4 años. Algo que ni imaginaba cuando inicié puesto que poco conocía del programa. Me permitió ser speaker en eventos increíbles como PowerBi Fabric Summits 2023 y 2024 de Radacad.

Hoy, 200 artículos después, ya no escribo solo para explicar cosas técnicas. Escribo para seguir construyendo una comunidad que valora compartir lo que sabe. Creo que parte de mi concepto de éxito se mide en hacer lo que uno ama. Amo la comunidad y compartir conocimiento de forma gratuita nos enriquece. El contenido original que se entrega con dedicación y cariño es invaluable. Lo resalto en un mundo donde existen IAs que pueden hacerlo por nosotros. Las palabras que me inspiraron fueron que mis palabras podían ayudar a otros, entonces los animó a ustedes a que usen sus palabras siempre.

Gracias por leerme tantos años. Con gusto y cariño los saluda Nacho,

P/D hoy mi entrega se anima a exceder la barrera de la tecnología y busca que las personas se anime a comunicarse mejor en su vida con sus vínculos o conocerse más en este proyecto. Si querés conocer más entrá a la web de Alpaca Apps aquí.

[ibarrau]

[Fabric] Agregar y compartir origenes de datos nube

Por mucho tiempo se pensó en los orígenes de datos nube como la mejor solución para utilizar PowerBi por su inmediatez ante una actualización programada sin dependencia externas como sucedía en caso de un origen on premise que requiere una puerta de enlace.

Sin embargo, por buen tiempo estuve frente a empresas que elegían utilizar un gateway aunque el origen sea nube por el simple hecho que las puertas de enlace permiten agregar orígenes puntales a datos y compartirlos. Esto para que la canalización de los modelos semánticos tuviera un único acceso a datos.

Esto ya no es más necesario. En este artículo veremos como crear y compartir un origen de datos cloud para mantener esa filosofía de gateway pero sin la necesidad de usarlo.

El lanzamiento de Fabric trajo muchos lanzamientos espectaculares en el ecosistema de datos de Microsoft. Algunos fueron muy desarrollados por las redes y otros fueron quedando más resguardados. Uno de ellos es el que permite mantener conexiones a datos nube.

Como una empresa que busca estandarizar procesos de acceso a datos a desarrolladores o usuarios finales en una estrategia de self-service. Se vuelve indispensable tomar decisiones sobre los detalles de seguridad o normas de control. Una de esas reglas deseadas es que la herramienta de Bi llegue a un origen de datos cloud mediante credenciales y accesos estandarizados por el área de tecnología a las tablas que sean visibles. La idea es que las actualizaciones de modelos de datos viaje en un solo canal controlado que pueda analizarse posteriormente en los orígenes evitando infinidad de consultas y accesos de muchos usuarios a muchas tablas diferentes. Hace mucho tiempo no era posible y solo podíamos agregar una conexión usando una puerta de enlace para reutilizar la conexión. Si no usábamos una puerta y configurábamos las credenciales cloud felices de no usar un gateway, estabamos generando por cada modelo conexiones dependientes de desarrolladores y accesos varios de personas.

¿Por qué haríamos una conexión cloud en Fabric?

Como buena práctica, tener los orígenes cloud estandarizados de accesos y credenciales podemos mantener un margen de seguridad en el acceso a tablas y conexiones abiertas bajo un solo canal. Esto favorece la performance del origen que no debe abrir canales de acceso por la actualización de cada persona que configuro sus credenciales por modelos varios. Además, permite a desarrolladores configurar orígenes de datos sin necesidad de conocer las credenciales productivas. Basta con mapear la conexión que un Administrador delimitó.

NOTA: de manera restrictiva, los orígenes direct lake de lakehouse y warehouse fuerzan esta configuración para poder utilizarlo.

Suficiente texto, veamos como se hace.

¿Cómo agregamos una conexión?

Si vamos al menú de configuración de Fabric veremos que no solo es Configuración de puertas de enlace, sino también de conexiones.

Allí encontrarán la lista de todas las conexiones generadas por todos los usuarios cuando utilizan una conexión nube. Ahí verán que puede haber muy mucho creado por usuarios y que sería mejor controlarlo.

Para agregar una nueva conexión de origen cloud, podemos proceder de dos modos.

Por un lado, darle alta dentro de dicho menú estilo alta tradicional como indica la imagen:

Por otro lado, cuando publicamos un modelo semántico que tiene un origen nube por primera vez, en su configuración de actualizaciones programadas, podremos apreciar que el apartado de gateway ahora también es para conexiones nubes.

Con la opción de gateway apagada, podemos abrir el menú de maps to y poner a crear nueva:

Eso abrirá el menú inicial que mostramos en las pantallas de administración pero precargará algunos valores siendo mas simple su configuración. Si miramos bien la imagen vemos lo que sucede una vez que ya esta configurada. Aparecería "AdventureWorksDW2020" como una conexión que podemos mapear. De esa forma, linkeamos el modelo semántico a la conexión por el canal deseado.

Recordemos que, si usamos direct lake, esto será mandatorio para que el modelo este constantemente actualizado.

Compartir

Una vez definido el origen pasamos a compartirlo para que los desarrolladores puedan utilizar el canal. En el menú donde vemos las conexiones hay tres puntos en cada una. Seleccionamos "Manage users". Abrirá un menú a la derecha donde podemos buscar usuarios

Fíjense que al agregar un usuario tenemos tres permisos para darles. Lo más convencional sería que solo sean "User" para tener la posibilidad de configurar sus modelos semánticos. Quienes tengan el 2do nivel de acceso pueden compartirlo. Permitir compartir es una gran responsabilidad porque damos pie a un acceso que probablemente sea productivo de una persona hacia otras y no de quienes nosotros conocemos. Finalmente, ownership para mantener y administrar en equipo.

Una vez configurado esto, el usuario agregado podrá configurar su modelo semántico mapeando al origen ya sea para un modelo importado o el direct lake activo hacia lakehouse/warehouse.