Sviluppare e implementare dipendenze inter-magazzino

Questo articolo illustra come modellare e distribuire dipendenze tra warehouse usando progetti di database SQL in Visual Studio Code. Si parte da due progetti di warehouse esistenti e si configurano dipendenze unidirezionali tra di essi usando riferimenti al database.

Questo articolo si basa sui concetti di Develop warehouse in Visual Studio Code e presuppone che tu abbia già familiarità con la compilazione e la pubblicazione di un singolo progetto warehouse.

Prerequisiti

Prima di iniziare, assicurarsi di:

• Crea due Fabric Warehouses nella stessa area di lavoro.
  • Per creare un nuovo warehouse di esempio, vedere Creare un warehouse di esempio in Microsoft Fabric.
• Creare o estrarre un progetto database per ogni magazzino in Visual Studio Code.
  • Per creare un progetto di database per il tuo magazzino esistente o per un nuovo magazzino, consulta Sviluppare progetti di magazzino in Visual Studio Code.
• Installare Visual Studio Code nella workstation.
• Installare .NET SDK per compilare e pubblicare progetti di database.
• Installare due estensioni Visual Studio Code: progetti di database SQL e SQL Server (mssql).
  • È possibile installare le estensioni necessarie direttamente da Visual Studio Code marketplace cercando "Progetti di database SQL" o "SQL Server (mssql)".
• I progetti di warehouse convalidano, compilano e possono essere pubblicati in Visual Studio Code.

Annotazioni

Questo articolo è incentrato sui progetti warehouse in Visual Studio Code e su come eseguirne la versione in Git come progetti di codice regolari. L'integrazione di Fabric Git per spazi di lavoro e articoli di magazzino è trattata separatamente in Development and Deployment e integrazione Git. L'articolo presume che il tuo workspace Fabric sia il target di distribuzione e che lo schema T-SQL sia presente in uno o più progetti Visual Studio Code che controlli le versioni su Git.

Questo articolo non copre lo sviluppo inter-warehouse per l'endpoint di analisi SQL di un Lakehouse. Le tabelle Lakehouse e gli oggetti endpoint di Analytics SQL non vengono rilevati nel controllo del codice sorgente nello stesso modo dei progetti di data warehouse. Usare gli elementi warehouse con progetti di database per il supporto completo dell'integrazione e della distribuzione git nelle esperienze native di Fabric e negli strumenti client.

Scenario: Magazzini tra domini di Zava Analytics

Zava Analytics usa due domini aziendali:

• Vendite: metriche relative a ordini, ricavi e pipeline dei clienti.
• Marketing : campagne, canali e metriche di engagement.

Ogni dominio ha:

• Un warehouse fabric nello stesso spazio di lavoro:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Un progetto database in Visual Studio Code:

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

Per creare report e ELT end-to-end, ogni dominio deve avere visualizzazioni di sola lettura per accedere ai dati dall'altro dominio:

• Sales ha bisogno di coinvolgimento di marketing da parte del cliente.
• Marketing richiede prestazioni di vendita per campagna.

Dovrai:

• Stabilire dipendenze incrociate unidirezionali tra magazzini dati tramite riferimenti al database.
• Evitare dipendenze cicliche.

Verificare che le dipendenze tra i magazzini siano unidirezionali

Per ogni coppia di warehouse, scegliere una direzione per la dipendenza logica:

Esempio:

• Sales dipende dai dati di coinvolgimento di Marketing.
• Marketing non dipende da Sales per gli oggetti necessari in fase di distribuzione.

In pratica:

Zava.Sales.Warehouse ha un riferimento al database a Zava.Marketing.Warehouse.

• T-SQL nel magazzino dati può utilizzare nomi in tre parti come:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouse non fa riferimento a Sales oggetti che forzano un ciclo di dipendenza in fase di distribuzione.

Suggerimento

Per ogni coppia di magazzini, disegnare un semplice diagramma freccia (Sales → Marketing). Se trovi frecce che puntano in entrambe le direzioni per lo stesso tipo di oggetto, rifattorizza il design per ripristinare una dipendenza unidirezionale.

Evitare dipendenze cicliche

Una dipendenza ciclica si verifica quando il magazzino A e il magazzino B dipendono l'uno dall'altro in un modo tale che il motore non possa risolvere in una singola distribuzione.

Esempio di problema (non eseguire questa operazione):

• 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;
  

In questo anti-modello:

• CustomerRollup in Vendite dipende da CustomerEngagement in Marketing.
• CampaignAttribution In Marketing dipende CustomerRollup da Sales.

Questo anti-modello crea un ciclo: visualizzazione Vendite → visualizzazione Marketing → visualizzazione Vendite di nuovo.

Indicazioni:

Non modellare le dipendenze reciproche tra i warehouse come normali oggetti a livello di schema. Se hai davvero bisogno di questo tipo di logica, sposta un lato della dipendenza in un modello semantico o report a valle che unisce i due warehouse al momento della query.

Riferimenti diretti cross-warehouse tramite riferimenti del database

In questo modello si modellano le dipendenze unidirezionale direttamente nei progetti di database usando riferimenti al database.

Passaggio 1: Iniziare da due progetti di warehouse esistenti

Dovresti avere già:

• Zava.Sales.Warehouse → distribuita in ZavaSalesWarehouse
• Zava.Marketing.Warehouse → distribuita in ZavaMarketingWarehouse

Ogni progetto è stato creato o estratto usando i passaggi descritti in Develop warehouse in Visual Studio Code.

Passaggio 2: Aggiungere un riferimento al database da Vendite a Marketing

• In Visual Studio Code, apri la vista Database Projects.
• Fare clic con il pulsante destro del mouse sul Zava.Sales.Warehouse progetto.
• Selezionare Aggiungi riferimento al database....
• Scegliere una delle seguenti:
  • ProgettoDatabase nell'area di lavoro corrente (un progetto di database a cui si fa riferimento in questo modo deve essere aperto anche in Visual Studio Code) o
  • Applicazione livello dati (.dacpac) (Assumendo che tu abbia creato un .dacpac per il Marketing magazzino).
• Impostare le opzioni di riferimento:
  • Tipo riferimento: Stesso server, database diverso.
  • Nome del database o variabile: Usare una variabile SQLCMD, ad esempio [$(MarketingWarehouseName)].
• Salvare e ricompilare il progetto Sales.

.sqlproj Nel file dovrebbe essere visualizzata una voce simile alla seguente:

<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>

Suggerimento

L'uso di una variabile SQLCMD per il nome del warehouse remoto consente di riutilizzare lo stesso progetto in tutti gli ambienti, ad esempio Sviluppo/Test/Prod, in cui i nomi del magazzino potrebbero differire.

Passaggio 3: Creare una visualizzazione intermagazzino in Sales

Aggiungere nel Sales progetto una vista che legge dall'Marketing archivio:

-- 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;

Punti chiave:

• Il nome [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] in tre parti corrisponde al modello T-SQL usato per le query tra magazzini nell'editor SQL Fabric.
• DacFx risolve il database esterno tramite il riferimento al database.

Compilare il progetto per assicurarsi che non siano presenti errori di riferimento non risolti SQL71501.

Passaggio 4: Pubblicare il Magazzino Marketing, quindi Vendite

Per evitare problemi di distribuzione:

• Compilare e pubblicareZava.Marketing.Warehouse primo:
  • Fare clic con il pulsante destro del mouse sul progetto → Compila.
  • Fare clic con il pulsante destro del mouse sul progetto → Pubblica → scegliere ZavaMarketingWarehouse.
• Una volta che la Marketing distribuzione ha avuto successo, compilare e pubblicareZava.Sales.Warehouse:
  • Fare clic con il pulsante destro del mouse sul progetto → Compila.
  • Fare clic con il pulsante destro del mouse sul progetto → Pubblica → scegliere ZavaSalesWarehouse.

Il flusso di distribuzione risultante è:

Zava.Marketing.Warehouse (nessuna dipendenza esterna) → Zava.Sales.Warehouse (dipende da Marketing)

Ora, qualsiasi query T-SQL in ZavaSalesWarehouse può usare la vista dbo.CustomerEngagementFact, che legge internamente dal magazzino Marketing usando T-SQL inter-magazzini.

Continua a imparare

• Combina questo schema con il controllo di versione e la guida CI/CD nello sviluppo e distribuzione e nella documentazione di integrazione Fabric git.
• Estendere lo scenario di Zava Analytics per includere ambienti di sviluppo/test/prod , usando pipeline di distribuzione o CI/CD esterno per orchestrare l'ordine di pubblicazione in più warehouse.

Contenuti correlati

• Flussi di lavoro di sviluppo e distribuzione