ibarrau

[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] Herramientas para administrar o monitorear la organización

Con el lanzamiento de fabric en 2023 aparecieron herramientas que nos ayudan a comprender mejor el uso de la plataforma. Una deuda pendiente que transcurría en Power Bi. Desde ese entonces, la plataforma no deja de sorprender. Incluso ahora en ignite 2024 volvemos a incorporar más herramientas ��tiles que nos asistan a entender nuestro entorno.

Este artículo listara las herramientas disponibles que hay para entender el uso de la plataforma, que hay creado por todas partes, monitorear sus corridas, monitorear la capacidad, etc. Cada una de ellas con distintos filtros de gran introspección

Vamos a comenzar separando el artículo en herramientas de monitoreo y herramientas de administración. Cada una de ellas con objetivos diferentes. Casi todas vienen visibles por defecto para poder utilizarlas. Algunas son accesibles por todo usuario y otras solo por administradores.

Administrativas

A mi parecer lo que conlleva a la administración pasa por comprender que está desplegado en la organización. La administración puede ser del Tenant o inclusive de un usuario convencional que es responsable de X cantidad de áreas de trabajo. Lo importante es poder explorar cuantos reportes (u otro contenido) hay, donde se encuentran, quienes lo crearon, etc. Esa información la tenemos disponible en dos formas.

Área de trabajo de administración

En esta área de trabajo, exclusiva de administradores, podremos ver la totalidad de la organización. Cada workspace, modelo semantico, notebook, etc. Aquí existe un informe llamado "Purview Hub". Este informe refleja todos los items creados en el ecosistema Fabric, sus dominios, etiquetas de sensibilidad de datos, endorsements (si fueron certificados o promovidos), etc. Una vista rápida para que se den una idea de como podríamos comprender todos los items es:

En caso de tener confusión en su uso, tiene una excelente guia de bookmarks en el primer botón de arriba a la izquierda llamado "Take a tour".

OneLake Catalag

Un lanzamiento reciente que tiene un foco similar es el Catálogo de Onelake. La principal diferencia se basa en que el catálogo está visible para todo usuario de Fabric y muestra sobre lo que el usuario tiene permisos en lugar de mostrar toda la organización. Se encuentra accesible en el menú izquierdo de navegación.

Tiene una muy simple y sencilla interfaz que nos permite buscar por área de trabajo o items (lakehouse, semantic model, report, pipeline, etc)

Me parece ideal para quienes sea administradores responsables de ciertos desarrollos en varias áreas de trabajo.

Monitoreo

Tenemos tres herramientas de monitoreo en distintos ejes, una de administradores, una app que podemos disponibilizar permisos y una para cada usuario.

Métricas/Logs de uso de plataforma.

Al igual que Purview hub, en el admin workspace encontraremos un segundo informe llamado "Feature usage and Adoption". Este informe se enfoca en revelarnos la actividad de cada usuario que ingresó a la plataforma los últimos 30 días. Registra el uso que dan los usuarios a la plataforma. La lista de operaciones que guardará al momento de ejecutarse podemos leerla en este enlace: https://learn.microsoft.com/en-us/fabric/admin/operation-list?wt.mc_id=DP-MVP-5004778

El informe nos permite explorar por area de trabajo y capacidad las actividades registradas. Podemos ver que usuario ejecuto que operación en que día. Siempre se registran últimos 30 días y no más.

Pronto podemos visualizar las operaciones más realizadas. En este caso get data source details, puesto que es un tenant que hay más investigaciones que reportes para visualizar. Para más detalles de su uso podemos revisar su doc aqui: https://learn.microsoft.com/en-us/fabric/admin/feature-usage-adoption?wt.mc_id=DP-MVP-5004778

Fabric Capacity metrics app

No tenemos una manera de monitorear una capacidad dedicada por defecto. Por eso, esta app es muy importante de leer e instalar. Cuando compramos una capacidad es crítico monitorear sus recursos. Comprender que contenidos, flujos de datos, etc están siendo más pesados que otros. Podemos comprender si la capacidad tiene mucho flujo de background o mucha interactividad de usuarios. Estos detalles y muchos más pueden verse con la Fabric Capacity Metrics App. La herramienta es clave para poder gestionar una sana capacidad como lo expresamos en este artículo.

Esta herramienta no viene por defecto en la organización. Debe instalarse desde el menú de Apps "Get Apps". Allí aparecen muchas de distintas emrpesas. Buscamos el nombre y la instalamos.

La app funciona igual que una PowerBi App de workspace. Crea una nueva área y permite dar permiso a quien querramos. Para configurarla debemos ser owners de la capacidad y completar los parámetros del dataset.

Para conocer en mayor detalle su funcionalidad, podemos ver el siguiente enlace: https://learn.microsoft.com/en-us/fabric/enterprise/metrics-app-compute-page?wt.mc_id=DP-MVP-5004778

Sección Monitoreo

¿Qué nos falta? comprender si nuestras operaciones de background estan corriendo satisfactoriamente. Si hoy usamos fabric, seguramente tenemos muchos contenidos de integración de datos poblando lakehouse o transformando, limpiando y preparando datos para leer. Este espacio nos permite ver el estado de esas operaciones con versátiles filtros de estado, tipo de item, fecha de corrida relativa, quien lo hizo o en que área de trabajo se encuentra. Así mismo brinda una variedad de columnas para ver en mayor detalle.

Esta sección la pueden ver todos los usuarios y les muestra aquellos elementos que tenga permisos de ver o controlar. Nuevamente, muy útil para ingenieros de datos con muchos flujos, administradores de áreas de trabajo o dominios, etc.

¿Eso es todo?

No claro que no. Todo el tiempo surjen actualizaciones e ideas de personas que traen más y más visibilidad. Por ejemplo, hay artículos revelando como leer información de los audit logs para llegar a una medida más profunda de una capacidad de Fabric. Podemos usar la API para generar un histórico de las operaciones para no quedarnos en últimos 30 días. Incluso armar nuestro propio purview hub basado en datos profundos que consigamos con API. Hay muchos miembros activo de la comunidad con nuevas ideas para afinar detalles o dar alternativas. Recientemente, en el ignite 2024, las áreas de trabajo incorporaron un monitoreo en tiempo real que podemos setear con recursos realtime:

Nosotros expresamos las que vienen por defecto y una indispensable. Ustedes pueden adaptar muchas otras nuevas en distintos ejes o utilizar lo que mostramos.

[ibarrau]

[DataModeling] Tip DAX para autoreferencia o recurrencia de tabla

Hace tiempo que no nos sentrabamos en acompañar un escenario de modelado. En esta oportunidad, nos vamos a enfocar en como resolver una situación de auto referencia o recurrencia de tabla. Suele ocurrir que una tabla puede tener ids o claves de referencia para si misma y las formas de resolverlo pueden variar.

En este artículo, vamos a mostrar como valernos de DAX para resolver un esquema jerárquico corporativo que ayude a develar un organigrama organizacional basado en niveles o posiciones/cargos superiores.

Contexto

Entre las formas de modelar bases de datos transaccionales, buscamos normalizar los datos para evitar la redundancia lo más posible. Así es como pueden aparecer escenarios donde hay tablas que van a referenciarse a si mismas. Esto quiere decir que podemos tener una clave foránea apuntando a una clave primaria. Para no abordar tanta teoría veamos un ejemplo que ayude a enfocar el caso.

Nos enviaron un requerimiento que pide detallar un organigrama o estructura jerárquica en la organización que permita explorar la cantidad de empleados según distintos focos de mando. Piden que la información sea explorable, puede ser una matriz o árbol del siguiente estilo:

Árbol de decomposición

Matriz

Supongamos que tenemos una tabla de Empleados en nuestra base de datos. La organización tiene un gran volumen de personal, lo que hace que naturalmente haya una estructura jerárquica con cargos de mando o de management. Todas las personas institucionales forman parte de la tabla empleados fila por fila. Sin embargo, necesitamos guardar información sobre la persona a la cual responden. Aquí aparece la auto referencia. Para resolver esta operación en vistas de base de datos transaccional, será más performante y menos costoso delimitar una nueva columna que autoreferencie a otra fila en lugar de otras tablas para los cargos pertinentes. Veamos como quedaría una tabla con la nueva columna:

Fíjense que la columna id_superior pertenece a un id_empleado de otra fila. Cuando esto ocurre, estamos frente a un caso de auto referencia.

Dependiendo el proceso y escenario a delimtiar en nuestro modelo semántico, puede ser resuelto de distintas formas. Podríamos generar fact factless que orienten un mapeo de quienes responden a quienes o podemos tomar esta tabla como dimensión y generar columnas que representen el mando jerárquico como columnas categóricas de la dimension.

Este artículo se enfocará en la segunda solución. Vamos a generar columnas categoricas que nos ayuden a construir algo semejante a lo siguiente:

La idea es generar columns por cantidad de niveles jerárquicos que se presenten. Si bien la mejor solución es implementarlo lo más temprano posible, es decir en un warehouse, lakehouse o procesamiento intermedio; aquí vamos a mostrar como crear las columnas con DAX.

Vamos a crear una columna calculada de la siguiente manera:

Level1 = LOOKUPVALUE( Empleados_Jerarquia[Nombre] , Empleados_Jerarquia[id_empleado] , PATHITEM( PATH ( Empleados_Jerarquia[id_empleado], Empleados_Jerarquia[id_superior]) , 1 , INTEGER ) )

Vamos a nutrirnos de tres funciones para generar un recorrido dentro de la misma tabla.

LOOKUPVALUE: Esta función busca un valor en una columna específica de una tabla, basándose en criterios de búsqueda. En este caso, está buscando el nombre de un empleado con criterio de igualdad entre id_empleado que mapee al id_superior de la fila actual.

PATH: Esta función crea una cadena que representa la jerarquía de empleados, utilizando los id_empleado y id_superior. Busca los ID y los separa por Pipes. Entonces por ejemplo en la fila de ID = 5 de Joaquín. El resultado de Path será "1|2|5" representando que los ID de sus superiores son primero el empleado 2 y luego el empleado 1.

PATHITEM(..., 1, INTEGER): Esta función toma la cadena generada por PATH y extrae un elemento de ella. En este caso, está extrayendo el primer elemento (el id del empleado que está en la posición 1). Aquí, el 1 se refiere a la posición que queremos extraer (el primer ítem en la jerarquía). Si Joaquín tenía 3 valores, vamos a buscar el de la primera posición, en este caso "1".

Resultado: lookupvalue buscara el nombre del empleado con ID 1 para la columna.

Esta función podríamos replicarla para cada nivel. La función antes vista traería el primero de la cadena, es decir la dirección de la empresa. Para llegar al siguiente nivel cambiamos el parametro de pathitem de manera que traiga el segundo resultado de Path en sus pipes.

Level2 = LOOKUPVALUE( Empleados_Jerarquia[Nombre] , Empleados_Jerarquia[id_empleado] , PATHITEM( PATH ( Empleados_Jerarquia[id_empleado], Empleados_Jerarquia[id_superior]) , 2 , INTEGER ) )

En primera instancia esto parecería resolverlo. Este sería nuestro resultado:

Esta puede ser una solución directa si solo queremos navegar por nombres de personas en cadena (filtramos Level5 <> Blank). Sin embargo, si también quisieramos conocer la cantidad de personas que tienen a cargo, es necesario contar a la persona al mando como parte del equipo, sino generaríamos una cadena de "Blanks" como pueden ver en niveles del 2 al 5. Esto lo podemos corregir copiando el nivel anterior cuando ocurre un blanco.

Level2 = VAR __lvl2 = LOOKUPVALUE( Empleados_Jerarquia[Nombre] , Empleados_Jerarquia[id_empleado] , PATHITEM( PATH ( Empleados_Jerarquia[id_empleado], Empleados_Jerarquia[id_superior]) , 2 , INTEGER ) ) RETURN IF ( ISBLANK(__lvl2) , Empleados_Jerarquia[Level1], __lvl2 )

De esa forma el equipo de Laura (primera) cuenta con tres gerentes y si misma al conteo total de empleados.

Las visualizaciones pueden ser construidas por cada nivel como columnas categóricas de las dimensiones:

Así mismo podría usarse el nombre del cargo como nombre de columna para ver la pirámide institucional de una manera más sencilla.

De esta forma llegaríamos al resultado esperado y mostrado en la primera imagen de requerimiento.

Ojala esta solución les sirva para resolver situaciones de modelado recursivo. Recuerden que si podemos ejecutar esto en SQL en nuestra capa de transformación, sería lo mejor para construir la dimensión. Como siempre pueden descargar el archivo de ejemplo de mi GitHub.

[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]

[SimplePBI] Documentar modelo semantico automáticamente

A medida que más modelos y reportes se construyen se vuelve más crítica la necesidad de tener documentos que ayuden a la interpretación de los mismos. La popularidad de la herramienta ya lleva muchos años de desarrollo y todos los días nuevos desarrolladores deben modificar o dar soporte a modelos que no construyeron.

Tanto por soporte, interpretación, mantenimiento y mucho más, se vuelve indispensable documentar lo que sucedió en el modelo semántico para que otros puedan seguir el hilo de nuestro trabajo. En este artículo veremos como podemos ejecutar una sentencia en python usando SimplePBI para exportar un documento html de un informe publicado en Power Bi Service.

Documentar es una de las tareas más odiadas por desarrolladores de múltiples industrias. Aunque a la mayoría no le guste es innegable que tiene beneficios. Uno de mis favoritos es mejorar la colaboración entre equipos. Imaginen que bueno sería dar soporte a una medida que tenga una buena Descripción o sus varias líneas de código con comentarios. Seguramente, la experiencia de modificar una así a 20 lineas sin especificar reduciría el tiempo de respuesta para resolverlo.

Pre-requisitos

Para poder utilizar esta herramienta es necesario contar con acceso a la Power Bi Rest API. Podes leer como dar tus primeros pasos aqui.

Limitaciones

Este método está basado en ejecuciones de consultas contra el modelo semántico. Si utilizamos un Service Principal para realizar este documento, no es posible ejecutar consultas contra un modelo semántico que tenga configurado RLS o de conexión direct lake o direct query.

Creación del documento

Veamos que simple que es exportar un documento html que lea un informe de un modelo semantico en el servicio de power bi. Para mejor experiencia de usuario, hemos desarrollado dos tipos de documento. Uno por contenido y otro por tablas.

La ejecución es bastante simple. Buscamos en nuestra interfaz el modelo semántico que queremos analizar y lo abrimos. Esto lo hacemos para poder extraer el id del área de trabajo y del modelo semántico de la URL

Doc por contenido

Como ya aclaramos muchas veces para iniciar la librería importamos los módulos que nos interesan y autenticamos un token para ejecutar los requests.

from simplepbi import token from simplepbi import datasets # Variables de autenticación TENANT_ID = "xxxx-xxxx-xxxx-xxxx" power_bi_client_id = 'xxxx-xxxx-xxxx-xxxx' power_bi_secret = 'xxxx-xxxx-xxxx-xxxx' workspace_id = 'xxxx-xxxx-xxxx-xxxx' dataset_id = 'xxxx-xxxx-xxxx-xxxx' # Creación de objetos con requests y token t = token.Token(TENANT_ID, power_bi_client_id, None, None, power_bi_secret, use_service_principal=True) d = datasets.Datasets(t.token)

Como podemos apreciar en la siguiente imagen, el nuevo método los datos que nos piden son del workspace y dataset id.

Fíjense que podemos elegir si queremos exportar el documento a un path local o pedir la respuesta en una cadena de texto "string" que podríamos copiar y pegar en un archivo vacío y crear el html nosotros. Esto porque dependerá de donde estemos ejecutando el código. Por ejemplo:

d.create_doc_by_content_dataset_in_group(workspace_id, dataset_id, "file", r"C:\Users\IBARRAU\Documents\css templates\doc_by_content.html")

El documento está dividido por contenido. Entonces tiene tres partes. Primero las tablas con su diagrama, luego las columnas de todas las tablas y finalmente las medidas de todas las tablas. Algo así:

Doc por Tabla

De la misma manera la exportación funciona exactamente igual. La diferencia esta en el tipo de contenido. Veamos el código

También aqui podemos delimitar si queremos "Text" o "File". La sentencía sería:

d.create_doc_by_table_dataset_in_group(workspace_id, dataset_id, "file", r"C:\Users\IBARRAU\Documents\css templates\doc_by_table.html")

Este documento es un poco más completo puesto que añade las definiciones de consultas de Power Query escondidas en un elemento html que colapsa el código para que no sea tan largo. Esta construido mostrando el diagrama de tablas seguido tabla por tabla. Cada tabla muestra la definición de su consulta, las columnas y sus medidas (en caso de tenerlas).

Ambos documentos podemos encontrarlos en mi repositorio de GitHub en caso que quieran leerlos con detalle. Si queres conocer más de SimplePBI, su repositorio y documentación esta en GitHub.

Así concluimos las exportaciones automáticas que pueden ayudarnos con los detalles de un modelo para tenerlos cerca si necesitamos conocer detalles de un modelo desplegado en el servicio de Power Bi.

[ibarrau]

[Fabric] Integrar repo GitHub con área de trabajo

Una característica que no para de causar revuelo y preguntas al momento de persistir los desarrollos de Fabric es la integración de áreas de trabajo con Github. Desde el lanzamiento de Fabric podíamos integrarnos a un repositorio, pero era exclusivamente con Azure DevOps. La historia continuó con el lanzamiento de Power Bi Projects que nos permitía desagregar el desarrollo de un pbix en código para poder persistirlo y mergearlo. La cuenta pendiente más grande de desarrollos de Power Bi estaba saldada. El desarrollo ya podía ser versionado en su totalidad.

En este artículo vamos a ver como configurar un repo de Github para estar integrado con un Area de trabajo en Fabric/PowerBi.

Lo primero que recomiendo si están iniciando este artículo sin conocer que es una integración de Git en un área de trabajo es pasar por este artículo anterior que explica el funcionamiento y la desagregación de archivos que consolidan un Proyecto de Power Bi.

Prerrequisitos

Cuenta de Github

Repositorio creado (se recomienda privado para desarrollos y manejo de datos corporativos sensibles)

Una Personal Access Token (PAT)

Un área de trabajo con capacidad dedicada

Asumiendo que conocemos como crear una cuenta de Github y un repositorio, comencemos con la creación de la PAT. Para ellos vamos a nuestro perfil, menú settings > Developer settings. Los tokens de acceso pueden ser classic o fine-grained. Recomiendo crear fine-grained que son la próxima generación de tokens y es bueno estar actualizados.

https://github.com/settings/tokens?type=beta

Delimitamos un nombre para nuestro token de acceso y en el apartado de permisos seleccionamos Read and Write para Contents.

Tras crear el token es necesario guardar el valor generado porque no podremos volver a verlo. Copienlo bien y resguárdenlo.

Ahora si podemos volver a PowerBi para abrir las configuraciones del área de trabajo en la parte de integraciones de Git. Hay dos configuraciones. Iniciamos logueando el proveedor con la dirección del repo y el token:

Una vez configurado se ve así. Continuamos sincronizando el pertinente Branch que nos permite seleccionar inclusive una carpeta o subcarpeta especifica. Tengamos presente que símbolos y espacios en las carpetas podrían generar dificultades para reconocerlas.

Así conseguimos nuestra integración para comenzar a trabajar en equipo sobre los reportes y modelos semánticos desarrollados como Power Bi Projects o elementos de Fabric.

Esta sencilla configuración nos permite comenzar a versionar nuestros desarrollos de PowerBi con simplemente una capacidad dedicada puesto que Github cuenta con servicio gratuito que fortalece no incorporar una licencia adicional.

Otros repositorios

Las áreas de trabajo permiten integración con dos repositorios Git hasta el momento (19-09-2024), Azure DevOps y GitHub. veamos algunas comparaciones entre las plataformas:

Si queres saber más sobre la integración con Azure DevOps podes ver este post.

Así completamos nuestro artículo para conectar un repositorio GitHub con un Área de trabajo. ¿Cual usar? depende de cada organización respecto de que tecnología se adaptaría mejor o cual están usando actualmente.

[ibarrau]

[DAX] INFO functions

Hace varios meses ya que microsoft nos ha sorprendido agregando nuevas funciones en DAX que responden a información del modelo. Conocer detalles del modelo se vuelve indispensable para documentar o trabajar por primera vez con un modelo ya creado.

Ya son más de 50 nuevas funciones que permiten preguntarle al modelo detalles particulares como por ejemplo indagar en las expresiones de las medidas de nuestro modelo o los roles de seguridad por filas creados.

Lo cierto es que ya existía una forma de llegar a esta información. Desde el inicio de modelos tabulares tuvimos exposición a DMV (Dynamic Management Views). Como nos gusta hacer aqui en LaDataWeb, primero veamos el contexto teórico:

Las vistas de administración dinámica (DMV) de Analysis Services son consultas que devuelven información sobre los objetos del modelo, las operaciones del servidor y el estado del servidor. La consulta, basada en SQL, es una interfaz para esquemas de conjuntos de filas.

Si quieren traer un poco más a la memoria o un ejemplo de ello, pueden revisar este viejo artículo. El nuevo esquema INFO en DAX nos brinda más de 50 funciones para obtener información del esquema TMSCHEMA de DMV.

Si ya existía... ¿Por qué tanto revuelo?

Las INFO de DAX vienen a evolucionar algunos aspectos que no podíamos resolver antes y darnos creatividad para explotarlos en otros que tal vez no habíamos pensado.

No es necesario utilizar una sintaxis de consulta diferente a DAX para ver información sobre tu modelo semántico (antes SQL). Son funciones DAX nativas y aparecen en IntelliSense cuando escribes INFO.

Puedes combinarlas usando otras funciones DAX. La sintaxis de consulta DMV existente no te permite combinarlas. Como función DAX, la salida es de tipo de datos Tabla y se pueden usar funciones DAX existentes que unen tablas o las resumen.

Estas son el eslabón inicial bajo el cual se llamó la atención. Ahora podemos pensar solo en DAX y si buscamos INFO de Tablas, relaciones, columnas o medidas, podemos combinarlas para mejorar el resultado de nuestra consulta. Si quisieramos conocer las medidas de una tabla puntual con su nombre, podríamos ejecutar algo así:

EVALUATE VAR _measures = SELECTCOLUMNS( INFO.MEASURES(), "Measure", [Name], "Desc", [Description], "DAX formula", [Expression], "TableID", [TableID] ) VAR _tables = SELECTCOLUMNS( INFO.TABLES(), "TableID", [ID], "Table", [Name] ) VAR _combined = NATURALLEFTOUTERJOIN(_measures, _tables) RETURN SELECTCOLUMNS( _combined, "Measure", [Measure], "Desc", [Desc], "DAX Formula", [DAX formula], "Home Table", [Table] )

Así obtendríamos una tabla con su nombre, sus medidas, sus descripciones de medidas y las expresiones de las medidas. El resultado puede ser documentación de modelo exportado a excel:

¿Donde o cómo puede ejecutarlo?

Las funciones de información puede ayudarnos para explorar un modelo en edición actual. Si estamos conociendo un modelo por primera vez o culminando un trabajo para documentar, podríamos abrir la vista de consultas DAX de un Power Bi Desktop para ejecutar el código. También siempre dispondríamos de DAX Studio que no solo permite ejecutar con un PowerBi Desktop, sino también contra un modelo en una capacidad dedicada en Fabric o PowerBi Service.

En mi opinión lo más interesante es que esto es DAX nativo. Como gran amante de la PowerBi Rest API, eso me entusiasma, dado que el método que permite ejecutar código DAX contra un modelo semántico en el portal de PowerBi, no permite DMV. Restringe a DAX nativo. Esto abre las puertas a ejecutar por código una consulta de información al modelo. Podríamos estudiar y comprender que es lo que a nuestra organización más nos ayuda entender de un modelo o nos gustaría documentar. A partir de ello construir un código que obtenga esa información de un modelo semántico que necesitemos comprender. Veamos la siguiente imagen que aclare más

Espero que las funciones los ayuden a construir flujos que les brinden la información que desean obtener de sus modelos.

[ibarrau]

[SimplePBI] Get tablas, medidas, columnas o roles de un modelo con código Python

Al día de hoy PowerBi esta instaurado masivamente. Ya lo usan muchísimas empresas y la cantidad de modelos e informes deployados es enorme. Esto hace que los desafíos de hoy, ya no sean los de antes.

Antes había más concentración en la comunidad por aprender PowerBi tips, buscar como armar una característica puntual de experiencia de usuario. Esto se daba porque eran los primeros informes de muchas empresas. Hoy nos toca entender informes ya implementados por otras personas o empresas. ¿Cómo entender que hay detrás de un modelo semántico publicado? El nuevo update/release de la librería de Python, SimplePBI, para leer la PowerBi Rest API puede ayudarnos a obtener información de tablas, medidas, columnas y hasta roles que existen en el modelo.

Cuando necesitamos editar, dar soporte y comprender algún modelo semántico en producción. Puede ser un gran desafío si no contamos con las prácticas adecuadas de versionado. Si necesitamos entender rápidamente sobre un linaje fino (tabla) del origen y no tenemos un catálogo de gobernanza apropiado hay un inconveniente.

Para estas situaciones y muchísimas más, SimplePBI incorporó la posibilidad de preguntar fácilmente con código python por información de un modelo semántico. ¿Qué podemos consultar?

Tablas: datos de las tablas del modelo.

Medidas: todas las medidas del modelo, sus expresiones y a que tabla pertencen.

Columns datos de las columnas del modelo y a que tabla pertenecen.

Roles: datos de roles de RLS creados en el modelo.

Veamos que simple que es consultar el modelo.

Pre requisitos

Lo primero que necesitamos es conocer como se utiliza la PowerBi Rest API, para ello podes dar tus primeros pasos con este artículo. Lo segundo es asegurarnos que tenemos una versión 0.1.10 o superior de la librería:

Si ya tenian la librería pueden correr en consola:

pip install SimplePBI --upgrade

Obtener información del modelo

A partir de ese momento podremos consultar un modelo semántico o conjunto de datos de un área de trabajo puntual.

Autenticamos y generamos un token:

Creamos el objeto de la categoría que nos gustaría ejecutar. En este caso datasets hace referencia a modelos semánticos:

d = datasets.Dataset(t.token)

Aún siendo desarrollo propio de la librería, los métodos a ejecutar tienen nombre amigables muy similares a los que ya existían en la documentación de la API:

get_tables_from_dataset_in_group

get_measures_from_dataset_in_group

get_columns_from_dataset_in_group

get_tables_from_dataset_in_group

Podemos obtener el id de área de trabajo y del modelo semántico desde la URL del navegador cuando abrimos el modelo. Se ve así:

https://app.powerbi.com/groups/[Workspace ID]/datasets/[Dataset ID]/details?experience=power-bi

Así ejecutaríamos las medidas:

Como podemos apreciar, es una simple linea que trae toda la información. Cada item de la lista de rows en el diccionario de respuesta tiene una medida. En este caso podemos ver tres medidas de la tabla "MEDIDAS". Entre los datos de mayor interes vemos su nombre, tipo de datos y expresión.

Espero que esto los ayude a investigar más sobre modelos deployados para aprender en caso de dar soporte, mejorar nuestras estructuras de catálogos o revisar rápidamente expresiones de medidas. El uso en definitiva tiene como límite su creatividad.

[ibarrau]

Fabric Mirroring

Estamos atravesando tiempos que avanzan muy rápido en materia de desarrollos de tecnología, software y datos. Especificamente, en el universo de datos podemos apreciarlo en el cambio constante que ocurre a las necesidades de cada empresa en construcciones analíticas.

Entre los más ocurrentes tenemos problemas que hablan de encontrar escalabilidad con menor costo, accesibilidad a todo tipo de usuario y reducir los data silos. Si están pensando en usar Fabric o ya lo usan. Mirroring puede ayudarnos en parte con estos problemas.

Contexto

Me gustaría comenzar recordando que las replicas o mirror no son algo nueva en industria tecnología. Veamos un concepto genérico en mirror de bases de datos que era algo bastante común.

"Mirroring en base de datos es una copia de seguridad completa de la base de datos que se puede usar si la base de datos principal falla. Las transacciones y cambios en la base de datos principal se transfieren directamente al espejo y se procesan de inmediato, por lo que el espejo siempre está actualizado y disponible como un 'standby' activo."

En tradicional desarrollo de software nacía como dar certeza que una falla no prevenga el acceso. Sin embargo, en materia de análisis de datos se consideraba crucial para evitar que el computo de grandes consultas analíticas no impactara directamente en la base de datos transaccional.

A mi modo de pensar ambos apuntan a un mismo foco indispensable. Disponibilidad. Que los accesos a datos siempre tengan certeza de consulta.

Fabric Mirror

Fabric Mirroring es una solución de bajo costo y baja latencia para unir datos de varios sistemas en una sola plataforma de análisis. Puedes replicar continuamente tu conjunto de datos existente directamente en OneLake de Fabric. Actualmente cuenta con tres posibles orígenes:

Azure SQL Database

Azure Cosmos DB

Snowflake.

Entre las características que me gustaría destacar estan:

Permite replicar bases de datos en Fabric sin necesidad de ETL

Los datos se replican en OneLake en formato Delta y se mantienen actualizados en tiempo casi real. (Mi favorita)

Todos los servicios de almacenamiento de Fabric funcionan instantáneamente con la réplica de OneLake, incluidas las experiencias de warehouse y lakehouse.

El almacenamiento y la replicación para el mirror están incluidos en tu capacidad de Fabric sin costo adicional.

Construido sobre CDC (Change data capture) para solo mover en el instante los cambios de datos.

Soporte para DDL (Data definition language): permitiendo que nuevas tablas sean instántaneamente agregadas (en caso que hagamos replica de todas las tablas)

Mi favorito y la principal diferencia con un caso convencional de mirror es que la replica se reguarda en formato abierto delta. Perfecto y listo para ser consultado en Fabric. Al igual que con Lakehouse y Warehouse, cuando creamos un mirror se generan la misma cantidad de contenidos. Un SQL endpoint para consultar datos y un modelo semántico por defecto para analizar datos con direct lake.

Para crear uno simplemente ponemos "Nuevo" y buscamos el contenido de mirror al origen deseado. Delimitamos la base de datos y nos aparecerá una guia para conectarnos tal como si estuvieramos agregando un conjunto de datos en gateway o dataflow gen2.

Luego podremos elegir si replicar toda la base de datos o simplemente una delimitada selección de tablas con objetivo de análisis de datos. Por defecto el recurso principal nos deja monitorear cada tabla:

Si nos dirigimos al SQL Analytics endpoint podremos tener vista previa de los datos e incluso encontrar su lugar puntual en el OneLake en su modo delta parquet.

De ese modo tenemos un excelente y simple proceso para tener al instante los datos que buscamos para construir proyectos de datos sin complejos ETL, disponible para consultar con computo de spark usando notebooks, sql o powerbi.

Pre requisitos

Necesitas tener una capacidad existente de Fabric. Si no la tienes, inicia una prueba de Fabric.

Habilita Fabric mirroring en tu configuración para inquilino de Microsoft Fabric (admin portal).

Si vas a trabajar con service principals, habilita la configuración de inquilinos de Fabric 'Permitir a los principales de servicio utilizar las API de Power BI'.

Requisitos de red para que Fabric acceda a la fuente de datos. Cada origen tiene configuración adicional en el origen. Puede verse en un tutorial de la doc de microsoft.

Espero que esta feature les resulte útil. Tiene un potencial inmenso que seguramente crecerá más y más a medida que pueda disponibilizar más orígenes. Hoy permitir snowflake es un bombazo y seguramente tendrá más.

[ibarrau]

[SimplePBI] Como armar un histórico de Fabric Capacity Metrics App

Cada día me llegan más solicitudes de instalar una herramienta de monitoreo para administrar una capacidad dedicada. Allí es cuando aparece la App de Microsoft. Sin embargo, la herramienta, o debería decir el modelo semántico, cuenta con una limitada historia para monitorear. Resulta que el informe resguarda pocos días hacia atrás y algunas instituciones prefieren contar con valores históricos para poder analizar tendencias o dar explicaciones a sucesos pasados y no solamente a lo que ocurre ahora.

En este artículo veremos como podemos extraer datos del modelo semántico de Fabric Capacity Metrics App para construir un histórico utilizando la librería SimplePBI de Python en un jupyter notebook.

Si tenemos nuestros desarrollos desplegados en una capacidad, seguramente estamos utilizando Fabric Capacity Metrics App. Digo "seguro" porque la aplicación del store de Microsoft provee un informe para monitorear el uso de nuestra capacidad (Unidades de procesamiento/capacity CUs). A diferencia del Admin Monitoring que provee un detalle de lo que esta desplegado en la organización y las operaciones o actividades que se ejecutan, la Capacity metrics nos ayuda a entender cuantos recursos de la capacidad esta utilizando un contenido como un modelo semantico, un dataflow gen2, un Fabric notebook o un pipeline de Fabric Data Factory.

Cuando disponemos de una capacidad la administración cambia completamente. Las acciones diarias y los hitos por proyectos o deploys nuevos deben tenerse en cuenta. Si queremos comparar o analizar cambios en deploys mensuales de proyectos complejos, necesitamos almacenar un histórico. Si necesitamos analizar si una tendencia actual que esta relentizando o consumiendo todos los recursos estaba sucediendo en el pasado y no es excepcional, necesitamos histórico. Por esta y muchas otras razones que me comentaron algunos clientes se me ocurrió escribir este artículo.

Prerequisitos

Lo primero que necesitamos será definir nuestro almacenamiento. Si ya utilizamos Fabric es posible usar lakehouse o warehouse con Fabric notebooks, sin embargo tal vez querramos aislar este desarrollo para que no tenga la más mínima influencia en la capacidad. Una vez definido el almacenamiento debemos asegurarnos que podemos usar la Power Bi Rest API. Este artículo puede ayudarlos. Por último, instalar en el entorno donde correremos código Python la librería SimplePBI.

¿Qué vamos a extraer?

El modelo semántico de la Capacity Metrics esta lleno de tablas y contiene parámetros dinámicos. Sin embargo, hoy nos vamos a concentrar en lo más usados.

Timepoints: puntos temporales donde ocurre un movimiento de la capacidad.

Items: contenido que ha utilizado la capacidad al menos una vez.

Background Operations: operaciones de código que incluyen procesamientos o transformaciones.

Interactive Operations: refiere a las interacciones de los usuarios explorando y utilizando los informes.

Vamos a iniciar importando librería, recolectando valores de nuestra Aplicacion Registrada en Azure para usar la API. También podemos buscar el id de la capacidad en el portal de administración de Fabric, administrando capacidades.

Para obtener los datos vamos a ejecutar una consulta/query contra el modelo de datos. Veamos por ejemplo una función para traer los Timepoints de un día específico.

Para comenzar debemos mandar un parámetro dinámico de M PowerQuery. Mandamos el id de capacidad y ejecutamos un SUMMARIZECOLUMNS buscando el listado de timepoints y algunas columnas más de operaciones.

A partir de los timepoints podremos buscar las operaciones puesto que se desencadenan para cada timepoint. Entonces hay muchas operaciones por cada timepoint. El primer desafío es que la API nos limita a 1.000.000 de celdas o registros. Calculando cuantas filas podemos traer para la cantidad de columnas que conllevan ese volumen, hablamos de 66.666 filas aproximadamente. Esta información es clave para iterar operaciones de nuestra capacidad.

NOTA: Esto solo será necesario si tenemos mucha cantidad de contenido o usuarios operando.

Comenzaremos ejecutando un COUNT de filas de las operaciones para partir la cantidad de iteraciones cada 66.666 filas.

La consulta para saber las filas y traer los resultados es similar. Ambas pasarán los parámetros dinámicos de M (id de capacidad y timepoint) y buscaran las columnas esperadas, las renombraremos y al final cambiará si buscamos contar las filas o traer los resultados en "ventanas" de 66.666 filas.

Con las funciones que nos den las filas y la ejecución de cada timepoint, vamos a construir la iteración.

En caso que las operaciones lleguen en "None", lo más probable es que sea porque la librería SimplePBI no hay podido traer los resultados por limitación de cantidad de requests ejecutados con la API. Entonces desencaderá una espera de 1 minuto para reanudar. Pueden observar cada paso con sus comentarios para ir comprendiendo el código o construir uno propio. Aqui iteramos dos veces, por un lado una lista timepoints "tp_looper" y por cada una de ella la limitación de filas de la API. Agregamos tres columnas que nos ayuden a reconocer el resultado, el id de capacidad (por si tenemos más de una capacidad), el timepoint (para conocer la fecha con exactitud) y tipo de operación (si es de back o interactiva). Vamos agregando los resultados en un solo pandas dataframe.

Así formamos un frame de operaciones background. Para las operaciones interactive es realmente muy similar, cambian un par de nombre de columnas y tablas.

Finalmente, traemos los items involucrados para constituir una dimensión de ellos. Sería bueno que al integrarlos comparemos el destino para ver de agregar únicamente las filas nuevas.

Así constituimos las 4 tablas que podrán ejecutarse cada día para ir construyendo un histórico.

Pueden repasar el Notebook completo en mi GitHub.

Espero que les sea de utilidad y puedan almacenar las operaciones historicas ordenadas en este modelo estrella sencillo de dimensiones de timepoints e items con hechos de operaciones background e interactivas.

[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.

[ibarrau]

[PowerBi] Efectos en botones mouse over

Si bien hay mucho escrito sobre botones en PowerBi y en este blog se ha escrito bastate sobre el tema, no he visto en mucho tiempo el uso de estos efectos para mejorar la experiencia de usuario.

Este artículo nos mostrará una forma de acondicionar los botones para dar una grata experiencia similar a la que podemos apreciar en distintos sitios y sistemas de información. Se trate de jugar con cambios al posicionar el mouse por encima. Si, muchos dirán, "obvio que cambio el background al pasar el mouse para que se vea lindo". Bueno pues aqui mostraremos otras dos ideas diferentes a pintar el background.

Antes de comenzar me gustaría aclarar una regla de oro para lograr una grata experiencia de usuarios con botones. Con esto me refiero a dar evidencia al usuario respecto a cual es el botón actualmente seleccionado frente a otros. Puede sonar sencillo y muchos dirán que el navigator que existe hoy lo resuelve, pero cuando queremos llegar más lejos con los efectos, necesitaremos un poco de creatividad retro con nuestros amigos bookmarks.

NOTA: Si no conoces como delimitar sencillamente un botón seleccionado pintando su fondo, podes revisar este artículo.

A continuación vamos a ver dos efectos por separado que tranquilamente podrían aplicarse juntos.

Subrayado por sobre fondo

Lo más natural al generar botones es concentrase en el fondo que presentan, tanto para la selección como para el paso del mouse. Sin embargo, si prestamos atención a la web, podremos apreciar que un efecto mucho más liviano a la visa aparece con titulos subrayados.

Con un simple subrayado puedo apreciar rapidamente cual es el botón seleccionado en este momento. También puedo jugar con el mismo efecto para cuando el cursor se posiciona por encima de las otras medidas.

Para construirlo vamos a necesitar de dos botones (el activo y el inactivo como en el artículo anterior) y una linea horizontal común. El botón inactivo en su estado común presenta un fondo sólido (transparencia 0%) con exacto decimal que el fondo que posee con letra gris. Mientras que su estado al pasar el mouse por encima presenta letra blanca y fondo transparente 100% para hacer visible la línea que hay por detrás.

Cuando clickeamos el botón activo, es decir el que lleva el estado actual de lo que vemos, permance oculto hasta clickear el botón. Luego de clickearlo con bookmarks lo haremos visible. Este botón esta posicionado exactamente encima del inactivo. Mientras el botón activo este visible vamos a ocultar el inactivo. El botón activo tendrá como "Default" las mismas propiedades que "On Hover" del inactivo, de manera que haga visible la línea horizontal y letra blanca. Veamos como queda todo armado:

Si nos fijamos este efecto podría ser transferido tranquilamente al menú de la izquierda también con una línea vertical.

Espaciado de movimiento

Aún que Power Bi no tenga visualizaciones que nos permitan jugar mucho con efectos de movimiento, algunas veces podemos simularlo. En este caso vamos a simular un ligero movimiento del texto hacia la derecha cuando posicionamos el cursor por encima del botón. Para lograrlo nuevamente vamos a utilizar 3 elementros, dos botones y una línea vertical. La diferencia en esta oportunidad es que no vamos a cubrir la línea de forma simple como antes sino que vamos a ocultarla y mostrarla. ¿Por qué la complicaríamos de ese modo? simplemente porque el fondo tiene un grandiente. En esos casos no podemos hacer que el botón en estado por defecto la oculte porque sería muy complejo lograr el mismo efecto en el fondo del botón. Por ello vamos a tener las líneas ocultas hasta que el botón sea presionado y la refleje en definitiva.

Para lograr este efecto veamos pondremos el botón inactivo con texto gris sin fondo y el truco estará en su estado "On Hover". En ese estado vamos a colocar carateres invisibles.

¿Qué es un caracter invisible? El texto invisible o caracteres invisibles se refiere a caracteres especiales que no pueden ser vistos en la pantalla pero son tratados como letras normales.

Nuestro texto al pasar el mouse comenzará con caracteres invisibles de manera que genere el efecto de que el texto se mueve levemente a la derecha al pasar por encima. Algo así:

Fijense que parece que hubiera espacios al inicio, pero no son espacios.

Aquí dejo los caracteres por si quieren copiarlos: ‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎<- atrás de la fecha. Si quieren comprobar que no es broma ni nada, pueden pegar el texto en Notepadd++ (que es capas de reconocerlos) y verán algo así:

La magia del movimiento ya está. Ahora ¿Cómo sigue la experiencia de usuario? con la regla de oro. Al hacer click vamos a ocultar el botón inactivo para hacer visible la línea vertical y el botón activo que en este caso tiene el texto pintado del mismo color que la línea.

Veamos como queda:

Esto fue todo, espero que les traiga nuevas ideas para ir reflejando nuevas experiencias amigables y similares a aplicaciones web que vemos diariamente. Recuerden que pueden combinar ambos efectos. Podríamos tener la lista vertical mostrando la línea vertical ademas de moverse.

[ibarrau]

Estrategia para licencias PowerBi - Fabric

La popularidad de Fabric no para de extenderse y eso hace que cada vez más aparezcan confusiones y dudas sobre licencias. Cada día llegan más dudas sobre el formato de licencias y como encaja lo nuevo en lo viejo. Dentro de esas dudas aparecen muchas alternativas para manejo de licencias.

En este artículo vamos a hablar de puntos medios y grises para optimizar costos de nuestras licencias encontrando el mejor balance con los nuevos planes que nos ofrece Fabric.

Primero vamos con conocimientos básicos de licencias en este antiguo artículo que escribí. En el mismo vamos a conocer detalles de las licencias disponibles en julio 2024.

Si ya conocen las de PowerBi, lo nuevo es Fabric. Una licencia por capacidad que viene a expandir los artefactos o contenidos que podemos crear dentro de un área de trabajo. Sus planes inician con valores más económicos que las capacidades anteriores, lo que permiten que todo tipo de organización pueda acceder al uso de éstos artefactos. Sin embargo, el uso de los tradicionales contenidos de PowerBi siguen bajo el mismo esquema.

La estrategía de optimización se base específicamente en los usuarios. Si tenemos capacidades dedicadas... ¿Por qué pagamos licencias por usuarios? esta es la pregunta que trae el principal contexto y razón del artículo. A las organizaciones les cuesta este concepto, más aún viendo que los contenidos de Fabric no necesitan licencias de usuario. No necesitamos una licencia PRO para desarrollar un notebook, escribir en Onelake o consultar un warehouse con SQL. Para resolver esta paradoja vamos a dividir nuestro enfoque en los dos tipos de usuarios, desarrolladores y visores.

Enfoque de Visores

Algo que suele trae mucho dolor a organizaciones que usan PowerBi es que los visores en entornos de capacidad compartida (pro o ppu), tengan que pagar licencia. Uno puede pensar que pagando una "Capacidad Dedicada" como premium lo soluciona, sin embargo premium va a desaparecer y quedará Fabric. Muchos podrán pensar que esta es la solución definitiva, puesto que Fabric comienza con planes muy económicos, pero no es cierto. La característica de compartir con usuarios gratuitos comienza en un plan F64, cuyo costo ronda entre 5000 y 8000 dolares (dependiendo el tipo de pago). Lo que nos hace pensar que valdría la pena si nuestra operación interna cuenta con más de 500 usuarios visores de PowerBi (puesto que una licencia pro sale 10 dolares). Ciertamente, un número que solo grandes empresas pueden considerar.

Entonces, ¿Qué hacemos cuando no podemos pagar ese monto? Si podemos comprar capacidades dedicadas más chicas, ¿Cómo podríamos compartir a usuarios visores sin pagarles licencias Pro? La respuesta es una característica bastante olvidada en el entorno de analytics. Estoy hablando de la feature de "Embedded". PowerBi cuenta con una compleja pero poderosa posibilidad de embeber informes en aplicaciones web con grandes posibilidades. Una de esas posibilidades es delegar la seguridad y loguear a la aplicación que refleja los informes. De ese modo, podríamos compartir a todos los usuarios visores que querramos sin pagar licencias. Sin embargo, no es tan simple puesto que necesitaríamos un potente equipo de desarrollo que construya esta web app aprendiendo todos los enfoques de power bi con especial atención a la seguridad, dado que ahora es responsabilidad nuestra (nos la delega microsoft al usar embedded).

Si no tenemos equipo de desarrollo y queremos aprovechar esa capacidad. ¿Cómo lo resolvemos?. La opción más viable sería comprando un producto de un tercero. Varias instituciones proveen este tipo de software. Por ejemplo, una que conozco en español es PiBi. PiBi es una plataforma web como servicio (SaaS) que usa la característica de Power Bi Embedded.  Una construcción que interactúa con tu entorno de Azure y te permite distribuir informes de PowerBi de manera segura, simple y eficiente.

¿Qué ventajas encontramos si nos embarcamos en este camino?

Operación de informes en un solo lugar

Más sencillo de usar que Fabric/PowerBi Service

Compartir con usuarios externos a la organización

Logins SSO Google/Microsoft

Mantener seguridad y privacidad

El requerimiento para usar Embedded es tener una licencia por capacidad. Herramientas como ésts pueden partir de valores como 450 dolares por mes, que junto a una licencia básica de Fabric con pago anual de 150 dolares son 600 dolares. Si nuestra operación de usuarios internos ronda entre 60 y 500 usuarios, encaja perfectamente para optimizar nuestra estrategia de Power Bi. Por supuesto, que habría detalles como si tenemos modelos y mucho volumen de datos, puede que necesitemos un Fabric un poco más elevado, pero deberíamos pensar a ese como costo de almacenamiento y no de distribución de contenido a los usuarios.

Enfoque de desarrolladores

En la mayoría de los casos, lo primero que normalmente tendería a evolucionar, son los visores. Una vez encontrado un punto de madurez en ellos, seguirá esta propuesta. Esto quiere decir que lo más probable es que YA contemos con capacidad dedicada (para usar la feature embedded). Pero no desesperen si no la tienen, esta estretegia es totalmente viable sin capacidad tal como lo explico en este otro artículo. Las estrategias no estan ligadas una a otra, aunque son poderosas juntas.

El eje para liberar a los usuarios desarrolladores de sus licencias es pensar en desarrollo de software convencional. Si pensamos en la industra de software, un desarrollador, sea backend o frontend, tiene como trabajo solamente desarrollar. Su eje y foco esta en construir. Hoy esos roles no hacen integración de soluciones, implementaciones o deploys, puestas en producción, etc. Existen roles como DevOps que ayudan a delegar la construcción final.

Tomando este enfoque como guía, si queremos que los desarrolladores de PowerBi no usen licencias, debemos concentrarnos en lo básico, un repositorio. Hoy Fabric nos da la posibilidad de integrar repositorios de GIT con Áreas de Trabajo. Esto no solo nos ayuda a que el desarrollador ni piense en Fabric o PowerBi Service, sino que también almacena los desarrollos en formato Power Bi Project que nos deja mergear código. Si queremos ver eso en más profundidad pueden abrir éste artículo.

Así los desarrolladores de Power Bi. Solo desarrollarán. Comienzan el día armando o con un pull a su branch de repositorio, comiteando cambios y al terminar un push. Ni piensa ni escucha quienes ven que informes y donde está. Luego podemos pensar en otro perfil que podemos decirle Admin del Area o DataOps que garantice que los reportes están en el lugar apropiado o sean automáticamente deployados. Veamos un poco más gráfico esto:

Vean como Local Machine nunca ve Fabric. El desarrollador no necesita ingresar al portal web. Solo necesitamos licencias para DataOps o Administradores de areas. Así es como reducimos licencias y ganamos robustez y soluciones tanto versionables como escalables.

Se que fue mucho texto pero espero que haya sido a meno y les traigan nuevas ideas para optimizar efectivamente la operación y licencias de sus entornos.

[ibarrau]

[SimplePBI] Importar archivo de PowerBi de Github o Azure DevOps

Cada día aparece más y más métodos que ayudan a generar flujos de trabajo para los desarrollos analíticos que nos ayuden a versionar las soluciones. Muy a la par aparece el tema de deploys automáticos.

Seguramente leyendo por internet encontraremos muchos artículos que informan que solo es posible implementar PowerBi entre ambientes con Deployment Pipelines o usando Pipelines de Azure DevOps y seguramente pronto aparecerán con Github actions. Me gusta diferir pensando que podemos nosotros armar nuestros flujos con nuestro propio código.

En este artículo veremos como importar un archivo.pbix de un repositorio en Power Bi Service.

Todos los días son más y más los proyectos y empresas que comienzan a entender la importancia de versionado. Lo que lleva a la necesidad de trabajar nuestras soluciones con repositorios. Por la naturaleza de la tecnología Microsoft seguramente el 90% de los involucrados utilizan Azure DevOps o Github.

Cada una de las herramientas no solo tiene repositorio versionado, sino también otras herramientas para ayudarnos con flujos automáticos. La realidad es que esos flujos no son simples de entender ni construir. Me he encontrado con personas abrumadas y desanimadas por la compleja tarea de usarlos para implementar soluciones CI/CD. Esta clarísimo que por algo existen los Roles de DevOps.

Pensando en que hoy existe una gran versatilidad en como usar la tecnología es que LaDataWeb implementó en el desarrollo de la librería de Python para usar la PowerBi Rest API (SimplePBI), la posibilidad de importar archivos.pbix de nuestros repositorios directo a un área de trabajo de Power Bi.

No será el flujo más perfecto y robusto para enormes soluciones analíticas, pero si uno simple para mantener simple un deploy automático de pequeñas soluciones. Con pocas líneas de python podríamos tener un script que se encargue de implementar automáticamente estos archivos en Áreas de Trabajo. Esto podría fácilmente ser implementado en algún servicio cloud que permita ejecutar código como Azure Automation Runbooks, Azure Functions, AWS Lambdas o inclusive podría estar dentro de los pipelines o github actions antes mencionadas.

Azure DevOps

Para poder obtener acceso a nuestros archivos de repositorio por código, necesitamos crear un "Personal Access Token". La creación es tan simple como la siguiente imagen:

La pantalla de creación basta con delimitar un nombre, fecha de expiración (un año máximo) y el permiso al código como se ve en la imagen:

Luego de crear nos muestra la clave.

NOTA: copien la clave en ese momento porque luego no podremos volver a verla de nuevo.

Ahora si contamos con la clave de acceso para hacer el import de nuestro .pbix. Por ejemplo, yo tengo un archivo en mi repositorio con la siguiente dirección:

Para importarlo vamos a ejecutar sl siguiente código que autentica a la PowerBi Rest API como hacemos en otros posts y tiene valores adicionales para conectarnos a DevOps

Código aqui.

Fíjense como la imagen de la dirección que les mostré tiene lo que necesitamos. Organización es el primer valor de la dirección que vemos en DevOps, luego sigue el nombre de proyecto. A la derecha en con ícono rojo se ve el nombre del repositorio (en este caso coincide con el proyecto). La dirección o path la veíamos bajo una sola carpeta "Blogging". Autenticamos con la clave que creamos hace un momento. Finalmente, delimitamos en que área de trabajo de service queremos guardarlo. Veamos un simple gif del deploy en acción:

Github

Al igual que antes, para poder leer los archivos de nuestro repositorio, es necesario crear un token de autenticación. Lo primero es ir al ícono de nuestro perfil y abrir la configuración. Luego buscaremos configuración de desarrollador "developer settings". Ahi encontraremos las Personal Access Token:

Aquí vamos a generar una Token (classic) con permisos al repositorio como hicimos antes. Veamos como es la dirección y valores de nuestro archivo en el repo de github:

Nuestro código:

Código aqui.

Ahora tenemos otros valores aunque parecidos. El Owner del repositorio, el nombre y la dirección. Eso acompañado de la clave que generamos en un principio. Veamoslo en acción:

Así llegamos al final de nuestro artículo mostrando como un simple código puede importar archivos de powerbi desktop a service. El flujo queda en nuestra creatividad. Por ejemplo, podrían ser azure functions corriendo una vez a la semana por cada carpeta del repositorio, pensando una carpeta por area de trabajo. De esa forma tendríamos deploy continuos de una carpeta como si fuera un área de trabajo. ¡La creatividad es el límite! sobre todo para quienes solo usen licencias PRO.

[ibarrau]

[PowerQuery] Combinar tablas de cualquier origen

Power Query ha demostrado ser un gran asistente en materia de experiencia de usuario y potencialidad. Sin embargo, eso no quita que sus acciones automáticas resuelvan todo de la mejor manera o que alguna acción no disponible en los botones no esté disponible.

Cuando trabajamos con particiones de archivos, tablas, etc. El motor podría sugerir combinar archivos si todo coincide con algunos parametros o detalles como así también podría no hacerlo. Éste artículo nos guiará a combinar Tablas sin importar la sugerencia del motor. Si sabemos que los json, excel, csv, tablas web o lo que sea coincide en estructura, podemos combinarlo.

Cuando hablamos de combinar, seguramente se les venga a la cabeza la sugerencia tradicional del motor con botones. Este método busca combinar archivos binarios (ej: csv) con el botón en vista de la carpeta:

Este puede ser el punto de partida para comprender lo que sucede y copiarlo en otro tipo de archivos de forma más simple. Veamos lo que sucede

El motor genera una prueba de formato de la tabla, parametro, lista y una función. Básicamente toma de ejemplo el primer archivo para aprender a leer el csv con las delimitaciones y separadores correspondientes y luego combinar esos resultados. Adicionalmente, nos agrega cuatro pasos a nuestro script definitivo y no resuelve la unificación de headers/columnas. Podrán apreciar que por cada archivo tendríamos las cabeceras sueltas.

No solamente seguiríamos agregando pasos sino que estamos atados a la propuesta del motor, ahora ¿Y si el botón no aparece? estaríamos en más problemas aún.

Combinar tablas escribiendo código

Puede sonar desafiante, pero no es nada que no podamos guiarnos de lo que el motor genera. Por ejemplo, si copiamos la función Table.PromoteHeaders y Csv.Document, nos bastaría para interpretar un archivo binario. En lugar de crear tantos recursos y pasos, nos bastaría con agregar una columna que lea los archivos binarios en tabla cuando estamos explorando la carpeta de archivos. Algo así:

Table.PromoteHeaders( Csv.Document([Content],[Delimiter=";", Columns=11, Encoding=1252]) )

En este código usamos la primera fila como header/columnas y leer el csv con los mismos parámetros que hubiera sugerido el motor. A partir de este momento tenemos dos opciones.

Expandir tablas

El motor nos permite seleccionar el botón de la interfaz para expandir las tablas con sus filas y columnas para llegar a la combinación de los archivos

La desventaja de este procedimiento es que aún tendríamos todas las columnas iniciales con las que navegabamos entre carpetas

Combinar Tablas

La otra opción, y la que más me gusta, es combinar las tablas como siguiente resultado. Cuando estamos usando la interfaz y hacemos una unión entre tablas, podremos apreciar que el motor usa una función "Table.Combine". Nosotros nos nutriremos de esa función para que el siguiente paso a la lectura de tablas sea combinarlas sin la participación de todo el contenido anterior. La función recibe una lista de tablas para combinar. Nosotros tenemos 2 registros de tipo Table en la columna "Tablas". Para devolver esos registros como lista, podemos simplemente referenciar la tabla y la columna entre corchetes. Así podríamos invocar la función:

= Table.Combine(#"Added Custom"[Tablas])

Que nos daría el resultado esperado:

De este modo podemos combinar archivos de cualquier tipo, siempre y cuando lleven el mismo patrón de lectura (extensión, columnas, etc), con tan solo dos pasos y sin la creación de contenidos adicionales. Considero esta última opción ligeramente más rápida, pero todo dependerá del requerimiento deseado.

[ibarrau]

[Python] PySpark to M, SQL or Pandas

Hace tiempo escribí un artículo sobre como escribir en pandas algunos códigos de referencia de SQL o M (power query). Si bien en su momento fue de gran utilidad, lo cierto es que hoy existe otro lenguaje que representa un fuerte pie en el análisis de datos.

Spark se convirtió en el jugar principal para lectura de datos en Lakes. Aunque sea cierto que existe SparkSQL, no quise dejar de traer estas analogías de código entre PySpark, M, SQL y Pandas para quienes estén familiarizados con un lenguaje, puedan ver como realizar una acción con el otro.

Lo primero es ponernos de acuerdo en la lectura del post.

Power Query corre en capas. Cada linea llama a la anterior (que devuelve una tabla) generando esta perspectiva o visión en capas. Por ello cuando leamos en el código #“Paso anterior” hablamos de una tabla.

En Python, asumiremos a "df" como un pandas dataframe (pandas.DataFrame) ya cargado y a "spark_frame" a un frame de pyspark cargado (spark.read)

Conozcamos los ejemplos que serán listados en el siguiente orden: SQL, PySpark, Pandas, Power Query.

En SQL:

SELECT TOP 5 * FROM table

En PySpark

spark_frame.limit(5)

En Pandas:

df.head()

En Power Query:

Table.FirstN(#"Paso Anterior",5)

Contar filas

SELECT COUNT(*) FROM table1

spark_frame.count()

df.shape()

Table.RowCount(#"Paso Anterior")

Seleccionar filas

SELECT column1, column2 FROM table1

spark_frame.select("column1", "column2")

df[["column1", "column2"]]

#"Paso Anterior"[[Columna1],[Columna2]] O podría ser: Table.SelectColumns(#"Paso Anterior", {"Columna1", "Columna2"} )

Filtrar filas

SELECT column1, column2 FROM table1 WHERE column1 = 2

spark_frame.filter("column1 = 2") # OR spark_frame.filter(spark_frame['column1'] == 2)

df[['column1', 'column2']].loc[df['column1'] == 2]

Table.SelectRows(#"Paso Anterior", each [column1] == 2 )

Varios filtros de filas

SELECT * FROM table1 WHERE column1 > 1 AND column2 < 25

spark_frame.filter((spark_frame['column1'] > 1) & (spark_frame['column2'] < 25)) O con operadores OR y NOT spark_frame.filter((spark_frame['column1'] > 1) | ~(spark_frame['column2'] < 25))

df.loc[(df['column1'] > 1) & (df['column2'] < 25)] O con operadores OR y NOT df.loc[(df['column1'] > 1) | ~(df['column2'] < 25)]

Table.SelectRows(#"Paso Anterior", each [column1] > 1 and column2 < 25 ) O con operadores OR y NOT Table.SelectRows(#"Paso Anterior", each [column1] > 1 or not ([column1] < 25 ) )

Filtros con operadores complejos

SELECT * FROM table1 WHERE column1 BETWEEN 1 and 5 AND column2 IN (20,30,40,50) AND column3 LIKE '%arcelona%'

from pyspark.sql.functions import col spark_frame.filter( (col('column1').between(1, 5)) & (col('column2').isin(20, 30, 40, 50)) & (col('column3').like('%arcelona%')) ) # O spark_frame.where( (col('column1').between(1, 5)) & (col('column2').isin(20, 30, 40, 50)) & (col('column3').contains('arcelona')) )

df.loc[(df['colum1'].between(1,5)) & (df['column2'].isin([20,30,40,50])) & (df['column3'].str.contains('arcelona'))]

Table.SelectRows(#"Paso Anterior", each ([column1] > 1 and [column1] < 5) and List.Contains({20,30,40,50}, [column2]) and Text.Contains([column3], "arcelona") )

Join tables

SELECT t1.column1, t2.column1 FROM table1 t1 LEFT JOIN table2 t2 ON t1.column_id = t2.column_id

Sería correcto cambiar el alias de columnas de mismo nombre así:

spark_frame1.join(spark_frame2, spark_frame1["column_id"] == spark_frame2["column_id"], "left").select(spark_frame1["column1"].alias("column1_df1"), spark_frame2["column1"].alias("column1_df2"))

Hay dos funciones que pueden ayudarnos en este proceso merge y join.

df_joined = df1.merge(df2, left_on='lkey', right_on='rkey', how='left') df_joined = df1.join(df2, on='column_id', how='left')Luego seleccionamos dos columnas df_joined.loc[['column1_df1', 'column1_df2']]

En Power Query vamos a ir eligiendo una columna de antemano y luego añadiendo la segunda.

#"Origen" = #"Paso Anterior"[[column1_t1]] #"Paso Join" = Table.NestedJoin(#"Origen", {"column_t1_id"}, table2, {"column_t2_id"}, "Prefijo", JoinKind.LeftOuter) #"Expansion" = Table.ExpandTableColumn(#"Paso Join", "Prefijo", {"column1_t2"}, {"Prefijo_column1_t2"})

Group By

SELECT column1, count(*) FROM table1 GROUP BY column1

from pyspark.sql.functions import count spark_frame.groupBy("column1").agg(count("*").alias("count"))

df.groupby('column1')['column1'].count()

Table.Group(#"Paso Anterior", {"column1"}, {{"Alias de count", each Table.RowCount(_), type number}})

Filtrando un agrupado

SELECT store, sum(sales) FROM table1 GROUP BY store HAVING sum(sales) > 1000

from pyspark.sql.functions import sum as spark_sum spark_frame.groupBy("store").agg(spark_sum("sales").alias("total_sales")).filter("total_sales > 1000")

df_grouped = df.groupby('store')['sales'].sum() df_grouped.loc[df_grouped > 1000]

#”Grouping” = Table.Group(#"Paso Anterior", {"store"}, {{"Alias de sum", each List.Sum([sales]), type number}}) #"Final" = Table.SelectRows( #"Grouping" , each [Alias de sum] > 1000 )

Ordenar descendente por columna

SELECT * FROM table1 ORDER BY column1 DESC

spark_frame.orderBy("column1", ascending=False)

df.sort_values(by=['column1'], ascending=False)

Table.Sort(#"Paso Anterior",{{"column1", Order.Descending}})

Unir una tabla con otra de la misma característica

SELECT * FROM table1 UNION SELECT * FROM table2

spark_frame1.union(spark_frame2)

En Pandas tenemos dos opciones conocidas, la función append y concat.

df.append(df2) pd.concat([df1, df2])

Table.Combine({table1, table2})

Transformaciones

Las siguientes transformaciones son directamente entre PySpark, Pandas y Power Query puesto que no son tan comunes en un lenguaje de consulta como SQL. Puede que su resultado no sea idéntico pero si similar para el caso a resolver.

Analizar el contenido de una tabla

spark_frame.summary()

df.describe()

Table.Profile(#"Paso Anterior")

Chequear valores únicos de las columnas

spark_frame.groupBy("column1").count().show()

df.value_counts("columna1")

Table.Profile(#"Paso Anterior")[[Column],[DistinctCount]]

Generar Tabla de prueba con datos cargados a mano

spark_frame = spark.createDataFrame([(1, "Boris Yeltsin"), (2, "Mikhail Gorbachev")], inferSchema=True)

df = pd.DataFrame([[1,2],["Boris Yeltsin", "Mikhail Gorbachev"]], columns=["CustomerID", "Name"])

Table.FromRecords({[CustomerID = 1, Name = "Bob", Phone = "123-4567"]})

Quitar una columna

spark_frame.drop("column1")

df.drop(columns=['column1']) df.drop(['column1'], axis=1)

Table.RemoveColumns(#"Paso Anterior",{"column1"})

Aplicar transformaciones sobre una columna

spark_frame.withColumn("column1", col("column1") + 1)

df.apply(lambda x : x['column1'] + 1 , axis = 1)

Table.TransformColumns(#"Paso Anterior", {{"column1", each _ + 1, type number}})

Hemos terminado el largo camino de consultas y transformaciones que nos ayudarían a tener un mejor tiempo a puro código con PySpark, SQL, Pandas y Power Query para que conociendo uno sepamos usar el otro.

[ibarrau]

[PowerBi] Catálgo de diseños para reportes

Hace tiempo he escrito un artículo para tener presente que la UI puede manipularse y mejorarse por herramientas terceras. Ciertamente, no es algo para tomar a la ligera, lleva su tiempo aporta un enorme valor para el usuario final.

En este artículo reflejé una, de muchas formas, que podemos usar para construir fondos para nuestros informes de PowerBi. Usando PowerPoint, podemos delimitar colores, sombras, espacios, alineamientos, etc. Las prestaciones de manipulación de formas y colores es mayor que lo que PowerBi nos represente. Sin duda, podemos hacer mucho en el canva de PowerBi, pero... ¿a que precio.? Tal vez generar un buen fondo nos tome el agregado de 15 formas. No es lo mismo que el fondo sea una imagen a que PowerBi renderice 15 elementos antes de siquiera pensar en sus números.

Como regalo para este mes de mi cumpleaños, quise entregar una nueva sección de LaDataWeb inspirada en Temas, Plantillas, Themes, Templates o como quieran llamarle.

Me alegra mucho presentarles este nuevo espacio "Temas". En él encontraran un pequeño catálogo de ejemplos UIUX para tableros que nos ayudaría a inspirar nuevas ideas.

Así mismo incorporé la posibilidad de descargarlo en máximo detalle, puesto que el .zip incluye:

Archivo.pbix

Imagen vácio de fondo

Imagen de Dashboard ejemplo de como desarrollar encima del fondo

Tema.json

Con esto serán capaces de llevar más comodamente los tableros que quieran hacer igual o guiarse a partir de uno de los ejemplos.

Hay también un enlace a GitHub en caso que quieran aportar algunos ustedes como contribuyentes de este catálogo.

Link al sitio: https://www.ladataweb.com.ar/templates.html

¡Espero que lo disfruten y traiga nuevas ideas para sus proyectos!