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

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

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

[前提条件]

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

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

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

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

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

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

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

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Visual Studio Codeの database プロジェクト:

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

循環依存関係を回避する

循環依存関係は、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 つのプロジェクトの 配置前または配置後のスクリプト に移動します。
• これらのスクリプトが 冪等 であり、再実行しても安全であることを確認します。

パターンの例:

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

詳細と例については、Fabric Data Warehouseのデプロイ前と配置後のスクリプトに関する記事を参照してください。

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

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

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

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

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

Visual Studio Codeの「Develop warehouse projects」のステップを使って、各プロジェクトを作成または抽出できます。

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

• Visual Studio Codeで、Database Projects ビューを開きます。
• Zava.Sales.Warehouse プロジェクトを右クリックします。
• [ データベース参照の追加...] を選択します。
• 以下のいずれかの方法を使用してください。
  • 現在のワークスペース内のデータベースプロジェクト(参照データベースプロジェクトもVisual Studio Codeで開いてください)、または
  • データ層アプリケーション(.dacpac)(Marketingウェアハウス用の.dacpacを構築している場合はこのオプションを使います)。
• 参照オプションを設定します。
  • 参照型: 同じサーバー、異なるデータベース。
  • データベース名または変数:[$(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>

手順 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 ビューを使用できるようになりました。

学び続ける

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

関連コンテンツ

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