Entwickeln und Bereitstellen von lagerübergreifenden Abhängigkeiten

In diesem Artikel erfahren Sie, wie Sie Lagerübergreifende Abhängigkeiten mithilfe von SQL-Datenbankprojekten in Visual Studio Code modellieren und bereitstellen. Man beginnt mit zwei bestehenden Warehouse-Projekten und konfiguriert Einwegabhängigkeiten zwischen ihnen mithilfe von Datenbankreferenzen.

Dieser Artikel baut auf den Konzepten in Develop-Lagerprojekten in Visual Studio Code auf und geht davon aus, dass Sie bereits ein einziges Lagerprojekt erstellen und veröffentlichen.

Voraussetzungen

Bevor Sie beginnen, stellen Sie sicher, dass Sie:

• Erstellen Sie zwei Fabric Warehouses im selben Arbeitsbereich.
  • Informationen zum Erstellen eines neuen Beispiellagers finden Sie unter Create a sample Warehouse in Microsoft Fabric.
• Erstellen oder extrahieren Sie ein Datenbankprojekt für jedes Lager in Visual Studio Code.
  • Informationen zum Erstellen eines Datenbankprojekts für Ihr vorhandenes Lager oder ein neues Lager finden Sie unter Develop-Lagerprojekte in Visual Studio Code.
• Installieren Sie Visual Studio Code auf Ihrer Arbeitsstation.
• Installieren Sie das SDK .NET, um Datenbankprojekte zu erstellen und zu veröffentlichen.
• Installieren Sie zwei Visual Studio Code Erweiterungen: SQL-Datenbankprojekte und SQL Server (mssql).
  • Sie können die erforderlichen Erweiterungen direkt aus Visual Studio Code Marketplace installieren, indem Sie nach "SQL-Datenbankprojekte" oder "SQL Server (mssql)" suchen.
• Die Lagerprojekte überprüfen, erstellen und können in Visual Studio Code veröffentlicht werden.

Szenario: Zava Analytics domänenübergreifende Lagerhäuser

Zava Analytics verwendet zwei Geschäftsdomänen:

• Vertrieb – Kundenaufträge, Umsatz- und Pipelinemetriken.
• Marketing – Kampagnen, Kanäle und Engagement-Metriken.

Jede Domäne hat:

• Ein Fabric Warehouse im selben Arbeitsbereich:

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Ein Datenbankprojekt in Visual Studio Code:

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

Um End-to-End-ELT und Berichterstellung zu realisieren, benötigt jede Domäne schreibgeschützte Ansichten, um auf Daten aus der anderen Domäne zuzugreifen.

• Sales erfordert ein Marketing-Engagement von Kunden.
• Marketing benötigt die Vertriebsleistung nach Kampagnen.

Sie müssen:

• Richten Sie Einweg-lagerübergreifende Abhängigkeiten über Datenbankverweise ein.
• Vermeiden Sie zyklische Abhängigkeiten.

Sicherstellen, dass Abhängigkeiten zwischen Lagerhäusern unidirektional sind

Wählen Sie für jedes Lagerpaar eine Richtung für die logische Abhängigkeit aus:

Beispiel:

• Sales ist von Marketing für Interaktionsdaten abhängig.
• Marketing hängt nicht von Sales für Objekte ab, die beim Deployment benötigt werden.

Praktisch:

Zava.Sales.Warehouse hat eine Datenbankreferenz zuZava.Marketing.Warehouse.

• T-SQL in der Sales Datenbank kann dreiteilige Namen wie:

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouse verweist nicht auf Sales Objekte, die bei der Bereitstellung einen Abhängigkeitszyklus erzwingen würden.

Vermeiden von zyklischen Abhängigkeiten

Eine zyklische Abhängigkeit geschieht, wenn Warehouse A und Warehouse B beide voneinander abhängig sind, sodass das Modul in einer einzelnen Bereitstellung nicht aufgelöst werden kann.

Problembeispiel (gehen Sie nicht wie folgt vor):

• ZavaSalesWarehouse.dbo.CustomerRollup ansehen:

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

  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 diesem Antimuster:

• CustomerRollup in Sales hängt von CustomerEngagement in Marketing ab.
• CampaignAttribution in Marketing hängt von CustomerRollup im Verkauf ab.

Dieses Antimuster erstellt einen Zyklus: Verkaufsansicht → Marketingansicht → Verkaufsansicht erneut.

Leitfaden:

Modellen Sie keine gegenseitigen Abhängigkeiten zwischen Lagerhäusern als normale Objekte auf Schemaebene. Wenn du diese Art von Logik wirklich brauchst, verschiebe eine Seite der Abhängigkeit in ein nachgelagertes semantisches Modell oder einen Bericht, der die beiden Lager zur Abfragezeit verbindet.

Direkte Cross-Warehouse-Referenzen über Datenbankreferenzen

In diesem Muster modellieren Sie unidirektionale Abhängigkeiten direkt in den Datenbankprojekten mithilfe von Datenbankverweise.

Schritt 1: Starten von zwei vorhandenen Lagerprojekten

Sie sollten folgendes bereits haben:

• Zava.Sales.Warehouse → bereitgestellt für ZavaSalesWarehouse
• Zava.Marketing.Warehouse → bereitgestellt für ZavaMarketingWarehouse

Jedes Projekt wurde mit den Schritten in Develop Warehouse-Projekten in Visual Studio Code erstellt oder extrahiert.

Schritt 2: Hinzufügen eines Datenbankverweises von Sales to Marketing

• Öffnen Sie in Visual Studio Code die Ansicht Datenbankprojekte.
• Klicken Sie mit der rechten Maustaste auf das Zava.Sales.Warehouse Projekt.
• Wählen Sie "Datenbankverweis hinzufügen..." aus.
• Wählen Sie eine der folgenden:
  • Datenbankprojekt im aktuellen Arbeitsbereich (Ein Datenbankprojekt, auf das auf diese Weise verwiesen wird, muss auch in Visual Studio Code geöffnet sein) oder
  • Data-tier application (.dacpac) (Es wird vorausgesetzt, dass Sie ein .dacpac für das Marketing-Lager erstellt haben).
• Legen Sie die Referenzoptionen fest:
  • Verweistyp: Derselbe Server, unterschiedliche Datenbank.
  • Datenbankname oder Variable: Verwenden Sie eine SQLCMD-Variable, z. B [$(MarketingWarehouseName)]. .
• Speichern und neu erstellen Sie das Vertriebsprojekt.

In der .sqlproj Datei sollte ein Eintrag ähnlich wie der folgende angezeigt werden.

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

Schritt 3: Erstellen einer lagerübergreifenden Ansicht in "Vertrieb"

Fügen Sie im Sales Projekt eine Ansicht hinzu, die aus dem Marketing Lager gelesen wird:

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

Wichtige Punkte:

• Der dreiteilige Name [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] entspricht dem T-SQL-Muster, das für Querlagerabfragen im Fabric SQL-Editor verwendet wird.
• DacFx löst die externe Datenbank über den Datenbankverweis auf.

Erstellen Sie das Projekt, um sicherzustellen, dass keine SQL71501 nicht aufgelösten Verweisfehler vorhanden sind.

Schritt 4: Veröffentlichen des Marketing-Datenlagers und dann Vertrieb.

So vermeiden Sie Bereitstellungsprobleme:

• Erstellen und VeröffentlichenZava.Marketing.Warehouse zuerst:
  • Klicken Sie mit der rechten Maustaste auf Projekt → Erstellen.
  • Klicken Sie mit der rechten Maustaste auf projekt → veröffentlichen → wählen ZavaMarketingWarehouse.
• Nachdem Marketing die Bereitstellung erfolgreich war, erstellen und veröffentlichenZava.Sales.Warehouse Sie Folgendes:
  • Klicken Sie mit der rechten Maustaste auf Projekt → Erstellen.
  • Klicken Sie mit der rechten Maustaste auf projekt → veröffentlichen → wählen ZavaSalesWarehouse.

Der resultierende Bereitstellungsfluss lautet:

Zava.Marketing.Warehouse (keine externen Abhängigkeiten) → Zava.Sales.Warehouse (hängt von Marketing)

Jetzt kann jede T-SQL-Abfrage in ZavaSalesWarehouse die dbo.CustomerEngagementFact-Ansicht nutzen, die intern mithilfe von T-SQL über Lager hinweg aus dem Marketing-Lager liest.

Weiter lernen

• Kombinieren Sie dieses Muster mit Quellcodekontrolle und CI/CD-Anleitung in Entwicklung und Bereitstellung sowie mit Fabric-Git-Integrationsdokumentation.
• Erweitern Sie das Zava Analytics-Szenario um Dev/Test/Prod-Umgebungen , indem Sie Bereitstellungspipelinen oder externe CI/CD verwenden, um die Veröffentlichungsreihenfolge für mehrere Lager zu koordinieren.

Verwandte Inhalte

• Entwicklungs- und Bereitstellungsworkflows