Uso de la base de datos SQL en ETL inverso

Se aplica a :✅base de datos SQL en Microsoft Fabric

En este artículo se describe cómo usar SQL Database en Fabric como destino ETL inverso dentro de un patrimonio de datos basado en Fabric. Proporciona instrucciones de arquitectura, patrones operativos e consideraciones de implementación para mover datos mantenidos de orígenes analíticos (como Microsoft Fabric Data Warehouse o Fabric Lakehouse) a SQL Database in Fabric para el consumo operativo por parte de aplicaciones, API y experiencias en tiempo real.

¿Qué es ETL inverso en Fabric?

Muchos clientes han invertido mucho tiempo y esfuerzo en crear procesos de extracción, transformación, carga (ETL) para transformar los datos operativos sin procesar en datos analíticos más refinados que se pueden usar para los informes empresariales. El resultado final de un proceso de ETL suele ser un almacén analítico, como un almacén de datos o un lakehouse, al que accede una capa de generación de informes como Power BI. Esta arquitectura sirve bien a los usuarios empresariales, pero los informes son relativamente estáticos y la información solo puede derivarse de la intervención humana. Mediante el uso de ETL inverso, puede devolver los datos transformados a sistemas operativos para que las aplicaciones y los agentes puedan obtener información de estos datos analizados en tiempo real. ETL inverso transfiere datos de hechos y dimensiones desde almacenes analíticos a una capa de servicio donde se puede acceder a ellos a través de puntos de conexión como GraphQL o directamente mediante consultas TDS (flujo de datos tabulares).

Aunque puede conectar aplicaciones operativas directamente a un almacén o un almacén de lago, estos almacenes de datos están diseñados para cargas de trabajo analíticas. Los almacenes de datos operativos, como SQL Database en Fabric, están diseñados para admitir consultas transaccionales y proporcionan un mejor rendimiento y escalabilidad para cargas de trabajo operativas. Las bases de datos operativas también ofrecen la opción de enriquecer aún más los datos con incrustaciones de vectores y metadatos adicionales para facilitar la búsqueda híbrida y vectorial, así como la generación aumentada por recuperación (RAG).

En este patrón, el almacén o el lakehouse sigue siendo el sistema analítico de registro.
SQL Database en Fabric actúa como un almacén operativo que ofrece baja latencia, indexación refinada, restricciones estrictas de datos y relaciones, y los niveles de servicio esperados por los equipos de aplicaciones.

Destinos ETL inversos comunes

Los destinos ETL inversos comunes suelen representar segmentos de datos mantenidos y de alto valor que los sistemas operativos pueden consumir con una transformación mínima. Estos destinos están diseñados para ofrecer acceso de baja latencia a los datos de confianza, a la vez que se conserva la lógica de negocios aplicada en la capa analítica. Algunos ejemplos son:

Datos de cliente y usuario (por ejemplo, métricas de interacción como la actividad de sesión, el uso de características y las interacciones)
Datos de ventas y marketing (por ejemplo, métricas de puntuación como la propensión para comprar, puntuaciones de compromiso, probabilidad de convertir)
Datos operativos y transaccionales (por ejemplo, datos de pedido e inventario, como niveles de existencias, estado de pedido y intervalos de entrega)
Datos derivados de IA/ML (por ejemplo, recomendaciones de productos personalizados, puntuaciones predictivas como riesgo de renovación o ventajas de ventas o análisis de sentimiento)

Mecanismos de movimiento de datos

El proceso comienza definiendo los datos de origen, estableciendo el destino y seleccionando un mecanismo de movimiento de datos. Elija uno o varios de los siguientes mecanismos para mover datos del almacén analítico a SQL Database en Fabric.

Sugerencia

Como regla general, use:

Canalizaciones para copias simples y cargas programadas.
Flujos de datos Gen2 para transformaciones de poco código.
Spark para procesamiento complejo y a gran escala (incluido el aprendizaje automático).
T-SQL de elementos cruzados donde esté disponible para mantener las operaciones centradas en SQL, por ejemplo, uniendo una tabla en una base de datos SQL con una tabla en un almacén o un punto de conexión de análisis de SQL.

Mecanismo	Usar cuando	Fortalezas	Consideraciones
Pipelines de datos de Fabric	Necesita cargas administradas y repetibles (por lotes o microprocesos) de operaciones de copia de datos.	Integración de primera clase; admite marcas de agua y procedimientos almacenados	Simultaneidad; escalar la base de datos SQL durante las cargas
Flujo de datos Gen2	Necesita transformaciones de datos con poco código y lógica de proceso mejorada.	Adecuado para el entorno empresarial; admite la configuración y depuración de columnas.	Menor rendimiento para grandes volúmenes; planear la creación de particiones
Spark (cuadernos y trabajos)	Necesita realizar transformaciones complejas basadas en código y reestructuración a gran escala.	Control de código completo; lecturas delta eficientes; Compatibilidad con escritura de JDBC	Autenticación y procesamiento por lotes; evitar transacciones grandes
Consultas T-SQL entre elementos	Necesitas movimiento de SQL dentro de la base de datos entre elementos de Fabric	Fontanería mínima; SQL nativo; fácil de programar

Arquitectura de referencia: ETL inverso a base de datos SQL en Fabric

La arquitectura de referencia para reverse ETL en Fabric reúne los bloques de construcción esenciales necesarios para poner en funcionamiento los datos analíticos curados. Muestra cómo fluyen los datos de orígenes analíticos de confianza a través de capas de transformación en una base de datos SQL estructurada. La base de datos operativa actúa como interfaz para los sistemas de bajada. Este patrón garantiza que las aplicaciones, las API y las herramientas de informes puedan acceder a datos de baja latencia y de alta calidad sin poner en peligro la integridad del sistema analítico de registro.

Los componentes principales de este flujo incluyen:

Origen: conjuntos de datos curados de Fabric Data Warehouse o Lakehouse (Delta).
Transformaciones: transformaciones ETL inversas aplicadas mediante Pipelines, Dataflow Gen2, Spark o cross-item T-SQL.
Destino: base de datos SQL en Fabric con aterrizaje, historial (opcional), cuarentena y esquemas de servicio definidos.
Consumidores: aplicaciones a través de GraphQL o TDS, API y Power BI para informes y paneles en tiempo real.

Components

Los siguientes componentes están implicados en el flujo general para usar SQL Database en Fabric como destino ETL inverso.

Esquemas de servicio y aterrizaje

Asigne los datos de origen a los esquemas de aterrizaje adecuados en la base de datos SQL en Fabric.
Opcionalmente, mantenga un history esquema para la auditabilidad.
Use un quarantine esquema para rechazar (problemas de calidad de datos).
Defina un serving esquema para el consumo en etapas posteriores con las restricciones e indexación apropiadas.

Orquestación

Programe transferencias en Fabric mediante canalizaciones, flujos de datos o trabajos de Spark.
Use la programación integrada para configurar la cadencia, la hora de inicio y la zona horaria.
Programe cuadernos de Spark a través del portal o la API de Fabric.
Supervise las ejecuciones de extremo a extremo en el centro de supervisión de Fabric.

Consumption

Exponga datos a través de puntos de conexión de GraphQL o T-SQL a través de TDS mediante bibliotecas de cliente como ADO.NET (y otros).
Cree paneles y visualizaciones de Power BI directamente a través de SQL Database en Fabric.

Gobernanza y seguridad

Use Microsoft Entra ID para la autenticación y autorización.
Combine los permisos de roles del área de trabajo de Fabric y los permisos de SQL para un control granular.
Opcionalmente, configure claves administradas por el cliente para el cifrado de datos en reposo.
Audite el acceso y proteja los datos en tránsito mediante Private Link.

Servicio de aplicaciones

Una vez que se seleccionan y actualizan los datos en la base de datos SQL, cambie el foco a la habilitación del acceso rápido y confiable para los consumidores operativos. En este contexto, el servicio de aplicaciones significa exponer conjuntos de datos de confianza a través de interfaces de baja latencia que se alinean con los patrones modernos de aplicaciones.

Después de que los datos se coloquen y actualicen en SQL Database en Fabric:

Para atender cargas de trabajo operativas, exponga los datos a través de puntos de conexión de GraphQL o el protocolo TDS , que se consumirán a través de ADO.NET y otras bibliotecas cliente. Por ejemplo, proporcione información del producto, cadena de suministro o casos de uso de servicio al cliente.
Empareja el conjunto de datos con Power BI para ofrecer paneles en tiempo real y análisis de autoservicio.

Consideraciones específicas del tejido

SQL Database en Fabric usa el mismo motor de SQL Database que Azure SQL Database y está controlado, protegido, facturado y operado a través del Portal de Fabric. También ofrece creación de reflejo integrada en archivos Delta/Parquet almacenados en Microsoft OneLake, a los que se accede a través de un punto de conexión de SQL Analytics. Dado que se encuentra en el entorno de Microsoft Fabric, hay algunas consideraciones que se deben tener en cuenta al crear el diseño:

Paridad de características: SQL Database en Fabric está convergendo con Azure SQL Database. Valide las características específicas que necesita para asegurarse de que se ajusten a sus fines y supervisen las actualizaciones de la hoja de ruta.
Modelo de seguridad: la base de datos SQL de Fabric usa solo la autenticación de Microsoft Entra ID. Planee identidades para canalizaciones, flujos de datos y trabajos de Spark adecuadamente.
Replicación: LA base de datos SQL de Fabric replica automáticamente los datos de solo lectura en OneLake. Esta sincronización es útil para las necesidades de informes y análisis, mientras que la base de datos permanece disponible para cargas de trabajo operativas de lectura y escritura.

Comentarios

¿Le resultó útil esta página?

Last updated on 2026-01-10