Mirroring con Microsoft Fabric: La solución integrada para sincronizar datos hacia Onelake?

Visitas: 65

Mirroring dentro de MS Fabric, pretende ser una solución integrada de replicación de datos que nos permite llevar los datos de varios sistemas fuente hacia el repositorio de Fabric (OneLake).

Es una solución de bajo coste y baja latencia, y al momento de este blog nos permite trabajar con origines de datos como Azure Database, Azure Cosmos DB y Snowflake. Aunque Microsoft seguramente incorporará otros cuantos más en un futuro cercano.

Una vez replicados los datos, éstos se almacenarán en un formato consultable dentro del OneLake y luego podrán ser utilizados por los distintos servicios de Fabric, como por ejemplo en un Notebook de Spark, dentro de Ingeniería de datos mediante T-SQL, o a través de reportes de Power BI con modelos semánticos.

La idea detrás de este feature, es la de simplificar el proceso de extraer los datos de los sistemas fuentes con una solución “SaaS” como todo lo que existe dentro del ecosistema de Fabric. Es decir, que mediante pocos Clicks y configuraciones podemos tener los datos de nuestras fuentes replicados y listos como tablas Delta Parquet.

Fig. 1. Diagrama de Fabric Database Mirroring para Azure SQL Database.

La replicación de Mirroring crea tres elementos de un Workspace de Fabric:

  • La base de datos replicada. Mirroring gestiona la replicación de datos en OneLake y la conversión a Parquet.
  • Un SQL Endpoint para trabajar lenguaje y herramientas SQL.
  • Un Modelo semántico default.

Cada base de datos replicada posee un Endpoint de SQL autogenerado que proporciona una experiencia analítica sobre las Tablas Delta creadas por el proceso de Mirroring.

Los usuarios podrán utilizar comandos T-SQL únicamente para consultar datos, ya que éstos son una copia de sólo lectura.

Aunque, si se podrán crear vistas SQL, TVFs (Table-valued Functions) en línea y procedimientos almacenados para encapsular su semántica y lógica de negocio en T-SQL.

Y tal vez lo más rico que se podrán consultar estos datos en otros Warehouses y Lakehouses en el mismo espacio de trabajo.

Todo esto puede ser realizado mediante el editor de consultas SQL de Microsoft Fabric, y tambien con otras herramientas que puedan consultar el Endpoint de SQL, incluido por supuesto SQL Server Management Studio, Azure Data Studio e incluso GitHub Copilot.

Habilitando Microsoft Fabric Mirroring Paso a Paso

Como primer paso para utilizar este feature, se debe primero habilitar la opción en el portal de Administración a nivel de Tenant. Esta opción puede estar limitada a Grupos de Seguridad específicos o bien para toda la organización.

Ref. Enable Mirroring – Microsoft Fabric | Microsoft Learn

Como punto importante, la disponibilidad del feature puede demorar algunos minutos hasta que quede activado.

Adicionalmente si no queremos dejar habilitado este feature a nivel deTenant, dado que aún se encuentra en Preview, podemos  habilitarlo únicamente a nivel de capacidad.

De esta manera podríamos limitar esta experiencia para un pequeño grupo de usuarios que quisieran probar esta capacidad. Esto lo podemos configurar a nivel de Capacidad, habilitando la opción de hacer “override” de la configuración a nivel de Tenant.

Replicar datos Microsoft Fabric Mirroring

Una vez habilitada esta característica, ya sea tanto a nivel de Tenant o bien a nivel de Capacidad, tenemos que configurar la réplica de datos desde alguna de las fuentes soportadas.

Estas fuentes por el momento pueden ser las siguientes:

  • Azure SQL Database
  • Azure Cosmos DB
  • Snowflake

Importante: Al momento de este Preview, Mirroring  no puede trabajar con conexiones de Red privadas de Azure SQL Database o Endpoints privados de CosmosDB.

Ref. Microsoft Fabric Enable Mirroring | Microsoft Learn

Ref. Microsoft Fabric mirrored databases from Azure Cosmos DB (Preview) | Microsoft Learn

Para comenzar la configuración, desde la experiencia de DataWarehouse, deberíamos poder hacer click en alguna de las opciones de Mirroring:

En la siguiente pantalla, dependiendo de la fuente seleccionada, se deberá configurar la conexión y que tablas vamos a replicar.

Una vez generada la conexión con las credenciales, tenemos que configurar que Tablas vamos a replicar. Por defecto, nos aparece la opción de replicar toda la base de datos pero podemos cambiar y seleccionar tablas y/o vistas en forma individual.

En este punto se pueden ver que algunas tablas o columnas no permiten ser replicadas. Esto se produce porque éstas contienen poseen de tipo de datos o features no soportados.

Para ver una lista completa de Limitaciones de Tipos de Datos no soportados se pueden ver los siguiente enlaces:

Y finalmente luego de conectar nuestra fuente, podremos ver que la replicación comienza en forma automática, para lo que debemos esperar algunos minutos para ver la primera sincronzación.

Una vez que el proceso haya comenzado, se habilitará la opción de Monitoreo en donde podremos ver el estado de la replicación para cada uno de los objetos como así tambien la cantidad de Registros copiados o bien si hay algún error.

Como vemos a simple vista, es un proceso simple y que requiere pocas configuraciones y que nos permite rápidamente replicar fuentes de datos hacia nuestro entorno de Fabric.

En nuestro workspace podemos ver que se ha creado un nuevo Endpoint de SQL y un modelo semántico default de nuestra base de datos en Mirroring:

En próximos posts, vamos a ver el detalle paso a paso para replicar las distintas fuentes de datos soportadas, como monitorear éstas y algunas conclusiones.

Microsoft Fabric – La nueva Solución de Analytics

Visitas: 185

Microsoft Fabric finalmente ha sido anunciado como Public Preview durante Microsoft Build 2023.

Y esencialmente, es una nueva herramienta, o bien una especie de nueva herramienta dentro todo el ecosistema de la plataforma de Datos de Microsoft.

Debido a que el anuncio fue de una magnitud importante, es conveniente separar un poco la visión general de Microsoft sobre el mundo de datos y bajar a tierra cada concepto de esta nueva herramienta.

Lo que nos lleva a tratar de responder algunas preguntas iniciales:

  • ¿Qué es Microsoft Fabric?
  • ¿Cómo funciona?
  • ¿Por qué nos debería importar?
  • ¿Realmente todos lo vamos a usar?
  • ¿Lo vamos a usar de repente sin darnos cuenta de que realmente lo hemos activado?
  • ¿Cómo encaja en el mundo existente?
  • ¿Dónde encaja Synapse Analytics?
  • ¿Dónde encaja Power BI?

¿Qué es Microsoft Fabric?

Bien, para comenzar tomando la definición oficial de Microsoft, Fabric se define como como “la plataforma de datos en la era de la IA”.

Es una nueva plataforma de tipo SaaS (Software as a Service) que encapsula todos los diferentes tipos de cargas de trabajo y cómputo que había Synapse analytics en una versión “SaaSificada”, sumado a la agradable facilidad de uso que tenemos en Power BI.

Agrega toda la capacidad de un Lake-House más todas las piezas de Synapse Analytics, traídos a la misma plataforma SaaS que Power BI. Eso es lo que proclama ser Microsoft Fabric.

Si ya somos usuarios de la versión premium de Power BI, algunas de estas características se encontrarán habilitadas a partir de este lanzamiento.

En resumen, Fabric es una plataforma SASS que encapsula Power BI más muchos de los componentes de Synapse Analytics y otras nuevas capacidades.

Haciendo un paralelo, la forma en que se definió a Fabric sería como hablar de Microsoft Office, pero para el mundo de datos.

Por lo que asumiendo los costos (y claramente habrá algunos), sería como usar Office 365. Entonces, si tengo que hacer una presentación podemos utilizar PowerPoint, o Word para componer un documento o si tenemos que hacer cálculos utilizaríamos Excel.

Tomando esta idea como concepto, deberíamos pensar en agrupar bajo un mismo portal todas las actividades de datos. Por ejemplo, un Pipeline de Copy en Data Factory o quizás empezar a trabajar directamente desde un Reporte de Power BI con un conjunto de datos, que a su vez otro usuario puede haber trabajado con un Notebook de Python o mediante un Dataflow.

Un único almacenamiento para gobernarlos a todos

Todas estas cargas de trabajo que mencionamos, si bien pertenecen a productos que ya existían y claramente estaban orientadas a diferentes roles de usuario, ahora se encuentran bajo una misma Suite y cuyo soporte de almacenamiento es común a todas a ellas.

Este es un pilar de Fabric, todo el almacenamiento es un único tipo de storage de tipo Lake.

Microsoft ha presentado este concepto de almacenamiento tipo Lake unificado como si fuese el concepto de OneDrive, pero orientado a cargas de datos.

Hoy todos conocemos el servicio de OneDrive, donde hay Teams y también carpetas de Sharepoint. Y siempre tenemos una copia en sincronía local en nuestros equipos, por lo que toda la organización puede trabajar y compartir los archivos que necesitan.

Y esencialmente, Microsoft está tratando de imitar esta funcionalidad con este almacenamiento Lake, basado en Cloud Storage.

Hasta ahora si teníamos que trabajar con diferentes tipos de archivos o fuentes de datos, incluso en diferentes ubicaciones o nubes, la integración de estos silos de datos requería mucha complejidad para poder conectarnos, copiar o masajear la información.

Esta situación terminaba inevitablemente requiriendo tareas de Data Engineering, pipelines de ETL/ELT o simplemente una de-duplicación de estos datos múltiples veces para poder trabajar con ellos.

Pues bien, ahora Fabric con el almacenamiento unificado de tipo Lake, quiere poner fin a estas tareas complejas presentando una “única” copia de los datos con los que todos los usuarios vamos a poder trabajar.

Y este es un gran concepto, ya que teniendo un único punto de donde parten los datos, se simplifica en una gran medida el trabajo con la seguridad, para decidir quién puede acceder a qué datos, y toda la integración con el resto de las herramientas.

Por otro lado también, se ofrecerá una interfaz similar a OneDrive, llamada OneLake donde podremos interactuar con este almacenamiento para subir, modificar u obtener archivos tan fácilmente como conectarnos con nuestras credenciales incluso desde un desktop.

Un motor para cada tarea

La evolución de las diferentes cargas de trabajo, hacen que un único motor de procesamiento no sea suficiente.

Y es por esto que MS Fabric, nos permite utilizar el poder de los diferentes tipos de motores bajo una misma interfaz y sin tener que preocuparnos de aprovisionar o configurar previamente una capacidad de cómputo específica.

Data Factory

En Fabric nos encontramos con una “evolución” de los pipelines y Mapping Dataflows de Synapse Analytics, que ahora utiliza Power Query para copia y transformación de flujos de datos.

Data Engineering

En cuanto a ingeniería de datos, esencialmente nos encontramos con el motor de Spark que teníamos en Synapse, donde vemos la versión 1.1 que incluye Spark 3.3 y Delta 2.2 y se espera que el ritmo de actualización sea más constante y con una experiencia más continua y que sea completamente transparente con el resto de las piezas de Fabric.

Data Science

Por el lado de Ciencia de Datos, tenemos la capacidad de crear Modelos y Experimientos y luego incluir éstos dentro de un Pipeline con Spark Jobs.

Data Warehousing

Luego llegamos al componente de Data Warehousing, el mundo un poco más conocido para los que trabajamos con T-SQL.

En este motor, tenemos la capacidad de escribir SQL y ejecutar Stored Procedures con cargas de trabajo transaccionales.

Lo que realmente estamos viendo con Fabric es que no vamos a tener que elegir si trabajar con un SQL Pool dedicado y un SQL Pool Serverless. Ahora vamos a tener un único motor SQL que operará con un único almacenamiento de datos que ya se encuentra previamente configurado.

Es quiere decir que todo el almacenamiento de nuestras tablas y registros se encontrará dentro del OneLake y nuevamente con formato Delta.

Real Time Analytics

Este motor de análisis en tiempo real, toma la forma de lo que teníamos en Azure Data Explorer con lenguaje Kusto, para realizar ingesta y consulta de eventos en tiempo real. Este motor permite trabajar y analizar grandes volúmenes de registros en formato de series temporales, que pueden desde luego ser conectados a Power BI.

Data Activator

Este motor quizás sea la pieza de Fabric mas novedosa y permite tomar acciones automáticamente basadas en los datos.

Normalmente para automatizar acciones sobre los datos, se require el desarrollo de código y esto suele ser costoso en tiempo y recursos. Es por esto Fabric ofrece dentro de sus motores a Data Activator con una experiencia “No-Code” para poder tomar acciones directamente desde los datos y sus cambios.

Basado en modelos de datos, reglas de negocio y Triggers que se pueden configurar en forma visual, se crean acciones que pueden desencadenar procesos, alertas y llamadas a otras aplicaciones. Desde un simple email hasta interactuar con Power Automate para crear flujos mas complejos.

Conclusión

Microsoft ha fijado con Fabric una dirección unificada de dónde visualiza sus servicios en términos de datos y análisis en la nube.

Y esto parece ser algo serio, ya que de alguna manera Fabric parece ser el punto de convergencia de las múltiples iniciativas y servicios que existían en el ecosistema de Azure y On Premises de los productos de Microsoft hasta hoy.

Es verdad que aún falta mucho camino y en toda unificación habrá cosas que se perderán y otras se ganarán. Cada pieza de Fabric aún está en desarrollo y otras que aún no han sido anunciadas pero lo importante es que finalmente tenemos una dirección que permite tener una historia consistente de punta a punta con los datos.

[Lanzamiento] Cumulative Update 1 | SQL Server 2022 en Disponiblilidad General

Visitas: 146

Esperando para realizar instalación de SQL Server 2022? Ahora si llegó el momento!

Microsoft ha lanzado el Cumulative Update 1 (CU1) para SQL Server 2022, que incluye todas las actualizaciones y correcciones desde la versión RTM.

El CU1 ofrece varias mejoras y novedades para SQL Server 2022, como:

  • Soporte para Azure Arc Data Services en Linux
  • Nuevas funciones de inteligencia artificial y aprendizaje automático
  • Mejoras en la replicación y la disponibilidad
  • Optimización del rendimiento de las consultas
  • Corrección de errores y vulnerabilidades


Para instalar el CU1 en tu servidor SQL, se debe tener configurado el repositorio de Cumulative Update. Luego, se deben actualizar los paquetes de SQL Server usando el comando apropiado para cada plataforma Linux.

Para obtener más instrucciones e información sobre el CU1, puedes consultar las notas de la versión o descargar el paquete desde el sitio web de Microsoft.

El CU1 es una actualización recomendada para SQL Server 2022 y tener la versión mas estable y con mas features disponibles.

Siempre antes de aplicar cualquier CU, es recomendable hacer una copia de seguridad de todas las bases de datos y seguir las mejores prácticas para evitar problemas.

 [Presentación] Introducción a Microsoft Azure 2023

Visitas: 121

El miércoles 22 de Enero de 2023, fui invitado a brindar una sesión de Introducción a Microsoft Azure en el  CES Juan Pablo II.

Adjunto el material presentado.

[Lanzamiento] SQL Server 2022 en Disponiblilidad General

Visitas: 155

SQL Server 2022 finalmente ya está aquí, y está repleto de innovaciones en materia de bases de datos e integración con Microsoft Azure.

Esta nueva versión, promete que el Query Engine sea más eficiente y consistente, y que pueda ejecutar se tanto On-Premises como en la nube o incluso en el Edge con su versión para IoT Devices.

En esta nueva versión, Microsoft se centró en facilitar el traslado de las cargas de trabajo de SQL Server hacia Azure con la integración de SQL Managed Instance, así como en simplificar la recuperación en caso de desastre.

SQL Server 2022 y Azure SQL Managed Instance

Configurar la recuperación de desastres siempre requiere de un gran esfuerzo y complejidad para cualquier infraestructura, especialmente cuando se requiere utilizar una máquina virtual de Azure u otro servidor fuera del datacenter principal.

Ahora con Azure SQL Managed Instance, esta tarea se encuentra simplificada. A partir de SQL Server 2022, una instancia SQLMI se puede convertir en pocos clicks en un sitio de recuperación de desastres.

Las instancias SQLMI de Azure ofrece muchos beneficios sobre las implementaciones tradicionales de SQLServer. No solo es más fácil de configurar, sino que, al ser un servicio gestionado, no hay necesidad de mantenimiento sobre la infraestructura de DR.

Una vez configurado el DR sobre Azure SQL MI, se puede ver directamente desde el SSMS un grupo de disponibilidad y un grupo de disponibilidad distribuido desplegado automáticamente. Y como se encuentra vinculado a la instancia de Azure SQLMI, también podremos verlo desde el portal de Azure.

Copias de seguridad y restauraciones de SQL MI

SQL Server 2022 introduce una nueva función que permite restaurar una versión de una base de datos de instancia gestionada de Azure SQL a SQL Server. Esto le permite migrar fácilmente sus datos de Azure a su instancia local de SQL Server. Para utilizar esta función, haga una copia de seguridad de su base de datos Azure SQL en una cuenta de almacenamiento Azure Blob utilizando la función de copia de seguridad en URL. A continuación, cambie a su instancia local de SQL Server y utilice T-SQL para restaurar el archivo de copia de seguridad.

Synapse Link

A partir de esta versión, Microsoft nos ofrece la posibilidad de eliminar los silos entre sus cargas de trabajo operativas y analíticas. SQL Server 2022 nos permite dar por finalizados los días en los que había que desarrollar ETLs para extraer los datos operativos para luego llevarlos a una plataforma analítica y ejecutar análisis e informes. Con la integración de Azure Synapse Link, ahora se pueden realizar análisis e informes casi en tiempo real, eliminando la necesidad de construir ETLs.

Además, todos los datos de SQL Server pueden ser catalogados y gobernados mediante la integración con Azure Purview.

Intelligent Query Processing

El motor de Inteligencia de Querys incorporado SQL Server 2022 realmente agiliza el rendimiento y elimina la necesidad de realizar cambios en el código. Por ejemplo, cuando se ejecuta un procedimiento almacenado, pueden existir dos tipos de planes dependiendo de la cantidad de datos que SQL necesite procesar. Un Index Seek es ideal para las consultas que devuelven sólo unas pocas filas. Pero un Index Scan es más adecuado para consultas que devuelven muchos más datos.

Dicho esto, sólo el primer plan ejecutado puede ser almacenado en caché y este permanecerá en la caché a menos que algo sea desalojado de la memoria.

De esta forma, las sucesivas ejecuciones del mismo procedimiento almacenado utilizarían el mismo plan, tomando más tiempo ejecutar la consulta.

Así que ahora, en lugar de realizar un tunning constante de las consultas y procedimientos, el motor de IQP realizará esto por nosotros.

En lugar de tener un solo plan caché por cada procedimiento almacenado, activando la optimización de Parameter Sensitive Plan Optimization, SQL Server puede ahora almacenar en caché múltiples planes contra el mismo procedimiento almacenado a medida que se ejecutan numerosas consultas contra él.

Así que no nos queda más remedio que actualizar y probar todas estas nuevas ventajas: