Diferencia entre Azure Synapse (anteriormente SQL DW) y las áreas de trabajo de Azure Synapse Analytics
Publicado originalmente como blog de techcommunity en: https://techcommunity.microsoft.com/t5/azure-synapse-analytics-blog/what-s-the-difference-between-azure-synapse-formerly-sql-dw-and/ba-p/3597772
Ha habido confusión durante un tiempo cuando se trata de Microsoft Docs y los dos conjuntos distintos de documentación para grupos de SQL dedicados. Al realizar una búsqueda en Internet de un documento relacionado con Azure Synapse y aterrizar en el sitio de Microsoft Learn Docs, la tabla de contactos tiene un cambio de alternancia entre dos conjuntos de documentación.
En este artículo se aclara qué documentación se aplica al entorno de Synapse Analytics.
| Azure Synapse Analytics | Grupos de SQL dedicados (antes SQL DW) |
|---|---|
|
|
También verá notas en muchos documentos que intentan resaltar qué implementación de Synapse de grupos de SQL dedicados hace referencia al documento.
Existen grupos de SQL dedicados en dos modalidades diferentes
En noviembre de 2020, se cambió el nombre de las instancias independientes o existentes de SQL Data Warehouse a "grupos de SQL dedicados (anteriormente SQL DW)". Desde entonces, los grupos de SQL dedicados creados en Synapse Analytics son "grupos de SQL dedicados en áreas de trabajo de Synapse".
Alrededor de 2016, Microsoft adaptó su dispositivo local de procesamiento masivo paralelo (MPP) a la nube como "Azure SQL Data Warehouse" o "SQL DW" durante un breve plazo.
El dispositivo se denominó almacenamiento de datos paralelo (PDW) y, a continuación, Analytics Platform System (APS), que sigue impulsando muchas soluciones de almacenamiento de datos locales hoy en día.
Azure SQL Data Warehouse adoptó las construcciones de Azure SQL DB, como un servidor lógico donde se controlan la administración y las redes. SQL DW podría existir en el mismo servidor que otros DB de SQL. Esta implementación facilita a los administradores y profesionales actuales de Azure SQL DB aplicar los mismos conceptos al almacenamiento de datos.
Sin embargo, el espacio de análisis e información ha pasado por cambios masivos desde 2016. Hicimos un cambio de paradigma en la forma en que se entregaba el almacenamiento de datos. A medida que SQL DW controló el almacenamiento, el área de trabajo de Synapse se expandió y redondeó la cartera de análisis. La nueva experiencia del área de trabajo de Synapse llegó a estar disponible con carácter general en 2020.
El componente SQL DW original es solo una parte de esto. Se conocía como un grupo de SQL dedicado.
Este fue un gran cambio y con más funcionalidades. Toda la plataforma recibió un nuevo nombre adecuado: Synapse Analytics.
¿Pero qué hay de todos los SQL DW existentes? ¿Se convertirán automáticamente en áreas de trabajo de Synapse?
Cambio de marca y migración
Las instancias de Azure SQL DW no se actualizaron automáticamente a las áreas de trabajo de Synapse Analytics.
Muchos factores influyen en las grandes actualizaciones de la plataforma y es mejor permitir que los clientes opten por esto. Azure SQL DW se cambió de nombre como "Grupo de SQL dedicado (anteriormente SQL DW)" con la intención de crear una indicación clara de que SQL DW anterior es de hecho el mismo artefacto que reside en Synapse Analytics.
En la documentación, también verá "Grupo de SQL dedicado (anteriormente SQL DW)" denominado "grupo de SQL dedicado independiente".
Migrar un grupo de SQL dedicado (anteriormente SQL DW) es relativamente fácil con unos pocos pasos de Azure Portal. Sin embargo, no es una migración completa. Hay una diferencia sutil que se observa en la notificación del sistema que aparece en Azure Portal.
En una migración, el grupo de SQL dedicado (anteriormente SQL DW) nunca se migra realmente. Permanece en el servidor lógico en el que estaba originalmente. El DNS del servidor server-123.database.windows.net nunca se convierte en server-123.sql.azuresynapse.net. Los clientes que "actualizaron" o "migraron" una instancia de SQL DW a Synapse Analytics todavía tienen un servidor lógico completo que se podría compartir en un servidor lógico de Azure SQL Database.
Área de trabajo de SQL DW y Synapse migradas
La ruta de actualización o migración descrita en la sección anterior está conectada a un área de trabajo de Synapse. Para entornos migrados, use la documentación de grupo de SQL dedicado (anteriormente SQL DW) para escenarios de grupo de SQL dedicados. Se accedería a todos los demás componentes de Synapse Analytics desde la documentación de Synapse Analytics.
Se muestra a continuación una manera rápida de visualizar esto como una "combinación" de todas las funcionalidades adicionales del área de trabajo de Synapse Analytics y SQL DW original.
Si nunca ha migrado una instancia de SQL DW y ha iniciado el recorrido con la creación de un área de trabajo de Synapse Analytics, simplemente use documentación de Synapse Analytics.
Diferencias de PowerShell
Una de las principales áreas de confusión en la documentación entre "grupo de SQL dedicado (anteriormente SQL DW)" y grupos de SQL dedicados de "Synapse Analytics" es PowerShell.
La implementación de SQL DW original usa un servidor lógico que es el mismo que Azure SQL Database. Hay un módulo compartido de PowerShell denominado Az.Sql. En este módulo, para crear un nuevo grupo de SQL dedicado (anteriormente SQL DW), el cmdlet New-AzSqlDatabase tiene un parámetro para Edition que se usa para distinguir que desea un DataWarehouse.
Cuando se lanzó Synapse Analytics, llegó con un módulo de PowerShell diferente de Az.Synapse. Para crear un grupo de SQL dedicado en un área de trabajo de Synapse Analytics, use New-AzSynapseSqlPool. En este módulo de PowerShell, no es necesario incluir un parámetro "Edition", ya que se usa exclusivamente para Synapse.
Estos dos módulos NO son iguales en todos los casos. Hay algunas acciones que se pueden realizar en Az.Sql que no se pueden realizar en Az.Synapse. Por ejemplo, la realización de una restauración para un grupo de SQL dedicado (anteriormente SQL DW) usa el cmdlet Restore-AzSqlDatabase, mientras que Synapse Analytics usa Restore-AzSynapseSqlPool. Sin embargo, la acción para restaurar a través de un límite de suscripción solo está disponible en el módulo Az.Sql con Restore-AzSqlDatabase.