Phase 4 : Migration de la sécurité et de la gouvernance

Cet article est la phase 4 sur 4 de la série de meilleures pratiques de migration d'Azure Synapse Spark vers Microsoft Fabric.

Utilisez cet article dans la dernière étape de votre migration pour valider les charges de travail, aligner les contrôles de sécurité et de gouvernance et planifier votre basculement de production. Cet article fournit des conseils sur le mappage de sécurité et une approche basée sur une liste de contrôle pour la validation, l’optimisation et le prêt au basculement.

Dans cet article, vous allez apprendre à :

  • Mapper les modèles RBAC et réseau Synapse à l'espace de travail Fabric, OneLake, et les contrôles réseau managés.
  • Reconnectez les flux de travail de gouvernance, notamment l’intégration de Microsoft Purview et l’étiquetage.
  • Utilisez la liste de contrôle de migration phase par phase pour valider, optimiser et exécuter le basculement.
  • Planifiez la mise hors service des anciennes ressources Synapse Spark après un basculement réussi.

Contrôle d’accès

  • Les rôles Synapse RBAC (Administrateur Synapse, Administrateur Synapse SQL, Administrateur Synapse Spark et autres) sont mappés aux rôles d'espace de travail de Fabric (Administrateur, Membre, Contributeur, Lecteur). le modèle de Fabric est plus simple avec quatre rôles.

  • Les services liés Synapse sont remplacés par Fabric Connections. Créez des connexions via les paramètres> de l’espace de travailpour gérer les connexions et les passerelles. Pour le code de notebook, remplacez les références de service lié par l'authentification basée sur Key Vault ou la configuration directe des points de terminaison.

  • OneLake RBAC fournit un contrôle d’accès aux données affiné au niveau du dossier et de la table au sein de Lakehouse.

Sécurité du réseau

  • Les réseaux virtuels managés et les points de terminaison privés Synapse se traduisent par un réseau virtuel managé Fabric et des points de terminaison privés managés. Notez que Fabric Spark nécessite des pools personnalisés (et non des pools de démarrage) pour la prise en charge des points de terminaison privés managés.

  • Les runtimes d’intégration auto-hébergés (SHIR) dans Synapse sont remplacés par des passerelles de données locales (OPDG) dans Fabric. Les IR de VNet sont remplacées par des passerelles de données VNet.

Governance

Si vous utilisez Azure Purview avec Synapse, Fabric fournit une intégration Microsoft Purview native pour le catalogue de données, la traçabilité, les étiquettes de confidentialité et les stratégies d’accès. Reconnectez votre compte Purview pour analyser les espaces de travail Fabric.

Liste des éléments à vérifier pour la migration

Utilisez cette liste de contrôle pour suivre la progression de votre migration Spark. Chaque phase s’appuie sur la précédente. Terminez tous les éléments d’une phase avant de passer à la suivante.

Phase 1 : Évaluer et planifier

Pour obtenir des conseils de planification, des modèles de migration et des comparaisons de fonctionnalités, consultez la phase 1 : Stratégie de migration et planification.

  • 1.1 Inventaire complet des ressources Spark : pools Spark, notebooks, définitions de travaux Spark, bases de données lake, bases de données Hive Metastore (HMS) et services liés utilisés dans les notebooks.
  • 1.2 Passez en revue les différences de fonctionnalités synapse et Fabric. Indicateurs bloqueurs : charges de travail GPU, API de catalogue non prises en charge, dépendances de services liés.
  • 1.3 Exécuter l’audit de pré-refactorisation : recherchez tous les notebooks pour les modèles spécifiques à Synapse (spark.synapse.linkedService, getSecretWithLS, TokenLibrary, synapsesql). Nombre de blocs-notes affectés.
  • 1.4 Vérifier la compatibilité des bibliothèques : exécutez pip freeze sur des pools Synapse, comparez aux bibliothèques intégrées Fabric Runtime 1.3. Répertorier les bibliothèques qui doivent être préinstallées.
  • 1.5 Créer des espaces de travail Fabric, approvisionner une capacité et créer des éléments Lakehouse cibles.
  • 1.6 Exporter des configurations de pool Spark, des bibliothèques personnalisées et des propriétés Spark à partir de Synapse Studio.

Phase 2 : Configurer les connexions et les informations d’identification

Pour obtenir des conseils sur le remplacement et l’authentification du service lié, consultez la phase 2 : Migration de charge de travail Spark et phase 4 : migration de sécurité et de gouvernance.

  • 2.1 Inventoriez tous les services liés à Synapse utilisés par les notebooks, les définitions de travaux Spark et l’accès aux données Lakehouse.
  • 2.2 Créer des connexions Fabric pour des sources de données externes (ADLS Gen2, Cosmos DB, Azure SQL et autres) via Workspace Settings>Manage connexions et passerelles.
  • 2.3 Configurez Azure Key Vault avec des secrets pour les sources de données qui nécessitent une authentification basée sur des clés (clés Cosmos DB, clés de compte de stockage, jetons Kusto). Configurez des stratégies d’accès pour votre identité d’espace de travail Fabric.
  • 2.4 Configurer les informations d’identification du principal de service pour l’accès OAuth ADLS Gen2 : inscrivez l’application dans Entra ID, accordez le rôle Contributeur aux données blob du stockage, notez l’ID client/secret/locataire.
  • 2.5 Vérifiez la connectivité : testez la récupération de secrets Key Vault et l’accès au compte de stockage à partir d’un bloc-notes Fabric avant de continuer.

Phase 3 : Migrer les données et le metastore Hive

Pour obtenir des conseils sur la migration des métadonnées de lac et de l'accès aux données, consultez Phase 3 : Metastore Hive et migration des données et Migration des données et des pipelines.

  • 3.1 Créer des raccourcis OneLake vers des chemins ADLS Gen2 existants (approche de copie zéro, par défaut). Utilisez les connexions Fabric configurées dans la phase 2 pour l’accès basé sur la passerelle de données.
  • 3.2 Pour les fichiers non delta (CSV, JSON, Parquet), créez des raccourcis dans la section Fichiers. Si la copie de données est requise, utilisez AzCopy ou l’activité de copie Data Factory.
  • 3.3 Migrer des objets du metastore Hive. Choisissez une approche : Option A : Exécuter des carnets d’exportation/importation HMS pour toutes les métadonnées. Option B : Utilisez Assistant Migration pour les tables Delta lake DB + importation/exportation HMS pour les non-Delta uniquement.
  • 3.4 Valider l’enregistrement automatique de la table Delta dans Lakehouse Explorer.
  • 3.5 Vérifiez que toutes les tables et raccourcis importés sont visibles dans Lakehouse Explorer et accessibles à partir de notebooks.

Phase 4 : Migrer des charges de travail Spark

Pour la migration d’éléments, la refactorisation du code et les instructions de configuration de l’environnement, consultez la phase 2 : Migration de charge de travail Spark.

  • 4.1 Exécuter spark Assistant Migration pour les notebooks, les définitions de travaux Spark, les pools Spark et les bases de données de lac. Passez en revue le rapport de migration pour les erreurs et les avertissements.
  • 4.2 Créer des environnements Fabric avec le runtime Spark cible, la configuration du pool et les bibliothèques personnalisées. Préinstallation des bibliothèques manquantes identifiées dans la phase 1.
  • 4.3 Remaniez le notebook et le code SJD : Remplacez mssparkutils par notebookutils, mettez à jour les chemins d’accès aux fichiers vers les chemins OneLake abfss://, remplacez les références de service lié par des Key Vault ou des connexions Fabric, puis remplacez les méthodes spark.catalog non prises en charge par des méthodes Spark SQL équivalentes.
  • 4.4 Refactorisation des connecteurs : Kusto/ADX — remplacez le service lié par accessToken via getToken(). Cosmos DB — remplacer getSecretWithLS par getSecret(akvName, secret).
  • 4.5 Remplacer les fournisseurs de jetons Synapse (LinkedServiceBasedTokenProvider, TokenLibrary) par OAuth ClientCredsTokenProvider standard via spark.conf.set().
  • 4.6 Testez les notebooks refactorisés et les SJDs de bout en bout par rapport aux données (Phase 3) et aux connexions (Phase 2).

Phase 5 : Sécurité, gouvernance et réseau

Pour obtenir des conseils sur la sécurité, la gouvernance et le mappage réseau, consultez la phase 4 : Migration de la sécurité et de la gouvernance.

  • 5.1 Mappez les rôles RBAC Synapse aux rôles d’espace de travail de Fabric (Administrateur, Membre, Contributeur, Lecteur).
  • 5.2 Configurez OneLake RBAC pour le contrôle d’accès aux données affiné au niveau du dossier et de la table.
  • 5.3 Configurer le réseau virtuel managé et les points de terminaison privés managés pour les charges de travail Spark qui accèdent aux sources de données privées (nécessite des pools personnalisés).
  • 5.4 Remplacez SHIR par Passerelle de Données Locale (OPDG), et remplacez VNet IR par Passerelle de Données de Réseau Virtuel (VNet Data Gateway).
  • 5.5 Reconnectez Microsoft Purview pour la gouvernance, la traçabilité et les étiquettes de confidentialité.
  • 5.6 Passez en revue et appliquez des étiquettes de confidentialité aux éléments Lakehouse migrés si nécessaire.

Phase 6 : Optimiser et valider

Pour obtenir des conseils sur la validation post-migration et la préparation à la production, consultez la phase 4 : Migration de sécurité et de gouvernance.

  • 6.1 Activer le moteur d’exécution natif (NEE) pour améliorer les performances Spark sur les charges de travail Parquet et Delta.
  • 6.2 Exécuter OPTIMIZE VORDER sur les tables consommées par Power BI Direct Lake ou le point de terminaison d’analytique SQL.
  • 6.3 Exécuter des charges de travail parallèles et comparer les résultats et les performances des travaux Spark entre Synapse et Fabric.
  • 6.4 Rediriger les consommateurs en aval, y compris les rapports Power BI, les API et les applications, vers des points de terminaison Fabric.
  • 6.5 Surveiller les charges de travail Fabric à l’aide du hub de surveillance et de l’émetteur de diagnostic pendant au moins une à deux semaines.

Phase 7 : Basculement

Pour obtenir une validation finale, un réacheminement en aval et des conseils de basculement, consultez la phase 4 : Migration de la sécurité et de la gouvernance.

  • 7.1 Confirmez que tous les blocs-notes migrés, SJD et travaux Spark s’exécutent correctement dans Fabric.
  • 7.2 Vérifiez l’intégrité des données par le biais du nombre de lignes, de la validation du schéma et de la comparaison des résultats des requêtes.
  • 7.3 Communiquez le basculement aux parties prenantes et mettez à jour la documentation.
  • 7.4 Mettre hors service les pools Synapse Spark, les notebooks et les ressources associées.

Note

Après la migration, envisagez de configurer l'intégration Fabric Git pour vos notebooks migrés et définitions d'emplois Spark. Fabric prend en charge l'intégration de Git d'Azure DevOps pour le contrôle de version, la création de branches et les pipelines de déploiement. Contrairement à Synapse (qui utilise des modèles ARM pour CI/CD), Fabric utilise un modèle basé sur un espace de travail où vous connectez un espace de travail à une branche Git et synchronisez les éléments directement. Les notebooks, environnements et SJD prennent tous en charge l’intégration Git. Configurez des pipelines de déploiement (Dev → Test → Prod) pour gérer la promotion entre les environnements.

Contenu connexe

  • Last updated on