Dela via

Informationslagerenheter (DWU:er) för dedikerad SQL-pool (tidigare SQL DW) i Azure Synapse Analytics

  • Artikel

Det här dokumentet innehåller rekommendationer om hur du väljer det ideala antalet informationslagerenheter (DWU:er) för dedikerad SQL-pool (tidigare SQL DW) för att optimera pris och prestanda och hur du ändrar antalet enheter.

Vad är informationslagerenheter?

En dedikerad SQL-pool (tidigare SQL DW) representerar en samling analysresurser som etableras. Analysresurser definieras som en kombination av CPU, minne och I/O.

Dessa tre resurser paketeras i beräkningsenheter med namnet Data Warehouse Units (DWU: er). En DWU representerar ett abstrakt, normaliserat mått för beräkningsresurser och prestanda.

En ändring av tjänstnivån ändrar antalet DWU:er som är tillgängliga för systemet, vilket i sin tur justerar systemets prestanda och kostnad.

För högre prestanda kan du öka antalet informationslagerenheter. Minska informationslagerenheterna för mindre prestanda. Lagrings- och beräkningskostnader faktureras separat, så ändringar av informationslagerenheter påverkar inte lagringskostnaderna.

Prestanda för informationslagerenheter baseras på dessa arbetsbelastningsmått för informationslager:

  • Hur snabbt en standardmässig dedikerad SQL-poolfråga (tidigare SQL DW) kan genomsöka ett stort antal rader och sedan utföra en komplex aggregering. Den här åtgärden är I/O och processorintensiv.
  • Hur snabbt den dedikerade SQL-poolen (tidigare SQL DW) kan mata in data från Azure Storage Blobs eller Azure Data Lake. Den här åtgärden är nätverks- och processorintensiv.
  • Hur snabbt CREATE TABLE AS SELECT T-SQL-kommandot kan kopiera en tabell. Den här åtgärden omfattar att läsa data från lagring, distribuera dem mellan noderna i enheten och skriva till lagring igen. Den här åtgärden är processor-, I/O- och nätverksintensiv.

Öka DWU:er:

  • Linjärt ändrar systemets prestanda för genomsökningar, aggregeringar och CTAS-instruktioner
  • Ökar antalet läsare och skrivare för PolyBase-inläsningsåtgärder
  • Ökar det maximala antalet samtidiga frågor och samtidighetsfack

Servicenivåmål

Servicenivåmålet (SLO) är skalbarhetsinställningen som avgör kostnaden och prestandanivån för din dedikerade SQL-pool (tidigare SQL DW). Tjänstnivåerna för den dedikerade SQL-poolen Gen2 (tidigare SQL DW) mäts i informationslagerenheter (DWU), till exempel DW2000c.

Kommentar

Dedikerad SQL-pool (tidigare SQL DW) Gen2 lade nyligen till ytterligare skalningsfunktioner för att stödja beräkningsnivåer så låga som DW100c. Befintliga informationslager på Gen1 som kräver de lägre beräkningsnivåerna kan nu uppgradera till Gen2 i de regioner som för närvarande är tillgängliga utan extra kostnad. Om din region ännu inte stöds kan du fortfarande uppgradera till en region som stöds. Mer information finns i Uppgradera till Gen2.

I T-SQL avgör inställningen SERVICE_OBJECTIVE tjänstnivån och prestandanivån för din dedikerade SQL-pool (tidigare SQL DW).

CREATE DATABASE mySQLDW
(Edition = 'Datawarehouse'
 ,SERVICE_OBJECTIVE = 'DW1000c'
)
;

Prestandanivåer och informationslagerenheter

Varje prestandanivå använder en något annorlunda måttenhet för sina informationslagerenheter. Den här skillnaden återspeglas på fakturan eftersom skalningsenheten direkt översätts till fakturering.

  • Gen1-informationslager mäts i DWU:er (Data Warehouse Units).
  • Gen2-informationslager mäts i beräkningsdatalagerenheter (cDWUs).

Både DWU:er och cDWUs stöder skalning av beräkning upp eller ned och pausar beräkning när du inte behöver använda informationslagret. Alla dessa åtgärder är på begäran. Gen2 använder en lokal diskbaserad cache på beräkningsnoderna för att förbättra prestandan. När du skalar eller pausar systemet ogiltigförklaras cacheminnet och därför krävs en period av cacheuppvärmning innan optimala prestanda uppnås.

Kapacitetsbegränsningar

Varje SQL-server (till exempel myserver.database.windows.net) har en DTU-kvot (Database Transaction Unit) som tillåter ett visst antal informationslagerenheter. Mer information finns i kapacitetsbegränsningarna för arbetsbelastningshantering.

Hur många informationslagerenheter behöver jag?

Det idealiska antalet informationslagerenheter beror mycket på din arbetsbelastning och mängden data som du har läst in i systemet.

Steg för att hitta den bästa DWU:en för din arbetsbelastning:

  1. Börja med att välja en mindre DWU.

  2. Övervaka programmets prestanda när du testar datainläsningar i systemet och observera antalet valda DWU:er jämfört med de prestanda du ser. Verifiera genom att övervaka resursanvändningen.

  3. Identifiera eventuella ytterligare krav för periodiska perioder med hög belastning. Arbetsbelastningar som visar betydande toppar och dalar i aktiviteten kan behöva skalas ofta.

Dedikerad SQL-pool (tidigare SQL DW) är ett utskalningssystem som kan etablera stora mängder beräkning och frågestora mängder data.

Om du vill se dess verkliga funktioner för skalning, särskilt vid större DWU:er, rekommenderar vi att du skalar datauppsättningen när du skalar för att säkerställa att du har tillräckligt med data för att mata processorerna. För skalningstestning rekommenderar vi att du använder minst 1 TB.

Kommentar

Frågeprestanda ökar bara med mer parallellisering om arbetet kan delas mellan beräkningsnoder. Om du upptäcker att skalningen inte ändrar prestandan kan du behöva justera tabelldesignen och/eller dina frågor. Vägledning för frågejustering finns i Hantera användarfrågor.

Behörigheter

För att ändra informationslagrets enheter krävs de behörigheter som beskrivs i ALTER DATABASE.

Inbyggda Azure-roller som SQL DB-deltagare och SQL Server-deltagare kan ändra DWU-inställningar.

Visa aktuella DWU-inställningar

Så här visar du den aktuella DWU-inställningen:

  1. Öppna SQL Server Object Explorer i Visual Studio.
  2. Anslut till huvuddatabasen som är associerad med den logiska SQL-servern.
  3. Välj från vyn sys.database_service_objectives dynamisk hantering. Här är ett exempel:
SELECT  db.name [Database]
,        ds.edition [Edition]
,        ds.service_objective [Service Objective]
FROM    sys.database_service_objectives   AS ds
JOIN    sys.databases                     AS db ON ds.database_id = db.database_id
;

Ändra informationslagerenheter

Azure Portal

Så här ändrar du DWU:er:

  1. Öppna Azure-portalen, öppna databasen och klicka på Skala.

  2. Under Skala flyttar du skjutreglaget åt vänster eller höger för att ändra DWU-inställningen.

  3. Klicka på Spara. Ett bekräftelsemeddelande visas. Klicka på Ja för att bekräfta eller på Nej för att avbryta.

PowerShell

Kommentar

Vi rekommenderar att du använder Azure Az PowerShell-modulen för att interagera med Azure. Information om hur du kommer igång finns i Installera Azure PowerShell. Information om hur du migrerar till Az PowerShell-modulen finns i artikeln om att migrera Azure PowerShell från AzureRM till Az.

Om du vill ändra DWU:erna använder du PowerShell-cmdleten Set-AzSqlDatabase . I följande exempel anges servicenivåmålet till DW1000 för databasen MySQLDW som finns på servern MyServer.

Set-AzSqlDatabase -DatabaseName "MySQLDW" -ServerName "MyServer" -RequestedServiceObjectiveName "DW1000c"

Mer information finns i PowerShell-cmdletar för dedikerad SQL-pool (tidigare SQL DW)

T-SQL

Med T-SQL kan du visa aktuella DWUsettings, ändra inställningarna och kontrollera förloppet.

Så här ändrar du DWU:erna:

  1. Anslut till huvuddatabasen som är associerad med servern.
  2. Använd ALTER DATABASE TSQL-instruktionen. I följande exempel anges servicenivåmålet till DW1000c för databasen MySQLDW.
ALTER DATABASE MySQLDW
MODIFY (SERVICE_OBJECTIVE = 'DW1000c')
;

REST API:er

Om du vill ändra DWU:erna använder du REST-API:et Skapa eller Uppdatera databas . I följande exempel anges servicenivåmålet till DW1000c för databasen MySQLDW, som finns på servern MyServer. Servern finns i en Azure-resursgrupp med namnet ResourceGroup1.

PUT https://management.azure.com/subscriptions/{subscription-id}/resourceGroups/{resource-group-name}/providers/Microsoft.Sql/servers/{server-name}/databases/{database-name}?api-version=2014-04-01-preview HTTP/1.1
Content-Type: application/json; charset=UTF-8

{
    "properties": {
        "requestedServiceObjectiveName": "DW1000c"
    }
}

Fler REST API-exempel finns i REST API:er för dedikerad SQL-pool (tidigare SQL DW).

Kontrollera status för DWU-ändringar

DWU-ändringar kan ta flera minuter att slutföra. Om du skalar automatiskt kan du överväga att implementera logik för att säkerställa att vissa åtgärder har slutförts innan du fortsätter med en annan åtgärd.

Genom att kontrollera databastillståndet via olika slutpunkter kan du implementera automatisering på rätt sätt. Portalen ger meddelande när en åtgärd och databasens aktuella tillstånd har slutförts, men tillåter inte programmatisk kontroll av tillstånd.

Du kan inte kontrollera databastillståndet för skalbara åtgärder med Azure-portalen.

Så här kontrollerar du status för DWU-ändringar:

  1. Anslut till huvuddatabasen som är associerad med servern.

  2. Skicka följande fråga för att kontrollera databastillståndet.

    SELECT    *
FROM      sys.dm_operation_status
WHERE     resource_type_desc = 'Database'
AND       major_resource_id = 'MySQLDW'
;

Denna DMV returnerar information om olika hanteringsåtgärder i din dedikerade SQL-pool (tidigare SQL DW), till exempel åtgärden och tillståndet för åtgärden, som antingen är IN_PROGRESS eller SLUTFÖRd.

Skalningsarbetsflödet

När du startar en skalningsåtgärd tar systemet först bort alla öppna sessioner och återställer alla öppna transaktioner för att säkerställa ett konsekvent tillstånd. För skalningsåtgärder sker skalning endast när den här transaktionsåterställningen har slutförts.

  • För en uppskalningsåtgärd kopplar systemet från alla beräkningsnoder, etablerar ytterligare beräkningsnoder och kopplar sedan till lagringslagret igen.
  • För en nedskalningsåtgärd kopplar systemet bort alla beräkningsnoder och kopplar sedan endast de noder som behövs till lagringslagret.

Nästa steg

Mer information om hur du hanterar prestanda finns i Resursklasser för arbetsbelastningshantering och minnes- och samtidighetsgränser.