Méthodologie de réussite d’implémentation de Synapse : Évaluer la conception de pool SQL dédié
Notes
Cet article fait partie de la série Réussite de l’implémentation d’Azure Synapse par conception. Pour obtenir une vue d’ensemble de la série, consultez Réussite de l’implémentation d’Azure Synapse par conception.
Vous devriez évaluer la conception de votre pool SQL dédié pour identifier les problèmes et vérifier qu’il répond aux directives et exigences. En évaluant la conception avant le début du développement de la solution, vous pouvez éviter les blocages et les modifications de conception inattendues. De cette façon, vous assurez le calendrier et le budget du projet.
Synapse SQL dispose d’une architecture de scale-out qui distribue le traitement des données de calcul sur plusieurs nœuds. Le calcul est séparé du stockage, ce qui permet d’adapter l’échelle du calcul indépendamment des données présentes dans le système. Pour plus d’informations, consultez Architecture d’un pool SQL (anciennement SQL DW) dans Azure Synapse Analytics.
Analyse d’évaluation
Au cours de la phase d’évaluation, vous avez collecté des informations sur la façon dont le système d’origine était déployé et des détails des structures implémentées. Ces informations peuvent désormais vous aider à identifier les écarts entre ce qui est implémenté et ce qui doit être développé. Par exemple, il est temps de prendre en compte l’impact de la conception de tables de distribution par tourniquet (round robin) plutôt que de tables distribuées par hachage, ou les avantages en termes de performances de l’utilisation correcte de tables répliquées.
Réviser l’architecture cible
Pour déployer correctement un pool SQL dédié, il est important d’adopter une architecture alignée sur les exigences métier. Pour plus d’informations, consultez Entreposage de données dans Microsoft Azure.
Chemin de migration
Un projet de migration pour Azure Synapse est similaire à toute autre migration de base de données. Vous devriez considérer qu’il pourrait y avoir des différences entre le système d’origine et Azure Synapse.
Assurez-vous que vous disposez d’un chemin de migration clair pour :
- Objets, scripts et requêtes de base de données
- Transfert de données (exportation à partir d’une source et transit vers le cloud)
- Chargement initial des données dans Azure Synapse
- Connexions et utilisateurs
- Contrôle d’accès aux données (sécurité au niveau des lignes)
Pour plus d’informations, consultez Migrer un entrepôt de données vers un pool SQL dédié dans Azure Synapse Analytics.
Absences de fonctionnalités
Déterminez si le système d’origine dépend de fonctionnalités qui ne sont pas prises en charge par Azure Synapse. Les fonctionnalités non prises en charge dans des pools SQL dédiés incluent certains types de données, tels que les types de données XML et spatiales, et des curseurs.
Pour plus d'informations, consultez les pages suivantes :
- Types de données de table pour un pool SQL dédié (anciennement SQL DW) dans Azure Synapse Analytics
- Fonctionnalités Transact-SQL prises en charge dans Azure Synapse SQL
Test de pool SQL dédié
Comme pour tout autre projet, vous devez effectuer des tests pour vous assurer que votre pool SQL dédié répond aux besoins métier requis. Il est essentiel de tester la qualité des données, l’intégration des données, la sécurité et les performances.
Étapes suivantes
Dans l’article suivant de la série Réussite d’Azure Synapse par conception, découvrez comment évaluer la conception de votre pool Spark pour identifier les problèmes et valider qu’elle répond aux instructions et exigences.