Développer et déployer des dépendances entre entrepôts

Dans cet article, vous allez apprendre à modéliser et déployer des dépendances entre entrepôts à l’aide de projets de base de données SQL dans Visual Studio Code. Vous commencez à partir de deux projets d’entrepôt existants et configurez des dépendances unidirectionnelles entre eux à l’aide de références de base de données et, si nécessaire, des scripts de prédéploiement et de post-déploiement.

Cet article s'appuie sur les concepts des projets Develop warehouse dans Visual Studio Code et suppose que vous êtes déjà à l'aise dans la création et la publication d'un projet d'entrepôt unique.

Prerequisites

Avant de commencer, assurez-vous de :

• Créez deux entrepôts Fabric dans le même espace de travail.
  • Pour créer un exemple d’entrepôt, consultez Créer un exemple d’entrepôt dans Microsoft Fabric.
• Créez ou extrayez un projet database pour chaque entrepôt dans Visual Studio Code.
  • Pour créer un projet de base de données pour votre entrepôt existant ou un nouvel entrepôt, consultez Développer des projets d’entrepôt dans Visual Studio Code.
• Installez Visual Studio Code sur votre station de travail.
• Installez le sdk .NET pour générer et publier des projets de base de données.
• Installez deux extensions Visual Studio Code : SQL Database Projects et SQL Server (mssql).
  • Vous pouvez installer les extensions requises directement à partir de Visual Studio Code Place de marché en recherchant « Projets SQL Database » ou « SQL Server (mssql) ».
• Les projets d’entrepôt valident, créent et peuvent être publiés dans Visual Studio Code.

Note

Cet article se concentre sur les projets warehouse dans Visual Studio Code et sur la façon dont vous les versionz dans Git en tant que projets de code standard. L’intégration Fabric Git pour les espaces de travail et les articles d’entrepôt est traitée séparément dans Development and Deployment et intégration Git. L’article part du principe que votre espace de travail Fabric est la cible de déploiement et que le schéma T-SQL se trouve dans un ou plusieurs projets Visual Studio Code que vous contrôlez dans Git.

Cet article ne couvre pas le développement inter-entrepôts pour le point de terminaison d’analyse SQL d'un Lakehouse. Les tables Lakehouse et les objets de points de terminaison SQL ne sont pas des objets suivis dans le contrôle de code source de la même manière que les projets de data warehouse. Utilisez des éléments Warehouse avec des projets de base de données pour une prise en charge complète de l’intégration et du déploiement git dans les expériences natives Fabric et les outils clients.

Scénario : Entrepôts inter-domaines Zava Analytics

Zava Analytics utilise deux domaines métier :

• Ventes : commandes client, chiffre d’affaires et métriques de pipeline.
• Marketing : campagnes, canaux et métriques d’engagement.

Chaque domaine a :

• Un entrepôt Fabric dans le même espace de travail :

  • ZavaSalesWarehouse
  • ZavaMarketingWarehouse

• Un projet database dans Visual Studio Code :

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

Pour créer des rapports ET ELT de bout en bout, chaque domaine a besoin d’affichages en lecture seule pour accéder aux données à partir de l’autre domaine :

• Sales a besoin d’un engagement marketing par le client.
• Marketing a besoin des performances des ventes par campagne.

Vous devez :

• Établissez des dépendances unidirectionnelles entre entrepôts via des références de base de données.
• Évitez les dépendances cycliques.

Vérifier que les dépendances entre les entrepôts sont unidirectionnelles

Pour chaque paire d’entrepôts, choisissez une direction pour la dépendance logique :

Exemple :

• Sales dépend des Marketing données d’engagement.
• Marketing ne dépend Sales pas des objets nécessaires au moment du déploiement.

Pratiquement:

Zava.Sales.Warehouse a une référence de base de données à Zava.Marketing.Warehouse.

• T-SQL dans l’entrepôt Sales peut utiliser des noms en trois parties comme :

  SELECT * FROM ZavaMarketingWarehouse.Marketing.CampaignEngagement
  

• Zava.Marketing.Warehouse ne fait pas référence à Sales des objets qui forcent un cycle de dépendance au moment du déploiement.

Conseil / Astuce

Pour chaque paire d’entrepôts, dessinez un diagramme de flèche simple (Sales → Marketing). Si vous trouvez des flèches pointant dans les deux directions pour le même type d’objet, refactorisez le design pour restaurer une dépendance unidirectionnelle.

Éviter les dépendances cycliques

Une dépendance cyclique se produit lorsque l’entrepôt A et l’entrepôt B dépendent les uns des autres d’une manière que le moteur ne peut pas résoudre dans un seul déploiement.

Exemple de problème (ne procédez pas comme suit) :

• ZavaSalesWarehouse.dbo.CustomerRollup Affichage:

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

  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;
  

Dans cet anti-pattern :

• CustomerRollup dans Sales dépend CustomerEngagement de Marketing.
• CampaignAttribution dans Marketing dépend CustomerRollup de Ventes.

Cet anti-modèle crée un cycle : vue Ventes → vue Marketing → vue Ventes à nouveau.

Conseils :

Ne modélisez pas les dépendances mutuelles entre les entrepôts en tant qu’objets de niveau schéma standard. Si vous avez vraiment besoin de ce type de logique, déplacez un côté de la dépendance vers :

• Un script post-déploiement ou
• Modèle sémantique ou rapport en aval qui joint les deux entrepôts au moment de la requête.

Utilisez des scripts pré- et post-déploiement pour gérer une logique entre entrepôts de données sensible au déploiement

Étant donné que les déploiements d’entrepôt sont des opérations de différences de schéma complètes (pas partielles par objet), traitez soigneusement les éléments inter-entrepôts :

Si Warehouse A et Warehouse B ont besoin d’objets qui dépendent les uns des autres :

• Conservez les tables principales et les vues principales dans chaque projet d’entrepôt.
• Déplacez les vues de pont ou les objets utilitaires qui créent des cycles dans des scripts de pré-déploiement ou de post-déploiement dans un même projet.
• Vérifiez que ces scripts sont idempotents et sûrs à réexécuter.

Exemples de modèles :

• Script de prédéploiement : supprimez temporairement une vue inter-entrepôt avant d’appliquer des modifications de schéma qui l’interrompraient.
• Script de post-déploiement : recréez ou mettez à jour la vue inter-entrepôt après le déploiement des deux entrepôts.

Pour plus d’informations et d’exemples, consultez les scripts de prédéploiement et de post-déploiement pour Fabric Data Warehouse.

Modèle 1 : Références inter-entrepôts directes via des références de base de données

Dans ce schéma, vous modélissez directement les dépendances unidirectionnelles dans les projets de base de données en utilisant les références de base de données.

Étape 1 : Démarrer à partir de deux projets d’entrepôt existants

Vous devez déjà avoir :

• Zava.Sales.Warehouse → déployée sur ZavaSalesWarehouse
• Zava.Marketing.Warehouse → déployée sur ZavaMarketingWarehouse

Créez ou extrayez chaque projet en utilisant les étapes de Développer des projets d’entrepôt dans Visual Studio Code.

Étape 2 : Ajouter une référence de base de données de Sales to Marketing

• Dans Visual Studio Code, ouvrez la vue Database Projects.
• Cliquez avec le bouton droit sur le Zava.Sales.Warehouse projet.
• Sélectionnez Ajouter une référence de base de données....
• Choisissez l’une des options suivantes :
  • Projet de base de données dans l’espace de travail actuel (ouvrir également le projet de base de données référencé dans Visual Studio Code), ou
  • Application de niveau de données (.dacpac) (utilisez cette option si vous avez créé un .dacpac pour l’entrepôt Marketing ).
• Définissez les options de référence :
  • Type de référence : Même serveur, base de données différente.
  • Nom ou variable de la base de données : Utilisez une variable SQLCMD, par exemple [$(MarketingWarehouseName)].
• Enregistrez et régénérez le projet Sales.

Dans le .sqlproj fichier, vous devez voir une entrée similaire à :

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

Conseil / Astuce

En utilisant une variable SQLCMD pour le nom de l’entrepôt distant, vous pouvez réutiliser le même projet dans tous vos environnements, tels que Dev, Test et Prod.

Étape 3 : Créer une vue inter-entrepôts dans Sales

Dans le Sales projet, ajoutez une vue qui lit à partir de l’entrepôt 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;

Points clés :

• Le nom [$(MarketingWarehouseName)].[dbo].[CustomerEngagement] en trois parties correspond au modèle T-SQL utilisé pour les requêtes inter-entrepôts dans l’éditeur FABRIC SQL.
• DacFx résout la base de données externe via la référence de la base de données.

Générez le projet pour vous assurer qu’il n’existe aucune erreur de référence non résolue SQL71501 .

Étape 4 : Publier l’entrepôt marketing, puis les ventes

Pour éviter les problèmes de déploiement :

• Générer et publierZava.Marketing.Warehouse premier:
  • Cliquez avec le bouton droit sur le projet → Générer.
  • Cliquez avec le bouton droit sur le projet → publier → choisissez ZavaMarketingWarehouse.
• Une fois Marketing le déploiement réussi, générez et publiezZava.Sales.Warehouse :
  • Cliquez avec le bouton droit sur le projet → Générer.
  • Cliquez avec le bouton droit sur le projet → publier → choisissez ZavaSalesWarehouse.

Le flux de déploiement obtenu est le suivant :

Zava.Marketing.Warehouse (aucune dépendance externe) → Zava.Sales.Warehouse (dépend de Marketing)

À présent, n'importe quelle requête T-SQL dans ZavaSalesWarehouse peut utiliser la vue dbo.CustomerEngagementFact, qui, en interne, lit à partir de l’entrepôt Marketing à l’aide de T-SQL inter-entrepôts.

Continuer à apprendre

• Combinez ce modèle avec la gestion du code source et les recommandations CI/CD dans Développement et déploiement ainsi que dans la documentation sur l’intégration Git de Fabric.
• Étendre le scénario Zava Analytics pour inclure des environnements Dev/Test/Prod, à l’aide de pipelines de déploiement ou de CI/CD externes pour orchestrer l’ordre de publication sur plusieurs entrepôts.

Contenu connexe

• Flux de travail de développement et de déploiement