Différences entre les espaces de travail Azure Synapse (anciennement SQL DW) et Azure Synapse Analytics
Initialement publié en tant que blog de la communauté technique à l’adresse suivante : https://techcommunity.microsoft.com/t5/azure-synapse-analytics-blog/what-s-the-difference-between-azure-synapse-formerly-sql-dw-and/ba-p/3597772
La confusion règne depuis un certain temps en ce qui concerne Microsoft Docs et les deux ensembles distincts de documentation pour les pools SQL dédiés. Lorsque vous recherchez sur Internet une documentation relative à Azure Synapse et que vous arrivez sur le site Microsoft Learn Docs, la table des matières comporte un interrupteur permettant de basculer entre les deux ensembles de documentation.
Cet article précise quelle documentation s’applique à votre environnement Synapse Analytics.
| Azure Synapse Analytics | Pools SQL dédiés (anciennement SQL DW) |
|---|---|
|
|
Vous verrez également des notes dans de nombreux documents qui tentent de mettre en évidence l’implémentation Synapse des pools SQL dédiés référencés par le document.
Les pools SQL dédiés existent dans deux modalités différentes
Les entrepôts SQL Data Warehouse autonomes ou existants ont été renommés en « pools SQL dédiés (anciennement SQL DW) » en novembre 2020. Depuis lors, les pools SQL dédiés créés dans Synapse Analytics sont des « pools SQL dédiés dans des espaces de travail Synapse ».
Vers 2016, Microsoft a adapté son appliance locale de traitement massivement parallèle (MPP) dans le cloud sous le nom de « Azure SQL Data Warehouse » ou « SQL DW » en abrégé.
Les historiens se souviennent que l’appliance était nommée « Parallel Data Warehouse (PDW) », puis « Analytics Platform System (APS) », qui alimente encore de nombreuses solutions d’entreposage de données locales aujourd’hui.
Azure SQL Data Warehouse a adopté les concepts d’Azure SQL DB, comme un serveur logique où l’administration et la mise en réseau sont contrôlées. SQL DW peut exister sur le même serveur que d’autres bases de données SQL. Cette implémentation permet aux administrateurs et utilisateurs actuels d’Azure SQL DB d’appliquer facilement les mêmes concepts à l’entrepôt de données.
Toutefois, l’espace d’analyse et d’insights a subi des changements massifs depuis 2016. Nous avons opéré un changement de paradigme dans la manière dont l’entreposage des données est assuré. À mesure que SQL DW a géré l’entreposage, l’espace de travail Synapse s’est développé et a complété le portefeuille analytique. La nouvelle expérience d’espace de travail Synapse est devenue généralement disponible en 2020.
Le composant SQL DW d’origine n’en est qu’une partie. Il est désormais connu sous le nom de pool SQL dédié.
Cela a constitué un changement important, avec davantage de capacités. L’ensemble de la plateforme a reçu un nouveau nom approprié : Synapse Analytics.
Mais qu’en est-il de tous les SQL DW existants ? Est-ce qu’ils deviennent automatiquement des espaces de travail Synapse ?
Changement de nom et migration
Les instances Azure SQL DW n’ont pas été automatiquement mises à niveau vers des espaces de travail Synapse Analytics.
De nombreux facteurs jouent dans les mises à niveau de grandes plateformes, et il était préférable de laisser le choix aux clients. Azure SQL DW a été renommé « Pool SQL dédié (anciennement SQL DW) » afin d’indiquer clairement que l’ancien SQL DW est en fait le même artefact que celui qui se trouve dans Synapse Analytics.
Dans la documentation, vous verrez également « pool SQL dédié (anciennement SQL DW) » appelé « pool SQL dédié autonome ».
La migration d’un pool SQL dédié (anciennement SQL DW) en termes relatifs est facile avec quelques étapes à partir du portail Microsoft Azure. Toutefois, il ne s’agit pas d’une migration complète. Il y a une différence subtile qui se remarque dans la bannière qui apparaît sur le portail Microsoft Azure.
Dans une migration, le pool SQL dédié (anciennement SQL DW) n’est jamais vraiment migré. Il reste sur le serveur logique sur lequel il se trouvait à l’origine. Le server-123.database.windows.net du serveur DNS ne devient jamais server-123.sql.azuresynapse.net. Les clients qui ont « mis à niveau » ou « migré » un SQL DW vers Synapse Analytics ont toujours un serveur logique complet qui peut être partagé dans un serveur logique Azure SQL Database.
Le SQL DW et l’espace de travail Synapse migrés
Le chemin de mise à niveau ou de migration décrit dans la section précédente est connecté à un espace de travail Synapse. Pour les environnements migrés, utilisez la documentation du pool SQL dédié (anciennement SQL DW) pour les scénarios de pool SQL dédié. Tous les autres composants de Synapse Analytics sont accessibles à partir de la documentation Synapse Analytics.
Voici une manière rapide de visualiser cette situation comme un « mélange » de toutes les capacités supplémentaires de l’espace de travail Synapse Analytics et du SQL DW d’origine.
Si vous n’avez jamais migré un SQL DW et que vous avez démarré votre parcours avec la création d’un espace de travail Synapse Analytics, utilisez simplement la documentation Synapse Analytics.
Différences avec PowerShell
L’un des principaux domaines de confusion dans la documentation entre le « pool SQL dédié (anciennement SQL DW) » et les pools SQL dédiés « Synapse Analytics » est PowerShell.
L’implémentation SQL DW d’origine utilise un serveur logique identique à Azure SQL Database. Il existe un module PowerShell partagé nommé Az.Sql. Dans ce module, pour créer un pool SQL dédié (anciennement SQL DW), l’applet de commande New-AzSqlDatabase a un paramètre pour Edition qui est utilisé pour distinguer que vous souhaitez un DataWarehouse.
Lorsque Synapse Analytics a été publié, il était fourni avec un autre module PowerShell de Az.Synapse. Pour créer un pool SQL dédié dans un espace de travail Synapse Analytics, vous allez utiliser New-AzSynapseSqlPool. Dans ce module PowerShell, il n’est pas nécessaire d’inclure un paramètre « Édition », car il est exclusivement utilisé pour Synapse.
Ces deux modules ne sont PAS égaux dans tous les cas. Certaines actions qui peuvent être effectuées dans Az.Sql ne peuvent pas l’être dans Az.Synapse. Par exemple, l’exécution d’une restauration pour un pool SQL dédié (anciennement SQL DW) utilise l’applet de commande Restore-AzSqlDatabase tandis que Synapse Analytics utilise Restore-AzSynapseSqlPool. Toutefois, l’action de restaurer sur une limite d’abonnement n’est disponible que dans le module Az.Sql avec Restore-AzSqlDatabase.