#fabric training

[ibarrau]

Fabric Notebooks obtener datos por red virtual con ip único

Siempre hay un detalle que puede complicar un proyecto de ingeniería de datos, especialmente cuando tenemos que trabajar con APIs limitadas o hay políticas de seguridad que requieren que los datos viajen por canales seguros.

En este artículo te mostramos como podemos acceder desde Fabric Notebooks a un origen de API por un canal seguro e IP pública única.

Si hay algo en lo que estamos de acuerdo es que conectarse a una API compleja siempre será más robusto y flexible hacerlo por código. Si estamos en Fabric, probablemente elijamos usar notebooks por sobre Pipelines. Los Pipelines están buenísimos, pero si de creación dinámica de token o jwt trata, se puede complicar.

Normalmente, cuando necesitamos canalizar Fabric por un canal seguro podemos usar la nueva feature de VNet Gateway. Sin embargo, ese canal solo funciona para los ítems Dataflow Gen2, Fabric data pipelines, Fabric Copy Job, Fabric Mirroring, Power BI semantic models y Power BI paginated reports. Fabric pensé que siempre necesitaríamos obtener datos desde esos ítems. Nosotros sabemos que obtener datos desde Notebooks puede ocurrir y quedamos frenados.

Para requerimientos de canales de seguridad dedicados por redes privadas, no podríamos ir por esa vía.

Por otro lado, algunos orígenes podrían dejarnos cargar las IPs públicas anunciadas por Microsoft sobre sus servicios. Lametablemente, no siempre es así. Fabric Notebooks puede salir por powerbi o por azure cloud. Lo que genera aproximadamente 150 rangos de IP y más de 600 mil IPs públicas. La carga de estas excepciones es inviable para algunos orígenes de datos.

¿Cómo podemos entonces salir a conectarnos en canal único y seguro? La realidad es que hoy no se puede 100% porque eso requeriría que Fabric Notebooks tengan configuraciones de redes privadas. A modo de alternativa, podemos canalizar que Fabric acceda a otro recurso que si esta configurado en una red. En este ejemplo tenemos una API de acceso restringido a 10 IPs públicas. Para que Fabric Notebooks pueda llegar, necesitaremos ayuda de otros recursos de azure. Primero un proxy que garantice una IP pública única. Segundo una red de privada de comunicación. Tercero un puente que ejecute las llamadas a la API y Fabric pueda comunicarse. La solución sería como muestra la siguiente imagen:

Azure NAT Gateway: es un servicio de traducción de direcciones de red (NAT) totalmente administrado y altamente resistente. Use Azure NAT Gateway para permitir que todas las instancias de una subred se conecten de salida a Internet mientras permanecen completamente privadas

Virtual Networks: permite a los recursos de Azure, como máquinas virtuales (VM) comunicarse de forma segura entre sí, Internet y redes locales

Azure Functions: es una solución sin servidor que le permite crear aplicaciones sólidas mientras usa menos código y con menos infraestructura y menores costos. En lugar de preocuparse de implementar y mantener servidores, puede usar la infraestructura en la nube para proporcionar todos los recursos actualizados necesarios para mantener sus aplicaciones en funcionamiento

Comenzamos creando una red virtual y en su configuración una subred:

Luego se asociará el NAT. También vamos a ir a Delegaciones para delegar a la subred el servicio de Apps de Azure:

Ahora creamos un Azure NAT Gateway asegurándonos que en Outbound IP creemos una IP pública. La clave aquí será asociar la red antes creada en networking:

La asociación debería asignarle a la red la salida nat automáticamente. Podemos validarlo buscando nuestra red y chequeando sus opciones:

Ahora si podemos continuar con nuestra Azure function. Lo primero será saber que solo los planes premium, app service flex consumption van a permitir la salida por red virtual. En nuestro caso iremos por flex consumption porque sabemos que el consumo será bastante reducido. Lo importante aquí es la sección de networking para seleccionar nuestra red virtual y su subred:

Por defecto, solo el tráfico hacia IPs privadas va por la VNet. Para que el tráfico hacia internet (tu API externa) use el NAT Gateway, debes configurar la aplicación para que todo el tráfico salga por la red virtual.

Esto lo vamos a configurar desde el azure functions. Buscamos el menú de configuración y las variables de entorno para configurar la siguiente:

WEBSITE_VNET_ROUTE_ALL = 1

El aplicar reiniciará la Function App para que tome efecto.

No vamos a explicar como se hace una Azure Function. Para ello puede leer la documentación de Microsoft. Pero si podemos mostrar que para probar podemos hacer un muy simple ejemplo con Python que tiene el siguiente código:

A la derecha tenemos los requests para llamar a la API de Azure Functions y el código solo hace un request a la api de ipify que devuelve la ip que la está consultando.

Podemos probarlo ejecutando un request de la azure function super sencillo para ver que la IP que devuelve:

Así comprobamos que coincide con nuestra IP generada en nuestro NAT Gateway:

De este modo hemos generado un túnel para que nuestro Fabric Notebook viajen a buscar datos por una red virtual controlada y segura que sale por una IP única. ¿Podríamos haber usado otro recurso en lugar de azure functions? Si. Podríamos usar Azure Logic Apps o código en un App Service Plan. Elegí functions por su free tier y familiaridad de uso. Además, que sería más práctico tener ahí una función que genere los requests de forma genérica los llamemos desde un notebook.

Espero que les haya servido para conocer un poco más sobre redes, seguridad y obtener datos con Fabric notebooks.

[ibarrau]

[Fabric] Intro VNet Gateway

Tal vez escucharon hablar de que se puede generar un Gateway virtual hoy en día. Lo cierto es que no siempre en los proyectos de datos basta con ir a buscar datos a un origen web o instalar un onpremise Gateway.

La seguridad suele ser una pieza clave y permitir que solo quien corresponda acceda a los datos de forma segura puede ser un tema excluyente en una solución de integración de datos.

En este artículo charlamos de Fabric VNet Gateway. ¿Qué es? ¿Qué hace?

Vamos comenzar nuestro post como nos gusta en LaDataWeb leyendo la definición oficial

Una puerta de enlace de datos de red virtual le permite conectar Azure y otros servicios de datos a Microsoft Fabric y Power Platform. La puerta de enlace le permite comunicarse de forma segura con el origen de datos, ejecutar consultas y transmitir los resultados al servicio de forma segura.

En definitiva, nos permite crear un túnel con una red privada virtual que tengamos en Azure de forma tal que los datos viajen siempre de forma segura por un canal diferenciado de la internet pública.

Nuestro Gateway permitiría a las herramientas de integración de datos (las que tienen un “obtener datos”) pida los datos y los transforme en ese canal seguro. Los ítems de Fabric que pueden utilizar esta característica son Dataflow Gen2, Data Pipelines, Copy Jobs, Reflex, modelos semánticos de Power BI e informes paginados de Power BI.

Veamos gráficamente como sería.

NOTA: Cabe aclarar que para que esto funcione, contamos con una Virtual Network creada administrada en Azure. Esta red debe tener una subred con una delegación al servicio de power Platform:

Veamos cómo proceder desde Fabric. Nos dirigimos al engranaje y abrimos el manejo de puertas de enlace y conexiones. Ahí veremos una opción para la VNet

Fíjense que antes de poder crearlo, hay una restricción en la suscripción y es prender una configuración para que el servicio Microsoft:PowerPlatform sea un proveedor de la suscripción.

https://learn.microsoft.com/en-us/data-integration/vnet/create-data-gateways#step-1-register-microsoftpowerplatform-as-a-resource-provider

Tras corregir eso podemos completar los valores de la suscripción hasta la subred que vive en azure.

Ahora si podemos comunicarnos con recursos que estén asegurados en redes virtuales independientes y separadas del tráfico público. Pueden pensar a esto como un gateway on premise. Cuando se conectan a un origen y ponen la dirección, pueden delimitar esta VNet en el apartado de Gateway para llegar a conectar a esa base de datos que estaba en una red virtual o a ese origen que debía salir por dicha red:

Esto también podría servirnos para ir a un origen de datos externo que solo permite IP públicas únicas para conetarse. Azure dispone una cantidad muy amplias de IPs para sus servicios pero si nuestro origen lo limita a pocas IP, esta solución junto a un NAT Gateway en Azure (quien restringe el tráfico de una red virtual a una sola dirección pública) serían una potente solución.

Repaso Sobre las Fabric VNet Gateway

Es una oferta de seguridad de red eficaz. Se puede usar con puntos de conexión privados para orígenes de datos de Azure para asegurarse de que ningún tráfico se expone nunca a un punto de conexión público.

Proporciona aislamiento de cómputo que mejora la seguridad contra ataques entre inquilinos.

Como nota adicional, cuando usamos Fabric Capacity, Microsoft recomienda usar F8 y versiones posteriores para tener un mejor funcionamiento, aun que funciona en todas las SKU.

Espero que les sirva para conocer más sobre seguridad y canales de redes virtuales en conexión de datos.

[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] Protegé la experiencia de usuarios en una capacidad

Cada día más y más personas se suman a la ola de Fabric. Gracias a su amplia variedad de planes permite a pequeñas y grandes empresas nutrirse de sus características desde tempranas etapas. Algo primordial al momento de construir servicios o contenido en un recurso dedicado es monitorear esa capacidad.

¿Por que lo hacemos? porque necesitamos asegurarnos que sus recursos sean viables y no se sobrecargue. Si hay una sobrecarga todo se vuelve lento, la experiencia de usuario cae dado que no logramos dar respuesta a sus peticiones por fallas o demoras.

En este artículo mostraremos como mantener la experiencia de usuario sana aunque los procesos operativos colapsaran.

Hace unos días escribimos sobre la importancia de mantener una capacidad sana y hemos mencionado formas de montiorearla/administrarla. Ambos artículos son una gran fuente de aprendizaje para velar por un espacio dedicado que respondas a las necesidades de los usuarios con los recursos disponibles.

En estos artículos hacemos mención sobre dos categorías de operaciones que utiliza la capacidad. Hablamos de operaciones background e interactive. Tal como su nombre lo indica una refiere a todos los procesos bach, código, calendarizados, flujos, etc. Mientras que interactivo vela por la respuesta de los modelos dentro de los informes para usuarios finales. En enero 2025 microsoft fabric incorporó una excelente característica que nos ayude a poner límites porcentuales a operaciones background.

La característica se llama Surge Protection, y la definición en palabras microsoft:

"La protección contra sobrecargas ayuda a limitar el uso excesivo de su capacidad al limitar la cantidad de cómputo consumido por los trabajos en segundo plano. Puede configurar la protección contra sobrecargas para cada capacidad. La protección contra sobrecargas ayuda a prevenir el estrangulamiento y los rechazos, pero no es un sustituto de la optimización de la capacidad, el escalado vertical y el escalado horizontal. Cuando la capacidad alcanza su límite de cómputo, experimenta retrasos interactivos, rechazos interactivos o todos los rechazos incluso cuando la protección contra sobrecargas está habilitada."

Muy bien define que esta es una característica que se suma a ayudarnos. No va a reemplazar las prácticas anteriores.

¿Cómo funciona?

Ahora disponemos de dos parámetros nuevos para definirle a las capacidades. Por un lado el porcentaje máximo de la capacidad que pueden alcanzar las operaciones de segundo plano (Background Rejection threshold) y por otro el porcentaje al cual debe bajar el procesamiento para retomar las operaciones de segundo plano. Tomemos un ejemplo para explicarlo mejor (Background Recovery threshold)

LaDataWeb ha configurado estos parametros delimitando 70% para el rechazo de operaciones y 40% para la recuperación. Elegimos 70% porque conocemos la actividad de interactividad de los usuarios y casi siempre ronda entre 17% y 20% según nuestra Fabric Capacity Metrics app. Entonces sabemos que resguardando 30% estaremos seguro y limitamos 70% a las de segundo plano. Podríamos pensarlo como que hemos partido el 100% de la capacidad limitando al back a usar hasta cierto punto.

El día comienza a las 8 am cuando la gente inicia la jornada tradicional de trabajo y corre más operaciones de lo debido manualmente logrando que el background llegue a 70%. Surge Protection al llegar al 70%, continuará las operaciones que este "En ejecución", pero comenzará a rechazar todas las operaciones nuevas que intenten correr. ¿Como sabremos que rechazó? podran saberlo al ejecutar porque verán así:

O en la Fabric capacity metrics app en el nuevo apartado de "System events":

Esto significa que por 24 horas Fabric intentará reducir la capacidad de background rechazando nuevas peticiones. Los usuarios que dan uso con operaciones de interactividad dispondran de 30% de la capacidad. Si su uso es el promedio especulado, no se verían afectados en performance en sus operaciones. Lo cual permite a la empresa seguir operando.

¿Hasta cuando estará bloqueado el back? seguirá rechazando peticiones hasta que la capacidad baje hasta un 40% como lo fue especificado en el parametro de recuperación de capacidad.

¿Cómo configurarlo?

Abrimos el menú de configuración -> Admin portal -> opciones de capacidad. Seleccionamos la capacidad deseada para configurarlo y prendemos la opción de Surge Protection. Luego delimitamos los valores como el ejemplo de la imagen:

Así llegamos al final del artículo donde revisamos una excelente característica que nos ayuda a mantener la experiencia de los usuarios aún cuando los procesos estan en situaciones críticas.

Espero que esta nueva feature los ayude.

[ibarrau]

[Fabric] Fast Copy con Dataflows gen2

Cuando pensamos en integración de datos con Fabric está claro que se nos vienen dos herramientas a la mente al instante. Por un lado pipelines y por otro dataflows. Mientras existía Azure Data Factory y PowerBi Dataflows la diferencia era muy clara en audiencia y licencias para elegir una u otra. Ahora que tenemos ambas en Fabric la delimitación de una u otra pasaba por otra parte.

Por buen tiempo, el mercado separó las herramientas como dataflows la simple para transformaciones y pipelines la veloz para mover datos. Este artículo nos cuenta de una nueva característica en Dataflows que podría cambiar esta tendencia.

La distinción principal que separa estas herramientas estaba basado en la experiencia del usuario. Por un lado, expertos en ingeniería de datos preferían utilizar pipelines con actividades de transformaciones robustas d datos puesto que, para movimiento de datos y ejecución de código personalizado, es más veloz. Por otro lado, usuarios varios pueden sentir mucha mayor comodidad con Dataflows puesto que la experiencia de conectarse a datos y transformarlos es muy sencilla y cómoda. Así mismo, Power Query, lenguaje detrás de dataflows, ha probado tener la mayor variedad de conexiones a datos que el mercado ha visto.

Cierto es que cuando el proyecto de datos es complejo o hay cierto volumen de datos involucrado. La tendencia es usar data pipelines. La velocidad es crucial con los datos y los dataflows con sus transformaciones podían ser simples de usar, pero mucho más lentos. Esto hacía simple la decisión de evitarlos. ¿Y si esto cambiara? Si dataflows fuera veloz... ¿la elección sería la misma?

Veamos el contexto de definición de Microsoft:

Con la Fast Copy, puede ingerir terabytes de datos con la experiencia sencilla de flujos de datos (dataflows), pero con el back-end escalable de un copy activity que utiliza pipelines.

Como leemos de su documentación la nueva característica de dataflow podría fortalecer el movimiento de datos que antes frenaba la decisión de utilizarlos. Todo parece muy hermoso aun que siempre hay frenos o limitaciones. Veamos algunas consideraciones.

Origenes de datos permitidos

Fast Copy soporta los siguientes conectores

ADLS Gen2

Blob storage

Azure SQL DB

On-Premises SQL Server

Oracle

Fabric Lakehouse

Fabric Warehouse

PostgreSQL

Snowflake

Requisitos previos

Comencemos con lo que debemos tener para poder utilizar la característica

Debe tener una capacidad de Fabric.

En el caso de los datos de archivos, los archivos están en formato .csv o parquet de al menos 100 MB y se almacenan en una cuenta de Azure Data Lake Storage (ADLS) Gen2 o de Blob Storage.

En el caso de las bases de datos, incluida la de Azure SQL y PostgreSQL, 5 millones de filas de datos o más en el origen de datos.

En configuración de destino, actualmente, solo se admite lakehouse. Si desea usar otro destino de salida, podemos almacenar provisionalmente la consulta (staging) y hacer referencia a ella más adelante. Más info.

Prueba

Bajo estas consideraciones construimos la siguiente prueba. Para cumplir con las condiciones antes mencionadas, disponemos de un Azure Data Lake Storage Gen2 con una tabla con información de vuelos que pesa 1,8Gb y esta constituida por 10 archivos parquet. Creamos una capacidad de Fabric F2 y la asignaciones a un área de trabajo. Creamos un Lakehouse. Para corroborar el funcionamiento creamos dos Dataflows Gen2.

Un dataflow convencional sin FastCopy se vería así:

Podemos reconocer en dos modos la falta de fast copy. Primero porque en el menú de tabla no tenemos la posibilidad de requerir fast copy (debajo de Entable staging) y segundo porque vemos en rojo los "Applied steps" como cuando no tenemos query folding andando. Allí nos avisaría si estamos en presencia de fast copy o intenta hacer query folding:

Cuando hace query folding menciona "... evaluated by the datasource."

Activar fast copy

Para activarlo, podemos presenciar el apartado de opciones dentro de la pestaña "Home".

Allí podemos encontrarlo en la opción de escalar o scale:

Mientras esa opción esté encendida. El motor intentará utilizar fast copy siempre y cuando la tabla cumpla con las condiciones antes mencionadas. En caso que no las cumpla, por ejemplo la tabla pese menos de 100mb, el fast copy no será efectivo y funcionaría igual que un dataflow convencional.

Aquí tenemos un problema, puesto que la diferencia de tiempos entre una tabla que usa fast copy y una que no puede ser muy grande. Por esta razón, algunos preferiríamos que el dataflow falle si no puede utilizar fast copy en lugar que cambie automaticamente a no usarlo y demorar muchos minutos más. Para exigirle a la tabla que debe usarlo, veremos una opción en click derecho:

Si forzamos requerir fast copy, entonces la tabla devolverá un error en caso que no pueda utilizarlo porque rompa con las condiciones antes mencionadas a temprana etapa de la actualización.

En el apartado derecho de la imagen tambien podemos comprobar que ya no está rojo. Si arceramos el mouse nos aclarará que esta aceptado el fast copy. "Si bien tengo otro detalle que resolver ahi, nos concentremos en el mensaje aclarando que esta correcto. Normalmente reflejaría algo como "...step supports fast copy."

Resultados

Hemos seleccionado exactamente los mismos archivos y ejecutado las mismas exactas transformaciones con dataflows. Veamos resultados.

Ejecución de dataflow sin fast copy:

Ejecución de dataflow con fast copy:

Para validar que tablas de nuestra ejecución usan fast copy. Podemos ingresar a la corrida

En el primer menú podremos ver que en lugar de "Tablas" aparece "Actividades". Ahi el primer síntoma. El segundo es al seleccionar una actividad buscamos en motor y encontramos "CopyActivity". Así validamos que funcionó la característica sobre la tabla.

Como pueden apreciar en este ejemplo, la respuesta de fast copy fue 4 veces más rápida. El incremento de velocidad es notable y la forma de comprobar que se ejecute la característica nos revela que utiliza una actividad de pipeline como el servicio propiamente dicho.

Conclusión

Seguramente esta característica tiene mucho para dar e ir mejorando. No solamente con respecto a los orígenes sino tambien a sus modos. No podemos descargar que también lo probamos contra pipelines y aqui esta la respuesta:

En este ejemplo los Data Pipelines siguen siendo superiores en velocidad puesto que demoró 4 minutos en correr la primera vez y menos la segunda. Aún tiene mucho para darnos y podemos decir que ya está lista para ser productiva con los origenes de datos antes mencionados en las condiciones apropiadas. Antes de terminar existen unas limitaciones a tener en cuenta:

Limitaciones

Se necesita una versión 3000.214.2 o más reciente de un gateway de datos local para soportar Fast Copy.

El gateway VNet no está soportado.

No se admite escribir datos en una tabla existente en Lakehouse.

No se admite un fixed schema.

[ibarrau]

Fabric Rest API ahora en SimplePBI

La Data Web trae un regalo para esta navidad. Luego de un gran tiempo de trabajo, hemos incorporado una gran cantidad de requests provenientes de la API de Fabric a la librería SimplePBI de python . Los llamados globales ya están en preview y hemos intentado abarcar los más destacados.

Este es el comienzo de un largo camino de desarrollo que poco a poco intentar abarcar cada vez más categorías para facilitar el uso como venimos haciendo con Power Bi hace años.

Este artículo nos da un panorama de que hay especificamente y como comenzar a utilizarla pronto.

Para ponernos en contexto comenzamos con la teoría. SimplePBI es una librería de Python open source que vuelve mucho más simple interactuar con la PowerBi Rest API. Ahora incorpora también Fabric Rest API. Esto significa que no tenemos que instalar una nueva librería sino que basta con actualizarla. Esto podemos hacerlo desde una consola de comandos ejecutando pip siempre y cuando tengamos python instalado y PIP en las variables de entorno. Hay dos formas:

pip install --upgrade SimplePBI pip install -U SimplePBI

Necesitamos una versión 1.0.1 o superior para disponer de la nueva funcionalidad.

Pre requisitos

Tal como lo hacíamos con la PowerBi Rest API, lo primero es registrar una app en azure y dar sus correspondientes permisos. De momento, todos los permisos de Fabric se encuentran bajo la aplicación delegada "Power Bi Service". Podes ver este artículo para ejecutar el proceso: https://blog.ladataweb.com.ar/post/740398550344728576/seteo-powerbi-rest-api-por-primera-vez

Características

La nueva incorporación intentará cubrir principalmente dos categorías indispensables de la Rest API. Veamos la documentación para guiarnos mejor: https://learn.microsoft.com/en-us/rest/api/fabric/articles/api-structure

A la izquierda podemos ver todas las categorías bajo las cuales consultar u operar siempre y cuando tengamos permisos. Fabric ha optado por denominar "Items" a cada tipo de contenido creable en su entorno. Por ejemplo un item podría ser un notebook, un modelo semántico o un reporte. En este primer release, hemos decidido enfocarnos en las categorías más amplias. Estamos hablando de Admin y Core. Cada una contiene una gran cantidad métodos. Una enfocada en visión del tenant y otro en operativo de la organización. Admin contiene subcategorías como domains, items, labels, tenant, users, workspaces. En core encontraremos otra como capacities, connections, deployment pipelines, gateways, items, job scheduler, long running operations, workspaces.

La forma de uso es muy similar a lo que simplepbi siempre ha presentado con una ligera diferencia en su inicialización de objeto, puesto que ahora tenemos varias clases en un objeto como admin o core.

Para importar llamaremos a fabric desde simplepbi aclarando la categoría deseada

from simplepbi.fabric import core

Para autenticar vamos a necesitar valores de la app registrada. Podemos hacerlo por service principal con un secreto o nuestras credenciales. Un ejemplo para obtener un token que nos permita utilizar los objetos de la api con service principal es:

t = token.Token(tenant_id, app_client_id, None, None, app_secret_key, use_service_principal=True)

Vamos intentar que las categorías de la documentación coincidan con el nombre a colocar luego de importar. Sin embargo, puede que algunas no coincidan como "Admin" de fabric no puede usarse porque ya existe en simplepbi. Por lo tanto usariamos "adminfab". Luego inicializamos el objeto con la clase deseada de la categoría de core.

it = core.Items(t.token)

De este modo tenemos accesibilidad a cada método en items de core. Por ejemplo listarlos:

Consideraciones

No todos los requests funcionan con Service Principal. La documentación especifica si podremos usar dicha autenticación o no. Leamos con cuidado en caso de fallas porque podría no soportar ese método.

Nuevos lanzamientos en core y admin. Nos queda un largo año en que buscaremos tener esas categorías actualizadas y poco a poco ir planificando bajo prioridad cuales son las más atractivas para continuar.

Para conocer más, seguirnos o aportar podes encontrarnos en pypi o github.

Recordemos que no solo la librería esta incorporando estos requests como preview sino también que la Fabric API esta cambiando cada día con nuevos lanzamientos y modificaciones que podrían impactar en su uso. Por esto les pedimos feedback y paciencia para ir construyendo en comunidad una librería más robusta.

[ibarrau]

[Fabric] Como administrar una sana capacidad

Estamos atravesando una etapa donde la madurez analítica de las compañías crece y ya cuenta con un buen volumen de reportes para la toma de decisiones.

El desafío que antes consistía en construir informes ahora atraviesa una nueva etapa que consiste en un balance de nuestro entorno productivo. Puede que todavía algunas instituciones no lo sientan porque aún trabajan con capacidades compartidas de licencias pro.

Sin embargo, cuando disponemos de una capacidad dedicada, ya sea porque contamos con un Power Bi Premium o estamos analizando comenzar con Fabric, es necesario establecer estándares o prácticas que nos ayuden a dar el mejor uso de la capacidad.

En este artículo veremos prácticas que nos ayuden a velar la sanidad de una capacidad dedicada en PowerBi Service o Fabric.

Iniciamos este recorrido con una práctica que no puede faltar cuando somos administradores de un recursos de procesamiento, monitoreo. Se vuelve indispensable conocer el estado de nuestra capacidad si queremos entenderla para acompañar su estabilidad. Fabric nos da cierto apoyo automático en un área de trabajo administrativa. Estos dos informes, que un Fabric Administrator puede ver, apuntan a conocer la actividad que los usuarios hacen de la capacidad y el contenido desplegado. Son muy útiles y yo diría que secundarias. La principal fortaleza para monitorear es una aplicación que debemos buscar en el store de PowerBi Apps llamada Fabric Metrics Capacity App.

No me voy a detener a explicar cada visualización de la aplicación, para esto la documentación de Microsoft lo detalla de muy buena manera en este enlace:

https://learn.microsoft.com/es-es/fabric/enterprise/metrics-app?wt.mc_id=DP-MVP-5004778

Partiendo de esa base es que podemos pensar en prácticas que fortalezcan nuestra capacidad puesto que comprenderíamos que el procesamiento y memoria de nuestra capacidad se divide en dos operaciones, background (Azul) e interactive (rojo)

Adicionalmente, está el proceso o metodología de desarrollo que implementemos en la organización. Se vuelve muy importante delimitar si utilizaremos ambientes de desarrollo, control de versiones, etc. Más que nada porque los ambientes pueden ayudarnos a distribuir nuestra capacidad, por ejemplo, podríamos disponer de dos capacidades, una fuerte para lo productivo y una más simple para el desarrollo que sabemos tendría menos interactividad. También podríamos pensar en un ambiente de desarrollo de capacidad compartida (licencias pro) siempre y cuando los modelos nos lo permitan (limitaciones de características). Este y cualquier otro estándar previo a que comience a convivir un modelo semántico con la capacidad puede fortalecer indirectamente la administración. Otro ejemplo es una validación, test o paso por buenas prácticas de archivos de Power Bi a modo de auditoria antes de ser publicados. Si buscamos una automatización puede darse con las buenas prácticas de Tabular Editor, optimización modelo o buenas prácticas de Power Query. Éstas últimas tres puedes dar introspección en los artículos:

[TabularEditor] Analizador de buenas prácticas de modelado

[DataModeling] 5 tips de reducción de tamaño de modelo

[PowerQuery] Buenas prácticas en el editor de consulta

Reducción operación Background

Éstas se refieren a procesos previos a la construcción de un modelo. Directamente relacionadas a lo que comúnmente pensamos como ETL. Los contenidos y operaciones que nos impactan son dataflows, notebooks, pipelines, dataset refreshes, etc. ¿Cómo podríamos disminuir su impacto? En su mayoría definiendo reglas o estándares. Veamos ejemplos.

Los modelos medianos o grandes si o si deben ser trabajados en capa de Warehouse/Lakehouse entregando tablas que sean consumidas sin interacción posterior con prácticas de data modeling que eviten operaciones power query.

Definir proceso de extracción y transformación apropiado. Ajustarse a un estándar y no permitir que se cree lo que cada usuario le sea más simple. Usualmente, ocurre con dataflows puesto que, si no son usados apropiadamente, son operaciones costosas.

Cuando deban realizarse transformaciones en Power Query, seguir las buenas prácticas antes mencionadas. Pueden hacer encuentros de control de su procesamiento o informar diagnósticos de sus resultados (con la herramienta de diagnósticos del editor de consultas)

Limitar actualizaciones programadas: delimitar un estándar de actualizaciones para modelos importados por día. Para eventualidades analizar caso puntual y quien lidere el requerimiento justificar la excepción.

Distribuir las actualizaciones programadas de modelos importados a lo largo del día o en rangos de horas por unidad de negocio o tableros. Las actualizaciones masivas en mismo horario pueden generar overloads.

Delimitar estándares para refresh on demand, pedir permiso al realizarlo o delimitar un horario permitido para correrlos.

Activar Large storage en workspace de medianos y grandes modelos. La opción permite trabajar con el almacenamiento columnar permitiendo una optimización de memoria cargando únicamente las columnas que fueron usadas recientemente bajo condiciones de temperatura como priorización.

Usar capacidad compartida PRO para escenarios que no lo requieran. Si tenemos desarrollos que solo verán usuarios pro y los informes no son muy pesados, entonces podría ser un área de trabajo de capacidad compartida. No todo debe estar en la capacidad. Si trabajamos con más de un ambiente, considerar que el de desarrollo podría ser pro para que su carga no impacte en la capacidad productiva.

Dividir la capacidad en ambientes de desarrollo. Si tenemos un F128, podríamos utilizar dos F64 para separar ambientes de desarrollo y productivos para evitar que quienes desarrollan y necesitan actualizaciones con validaciones no consuman la memoria de tableros definitivos que están dando producción a la organización o dirección.

Auditorias de modelos semánticos: Control de calidad de desarrollo antes de publicar en la capacidad dedicada garantizando que las teorías de data modeling fueron aplicadas.

En caso de no poder realizar auditorías constantes para todo, monitorear contenido de workspaces que más usan la capacidad. Agendarles control de prácticas de desarrollo para dichos contenidos puntuales.

Construir una herramienta de monitoreo de refreshes a partir de Power Bi Rest API.

Construir herramienta de monitoreo a partir de azure logs que den más detalle que la Fabric Capacity Metrics App.

Reducción operación Interactive

Éstas se ejecutan cuando un usuario interactúa con un informe o con el modelo semántico directamente. Algunas prácticas para reducirla son:

Estándares de data visualization. Si definimos reglas visuales como límite en cantidad de visualizaciones, no construir páginas gigantes con scroll, reducción custom visuals, no sobrecargar de campos las tablas, etc. Ayudaremos a que los tableros sean más livianos.

Indirectamente realizar un correcto modelado de datos se reflejará en medidas DAX más simples y livianas que eviten sobrecargar la memoria de las visuales.

Política respecto a “Analizar en Excel”. Conectar un Excel al modelo semántico puede resultar muy costoso puesto que usuarios expertos podrían construir tablas pivot demasiado sobrecargadas de datos.

Mejorar entendimiento de DAX. Si conocemos con más detalles sus motores, formula engine y storage engine, será el primer paso para optimizar medidas que no colapsen visualizaciones.

Activar Large storage también repercute sobre la interactividad puesto que la cantidad de memoria con la que el usuario interactúa es menor. Carga en memoria por columnas a demanda con referencia de temperatura (data caliente o fría).

Encender scaleout de modelos muy concurridos. Ayuda a ofrecer un rendimiento rápido mientras una gran audiencia consume los informes y paneles. Hospeda una o varias réplicas de solo lectura del modelo semántico principal. Al aumentar el rendimiento, las réplicas de solo lectura aseguran que el rendimiento no se ralentice cuando varios usuarios envían consultas al mismo tiempo.

Al igual que con background no todo debe ir a la capacidad dedicada. Si tenemos tableros o unidades que solo tienen usuarios pro, podríamos usar capacidades compartidas que reduzcan también la interactividad.

Política de uso y límites para copilot. Si contamos con las características del copiloto, sería prudente establecer límites de uso u horarios permitidos para que usuarios no se excedan en pruebas o curiosidades que afecten la capacidad.

Estas y seguramente otras prácticas serán necesarias para cada escenario puntual puesto que cada capacidad tiene desployado soluciones diferentes. Ojala los ayude a ver prácticas y modos que velen por la sanidad de su capacidad.

[ibarrau]

[Fabric] Leer PowerBi data con Notebooks - Semantic Link

El nombre del artículo puede sonar extraño puesto que va en contra del flujo de datos que muchos arquitectos pueden pensar para el desarrollo de soluciones. Sin embargo, las puertas a nuevos modos de conectividad entre herramientas y conjuntos de datos pueden ayudarnos a encontrar nuevos modos que fortalezcan los análisis de datos.

En este post vamos a mostrar dos sencillos modos que tenemos para leer datos de un Power Bi Semantic Model desde un Fabric Notebook con Python y SQL.

¿Qué son los Semantic Links? (vínculo semántico)

Como nos gusta hacer aquí en LaDataWeb, comencemos con un poco de teoría de la fuente directa.

Definición Microsoft: Vínculo semántico es una característica que permite establecer una conexión entre modelos semánticos y Ciencia de datos de Synapse en Microsoft Fabric. El uso del vínculo semántico solo se admite en Microsoft Fabric.

Dicho en criollo, nos facilita la conectividad de datos para simplificar el acceso a información. Si bién Microsoft lo enfoca como una herramienta para Científicos de datos, no veo porque no puede ser usada por cualquier perfil que tenga en mente la resolución de un problema leyendo datos limpios de un modelo semántico.

El límite será nuestra creatividad para resolver problemas que se nos presenten para responder o construir entorno a la lectura de estos modelos con notebooks que podrían luego volver a almacenarse en Onelake con un nuevo procesamiento enfocado en la solución.

Semantic Links ofrecen conectividad de datos con el ecosistema de Pandas de Python a través de la biblioteca de Python SemPy. SemPy proporciona funcionalidades que incluyen la recuperación de datos de tablas , cálculo de medidas y ejecución de consultas DAX y metadatos.

Para usar la librería primero necesitamos instalarla:

%pip install semantic-link

Lo primero que podríamos hacer es ver los modelos disponibles:

import sempy.fabric as fabric df_datasets = fabric.list_datasets()

Entrando en más detalle, también podemos listar las tablas de un modelo:

df_tables = fabric.list_tables("Nombre Modelo Semantico", include_columns=True)

Cuando ya estemos seguros de lo que necesitamos, podemos leer una tabla puntual:

df_table = fabric.read_table("Nombre Modelo Semantico", "Nombre Tabla")

Esto genera un FabricDataFrame con el cual podemos trabajar libremente.

Nota: FabricDataFrame es la estructura de datos principal de vínculo semántico. Realiza subclases de DataFrame de Pandas y agrega metadatos, como información semántica y linaje

Existen varias funciones que podemos investigar usando la librería. Una de las favoritas es la que nos permite entender las relaciones entre tablas. Podemos obtenerlas y luego usar otro apartado de la librería para plotearlo:

from sempy.relationships import plot_relationship_metadata relationships = fabric.list_relationships("Nombre Modelo Semantico") plot_relationship_metadata(relationships)

Un ejemplo de la respuesta:

Conector Nativo Semantic Link Spark

Adicional a la librería de Python para trabajar con Pandas, la característica nos trae un conector nativo para usar con Spark. El mismo permite a los usuarios de Spark acceder a las tablas y medidas de Power BI. El conector es independiente del lenguaje y admite PySpark, Spark SQL, R y Scala. Veamos lo simple que es usarlo:

spark.conf.set("spark.sql.catalog.pbi", "com.microsoft.azure.synapse.ml.powerbi.PowerBICatalog")

Basta con especificar esa línea para pronto nutrirnos de clásico SQL. Listamos tablas de un modelo:

%%sql SHOW TABLES FROM pbi.`Nombre Modelo Semantico`

Consulta a una tabla puntual:

%%sql SELECT * FROM pbi.`Nombre Modelo Semantico`.NombreTabla

Así de simple podemos ejecutar SparkSQL para consultar el modelo. En este caso es importante la participación del caracter " ` " comilla invertida que nos ayuda a leer espacios y otros caracteres.

Exploración con DAX

Como un tercer modo de lectura de datos incorporaron la lectura basada en DAX. Esta puede ayudarnos de distintas maneras, por ejemplo guardando en nuestro FabricDataFrame el resultado de una consulta:

df_dax = fabric.evaluate_dax( "Nombre Modelo Semantico", """ EVALUATE SUMMARIZECOLUMNS( 'State'[Region], 'Calendar'[Year], 'Calendar'[Month], "Total Revenue" , CALCULATE([Total Revenue] ) ) """ )

Otra manera es utilizando DAX puramente para consultar al igual que lo haríamos con SQL. Para ello, Fabric incorporó una nueva y poderosa etiqueta que lo facilita. Delimitación de celdas tipo "%%dax":

%%dax "Nombre Modelo Semantico" -w "Area de Trabajo" EVALUATE SUMMARIZECOLUMNS( 'State'[Region], 'Calendar'[Year], 'Calendar'[Month], "Total Revenue" , CALCULATE([Total Revenue] ) )

Hasta aquí llegamos con esos tres modos de leer datos de un Power Bi Semantic Model utilizando Fabric Notebooks. Espero que esto les revuelva la cabeza para redescubrir soluciones a problemas con un nuevo enfoque.