En SolidQ, un tema que se nos plantea habitualmente en todos los proyectos es el diseño de la arquitectura. Como especialistas, una parte muy importante de nuestro trabajo es ayudar a los clientes a definir y construir una arquitectura óptima en función de las necesidades de cada proyecto, no solo para conseguir la mejor funcionalidad del mismo, sino también para construir una solución que sea escalable en el tiempo y se ajuste de la mejor forma posible al presupuesto y topología ya existente en el cliente.
Con la entrada en el mercado de Power BI, y las constantes mejoras que está recibiendo, no cabe duda de la gran apuesta que está haciendo Microsoft por este producto. Al tener una herramienta tan polivalente, en muchos casos no sabemos qué vía tomar para desarrollar un proyecto y/o cuál de ellas se ajustará mejor a nuestras necesidades a la hora del desarrollo. Por otro lado, muchos clientes están dando el salto a Power BI Premium por la necesidad de dar respuesta a algunas de las limitaciones con las que cuenta la capacidad compartida. Nos encontramos clientes que ya tienen Power BI Premium adquirido, que frente a la necesidad de evolucionar su sistema de BI/BA se plantean la duda de qué arquitectura deberían implementar.
En este artículo vamos a repasar las principales posibles arquitecturas que puede tomar un proyecto de BI, partiendo de un escenario en el que el cliente ya dispone de Power BI Premium y en el que principalmente el dato viene de orígenes ya estructurados, analizando las principales ventajas e inconvenientes de cada uno, para poder elegir siempre el mejor camino, en función de nuestras necesidades, previsión de evolución y coste.
Arquitecturas
1. Todo Power BI
Gracias a Power Query, y ahora más con dataflows, en Power BI podemos realizar, tanto el proceso de ingesta de datos de innumerables fuentes gracias a sus múltiples conectores, como la capa de transformación de datos para su posterior carga. Esto otorga a Power BI la posibilidad de ser una herramienta completa de BI, no una exclusivamente de visualización. Por tanto, la primera arquitectura que proponemos es realizar todo el proyecto en Power BI.
Analizando este tipo de arquitectura, nos encontramos con una forma de desarrollar muy centralizada, de bajo coste, pero con algunas limitaciones.
2. Power BI - DirectQuery
Dando un paso más adelante, en cuanto a adaptabilidad de la arquitectura se refiere, tendríamos el modelo con DirectQuery. Sería la opción más parecida a real time que ofrece Power BI, conectado directamente a nuestro origen de datos.
Por un lado, haríamos la ingesta de datos desde SSIS o Data Factory si tenemos la ventaja de contar con una suscripción en Azure. La transformación se podría realizar bien en SSIS mediante la creación de paquetes, o mediante vistas en SQL Server, ya que es donde almacenamos la información una vez realizados los pasos de Extracción y Transformación.
El siguiente paso en esta arquitectura sería importar estas tablas/vistas que ya cuentan con la lógica de negocio que hemos incorporado mediante SSIS o SQL, para posteriormente modelar en Power BI y finalmente visualizar la información.
En este tipo de arquitectura, ya se añaden más herramientas del stack de Microsoft, como es SQL Server, SSIS (SQL Server Integration Services) y/o Azure Data Factory.
3. Power BI Híbrido
Otra opción, semejante a la vista anteriormente, sería la que nos facilita Power BI a la hora de importar datos, hablamos del modo Import. Con este modo, cargamos la información en memoria tras haber tratado el dato previamente con SSIS/ADF tal como comentábamos en el caso anterior.
Como consideramos que es importante elegir el modo de lectura a la hora de desarrollar nuestro proyecto, a continuación, se detallan las características de cada funcionalidad, para saber cuál se ajustará a nuestro escenario de la forma más correcta:
4. Power BI - SSAS
Por último, la arquitectura más común, ya que es la opción que permite mayor flexibilidad, funcionalidad y menos limitaciones.
Esta arquitectura se basa en utilizar únicamente Power BI para representar la información, por lo que la parte de modelado pasaría a desarrollarse en SSAS (Microsoft SQL Server Analysis Services).
Es decir, haríamos la parte de extracción de datos a través de SSIS/ADF, en nuestra base de datos de Staging realizaríamos la correspondiente parte de transformación de datos, modificaciones y adiciones que sean necesarias para la parte de modelado, así como las reglas de negocio materializadas en nuestros procesos.
Esquema típico de esta arquitectura:
Resumen
Así pues, para poder tomar nuestra decisión y decantarnos por uno u otro escenario resultará imprescindible conocer los pros y contras de cada uno de ellos. El siguiente gráfico recopila lo tratado en el post, de una forma más visual y esquemática.
Tras haber analizado las posibilidades de arquitectura que se nos presentan ante un proyecto en el que entra en juego Power BI, como hemos visto, tenemos diferentes opciones para elegir, pero como siempre elegiremos el camino que más se ajuste a nuestras necesidades de volumen de datos, usuarios que van a consumir la aplicación, presupuesto disponible, arquitectura existente, entre otros.
