BI

SSRS dice adiós: PBIRS toma el relevo en SQL Server 2025

SSRS dice adiós: PBIRS toma el relevo en SQL Server 2025

La semana pasada, en el SQL Bits, Bob Ward nos daba la noticia con la sonrisa de quien cree que ha tenido una gran idea y espera que todos aplaudamos: a partir de SQL Server 2025, SSRS se queda sin futuro. No habrá nuevas versiones, ni promesas de mejoras, ni siquiera ese Service Pack que llegaba tarde y mal. En su lugar, Microsoft ha decidido que todo lo relacionado con reporting on-premises se haga con Power BI Report Server. PBIRS entra en todas las ediciones de pago de SQL Server y SSRS, después de dos décadas de leales servicios, se queda en mantenimiento hasta 2033. Merece la pena parar un momento, repasar esta historia y ver por qué este cambio tiene sentido, aunque duela.

El ascenso y estancamiento de SSRS

SSRS lleva en nuestras vidas desde antes que alguno de vosotros. Concretamente desde 2004, cuando se presentó como una extensión gratuita para SQL Server 2000. Su propuesta era clara: permitir la creación de informes paginados usando RDL (Report Definition Language), con control pixel-perfect y exportaciones a Excel que acababan en los escritorios de medio planeta. Fue una revolución en su momento, sustituyendo soluciones propietarias más caras y difíciles de mantener (Crystal Reports, te estamos mirando a ti). A partir de SQL Server 2005, SSRS ya venía integrado, y poco a poco se convirtió en la herramienta por defecto para reporting operativo en entornos on-prem. Muchos aún lo siguen usando a diario: por robusto, por fiable y porque funciona.

Pero también es cierto que lleva años estancado. Las mejoras en las últimas versiones han sido mínimas, casi anecdóticas. La interfaz de desarrollo, ya sea en Visual Studio o en Report Builder, parece sacada de una cápsula del tiempo. Y mientras tanto, Power BI ha crecido, se ha convertido en la niña mimada del equipo de producto y ha absorbido toda la inversión. No había que ser visionario para intuir que a SSRS le quedaban pocos cartuchos.

PBIRS entra en escena con todo el respaldo

PBIRS, por su parte, se presentó como una solución híbrida. Construido sobre la base de SSRS permite ejecutar tanto informes paginados como informes interactivos en formato PBIX, lo cual lo convierte en un candidato ideal para ser ese puente entre lo tradicional y lo moderno. Además, añade características importantes como el soporte de seguridad a nivel de fila, visuales personalizados y actualizaciones con una frecuencia más propia de los productos cloud que del viejo stack on-prem. 

Hasta ahora, PBIRS era un extra al que solo podían acceder los clientes de SQL con licencia Enterprise y Software Assurance o clientes de Fabric con licencias F64 o superior, lo que limitaba mucho su adopción. Por suerte, esos tiempos oscuros se van a acabar: a partir de SQL Server 2025, cualquier edición de pago de SQL incluye derecho a instalar PBIRS, usando la misma clave del servidor. Más fácil, más directo, más lógico, como era con SSRS.

La lógica detrás del cambio de SSRS a PBIRS

La justificación oficial es que SSRS no es más que un subconjunto de lo que ofrece PBIRS. Y es cierto: todo lo que hacía SSRS, lo hace PBIRS. Pero también hace más cosas. Si estás en un entorno donde ya conviven informes RDL con Power BI, la unificación es natural. Si vienes solo de SSRS, puede que el salto te parezca innecesario, pero la dirección está clara. Microsoft quiere que el reporting on-prem hable el lenguaje de Power BI, aunque aún no estemos listos para irnos a la nube.

Lo que ganamos con PBIRS (y lo que perdemos)

Ahora bien, no todo es ganancia. En la transición se pierden cosas. Algunas funcionalidades específicas, como los informes vinculados, no tienen una traducción directa en PBIRS. Las integraciones con sistemas antiguos o personalizados, especialmente aquellas que dependían de extensiones específicas o APIs internas de SSRS, pueden requerir adaptación. Y aunque la migración de RDLs está soportada y bien documentada, eso no significa que sea trivial. Hay que revisar fuentes de datos, suscripciones, permisos, configuraciones de caché y otras complicaciones que todos sabemos que pueden existir en informes que tienen más de 20 años y duermen tranquilas hasta que una migración las despierta.

Migrar a PBIRS: lo bueno, lo malo y lo inevitable

El proceso de migración, en sí mismo, está bastante claro. Microsoft ha publicado guías detalladas y herramientas para mover informes y catálogos desde SSRS a PBIRS. Incluso puedes probar PBIRS en modo Developer o Evaluation antes de tomar decisiones definitivas. Pero, como siempre, todo depende del grado de personalización de tu entorno y de cuánto te hayas alejado del camino en los últimos diez años. Porque sí, todos decimos que usamos SSRS “como viene”, pero luego llegan los informes con código embebido, las fuentes de datos compartidas con autenticación personalizada y ese servidor que nadie quiere tocar porque “funciona y no se ha caído en años”.

Soporte hasta 2033: más calma que consuelo

Lo curioso es que la noticia, pese a ser una especie de epitafio para SSRS, viene acompañada de la típica promesa tranquilizadora: SSRS 2022 seguirá recibiendo actualizaciones de seguridad (en soporte extendido) hasta enero de 2033. Eso quiere decir que puedes seguir usándolo si no quieres o no puedes migrar todavía. Puedes incluso seguir instalando SSRS 2022 con versiones más nuevas del motor de SQL Server, aunque no recibirás nuevas funcionalidades. Básicamente, queda en modo mantenimiento. Como cuando apagas el monitor pero dejas el servidor encendido: sigue ahí, pero ya no espera nada de la vida.

SSRS y PBIRS: Una consolidación inevitable

Hay que reconocer que este cambio tiene sentido. No es una jugada improvisada. Es parte del movimiento más amplio hacia Fabric, hacia unificar las herramientas de BI bajo el paraguas de Power BI, y hacia simplificar el stack on-prem. En lugar de mantener dos productos con solapamientos, Microsoft apuesta por uno solo, más potente, más alineado con su estrategia cloud y más fácil de justificar a nivel de roadmap. Tiembla SSIS.

Aun así, para quienes hemos vivido el mundo SSRS puro y duro, este cambio tiene algo de nostalgia. Nos ha acompañado en muchas guerras, nos ha dado informes que imprimen correctamente en la primera pasada, nos ha dejado programar suscripciones y controlar exportaciones como si estuviésemos montando una fábrica de PDFs. Pero el futuro no es eso. El futuro tiene interactividad, exploración de datos, visuales dinámicos y conectividad con servicios cloud. Y todo eso, por mucho que nos pese, no lo va a ofrecer nunca SSRS.

Conclusión

Así que, no lo veamos como una pérdida. Veámoslo como lo que es: una consolidación que estaba cantada. PBIRS hereda todo lo bueno de SSRS y añade lo que le faltaba. Que el proceso de migración tenga sus complejidades no debería sorprendernos. Es parte del juego (y a los consultores y técnicos nos dará dinerito). Lo importante es que ahora tenemos un camino claro, una herramienta mejor y tiempo suficiente para adaptarnos. Porque sí, SSRS fue grande. Pero PBIRS es el que se queda. Y conviene conocerlo bien, porque es lo que nos espera en los próximos años.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Power BI, SQL Server, 0 comentarios
Funciones de Ventana

Funciones de Ventana

Cuando analizamos datos con SQL Server, a menudo nos encontramos con la necesidad de realizar cálculos complejos que involucren conjuntos de filas relacionados entre sí. Tradicionalmente, recurríamos a subconsultas o a la ya conocida cláusula «GROUP BY». Sin embargo, existe un conjunto de herramientas mucho más potente y elegante para abordar estas situaciones: las funciones de ventana. A lo largo de este artículo, exploraremos en profundidad qué son, cómo funcionan y cómo podemos sacarles el máximo partido en nuestras consultas en SQL Server.

¿Qué son realmente las Funciones de Ventana en SQL Server? 

Las funciones de ventana son un tipo especial de funciones que nos permiten realizar cálculos sobre un conjunto de filas que están relacionadas con la fila actual que estamos procesando. No es nada nuevo, las vimos por primera vez en 1998 en Oracle8i y fueron introducidas como parte del estándar SQL en su versión 3 en el año 2003. En SQL Server las tenemos desde la versión 2005 y posteriormente llegaron a otros sistemas de bases de datos como PostgreSQL (2009), MariaDB (2016) y MySQL (2018).

La clave de su potencia reside en que, a diferencia de las funciones agregadas tradicionales que colapsan múltiples filas en una única fila de salida (como sucede con «GROUP BY»), las funciones de ventana operan dentro de una «ventana» o «marco de ventana» definido por nosotros, devolviendo un valor para cada fila individual.

Imaginemos una tabla de ventas donde queremos calcular el total de ventas acumulado por vendedor a lo largo del tiempo. Sin una función de ventana, tendríamos que recurrir a subconsultas complejas o a cursores, lo que puede resultar ineficiente y difícil de mantener. Con una función de ventana, podemos definir una ventana que incluya todas las ventas del vendedor hasta la fecha actual, calculando el acumulado para cada venta sin perder la información de cada transacción individual.

La sintaxis fundamental para utilizar una función de ventana involucra la cláusula «OVER()». Esta cláusula es la que define la «ventana» sobre la cual la función operará. Dentro de «OVER()», podemos especificar cómo se particionarán los datos y cómo se ordenarán dentro de cada partición.

Sintaxis de las Funciones de Ventana en SQL Server

La estructura básica para emplear una función de ventana es la siguiente:

Analicemos cada uno de los componentes esenciales:

  • funcion_ventana: Aquí especificamos la función de ventana que queremos aplicar. Puede ser una función de agregación (como «SUM()», «AVG()», «MIN()», «MAX()», «COUNT()»), una función de ranking («ROW_NUMBER()», «RANK()», «DENSE_RANK()», «NTILE()»), o una función de valor («LAG()», «LEAD()», «FIRST_VALUE()», «LAST_VALUE()»). El argumento dependerá de la función específica.
  • OVER(): Esta cláusula es obligatoria para indicar que estamos utilizando una función de ventana. Es dentro de sus paréntesis donde definimos el contexto de la ventana.
  • PARTITION BY lista_de_columnas (Opcional): La cláusula «PARTITION BY» divide el conjunto de resultados en particiones basadas en los valores de las columnas especificadas. La función de ventana se aplicará de forma independiente a cada una de estas particiones. Si omitimos «PARTITION BY», la función se aplicará a toda la tabla como una única partición.
  • ORDER BY lista_de_columnas [ASC | DESC] (Opcional): Dentro de cada partición (o en toda la tabla si no hay «PARTITION BY»), la cláusula «ORDER BY» define el orden lógico de las filas. Este orden es crucial para muchas funciones de ventana, especialmente las de ranking y las que trabajan con valores de filas precedentes o siguientes. Si se omite, el orden de las filas dentro de la partición será arbitrario.
  • ROWS o RANGE especificación_de_marco (Opcional): Esta cláusula nos permite definir aún más el marco de la ventana dentro de cada partición. Podemos especificar un conjunto de filas contiguas que se incluirán en el cálculo de la función para la fila actual. Las opciones más comunes incluyen:
    •  «ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW»: Incluye todas las filas desde el inicio de la partición hasta la fila actual.
    • «ROWS BETWEEN n PRECEDING AND CURRENT ROW»: Incluye las «n» filas anteriores a la fila actual y la fila actual.
    • “ROWS BETWEEN CURRENT ROW AND n FOLLOWING»: Incluye la fila actual y las «n» filas siguientes.
    • “ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING»: Incluye todas las filas de la partición.
    • «RANGE» funciona de manera similar a «ROWS», pero en lugar de un número fijo de filas, define el marco basándose en los valores de las columnas especificadas en «ORDER BY».

Tipos de Funciones de Ventana en SQL Server

Las funciones de ventana se pueden clasificar en varios tipos, cada uno diseñado para abordar necesidades específicas de análisis:

Funciones de Agregación

Podemos utilizar las funciones de agregación que ya conocemos (SUM(),AVG(), MIN(), MAX() o COUNT()) como funciones de ventana al incluirlas con la cláusula «OVER()». La diferencia fundamental con su uso tradicional con «GROUP BY» es que, al emplearlas como funciones de ventana, no perdemos la granularidad de las filas individuales.

Por ejemplo, para obtener el total de ventas por ciudad y a la vez visualizar el importe de cada pedido individual junto con el total de su ciudad, podríamos escribir algo como:

Aquí, «SUM(order_amount) OVER (PARTITION BY city)» calcula la suma de «order_amount» para todas las filas que comparten el mismo valor en la columna «city», y este total se muestra en cada fila correspondiente a esa ciudad.

Funciones de Ranking 

Las funciones de ranking nos permiten asignar una posición o rango a cada fila dentro de una partición según un criterio de ordenación específico. SQL Server nos ofrece las siguientes funciones de ranking:

  • ROW_NUMBER(): Asigna un número secuencial único a cada fila dentro de una partición, comenzando en 1. Si hay filas con los mismos valores en la columna de ordenación, se les asignarán números diferentes según el orden en que se procesen.
  • RANK(): Asigna un rango a cada fila dentro de una partición basado en el orden de las columnas especificadas en «ORDER BY». Si dos o más filas tienen el mismo valor, recibirán el mismo rango, y el siguiente rango se saltará. Por ejemplo: 1, 2, 2, 4…
  • DENSE_RANK(): Similar a «RANK()», asigna rangos basados en el orden, pero no se salta ningún rango en caso de empate. Por ejemplo: 1, 2, 2, 3, 4…
  • NTILE(n): Divide las filas dentro de una partición en «n» grupos (aproximadamente) iguales y asigna un número de grupo (desde 1 hasta «n») a cada fila. Es útil para identificar percentiles, cuartiles, etc..

Funciones de Valor 

Las funciones de valor nos permiten acceder a valores de otras filas dentro de la misma partición (o en toda la tabla) sin necesidad de realizar joins o subconsultas. Las más utilizadas son:

  • LAG(columna, n, valor_predeterminado): Accede al valor de la «columna» en la fila que está «n» filas antes de la fila actual dentro de la partición (ordenada por «ORDER BY»). Si no existe una fila anterior en la distancia especificada, devuelve el «valor_predeterminado» (si se proporciona, sino devuelve «NULL»).
  • LEAD(columna, n, valor_predeterminado): Accede al valor de la «columna» en la fila que está «n» filas después de la fila actual dentro de la partición (ordenada por «ORDER BY»). Similar a «LAG()», permite especificar un «valor_predeterminado» si no existe una fila posterior.
  • FIRST_VALUE(columna): Devuelve el valor de la «columna» de la primera fila dentro de la partición (ordenada por «ORDER BY»).
  • LAST_VALUE(columna): Devuelve el valor de la «columna» de la última fila dentro de la partición (ordenada por «ORDER BY»). Es importante tener en cuenta que, por defecto, el marco de la ventana para «LAST_VALUE()» va desde el inicio de la partición hasta la fila actual, por lo que a menudo se utiliza con una especificación de marco como «ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING» para obtener el verdadero último valor de la partición.

Cláusulas avanzadas en Funciones de Ventana

Como mencionaba anteriormente, las cláusulas «ROWS» y «RANGE» nos permiten refinar la definición del marco de la ventana. «ROWS» define el marco en términos de un número fijo de filas precedentes o siguientes a la fila actual. «RANGE», por otro lado, define el marco basado en los valores de la columna de ordenación.

Por ejemplo, para calcular una media móvil de ventas de los últimos tres meses (incluyendo el mes actual), podríamos utilizar:

Aquí, «ROWS BETWEEN 2 PRECEDING AND CURRENT ROW» define una ventana que incluye la fila actual y las dos filas anteriores según el orden de la columna «mes».

El poder de «PARTITION BY» y «ORDER BY» juntos en Funciones de Ventana 

La combinación de «PARTITION BY» y «ORDER BY» dentro de la cláusula «OVER()» es donde realmente brilla el potencial de las funciones de ventana. «PARTITION BY» nos permite dividir los datos en grupos lógicos, mientras que «ORDER BY» establece un orden significativo dentro de cada uno de estos grupos.

Consideremos el ejemplo de calcular el ranking de productos más vendidos dentro de cada categoría:

En este caso, los productos se particionan por «categoria», y dentro de cada categoría, se ordenan por «ventas» de forma descendente. La función «RANK()» asignará un ranking a cada producto dentro de su respectiva categoría.

Usando la Cláusula «WINDOW» para simplificar consultas complejas en SQL Server

A partir de SQL Server 2022 (con un nivel de compatibilidad de base de datos 160 o superior), se introduce la cláusula «WINDOW». Esta cláusula nos permite definir especificaciones de ventana con nombre que pueden ser referenciadas por múltiples funciones de ventana dentro de una misma consulta. Esto mejora significativamente la legibilidad y el mantenimiento de consultas complejas que utilizan las mismas definiciones de ventana varias veces. La sintaxis básica de la cláusula «WINDOW» es:

Una vez definida la ventana con nombre, podemos referenciarla en la cláusula «OVER()» de nuestras funciones de ventana:

Esto resulta especialmente útil cuando tenemos varias funciones de ventana que comparten la misma lógica de partición y ordenación.

Conclusión

Las funciones de ventana representan una herramienta fundamental en el arsenal de cualquier experto en SQL Server. Nos brindan la capacidad de realizar análisis sofisticados sobre conjuntos de datos relacionados sin sacrificar la información a nivel de fila, abriendo un abanico de posibilidades para calcular totales acumulados, medias móviles, rankings dinámicos, y comparar valores entre filas.

Dominar la sintaxis de la cláusula «OVER()», comprender los diferentes tipos de funciones de ventana (agregación, ranking, valor), y saber cómo utilizar las cláusulas «PARTITION BY», «ORDER BY», «ROWS», y «RANGE» nos permitirá escribir consultas más eficientes, legibles y potentes. La introducción de la cláusula «WINDOW» en versiones recientes de SQL Server simplifica aún más la gestión de consultas complejas con múltiples definiciones de ventana.

Os animamos a explorar y practicar con estas funciones en vuestros proyectos. El potencial analítico que desbloquean las funciones de ventana en SQL Server es enorme y, sin duda, os permitirá llevar vuestras habilidades de análisis de datos al siguiente nivel.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Cloud, SQL Server, 0 comentarios

¿Por qué usar SSAS o Azure Analysis Services (AAS) en 2025?

Estamos viviendo la época dorada de los datos, la toma de decisiones basada en datos se ha convertido en un pilar fundamental para las organizaciones que buscan competitividad y eficiencia, por no hablar de la inteligencia artificial y el machine learning no serían nada sin datos. Esto ha llevado a una necesidad cada vez más creciente de datos, pero no datos de cualquier manera, la necesidad de herramientas que permitan el modelado y análisis avanzados es más crítica que nunca. En este sentido, SQL Server Analysis Services (SSAS) y Azure Analysis Services (AAS) continúan siendo soluciones clave para transformar datos en información estratégica.

En este artículo, quiero intentar responder a la pregunta ¿por qué SSAS y AAS siguen siendo relevantes en 2025? Para ello vamos a hablar de sus beneficios, y cuándo optar por una solución on-premises o en la nube.

La evolución del análisis de datos y la relevancia de SSAS/AAS

Con el crecimiento de plataformas de datos como Microsoft Fabric, Power BI y Synapse Analytics, es normal preguntarse si SSAS o AAS siguen siendo relevantes. La respuesta corta es sí, y la larga es que su uso ha evolucionado para adaptarse a nuevos escenarios.

SSAS y AAS siguen siendo las mejores soluciones para modelos de datos semánticos con alta reutilización y complejidad. Los modelos analíticos requieren rendimiento, escalabilidad, seguridad y gobernanza de primer nivel, y estas tecnologías lo ofrecen mejor que muchas alternativas.

Tendencias que refuerzan la importancia de SSAS y AAS:

La demanda de análisis de datos en tiempo real ha crecido significativamente, impulsando el uso de modelos híbridos que combinan almacenamiento en memoria con consultas en vivo a bases de datos. Al mismo tiempo, la necesidad de modelos escalables que puedan soportar miles de usuarios simultáneamente hace que soluciones como SSAS y AAS sean fundamentales para empresas de gran tamaño. Además, estas herramientas siguen desempeñando un papel clave en la integración con otras plataformas de Microsoft como Power BI, SQL Server, Synapse Analytics y Azure Data Lake, lo que refuerza su importancia en arquitecturas modernas de inteligencia empresarial.

Beneficios de SSAS y AAS

Uno de los principales motivos por los que SSAS y AAS siguen siendo relevantes es su capacidad para ofrecer un rendimiento excepcional en el análisis de datos. Gracias a la tecnología VertiPaq, los modelos tabulares permiten consultas rápidas mediante compresión y almacenamiento en memoria. Esto es crucial en un contexto donde los usuarios esperan tiempos de respuesta inmediatos en sus informes y dashboards.

Otro aspecto fundamental es la capacidad de manejar grandes volúmenes de información de manera eficiente. Los modelos en SSAS y AAS pueden procesar billones de filas sin comprometer el rendimiento, algo que sigue siendo una ventaja en comparación con otras soluciones. Aunque Power BI Premium y Fabric han mejorado en este aspecto, SSAS y AAS continúan siendo superiores para centralizar y administrar modelos de datos complejos que requieren alto rendimiento y reutilización en múltiples reportes.

La seguridad es otro factor determinante. Este 2025, la protección de datos debería ser una prioridad para todas las organizaciones. Tanto SSAS como AAS permiten la implementación de mecanismos avanzados de seguridad, como Row-Level Security (RLS) y Object-Level Security (OLS), lo que garantiza que cada usuario acceda únicamente a la información que le corresponde. Esta capacidad es especialmente valiosa en entornos empresariales donde la confidencialidad de los datos es crítica.

Por último, la integración con otras herramientas sigue siendo una de sus grandes ventajas. SSAS y AAS se conectan de manera nativa con Power BI, SQL Server, Azure Synapse Analytics y Data Factory, facilitando la creación de soluciones analíticas robustas y escalables. La posibilidad de definir modelos semánticos reutilizables permite a las empresas garantizar la consistencia de los datos en toda la organización, evitando la duplicación de esfuerzos y asegurando que todos los usuarios trabajen con la misma información consolidada.

¿SSAS o AAS? ¿On-premises o en la nube?

La elección entre SSAS (on-premises) y AAS (Azure) depende del contexto de cada empresa. Los factores clave siguen siendo coste, escalabilidad, mantenimiento y requisitos de seguridad.

¿Cuándo elegir SSAS?

Es cierto que la nube se está imponiendo como solución pero aún quedan casos donde puede ser recomendable una solución local como SSAS. Si la empresa sigue operando mayormente on-premises y no ha migrado a la nube o si tenemos licenciamiento de SQL Server con SSAS ya incluido SSAS puede ser mejor solución que AAS. Además, con esta solución tendremos el máximo control sobre la infraestructura y cumpliremos con los requisitos de esos escenarios con estrictos requisitos de seguridad que impiden almacenar datos en la nube ya sea por legislación o políticas de empresa. En este último caso podremos combinar SSAS con PBIRS todo el local.

¿Cuándo elegir AAS?

Por el contrario, si la empresa ya usa Azure y otros servicios en la nube o si necesitamos escalabilidad dinámica sin administrar servidores AAS es una solución que puede reducir costes en mantenimiento y licencias on-premises. Si usamos Power BI o Fabric en la nube también podremos aprovechar la integración nativa con AAS.

¿Y Microsoft Fabric? ¿Sustituye a AAS?

Microsoft Fabric ha introducido un nuevo paradigma con Power BI Semantic Models, que combina capacidades de SSAS/AAS con Power BI Premium. Sin embargo, AAS sigue siendo la mejor opción en entornos donde se requiere máxima flexibilidad y control sobre modelos semánticos.

Conclusión

A pesar de la evolución de las plataformas de datos en la nube, SSAS y AAS siguen siendo fundamentales en arquitecturas de BI modernas. Su capacidad para ofrecer modelos de datos centralizados, rendimiento óptimo y seguridad avanzada los mantiene como una opción relevante para empresas que buscan eficiencia en el análisis de datos.

Si la empresa opera on-premises, SSAS sigue siendo una opción válida. Por el contrario, si la estrategia es cloud-first, AAS ofrece flexibilidad y escalabilidad sin preocuparse por infraestructura. Si se usa Power BI, Microsoft Fabric puede ser una alternativa para simplificar la arquitectura, aunque AAS sigue siendo preferible en entornos empresariales grandes.

En resumen, SSAS y AAS continúan siendo pilares del análisis de datos en 2025, y su relevancia dependerá del contexto y la estrategia de cada organización. La clave está en aprovechar su potencia para construir soluciones analíticas de alto rendimiento, integradas con las últimas tecnologías de Microsoft.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Cloud, Power BI, 0 comentarios

SQL Server Analysis Services (SSAS)

SQL Server Analysis Services (SSAS) es una de las tecnologías más robustas y flexibles para el análisis de datos en el ecosistema Microsoft. Desde su introducción en 1998 como OLAP Services (parte de SQL Server 7), ha evolucionado hasta convertirse en un pilar fundamental para la inteligencia empresarial (BI), proporcionando capacidades avanzadas para el modelado y la explotación de datos. En este artículo, os quiero introducir SSAS como herramienta, sus modelos, arquitectura y buenas prácticas para su implementación.

Introducción a SSAS

SSAS es una solución de Microsoft para la creación de modelos analíticos que permiten consultas optimizadas sobre grandes volúmenes de datos. Se integra con el ecosistema de SQL Server y herramientas como Power BI, Excel y otros clientes de BI. Su propósito es ofrecer un rendimiento excepcional en la consulta de datos y permitir cálculos complejos con una estructura optimizada.

Existen dos modos principales en los que SSAS puede operar el multidimensional y el tabular.

Modelos de SSAS: Multidimensional vs. Tabular

La elección entre los modelos multidimensional y tabular depende de diversos factores como el volumen de datos, la complejidad del análisis y la facilidad de uso.

Modelo Multidimensional (OLAP)

El clásico modelo analítico utiliza cubos y dimensiones para organizar la información de manera jerárquica. Se basa en la idea de organizar los datos en cubos OLAP (Online Analytical Processing), donde cada cubo representa un conjunto de datos preprocesados y optimizados para consultas analíticas rápidas. Estos cubos contienen medidas numéricas (como ventas o ingresos) y dimensiones (como tiempo, ubicación o producto), que permiten a los usuarios explorar la información desde múltiples perspectivas. Estos cubos pueden almacenarse como MOLAP (Multidimensional OLAP), ROLAP (Relational OLAP) o HOLAP (Hybrid OLAP). Gracias a esta arquitectura, las consultas se ejecutan con una latencia mínima, permitiendo análisis complejos como agregaciones, drill-downs y cálculos avanzados sin afectar el rendimiento de la base de datos transaccional. Por cierto, estas consultas son expresiones MDX (Multidimensional Expressions), que es el lenguaje de consulta optimizado para OLAP. 

Como ventajas del Modelo Multidimensional podemos destacar su alto rendimiento en consultas agregadas preprocesadas y el soporte avanzado para modelado complejo de datos lo que lo hacen ideal para escenarios con jerarquías bien definidas.

Como desventajas del Modelo Multidimensional tenemos una curva de aprendizaje elevada debido a la necesidad de conocer MDX y una mayor complejidad en la administración y diseño de modelos que con otras alternativas.

Modelo Tabular (In-Memory)

Un modelo tabular en SQL Server Analysis Services (SSAS) es un enfoque más moderno para el análisis de datos que utiliza una arquitectura en memoria basada en el motor VertiPaq (si, igual que Power BI), optimizado para consultas de alto rendimiento. A diferencia del modelo multidimensional, el modelo tabular almacena los datos en formato columnar en lugar de estructuras de cubo preprocesadas, lo que permite una mayor comprensión y rapidez en las consultas. Se basa en tablas y relaciones, similar a un modelo relacional, y emplea el lenguaje DAX (Data Analysis Expressions) para la creación de cálculos y medidas. Su flexibilidad y facilidad de desarrollo lo han convertido en una alternativa popular al modelo multidimensional, ya que permite una integración más sencilla con herramientas de BI como Power BI y Excel, facilitando el análisis de datos sin la complejidad de los cubos OLAP tradicionales.

Como ventajas del Modelo Tabular destacaría su mayor facilidad de desarrollo en comparación con el modelo multidimensional (DAX es más sencillo que MDX), sus excelentes tiempos de respuesta debido a su estructura en memoria y su mejor integración con herramientas modernas como Power BI.

Por el contrario, las desventajas principales del Modelo Tabular son el consumo de memoria más elevado en modelos de gran tamaño y las limitaciones en la gestión de relaciones complejas en comparación con OLAP.

Arquitectura de SSAS

SSAS opera bajo una arquitectura de servidor que permite múltiples conexiones concurrentes de usuarios y herramientas de BI. La arquitectura básica que tenemos que tener clara antes de empezar incluye la o las fuentes de datos, es decir el origen de los datos (que puede ser de SQL Server, Azure SQL Database, Oracle, Teradata, entre otros) y el modelo de datos. Obviamente estos datos se van a introducir en un modelo de datos de SSAS mediante un cubo OLAP o un modelo tabular (en estrella a poder ser 🙂).

Una vez con esto definido llega la parte del modelado. En SSAS la información se procesa y se almacena en SSAS en formatos optimizados. En este punto igual hay que hacer algunas consultas a través de MDX (para OLAP) o DAX (para modelos tabulares) para terminar de pulir detalles antes de conectar nuestros clientes BI que serán herramientas como Power BI, Excel, Reporting Services y aplicaciones personalizadas consumen los modelos de SSAS.

Prácticas recomendadas en la implementación de SSAS

Al diseñar una solución con SSAS, es importante seguir ciertas recomendaciones para garantizar rendimiento y escalabilidad. Tenemos que tener en cuenta que estas aplicaciones analíticas van a almacenar y operar con gran cantidad de datos y por tanto definir un buen modelo de datos es fundamental. Tendremos que prestar especial atención para evitar redundancias y asegurar integridad referencial. En modelos tabulares, minimizar el uso de columnas de texto para optimizar la compresión.

A la hora de optimizar el rendimiento en OLAP utilizaremos agregaciones para reducir el tiempo de consulta mientras que en modelos tabulares, buscaremos reducir la cardinalidad de las columnas para mejorar la compresión. También podemos implementar particionamiento en modelos grandes para mejorar el procesamiento.

En cuanto a seguridad, podremos configurar roles y permisos en SSAS para restringir el acceso a datos sensibles. Si queremos ir más allá tenemos también Row-Level Security en modelos tabulares para aplicar filtros por usuario.

Y para cerrar este apartado, como no podía ser de otra manera, tenemos que hablar de la monitorización del uso de memoria y CPU sobre todo en entornos productivos.

SSAS en la Nube: Azure Analysis Services

Como ha pasado con otros servicios, Microsoft también ha llevado SSAS a la nube de Azure con Azure Analysis Services (AAS), ofreciendo las mismas capacidades de modelado de datos pero con las ventajas adicionales propias de Azure. Estas son la escalabilidad dinámica según la demanda de consultas, la integración con servicios de Azure como Azure SQL Database y Azure Synapse Analytics y el modelo de pago por uso sin necesidad de administrar infraestructura.

Para organizaciones que buscan reducir costes de mantenimiento y beneficiarse de la flexibilidad de la nube, Azure Analysis Services es una excelente opción.

Conclusión

SSAS sigue siendo una herramienta clave para arquitecturas de BI en empresas de todos los tamaños. Su capacidad para manejar grandes volúmenes de datos y realizar análisis avanzados lo convierte en una opción robusta tanto en entornos on-premises como en la nube. La elección entre modelo tabular o multidimensional dependerá de los requisitos del negocio y la facilidad de integración con otras herramientas.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en Power BI, 1 comentario

¿Cuándo y por qué usar un servidor SSAS intermedio entre SQL Server y Power BI?

Una de las decisiones clave a la hora de diseñar arquitecturas BI robustas es determinar cómo gestionar y procesar de manera eficiente la ingente cantidad datos que vamos a manejar. Aquí es donde la pregunta de si incluir un servidor SQL Server Analysis Services (SSAS) como capa intermedia entre SQL Server y Power BI cobra especial relevancia, sobre todo cuando buscamos soluciones escalables, de alto rendimiento y con un control centralizado. Aunque Power BI, al igual que SSAS, utiliza el motor VertiPaq, los objetivos y capacidades de cada herramienta pueden llegar a justificar el coste extra (recursos y tiempo) de la integración de SSAS en no pocas situaciones.

A lo largo de este artículo trataré de explicar los casos en los que SSAS aporta valor añadido a las arquitecturas BI y analizaremos su utilidad tanto en combinación con Power BI como, en escenarios mucho más específicos como Power BI Report Server (PBIRS). Además, abordaremos cómo estas soluciones contribuyen a la consistencia de los datos, el rendimiento de las consultas y la gobernanza empresarial.

¿Qué es SQL Server Analysis Services (SSAS)?

Empecemos por el principio, ¿qué es SSAS? SQL Server Analysis Services (SSAS) es un componente de Microsoft SQL Server diseñado para proporcionar capacidades analíticas avanzadas mediante la creación de modelos de datos optimizados. SSAS es esencialmente un motor analítico que permite construir modelos tabulares o multidimensionales que los usuarios pueden consultar para obtener insights clave de negocio.

Existen dos variantes principales de SSAS: modelos tabulares y modelos multidimensionales. Aunque ambos ofrecen capacidades de análisis, aunque, los modelos tabulares, introducidos en 2012, se han impuesto como la opción preferida por la mayoría de las organizaciones debido a su simplicidad y rendimiento. Los modelos tabulares utilizan el motor VertiPaq, que permite almacenar datos en memoria de forma comprimida y procesarlos rápidamente. Esto lo hace ideal para escenarios que requieren análisis en tiempo real o procesamiento rápido de grandes volúmenes de datos.

Además de ser un motor analítico, SSAS actúa como un servidor centralizado donde los modelos de datos pueden ser compartidos y consumidos por múltiples herramientas, como Power BI, Excel o cualquier cliente que soporte DAX o MDX. Esta capacidad de centralizar la lógica analítica y permitir el acceso desde diferentes aplicaciones lo convierte en una pieza clave en la gobernanza de datos empresariales.

En términos de seguridad, SSAS permite implementar configuraciones avanzadas como Row-Level Security (RLS), que garantiza que los usuarios solo accedan a la información que les corresponde según sus roles. Esto, junto con su capacidad para manejar grandes volúmenes de datos y consultas complejas, posiciona a SSAS como una solución ideal para arquitecturas de BI empresariales.

SSAS y Power BI: una combinación estratégica para el análisis de datos

Ya hemos visto que el motor VertiPaq es núcleo de las capacidades de análisis en memoria tanto de Power BI como de SSAS Tabular. Este motor está diseñado para gestionar grandes volúmenes de datos y optimizar consultas analíticas complejas. Aunque tanto SSAS como PowerBI comparten esta tecnología, las diferencias entre Power BI y SSAS Tabular son notables. Mientras que Power BI está orientado a usuarios finales que necesitan autonomía en la creación de modelos y reportes, SSAS está diseñado para ser un motor analítico centralizado, ideal para entornos empresariales con necesidades avanzadas de escalabilidad, rendimiento y control.

Esta diferencia de enfoques posiciona a SSAS como un intermediario estratégico en arquitecturas BI. Al encargarse del procesamiento analítico, SSAS permite que Power BI se concentre en la visualización e interacción con los datos, podríamos decir que lo libera de la carga computacional asociada a cálculos pesados y transformaciones complejas.

Beneficios de incluir SSAS en la arquitectura BI

Lo sé, aún no te he dicho que ventajas tiene montar SSAS. Pues bien, cuando integras SSAS, el impacto en términos de rendimiento, centralización y escalabilidad es significativo. Su capacidad para manejar grandes volúmenes de datos, centralizar la lógica analítica y gestionar la seguridad de forma avanzada lo convierte en una solución potente para escenarios empresariales complejos.

Uno de los principales beneficios de SSAS es su capacidad para optimizar consultas analíticas a través del motor VertiPaq, que procesa los datos en memoria de manera comprimida. Esto se traduce en tiempos de respuesta significativamente más rápidos en consultas que involucran relaciones complejas, medidas calculadas o grandes cantidades de datos. Este enfoque mejora la experiencia del usuario final y alivia la carga sobre el servidor SQL subyacente frente a por ejemplo unas consultas direct query pero tampoco es ninguna ventaja frente a un Power BI en modo import, en el fondo es lo mismo.

Entonces, lo que sí es una ventaja de SSAS es que permite centralizar los modelos analíticos, asegurando que todas las herramientas y usuarios consuman el mismo conjunto de datos y cálculos. Esta centralización elimina inconsistencias entre departamentos y garantiza que los análisis se basen en las mismas definiciones métricas, lo que es esencial en entornos empresariales con múltiples equipos trabajando en paralelo. Con esta configuración, Power BI actúa como un consumidor de estos modelos, lo que simplifica la gobernanza de los datos y la gestión de los cambios.

Otro aspecto clave es la seguridad. SSAS ofrece un control robusto a través de la seguridad a nivel de fila (Row-Level Security, RLS), que permite definir permisos detallados para los datos. Esto asegura que cada usuario solo tenga acceso a los datos relevantes para su función, garantizando el cumplimiento de las políticas de privacidad y seguridad de la organización.

Casos prácticos de uso de SSAS con Power BI

La integración de SSAS con Power BI se justifica especialmente en entornos donde se manejan grandes volúmenes de datos, múltiples usuarios concurrentes o modelos analíticos complejos. En estos escenarios, SSAS actúa como un motor analítico dedicado que libera a Power BI de la carga computacional, permitiendo que esta última herramienta se concentre en la presentación de los datos.

Por ejemplo, en organizaciones donde los reportes son consultados por decenas o cientos de usuarios simultáneamente, SSAS distribuye eficientemente el procesamiento de las consultas. Esto no solo mejora los tiempos de respuesta, sino que también evita la saturación del servidor SQL transaccional, que puede centrarse en otras tareas críticas del negocio.

Asimismo, en escenarios donde los modelos de datos contienen cálculos avanzados, relaciones de muchos a muchos (no hagáis eso) o jerarquías complejas, SSAS es la herramienta ideal. Su capacidad para procesar y almacenar en memoria estos modelos garantiza que las consultas sean rápidas y precisas, incluso cuando los volúmenes de datos son masivos.

La utilidad de SSAS con Power BI Report Server (PBIRS)

Hay otro caso especial donde SSAS cobra especial relevancia y es en esas organizaciones que necesitan soluciones on-premises. En estos escenarios, SSAS se convierte en un complemento esencial para Power BI Report Server (PBIRS). PBIRS está diseñado para gestionar y publicar reportes de forma local, pero no permite que varios informes accedan al mismo modelo por lo que un SSAS común como fuente de datos se hace imprescindible.

Además, cuando SSAS se combina con PBIRS, se crea una arquitectura en la que el procesamiento analítico es gestionado por SSAS, mientras que PBIRS se encarga de la presentación y administración de los reportes. Esto asegura tiempos de respuesta rápidos incluso en escenarios con alta concurrencia, ya que las consultas complejas se resuelven en el servidor SSAS antes de ser entregadas al usuario.

Por último, el uso de SSAS con PBIRS permite aprovechar sus capacidades de seguridad centralizada. Los permisos configurados en el modelo de SSAS se aplican automáticamente a los reportes alojados en PBIRS, simplificando la administración de la seguridad y asegurando que los datos sensibles estén protegidos.

Azure Analysis Services: la evolución hacia la nube

Y ahora que hemos hablado de entornos 100% on-premises no podemos no hablar de los 100% cloud. Esos entornos donde la escalabilidad y flexibilidad son prioritaria. Para estos casos Microsoft tiene una herramienta llamada Azure Analysis Services (AAS) y no es más que una evolución natural de SSAS a la nube de Azure. AAS ofrece las mismas capacidades avanzadas que SSAS Tabular, pero con las ventajas de estar alojado en la infraestructura de Azure. Esto permite a las organizaciones implementar modelos analíticos centralizados sin preocuparse por la gestión del hardware o el mantenimiento de los servidores.

Azure Analysis Services resulta especialmente útil en arquitecturas híbridas, donde los datos se encuentran tanto en la nube como on-premises. Su integración con servicios cloud como Azure Synapse Analytics además de con servicios locales como SQL Server, facilita la construcción de soluciones escalables que pueden crecer dinámicamente según las necesidades del negocio. Además, AAS hereda la seguridad y gobernanza avanzadas de SSAS, lo que garantiza que las organizaciones puedan mantener el control sobre sus datos mientras aprovechan la elasticidad de la nube.

La elección entre SSAS on-premises y AAS dependerá de los requisitos específicos de cada organización. Sin embargo, AAS ofrece una opción atractiva para aquellas que buscan combinar la potencia analítica de SSAS con la flexibilidad y capacidad de expansión de Azure.

Conclusión

El uso de un servidor SSAS como capa intermedia entre SQL Server y Power BI aporta múltiples beneficios en términos de rendimiento, escalabilidad y gobernanza. Su capacidad para procesar grandes volúmenes de datos, centralizar modelos analíticos y gestionar la seguridad lo convierte en una pieza clave en arquitecturas empresariales complejas. Aunque Power BI puede manejar muchos casos de forma autónoma, la inclusión de SSAS garantiza un nivel de eficiencia y control que es difícil de igualar.

Cuando se utiliza con Power BI Report Server (PBIRS), SSAS se convierte en un motor analítico esencial, capaz de manejar consultas complejas y soportar escenarios de alta concurrencia en entornos on-premises. Esto asegura una solución integral para organizaciones que buscan combinar el poder del análisis en memoria con la flexibilidad y seguridad de un entorno local.

En definitiva, la combinación de SSAS, Power BI y PBIRS representa una solución robusta para cualquier organización que busque maximizar el valor de sus datos. 

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Power BI, 0 comentarios

SQL Server Big Data Clusters

Hoy vamos a hablar de una funcionalidad no tan conocida de SQL Server. Esta funcionalidad se estrenó con SQL Server 2019 y realmente no ha tenido la adopción del mercado deseada. Quizá porque al poco tiempo le surgió un enemigo dentro de su propia casa, Microsoft Fabric. Pero bueno, no es mi objetivo hacer análisis de mercado, simplemente vamos a descubrir hoy SQL Server Big Data Clusters (BDC). 

SQL Server Big Data Clusters es una solución avanzada para gestionar, analizar y transformar grandes volúmenes de datos integrando el potencial de SQL Server con tecnologías de Big Data como Apache Spark y Hadoop Distributed File System (HDFS). Como os decía, en este artículo, profundizaremos en qué consiste esta tecnología, sus componentes clave y cómo se implementa en entornos empresariales modernos.

¿Qué es SQL Server Big Data Clusters?

Empecemos por el principio, SQL Server Big Data Clusters es una implementación de contenedores que permite desplegar un clúster escalable de SQL Server, Spark y HDFS utilizando Kubernetes como orquestador. La solución está diseñada para trabajar con datos estructurados, no estructurados y semiestructurados, facilitando tanto la consulta como el procesamiento distribuido.

Esta plataforma no solo facilita la consulta sobre grandes volúmenes de datos, sino que también permite integrar fuentes de datos externas y realizar análisis avanzados directamente desde SQL Server.

Componentes Clave de SQL Server Big Data Clusters

Ahora que ya sabemos lo que es, veamos de qué se compone y que debemos tener en cuenta. 

  • Control Plane: El componente principal que debemos conocer es el Control Plane. Es el núcleo del clúster que administra la infraestructura y orquesta las operaciones entre los diferentes servicios. Kubernetes actúa como el motor principal para gestionar el despliegue de los recursos.
  • SQL Server Master Instance: SQL Server Master Instance es la instancia principal de SQL Server en el clúster que actúa como punto de entrada para las consultas y la administración de datos. Desde aquí se pueden realizar operaciones T-SQL estándar, así como consultas externas.
  • Data Pool: El Data Pool es el componente que almacena y gestiona los datos estructurados que se cargan directamente en el clúster para procesamiento intensivo. Es ideal para cargas de trabajo analíticas donde los datos se distribuyen y procesan en paralelo.
  • Storage Pool: El Storage Pool es la integración de Hadoop Distributed File System (HDFS) y se usa para manejar datos no estructurados. Este almacenamiento es distribuido y permite el escalado horizontal para manejar grandes volúmenes de datos.
  • Compute Pool: El componente Compute Pool es el grupo diseñado para manejar consultas distribuídas sobre grandes datasets. A grandes rasgos, lo que hace es ejecutar SQL Server en contenedores con funcionalidades de consulta paralela.
  • Spark Pool: El Spark Pool, como su propio nombre indica es el componente de Apache Spark que proporciona capacidades de procesamiento de datos. Nos sirve para optimizar tareas de Machine Learning, ETL y análisis en tiempo real.Application Services: Por último, los Application Services nos facilitan el desarrollo y despliegue de aplicaciones personalizadas dentro del clúster, incluyendo APIs, paneles analíticos y aplicaciones de Machine Learning.

Beneficios Principales de SQL Server Big Data Clusters

Lo más destacable de esta solución es su escalabilidad y flexibilidad. Al estar basado en Kubernetes, se pueden escalar los recursos del clúster según las necesidades de la carga de trabajo, optimizando tanto el costo como el rendimiento.

Además, el procesamiento de datos distribuido es otra de sus grandes ventajas. Gracias a HDFS y Spark, los BDC permiten procesar grandes volúmenes de datos de manera distribuida, reduciendo significativamente los tiempos de procesamiento.

Por si esto fuese poco, tenemos también su gran capacidad de integración de fuentes de datos externas. SQL Server BDC soporta PolyBase, permitiendo la consulta y análisis de datos almacenados en plataformas como Azure Data Lake, Amazon S3, y otros sistemas externos, directamente desde SQL Server.

Como veis, tenemos a nuestro alcance todo un ecosistema analítico completo que incluye capacidades analíticas avanzadas, como análisis en tiempo real, integración con herramientas de Machine Learning y capacidades ETL robustas.

Casos de Uso

SQL Server Big Data Clusters, gracias a sus capacidades para el análisis de datos masivos, es ideal para organizaciones que manejan grandes cantidades de datos estructurados y no estructurados. Estas organizaciones pueden beneficiarse de la capacidad de consulta distribuida y almacenamiento escalable de los BDC.

Además su integración multifuente hace que empresas con datos distribuidos en múltiples plataformas pueden usar BDC para consolidar y analizar datos sin necesidad de migrarlos.

Otro de los casos de uso de rabiosa actualidad es para escenarios de Machine Learning e Inteligencia Artificial. Con Spark integrado, los BDC son ideales para implementar modelos de Machine Learning en entornos de Big Data. Pero no hace falta apuntar tan alto, la combinación de Spark y SQL Server facilita la transformación de datos y su preparación para análisis haciendo accesibles los procesos ETL más complejos.

Implementación de SQL Server Big Data Clusters

Como hemos visto, la instalación de SQL Server BDC requiere un entorno Kubernetes configurado. A continuación, os resumo los pasos básicos:

  1. Preparar el Entorno Kubernetes: Lo primero que deberemos hacer es configurar un clúster de Kubernetes compatible con SQL Server BDC, como AKS, OpenShift o cualquier distribución Kubernetes certificada.
  2. Configurar el Almacenamiento: Una vez el entorno de Kubernetes está configurado deberemos seleccionar el almacenamiento persistente para HDFS y otros componentes del clúster.
  3. Desplegar el Clúster: En este punto ya estamos en disposición de usar herramientas como Azure Data CLI (azdata) para desplegar los contenedores de SQL Server BDC en el clúster Kubernetes.
  4. Configurar el Acceso: Por último, no debemos olvidarnos de implementar reglas de acceso seguro y configurar el acceso a las fuentes de datos externas.

¿Qué pasa ahora que ha llegado Fabric?

SQL Server BDC fue concebido como una solución para gestionar datos estructurados y no estructurados en entornos híbridos y locales, utilizando Kubernetes como orquestador. Sin embargo, Fabric ha superado a BDC en varias áreas críticas.

Mientras que BDC ofrece escalabilidad mediante Kubernetes, Fabric utiliza una arquitectura nativa en la nube, permitiendo una expansión horizontal más ágil y transparente. Esto simplifica la gestión de recursos y permite un enfoque más integral hacia el análisis en tiempo real. Fabric también centraliza las herramientas de análisis, desde la ingestión de datos hasta su visualización, lo que elimina la necesidad de múltiples tecnologías y reduce la complejidad operativa. Por el contrario, BDC requiere una integración manual de componentes como PolyBase y HDFS, aumentando la carga administrativa. A todo esto hay que sumar que, en Fabric, al incorporar servicios completamente gestionados, se reduce drásticamente la necesidad de conocimientos especializados para administrar clústeres, facilitando la adopción incluso para equipos con menos experiencia en Kubernetes.

Mientras que Fabric brilla en escenarios modernos como análisis avanzado, gobernanza centralizada y machine learning, BDC sigue siendo relevante únicamente para organizaciones con fuertes inversiones en infraestructura híbrida local que requieren una compatibilidad estrecha con SQL Server. 

Debemos tener en cuenta que aunque Microsoft no ha declarado explícitamente el final del soporte para BDC, su desarrollo está estancado en favor de Fabric. Esto posiciona a BDC como una tecnología de nicho, útil en entornos muy específicos o en organizaciones que todavía no pueden migrar completamente a la nube.

Conclusión

SQL Server Big Data Clusters representó un avance significativo en su tiempo, combinando SQL Server con tecnologías de Big Data para abordar desafíos complejos de gestión de datos. Sin embargo, la llegada de Microsoft Fabric ha redefinido este espacio, ofreciendo una solución más moderna, integrada y eficiente para la mayoría de los casos de uso actuales.

Si bien BDC sigue siendo útil en ciertos contextos específicos, Microsoft Fabric es claramente el futuro de la analítica de datos en el ecosistema de Microsoft. Para maximizar el valor y mantenerse alineados con el roadmap tecnológico, las organizaciones deben considerar una transición estratégica hacia Fabric. Este cambio no solo optimiza la infraestructura, sino que también abre nuevas oportunidades para aprovechar al máximo los datos en un entorno dinámico y escalable. Fabric no es simplemente una evolución; es una revolución en la forma en que entendemos y utilizamos los datos.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima! 

Publicado por Roberto Carrancio en SQL Server, 1 comentario

Fabric Lakehouse vs Warehouse

Comparar Fabric Lakehouse y Fabric Warehouse dentro del ecosistema de Microsoft Fabric nos lleva a analizar dos enfoques arquitectónicos que, aunque comparten una base tecnológica común, se diseñan para resolver problemas muy diferentes. Ambas soluciones surgen como respuesta a la necesidad de gestionar datos en un panorama empresarial cada vez más complejo, pero destacan por sus diferencias en flexibilidad, rendimiento y casos de uso.

Para empezar, debemos saber que Microsoft Fabric utiliza Delta Lake como formato de tabla unificado tanto para los componentes de Lakehouse como para los Warehouses. Las tablas Delta son esencialmente archivos Delta Parquet, un formato de código abierto compatible con la mayoría de las soluciones de otras nubes. Esto permite un acceso sin problemas a los datos en todos los motores de proceso de Microsoft Fabric y también entre diferentes nubes como Google, AWS, IBM, etc.

Por lo tanto, aunque los Warehouses en Microsoft Fabric pueden tener algunas similitudes con las bases de datos SQL tradicionales que tan bien conocemos, también tienen muchas características en común con los Lakehouses, incluyendo el uso de tablas Delta Parquet. Pero, entremos un poco más en detalle.

¿Qué es Fabric Lakehouse?

Fabric Lakehouse es una solución híbrida que combina lo mejor de los data lakes y los data warehouses. Este modelo permite gestionar datos estructurados, semiestructurados y no estructurados en un entorno único y flexible. Su arquitectura está basada en tecnologías de almacenamiento de objetos, como Delta Lake, optimizadas para trabajar con grandes volúmenes de datos en formatos diversos como Parquet, CSV y JSON.

Su enfoque permite a las empresas procesar datos en bruto, realizar análisis exploratorios y aplicar modelos avanzados como machine learning, sin necesidad de transformaciones estrictas previas. Por esta razón, Fabric Lakehouse es ideal para casos en los que se manejan datos históricos, flujos de datos en tiempo real o múltiples fuentes heterogéneas.

Fabric Warehouse: Optimización para consultas estructuradas

Fabric Warehouse, por su parte, representa el enfoque más tradicional de los almacenes de datos. Diseñado para cargas de trabajo analíticas OLAP, este modelo almacena los datos en un formato tabular estructurado que facilita consultas rápidas y eficientes. Su base tecnológica incluye índices columnstore que aceleran significativamente el tiempo de respuesta en análisis complejos.

Fabric Warehouse se destaca en escenarios de reporting empresarial, donde la precisión y la rapidez son fundamentales. Además, su integración nativa con herramientas como Power BI y Excel lo convierte en una elección prioritaria para la generación de informes y dashboards operativos.

Diferencias entre Fabric Lakehouse y Warehouse

Aunque ambos modelos comparten objetivos relacionados con la gestión de datos, presentan diferencias importantes en cuanto a flexibilidad, rendimiento y casos de uso.

Flexibilidad en el manejo de datos

Fabric Lakehouse ofrece un enfoque más versátil, permitiendo trabajar con datos en su estado original sin transformaciones previas. Esto es crucial en proyectos donde los datos cambian constantemente o provienen de múltiples fuentes con formatos variados. Por otro lado, Fabric Warehouse requiere un modelo de datos predefinido y procesos ETL claros para garantizar la eficiencia en el análisis.

Rendimiento en consultas y análisis

En términos de rendimiento, Fabric Warehouse sobresale en escenarios donde se necesitan consultas estructuradas y rápidas sobre datos optimizados. En cambio, Fabric Lakehouse es más adecuado para procesar grandes volúmenes de información y ejecutar análisis avanzados, aunque puede ser menos eficiente para consultas pequeñas.

Integración con herramientas de análisis

Fabric Lakehouse se integra de manera natural con entornos de Big Data y plataformas como Apache Spark, lo que lo hace ideal para análisis exploratorio y aprendizaje automático. Fabric Warehouse, por su parte, está optimizado para herramientas de BI tradicionales, siendo la opción preferida para usuarios de Power BI y Excel.

Endpoints de Fabric. La principal diferencia

Hasta ahora hemos estado viendo las definiciones más comerciales y las diferencias teóricas entre ambos sistemas. Vamos ahora con algo que va a marcar la diferencia entre ambas soluciones, los endpoints o puntos de conexión (me niego a llamarlos puntos finales como me niego a llamar tejido a fabric). Estos endpoints son los extremos finales de nuestros lakehouse y warehouse a los que nos vamos a conectar y vamos a ver que hay 3 tipos principales.

Lakehouse Endpoint para Spark Runtimes/Libraries

Para trabajar con archivos y tablas de Lakehouse, ya sea para análisis, transformaciones o procesamiento usando Spark, nos conectaremos al endpoint del Lakehouse que está separado del endpoint de SQL Analytics. Igual que con los métodos estándar fuera de Fabric para trabajar con archivos y tablas delta, para conectarnos, usaremos la URL, la ruta ABFS o montaremos el Lakehouse directamente en nuestro explorador. El uso de Spark nos permite realizar operaciones de escritura con Scala, PySpark, Spark SQL o R. Sin embargo, si deseamos utilizar T-SQL, deberemos utilizar SQL Analytics Endpoint, donde vamos a ver que solo podemos realizar operaciones de “solo lectura”.

SQL Analytics Endpoint (Lakehouse)

El endpoint SQL Analytics se crea automáticamente cuando creamos un Lakehouse. Cada Lakehouse tiene solo un endpoint SQL y, como cada Workspace o Área de Trabajo de Fabric puede tener más de un Lakehouse, la cantidad de endpoints SQL en un espacio de trabajo coincide con la cantidad de Lakehouses que tengamos.

Estos endpoint nos ofrecen una experiencia SQL para leer tablas Delta. Es importante destacar que este Endpoint es solo lectura y únicamente sirve para las tablas, como es lógico no podremos usar SQL para consultar archivos e información no estructurada. Por algo la S de SQL significa Structured, ¿no? 

Esto no es todo, SQL Analytics Endpoint no solo nos permite analizar las tablas Delta utilizando T-SQL, también vamos a poder guardar funciones, generar vistas y aplicar seguridad a nivel de objetos SQL. Gracias a estas funcionalidades los ingenieros de datos podrán crear una capa relacional sobre los datos físicos en Lakehouse, y exponerlos para que los analistas usen sus a herramientas de informes utilizando una cadena de conexión SQL.

Ya que estos endpoint son solo lectura, la creación/modificación de tablas Delta (y los datos dentro de las tablas Delta) se debe hacer usando Apache Spark. Una vez creadas las tablas Delta con Spark dentro de Lakehouse se podrán ver y leer automáticamente a través del endpoint SQL. ¿Y qué pasa si hay tablas Delta externas creadas con código Spark? Estas tablas no serán visibles desde el endpoint SQL hasta que cree un acceso directo o Shortcut a la tabla Delta externa.

Seguridad en el SQL Endpoint de Fabric Lakehouse

Como hemos visto, podemos configurar la seguridad a nivel de objeto (OLS) para acceder a los datos mediante el punto final de análisis SQL. Sin embargo, es importante destacar que estos permisos solo se aplicarán cuando accedamos a los datos a través endpoint de análisis SQL. Si deseamos asegurar que no se pueda acceder a nuestros datos de otras maneras (a través de diferentes endpoints o directamente), debemos establecer roles y permisos en el Área de Trabajo.

Conexión al SQL Analytics Endpoint

Para esta parte del artículo me voy a basar en este del blog de Microsoft publicado por Marc Bushong y voy a tomar prestadas sus fotos.

Dejadme que antes de nada os enseñe su Área de Trabajo de Fabric. Como veis tiene un Lakehouse llamado “BronzeLakehouse” y, en la imagen, podemos ver el endpoint de SQL Analytics (rojo) y el endpoint de Lakehouse (verde)

Accediendo al endpoint de Lakehouse vemos Files (rojo) y Tables Delta (verde). Si queremos asegurarnos, en la esquina superior derecha veremos un menú desplegable con el endpoint estamos viendo seleccionado.

Si cambiamos la vista al Endpoint de SQL Analytics vais a ver que ya solo podemos ver las tablas:

Antes de pasar al siguiente endpoint tenemos que saber que también podemos conectar al endpoint SQL desde fuera de Fabric con las herramientas que conocemos como SSMS o Azure Data Studio. Simplemente tendremos que poner la autenticación y cadena de conexión del endpoint como si de cualquier otra conexión de servidor SQL se tratara.

Data Warehouse Endpoint

El Data Warehouse Endpoint opera como un DWH SQL en un entorno tradicional. Esto significa que proporciona compatibilidad casi total con T-SQL, de manera similar a una base de datos SQL Server implementada en nuestros servidores. Este endpoint ofrece múltiples ventajas funcionales.

T-SQL de lectura y escritura

Entre estas ventajas funcionales podemos destacar que cuenta con soporte para lectura y escritura en tablas Delta, lo que permite consultar los datos tanto con Spark como con T-SQL. Sin embargo, mientras que en el Lakehouse las operaciones de escritura solo se podían realizar con Spark, en el Warehouse es al revés y únicamente pueden realizarse mediante T-SQL. Además, incluye soporte casi completo para operaciones DML y DDL, lo que abarca la ingesta, el modelado y el desarrollo de datos a través de T-SQL o mediante interfaces gráficas. Esto nos permite un control absoluto sobre la creación de tablas, la carga de datos y las transformaciones, utilizando herramientas como COPY INTO, pipelines, dataflows o métodos de ingesta cruzada entre bases de datos como CREATE TABLE AS SELECT (CTAS), INSERT..SELECT o SELECT..INTO. Solo hay una pega, a día de hoy todavía no es compatible con la sintaxis MERGE.

Soporte ACID

Este endpoint también garantiza el cumplimiento de las propiedades ACID para transacciones aunque trabaje con tablas Delta. Cabe destacar que, aunque Lakehouse ofrece compatibilidad ACID, se limita a las tablas Delta, por lo que los ficheros de un Lakehouse podrían no cumplir con estas propiedades.

Transacciones Multitabla

Otra característica es el soporte para transacciones que abarcan múltiples tablas, lo que facilita flujos de trabajo complejos. Al combinar estas capacidades de lectura/escritura con las herramientas de ingesta entre bases de datos, es posible integrar datos sin complicaciones desde varios Warehouses o Lakehouses. Cuando se ingieren datos en el Warehouse, estos se almacenan automáticamente en formato Delta dentro de OneLake, garantizando una estructura optimizada y unificada.

 

En la siguiente imagen podemos ver todo lo que hemos comentado hasta ahora en acción, una consulta entre bases de datos para cargar datos en el Warehouse desde el Lakehouse, donde se crea y se carga la tabla de Warehouse «holiday.Warehouse_Holiday_Clean» con los datos de la tabla «Silverlakehouse.dbo.Holiday_Clean» del Lakehouse como origen, y luego se muestran los registros.

Conclusión

Para cerrar esta comparativa, queda claro que tanto Fabric Lakehouse como Fabric Warehouse son piezas fundamentales en el ecosistema de Microsoft Fabric, cada uno respondiendo a diferentes necesidades en el manejo y análisis de datos. A través de su integración en OneLake, ambas soluciones permiten un acceso uniforme y una gestión eficiente de los datos, aprovechando las ventajas de las tablas Delta como formato unificado.

La verdadera innovación radica en cómo Microsoft Fabric ofrece puntos de conexión (endpoints) especializados para cada solución. Estos endpoints no sólo habilitan el acceso a los datos según las necesidades específicas de cada modelo, sino que también permiten combinar diferentes entornos de datos en operaciones cruzadas, como lo demuestra la imagen adjunta. Aquí vemos cómo los endpoints para Lakehouse y Warehouse trabajan en conjunto, integrando datos de manera fluida y demostrando el poder de esta arquitectura unificada.

Este enfoque, que facilita tanto la conexión como el intercambio de datos entre sistemas, posiciona a Microsoft Fabric como una solución robusta y flexible para las necesidades actuales de la analítica empresarial.

Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!

Publicado por Roberto Carrancio en Cloud, Power BI, 0 comentarios