Compartir a través de

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 ellas 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 Desarrollar proyectos de almacén en Visual Studio Code y se da por supuesto que ya está familiarizado con la creación y publicación de un único proyecto de almacén.

Prerrequisitos

Antes de empezar, asegúrese de que:

Nota:

Este artículo se centra en los proyectos de almacenamiento en Visual Studio Code y en cómo los versiona en Git como proyectos de código normales. La integración de Git de Fabric para áreas de trabajo y elementos de almacén se trata por separado en Control de código fuente con Fabric Data Warehouse y la documentación de integración con Git. El artículo supone que el área de trabajo de Fabric es el destino de implementación y que el esquema de T-SQL reside en uno o varios proyectos de Visual Studio Code que controlas por versiones 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 no son objetos de seguimiento en el control de código fuente de la misma manera que los proyectos de almacén de datos. 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 de base de datos 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.

Se necesita:

  • Establecer dependencias unidireccionales entre almacenes a través de referencias de base de datos.
  • Evite las dependencias cíclicas.
  • Use scripts previos y posteriores a la implementación para casos en los que los objetos de ambos almacenes dependen entre sí.

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 encuentra flechas que apuntan en ambas direcciones para el mismo tipo de objeto, es probable que tenga que refactorizar o mover alguna lógica a scripts previos y posteriores a la implementación.

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 visualización: 
    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.

Uso de scripts previos y posteriores a la implementación para la lógica de almacenamiento cruzado confidencial

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.

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

En este patrón, modela las dependencias unidireccionales directamente en los proyectos de base de datos mediante 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

Cada proyecto se creó o extrajo mediante los pasos descritos en Desarrollo de proyectos de almacenamiento en Visual Studio Code.

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

  • En Visual Studio Code, abra la vista Proyectos de base de datos .
  • 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 área de trabajo actual (un proyecto de base de datos al que se hace referencia de esta manera también debe estar abierto en Visual Studio Code) o
    • Aplicación de capa de datos (.dacpac) ( se asume que ha sido creada si ya tiene una .dacpac para el Marketing almacenamiento).
  • 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

El uso de una variable SQLCMD para el nombre del almacenamiento remoto le permite reutilizar el mismo proyecto en todos los entornos, como Dev/Test/Prod, donde los nombres de almacenamiento pueden diferir.

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.

Patrón 2: Dependencias entre almacenes administradas a través de scripts previos y posteriores a la implementación

En algunos escenarios de Zava Analytics, ambos dominios pueden necesitar objetos agregados que dependen entre sí. Por ejemplo:

  • Las ventas quieren una vista que usa datos de campaña de marketing para proporcionar ingresos de ventas por campaña de marketing.
  • Marketing quiere una vista que usa los datos de ingresos de ventas para proporcionar eficacia de la campaña de marketing.

No quiere que ambos objetos sean vistas normales que participen en la implementación completa del modelo, ya que esto corre el riesgo de una dependencia cíclica o un orden de implementación frágil.

En su lugar, usted:

  • Mantenga independiente el modelo principal de cada almacén.
  • Utiliza scripts posteriores a la implementación dentro de un proyecto para crear más vistas inter-almacenes después de que ambos esquemas estén establecidos.

Paso 1: Agregar referencias de base de datos para la validación en tiempo de compilación

Configure referencias similares a pattern 1, pero para ambos proyectos:

  • En Zava.Sales.Warehouse, agregue una referencia a Marketing a través de [$(MarketingWarehouseName)].
  • En Zava.Marketing.Warehouse, agregue opcionalmente una referencia a Sales a través de [$(SalesWarehouseName)] si desea la validación en tiempo de compilación de vistas entre almacenes usadas en scripts.

En los .sqlproj archivos, puede establecer lo siguiente:

<SqlCmdVariable Include="SalesWarehouseName">
  <DefaultValue>ZavaSalesWarehouse</DefaultValue>
</SqlCmdVariable>

Paso 2: Crear objetos principales como objetos de proyecto normales

Ejemplo:

  • Sales proyecto:

    • Tabla de dbo.CustomerRevenue
    • dbo.SalesByCampaign consulta (utilizando únicamente tablas locales)

  • Marketing proyecto:

    • Tabla de dbo.Campaigns
    • dbo.CampaignStats vista (usando solo tablas locales)

Estos objetos no usan consultas entre almacenes. En el paso siguiente, introduciremos referencias cruzadas entre almacenes.

Paso 3: Agregar un script posterior a la implementación para las vistas de puente entre almacenes

Elija un almacén para hospedar objetos puente; suele ser el dominio que más consume la salida combinada. Supongamos Sales que es ese dominio.

  • En el Sales proyecto: haga clic con el botón derecho en el proyecto y, a continuación, Agregar → Script de post-implementación.
  • Asigne al script PostDeployment_CrossWarehouse.sqlel nombre .
  • En el script, cree o modifique las vistas interalmacenes usando patrones IF EXISTS / DROP / CREATE para mantenerlas idempotentes.

Ejemplo de un script en que Sales hará referencia a Marketing objetos de almacenamiento:

-- PostDeployment_CrossWarehouse.sql

-- Ensure object can be recreated safely
IF OBJECT_ID('dbo.CampaignRevenueBridge', 'V') IS NOT NULL
    DROP VIEW [dbo].[CampaignRevenueBridge];
GO

CREATE VIEW [dbo].[CampaignRevenueBridge] AS
SELECT
    c.CampaignId,
    c.CampaignName,
    m.Channel,
    SUM(s.TotalRevenue) AS Revenue
FROM [$(MarketingWarehouseName)].[dbo].[Campaigns] AS c
JOIN [$(MarketingWarehouseName)].[dbo].[CampaignEngagement] AS m
    ON c.CampaignId = m.CampaignId
JOIN dbo.SalesByCampaign AS s
    ON s.CampaignId = c.CampaignId
GROUP BY
    c.CampaignId,
    c.CampaignName,
    m.Channel;
GO

Aquí:

  • Los proyectos principales Sales y Marketing de almacenamiento permanecen independientes e implementables por sí mismos.
  • La vista puente se crea después de la implementación del esquema a través del script posterior a la implementación.
  • Si la implementación se ejecuta varias veces, es idempotente, ya que el script elimina y vuelve a crear la vista de forma segura.

Paso 4: (Opcional) Uso de scripts previos a la implementación para proteger dependencias frágiles

En escenarios más avanzados, puede:

  • Use un script previo a la implementación para quitar o deshabilitar las vistas entre almacenes que podrían bloquear los cambios de esquema (por ejemplo, si cambia el nombre de las columnas).
  • Permita que DacFx aplique las diferencias de esquema.
  • Use el script posterior a la implementación para volver a crear o actualizar las vistas entre almacenes.

Importante

Los scripts previos y posteriores a la implementación se ejecutan como parte del plan de implementación y deben ser:

  • Idempotente, lo que significa que es seguro ejecutarlo varias veces.
  • Compatible con el esquema final generado por DacFx.
  • Sin cambios destructivos que entran en conflicto con la BlockOnPossibleDataLoss directiva.

Paso 5: Publicar el orden de las dependencias administradas por scripts

Un patrón común para Zava Analytics:

  • Publicar proyectos base:
    • Zava.Marketing.Warehouse (esquema principal)
    • Zava.Sales.Warehouse (esquema principal + script posterior a la implementación entre almacenes)
  • Deje que el script Sales posterior a la implementación cree las vistas puente después de que se desplieguen su propio esquema y el esquema al que se hace Marketing referencia.

Si introduce más de dos almacenes, repita este patrón en capas. Nunca cree dependencias cíclicas a través de objetos de proyecto normales.

Sigue aprendiendo

  • Combina estos patrones con la guía de CI/CD y el control de código fuente en la documentación de control de código fuente con Fabric Data Warehouse y la 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

  • Last updated on