NOTA: Este artículo se escribió originalmente en crosspoint365.com el 5 diciembre 2024. Si lo prefieres puedes leer la publicación original.
Microsoft Fabric lleva alrededor de un año entre nosotros y el interés que despierta, por la cantidad de funcionalidades que incorpora y la gran ventaja de unificarlas en un mismo entorno, es grande.
Su acogida ha sido apasionada por los que estamos en la parte técnica, y con años trabajando con Power BI, pero quizá algo más tímida por los clientes…
Dejando aparte los proyectos en los que no se justifica una infraestructura tan compleja como la de Fabric, en los casos que sí, me atrevería a decir que su sistema de precios tiene mucho que ver, pues es difícil de comprender. Doy fe: es difícil de explicar.
Intentaré hacerlo en este post, siguiendo un caso práctico, por si te puede ayudar a aclararte.
En este post:
Escenario del caso
Una empresa que tiene Dynamics 365 FO y un Dawarehouse (DW) en Azure SQL Server.
Por medio de BYOD se hace un traspaso de datos de DFO a SQL varias veces al día.
A partir de los datos en el DW, se realizan transformaciones que vuelcan a otra base de datos SQL, en la se dispone de las tablas con las dimensiones y hechos necesarias para nuestros modelos de datos de Power BI.
No quiero extender las premisas con asuntos como gobernanza, herramientas adicionales, etc, pero sí destacar que en este caso práctico, mantener el sistema actual no es particularmente eficiente y tiene un coste relativamente alto…
En esta situación se están planteando la migración a Fabric y quieren hacer una estimación del coste de los componentes requeridos.
Vamos allá.
Primero, estimar la capacidad a contratar
Fabric es una plataforma unificada de componentes, herramientas… como quieras llamarlo, que van a funcionar dentro de una capacidad. Asimilemos la capacidad a una máquina virtual. Más memoria, procesador… harán que esa máquina virtual funcione mejor. También tendrá un coste más alto. Lo mismo pasa con las capacidades disponibles que cada una de esas máquinas proporciona, que se miden en Capacity Units (CU). Más CU, mejor… y más caro.
La tabla de precios para las capacidades es la siguiente (los precios pueden sufrir modificaciones en el tiempo):
F2 ofrece 2 CU, F4 ofrece 4… Y en un primer momento hay que hacer una estimación de qué Fx puede ser la más adecuada: la que equilibre coste con CU necesarias para realizar de forma solvente todas las tareas por los componentes que usemos de Fabric. Esos componentes, aplicados a datos, pueden ser transformaciones, traspasos, visualización, algoritmos ML… Y unos consumen más CU que otros. Volveremos a ello después.
La elección de una capacidad inicial no impide que más adelante podamos cambiarla por otra menor o mayor.
Los precios mostrados son por capacidad funcionando por mes completo. Si no consumes más CU de los que la capacidad ofrece, es lo que pagarás (por este concepto).
La capacidad puede arrancarse/pausarse para su uso en los momentos que se requiera y esto contribuye a aminorar el coste. Por ejemplo, aquí vemos un gráfico de Fabric Capacity Metrics (después profundizamos en esto) en el que se ve una capacidad que se apaga los fines de semana y durante el resto de semana uso queda acotado a la jornada laboral:
Queda por añadir que el coste de Fabric depende también de la región elegida: si es West Europe el precio puede variar (algo) respecto el de North Europe. La elección de zonas en el tenant es relevante también a otros efectos, como creación de shortcuts, etc… Pero eso da para otro post.
Pero antes ¿qué es un CU?
Aclarar el concepto de CU es vital para comprender el coste.
Veamos el caso de una capacidad F4, que te proporciona 4CU por segundo. En una hora dispones de 14400 CU:
Si durante esa hora consumes menos de 14400 CU, vas a pagar eso, aunque no consumas o consumas solo 100 CU (recuerda, mientras tengas en marcha la capacidad).
El consumo de CU se calcula en franjas de 30 segundos, y esta es la unidad de facturación. En 30 segundos dispongo de 120 CU.
Bien, ahora es el momento de presentar el informe de que te permite ver el consumo de CUs. Microsoft Fabric proporciona una aplicación de Power BI para este propósito, Microsoft Capacity Metrics, que puedes obtener del App Store:
En el mismo puede verse cómo se distribuye el consumo de CU´s de los últimos 15 días en una capacidad seleccionada:
Como puede verse, se diferencian los tipos de actividad realizados, Dataflow, Lakehouse… y lo que ha consumido cada una. Además, agrupa las actividades de background (dataset, dataflow,.. todo lo que suponga actualizar datos) y actividades interactivas (como consultar un informe).
Si nos centramos en un día y ampliamos la ejecución por minutos podemos ver los detalles de ejecución en ese momento:
Vemos que en ese tiempo disponías de 120 CU’s pero se han consumido más de 40.000. En este caso todas son tareas de background, lo que supone haber usado un 33702% de la capacidad. Más de lo que mi capacidad permite durante ese período ¿Cómo es eso?
Es un consumo instantáneo sobre el que se hace un alisado (smoothing).
Supongamos que esta capacidad está permanentemente conectada.
Los trabajos de background se promedian a 24 horas (el promediado que hace Microsoft de las interactivas no está concretado).
Dentro de esas 24 horas… ¿Cuántas franjas de 30 segundos hay? 2880. Y el alisado se hará repartiendo el consumo entre esas 2880 franjas.
Así, una tarea que consuma 21254 CU’s, al dividirse entre 2880 franjas, en cada una de ellas imputa un consumo de 7.38 CU’s cada 30 segundos. Recuerda que en el ejemplo dispones de 120 CU’s cada 30 segundos.
Esto se hace así para no dejarte bloqueado (throttling) cada vez que te pases de los límites de tu capacidad. Si te pasas, Microsoft te presta CU’s , a devolver en cómodos plazos de 30 segundos (bursting). Si te pasas demasiado, te bloquea. Y si no llegas, estás pagando en exceso.
¿Y si detengo la capacidad? Se te facturará lo pendiente.
Hay que indicar que, a diferencia de las tareas de background, el alisado de tareas interactivas es cada 5 minutos y a partir de ahí una aritmética similar.
Volviendo a nuestro caso práctico
Todos los números anteriores surgen de un análisis post mortem, o sea, ya con un proyecto Fabric realizado. Sin lanzarse a la piscina, habría sido difícil hacer una estimación más o menos precisa de lo que hubiese sido el coste esperado. Pero sabiendo que para una capacidad determinada tienes los costes ‘máximos’, a partir de ahí se trata optimizarlos.
Para un F4 con procesos optimizados, ejecutándose en jornada laboral (de 8:00 a 18:00) el coste de Fabric puede rondar unos 200€. Y si se sacan los informes de Power BI a un área de trabajo Pro, se puede reducir más. Además, con unos tiempos de proceso muy inferiores a los del planteamiento inicial y en un entorno unificado de procesado y analítica.
También pesa en la consideración el hecho de que el Synapse Link/Link to Fabric, utilizado para sincronizar la información de Dynamics DFO con Fabric, nos proporcionará información actualizada del ERP automáticamente, sin mediar más intervención que conectar las tablas que nos interesen en el proyecto, y aparecerán disponibles en nuestro lakehouse de Fabric, listas para consumir.
Conclusiones
La primera conclusión que podemos extraer es que es importante saber optimizar para reducir el consumo de CU’s. La calidad de los trabajos realizados en este sentido es crítica, por eso es conveniente que seas concienzudo o te pongas en buenas manos, pues de eso depende el coste, muy asequible para todo lo que Fabric ofrece, o disparatado si no se tienen en cuenta los ‘detalles’.
La segunda es que no todas las actividades valen lo mismo. Por ejemplo, para hacer lo mismo es más barato (y en ocasiones, más rápido) usar un Notebook que un dataflow. Claro, también es verdad que uno tiene una curva de aprendizaje mucho más elevada que el otro.
Finalmente, que en determinadas arquitecturas, como la del ejemplo con Dynamics DFO y Fabric Link, la sincronización de datos queda limitada a marcar las tablas que necesites en tu lakehouse con un simple checkbox, sin mantener arquitecturas adicionales.
Esperamos que te haya quedado un poco más claro el sistema de costes y cómo optimizarlo para que no se nos vaya de las manos. Si necesitas saber más o crees que podemos ayudarte con los proyectos de Fabric en tu organización, no dudes en contactar con nosotros.
Apasionado de las tecnologías de análisis de datos y Business Intelligence, y con larga experiencia en el uso de las mismas en empresas de todos los sectores, tamaños, y proyectos de diversa complejidad, en los cuales disfruto creando, planteando y desarrollando soluciones.
Tengo una curiosidad insaciable y demasiadas aficiones, entre ellas tocar el bajo con mi grupo.