Vyvinúť a nasadiť závislosti medzi skladmi

V tomto článku sa naučíte, ako modelovať a nasadzovať závislosti medzi skladmi pomocou SQL databázových projektov vo Visual Studio Code. Začínate od dvoch existujúcich skladových projektov a konfigurujete jednosmerné závislosti medzi nimi pomocou databázových referencií a tam, kde je to potrebné, skriptov pred a po nasadení.

Tento článok nadväzuje na koncepty z Develop warehouse projects vo Visual Studio Code a predpokladá, že už sa cítite pohodlne s vytvorením a publikovaním jedného skladového projektu.

Prerequisites

Skôr než začnete, uistite sa, že:

• Vytvorte dva sklady látok v rovnakom pracovnom priestore.
  • Ak chcete vytvoriť nový sklad vzoriek, pozrite si tému Vytvorenie vzorového skladu v službe Microsoft Fabric.
• Vytvorte alebo extrahujte databázový projekt pre každý sklad vo Visual Studio Code.
  • Ak chcete vytvoriť databázový projekt pre váš existujúci sklad alebo nový sklad, pozrite si Vyvíjať skladové projekty vo Visual Studio Code.
• Nainštalujte Visual Studio Code na svoju pracovnú stanicu.
• Nainštalujte súpravu .NET SDK na vytváranie a publikovanie databázových projektov.
• Nainštalujte dve rozšírenia Visual Studio Code: SQL Database Projects a SQL Server (mssql).
  • Požadované rozšírenia môžete nainštalovať priamo z trhu Visual Studio Code vyhľadaním výrazu "SQL Database Projects" alebo "SQL Server (mssql)".
• Skladové projekty overujú, stavajú a môžu byť publikované vo Visual Studio Code.

Poznámka

Tento článok sa zameriava na skladové projekty vo Visual Studio Code a na to, ako ich verzovať v Gite ako bežné kódové projekty. Integrácia Fabric Git pre pracovné priestory a skladové položky je pokrytá samostatne v Source Control s dokumentáciou Fabric Data Warehouse a Git integrácie. Článok predpokladá, že váš Fabric pracovný priestor je cieľom nasadenia a T-SQL schéma sa nachádza v jednom alebo viacerých projektoch Visual Studio Code, ktoré verzujete v Gite.

Tento článok sa nezaoberá vývojom naprieč skladmi pre SQL analytický endpoint Lakehouse. Lakehouse tabuľky a SQL endpoint objekty nie sú sledované objekty vo source control rovnako ako skladové projekty. Používajte skladové položky s databázovými projektmi na kompletnú integráciu gitu a podporu nasadenia v natívnych zariadeniach Fabric a klientských nástrojoch.

Scenár: Medzidoménové sklady Zava Analytics

Zava Analytics využíva dve obchodné domény:

• Predaj – zákaznícke objednávky, tržby a metriky pipeline.
• Marketing – kampane, kanály a metriky zapojenia.

Každá doména má:

• Sklad látok v tom istom pracovnom priestore:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Projekt databázy vo Visual Studio Code:

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

Na vytvorenie end-to-end ELT a reportovania potrebuje každá doména len na čítanie na prístup k dátam z druhej domény:

• Sales Vyžaduje marketingovú angažovanosť zákazníka.
• Marketing Potrebuje predajný výkon podľa kampane.

Musíte:

• Vytvorte jednosmerné závislosti medzi skladmi prostredníctvom databázových referencií.
• Vyhnite sa cyklickým závislostiam.
• Použite skripty pred a po nasadení pre prípady, keď objekty v oboch skladoch závisia jeden od druhého.

Zabezpečiť, aby závislosti medzi skladmi boli jednosmerné

Pre každý pár skladov zvoľte smer logickej závislosti:

Príklad:

• Sales Závisí to od Marketing údajov o zapojení.
• Marketing Nezávisí od Sales žiadnych objektov, ktoré sú potrebné pri nasadení.

V praxi:

Zava.Sales.Warehouse má databázový odkaz na Zava.Marketing.Warehouse.

• T-SQL v sklade Sales môže používať trojdielne názvy, napríklad:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouseneodkazuje na objekty, ktoré by vynútili závislostný cyklus pri nasadení.Sales

Tip

Pre každý pár skladov nakreslite jednoduchý šípkový diagram (Sales → Marketing). Ak zistíte, že šípky ukazujú oboma smermi pre ten istý typ objektu, pravdepodobne budete musieť refaktorovať alebo presunúť logiku do skriptov pred a po nasadení.

Vyhnite sa cyklickým závislostiam

Cyklická závislosť nastáva, keď sklad A a sklad B na sebe závisia spôsobom, ktorý engine nedokáže vyriešiť v jednom nasadení.

Príklad problému (nerobte to):

• ZavaSalesWarehouse.dbo.CustomerRollup pohľad:

  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 pohľad:

  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;
  

V tomto anti-vzore:

• CustomerRollup v predaji závisí od CustomerEngagementmarketingu.
• CampaignAttribution v marketingu závisí od CustomerRolluppredaja.

Tento anti-vzor vytvára cyklus: Pohľad na predaj → Zobrazenie marketingu → opäť zobrazenie predaja.

Usmernenie:

Nemodelujte vzájomné závislosti medzi skladmi ako bežné objekty na úrovni schémy. Ak naozaj potrebujete takúto logiku, posuňte jednu stranu závislosti do:

• Skript po nasadení, alebo
• Downstream sémantický model alebo report, ktorý spája oba sklady v čase dotazu.

Používajte skripty pred a po nasadení pre citlivú logiku medzi skladmi

Keďže nasadenia v skladoch sú plné operácie typu schema diff (nie čiastočné nasadenia na každý objekt), zaobchádzajte s položkami medzi skladmi opatrne:

Ak sklad A aj sklad B potrebujú objekty, ktoré na sebe závisia:

• Základné tabuľky a pohľady na jadro ponechajte v každom skladovom projekte.
• Presúvajte pohľady na mosty alebo utility objekty , ktoré vytvárajú cykly, do skriptov pred alebo po nasadení v jednom projekte.
• Uistite sa, že tieto skripty sú idempotentné a bezpečné na opakované spustenie.

Príklady vzorov:

• Skript pred nasadením: dočasne zrušte pohľad medzi skladmi predtým, než aplikujete zmeny v schéme, ktoré by ho pokazili.
• Skript po nasadení: znovu vytvorte alebo aktualizujte pohľad medzi skladmi po nasadení oboch skladov.

Vzor 1: Priame odkazy medzi skladmi cez databázové odkazy

V tomto vzore modelujete jednosmerné závislosti priamo v databázových projektoch pomocou databázových referencií.

Krok 1: Začnite s dvoma existujúcimi skladovými projektmi

Mali by ste už mať:

• Zava.Sales.Warehouse → nasadená do ZavaSalesWarehouse
• Zava.Marketing.Warehouse → nasadená do ZavaMarketingWarehouse

Každý projekt bol vytvorený alebo extrahovaný pomocou krokov v sekcii Vyvíjať skladové projekty vo Visual Studio Code.

Krok 2: Pridajte referenciu databázy z predaja do marketingu

• Vo Visual Studio Code otvorte pohľad Databázové projekty .
• Kliknite pravým tlačidlom na Zava.Sales.Warehouse projekt.
• Vyberte Pridať referenciu databázy....
• Vyberte si jednu z:
  • Databázový projekt v aktuálnom pracovnom priestore (Databázový projekt, na ktorý sa takto odkazuje, musí byť tiež otvorený vo Visual Studio Code), alebo
  • Data-tier aplikácia (.dacpac) (Predpokladá, že .dacpac ste vytvorili pre sklad).Marketing
• Nastavte referenčné možnosti:
  • Typ referencie: Ten istý server, iná databáza.
  • Názov databázy alebo premenná: Použite napríklad premennú [$(MarketingWarehouseName)]SQLCMD .
• Uložte a obnovte projekt Sales.

V súbore .sqlproj by ste mali vidieť záznam podobný tomu:

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

Tip

Použitie premennej SQLCMD pre vzdialený názov skladu vám umožní opätovne použiť ten istý projekt vo všetkých prostrediach, napríklad Dev/Test/Prod, kde sa názvy skladov môžu líšiť.

Krok 3: Vytvorte pohľad naprieč skladom v sekcii Predaj

V projekte Sales pridajte pohľad, ktorý číta zo skladu 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;

Kľúčové body:

• Trojdielny názov [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] zodpovedá T-SQL vzoru používanému pre dotazy medzi skladmi v Fabric SQL editore.
• DacFx rieši externú databázu cez referenciu databázy.

Vytvorte projekt tak, aby neexistovali SQL71501 nevyriešené chyby referencií .

Krok 4: Zverejnite marketingový sklad, potom predaj

Aby sa predišlo problémom s nasadením:

• Postaviť a publikovaťZava.Marketing.Warehouse prvý:
  • Pravým kliknutím kliknite na projekt → Build.
  • Kliknite pravým tlačidlom na projekt → Publikovať → vybrať ZavaMarketingWarehouse.
• Keď Marketing je nasadenie úspešné, vytvorte a publikujteZava.Sales.Warehouse:
  • Pravým kliknutím kliknite na projekt → Build.
  • Kliknite pravým tlačidlom na projekt → Publikovať → vybrať ZavaSalesWarehouse.

Výsledný postup nasadenia je:

Zava.Marketing.Warehouse (bez externých závislostí) → Zava.Sales.Warehouse (závisí od Marketing)

Teraz môže akýkoľvek T-SQL dotaz ZavaSalesWarehouse použiť dbo.CustomerEngagementFact tento pohľad, ktorý interne číta zo Marketing skladu pomocou cross-warehouse T-SQL.

Vzor 2: Závislosti medzi skladmi spravované pomocou skriptov pred a po nasadení

V niektorých scenároch Zava Analytics môžu obe domény potrebovať agregované objekty, ktoré na sebe závisia. Príklad:

• Predaj chce pohľad, ktorý využíva údaje z marketingových kampaní na poskytovanie tržieb na jednu marketingovú kampaň.
• Marketing chce pohľad, ktorý využíva údaje o tržbách na dosiahnutie efektívnosti marketingových kampaní.

Nechcete, aby oba tieto objekty boli bežné pohľady, ktoré sa podieľajú na plnom nasadení modelu, pretože to riskuje cyklickú závislosť alebo krehké poradie nasadenia.

Namiesto toho:

• Udržujte základný model každého skladu nezávislý.
• Použite post-deployment skripty v jednom projekte na vytvorenie viacerých pohľadov naprieč skladom, keď sú obe schémy na mieste.

Krok 1: Pridajte databázové odkazy na validáciu v čase kompilácie

Nastavte referencie podobné Pattern 1, ale pre oba projekty:

• V Zava.Sales.Warehouse, pridajte odkaz na Marketing cez [$(MarketingWarehouseName)].
• V Zava.Marketing.Warehouse, voliteľne pridajte odkaz na predaj pomocou [$(SalesWarehouseName)] ak chcete validáciu v čase kompilácie pre pohľady medzi skladmi používané v skriptoch.

V súboroch .sqlproj môžete nastaviť:

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

Krok 2: Vytvorte základné objekty ako bežné projektové objekty

Príklad:

• Sales projekt:

  • dbo.CustomerRevenue stôl
  • dbo.SalesByCampaign Zobraziť (používajúc iba lokálne tabuľky)

• Marketing projekt:

  • dbo.Campaigns stôl
  • dbo.CampaignStats Zobraziť (používajúc iba lokálne tabuľky)

Tieto objekty nepoužívajú dotazy medzi skladmi. V ďalšom kroku predstavíme referencie medzi skladmi.

Krok 3: Pridajte post-nasadený skript pre prechodné pohľady medzi skladmi

Vyberte jeden sklad na hostenie mostových objektov; typicky doména, ktorá najviac spotrebúva kombinovaný výstup. Predpokladajme, že Sales je to doména.

• V projekte Sales : Kliknite pravým tlačidlom myši na projekt a potom pridajte→ Post-Deployment Script.
• Pomenujte scenár.PostDeployment_CrossWarehouse.sql
• V skripte vytvárajte alebo upravujte pohľady medzi skladmi pomocou IF EXISTS / / DROPCREATE vzorov, aby zostali idempotentné.

Príklad skriptu Sales , ktorý odkazuje Marketing na objekty skladu:

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

Tu:

• Jadrové Sales a Marketing skladové projekty zostávajú samostatné a samostatne nasaditeľné.
• Bridge view sa vytvára po nasadení schémy pomocou post-deployment skriptu.
• Ak sa nasadenie spustí viackrát, je idempotentné, pretože skript bezpečne zruší a znovu vytvorí pohľad.

Krok 4: (Voliteľné) Použite skripty pred nasadením na ochranu krehkých závislostí

V pokročilejších situáciách môžete:

• Použite skript pred nasadením na zrušenie alebo vypnutie pohľadov naprieč skladom, ktoré môžu blokovať zmeny schémy (napríklad ak premenovávate stĺpce).
• Nech DacFx použije diff schémy.
• Použite post-deployment skript na opätovné vytvorenie alebo aktualizáciu pohľadov medzi skladmi.

Dôležité

Skripty pred a po nasadení bežia ako súčasť plánu nasadenia a musia byť:

• Idempotentné, čo znamená, že je bezpečné ich používať viackrát.
• Kompatibilné s finálnou schémou vytvorenou DacFx.
• Bez deštruktívnych zmien, ktoré sú v rozpore s vašou BlockOnPossibleDataLoss poistkou.

Krok 5: Publikovať poradie pre skriptom spravované závislosti

Bežný vzorec pre Zava Analytics:

• Publikujte základné projekty:
  • Zava.Marketing.Warehouse (jadrová schéma)
  • Zava.Sales.Warehouse (jadrová schéma + cross-warehouse post-deployment skript)
• Nechajte skript Sales po nasadení vytvoriť pohľady mosta po nasadení vlastnej schémy a odkazovanej Marketing schémy.

Ak zavádzate viac ako dva sklady, opakujte tento vzor po vrstvách. Nikdy nevytvárajte cyklické závislosti cez bežné projektové objekty.

Pokračovať v učení

• Kombinujte tieto vzory s riadením zdrojového kódu a CI/CD riadením vo zdrojovej kontrole s dokumentáciou integrácie Fabric Data Warehouse a Fabric git.
• Rozšíriť scenár Zava Analytics o vývojové / testovacie/produkčné prostredia, využívajúc nasadzovacie pipeline alebo externé CI/CD na orchestráciu objednávky publikovania v rôznych skladoch.

Súvisiaci obsah

• Pracovné postupy vývoja a nasadenia