你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站,请访问 https://docs.azure.cn

Azure Synapse(以前称为 SQL DW)与 Azure Synapse Analytics 工作区之间的差异

本文最初以技术博客形式发表于 https://techcommunity.microsoft.com/t5/azure-synapse-analytics-blog/what-s-the-difference-between-azure-synapse-formerly-sql-dw-and/ba-p/3597772

一段时间以来,在 Microsoft Docs 和专用 SQL 池的两组不同文档方面,一直存在着混淆现象。 当你在 Internet 上搜索 Azure Synapse 相关文档并登录 Microsoft Learn Docs 网站时,“联系人表”会在两组文档之间切换。

本文阐明了哪些文档适用于 Synapse Analytics 环境。

Azure Synapse Analytics 专用 SQL 池(旧称为 SQL DW)
Microsoft Learn Docs 站点的屏幕截图,其中显示了 Azure Synapse Analytics 目录。 Microsoft Learn Docs 站点的屏幕截图,其中显示了较旧的专用 SQL 池(以前称为 SQL DW)目录。

你还会在许多文档中看到笔记,它们尝试突出显示该文档引用的专用 SQL 池的 Synapse 实现。

专用 SQL 池以两种不同的形式存在

2020 年 11 月,独立或现有 SQL 数据仓库已重命名为“专用 SQL 池(以前称为为 SQL DW)。 此后,在 Synapse Analytics 中创建的专用 SQL 池成为了“Synapse 工作区中的专用 SQL 池”。

大约在 2016 年,Microsoft 将其大规模并行处理 (MPP) 本地设备调整到云中,即“Azure SQL 数据仓库”或简称为“SQL DW”。

历史上,该设备被命名为并行数据仓库 (PDW),然后改为分析平台系统 (APS),目前仍在为许多本地数据仓库解决方案提供支持。

Azure SQL 数据仓库采用了 Azure SQL DB 的构造,例如控制管理和网络的逻辑服务器。 SQL DW 可以与其他 SQL DB 位于同一服务器上。 通过此实现,当前 Azure SQL DB 管理员和从业者可以轻松地将相同的概念应用于数据仓库。

然而,自 2016 年以来,分析和见解空间发生了巨大的变化。 我们改变了数据仓库交付方式的范式。 当 SQL DW 处理仓库时,Synapse 工作区在此基础上进行了扩展了,并完善了分析组合。 新的 Synapse 工作区体验于 2020 年正式发布。

Azure Synapse Analytics 工作区、体验和平台的关系图。

原始 SQL DW 组件只是其中的一部分。 它被称为专用 SQL 池。

专用 SQL 池与 Synapse 工作区差异的关系图。

这是一项重大更改,并且提供了更多的功能。 整个平台被赋予了一个合适的新名称:Synapse Analytics。

但所有现有的 SQL DW 该怎么办? 它们是否会自动成为 Synapse 工作区?

重塑品牌和迁移

Azure SQL DW 实例并未自动升级到 Synapse Analytics 工作区。

许多因素都会影响大型平台的升级,因此最佳做法是允许客户选择升级。 Azure SQL DW 已被重新命名为“专用 SQL 池(以前称为 SQL DW)”,旨在明确说明以前的 SQL DW 其实就是 Synapse Analytics 中的同一工件。

专用 SQL 池(以前称为 SQL DW)和 Azure Synapse Analytics 的功能差异关系图。

在文档中,还将看到“专用 SQL 池(以前称为 SQL DW)”被称为“独立专用 SQL 池”。

迁移专用 SQL 池(以前称为 SQL DW)相对来说比较简单,只需在 Azure 门户中执行几个步骤即可完成。 但这不是完全的迁移。 在 Azure 门户中弹出的 Toast 中,可以注意到细微的差异。

紫色功能区 Azure 门户中的屏幕截图,它提醒你现在可以从 Synapse 工作区访问专用 SQL 池(以前称为 SQL DW)。

在迁移中,专用 SQL 池(以前称为 SQL DW)从不会真正迁移。 它会保留在最初所在的逻辑服务器上。 服务器 DNS server-123.database.windows.net 则永远不会变为 server-123.sql.azuresynapse.net。 将 SQL DW“升级”或“迁移”到 Synapse Analytics 的客户仍具有可在 Azure SQL 数据库逻辑服务器中共享的完整逻辑服务器。

已迁移的 SQL DW 和 Synapse 工作区

上一部分所述的升级或迁移路径已连接到 Synapse 工作区。 对于已迁移的环境,请使用专用 SQL 池方案的专用 SQL 池(以前称为 SQL DW)中的文档。 可以从 Synapse Analytics 文档访问 Synapse Analytics 的所有其他组件。

以下是将此功能可视化为所有其他 Synapse Analytics 工作区功能和原始 SQL DW 的“混合”的快速方法。

已迁移的专用 SQL 池(以前称为 SQL DW)和 Azure Synapse Analytics 的功能差异关系图。

如果从未迁移过 SQL DW,并已开始创建 Synapse Analytics 工作区的过程,则只需使用 Synapse Analytics 文档

PowerShell 差异

在文档中,“专用 SQL 池(以前称为 SQL DW)”和“Synapse Analytics”专用 SQL 池之间最容易引起混淆的领域之一是 PowerShell。

原始 SQL DW 实现使用与 Azure SQL 数据库相同的逻辑服务器。 有一个名为 Az.Sql 的共享 PowerShell 模块。 在本模块中,如果要创建新的专用 SQL 池(以前称为 SQL DW),cmdlet New-AzSqlDatabase 包含了一个 Edition 的参数,用于区分你需要 DataWarehouse

发布 Synapse Analytics 后,它附带了 Az.Synapse 的一个不同的 PowerShell 模块。 要在 Synapse Analytics 工作区中创建专用 SQL 池,请使用 New-AzSynapseSqlPool。 在此 PowerShell 模块中,无需包含“Edition”参数,因为它是专用于 Synapse 的。

这两个模块在所有情况下都不相等。 一些操作可以在 Az.Sql 中完成,但无法在 Az.Synapse 中完成。 例如,对专用 SQL 池(以前称为 SQL DW)执行还原会使用 Restore-AzSqlDatabase cmdlet,而 Synapse Analytics 使用的则是 Restore-AzSynapseSqlPool cmdlet。 但跨订阅边界进行还原的操作仅可用于包含 Restore-AzSqlDatabaseAz.Sql 中。