Unterschied zwischen Azure Synapse-Arbeitsbereichen (vormals SQL DW) und Azure Synapse Analytics-Arbeitsbereichen
Ursprünglich veröffentlicht als Techcommunity-Blog unter: https://techcommunity.microsoft.com/t5/azure-synapse-analytics-blog/what-s-the-difference-between-azure-synapse-formerly-sql-dw-and/ba-p/3597772
Bei Microsoft Docs und den beiden unterschiedlichen Dokumentationssätzen für dedizierte SQL-Pools gab es eine Weile Verwirrung. Wenn Sie eine Internetsuche nach einem Azure Synapse-bezogenen Dokument durchführen und auf der Microsoft Learn Docs-Website landen, zeigt das Inhaltsverzeichnis eine Umschaltfläche zwischen zwei Dokumentensätzen an.
In diesem Artikel wird erläutert, welche Dokumentation für Ihre Synapse Analytics-Umgebung gilt.
| Azure Synapse Analytics | Dedizierte SQL-Pools (vormals SQL DW) |
|---|---|
|
|
Außerdem werden in vielen Dokumenten Notizen angezeigt, die hervorheben möchten, auf welche Synapse-Implementierung dedizierter SQL-Pools das Dokument verweist.
Dedizierte SQL-Pools sind in zwei verschiedenen Modalitäten vorhanden
Eigenständige oder vorhandene SQL Data Warehouses wurden im November 2020 in „dedizierte SQL-Pools (vormals SQL DW)“ umbenannt. Seitdem sind dedizierte SQL-Pools, die in Synapse Analytics erstellt wurden, „dedizierte SQL-Pools in Synapse-Arbeitsbereichen“.
Etwa im Jahr 2016 hat Microsoft seine massive parallele Verarbeitung (Massively Parallel Processing, MPP) lokaler Appliances an die Cloud als „Azure SQL Data Warehouse“ oder kurz „SQL DW“ angepasst.
Historiker erinnern sich daran, dass die Appliance als paralleles Data Warehouse (PDW) und dann Analytics Platform System (APS) bezeichnet wurde, das heute noch viele lokale Data Warehousing-Lösungen unterstützt.
Azure SQL Data Warehouse hat die Konstrukte von Azure SQL DB übernommen, z. B. einen logischen Server, auf dem die Verwaltung und Netzwerke gesteuert werden. SQL DW könnte auf demselben Server wie andere SQL-DBs vorhanden sein. Diese Implementierung erleichterte es aktuellen Azure SQL DB-Administratoren und -Fachkräften, dieselben Konzepte auf Data Warehouse anzuwenden.
Seit dem Jahr 2016 hat der Bereich der Analyse und Erkenntnisse jedoch massive Veränderungen durchlaufen. Wir haben einen Paradigmenwechsel in der Bereitstellung von Data Warehousing vorgenommen. Da SQL DW die Speicherung verarbeitete, baute der Synapse-Arbeitsbereich darauf auf und rundete das Analyseportfolio ab. Die neue Oberfläche des Synapse-Arbeitsbereichs wurde im Jahr 2020 allgemein verfügbar.
Die ursprüngliche SQL DW-Komponente ist nur ein Teil davon. Sie wurde als dedizierter SQL-Pool bekannt.
Dies war eine große Änderung, wobei mehr Funktionen dazugekommen sind. Die gesamte Plattform erhielt einen passenden neuen Namen: Synapse Analytics.
Aber was ist mit all den vorhandenen SQL DWs? Werden sie automatisch zu Synapse-Arbeitsbereichen?
Rebranding und Migration
Für Azure SQL DW-Instanzen wurde nicht automatisch ein Upgrade auf Synapse Analytics-Arbeitsbereiche durchgeführt.
Viele Faktoren spielen bei großen Plattformupgrades eine Rolle, und es war am besten, Kunden die Möglichkeit zu geben, sich für diese zu entscheiden. Azure SQL DW wurde in „Dedizierter SQL-Pool (vormals SQL DW)“ umbenannt, mit der Absicht, einen klaren Hinweis darauf zu schaffen, dass das frühere SQL DW tatsächlich dasselbe Artefakt ist, das in Synapse Analytics weiterverwendet wird.
In der Dokumentation sehen Sie auch den „Dedizierten SQL-Pool (vormals SQL DW)“, der als „eigenständiger dedizierter SQL-Pool“ bezeichnet wird.
Die Migration eines dedizierten SQL-Pools (vormals SQL DW) vom Azure-Portal ist relativ einfach und mit nur wenigen Schritten verbunden. Es handelt sich jedoch nicht um eine vollständige Migration. Es gibt einen feinen Unterschied, der von dem Popup im Azure-Portal angezeigt wird.
In einer Migration wird der dedizierte SQL-Pool (vormals SQL DW) nie wirklich migriert. Er verbleibt auf dem logischen Server, auf dem er sich ursprünglich befunden hat. Der Server-DNS server-123.database.windows.net wird niemals zu server-123.sql.azuresynapse.net. Kunden, die ein SQL DW zu Synapse Analytics „upgegradet“ oder „migriert“ haben, verfügen weiterhin über einen vollständigen logischen Server, der auf einem logischen Azure SQL-Datenbankserver freigegeben werden kann.
Der migrierte SQL DW- und Synapse-Arbeitsbereich
Der im vorherigen Abschnitt beschriebene Upgrade- oder Migrationspfad ist mit einem Synapse-Arbeitsbereich verbunden. Verwenden Sie die Dokumentation für migrierte Umgebungen im dedizierten SQL-Pool (vormals SQL DW) für dedizierte SQL-Poolszenarien. Auf alle anderen Komponenten von Synapse Analytics würde über die Synapse Analytics-Dokumentation zugegriffen werden.
Eine schnelle Möglichkeit, dies als „Mischung“ aller zusätzlichen Synapse Analytics-Arbeitsbereichsfunktionen und des ursprünglichen SQL DW zu visualisieren, finden Sie in der folgenden schematischen Darstellung.
Wenn Sie nie ein SQL DW migriert und Ihre Journey mit dem Erstellen eines Synapse Analytics-Arbeitsbereichs begonnen haben, verwenden Sie einfach die Synapse Analytics-Dokumentation.
PowerShell-Unterschiede
Einer der größten Verwirrung stiftenden Bereiche in der Dokumentation zwischen dem „dedizierten SQL-Pool (vormals SQL DW)“ und dedizierten SQL-Pools in „Synapse Analytics“ ist PowerShell.
Die ursprüngliche SQL DW-Implementierung verwendet einen logischen Server, der mit der Azure SQL-Datenbank identisch ist. Es gibt ein freigegebenes PowerShell-Modul mit dem Namen Az.Sql. In diesem Modul verfügt das Cmdlet New-AzSqlDatabase zum Erstellen eines neuen dedizierten SQL-Pools (vormals SQL DW) über einen Parameter für Edition, der verwendet wird, um zu unterscheiden, dass Sie ein DataWarehouse möchten.
Als Synapse Analytics veröffentlicht wurde, wurde es mit einem anderen PowerShell-Modul von Az.Synapse bereitgestellt. Zum Erstellen eines dedizierten SQL-Pools in einem Synapse Analytics-Arbeitsbereich würden Sie New-AzSynapseSqlPool verwenden. In diesem PowerShell-Modul muss kein „Edition“-Parameter eingeschlossen werden, da es ausschließlich für Synapse verwendet wird.
Diese beiden Module SIND NICHT in allen Fällen gleich. Es gibt einige Aktionen, die in Az.Sql ausgeführt werden können, die in Az.Synapse nicht ausgeführt werden können. Beispielsweise wird beim Ausführen einer Wiederherstellung für einen dedizierten SQL-Pool (vormals SQL DW) das Cmdlet Restore-AzSqlDatabase verwendet, während Synapse Analytics Restore-AzSynapseSqlPool verwendet. Die Aktion zur abonnementübergreifenden Wiederherstellung ist jedoch nur im Az.Sql-Modul mit Restore-AzSqlDatabase verfügbar.