Saltar al contenido

Microsoft Fabric y la transformación estructural del analista

Una plataforma cuya principal premisa es la integración bajo un mismo bloque y la posibilidad de habilitar servicios en cuestión de segundos con apenas un par de clics. El concepto de «copiar datos» se interpreta como algo opcional, tóxico ante la proliferación de silos de datos. Aquí dan vida nuevos lenguajes, arquitecturas y practicas de ingeniería de datos que modifican la forma clásica de desarrollar modelos semánticos.

Eso y mucho más es Microsoft Fabric.

Recordemos un poco…

Power BI fue presentado a mediados del año 2015 como el programa que permitió a los usuarios de negocio utilizar la potencia de motores analíticos empresariales (antes exclusivos para profesionales de TI), envuelto en un caramelo, que además incluye otro motor de transformación, siendo el lenguaje «M» presente en Power Query, y una capa de visualización moderna, interpretada en sus inicios como algo interactivo –¡Un dashboard interactivo! algo que hoy en día sería obvio– arrastrando y soltando elementos al canvas. Por casi 11 años, y distintos licenciamientos que han tenido hogar en el Servicio de Power BI (nube) han ofrecido características técnicas que se adaptan a pequeñas, medianas y grandes organizaciones.

The world is not enough…

Con el paso de los años se separaron las aguas: usuarios de negocio y la organización como eje monolítico.

El detonante fue tener todo en un mismo lugar. El archivo de Power BI Desktop con extensión .pbix contiene las conexiones iniciales, transformaciones, modelado de datos, cálculos en DAX, datos (copiados y comprimidos) las hojas de reporte, reglas de seguridad y todos los metadatos necesarios para funcionar posteriormente en la nube.

Arquitectura clásica en Power BI Service. Un archivo .pbix contiene todo lo necesario para consumir reportes en la nube.

 

Disponer de archivos con datos comprimidos a una tasa de 20-25x y con toda una estructura analítica incorporada es muy práctico para cualquier usuario. Sin embargo, desde la mirada organizacional es todo lo contrario. Trabajar en equipo de forma simultanea, aplicar controles de versión, separar el almacenamiento, y adaptar un producto evidentemente enfocado al usuario, y no a la organización fue limitando su crecimiento. Hubo alternativas con mejoras sustanciales (no es que no hayamos visto opciones) sino que de una forma u otra se percibían como «piruetas» que no escalaban del todo.

Microsoft Fabric

Lo primero que genera Fabric en el analista de datos que ha utilizado Power BI de forma clásica es que ha perdido el control.

La responsabilidad se concentraba en una sola persona (principalmente), ahora, los roles de ingeniería y arquitectura de datos se hacen presentes para identificar y crear las estructuras –items– en Fabric que serán necesarios para separar por etapas o secuencias lo que el archivo de Power BI Desktop (.pbix) ejecuta internamente de forma local.

Al separar la ingesta, almacenamiento, procesamiento y la visualización se tiene la capacidad de seguir punto a punto el ciclo de vida del dato.

Y esto, es precisamente lo que las organizaciones requieren cuando la gobernancia no puede estar supeditada a un solo y único archivo.

En Microsoft Fabric las arquitecturas se adaptan al escenario. El archivo .pbix deja de existir.

 

Desde un punto de vista visual se infiere que el nivel de complejidad ha aumentado. Y, en efecto, es lo que sucede. Por mucho que queramos simplificar el cambio, existen nuevos lenguajes disponibles (SQL, PySpark, KQL, Python, etcétera), métodos de conexión, prácticas que ahora son puestas en juicio y, lo más crítico: aparece el consumo por capacity unit, siendo la unidad de medida que se utiliza en Fabric por el consumo de recursos distribuidos entre los servicios que se hayan habilitado y su posterior consumo entre los usuarios finales.

Por esa razón, el analista clásico se verá una encrucijada: concentrar sus conocimientos en las áreas donde ahora tendrá un rol específico, o expandir su visión hacia las aquellas que ahora son ejecutadas por otros servicios donde no es obligatorio utilizar los mismos lenguajes ni las practicas conocidas.

La decisión de migrar a Microsoft Fabric se podría pensar que se inclina por una sola vertiente; pero esto va más allá, desde el componente humano, los límites técnicos, los aspectos operacionales y la visión organizacional en conjunto o de forma aislada puede justificarlo; pero de eso hablaremos en otro momento.

Video relacionado: De Power BI Service a Microsoft Fabric: la arquitectura que sí escala

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *