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. Sie beginnen mit zwei vorhandenen Lagerprojekten und konfigurieren unidirektionale Abhängigkeiten zwischen ihnen mithilfe von Datenbankverweise und ggf. Skripts vor der Bereitstellung und nach der Bereitstellung.

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.

Hinweis

Dieser Artikel befasst sich mit warehouse-Projekten in Visual Studio Code und deren Versionsverwaltung in Git als normale Codeprojekte. Fabric Git-Integration für Arbeitsbereiche und Warehouse-Elemente wird separat in Entwicklung und Bereitstellung sowie Git-Integration behandelt. Der Artikel geht davon aus, dass dein Fabric-Arbeitsbereich das Deployment-Ziel ist und das T-SQL-Schema in einem oder mehreren Visual Studio Code-Projekten lebt, die du in Git versionskontrollierst.

In diesem Artikel wird die Lagerübergreifende Entwicklung für den SQL-Analyseendpunkt eines Lakehousenicht behandelt. Lakehouse-Tabellen und SQL-Analyseendpunktobjekte werden in der Quellcodeverwaltung nicht auf die gleiche Weise nachverfolgt wie Lagerprojekte. Verwenden Sie Warehouse-Elemente mit Datenbankprojekten für vollständige Git-Integrations- und Bereitstellungsunterstützung in nativen Fabric-Oberflächen und Clienttools.

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.

Tipp

Zeichnen Sie für jedes Lagerpaar ein einfaches Pfeildiagramm (Sales → Marketing). Wenn du Pfeile in beide Richtungen für denselben Objekttyp findest, refaktoriere das Design, um eine Einwegabhängigkeit wiederherzustellen.

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 Sie diese Art von Logik wirklich benötigen, verschieben Sie eine Seite der Abhängigkeit in:

• Ein Skript nach der Bereitstellung oder
• Ein nachgelagertes semantisches Modell oder Bericht, das die beiden Lagerhäuser zum Zeitpunkt der Abfrage verknüpft.

Verwenden Sie Pre- und Post-Deployment-Skripte für bereitstellungssensible warehouseübergreifende Logik

Da Lagerbereitstellungen vollständige Schema-Diff-Vorgänge (nicht teilweise Bereitstellungen pro Objekt) sind, behandeln Sie lagerübergreifende Elemente sorgfältig:

Wenn Warehouse A und Warehouse B beide Objekte benötigen, die voneinander abhängen:

• Behalten Sie die Wichtigsten Tabellen und Kernansichten in jedem Lagerprojekt bei.
• Verschieben Sie Brückenansichten oder Hilfsobjekte, die Zyklen erzeugen, in Skripts zur Vor- oder Nachbereitung der Bereitstellung innerhalb eines Projekts.
• Stellen Sie sicher, dass diese Skripts idempotent sind und sicher erneut ausgeführt werden können.

Beispielmuster:

• Skript vor der Bereitstellung: Entfernen Sie vorübergehend eine bereichsübergreifende Ansicht, bevor Sie Schemaänderungen anwenden, die sie beeinträchtigen würden.
• Skript nach der Bereitstellung: Erstellen oder Aktualisieren der lagerübergreifenden Ansicht, nachdem beide Lagerhäuser bereitgestellt wurden.

Weitere Informationen und Beispiele finden Sie unter Skripts vor der Bereitstellung und nach der Bereitstellung für Fabric Data Warehouse.

Muster 1: Direkte lagerübergreifende Verweise durch Datenbankverweise

In diesem Muster modellieren Sie Einwegabhängigkeiten direkt in den Datenbankprojekten mithilfe von Datenbankreferenzen.

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

Erstellen oder extrahieren Sie jedes Projekt mithilfe der Schritte in Warehouse-Projekte entwickeln in Visual Studio Code.

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 Optionen aus:
  • Datenbankprojekt im aktuellen Arbeitsbereich (öffnen Sie auch das referenzierte Datenbankprojekt in Visual Studio Code), oder
  • Datentier-Anwendung (.dacpac) (nutze diese Option, wenn du eine .dacpac für das Marketing Warehouse gebaut hast).
• 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>

Tipp

Indem Sie eine SQLCMD-Variable für den Namen des entfernten Lagerhauses verwenden, können Sie dasselbe Projekt in allen Umgebungen wie Entwicklung, Test und Produktion wiederverwenden.

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