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 Warehouse-Projekten in Visual Studio Code auf und geht davon aus, dass Sie bereits mit dem Erstellen und Veröffentlichen eines einzelnen Lagerprojekts vertraut sind.

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 Erstellen eines Beispiellagers in Microsoft Fabric.
• Erstellen oder Extrahieren eines Datenbankprojekts 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 Entwickeln von Lagerprojekten in Visual Studio Code.
• Installieren Sie Visual Studio Code auf Ihrer Arbeitsstation.
• Installieren Sie das .NET SDK zum Erstellen und Veröffentlichen von Datenbankprojekten.
• Installieren Sie zwei Visual Studio Code-Erweiterungen: SQL-Datenbankprojekte und SQL Server (mssql).
  • Sie können die erforderlichen Erweiterungen direkt aus dem 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 Lagerprojekten in Visual Studio Code und deren Versionsverwaltung in Git als normale Codeprojekte. Die Fabric Git-Integration für Arbeitsbereiche und Speicherobjekte wird separat in Quellcodeverwaltung mit Fabric Data Warehouse und Git-Integrationsdokumenten behandelt. In diesem Artikel wird davon ausgegangen, dass Ihr Fabric-Arbeitsbereich das Bereitstellungsziel ist und das T-SQL-Schema in ein oder mehreren Visual Studio Code-Projekten vorhanden ist, die Sie in Git versionsverwaltet.

In diesem Artikel wird die Lagerübergreifende Entwicklung für den SQL-Analyseendpunkt eines Lakehousenicht behandelt. Lakehouse-Tabellen und SQL-Endpunktobjekte werden in der Quellcodeverwaltung nicht auf die gleiche Weise wie Data Warehouse-Projekte nachverfolgt. 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.

Folgende Schritte sind erforderlich:

• Richten Sie Einweg-lagerübergreifende Abhängigkeiten über Datenbankverweise ein.
• Vermeiden Sie zyklische Abhängigkeiten.
• Verwenden Sie Skripts vor und nach der Bereitstellung für Fälle, in denen Objekte in beiden Lagerhäusern voneinander abhängen.

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 Sie Pfeile finden, die in beide Richtungen für denselben Objekttyp zeigen, müssen Sie wahrscheinlich einige Logik in Skripts vor und nach der Bereitstellung umgestalten oder verschieben.

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

  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 von Skripts vor und nach der Bereitstellung für die Bereitstellung sensibler lagerübergreifender 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.

Muster 1: Direkte lagerübergreifende Verweise durch Datenbankverweise

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 mithilfe der Schritte in "Warehouse-Projekte entwickeln" 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>

Tipp

Wenn Sie eine SQLCMD-Variable für den Namen des Remotelagers verwenden, können Sie dasselbe Projekt in allen Umgebungen wiederverwenden, z. B. Dev/Test/Prod, wo sich die Lagernamen möglicherweise unterscheiden.

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.

Muster 2: Lagerübergreifende Abhängigkeiten, die über Skripts vor und nach der Bereitstellung verwaltet werden

In einigen Zava Analytics-Szenarien benötigen beide Domänen möglicherweise aggregierte Objekte, die voneinander abhängen. Beispiel:

• "Vertrieb" möchte eine Ansicht anzeigen, die Marketingkampagnendaten verwendet, um Umsatzerlöse pro Marketingkampagne bereitzustellen.
• Marketing möchte eine Ansicht anzeigen, die Umsatzdaten verwendet, um die Effizienz der Marketingkampagne zu gewährleisten.

Sie möchten nicht, dass beide Objekte reguläre Ansichten sind, die an der vollständigen Modellbereitstellung teilnehmen, da dadurch eine zyklische Abhängigkeit oder eine fragile Bereitstellungsreihenfolge entstehen könnte.

Stattdessen machen Sie Folgendes:

• Halten Sie das Kernmodell jedes Lagers unabhängig.
• Verwenden Sie Skripts nach der Bereitstellung in einem Projekt, um mehr lagerübergreifende Ansichten zu erstellen, nachdem beide Schemas vorhanden sind.

Schritt 1: Hinzufügen von Datenbankverweise zur Kompilierungszeitüberprüfung

Richten Sie Verweise ähnlich wie Pattern 1 ein, aber für beide Projekte:

• Fügen Sie in Zava.Sales.Warehouse einen Verweis auf Marketing über [$(MarketingWarehouseName)] hinzu.
• Fügen Sie Zava.Marketing.Warehouse optional einen Verweis auf "Vertrieb" hinzu[$(SalesWarehouseName)], wenn Sie eine Überprüfung zur Kompilierungszeit der in Skripts verwendeten bereichsübergreifenden Ansichten wünschen.

In den .sqlproj Dateien können Sie Folgendes festlegen:

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

Schritt 2: Erstellen von Kernobjekten als normale Projektobjekte

Beispiel:

• Sales Projekt:

  • dbo.CustomerRevenue-Tabelle
  • dbo.SalesByCampaign Ansicht (nur lokale Tabellen verwenden)

• Marketing Projekt:

  • dbo.Campaigns-Tabelle
  • dbo.CampaignStats Ansicht (nur lokale Tabellen verwenden)

Diese Objekte verwenden keine lagerübergreifenden Abfragen. Im nächsten Schritt führen wir lagerübergreifende Verweise ein.

Schritt 3: Hinzufügen eines Skripts nach der Bereitstellung für Querlagerbrückenansichten

Wählen Sie ein Lager aus, um Brückenobjekte zu hosten; in der Regel die Domäne, die die kombinierte Ausgabe am stärksten verbraucht. Angenommen Sales ist jene Domäne.

• Klicken Sie im Sales Projekt mit der rechten Maustaste auf das Projekt und wählen Sie dann Hinzufügen → Bereitstellungsskript nach der Bereitstellung aus.
• Benennen Sie das Skript PostDeployment_CrossWarehouse.sql.
• Erstellen oder ändern Sie im Skript die lagerübergreifenden Ansichten mithilfe von IF EXISTS / DROP / CREATE Mustern, um sie idempotent zu halten.

Beispiel für ein Skript in Sales, das auf Marketing-Warehouse-Objekte verweist:

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

Hier:

• Die Kernprojekte Sales und die Lagerhausprojekte Marketing bleiben unabhängig und können von sich aus bereitgestellt werden.
• Die Brückenansicht wird nach der Schemabereitstellung mit einem nachgelagerten Skript erstellt.
• Wenn die Bereitstellung mehrfach erfolgt, ist sie idempotent, da das Skript die Ansicht fehlerfrei löscht und neu erstellt.

Schritt 4: (Optional) Verwenden von Skripts vor der Bereitstellung zum Schutz fragiler Abhängigkeiten

In komplexeren Szenarien können Sie folgende Aktionen ausführen:

• Verwenden Sie ein Skript vor der Bereitstellung , um lagerübergreifende Ansichten abzulegen oder zu deaktivieren, die Schemaänderungen blockieren können (z. B. wenn Sie Spalten umbenennen).
• Lassen Sie DacFx die Schema-Differenz anwenden.
• Verwenden Sie das Skript nach der Bereitstellung , um die lagerübergreifenden Ansichten neu zu erstellen oder zu aktualisieren.

Von Bedeutung

Skripte vor und nach der Bereitstellung werden als Teil des Bereitstellungsplans ausgeführt und müssen Folgendes erfüllen:

• Idempotent, was bedeutet, dass sie mehrmals sicher ausgeführt werden können.
• Kompatibel mit dem endgültigen Schema von DacFx.
• Frei von destruktiven Änderungen, die mit Ihrer BlockOnPossibleDataLoss Richtlinie in Konflikt geraten.

Schritt 5: Veröffentlichen der Reihenfolge für skriptverwaltete Abhängigkeiten

Ein gängiges Muster für Zava Analytics:

• Veröffentlichen von Basisprojekten:
  • Zava.Marketing.Warehouse (Kernschema)
  • Zava.Sales.Warehouse (Kernschema + Lagerübergreifendes Skript nach der Bereitstellung)
• Lassen Sie das Vertrieb-Bereitstellungsskript die Bridge-Ansichten erstellen, nachdem sowohl das eigene Schema als auch das referenzierte Marketing Schema bereitgestellt wurden.

Wenn Sie mehr als zwei Lagerhäuser einführen, wiederholen Sie dieses Muster in Schichten. Erstellen Sie niemals zyklische Abhängigkeiten über gewöhnliche Projektobjekte.

Weiter lernen

• Kombinieren Sie diese Muster mit Richtlinien zur Quellcodeverwaltung und CI/CD in Quellcodeverwaltung mit Fabric Data Warehouse und Fabric-Git-Integrationsdokumenten.
• 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