Azure Synapse SQL-arkitektur

I den här artikeln beskrivs arkitekturkomponenterna i Synapse SQL. Den förklarar också hur Azure Synapse SQL kombinerar funktioner för distribuerad frågebearbetning med Azure Storage för att uppnå höga prestanda och skalbarhet.

Komponenter i Synapse SQL-arkitekturen

Synapse SQL använder en utskalningsarkitektur för att distribuera beräkningsbearbetning av data över flera noder. Beräkning är separat från lagring, vilket gör att du kan skala beräkning oberoende av data i systemet.

För dedikerad SQL-pool är skalningsenheten en abstraktion av beräkningskraft som kallas för en informationslagerenhet.

För serverlös SQL-pool sker skalning automatiskt för att tillgodose frågeresurskrav eftersom den är serverlös. När topologin ändras över tid genom att lägga till, ta bort noder eller redundans, anpassas den till ändringar och ser till att frågan har tillräckligt med resurser och slutförs korrekt. Följande bild visar till exempel serverlös SQL-pool som använder fyra beräkningsnoder för att köra en fråga.

Skärmbild av Synapse SQL-arkitektur.

Synapse SQL använder en nodbaserad arkitektur. Program ansluter och utfärdar T-SQL-kommandon till en kontrollnod, vilket är den enda startpunkten för Synapse SQL.

Den Azure Synapse SQL-kontrollnoden använder en distribuerad frågemotor för att optimera frågor för parallell bearbetning och skickar sedan åtgärder till beräkningsnoder för att utföra sitt arbete parallellt.

Den serverlösa SQL-poolkontrollnoden använder DQP-motorn (Distributed Query Processing) för att optimera och samordna distribuerad körning av användarfrågor genom att dela upp den i mindre frågor som ska köras på beräkningsnoder. Varje liten fråga kallas aktivitet och representerar distribuerad körningsenhet. Den läser filer från lagring, kopplar resultat från andra uppgifter, grupper eller orderdata som hämtats från andra uppgifter.

Beräkningsnoderna lagrar alla användardata i Azure Storage och kör de parallella frågorna. Data Movement Service (DMS) är en intern tjänst på systemnivå som flyttar data mellan noder efter behov för att köra frågor parallellt och returnera korrekta resultat.

Med frikopplad lagring och beräkning kan du dra nytta av oberoende storleksändring av beräkningskraft oavsett dina lagringsbehov när du använder Synapse SQL. För serverlös SKALning av SQL-pool görs automatiskt, och för dedikerad SQL-pool kan man:

  • Öka eller minska beräkningskraften i en dedikerad SQL-pool utan att flytta data.
  • Pausa beräkningskapaciteten och lämna data intakta, så att du bara betalar för lagring.
  • Återuppta beräkningskapacitet under driftstimmar.

Azure Storage

Synapse SQL använder Azure Storage för att skydda dina användardata. Eftersom dina data lagras och hanteras av Azure Storage debiteras du separat för din lagringsförbrukning.

Med en serverlös SQL-pool kan du köra frågor mot dina Data Lake-filer, medan en dedikerad SQL-pool gör att du kan köra frågor mot och mata in data från dina Data Lake-filer. När data matas in i en dedikerad SQL-pool partitioneras data i distributioner för att optimera systemets prestanda. Du kan välja vilket mönster för horisontell partitionering som ska användas för att distribuera data när du definierar tabellen. Dessa mönster för horisontell partitionering stöds:

  • Hash
  • Resursallokering (round robin)
  • Replikera

Kontrollnoden

Kontrollnoden är hjärnan i arkitekturen. Det är den som är klientdelen som interagerar med alla program och anslutningar.

I Synapse SQL körs den distribuerade frågemotorn på kontrollnoden för att optimera och samordna parallella frågor. När du skickar en T-SQL-fråga till en dedikerad SQL-pool omvandlar kontrollnoden den till frågor som körs parallellt mot varje distribution.

I en serverlös SQL-pool körs DQP-motorn på kontrollnoden för att optimera och samordna distribuerad körning av användarfrågor genom att dela upp den i mindre frågor som ska köras på beräkningsnoder. Den tilldelar också uppsättningar filer som ska bearbetas av varje nod.

Beräkningsnoder

Beräkningsnoderna ger dataresurser.

I en dedikerad SQL-pool mappas distributioner till beräkningsnoder för bearbetning. När du betalar för fler beräkningsresurser mappas distributionerna om till tillgängliga beräkningsnoder i poolen. Antalet beräkningsnoder sträcker sig från 1 till 60 och bestäms av tjänstnivån för den dedikerade SQL-poolen. Varje beräkningsnod har ett nod-ID som visas i systemvyer. Du kan se beräkningsnodens ID genom att leta efter kolumnen node_id i systemvyer vars namn börjar med sys.pdw_nodes. En lista över dessa systemvyer finns i Synapse SQL-systemvyer.

I en serverlös SQL-pool tilldelas varje beräkningsnod uppgift och uppsättning filer som aktiviteten ska köras på. Uppgiften är en distribuerad frågekörningsenhet, som i själva verket är en del av frågeanvändaren som skickats. Automatisk skalning används för att se till att tillräckligt många beräkningsnoder används för att köra användarfrågor.

Data Movement Service

Data Movement Service (DMS) är datatransporttekniken i en dedikerad SQL-pool som samordnar dataflytten mellan beräkningsnoderna. Vissa frågor kräver dataflytt för att säkerställa att de parallella frågorna returnerar korrekta resultat. När dataflytt krävs ser DMS till att rätt data kommer till rätt plats.

Distributioner

En distribution är den grundläggande lagrings- och bearbetningsenheten för parallella frågor som körs på distribuerade data i en dedikerad SQL-pool. När en dedikerad SQL-pool kör en fråga delas arbetet upp i 60 mindre frågor som körs parallellt.

Var och en av de 60 mindre frågorna körs på en av datadistributionerna. Varje beräkningsnod hanterar en eller flera av de 60 distributionerna. En dedikerad SQL-pool med maximalt antal beräkningsresurser har en distribution per beräkningsnod. En dedikerad SQL-pool med minsta möjliga beräkningsresurser har alla distributioner på en beräkningsnod.

Hash-distribuerade tabeller

En hash-distribuerad tabell kan leverera högsta frågeprestanda för kopplingar och aggregeringar för stora tabeller.

För att fragmentera data i en hash-distribuerad tabell använder den dedikerade SQL-poolen en hash-funktion för att deterministiskt tilldela varje rad till en distribution. I tabelldefinitionen utses en av kolumnerna till distributionskolumnen. Hash-funktionen använder värdena i distributionskolumnen för att tilldela varje rad till en distribution.

Följande diagram illustrerar hur en fullständig (icke-distribuerad tabell) lagras som en hash-distribuerad tabell.

Skärmbild av en tabell som lagras som en hash-distribution.

  • Varje rad tillhör en distribution.
  • En deterministisk hashalgoritm tilldelar varje rad till en distribution.
  • Antalet tabellrader per distribution varierar beroende på tabellernas olika storlekar.

Det finns prestandaöverväganden för valet av en distributionskolumn, till exempel distinkthet, datasnedställning och de typer av frågor som körs i systemet.

Distribuerade tabeller med resursallokering

En resursallokeringstabell är den enklaste tabellen för att skapa och leverera snabba prestanda när den används som mellanlagringstabell för belastningar.

En distribuerad tabell med resursallokering distribuerar data jämnt i tabellen men utan ytterligare optimering. En fördelning väljs först slumpmässigt och sedan tilldelas buffertar med rader till distributioner sekventiellt. Det går snabbt att läsa in data i en resursallokeringstabell, men frågeprestanda kan ofta vara bättre med hash-distribuerade tabeller. Kopplingar i resursallokeringstabeller kräver omfördelning av data, vilket tar extra tid.

Replikerade tabeller

En replikerad tabell ger snabbaste frågeprestanda för små tabeller.

En tabell som replikeras cachelagrar en fullständig kopia av tabellen på varje beräkningsnod. Om du replikerar en tabell behöver du därför inte överföra data mellan beräkningsnoder före en koppling eller aggregering. Replikerade tabeller används bäst med små tabeller. Extra lagringsutrymme krävs och det tillkommer extra kostnader när du skriver data, vilket gör stora tabeller opraktiska.

Diagrammet nedan visar en replikerad tabell som cachelagras på den första distributionen på varje beräkningsnod.

Skärmbild av den replikerade tabellen som cachelagras på den första distributionen på varje beräkningsnod.

Nästa steg

Nu när du vet lite om Synapse SQL kan du lära dig hur du snabbt skapar en dedikerad SQL-pool och läser in exempeldata. Eller börja använda en serverlös SQL-pool. Om du inte har använt Azure tidigare kanske du tycker att Azure-ordlistan är användbar när du stöter på ny terminologi.