Desarrollo e despliegue de dependencias inter-almacenes

En este artículo, aprenderá a modelar e implementar dependencias entre almacenes mediante proyectos de base de datos SQL en Visual Studio Code. Comience desde dos proyectos de almacenamiento existentes y configure dependencias unidireccionales entre ellos mediante referencias de base de datos y, cuando sea necesario, scripts previos a la implementación y posteriores a la implementación.

Este artículo se basa en los conceptos de Desarrollo de proyectos de almacenamiento en Visual Studio Code y supone que ya está familiarizado con la creación y publicación de un único proyecto de almacenamiento.

Prerrequisitos

Antes de empezar, asegúrese de que:

• Cree dos almacenes de tejido en la misma área de trabajo.
  • Para crear un almacén de ejemplo, consulte Crear un almacén de ejemplo en Microsoft Fabric.
• Cree o extraiga un proyecto de base de datos para cada almacén en Visual Studio Code.
  • Para crear un proyecto de base de datos para el almacenamiento existente o un nuevo almacén, consulte Proyectos de almacenamiento de desarrollo en Visual Studio Code.
• Instale Visual Studio Code en la estación de trabajo.
• Instale el SDK .NET para compilar y publicar proyectos de base de datos.
• Instale dos extensiones de Visual Studio Code: SQL Database Projects y SQL Server (mssql).
  • Puede instalar las extensiones necesarias directamente desde Visual Studio Code Marketplace si busca "Proyectos de SQL Database" o "SQL Server (mssql)".
• Los proyectos de almacenamiento validan, compilan y se pueden publicar en Visual Studio Code.

Nota:

Este artículo se centra en los proyectos de warehouse en Visual Studio Code y cómo los versiona en Git como proyectos de código normales. La integración de Fabric Git para espacios de trabajo y artículos de almacén se cubre por separado en Desarrollo y Desplieguey en la integración de Git. El artículo asume que tu espacio de trabajo de Fabric es el destino de despliegue y que el esquema T-SQL está en uno o más proyectos de Visual Studio Code que controlas en Git.

Este artículo no cubre el desarrollo entre almacenes para el punto de conexión de SQL Analytics de un Lakehouse. Las tablas de Lakehouse y los objetos de punto de conexión de SQL Analytics no son objetos de seguimiento en el control de código fuente de la misma manera que los proyectos de almacenamiento. Use elementos de almacén con proyectos de base de datos para la integración completa de Git y el soporte para la implementación en las experiencias nativas de Fabric y las herramientas de clientes.

Escenario: Almacenamientos entre dominios de Zava Analytics

Zava Analytics usa dos dominios empresariales:

• Ventas : pedidos de clientes, ingresos y métricas de canalización.
• Marketing : campañas, canales y métricas de involucración.

Cada dominio tiene:

• Un almacén de tejido en la misma área de trabajo:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Un proyecto database en Visual Studio Code:

  • Zava.Sales.Warehouse
  • Zava.Marketing.Warehouse

Para construir procesos ELT e informes integrales, cada dominio necesita vistas de solo lectura para acceder a los datos del otro dominio.

• Sales necesita compromiso de marketing por parte del cliente.
• Marketing necesita rendimiento de ventas por campaña.

Necesitas:

• Establecer dependencias unidireccionales entre almacenes a través de referencias de base de datos.
• Evite las dependencias cíclicas.

Asegurarse de que las dependencias entre almacenes son unidireccionales

Para cada par de almacenes, elija una dirección para la dependencia lógica:

Ejemplo:

• Sales depende de Marketing para los datos de interacción.
• Marketing no depende de Sales para ninguno de los objetos necesarios al implementar.

En la práctica:

Zava.Sales.Warehouse tiene una referencia de base de datos a Zava.Marketing.Warehouse.

• T-SQL en el Sales almacén de datos puede usar nombres en tres partes como:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouse no hace referencia a Sales objetos que provocarían un ciclo de dependencias en el momento de la implementación.

Sugerencia

Para cada par de almacenes, dibuje un diagrama de flecha simple (Sales → Marketing). Si encuentras flechas apuntando en ambas direcciones para el mismo tipo de objeto, refactoriza el diseño para restaurar una dependencia unidireccional.

Evitar dependencias cíclicas

Una dependencia cíclica se produce cuando el almacén A y el almacén B dependen entre sí de una manera que el motor no puede resolver en una sola implementación.

Ejemplo de problema (no hagas esto):

• ZavaSalesWarehouse.dbo.CustomerRollup vista:

  CREATE VIEW dbo.CustomerRollup AS
  SELECT  c.CustomerId,
          c.TotalRevenue,
          m.LastCampaignId
  FROM    dbo.CustomerRevenue AS c
  LEFT OUTER JOIN   
          ZavaMarketingWarehouse.dbo.CustomerEngagement AS m
          ON c.CustomerId = m.CustomerId;
  

• ZavaMarketingWarehouse.dbo.CampaignAttribution vista:

  CREATE VIEW dbo.CampaignAttribution AS
  SELECT  m.CampaignId,
          SUM(s.TotalRevenue) AS RevenueAttributed
  FROM    dbo.Campaigns AS m
  LEFT OUTER JOIN    
          ZavaSalesWarehouse.dbo.CustomerRollup AS s
          ON m.CampaignId = s.LastCampaignId
  GROUP BY m.CampaignId;
  

En este antipatrón:

• CustomerRollup en Ventas depende de CustomerEngagement en Marketing.
• CampaignAttribution en Marketing depende de CustomerRollup en Ventas.

Este antipatrón crea un ciclo: la vista de Ventas → la vista de Marketing → la vista de Ventas de nuevo.

Guía:

No modele las dependencias mutuas entre almacenes como objetos de nivel de esquema normales. Si realmente necesita este tipo de lógica, mueva un lado de la dependencia a:

• Un script posterior a la implementación o
• Un modelo semántico posterior o informe que une los dos almacenes durante la consulta.

Utiliza scripts previos y posteriores al despliegue para una lógica sensible al despliegue entre almacenes

Dado que las implementaciones de almacenamiento son operaciones de difusión completa de esquemas (no implementaciones parciales por objeto), debemos manejar con cuidado los elementos compartidos entre almacenes.

Si el almacén A y el almacén B necesitan objetos que dependen entre sí:

• Mantenga las tablas principales y las vistas principales en cada proyecto de almacenamiento.
• Mueva vistas de puente o objetos de utilidad que crean ciclos en scripts previos o posteriores a la implementación en un proyecto.
• Asegúrese de que esos scripts son idempotentes y seguros para volver a ejecutarse.

Patrones de ejemplo:

• Script previo a la implementación: quite temporalmente una vista entre almacenes antes de aplicar los cambios de esquema que lo interrumpirían.
• Script posterior a la implementación: recrear o actualizar la vista interalmacén después de la implementación de ambos almacenes.

Para obtener más información y ejemplos, consulte Scripts previos a la implementación y posteriores a la implementación para Fabric Data Warehouse.

Patrón 1: Referencias directas entre almacenes a través de referencias de base de datos

En este patrón, modelas dependencias unidireccionales directamente en los proyectos de bases de datos usando Referencias de Base de Datos.

Paso 1: Empezar a partir de dos proyectos de almacenamiento existentes

Ya debería tener:

• Zava.Sales.Warehouse → implementado en ZavaSalesWarehouse
• Zava.Marketing.Warehouse → implementado en ZavaMarketingWarehouse

Crea o extrae cada proyecto utilizando los pasos de Develop warehouse projects en Visual Studio Code.

Paso 2: Agregar una referencia de base de datos de Ventas a Marketing

• En Visual Studio Code, abra la vista Database Projects.
• Haga clic con el botón derecho en el Zava.Sales.Warehouse proyecto.
• Seleccione Agregar referencia de base de datos....
• Elija una de las siguientes opciones:
  • Proyecto de base de datos en el espacio de trabajo actual (también abrir el proyecto de base de datos referenciado en Visual Studio Code), o
  • Aplicación de nivel de datos (.dacpac) (usa esta opción si has construido un .dacpac para el Marketing almacén).
• Establezca las opciones de referencia:
  • Tipo de referencia: Mismo servidor, base de datos diferente.
  • Nombre o variable de la base de datos: Use una variable SQLCMD, por ejemplo [$(MarketingWarehouseName)].
• Guarde y recompile el proyecto Sales.

En el .sqlproj archivo, debería ver una entrada similar a la siguiente:

<ItemGroup>
  <ArtifactReference Include="..\Zava.Marketing.Warehouse\bin\Debug\Zava.Marketing.Warehouse.dacpac">
    <DatabaseVariableLiteralValue>$(MarketingWarehouseName)</DatabaseVariableLiteralValue>
  </ArtifactReference>
</ItemGroup>
<ItemGroup>
  <SqlCmdVariable Include="MarketingWarehouseName">
    <DefaultValue>ZavaMarketingWarehouse</DefaultValue>
  </SqlCmdVariable>
</ItemGroup>

Sugerencia

Usando una variable SQLCMD como nombre remoto del almacén, puedes reutilizar el mismo proyecto en todos tus entornos, como Dev, Test y Prod.

Paso 3: Crear una vista interalmacenes en la sección de Ventas

En el proyecto Sales, agregue una vista que lea del almacén Marketing.

-- schema/Views/dbo.CustomerEngagementFact.sql
CREATE VIEW [dbo].[CustomerEngagementFact] AS
SELECT
    s.CustomerId,
    s.TotalRevenue,
    m.LatestChannel,
    m.LastEngagementDate
FROM dbo.CustomerRevenue AS s
JOIN [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] AS m
    ON s.CustomerId = m.CustomerId;

Puntos clave:

• El nombre [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] de tres partes coincide con el patrón T-SQL que se usa para las consultas entre almacenes en el editor de Fabric SQL.
• DacFx resuelve la base de datos externa a través de la referencia de la base de datos.

Construir el proyecto para asegurarse de que no haya errores de referencia sin resolver SQL71501.

Paso 4: Publicar el almacén de marketing y luego el de Ventas

Para evitar problemas de implementación:

• Compilación y publicaciónZava.Marketing.Warehouse Primero:
  • Haga clic con el botón derecho en proyecto → Compilar.
  • Haga clic con el botón derecho en el proyecto → Publicar → elija ZavaMarketingWarehouse.
• Una vez Marketing que la implementación se realiza correctamente, compile y publiqueZava.Sales.Warehouse:
  • Haga clic con el botón derecho en proyecto → Compilar.
  • Haga clic con el botón derecho en el proyecto → Publicar → elija ZavaSalesWarehouse.

El flujo de implementación resultante es:

Zava.Marketing.Warehouse (sin dependencias externas) → Zava.Sales.Warehouse (depende de Marketing)

Ahora, cualquier consulta de T-SQL en ZavaSalesWarehouse puede usar la vista dbo.CustomerEngagementFact, que lee internamente del almacén Marketing mediante T-SQL entre almacenes.

Sigue aprendiendo

• Combina este patrón con el control del código fuente y la guía sobre CI/CD en Desarrollo y despliegue y la documentación de integración de Git de Fabric.
• Amplíe el escenario de Zava Analytics para incluir entornos de desarrollo, pruebas y producción, mediante canalizaciones de implementación o CI/CD externos para orquestar el orden de publicación en varios almacenes.

Contenido relacionado

• Flujos de trabajo de desarrollo e implementación