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 inizia da due progetti di warehouse esistenti e si configurano le dipendenze unidirezionale tra di esse usando i riferimenti al database e, se necessario, gli script di pre-distribuzione e post-distribuzione.

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.

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.

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 è veramente necessario questo tipo di logica, spostare un lato della dipendenza in:

• Uno script post-distribuzione o
• Un modello semantico downstream o report che unisce i due magazzini durante l'interrogazione.

Usa gli script pre- e post-distribuzione per la logica tra data warehouse dipendente dalla distribuzione

Poiché le distribuzioni di magazzino sono operazioni di differenze complete dello schema (non parziali per ogni oggetto), considerate attentamente gli elementi tra magazzini:

Se Warehouse A e Warehouse B hanno entrambi bisogno di oggetti che dipendono l'uno dall'altro:

• Mantenere le tabelle di base e le visualizzazioni principali in ogni progetto warehouse.
• Spostare le visualizzazioni bridge o gli oggetti di utilità che creano cicli negli script di pre-distribuzione o post-distribuzione dello stesso progetto.
• Assicurarsi che tali script siano idempotenti e sicuri da eseguire di nuovo.

Modelli di esempio:

• Script di pre-distribuzione: eliminare temporaneamente una visualizzazione tra warehouse prima di applicare le modifiche dello schema che lo interromperebbero.
• Script post-distribuzione: ricreare o aggiornare la visualizzazione tra warehouse dopo la distribuzione di entrambi i warehouse.

Per altre informazioni ed esempi, vedi Script di pre-distribuzione e post-distribuzione per Fabric Data Warehouse.

Modello 1: Riferimenti diretti tra warehouse tramite riferimenti al database

In questo schema, si modellano dipendenze unidirezionali direttamente nei progetti di database utilizzando i Riferimenti 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

Crea o estrai ogni progetto seguendo i passaggi descritti in Sviluppare progetti di 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 opzioni:
  • Progetto database nell'attuale spazio di lavoro (aprire anche il progetto database referenziato in Visual Studio Code), oppure
  • Applicazione a livello dati (.dacpac) (usare questa opzione se è stato creato un .dacpac per il Marketing data warehouse).
• 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>

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