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.