クロスウェアハウス依存関係の開発とデプロイ

この記事では、Visual Studio Code で SQL データベース プロジェクトを使用して、ウェアハウス間の依存関係をモデル化してデプロイする方法について説明します。 2 つの既存のウェアハウス プロジェクトから開始し、データベース参照を使用してそれらの間の一方向の依存関係を構成します。必要に応じて、配置前および配置後のスクリプトを構成します。

この記事は、 Visual Studio Code でのウェアハウス プロジェクトの開発の 概念に基づいており、1 つのウェアハウス プロジェクトを構築して発行することに既に慣れているものとします。

[前提条件]

開始する前に、次のことを確認してください。

• 同じワークスペースに 2 つの Fabric Warehouse を作成します。
  • 新しいサンプル ウェアハウスを作成するには、「 Microsoft Fabric でサンプル ウェアハウスを作成する」を参照してください。
• Visual Studio Code で各ウェアハウスの データベース プロジェクト を作成または抽出します。
  • 既存の倉庫または新しい倉庫のデータベース プロジェクトを作成するには、「 Visual Studio Code でウェアハウス プロジェクトを開発する」を参照してください。
• ワークステーションに Visual Studio Code をインストールします。
• .NET SDK をインストールして、データベース プロジェクトをビルドして発行します。
• SQL Database Projects と SQL Server (mssql) という 2 つの Visual Studio Code 拡張機能をインストールします。
  • 必要な拡張機能は、"SQL Database Projects" または "SQL Server (mssql)" を検索することで、Visual Studio Code マーケットプレース内から直接インストールできます。
• ウェアハウス プロジェクトは検証、ビルド、および Visual Studio Code で発行できます。

注

この記事では、Visual Studio Code の ウェアハウス プロジェクト と、通常のコード プロジェクトとして Git でそれらをバージョン管理する方法について説明します。 ワークスペースとウェアハウス項目の Fabric Git 統合 については、Fabric Data Warehouse と Git 統合に関するドキュメント を使用したソース管理 で個別に説明されています。この記事では、Fabric ワークスペースがデプロイ ターゲットであり、T-SQL スキーマが Git でバージョン管理する 1 つ以上の Visual Studio Code プロジェクトに存在することを前提としています。

この記事では、Lakehouse の SQL 分析エンドポイントのクロスウェアハウス開発については説明しません。 Lakehouse テーブルと SQL エンドポイント オブジェクトは、ウェアハウス プロジェクトと同じ方法でソース管理内のオブジェクトを追跡しません。 Fabric ネイティブ エクスペリエンスとクライアント ツールで完全な Git 統合とデプロイのサポートを行うには、データベース プロジェクトで Warehouse 項目を使用します。

シナリオ: Zava Analytics クロスドメイン ウェアハウス

Zava Analytics では、次の 2 つのビジネス ドメインが使用されます。

• Sales – 顧客の注文、収益、パイプラインのメトリック。
• マーケティング – キャンペーン、チャネル、エンゲージメント メトリック。

各ドメインには次の内容があります。

• 同じワークスペース内の ファブリック ウェアハウス :

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Visual Studio Code の データベース プロジェクト :

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

エンド ツー エンドの ELT とレポートを作成するには、各ドメインが他のドメインのデータにアクセスするための 読み取り専用ビュー が必要です。

• Sales 顧客によるマーケティングエンゲージメントを必要とします。
• Marketing はキャンペーン別の販売実績を必要とします。

以下を実行する必要があります。

• データベース参照を使用して 、一方向のクロスウェアハウス依存関係 を確立します。
• 循環依存関係を回避します。
• 両方のウェアハウス内のオブジェクトが互いに依存する場合は、 デプロイ前と配置後のスクリプト を使用します。

倉庫間の依存関係が一方向であることを確認する

倉庫のペアごとに、 論理依存関係の方向を選択します。

例:

• Sales は、エンゲージメント データの Marketing に依存します。
• Marketingは、Salesに必要なオブジェクトのに依存しません。

実際に：

Zava.Sales.Warehouseには、へのZava.Marketing.Warehouseがあります。

• Sales ウェアハウスの T-SQL では、次のような 3 つの部分から構成される名前を使用できます。

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouseは、デプロイ時依存関係サイクルを強制するオブジェクトを参照Sales。

ヒント

倉庫のペアごとに、単純な矢印図 (Sales → Marketing) を描画します。 同じ種類のオブジェクトに対して双方向を指す矢印がある場合は、デプロイ前と配置後のスクリプトにロジックをリファクタリングまたは移動する必要がある可能性があります。

循環依存関係を回避する

循環依存関係は、1 つのデプロイでエンジンが解決できない方法で、倉庫 A と倉庫 B の両方が相互に依存している場合に発生します。

問題の例 (これを行わないでください):

• ZavaSalesWarehouse.dbo.CustomerRollup ビュー：

  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 ビュー：

  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;
  

このアンチパターンでは、次の操作を行います。

• CustomerRollupin Sales はCustomerEngagementのに依存します。
• CampaignAttribution マーケティングはCustomerRollupに依存しています。

このアンチパターンでは、売上ビュー→マーケティング ビュー→売上ビューというサイクルが作成されます。

ガイダンス:

ウェアハウス間の 相互依存関係 を通常のスキーマ レベルのオブジェクトとしてモデル化しないでください。 この種のロジックが本当に必要な場合は、依存関係の片方を移動してください。

• デプロイ後のスクリプト、または
• クエリ時に 2 つのウェアハウスを結合するダウンストリーム セマンティック モデル または レポート 。

デプロイ前とデプロイ後のスクリプトを使用して、展開の機密性の高いクロスウェアハウス ロジックを作成する

ウェアハウスデプロイは 完全なスキーマ差分 操作 (オブジェクトごとの部分的な展開ではありません) であるため、クロスウェアハウスアイテムは慎重に扱ってください。

倉庫 A と倉庫 B の両方に相互に依存するオブジェクトが必要な場合:

• コア テーブルとコア ビュー は、各ウェアハウス プロジェクトに保持します。
• サイクルを作成する ブリッジ ビューまたはユーティリティ オブジェクト を、1 つのプロジェクトの 配置前または配置後のスクリプト に移動します。
• これらのスクリプトが 冪等 であり、再実行しても安全であることを確認します。

パターンの例:

• デプロイ前スクリプト: スキーマ変更が影響を与える前に、クロス倉庫ビューを一時的に削除します。
• デプロイ後スクリプト: 両方のウェアハウスがデプロイされた後に、クロスウェアハウス ビューを再作成または更新します。

パターン 1: データベース参照を使用した直接のクロスウェアハウス参照

このパターンでは、データベース参照を使用して、データベース プロジェクトで一方向の依存関係を直接モデル化します。

手順 1: 2 つの既存の倉庫プロジェクトから開始する

既に次の情報が必要です。

• Zava.Sales.Warehouse をZavaSalesWarehouseにデプロイ
• Zava.Marketing.Warehouse をZavaMarketingWarehouseにデプロイ

各プロジェクトは、「 Visual Studio Code でのウェアハウス プロジェクトの開発」の手順を使用して作成または抽出されました。

手順 2: Sales から Marketing にデータベース参照を追加する

• Visual Studio Code で、[ データベース プロジェクト ] ビューを開きます。
• Zava.Sales.Warehouse プロジェクトを右クリックします。
• [ データベース参照の追加...] を選択します。
• 次のいずれかを選択します。
  • 現在のワークスペース内のデータベース プロジェクト (この方法で参照されるデータベース プロジェクトも Visual Studio Code で開く必要があります)、または
  • データ層アプリケーション (.dacpac) (.dacpac ウェアハウス用のビルドMarketingがある場合にビルド済みであることを前提としています)。
• 参照オプションを設定します。
  • 参照型: 同じサーバー、異なるデータベース。
  • データベース名または変数:[$(MarketingWarehouseName)]など、SQLCMD 変数を使用します。
• Sales プロジェクトを保存してリビルドします。

.sqlproj ファイルに、次のようなエントリが表示されます。

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

ヒント

リモート ウェアハウス名に SQLCMD 変数を使用すると、Dev/Test/Prod など、ウェアハウス名が異なる可能性があるすべての環境で同じプロジェクトを再利用できます。

手順 3: Sales でクロスウェアハウス ビューを作成する

Sales プロジェクトで、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;

重要なポイント:

• 3 部構成の名前 [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] は、Fabric SQL エディターのクロスウェアハウス クエリに使用される T-SQL パターンと一致します。
• DacFx は、データベース参照を使用して外部データベースを解決 します。

未解決の参照エラー SQL71501がないように、プロジェクトをビルドする。

手順 4: マーケティング ウェアハウスを発行してから Sales を発行する

デプロイの問題を回避するには:

• ビルドと発行Zava.Marketing.Warehouse まずは：
  • ビルド→プロジェクトを右クリックします。
  • [ 発行 ] →プロジェクトを右クリック→、[ ZavaMarketingWarehouse] を選択します。
• デプロイMarketing成功したら、ビルドして発行しますZava.Sales.Warehouse:
  • ビルド→プロジェクトを右クリックします。
  • [ 発行 ] →プロジェクトを右クリック→、[ ZavaSalesWarehouse] を選択します。

結果のデプロイ フローは次のとおりです。

Zava.Marketing.Warehouse (外部依存関係なし) → Zava.Sales.Warehouse ( Marketingによって異なります)

これで、ZavaSalesWarehouseの T-SQL クエリでは、クロスウェアハウス T-SQL を使用してdbo.CustomerEngagementFact ウェアハウスから内部的に読み取るMarketing ビューを使用できるようになりました。

パターン 2: デプロイ前とデプロイ後のスクリプトを使用して管理されるクロスウェアハウス依存関係

一部の Zava Analytics シナリオでは、 両方のドメイン が相互に依存する集約オブジェクトを必要とする場合があります。 例えば次が挙げられます。

• Sales には、マーケティング キャンペーン データを使用してマーケティング キャンペーンごとの売上収益を提供するビューが必要です。
• マーケティングでは、売上収益データを使用してマーケティング キャンペーンの効率を提供するビューが必要です。

これらのオブジェクトの両方を、完全なモデルデプロイに参加する通常のビューにしたくないのは、循環依存関係や脆弱なデプロイ順序のリスクがあるためです。

代わりに、次の手順を実行します。

• 各倉庫の コア モデル を独立させておく。
• 1 つのプロジェクトで 配置後スクリプトを 使用して、両方のスキーマを配置した後に、より多くのクロスウェアハウス ビューを作成します。

手順 1: コンパイル時の検証用にデータベース参照を追加する

パターン 1 のような参照を設定しますが、両方のプロジェクトに対して次の 手順 を実行します。

• Zava.Sales.Warehouseで、[$(MarketingWarehouseName)]経由で Marketing への参照を追加します。
• Zava.Marketing.Warehouseで、スクリプトで使用されるクロスウェアハウス ビューのコンパイル時検証を行う場合は、必要に応じて、[$(SalesWarehouseName)]経由で Sales への参照を追加します。

.sqlproj ファイルでは、次の設定を行うことができます。

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

手順 2: コア オブジェクトを通常のプロジェクト オブジェクトとして作成する

例:

• Sales プロジェクト：

  • dbo.CustomerRevenue テーブル
  • dbo.SalesByCampaign ビュー (ローカル テーブルのみを使用)

• Marketing プロジェクト：

  • dbo.Campaigns テーブル
  • dbo.CampaignStats ビュー (ローカル テーブルのみを使用)

これらのオブジェクトは、クロスウェアハウス クエリを使用しません。 次のステップでは、倉庫間参照システムを導入します。

手順 3: クロスウェアハウス ブリッジ ビューのデプロイ後スクリプトを追加する

ブリッジ オブジェクトをホストする 1 つの ウェアハウスを選択します。通常は、結合された出力を最も多く消費するドメインです。 Salesがそのドメインであるとします。

• Sales プロジェクトで、プロジェクトを右クリックし、追加 → 配置後スクリプトします。
• スクリプトに PostDeployment_CrossWarehouse.sqlという名前を付けます。
• スクリプト内でIF EXISTS / DROP / CREATEパターンを使用し、クロスデータウェアハウスビューを作成または変更して、その冪等性を保持します。

Salesウェアハウス オブジェクトを参照する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

適用されます。

• コア Sales および Marketing ウェアハウス プロジェクトは、独立した、単独でデプロイ可能なままです。
• ブリッジ ビューは、デプロイ後スクリプトを使用してスキーマのデプロイ後に作成されます。
• デプロイが複数回実行された場合でも、スクリプトはビューを安全に削除してから再作成するため、処理はべき等性を持ちます。

手順 4: (省略可能) 展開前スクリプトを使用して脆弱な依存関係を保護する

より高度なシナリオでは、次の場合があります。

• デプロイ前スクリプトを使用して、スキーマの変更をブロックする可能性があるクロスウェアハウス ビューを削除または無効にします (たとえば、列の名前を変更する場合)。
• DacFx にスキーマの差分を適用させます。
• デプロイ後スクリプトを使用して、クロスウェアハウス ビューを再作成または更新します。

Important

デプロイ前および配置後のスクリプトは、展開計画の一部として実行され、次の必要があります。

• べき等とは、複数回実行しても安全であることを意味します。
• DacFx によって生成された 最終的なスキーマ と互換性があります。
• 破壊的な変更がBlockOnPossibleDataLossポリシーと競合することはありません。

手順 5: スクリプトで管理される依存関係の発行順序

Zava Analytics の一般的なパターン:

• 基盤プロジェクトを公開する:
  • Zava.Marketing.Warehouse (コア スキーマ)
  • Zava.Sales.Warehouse (コア スキーマ + クロスウェアハウス デプロイ 後スクリプト)
• Sales デプロイ後スクリプトで、独自のスキーマと参照される スキーマがデプロイされたMarketingにブリッジ ビューを作成できるようにします。

複数の倉庫を導入する場合は、このパターンをレイヤーで繰り返します。 通常のプロジェクト オブジェクトを使用して循環依存関係を作成しないでください。

学び続ける

• これらのパターンを ソース管理と CI/CD ガイダンス とFabric Data Warehouse および Fabric Git 統合ドキュメント と組み合わせます。
• デプロイ パイプラインまたは外部 CI/CD を使用して、複数のウェアハウス間で発行順序を調整して、開発 /テスト/Prod 環境を含めるように Zava Analytics シナリオを拡張します。

関連コンテンツ

• 開発とデプロイのワークフロー