Udostępnij przez

Tworzenie i wdrażanie zależności między magazynami

Z tego artykułu dowiesz się, jak modelować i wdrażać zależności między magazynami przy użyciu projektów bazy danych SQL w programie Visual Studio Code. Rozpoczynasz od dwóch istniejących projektów magazynu i konfigurujesz między nimi zależności jednokierunkowe przy użyciu odwołań do bazy danych i, w razie potrzeby, skryptów przed wdrożeniem i po wdrożeniu.

Ten artykuł opiera się na pojęciach tworzenia projektów magazynu w programie Visual Studio Code i zakłada, że jesteś już zaznajomiony z kompilowaniem i publikowaniem pojedynczego projektu magazynu.

Wymagania wstępne

Przed rozpoczęciem upewnij się, że:

Uwaga / Notatka

Ten artykuł koncentruje się na projektach repozytoriów w programie Visual Studio Code i sposobie ich wersjonowania w usłudze Git jako typowych projektów kodu. Integracja Fabric Git dla obszarów roboczych i elementów magazynowych jest omówiona oddzielnie w dokumentacji Kontrola wersji z Fabric Data Warehouse i integracji z Git. W tym artykule założono, że obszar roboczy Fabric jest celem wdrożenia, a schemat T-SQL znajduje się w jednym lub większej liczbie projektów Visual Studio Code, które są kontrolowane wersyjnie w Git.

Ten artykuł nie obejmuje rozwoju między-magazynowego dla punktu końcowego analityki SQL w Lakehouse. Tabele usługi Lakehouse i obiekty punktu końcowego SQL nie są śledzone w kontroli źródła tak samo jak projekty magazynu. Używaj elementów magazynu z projektami bazy danych, aby uzyskać pełną obsługę integracji i wdrażania usługi Git w środowiskach natywnych i narzędziach klienckich usługi Fabric.

Scenariusz: Wielodomenowe magazyny Zava Analytics

Usługa Zava Analytics używa dwóch domen biznesowych:

  • Sales — zamówienia klientów, przychody i metryki lejka sprzedażowego.
  • Marketing — kampanie, kanały i metryki zaangażowania.

Każda domena ma:

  • Magazyn Fabric w tym samym obszarze roboczym:

    • ZavaSalesWarehouse
    • ZavaMarketingWarehouse

  • Projekt bazy danych w programie Visual Studio Code:

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

Aby utworzyć kompleksowe ELT i raportowanie, każda domena wymaga widoków tylko do odczytu w celu uzyskania dostępu do danych z innej domeny:

  • Sales wymaga zaangażowania marketingowego przez klienta.
  • Marketing potrzebuje wyników sprzedaży dla poszczególnych kampanii.

Należy wykonać:

  • Ustanów jednokierunkowe zależności między magazynami za pomocą odwołań do bazy danych.
  • Unikaj cyklicznych zależności.
  • Użyj skryptów wstępnych i po wdrożeniu w przypadkach, w których obiekty w obu magazynach zależą od siebie.

Upewnij się, że zależności między magazynami są jednokierunkowe

Dla każdej pary magazynów wybierz kierunek zależności logicznej:

Przykład:

  • Sales zależy od Marketing danych zaangażowania.
  • Marketing nie zależy od żadnych obiektów Sales, które są potrzebne w czasie wdrażania.

W praktyce:

zawiera odwołanie do bazy danych.

  • Język T-SQL w Sales magazynie może używać nazw trzyczęściowych, takich jak: 
    SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  • Zava.Marketing.Warehouse nie odwołuje się do Sales obiektów, które wymusiłyby cykl zależności w czasie wdrażania.

Wskazówka

Dla każdej pary magazynów rysuj prosty diagram strzałki (Sales → Marketing). Jeśli znajdziesz strzałki wskazujące w obu kierunkach dla tego samego typu obiektu, prawdopodobnie trzeba refaktoryzować lub przenieść logikę do skryptów wstępnych i po wdrożeniu.

Unikaj cyklicznych zależności

Zależność cykliczna występuje, gdy Magazyn A i Magazyn B zależą od siebie w sposób, którego silnik nie może rozwiązać w jednym wdrożeniu.

Przykład problemu (nie rób tego):

  • ZavaSalesWarehouse.dbo.CustomerRollup widok: 
    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 widok: 
    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;

W tym antywzór:

  • CustomerRollup w obszarze Sprzedaży zależy CustomerEngagement od Marketingu.
  • CampaignAttribution w Marketingu zależy od CustomerRollup w Sprzedaży.

Ten antywzorzec tworzy cykl: Widok sprzedaży → Widok marketingowy → Widok sprzedaży ponownie.

Wskazówki:

Nie modeluj wzajemnych zależności między magazynami jako zwykłych obiektów na poziomie schematu. Jeśli naprawdę potrzebujesz tej logiki, przenieś jedną stronę zależności do:

  • Skrypt po wdrożeniu lub
  • Podrzędny model semantyczny lub raport, który łączy dwa magazyny w czasie wykonywania zapytań.

Używanie skryptów przed wdrożeniem i po wdrożeniu na potrzeby wrażliwej logiki między magazynami

Ponieważ wdrożenia magazynu to pełne operacje porównywania schematów (nie częściowe wdrożenia poszczególnych obiektów), postępuj ostrożnie z elementami powiązanymi z różnymi magazynami.

Jeśli magazyn A i Magazyn B potrzebują obiektów, które zależą od siebie nawzajem:

  • Zachowaj podstawowe tabele i podstawowe widoki w każdym projekcie magazynu.
  • Przenieś widoki mostków lub obiekty narzędziowe, które tworzą cykle, do skryptów przedwdrożeniowych lub powdrożeniowych w jednym projekcie.
  • Upewnij się, że te skrypty są idempotentne i bezpieczne do ponownego uruchomienia.

Przykładowe wzorce:

  • Skrypt przed wdrożeniem: tymczasowo upuść widok między magazynami przed zastosowaniem zmian schematu, które spowodują jego przerwanie.
  • Skrypt po wdrożeniu: utwórz ponownie lub zaktualizuj widok między magazynami po wdrożeniu obu magazynów.

Wzorzec 1: Bezpośrednie odniesienia między magazynami poprzez odwołania bazodanowe

W tym wzorcu modelujesz jednokierunkowe zależności bezpośrednio w projektach bazy danych przy użyciu odwołań do bazy danych.

Krok 1. Rozpoczęcie od dwóch istniejących projektów magazynu

Musisz mieć już:

  • Zava.Sales.Warehouse → wdrożone do ZavaSalesWarehouse
  • Zava.Marketing.Warehouse → wdrożone do ZavaMarketingWarehouse

Każdy projekt został utworzony lub wyodrębniony, wykonując kroki z "Tworzenia projektów magazynowych w Visual Studio Code."

Krok 2: Dodaj odwołanie do bazy danych z Sales do Marketing

  • W programie Visual Studio Code otwórz widok Projekty bazy danych .
  • Kliknij prawym przyciskiem myszy projekt Zava.Sales.Warehouse.
  • Wybierz pozycję Dodaj odwołanie do bazy danych....
  • Wybierz jedną z:
    • Projekt bazy danych w bieżącym obszarze roboczym (projekt bazy danych, do których odwołuje się ten sposób, musi być również otwarty w programie Visual Studio Code) lub
    • Aplikacja warstwy danych (.dacpac) (Zakłada się, że zbudowałeś .dacpac, jeśli masz gotową Marketing aplikację dla magazynu).
  • Ustaw opcje referencyjne:
    • Typ odwołania: Ten sam serwer, inna baza danych.
    • Nazwa bazy danych lub zmienna: Użyj zmiennej SQLCMD, na przykład [$(MarketingWarehouseName)].
  • Zapisz i ponownie skompiluj projekt Sales.

.sqlproj W pliku powinien zostać wyświetlony wpis podobny do:

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

Wskazówka

Użycie zmiennej SQLCMD dla nazwy magazynu zdalnego umożliwia ponowne użycie tego samego projektu we wszystkich środowiskach, takich jak Tworzenie i testowanie/prod, gdzie nazwy magazynów mogą się różnić.

Krok 3. Tworzenie widoku między magazynami w usłudze Sales

W projekcie Sales dodaj widok, który odczytuje z magazynu 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;

Najważniejsze kwestie:

  • Nazwa [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] trójczęściowa jest zgodna ze wzorcem języka T-SQL używanym do zapytań między magazynami w edytorze SQL sieci szkieletowej.
  • Narzędzie DacFx rozpoznaje zewnętrzną bazę danych za pomocą odwołania do bazy danych.

Skompiluj projekt, aby upewnić się, że nie ma SQL71501 nierozwiązanych błędów referencyjnych .

Krok 4. Publikowanie magazynu marketingowego, a następnie sales

Aby uniknąć problemów z wdrażaniem:

  • Buduj i publikujZava.Marketing.Warehouse najpierw:
    • Kliknij prawym przyciskiem myszy projekt → Kompiluj.
    • Kliknij prawym przyciskiem myszy projekt → Opublikuj → wybierz pozycję ZavaMarketingWarehouse.
  • Po Marketing pomyślnym wdrożeniu skompiluj i opublikujZava.Sales.Warehouse:
    • Kliknij prawym przyciskiem myszki projekt → Kompilacja.
    • Kliknij prawym przyciskiem myszy projekt → Opublikuj → wybierz pozycję ZavaSalesWarehouse.

Wynikowy przepływ wdrażania to:

Zava.Marketing.Warehouse (brak zależności zewnętrznych) → Zava.Sales.Warehouse (zależy od Marketing)

Teraz każde zapytanie T-SQL w ZavaSalesWarehouse może używać widoku dbo.CustomerEngagementFact, który wewnętrznie odczytuje z magazynu Marketing przy użyciu między-magazynowego T-SQL.

Wzorzec 2: zależności między magazynami zarządzane za pośrednictwem skryptów przed wdrożeniem i po wdrożeniu

W niektórych scenariuszach analizy Zava obie domeny mogą wymagać zagregowanych obiektów, które zależą od siebie nawzajem. Przykład:

  • Sprzedaż chce mieć widok, który używa danych z kampanii marketingowych do dostarczenia informacji o przychodach z kampanii marketingowych.
  • Marketing chce mieć widok, który używa danych przychodów ze sprzedaży w celu zapewnienia skuteczności kampanii marketingowej.

Nie powinieneś, aby oba te obiekty były standardowymi widokami, które uczestniczą w pełnym wdrożeniu modelu, ponieważ wiąże się to z ryzykiem cyklicznej zależności lub kruchego porządku wdrażania.

Zamiast tego, należy:

  • Zachowaj niezależny model podstawowy każdego magazynu.
  • Użyj skryptów po wdrożeniu w jednym projekcie, aby utworzyć więcej widoków między magazynami po utworzeniu obu schematów.

Krok 1. Dodawanie odwołań do bazy danych na potrzeby walidacji czasu kompilacji

Skonfiguruj odwołania podobne do wzorca 1, ale dla obu projektów:

  • W Zava.Sales.Warehouse, dodaj odwołanie do Marketing za pośrednictwem [$(MarketingWarehouseName)].
  • W Zava.Marketing.Warehouse opcjonalnie dodaj odwołanie do Sales za pomocą [$(SalesWarehouseName)] jeśli chcesz przeprowadzić walidację podczas kompilacji widoków między magazynami używanych w skryptach.

W plikach .sqlproj można ustawić następujące ustawienia:

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

Krok 2. Tworzenie obiektów podstawowych jako zwykłych obiektów projektu

Przykład:

  • Sales projekt:

    • Tabela usługi dbo.CustomerRevenue
    • dbo.SalesByCampaign widok (tylko przy użyciu tabel lokalnych)

  • Marketing projekt:

    • Tabela usługi dbo.Campaigns
    • dbo.CampaignStats widok (tylko przy użyciu tabel lokalnych)

Te obiekty nie używają zapytań między magazynami danych. W następnym kroku wprowadzimy odwołania między magazynami.

Krok 3. Dodawanie skryptu po wdrożeniu dla widoków mostka między magazynami

Wybierz jeden magazyn do hostowania obiektów mostka; zazwyczaj domena, która zużywa połączone dane wyjściowe w największym stopniu. Załóżmy, że Sales jest tą domeną.

  • W projekcie Sales: kliknij prawym przyciskiem myszy na projekcie, a następnie wybierz Dodaj → Skrypt wdrożeniowy.
  • Nadaj skryptowi PostDeployment_CrossWarehouse.sqlnazwę .
  • W skrypcie utwórz lub zmień widoki między magazynami, używając wzorców IF EXISTS / DROP / CREATE w celu zachowania ich idempotentności.

Przykład skryptu w Sales, który będzie odnosił się do obiektów magazynu Marketing.

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

Tutaj:

  • Projekty podstawowe Sales i magazynowe Marketing pozostają niezależne i wdrażalne samodzielnie.
  • Widok mostka jest tworzony po wdrożeniu schematu za pomocą skryptu po wdrożeniu.
  • Jeśli wdrożenie jest wykonywane wiele razy, jest idempotentne, ponieważ skrypt bezpiecznie usuwa i ponownie tworzy widok.

Krok 4. (Opcjonalnie) Używanie skryptów przed wdrożeniem w celu ochrony niestabilnych zależności

W bardziej zaawansowanych scenariuszach możesz:

  • Użyj skryptu przed wdrożeniem , aby usunąć lub wyłączyć widoki między magazynami, które mogą blokować zmiany schematu (na przykład jeśli zmieniasz nazwy kolumn).
  • Pozwól DacFx zastosować różnice schematu.
  • Użyj skryptu po wdrożeniu, aby odtworzyć lub zaktualizować widoki międzyhurtowniane.

Ważne

Skrypty przed wdrożeniem i po wdrożeniu są uruchamiane w ramach planu wdrożenia i muszą być następujące:

  • idempotentne, co oznacza, że są bezpieczne do wielokrotnego uruchamiania.
  • Zgodny ze schematem końcowym wyprodukowanym przez DacFx.
  • Wolne od destrukcyjnych zmian, które powodują konflikt z zasadami BlockOnPossibleDataLoss .

Krok 5. Kolejność publikowania dla zależności zarządzanych przez skrypty

Typowy wzorzec analizy Zava:

  • Publikowanie projektów podstawowych:
    • Zava.Marketing.Warehouse (podstawowy schemat)
    • Zava.Sales.Warehouse (podstawowy schemat i skrypt po wdrożeniu między magazynami)
  • Pozwól skryptowi wdrożeniowemu Sales utworzyć widoki mostu po wdrożeniu jego własnego schematu i schematu Marketing, do którego się odnosi.

Jeśli wprowadzisz więcej niż dwa magazyny, powtórz ten wzorzec w warstwach. Nigdy nie twórz zależności cyklicznych za pośrednictwem zwykłych obiektów projektu.

Kontynuuj naukę

  • Połącz te wzorce ze wskazówkami dotyczącymi kontroli źródła i CI/CD (ciągłej integracji/ciągłego wdrażania) w dokumentacji 'Source control with Fabric Data Warehouse' i dokumentacji integracji Git z Fabric.
  • Rozszerz scenariusz analizy Zava, aby uwzględnić środowiska Dev/Test/Prod, korzystając z potoków wdrażania lub zewnętrznego CI/CD do koordynacji kolejności publikacji w wielu magazynach.

Treści powiązane

  • Last updated on