Para dar una idea del consumo he hecho algo muy sencillo y manual:

• Me he puesto a explorar varias de las Fabric Apps de los posts anteriores, que están todas en la misma área de trabajo “Fabric App”
• Luego he utilizado Fabric Capacity Metrics para mirar el consumo de cómputo y de almacenamiento de dicha área de trabajo durante el día en que hice las pruebas.

Si aún no te has leído las entradas anteriores de la serie, te animo a que lo hagas antes de continuar.

Este post será muy breve porque consiste básicamente en mostrarte los gráficos de Capacity Metrics. Pero primero vamos a repasar lo que dice la documentación.

¿Qué dice la documentación sobre el consumo?

Aquí puedes leer la documentación oficial de precios y uso de capacidad: https://learn.microsoft.com/es-es/fabric/apps/pricing.

Ten en cuenta que las Fabric Apps aún están en versión preliminar.

Los elementos externos a la Fabric App si se cobran por el consumo de la capacidad:

• Base de datos SQL de Fabric
• API de Graph QL
• Funciones de Datos de Usuario (UDF) de Fabric
• La utilización que hace de OneLake el contenido estático de la Fabric App

Aquí yo añadiría:

• Consultas DAX a los modelos semánticos que utilice la Fabric App

Mientras que los componentes de la propia Fabric no se cobran por el consumo consumen de la capacidad:

• El servicio de hospedaje de la aplicación web
• La autenticación
• Las operaciones de despliegue (rayfin up)

Esto no significa que estas operaciones no puedan provocar consumo en otros elementos. Por ejemplo, las operaciones de escritura en OneLake que se realizan durante un despliegue sí consumen capacidad.

A continuación voy a mostrar como reflejan estos consumos Fabric Capacity Metrics.

Cómputo

En la tabla de la imagen muestro los consumos por cómputo de los elementos de algunas de las Fabric Apps. He filtrado por el área de trabajo y por el día en que hice las pruebas. La tabla está ordenada por el nombre de la aplicaciones (columna Item name).

Si te fijas en la segunda columna (Item kind), que indica el tipo0 de elemento que generó el consumo, verás 3 valores diferentes: AppBackend, SQLDbNative, Dataset. Algunas aplicaciones tienen solo AppBackend, mientras que otras tienen AppBackend y SQLDbNative. En la lista también aparecen los modelos semánticos Finanzas y Ventas, que son los únicos del tipo Dataset.

Vamos a tomar de ejemplo las Fabric Apps fabapp-dax-finance y fabapp-etl-config.

Consumo de cómputo de fabapp-dax-finance

En la imagen se muestran los detalles de fabapp-dax-finance, que aparece una sola vez en el listado con el tipo AppBackend. Te recuerdo que esta Fabric App se conecta al modelo semántico de Finanzas y que no utiliza una base de datos SQL.

En los detalles se observan solo 2 operaciones billables relacionadas con OneLake: OneLake Other Operations y OneLake Read via Proxy y que están relacionadas con el acceso al contenido estático de la Fabric App que se utiliza en el frontend y que está almacenado en OneLake pero no tenemos acceso directo a él.

Hay otro consumo de cómputo en el que ha incurrido esta aplicación y que no se ve en la imagen con los detalles: las consultas al modelo semántico Finanzas.

En esta imagen muestro los detalles del consumo para Finanzas, donde se aprecia que la única operación es XMLA Read Operation, debido a las consultas DAX que se hacen desde la Fabric App.

Consumo de cómputo de fabapp-etl-config

Ahora vamos a ver los detalles del consumo de cómputo de la Fabric App fabapp-etl-config que si utiliza una base de datos SQL y no utiliza un modelo semántico. Esta aplicación aparece dos veces en el listado, una vez con AppBackend y la otra con SQLDbNative.

En la siguiente imagen he expandido los detalles de AppBackend, donde se observan cuatro operaciones. OneLake Other Operations y OneLake Read via Proxy ya la vimos en la aplicación anterior. OneLake Write via Proxy es nuevo y se produce por un despliegue que hice de esta aplicación mediante rayfin up. La última operación es GraphQL Query es la que más me interesa porque representa el consumo de las consultas GraphQL sobre la base de datos SQL.

También he abierto los detalles de la otra línea de esta Fabric App, correspondiente a SQLDbNative y que nos muestra las operaciones de la base de datos SQL vinculada a la aplicación.

La operación más importante es Sql Usage, que se refiere al consumo de las consultas T-SQL. También se ven varias operaciones de OneLake que son propias de la operación de la base de datos SQL.

Consumo de cómputo de otras Fabric Apps

He mostrado las operaciones que consumen capacidad de dos aplicaciones, una que se conecta a un modelo semántico y otra que se conecta a una base de datos SQL. Pero recuerda que entre los ejemplos de esta serie de blogs hay una aplicación que combina dos modelos semánticos y otra que combina un modelo semántico con una base de datos SQL. En este último caso aparecerán tanto operaciones de Dataset como de SQLDbNative dentro de la misma Fabric App.

Almacenamiento

En cuanto al consumo de almacenamiento, adjunto una imagen con la página de almacenamiento de Capacity Metrics, filtrada por el área de trabajo donde están las Fabric Apps que he implementado en esta serie de blogs.

Puedes observar que hay operaciones de almacenamiento tanto en OneLake como en la base de datos SQL. El consumo de OneLake corresponde principalmente al contenido estático de las aplicaciones.

En el gráfico inferior izquierdo se aprecia que el almacenamiento se ha mantenido estable en los últimos días. Esto se debe a que todas las aplicaciones habían sido desplegadas a Fabric con anterioridad al primer día mostrado en el gráfico, y aunque he usado algunas de las aplicaciones, no he insertado muchos datos en ninguna de las bases de datos SQL.

El gráfico inferior derecho muestra el almacenamiento facturable acumulado durante el periodo, que se calcula mediante un prorrateo de los datos almacenados durante el intervalo de tiempo. Que el gráfico crezca de forma lineal indica que el volumen de datos se ha mantenido estable.

Continuará…

Gracias por llegar hasta aquí. 😊

La serie continuará, en la próxima entrega hablaré sobre las funciones.

Cuando creamos una Fabric App, el backend se gestiona a través de Rayfin, pero en el frontend tenemos libertad total. Las plantillas nos ofrecen un punto de partida a través de la instalación de componentes, para tener disponible un framework con el que podemos acelerar el desarrollo.

Si aún no te has leído las entradas anteriores de la serie, te animo a que lo hagas antes de continuar.

Las plantillas incluidas con Rayfin

En entradas anteriores hemos visto que la herramienta de línea de comandos (CLI) de Rayfin incorpora varias plantillas:

1. Blank App: Una aplicación web muy sencilla de una sola página.
   • Sin base de datos.
   • Biblioteca React para los componentes del frontend.
   • Herramienta Vite para gestionar el desarrollo de la aplicación web.
   • La única skill incluida es la de Rayfin.
2. Data App: Aplicación web analítica preparada para conectarse a modelos semánticos de Fabric.
   • Sin base de datos.
   • También utiliza React y Vite.
   • Además de la skill de Rayfin, incluye varias skills para la planificación, desarrollo y validación de la aplicación analítica, como explico en un post de esta serie.
3. Todo App: Aplicación web de ejemplo que gestiona una lista de tareas.
   • Utiliza una base de datos SQL.
   • También utiliza React y Vite.
   • La única skill es la de Rayfin, que incluye instrucciones para gestionar la base de datos desde del frontend con GraphQL, como comento en otro post de esta serie.
   • Hay dos plantillas de este tipo y la principal diferencia entre ellas es que una incorpora la biblioteca Radiux UI.

Si utilizamos Fabricator para desarrollar nuestra Fabric App, tenemos disponible una plantilla propia llamada Universal App.

Todas estas plantillas incorporan autenticación con Fabric, que hasta el momento es un requisito para utilizar las Fabric Apps.

Awesome Rayfin

Además de las plantillas incluidas con Rayfin, Microsoft mantiene un repositorio en GitHub con más plantillas, algunas desarrolladas por la comunidad.

Este es el repositorio: https://github.com/microsoft/awesome-rayfin.

Para crear una Fabric App con Rayfin CLI a partir de alguna de las plantillas, utiliza este comando:

npm create @microsoft/rayfin@latest "Mi app" -- --template https://github.com/microsoft/awesome-rayfin

Los guiones dobles (–) hay que repetirlos, no es un error.

Al ejecutar el comando anterior, se presentará el listado de las plantillas disponibles, como se aprecia en la siguiente imagen. Ten en cuenta que solo se muestran 7 plantillas, pero hay más, que puedes ver desplazándote con la flecha hacia abajo.

Si utilizas Fabricator, puedes acceder a estas plantillas cuando creas un proyecto con la opción Template/Community.

Si entras al repositorio puedes ver los detalles y el código de las plantillas que contiene. En este momento hay 9 plantillas, y a continuación te comento las que me parecen más interesantes.

Angular Blank App

https://github.com/microsoft/awesome-rayfin/tree/main/templates/angular-blankapp

Es una plantilla mínima, sin base de datos, que utiliza en el frontend Angular en lugar de React, y la biblioteca de componentes de UI Angular Material.

No incluye skills adicionales, solo la de Rayfin.

Angular Dashboard App

https://github.com/microsoft/awesome-rayfin/tree/main/templates/angular-dashboard

Esta plantilla crea un cuadro de mandos para manejar proyectos. Piensa en una aplicación Todo pero más avanzada. O en GitHub Projects. De hecho puede conectarse a un repositorio público de GitHub y mostrar los issues y las pull requests.

Utiliza una base de datos SQL y se basa en la plantilla Angular Blank App.

Slide Deck

https://github.com/microsoft/awesome-rayfin/tree/main/templates/slide-deck

Con esta plantilla puedes implementar una Fabric App para crear diapositivas con Markdown o HTML y presentarlas a tu audiencia, con registro de participantes y chat en vivo.

Utiliza una base de datos SQL.

Power BI Fixer

https://github.com/microsoft/awesome-rayfin/tree/main/templates/pbi-fixer

Esta plantilla es maravillosa porque crea una Fabric App llena de funcionalidades:

• Edición de modelos semánticos
• Optimización de modelos semánticos asistida por IA
• Edición de reportes
• Tareas de administración de Fabric
• Creación de Fabric Apps
• Y mucho más…

El autor es también el creador del proyecto PBI Fixer, un notebook para Fabric que permite optimizar modelos semánticos e informes de una manera interactiva y que utiliza Semantic Link Labs.

En esta plantilla ha incorporado todo lo que está en el notebook y ha añadido nuevas opciones. Vale mucho la pena revisar el código, porque incluso ha utilizado User Defined Functions (UDF) de Fabric que aún no están soportadas oficialmente en Rayfin.

Crear tu propia plantilla

Es muy fácil crear una plantilla para Rayfin porque no es más que una Fabric App pero con alguna configuración extra.

En el repositorio Awesome Rayfin hay un documento con las directrices para crear una plantilla: https://github.com/microsoft/awesome-rayfin/blob/main/docs/template-guidelines.md.

También hay un fichero AGENTS.md con instrucciones para los agentes de IA.

Y los requisitos para publicar una plantilla en el repositorio: https://github.com/microsoft/awesome-rayfin/blob/main/CONTRIBUTING.md.

Si revisas este último documento verás que hay una serie de pasos para publicar nuestra plantilla en Awesome Rayfin y por supuesto hay que hacer un Pull Request (PR) y esperar la aprobación.

Para utilizar una plantilla, no es obligatorio que esté en Awesome Rayfin, sino que podemos hacerlo desde un repositorio propio o incluso desde una carpeta.

A continuación te comento dos ficheros que si son imprescindibles en las plantillas.

Fichero rayfin-template.yml

Toda plantilla tiene que tener un fichero rayfin-template.yml con esta estructura:

apiVersion: v1
metadata:
  name: angular-blankapp
  displayName: Angular Blank App
  description: Bare-bones Fabric-authenticated Angular + Material app — sign-in, routing, and a placeholder home page, with no data layer to remove
entries:
  - path: .
    name: Angular Blank App

El código anterior es de la plantilla Angular Blank App https://github.com/microsoft/awesome-rayfin/blob/main/templates/angular-blankapp/rayfin-template.yml

name tiene que coincidir con el nombre de la carpeta donde está la plantilla y el formato tiene que ser kebab case.

entries contiene la ruta al código de la plantilla y el nombre de la plantilla.

Si en una carpeta hay varias planillas, se crea un elemento de entries para cada una, por ejemplo:

apiVersion: v1
metadata:
  name: awesome-rayfin
  displayName: Awesome Rayfin Templates
  description: Community-curated template gallery for Project Rayfin
entries:
  - path: templates/angular-blankapp
    name: Angular Blank App
    description: Bare-bones Fabric-authenticated Angular + Material app — sign-in, routing, and a placeholder home page, with no data layer to remove
  - path: templates/angular-dashboard
    name: Angular Dashboard App
    description: Responsive Angular Material dashboard — top navbar + collapsible side menu, Project/Task data model, and optional one-click GitHub Issues/PRs sync for a public repo.
  - path: templates/field-technician
    name: Field Technician App
    description: Field service management app with role-based dashboards for dispatchers and technicians, job tracking, customer lookup, and dual-mode auth (local password + Fabric)

El código anterior es un fragmento del fichero rayfin-template.yml del repositorio Awesome Rayfin https://github.com/microsoft/awesome-rayfin/blob/main/rayfin-template.yml

La carpeta de cada plantilla tendrá que contener a su vez un fichero rayfin-template.yml como el del primero ejemplo.

Fichero manifest.json

El fichero manifest.json está presente en las Fabric Apps aunque no sean plantillas, pero en el caso de estas la propiedad templatedId tiene que coincidir con el nombre de la carpeta.

{
  "templateId": "angular-blankapp",
  "icon": "angular-blankapp",
  "services": {
    "auth": true,
    "data": true,
    "storage": false,
    "staticHosting": true
  },
  "hasDabSchema": false,
  "tokens": [
    "__RAYFIN_API_URL__",
    "__RAYFIN_PK__",
    "__FABRIC_ITEM_ID__",
    "__FABRIC_WORKSPACE_ID__",
    "__FABRIC_PORTAL_URL__"
  ]
}

El código anterior es de la plantilla Angular Blank App https://github.com/microsoft/awesome-rayfin/blob/main/templates/angular-blankapp/manifest.json

Hola plantillas

Para demostrar como puedes crear tu propia plantilla, voy a preparar una muy básica que he llamado hola-plantillas, y que consiste en una única página estática.

Para hacer una plantilla te recomiendo que primero implementes una Fabric App y compruebes que funcione y luego la conviertes en plantilla añadiendo el fichero rayfin-template.yml y el resto de los metadatos. Y que te asegures de eliminar cualquier referencia a áreas de trabajo u otros elementos que puedan aparecer en la Fabric App al hacer pruebas o despliegue.

Estos son los pasos que he seguido para crear la plantilla hola-plantillas:

1. He creado una Fabric App con el nombre “Hola plantillas” utilizando la plantilla “Blank App”. Lo que crea la carpeta hola-plantillas.
2. He utilizado un agente de IA para que modifique la aplicación y la simplifica aún más dejando solo una página web y la autenticación, y que deshabilite la base de datos.
3. He probado la aplicación localmente y también la he desplegado a Fabric.
4. He clonado el repositorio Awesome Rayfin en mi ordenador con el comando: git clone https://github.com/microsoft/awesome-rayfin.gi
5. He recurrido de nuevo el agente de IA para que me ayude a convertir la Fabric App en una plantilla, indicándole que utilice la SKILL de la copia local de Awesome Rayfin.
   • He comprobado que exista el fichero rayfin-template.yml y que esté correcto.
   • He comprobado que el fichero manifest.json tenga el valor correcto (hola-plantilla) en templateId
6. He limpiado las referencias a datos privados que pudieran quedar de la Fabric App:
   • En el fichero rayfin/rayfin.yml quitar los elementos de allowedRedirectUris que no incluyan localhost.
   • Eliminar el fichero fichero rayfin/.deployments.json
   • Eliminar el fichero fichero rayfin/.env
   • Eliminar el fichero fichero .env.local

El resultado lo he publicado en GitHub: https://github.com/dataxbi/fabric-app-templates/tree/main/hola-plantillas

Para crear una Fabric App con Rayfin CLI a partir de esta plantilla, utiliza este comando:

npm create @microsoft/rayfin@latest "Hola Plantillas" -- --template https://github.com/dataxbi/fabric-app-templates --template-name hola-plantillas

Si utilizas Fabricator, al crear el proyecto ve a la opción Template/Community y has scroll hasta el final de la lista y busca el link “Use a custom URL” que está abajo a la derecha, y llena el URL del repositorio y el nombre de la plantilla como muestra la imagen.

En realidad el repositorio donde está hola-plantillas contiene otra plantilla que veremos a continuación, y también tiene un fichero rayfin-template.yml general para que se pueda usar directamente el URL del repositorio y aparezca el listado de las plantillas disponibles.

npm create @microsoft/rayfin@latest "Otra Plantillas" -- --template https://github.com/dataxbi/fabric-app-templates

Una plantilla corporativa

La gobernanza ha sido una de las principales preocupaciones desde que fueron anunciadas las Fabric Apps, y con razón, porque sin ningún control podemos tener una explosión de aplicaciones web y bases de datos en las áreas de trabajo de Fabric.

Creo que las plantillas pueden servirnos para dar un pequeño paso en la buena dirección, porque las veo como el lugar donde podemos recoger las reglas que deben cumplir las Fabric Apps que se desplieguen en la empresa. Es verdad que por ahora Fabric no provee out of the box un mecanismo para forzar el uso de determinadas plantillas, ni de validar antes de desplegar, pero recuerda que las Fabric Aps aún están en versión preliminar, y además creo que con las herramientas que existen para CI/CD y las APÎs se podría implementar algún mecanismo a la medida.

A modo de ejemplo, he creado una plantilla para crear cuadros de mandos a partir de modelos semánticos publicados en Fabric, que ya incorpora un diseño corporativo. Lo puedes ver como el equivalente a un tema de Power BI, pero que además de indicar los colores, también tiene la disposición de los elementos generales (logo de la empresa, el encabezado, el menú), y también una biblioteca de componentes específicos para las visualizaciones

El nombre de la plantilla es brand-dashboard y la he publicado en el mismo repositorio de GitHub que he mencionado antes. Puedes acceder directamente con este URL: https://github.com/dataxbi/fabric-app-templates/tree/main/brand-dashboard

Para crearla me he basado en la plantilla Data App de Rayfin con las siguientes adaptaciones:

• Shell corporativo: Sustituye el layout simple por una barra lateral expandible/contraíble y cabecera compartida.
• Componentes visuales: Reemplaza VegaVisual por Recharts + componentes shadcn/ui para consistencia visual.

La idea con esta planilla no es que la uses directamente para crear una Fabric App, sino que la descargues, clonando el repositorio, y la personalices con el logo y los colores corporativos.

Luego creas las Fabric Apps a partir de la plantilla con tus modificaciones. O que compartas la plantilla modificada en algún repositorio para que la puedan utilizar otros colegas.

Esto se explica en la guía para administradores que está en el repositorio.

También hay otra guía para los colegas que utilicen la plantilla modificada.

Así luce la plantilla:

Así luce una aplicación implementada con esta planilla:

Continuará…

Gracias por llegar hasta aquí. 😊

La serie continuará, en la próxima entrega hablaré del consumo de CUs de la capacidad Fabric.

Todos los ejemplos que te he mostrado en esta serie los he construido en la línea de comandos (Terminal de Windows), por requerimientos de Rayfin y también por preferencias personales. Pero este post va a ser diferente porque mostraré una aplicación de escritorio desde la que puedes controlar todo el ciclo de vida de una Fabric App, desde la instalación de los requerimientos, la conexión al modelo semántico, el desarrollo de la aplicación, el control de versiones con Git y el despliegue en Fabric.

Si aún no te has leído las entradas anteriores de la serie, te animo a que lo hagas antes de continuar.

Instalando Fabricator

Todo el código de Fabricator está disponible en GitHub: https://github.com/spatney/rayfin-fabricator.

Su autor, Sachin Patney, es empleado de Microsoft donde lidera el desarrollo de Rayfin, pero Fabricator es un proyecto personal que realiza en su tiempo libre por lo que no está soportado por Microsoft.

Desde el repositorio de GitHub se puede descargar el instalador para Windows o para Mac: https://github.com/spatney/rayfin-fabricator/releases/latest

• El nombre del instalador para Windows tiene este formato: Rayfin Fabricator_<version>_x64-setup.exe
• El nombre del instalador para Mac tiene este formato: Rayfin Fabricator_<version>_aarch64.dmg

Una vez instalado, lo ejecutamos, y lo primero que hace es comprobar si en el ordenador están las herramientas necesarias:

• Node.js
• Git
• Azure CLI
• GitHub CLI (opcional)

Si alguna no está, podemos instalarla desde el propio Fabricator.

GitHub CLI solo es necesario si tenemos una cuenta en GitHub y queremos clonar repositorios donde tengamos Fabric Apps.

Además de estas herramientas, se requiere:

• Tener acceso a un área de trabajo de Fabric en un inquilino donde se hayan habilitado las Fabric Apps
• Tener una licencia de GitHub Copilot

Fabricator te permite entrar tus credenciales para conectarte a GitHub Copilot y a Fabric a través de Azure CLI.

Creando la Fabric App

Después de instalar las herramientas y conectarnos a GitHub Copilot y a Fabric, estamos listos para comenzar a crear nuestra Fabric App. Para ello utilizamos el botón “Enter Fabricator →” que encontrarás en la parte inferior derecha de la pantalla.

Se nos presentan tres opciones:

• New project
• Open folder
• Clone from GitHub (esta opción necesita instalar GitHub CLI)

También te recomiendo prestar atención al recuadro que aparece abajo, con la ruta a la carpeta donde Fabricator creará los proyectos, que puedes cambiar si lo deseas.

Vamos a escoger la opción “New project” que nos llevará a una pantalla como la que te muestro abajo, donde debemos escribir el nombre del proyecto y seleccionar una plantilla.

Yo le he puesto el nombre “Hola Fabricator”, por lo que el proyecto se creará en la carpeta hola-fabricator.

En cuanto a la plantilla, he utilizado “Universal App”, que es la predeterminada y es propia de Fabricator, pero también se puede escoger la plantilla “Todo App” (que comenté en el post anterior) u otras plantillas creadas por la comunidad.

Te adelanto que la próxima entrega de esta serie estará dedicada a las plantillas.

Le damos al botón “Create project” y esperamos unos minutos a que se descarguen los componentes de la plantilla en la carpeta del proyecto.

Antes de comenzar a trabajar en la Fabric App tenemos que desplegarla en un área de trabajo con capacidad Fabric, y para ello Fabricator nos mostrará una pantalla donde podemos buscar entre las áreas de trabajo, o crear una.

Yo he escogido el área de trabajo con el nombre “Fabric_App”.

Cuando haya terminado el despliegue, aparecerá una pantalla como la que te muestro continuación, dividida en dos paneles: a la izquierda tenemos un chat para darle las instrucciones a GitHub Copilot, y a la derecha podemos interactuar con la Fabric App que por ahora es poco más que un lienzo en blanco.

Encima de los paneles al centro, tenemos cuatro botones:

• Build
• Code
• Model
• Advisor

En la pantalla de la imagen anterior estamos en el modo “Build”, pero si cambiamos al modo “Code” podemos ver el código de la aplicación con un editor que incorpora Fabricator, o podemos abrir Visual Studio Code mediante el botón que está arriba a la derecha.

También podemos revisar el historial de cambios, lo que es posible porque Fabricator se encarga de utilizar Git para hacer commit cada vez que se hace una modificación.

Y en el mismo modo “Code” también podemos activar y desactivar skills con instrucciones y herramientas para los agentes de IA.

Construyendo un cuadro de mando

Vamos a regresar al modo “Build” para construir un cuadro de mando de ventas utilizando el mismo modelo semántico del segundo post de esta serie.

Recomiendo habilitar el modo plan de GitHub Copilot, que en Fabricator está inactivo de inicio por ser una funcionalidad que áun está en pruebas (beta). Hay que buscar el botón “Settings” en la esquina superior derecha de la pantalla y dentro de la ventana de configuración abrir la opción EXPERIMENTS, que está al final, y activar la opción “Chat mode selector”.

Después de activarlo, hay que seleccionarlo en el panel de chat.

De esta manera podemos trabajar siguiendo el mismo proceso de toda la serie: plan - especificación - implementación - testing - despliegue, en varias iteraciones.

Las primeras instrucciones que le daremos al agente de IA serán para indicarle el modelo semántico que debe utilizar. Fabricator nos ofrece una manera muy practica mediante un botón situado en la esquina inferior derecha del chat, como se muestra en la imagen. Al pulsarlo, aparece una lista con los modelos semánticos disponibles en el área de trabajo donde hemos desplegado la Fabric App. Cuando seleccionamos uno, se añaden al chat las instrucciones con los identificadores del modelo semántico y del área de trabajo.

También es posible adjuntar imágenes en el chat, por ejemplo, un boceto del cuadro de mando, o un logotipo, pero en este caso no he utilizado ninguna imagen.

Por cierto, otra de las maravillas de Fabricator es que podemos revisar la estructura del modelo semántico seleccionado, con el botón “Model” de la parte superior de la pantalla.

Para continuar, escribimos en el chat algunas instrucciones generales sobre el cuadro de mando, para que el agente de IA nos proponga un plan.

Yo comencé con estas instrucciones:

Crea un cuadro de mandos que ofrezca una visión general de las ventas utilizando las medidas que ya existen en el modelo. Que los indicadores se comparen con el año anterior.

El agente me hizo algunas preguntas y yo le hice algunas sugerencias adicionales, y este fue el plan acordado:

- Primera entrega: crear únicamente docs/especificaciones-dashboard.md con alcance, KPIs, comparación interanual, visuales, filtros, estados y criterios de aceptación.
- Detener todo trabajo después de crear el documento para que puedas revisarlo.
- Mantener bloqueados el pack analytics, la conexión al modelo, el DAX y el dashboard hasta recibir tu aprobación explícita de las especificaciones.
- Tras aprobarlas, continuar con la conexión ventas, descubrimiento del esquema e implementación validada contra datos reales.

Revisé el documento con las especificaciones dentro del propio fabricator utilizando el botón “Code”, y le di el OK al agente de IA para que implementara el plan.

Después de trabajar durante un rato, el agente de IA tuvo lista y desplegada una primera versión del cuadro de mando, que te muestro en el vídeo.

Como esta Fabric App utiliza un modelo semántico, he tenido que utilizar el botón “Fabric”, de la esquina superior derecha, para que se abra dentro del portal de Fabric.

Modo diseño

El cuadro de mando ha quedado bastante bien, pero quiero dos mejoras:

• Cambiar el gráfico de donut por uno de columnas
• Quitar los títulos de los ejes de los gráficos

Para el primer cambio, Fabricator nos ofrece otra herramienta maravillosa: el modo diseño, que se activa con el botón “Design” ubicado en la esquina superior derecha, junto al botón “Fabric”.

En dicho modo podemos modificar el aspecto de la Fabric App de manera visual, por ejemplo, seleccionar un elemento para cambiar sus dimensiones, el font o el color. O seleccionar un gráfico para cambiarle el tipo. O incluso, dibujar o escribir comentarios. Es un poco como Power Point o Canvas.

Pero esto no modifica directamente la Fabric App, sino que hay que pulsar el botón “Send tu chat” para que se genere una imagen y unas instrucciones que se envían al chat para que el agente de IA haga las modificaciones en el código.

En este caso, seleccioné el gráfico de donut y cambié el tipo a gráfico de barras, como se aprecia en la imagen.

Para el segundo cambio no utilicé el modo diseño, sino que se lo pedí directamente en el chat.

Despliegue

Cada vez que el agente de IA realiza cambios en la Fabric App, automáticamente se hace un commit con Git, y se vuelve a desplegar en el área de trabajo de Fabric que indicamos al crear el proyecto.

Si necesitamos hacer un despliegue puntual, podemos utilizar el botón “Redeploy” ubicado en la esquina superior derecha.

Y también podemos añadir otras áreas de trabajo para desplegar la misma Fabric App, por ejemplo, para tener un entorno de desarrollo y otro de pruebas, como se muestra en la imagen.

Advisor

Para finalizar este recorrido por Fabricator quiero mencionar otra maravilla: la pantalla “Advisor”, que utiliza a GitHub Copilot para revisar el código de la aplicación y detectar problemas de seguridad, de rendimiento o de accesibilidad.

Yo lo ejecuté con la aplicación y encontró dos problemas, uno de rendimiento y otro de accesibilidad, como se muestra en la imagen.

Si se pulsa en el botón “Fix with Copilot” de un problema, se copia el texto en el chat para que el agente de IA trate de resolverlo.

Continuará…

Gracias por llegar hasta aquí. 😊

En la próxima entrega de la serie hablaré sobre las plantillas de Rayfin.

Si aún no te has leído las entradas anteriores de la serie, te animo a que lo hagas antes de continuar.

Hola GraphQL

Vamos a comenzar creando una Fabric App a partir de la plantilla Basic Todo App de Rayfin. Para ello, abro una terminal y ejecuto el comando:

npm create @microsoft/rayfin@latest "Hola GraphQL"

Una aplicación Todo nos permite gestionar una lista de tareas por hacer, y es un ejemplo clásico en los tutoriales de lenguajes de programación, porque es bastante sencilla de implementar.

Recuerda que debes cumplir con los requisitos indicados en la primera entrada de la serie.

Si te fijas, verás que he escogido la opción 4, aunque la opción 3 también es una plantilla Todo App. La principal diferencia es que en la opción 3 el frontend está más elaborado que en la opción básica que he elegido, y utiliza la biblioteca de componentes Radix UI.

La ejecución de la plantilla crea la carpeta hola-graphql con el código de la Fabric App.

En la terminal, entra a la carpeta: cd hola-graphql.

Despliega la Fabric App con el comando npx rayfin up.

Ve al área de trabajo de Fabric y prueba la aplicación creando algunas tareas. También entra a la base de datos y mira las tablas que se han creado.

Detalles a tener en cuenta en este tipo de Fabric App, que accede a una base de datos SQL:

• Si se puede abrir de manera independiente, sin estar dentro del portal de Fabric, a diferencia de las Fabric Apps que acceden a modelos semánticos que, por ahora, sólo se pueden abrir dentro del portal de Fabric.
• Cada Fabric App tiene su propia base de datos SQL y, por ahora, no se puede conectar a otra.

El código lo he publicado en GitHub: https://github.com/dataxbi/fabapp-hello-graphql

Hice unos cambios mínimos en el frontend para agregarle el ícono y el logo de dataXbi. Los hice yo mismo, sin ningún agente de IA 😊.

¿Te has preguntado por qué le he llamado “Hola GraphQL” a esta Fabric App? La respuesta te la doy al final de la siguiente sección.

Revisando el código generado por la plantilla Basic Todo App

Aunque las Fabric Apps han sido concebidas para que el código no lo piquemos nosotros, sino que contemos con la ayuda de los agentes de IA, creo que vale la pena tener una idea general del funcionamiento interno.

Por lo que vamos a revisar algunos aspectos del código generado por la plantilla.

Puedes abrir Visual Studio Code desde la terminal con el comando code ..

Lo primero que te quiero mostrar del código son las instrucciones para los agentes de IA, que están en los ficheros /AGENTS.md y /.agents/skills/rayfin/SKILL.md y que son prácticamente los mismos que los de la plantilla Blank App que mostré en el post inicial de la serie. De estas instrucciones, las secciones importantes para el trabajo con una base de datos son: Security, Data Modeling, Querying y Schema.

Estas son las únicas instrucciones para agentes de IA incluidas con esta plantilla. No viene el conjunto de skills de la plantilla Data App que mostré en el segundo post de la serie.

Backend

Otra parte interesante del código está en la carpeta /rayfin donde se configura el backend. Dentro de esta carpeta encontramos el fichero rayfin.yml que ya conocemos, y donde está habilitada la base de datos SQL de Fabric:

  data:
    enabled: true
    dialect: mssql

La estructura de esta base de datos se establece en la carpeta /rayfin/data a través del fichero schema.ts y de un fichero por tabla.

Fichero schema.ts:

import { Todo } from './Todo.js';

export type TodoAppSchema = {
  Todo: Todo;
};

export const schema = [Todo];

En este caso solo hay una tabla con el nombre Todo cuya definición está en el fichero Todo.ts.

Fichero Todo.ts:

import {
  entity,
  role,
  text,
  boolean,
  date,
  uuid,
} from '@microsoft/rayfin-core';

@entity()
@role('authenticated', '*', {
  policy: (claims, item) => claims.sub.eq(item.user_id),
})
export class Todo {
  @uuid() id!: string;
  @text({ min: 1, max: 100 }) title!: string;
  @boolean() isCompleted!: boolean;
  @date() createdAt!: Date;
  @text() user_id!: string;
}

El nombre que tendrá la tabla en la base de datos se define en la instrucción export class Todo, y a dicho nombre se le agregará una s.

A partir de esta configuración, Rayfin crea la base de datos cuando desplegamos la Fabric App con el comando npx rayfin up.

Aunque la estructura de la base de datos se puede modificar directamente en Fabric, es muy recomendable que todos los cambios se hagan aquí en esta configuración. De esta manera se actualizarán cada vez que hagamos un despliegue. Podemos utilizar el comando npx rayfin up db apply si sólo queremos cambiar la base de datos sin actualizar el resto de la Fabric App.

Te invito a leer en la documentación oficial los detalles de la configuración de la base de datos (modelo de datos).

Si luego de desplegar la Fabric App, vas al área de trabajo y revisas la base de datos, podrás comprobar que se ha creado una tabla con el nombre Todos.

Permisos de datos

Si revisas con atención Todo.ts encontrarás que, además de la estructura de la tabla, se incluye este fragmento de código:

@role('authenticated', '*', {
  policy: (claims, item) => claims.sub.eq(item.user_id),
})

Aquí se está indicando que solo pueden acceder a esta tabla los usuarios con el rol authenticated (que son todos porque recuerda que para acceder a cualquier Fabric App hay que autenticarse en Fabric), y que pueden realizar cualquier operación de creación, lectura, modificación o borrado. Si se crea o modifica una fila, el ID del usuario se guardará en la columna user_id. Y si se lee la tabla se filtrarán las filas donde el ID del usuario coincida con el valor en la columna user_id.

El ID del usuario proviene de Microsoft Entra ID que es el servicio de autenticación que utiliza Fabric.

Cuando revisaste la base de datos creada en Fabric habrás notado que además de la tabla Todos, también se había creado una tabla Users. Esta es una tabla de sistema, creada automáticamente por Rayfin.

Puedes profundizar sobre los permisos de datos en la documentación oficial.

Frontend

Para finalizar este recorrido por el código, te voy a llevar a la carpeta /src que forma parte del frontend de la Fabric App. Y dentro de esta carpeta voy a abrir el fichero /src/services/todos.ts que contiene las operaciones de lectura, inserción, modificación y borrado que se hacen en la base de datos. Estas operaciones utilizan internamente el lenguaje de consultas para APIs GraphQL y es la razón de que el nombre de esta Fabric App sea “Hola GraphQL”.

A continuación muestro algunos fragmentos del código de todo.ts.

Listar las filas de la tabla Todos:

  const client = getRayfinClient();
  const results = await client.data.Todo.select([
    'id',
    'title',
    'isCompleted',
    'createdAt',
  ])
    .orderBy({ createdAt: 'desc' })
    .execute();

Crear una fila en la tabla Todos:

  const client = getRayfinClient();
    const session = client.auth.getSession();
    if (!session.isAuthenticated || !session.user) {
      throw new Error('Cannot create todo: user is not authenticated.');
    }
    const todo = await client.data.Todo.create({
      title,
      isCompleted: false,
      createdAt: new Date(),
      user_id: session.user.id,
    });

Modificar una fila de la tabla Todos:

  const client = getRayfinClient();
  await client.data.Todo.update({ id }, updates);
  const todo = await client.data.Todo.findById(id);

Borrar una fila de la tabla Todos:

  const client = getRayfinClient();
  await client.data.Todo.delete({ id });

ETL Config

En el segundo ejemplo he hecho una Fabric App para gestionar la configuración de la ingesta de datos hacia la capa bronce de una arquitectura Medallion. Cuando implemento una ETL me gusta que sea metadata driven, y una base de datos SQL es una buena opción para guardar los metadatos de configuración. Algunos de esos metadatos se pueden llenar de manera automática, pero es útil poder hacer modificaciones puntuales, y con una Fabric App se logra una solución muy elegante.

He partido de la misma plantilla Basic Todo App, y he utilizado agentes de IA siguiendo el mismo proceso que ya he explicado en otros posts de esta serie: plan - especificación - implementación - testing - despliegue, en varias iteraciones.

Recomiendo instalar el MCP de Microsoft Learn para que los agentes tengan acceso a la documentación de la configuración del modelo de la base de datos SQL.

Lo primero que definí fue la estructura de la tabla de metadatos:

CREATE TABLE EtlConfigIngestions (
    ConfigId UNIQUEIDENTIFIER NOT NULL PRIMARY KEY DEFAULT NEWID(),

    IsEnabled BIT NOT NULL DEFAULT 1,

    SourceConnectionName NVARCHAR(100) NOT NULL,
    SourceSchemaName NVARCHAR(128) NOT NULL,
    SourceTableName NVARCHAR(128) NOT NULL,

    LoadMode NVARCHAR(20) NOT NULL,
    IncrementalColumnName NVARCHAR(128) NULL,

    TargetWorkspaceName NVARCHAR(100) NOT NULL,
    TargetLakehouseName NVARCHAR(100) NOT NULL,
    TargetSchemaName NVARCHAR(128) NULL,
    TargetTableName NVARCHAR(128) NOT NULL,

    CreatedAt DATETIME2 NOT NULL
        DEFAULT SYSDATETIME(),

    UpdatedAt DATETIME2 NULL,
    UpdatedByUserId NVARCHAR(100) NULL,

    CONSTRAINT CK_EtlConfigIngestions_LoadMode
        CHECK (LoadMode IN ('Full', 'Incremental'))
);

En cuanto a la parte visual de la aplicación, le indiqué que se basara en el diseño de nuestro sitio web y que utilizara la biblioteca TanStack Table.

La especificación completa la puedes leer aquí: https://github.com/dataxbi/fabapp-etl-config/blob/main/specs/00-especificacion-general.md

Todo el código está disponible en GitHub: https://github.com/dataxbi/fabapp-etl-config

Si revisas el historial de los commits podrás ver cómo fui iterando hasta llegar a la versión final.

Análisis What-If PyG

Para el último ejemplo de hoy voy a combinar en una Fabric App un modelo semántico de finanzas y una base de datos SQL, para implementar un análisis what-if de pérdidas y ganancias (PyG).

El modelo semántico es el mismo que utilicé en el segundo post de esta serie para implementar un informe de PyG. La base de datos SQL almacena posibles escenarios de aumento o disminución de los ingresos y los gastos, expresados en valores porcentuales. La Fabric App permite gestionar los escenarios (crear, modificar, borrar), y comprobar cómo influyen en el informe de PyG, calculando la variación con el estado actual. Esto ocurre de forma interactiva y con un tiempo de respuesta bajo, por lo que la experiencia del usuario es muy buena.

Esta Fabric App solo se puede abrir dentro del portal de Fabric porque accede a un modelo semántico.

Lo que ocurre internamente es lo siguiente:

• La gestión de los escenarios se hace con GraphQL. Excepto el listado de cuentas al insertar un ajuste, que se obtiene con una consulta DAX al modelo semántico.
• Para construir la tabla PyG What-if, primero se hace una consulta GraphQL para obtener los valores del escenario. Estos datos se incluyen en una consulta DAX que se envía al modelo semántico, para obtener los valores actuales de ingresos, gastos y total, y calcular la variación con el escenario.

En el modelo semántico no hay medidas para calcular la variación, porque los datos del escenario no están en el modelo. Hay expresiones DAX que solo están en la Fabric App.

En lugar de crear tablas desconectadas dentro del modelo, las estamos externalizamos a una base de datos SQL, y también externalizamos, en el frontend de la Fabric App, el código DAX que hace la conexión y los cálculos.

Al implementar este ejemplo, en lugar de crear una nueva aplicación con Rayfin, cloné el repositorio con el informe de PyG. Si hubiera empezado de cero, utilizaría la plantilla Data App porque incluye todo lo necesario para hacer y probar las consultas DAX, que es lo más complicado.

A partir de aquí, fui iterando en mi proceso habitual de trabajo con agentes de IA: plan - especificación - implementación - testing - despliegue.

Todo el código está disponible en GitHub: https://github.com/dataxbi/fabapp-what-if

Te invito a revisar:

• Las especificaciones: https://github.com/dataxbi/fabapp-what-if/tree/main/docs
• El esquema de la base de datos: https://github.com/dataxbi/fabapp-what-if/tree/main/rayfin/data
• Las consultas DAX: https://github.com/dataxbi/fabapp-what-if/tree/main/src/queries/pl

Continuará…

Gracias por llegar hasta aquí. 😊

En la próxima entrega de la serie te mostraré una herramienta gratuita que te permite crear las Fabric Apps desde una aplicación de escritorio, nada de línea de comando.

Si en el post anterior me di el capricho de regresar por unos momentos a mi niñez para jugar 😉, en este me enfoco más en mostrar el business value que pueden tener las Fabric Apps.

La plantilla Data App de Rayfin

Para comenzar, voy a implementar un cuadro de mando de ventas, a partir de un modelo semántico que ya esta publicado en un área de trabajo de Fabric.

Más adelante hablaré del modelo, porque ahora utilizaré Rayfin para sentar los cimientos de esta Fabric App.

Si quieres seguir cada paso, te recomiendo revisar los requisitos y la forma de trabajar con Rayfin en el post anterior.

Pues si ya tienes todos los requisitos, manos a la obra con la nueva Fabric App.

1. Abre la Terminal y ejecuta el comando npm create @microsoft/rayfin@latest "Hola DAX"
   1. En el menú que aparece, escoge la primera opción: 📦 Use a template (built-in)
   2. Selecciona la segunda template: 2) Data App - Build data analytics app based on your data in Fabric
   3. Espera a que se instalen todos los componentes en la carpeta hola-dax.
2. Cámbiate a la nueva carpeta hola-dax.
3. Ya dentro de la carpeta, abre VS Code con el comando: code .

Vamos a detenernos en este punto para echarle un vistazo a lo que ha instalado esta plantilla. ¡Yo flipé con lo que me encontré!

Por cierto, en esta plantilla si viene deshabilitada la base de datos, por lo que no hay que recurrir al truco que vimos en el primer post para evitar desplegar en Fabric una base de datos SQL que no vamos a utilizar.

A primera vista la estructura de carpetas es similar a la creada por la plantilla que utilizamos en el primer post (Blank App,).

Pero, hay un tesoro frente a nosotros, y para descubrirlo basta con abrir el archivo AGENTS.md.

En Blank App este archivo solo contenía las instrucciones de Rayfin, pero ahora tiene una gran cantidad de instrucciones, dirigidas a implementar una aplicación de datos en el front-end que es capaz de ejecutar consultas DAX en modelos semánticos de Power BI / Fabric.

Aquí tenemos un verdadero framework dividido en varias capas y totalmente preparado para los agentes de IA generativa.

AGENTS.md es solo el inicio, porque luego cada capa tiene su propia SKILL.md. Las puedes encontrar en la carpeta .agents/skills. Muchas de estas SKILLS hacen referencia a módulos que se han instalado en la carpeta node_modules.

Creo que vale la pena revisar los archivos AGENT y SKILLS para comprender el funcionamiento del framework.

Como punto de partida utiliza la documentación oficial: https://learn.microsoft.com/es-es/fabric/apps/data-apps-template

Aquí te dejo un resumen de cada capa:

• Experiencia de aplicación: Responsable de estructurar la aplicación en páginas y de la navegación.

• Presentación visual: Responsable de dibujar gráficos, tablas, paneles y otros controles de UI, además de capturar las interacciones del usuario. Utiliza Vega-Lite para los gráficos y el componente @microsoft/fabric-datagrid para las tablas.

• Orquestación de página: Responsable de conectar la UI con la lógica de filtrado, selección y parámetros que alimentan las consultas DAX.

• Arquitectura de consultas: Responsable de definir qué se consulta, cómo se describe cada visual y qué metadatos acompañan al resultado.

• Acceso a datos runtime: Responsable de ejecutar consultas DAX en el modelo semántico y de su caché. Utiliza el componente @microsoft/fabric-app-data

• Modelo semántico: Responsable de aportar medidas, dimensiones, relaciones y metadatos del modelo publicado en Fabric/Power BI.

• Transformación de datos: Responsable de convertir la respuesta cruda de las consultas DAX en un formato visual consumible y enriquecido.

• Diseño y temas: Responsable de los colores, la tipografía, el branding y la consistencia visual entre componentes.

• Validación y calidad: Responsable de comprobar el comportamiento de la aplicación. Realiza tests y validación real utilizando Playwright CLI.

• Plataforma · Rayfin / Fabric embed: Responsable de desplegar la aplicación en Fabric, de la autenticación y la configuración del entorno.

Con estas capas no solo podemos implementar la aplicación, sino que además nos permiten descubrir las estructura del modelo semántico y probar las consultas DAX antes de utilizarlas, hacer testing una vez implementada la aplicación, y desplegarla en Fabric.

Hola DAX

Como hemos visto, este framework está muy bien preparado para los agentes de IA. Así que vamos a continuar implementando el cuadro de mando de ventas con la ayuda de nuestra herramienta de IA preferida. En mi caso he utilizado indistintamente GitHub Copilot CLI y Codex CLI.

Antes de continuar, te recomiendo que le pidas al agente que compruebe si se puede conectar a Fabric y con cuál usuario lo está haciendo, para evitar que esté utilizando un usuario incorrecto.

O también lo puedes hacer directamente en la terminal con el comando npx rayfin login status y así te ahorras un par de tokens.

Cuando trabajo con agentes de IA en un proyecto lo primero que hago es configurar GIT, para mantener la historia de todos los cambios. Y he hecho un primer commit justo después de instalar la plantilla.

Lo siguiente que hago es elaborar un plan inicial, con la ayuda de la herramienta de IA, que guardo en un archivo de especificaciones y en archivos con las diferentes tareas. Una vez que las especificaciones están revisadas y corregidas por mí, hago un commit, y le pido al agente que lo implemente.

Para elaborar el plan para una Data App (esta plantilla) hay que tener en cuenta el flujo de trabajo que seguirán los agentes, como se describe en el archivo AGENTS, y que tiene tres fases:

1. Fase de diseño y creación de consultas: Exploración de los datos y validar las consultas. En esta fase todavía no se escribe código de la aplicación.
2. Fase de diseño de la aplicación: Diseño de la experiencia de usuario (UX) de la aplicación web antes de escribir cualquier código de ejecución.
3. Fase de desarrollo de la aplicación: Implementación de los componentes que obtienen los datos en tiempo de ejecución utilizando el SDK de Fabric.

Como parte del plan hay que indicar la URL del modelo semántico en Fabric, que tiene un formato como este: https://app.fabric.microsoft.com/onelake/details/id-area-trabajo/dataset/id-modelo-semantico

Esta información le servirá a los agentes para para configurar la aplicación.

El modelo de ventas con el que trabajé tiene la estructura mostrada en la siguiente imagen, y las medidas [Facturacion], [Margen] y [% Margen].

Como punto de partida del plan utilicé un prompt bastante abierto:

Construir una Fabric App ejecutiva sobre el modelo semántico Ventas (https://app.fabric.microsoft.com/onelake/details/id-area-trabajo/dataset/id-modelo-semantico) para ofrecer una visión resumida del negocio y páginas de detalle que permitan profundizar en los principales ejes comerciales.

Las únicas indicaciones de diseño que incluí fueron que utilizara el logo y el tono visual de nuestro sitio web, y que los formatos de fechas y números fueran los de España.

El agente se encargó de conectarse al modelo para descubrir las tablas y medidas y me propuso un informe con cuatro páginas:

• Overview
• Regiones
• Portafolio comercial
• Clientes

Continué iterando hasta tener un plan completo que puedes ver en GitHub: https://github.com/dataxbi/fabapp-hello-dax/blob/main/docs/especificacion-cuadro-mando-ventas.md

Durante la ejecución del plan por parte del agente se puede observar como utiliza las diferentes skills y herramientas para crear las consultas DAX que utilizará en cada visual y para probarlas antes de incluirlas en la aplicación.

Y una vez que termina de implementar la aplicación ejecuta comandos como npm run test, npm run build y npm run lint que son propios del flujo de desarrollo de aplicaciones front-end.

Al final, el agente ejecuta la Fabric App localmente y hace validaciones utilizando Playwright CLI. Aquí me falló algunas veces porque el back-end de la aplicación no se publicaba en Fabric la primera vez.

Para desplegar la aplicación completa en Fabric, se lo puedes pedir al agente o, si te quires ahorrar unos tokens, utilizar directamente el comando npx rayfin up.

Ten en cuenta que, por ahora, las Fabric Apps que se conectan a un modelo semántico solo se pueden abrir dentro del portal Fabric, no lo pueden hacer de manera independiente como vimos en el primer post. Esto se debe a que la autenticación está implementada de una manera que depende de funcionalidad presente en el portal de Fabric. Pero esto debe cambiar en el futuro.

La primera versión de la aplicación salió bastante bien, pero no cargaba datos en las tablas, así que le pedí a mi agente que revisara y corrigiera.

También tuve que pedirle mejoras en la parte visual, sobre todo en la coherencia, porque utilizó colores diferentes en los gráficos.

Pienso que estos resultados iniciales podrían haber sido mejores si hubiera incluido más detalles de diseño en la especificación y hubiera utilizado otro modelo de LLM. Aquí he utilizado GPT 5.4.

Así luce la Fabric App:

Todo el código esta en GitHub: https://github.com/dataxbi/fabapp-hello-dax

Cross-filter

Aún no hemos terminado con este primer ejemplo, porque esta versión inicial no tiene cross-filter entre los visuales, a pasar de que el framework de Data App viene preparado para implementarlo. Aquí también influyen dos factores: 1) la especificación, donde no mencioné que se implementara cross-filter, y 2) el modelo de LLM que estoy utilizando.

Bueno, para implementarlo seguí el mismo proceso de planificar primero y que el agente implemente después, enriqueciendo mi propuesta con las sugerencia del modelo LLM.

El resultado puedes verlo a continuación. Además de aplicar el filtrado entre visuales, hay un panel en la página que muestra los filtros aplicados y botones para limpiarlos.

Panel de filtros dinámicos

Llegados a este punto, me vine un poco arriba, y quise ir un poco más allá, para poner a prueba los límites de lo que se puede hacer.

Con la ayuda de los agentes de IA he implementado un panel de filtros dinámicos, que trabaja de la siguiente manera:

• Al cargar la página utiliza las funciones INFO de DAX para encontrar las dimensiones del modelo semántico, descartando las tablas y columnas ocultas.
• Agrupa cada dimensión por su tipo de dato: texto, numérico o fecha.
• Crea en la página web un panel de filtros con un control específico para cada tipo de dato.
  • Para los números utiliza un rango con mínimo y máximo.
  • Para las fechas utiliza un rango con calendarios.
  • Para los textos utiliza una lista desplegable, pero los datos solo se cargan en el momento en que se abre el filtro.

Para implementar estos controles le pedí en la especificación que utilizara la librería de código abierto shadcn/ui.

Con esto he extendido la funcionalidad que trae el framework de la plantilla Data App, pero solo para esta aplicación.

Para reutilizar este panel de filtros dinámico en otros proyectos, debería haber creado una SKILL. Algo que no descarto hacer en el futuro.

Informe PyG

Para el segundo ejemplo he utilizado otro modelo semántico, esta vez de finanzas, que tiene la estructura que muestro en la imagen y con medidas como [Gastos], [Ingresos], [Presupuesto], [Variacion]

Creé un nuevo proyecto con la plantilla Data App y seguí el mismo proceso que he explicado antes.

Esta vez fuí más explicito al crear la especificación:

Construir una Fabric App ejecutiva sobre el modelo semántico de P&L para ofrecer una visión del resultado económico del negocio con una tabla detallada y tarjetas resumen, usando componentes propios en React.

Puedes leer el texto completo aquí: https://github.com/dataxbi/fabapp-dax-finance/blob/main/docs/especificacion-informe-pl.md, que es el resultado de varias iteraciones.

El fragmento de la especificación termina diciendo “… usando componentes propios…” y si abres la especificación completa verás que en el stack de visuales se indica que para la tabla utilice un componente propio basado en @tanstack/react-table que es una librería de código abierto.

Además, he modificado la SKILL de la capa visual para que al dibujar tablas se utilice este componente en lugar del original de la plantilla Data App.

Y también he cambiado las instrucciones para construir las tablas.

Todo el código está en GitHub: https://github.com/dataxbi/fabapp-dax-finance

Y el resultado lo puedes ver en este clip:

Cuadro de mando multi modelo

El tercer ejemplo lo que tiene de novedoso es que combina datos y métricas de los dos modelos de ventas y de finanzas, para hacer un cuadro de mando ejecutivo para la dirección general.

De nuevo creé un proyecto con la plantilla Data App, y seguí el mismo proceso: plan - especificación - implementación - testing - despliegue, a través de varias iteraciones.

La especificación final comienza de esta manera:

Construir un dashboard ejecutivo para Dirección General sobre dos modelos semánticos de Microsoft Fabric, ventas y finanzas.

El dashboard debe presentar una vista clara del negocio con KPIs, comparativa inter anual y al menos un gráfico temporal que combine medidas de ambos modelos mediante su dimension común de fecha.

Puedes ver el texto completo aquí: https://github.com/dataxbi/fabapp-dax-multi-model/blob/main/docs/especificacion-general.md

Los modelos semánticos siguen estando separados en Fabric, la mezcla de los datos ocurre en el front-end, luego de hacer consultas DAX independientes para cada modelo.

Todo el código está en GitHub: https://github.com/dataxbi/fabapp-dax-multi-model

Y el resultado lo puedes ver en este clip:

Continuará…

Este post me ha salido un poco largo, así que te agradezco si has llegado hasta aquí. 👏

Mi objetivo ha sido mostrar las posibilidades de la plantilla Data App y cómo se puede personalizar y extender.

He creado algunos ejemplos que me han parecido interesantes con la esperanza de dejarte con ganas de probar y de innovar.

Recuerda que todo lo que hemos visto hoy ocurre en el front-end de la aplicación web.

La próxima entrega de la serie estará dedicada como hacer Fabric Apps para gestionar una base de datos SQL en Fabric.

¿Qué es una Fabric App?

En esencia, una Fabric App es una aplicación web que se hospeda en un área de trabajo de Fabric.

Como toda aplicación web, está formada por un front-end que se ejecuta en un navegador en tu ordenador, y un back-end que en este caso se ejecuta en Fabric.

En el front-end tenemos casi total libertad para implementar lo que se nos ocurra.

Mientras que en el back-end estamos limitados a utilizar los servicios que se nos permitan, que por ahora son dos: autenticación y base de datos Fabric SQL.

Para gestionar los servicios del back-end y la publicación de la aplicación en Fabric debemos utilizar Rayfin, un proyecto de código abierto desarrollado por Microsoft.

Con estos elementos tenemos todo lo necesario para construir, con la ayuda de agentes de IA generativa, un cuadro de mando que se conecte a un modelo semántico de Power BI, o incluso a varios.

También podemos implementar una aplicación para gestionar una base de datos Fabric SQL.

O una aplicación que combine las dos anteriores.

Las posibilidades son infinitas. Pero vayamos paso a paso.

En este post me centraré en lo más básico y mostraré tres ejemplos que utilizan únicamente el front-end.

En realidad, lo único que tienen de Fabric Apps es que están publicados en Fabric.

Hola mundo

Voy a comenzar mostrando paso a paso como crear una Fabric App minimalista, formada con una sola página y sin ninguna base de datos.

1. Requisitos antes de comenzar:
   1. Que un administrador de Fabric haya activado la opción: Habilitar elementos de aplicación de Fabric (versión preliminar)
   2. Tener acceso a un área de trabajo con capacidad Fabric.
   3. Instalar Node.js en tu ordenador, que se puede descargar desde https://nodejs.org/
   4. También te recomiendo instalar Visual Studio Code, si es que aún no lo tienes.

2. Rayfin trabaja en la línea de comandos, por lo que debes abrir la aplicación Terminal de Windows. Una manera de hacerlo es con la combinación de teclas Windows + R y luego escribe wt y pulsa Enter.

3. Para crear la Fabric App, dentro de la terminal ejecuta este comando: npm create @microsoft/rayfin@latest “Hola Mundo”, que creará la carpeta hola-mundo con la estructura de un proyecto Rayfin e instalará varias librerías.
   1. En el menú que aparece, escoge la primera opción: 📦 Use a template (built-in)
   2. Selecciona la primera template: 1) Blank App - Bare-bones Fabric-authenticated React + Vite app — sign-in, routing, and a placeholder home page, with no data layer to remove
   3. Espera a que se instalen todos los componentes en la carpeta hola-mundo.

4. Cámbiate a dicha carpeta: hola-mundo

5. Ya dentro de la carpeta, ejecuta el comando: npm run dev
   1. Este comando te permite probar la Fabric App en tu ordenador antes de la publicación definitiva en Fabric. Aunque actualmente necesita publicar una parte de la aplicación en Fabric para que funcione la autenticación.
   2. Escribe el nombre del área de trabajo donde quieres publicar la Fabric App.
   3. Espera hasta que termine de prepararse todo.
   4. Al finalizar la preparación, en la terminal debe aparecer un texto similar a este: Local: http://localhost:5173, que significa que hay un pequeño servidor web en tu ordenador listo para probar la Fabric App.
   5. Para abrir el link (http://localhost:5173) puedes pasar el cursor sobre él y utilizar la combinación Ctrl + clic.
   6. Primero te pedirá autenticarte con sus credenciales de Fabric, si no estás autenticado ya.
   7. A continuación te aparecerá una página con el texto “Hello, World”.
6. Una vez superada la prueba local estamos listos para desplegar la Fabric App para que se pueda utilizar por otros usuarios.
   1. Regresa a la terminal y, situado en la carpeta hola-mundo, ejecuta el comando: npx rayfin up
   2. Esto despliega en Fabric la versión definitiva de la Fabric App.
   3. Si vas al área de trabajo verás que hay un elemento con el nombre hola-mundo.
   4. Hay dos maneras de acceder a la Fabric App:

      • Utilizando un URL como este: https://app.fabric.microsoft.com/groups/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/appbackends/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx

        Para navegar a este URL basta con hacer clic en el elemento dentro del área de trabajo.

        La Fabric App se ve dentro del portal de Fabric.

      • Utilizando un URL como este: https://xxxxxxxxxxxxxxxxxxxxx-westeurope.webapp.fabricapps.net/

        Este URL se puede ver en los mensajes que imprimió en la pantalla el comando que ejecutamos para publicar: npx rayfin up

        La Fabric App se ve como una aplicación web independiente, sin los elementos de Fabric.

        En ambos casos es necesario autenticarse con un usuario de Fabric.

¡Felicidades! Has creado tu primera Fabric App.

Pero, aún no hemos terminado este primer ejemplo. Porque te había prometido que no utilizaríamos una base de datos, y de hecho no la estamos usando, pero si se está creando una en Fabric.

Si entras al área de trabajo de Fabric verás que bajo el nuevo elemento hola-mundo hay una base de datos SQL y su punto de conexión de SQL analítico. 😯 Y eso que escogimos una template with no data layer. Pero parece que ya crean la base de datos aunque esté vacía por si más tarde cambiamos de idea.

Pero esto tiene una solución muy fácil, que consiste en modificar un archivo de configuración de Rayfin.

Para demostrarlo, vamos a crear otra Fabric App con el nombre “Hola Mundo 2”.

Repite los pasos 2 y 3 anteriores, pero usando en el paso 3 el comando npm create @microsoft/rayfin@latest “Hola Mundo 2” (lo único que cambia es el 2 al final).

Todavía no pruebes la nueva Fabric App, ni mucho menos la despliegues.

Antes has lo siguiente:

• Cámbiate a la carpeta: hola-mundo-2
• Ejecuta el comando code . para entrar a VS Code con la carpta abierta.
  • Ya en VS Code abre la subcarpeta rayfin
    • Dentro de la subcarpeta, abre el archivo rayfin.yml
    • En el archivo busca la línea 14 y cambia true por false.
    • Guarda los cambios (Ctrl + s)

Ahora sí, prueba la Fabric App y luego despliégala siguiendo los pasos 5 y 6. Utiliza la misma área de trabajo.

Una vez desplegada, revisa el área de trabajo y debes ver el nuevo elemento hola-mundo-2, pero en solitario, sin la base de datos SQL 😊.

Yo he hecho una versión del “Hola Mundo” en la que además de deshabilitar la base de datos, he modificado algunos detallitos del sitio web generado por la plantilla para poner el texto en español y añadir una imagen y un ícono.

Todo el código lo he compartido en un repositorio de GitHub: https://github.com/dataxbi/fabapp-hello-world

Rayfin y los agentes de IA

Rayfin viene preparado para los agentes de IA generativa, lo que puedes comprobar revisando el código de las Fabric Apps en tu ordenador, o en el repositorio que te compartí con mi “Hola Mundo”.

• Archivo AGENTS.md

• Archivo SKILL.md

  Esta skill puede acceder a la documentación de dos maneras:

  • Con un MCP Server, si se ha configurado: https://github.com/microsoft/rayfin/tree/main/packages/tools/mcp
  • Utilizando Rayfin CLI en la línea de comandos, que se instala cuando generamos el sitio web utilizando la template.

Para mostrar cómo trabaja, he utilizado GitHub Copilot CLI en la carpeta de mi “Hola Mundo” y le he pedido lo siguiente:

confirma si la última versión de la fabric app está publicada en fabric en qué área de trabajo y con cual urls puedo acceder

El resultado lo puedes ver en la imagen, donde se aprecia como:

• Ha utilizado la skill de Rayfin.
• Ha comparado la fecha del último despliegue en Fabric con el último commit en GIT.
• Muestra el nombre y el ID del área de trabajo y si la aplicación está disponible.
• Muestra la URL para acceder a través del portal de Fabric y la URL pública.

Fabric Invaders

En el ejemplo “Hola mundo” los cambios fueron muy sencillos y los hice yo mismo, sin la ayuda de la IA.😉

El segundo ejemplo que te quiero compartir lo he hecho con agentes de IA utilizando GitHub Copilot CLI, aunque no se han utilizado las instrucciones ni la skill de Rayfin porque los cambios solo afectan al front-end.

He implementado un juego del tipo Space Invaders pero utilizando los magníficos íconos de Microsoft Fabric para Excalidraw creados y mantenidos por Miles Cole.

A esta nueva Fabric App le he llamado Fabric Invaders y para crearla he seguido los mismos pasos que en mi “Hola Mundo” y luego:

• He descargado el archivo con los íconos de Fabric desde el sitio de Excalidraw hacia la carpeta src/assets de la Fabric App.
• He utilizado el modo plan de GitHub Copilot CLI para crear una especificación para el juego, indicándole el stack técnico, donde encontrar los íconos de Fabric y pidiéndole explícitamente que no toque los archivos de Rayfin porque las modificaciones deben ser solo en el front-end.
• Una vez que he considerado que la especificación está lista, le he pedido a GitHub Copilot CLI que cree un plan a partir de ella y que proceda a implementar.

El primer resultado me dejó impresionado porque el juego funcionó perfectamente.

Hice algunas iteraciones más para añadirle sonido, incluir un logo y optimizar la carga de los archivos del front-end.

Si quieres revisar el código o probarlo por ti mismo, está en GitHub: https://github.com/dataxbi/fabapp-fabric-invaders

• Este es el archivo AGENTS.md modificado para hacer referencias a la especificación del juego: https://github.com/dataxbi/fabapp-fabric-invaders/blob/main/AGENTS.md
• Esta es la especificación: https://github.com/dataxbi/fabapp-fabric-invaders/blob/main/docs/SPEC.md
• Y en el historial de commits puedes ver las iteraciones: https://github.com/dataxbi/fabapp-fabric-invaders/commits/main/

Pokémon Hunter

Mi intención con el ejemplo anterior ha sido mostrar que tenemos libertad para ser creativos en el front-end.

En este último ejemplo quiero poner a prueba esa libertad, llamando a una API REST que no tenga nada que ver con Fabric.

La última Fabric App de este post se llama Pokémon Hunter y es una versión del juego anterior, pero sustituyendo los íconos de Fabric por imágenes de pokémon y la nave espacial por la cazadora Pokémon J.

La imagen de la cazadora es estática y la he descargado a la carpeta src/assets de la Fabric App.

Pero las imágenes de los pokémon no están guardadas en la aplicación, sino que se obtienen dinámicamente a través de la PokéAPI.

Cada vez que comienza una partida se llama a la PokéAPI para obtener los URLs con las imágenes de 20 pokémons de manera aleatoria.

Este es el repositorio con el código: https://github.com/dataxbi/fabapp-pokemon-hunter

• AGENTS.md: https://github.com/dataxbi/fabapp-pokemon-hunter/blob/main/AGENTS.md
• Especificaciones: https://github.com/dataxbi/fabapp-pokemon-hunter/blob/main/docs/SPEC.md
• En la historia de commits se puede apreciar que para este último ejemplo partí de clonar el repo de Fabric Invaders.

Esta API es sencilla y no requiere autenticación, por lo que no hay ninguna dificultad al llamarla desde el front-end.

Pero, para utilizar una API que requiera autenticación hay que ser cuidadoso de no exponer credenciales.

Continuará…

En los tres ejemplos que te he mostrado, Fabric no pinta casi nada. De hecho, estas aplicaciones web se podrían haber implementado sin Rayfin y desplegarlas en cualquier sitio web.

Lo único que hemos ganado con Rayfin es poderlas desplegar en un área de trabajo de Fabric y controlar el acceso.

En próximas entregas de esta serie sí utilizaremos elementos de Fabric.

Es una continuación de los dos post anteriores (post 1, post 2), pero esta vez no se han ejecutado consultas T-SQL sino consultas DAX sobre modelos semánticos Direct Lake en OneLake.

Para realizar estas pruebas se ha creado una nueva área de trabajo con capacidad Fabric de prueba F64.

Al igual que en los posts anteriores he contado con la valiosa ayuda de GitHub Copilot CLI, con el mismo flujo de trabajo que he explicado en el primer post de la serie.

El código y las instrucciones las puedes consultar en el repositorio en GitHub https://github.com/dataxbi/fablab-direct-lake.

Preparación de los datos

Se crearon 6 modelos semánticos en modo de almacenamiento Direct Lake en OneLake, a partir de los datos y escenarios (esquemas) utilizados en los posts anteriores.

En el listado anterior hay una nota indicando que para el último modelo semántico falló el refresco de los datos, que en el caso de Direct Lake es en realidad el enmarcado (framing) y que consiste en actualizar solo los metadatos de las tablas Delta. La causa del fallo es que en el escenario del lakehouse fragmentado la tabla de hechos tiene muchos archivos Parquet pequeños (29.000 archivos 😢), por lo que está muy por encima del límite para una capacidad F64 que son 5.000 archivos Parquet por tabla Delta. Por tanto, este modelo se excluyó de las pruebas.

Sin embargo, esto no sucede en el modelo semántico que utiliza las tablas fragmentadas del warehouse y la razón es que en este caso Fabric se encarga de ejecutar OPTIMIZE automáticamente, por lo que se agruparon varios archivos Parquet en uno solo. En una investigación que hice con la ayuda de Copilot encontré que en el warehouse los archivos Parquet se redujeron de casi 29.000 a 149 😎.

Todos los modelos semánticos tienen la misma estructura, que se muestra en la imagen. En el repositorio de GitHub está la definición en TMDL.

Consultas DAX

Las consultas DAX que se utilizaron para medir el rendimiento se crearon a partir de las consultas T-SQL de las pruebas anteriores, que a su vez están inspiradas en consultas de TPC-DS.

• Q1 — Agregación simple: https://github.com/dataxbi/fablab-direct-lake/blob/main/dax/q01_simple_agg.dax

• Q2 — Join grande (star schema): https://github.com/dataxbi/fablab-direct-lake/blob/main/dax/q02_large_join.dax

• Q3 — Top N con filtros selectivos: https://github.com/dataxbi/fablab-direct-lake/blob/main/dax/q03_top_n_selective.dax

• Q4 — Query compleja tipo TPC-DS real: https://github.com/dataxbi/fablab-direct-lake/blob/main/dax/q04_complex_tpcds.dax

• Q5 — Función ventana analítica: https://github.com/dataxbi/fablab-direct-lake/blob/main/dax/q05_window_function.dax

Para crear las consultas DAX, utilicé primero el modelo Claude Opus 4.7 para traducir las consultas T-SQL. Luego cambié al modelo GPT-5.5 y le pedí que las revisara. Y finalmente las revisé yo.

Ambos modelos LLM se conectaron a uno de los modelos semánticos para validar que las consultas se ejecutaban bien. Esta ejecución sirvió para detectar que en una de las consultas había un filtro con un valor que no existía en la dimensión, y fue corregido por Claude Opus. En la revisión hecha por GPT sugirió cambiar un FILTER dentro de un SUMMARIZECOLUMNS por un TREATAS, lo que me pareció muy bien.

En mi revisión lo único que encontré fue un par de SUMMARIZE donde se añadían directamente columnas con expresiones y lo cambié por ADDCOLUMNS / SUMMARIZE.

Pruebas realizadas

Para las pruebas se creó un script que utiliza la API REST de Power BI para hacer lo siguiente:

• Refrescar los 5 modelos semánticos para asegurar que no haya datos cargados en memoria.
• Ejecutar una vez las 5 consultas DAX en cada uno de los 5 modelos semánticos. (Ejecución en frío.)
• Ejecutar 3 veces las 5 consultas DAX en cada uno de los 5 modelos semánticos. (Ejecución en caliente.)

En total se hicieron 100 ejecuciones de las consultas DAX.

Los resultados de estas pruebas se guardaron en archivos CSV.

También se creó un notebook Python para analizar los resultados de estas ejecuciones.

Resultados

👇 El primer resultado es la comparación del tiempo de ejecución de las consultas en frío (barras izquierdas, azules) vs. la mediana del tiempo de ejecución de las consultas en caliente (barras derechas, naranjas) para cada uno de los 5 modelos semánticos.

Aquí resalta lo obvio: Las consultas en frío son más lentas en todos los casos.

👇 En el segundo gráfico se analizan solo las ejecuciones en caliente, mostrándose para cada consulta DAX la mediana de las 3 ejecuciones en cada uno de los 5 modelos semánticos.

Dentro de cada consulta los tiempos son bastante parecidos en 4 de los modelos y sólo hay una diferencia notable en el modelo que utiliza las tablas del lakehouse con V-Order, que es el más lento. Este resultado me ha sorprendido porque esperaba que el V-Order ayudara en la transcodificación del formato Parquet a VertiPaq, pero al parecer no ha ocurrido así. Es algo que hay que analizar más a fondo y puede que tenga que ver con el tamaño de los archivos Parquet y de los grupos de filas dentro de estos.

El comportamiento del modelo semántico que utiliza los datos del warehouse fragmentado es similar al resto y esto se debe a la optimización automática que expliqué antes.

👇 Para finalizar muestro el tiempo de las 3 ejecuciones en caliente para cada una de las 5 consultas DAX en los 5 modelos semánticos.

Me llama un poco la atención que en los tres escenarios del lakehouse (gráficos de arriba) se aprecia que para cada consulta, con cada repetición mejora el rendimiento. Sin embargo, en los dos escenarios del warehouse (gráficos de abajo) casi que ocurre lo contrario.

En el caso del lakehouse con V-Order (tercer gráfico de arriba) hay una mejora apreciable en la tercera repetición.

Como ves, este tema todavía da para mucho. Ojalá te anime a hacer tus propias pruebas y a contribuir al repositorio.

Se han utilizado los mismos datos que expliqué en el post anterior y que son un subconjunto de las tablas de TPC-DS, con el factor de escala SF100.

También he contado con la valiosa ayuda de GitHub Copilot CLI, y en el post anterior explico el flujo de trabajo que he seguido.

Todo el código, los datos y las instrucciones las puedes consultar en el repositorio en GitHub https://github.com/dataxbi/fablab-sql-endpoint.

Preparación de los datos

Esta vez se ha creado un nuevo esquema en el lakehouse y otro en el warehouse, ambos con el mismo nombre: benchmark_frag.

Las tablas de dimensiones se han copiado desde el esquema benchmark_default, explicado en el post anterior, usando consultas CREATE TABLE AS SELECT (CTAS). En el lakehouse se ha utilizado Spark SQL y en el warehouse T-SQL.

La tabla de hechos store_sales es la que se ha fragmentado en archivos Parquet muy pequeños, de 10.000 filas cada uno. Por lo que para alcanzar las casi 288 millones de filas se han creado unos 29.000 archivos Parquet.

⚠️ Este proceso de fragmentación lo estoy haciendo para estas pruebas, pero en un proyecto real por lo general se hace todo lo contrario. 😉

El proceso de fragmentación fue diferente en cada elemento de almacenamiento.

En el lakehouse se partió de la tabla store_sales del esquema benchmark_default y se copiaron sus datos en una tabla con el mismo nombre pero en el nuevo esquema benchmark_frag, con sobrescritura y lo más importante, con la opción maxRecordsPerFile.

MAX_RECORDS_PER_FILE = 10000

spark.table("benchmark_default.store_sales")
    .write
    .format("delta")
    .mode("overwrite")
    .option("overwriteSchema", "true")
    .option("maxRecordsPerFile", str(MAX_RECORDS_PER_FILE))
    .saveAsTable("benchmark_frag.store_sales")

La imagen muestra un fragmento del delta_log de la tabla Delta creada en el lakehouse, donde se puede apreciar que en una misma transacción se han creado todos los archivos Parquet y que cada uno contiene 10.000 filas.

En el warehouse se utilizó una estrategia diferente porque en T-SQL no hay una opción equivalente a maxRecordsPerFile.

Se partió del archivo CSV con los datos de la tabla store_sale, cuya generación se explicó en el post anterior. Este se dividió en archivos CSV con 10.000 filas cada uno, obteniendo casi 29.000 archivos CSV. Los archivos se compactaron, se subieron a una carpeta del lakehouse y se descompactaron.

Se creó la tabla store_sale en el esquema benchmark_frag del warehouse.

Se utilizó el comando T-SQL COPY INTO para insertar los datos desde los archivos CSV en el lakehouse hacia la tabla en el warehouse.

COPY INTO benchmark_frag.store_sales
FROM <FILE_URL>
WITH (FILE_TYPE = 'CSV', FIELDTERMINATOR = '|')

Para optimizar la copia, se creó un script que utiliza el driver ODBC de SQL Server para conectarse al warehouse desde mi ordenador, y que implementa un mecanismo para ejecutar varias consultas COPY INTO en paralelo.

Las inserciones no se han hecho dentro de una misma transacción por lo que en la tabla Delta se ha creado un delta_log por cada archivo Parquet que se ha creado. En la figura se ve el contenido de uno de estos delta_log.

Pruebas realizadas

Para medir el rendimiento se han utilizado las mismas 5 consultas T-SQL que en el post anterior, inspiradas en consultas del TCP-DS:

• Q1 — Agregación simple: https://github.com/dataxbi/fablab-sql-endpoint/blob/main/sql/q01_simple_agg.sql

• Q2 — Join grande (star schema): https://github.com/dataxbi/fablab-sql-endpoint/blob/main/sql/q02_large_join.sql

• Q3 — Top N con filtros selectivos: https://github.com/dataxbi/fablab-sql-endpoint/blob/main/sql/q03_top_n_selective.sql

• Q4 — Query compleja tipo TPC-DS real: https://github.com/dataxbi/fablab-sql-endpoint/blob/main/sql/q04_complex_tpcds.sql

• Q5 — Función ventana analítica: https://github.com/dataxbi/fablab-sql-endpoint/blob/main/sql/q05_window_function.sql

Se extendió el script explicado en el post anterior, para poder ejecutar estas consultas sobre las tablas de los nuevos esquemas benchmark_frag.

En este caso todas las consultas se hicieron en caliente, sin pausar la capacidad Fabric. Y se utilizó una capacidad Fabric F64 de pruebas.

Se ejecutaron 3 repeticiones de cada consulta en los 6 esquemas: los cuatro que se explicaron en el post anterior, y los los dos nuevos benchmark_frag.

En total se hicieron 90 ejecuciones.

Los resultados de estas pruebas se guardaron en archivos CSV para poder analizarlos.

Resultados

A continuación muestro tres imágenes con los resultados de las pruebas.

👆La primera imagen contiene dos gráficos de columnas con el tiempo de las 3 ejecuciones de cada consulta sobre las tablas fragmentadas (esquema benchmark_frag) del warehouse (gráfico de la izquierda) y el lakehouse (gráfico de la derecha).

De primeras se aprecia que las consultas del lakehouse tardaron más que las del warehouse. Y si prestamos más atención al eje Y, nos daremos cuenta que la escala es logarítmica, por lo que la diferencia es aún mayor que lo que muestran las columnas. Como referencia, la consulta que más tardó en el warehouse fue de 14 segundos, mientras que la que más tardó en el lakehouse fue de 147 segundos.

También hay que destacar cómo la consulta Q04 va mejorando el rendimiento en cada repetición, y esto sucede en ambos elementos de almacenamiento.

👆 La segunda imagen es un gráfico de columnas, también con escala logarítmica, donde se compara la mediana de las 3 repeticiones de cada consulta en las tablas fragmentadas (esquema benchmark_frag) entre el warehouse (izquierda, azul) y el lakehouse (derecha, naranja). Se aprecia claramente como el warehouse tiene un rendimiento que es varios órdenes de magnitud superior al del lakehouse, llegando a ser hasta 29 veces más rápido (consulta Q03).

La excepción es la consulta Q04 que ya vimos en el primer gráfico que mejora mucho el rendimiento luego de la primera repetición, por lo que al considerar la mediana en este gráfico no hay casi ninguna diferencia entre el lakehouse y el warehouse.

👆 La última imagen es otro gráfico de columnas con escala logarítmica que compara la mediana de las ejecuciones de las 5 consultas en todos los escenarios de este post y del anterior.

Aquí se aprecia claramente que el lakehouse fragmentado (naranja, derecha) es el de peor rendimiento, excepto en la consulta Q04.

Conclusión

La principal conclusión que podemos extraer de estas pruebas es algo bastante conocido: las tablas Delta no rinden bien cuando contienen muchos archivos de datos de pequeño tamaño. Es por esa razón que en un lakehouse debemos encargarnos de su mantenimiento utilizando los comandos OPTIMIZE y VACUUM, junto a otras técnicas.

Por otra parte, aunque un warehouse también utiliza tablas Delta, hay procesos automáticos que se encargan del mantenimiento.

Si quieres profundizar sobre el mantenimiento y optimización de las tablas Delta, te dejo un artículo de la documentación oficial: https://learn.microsoft.com/es-es/fabric/fundamentals/table-maintenance-optimization