Azure Synapse SQL-arkitektur

I den här artikeln beskrivs arkitekturkomponenterna i Synapse SQL.

Synapse SQL arkitekturkomponenter

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

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

För serverlösa SQL en serverlös pool görs skalning automatiskt för att tillgodose resurskraven för frågor. När topologin ändras med tiden genom att lägga till, ta bort noder eller redundans, anpassas den efter ändringar och ser till att din fråga har tillräckligt med resurser och slutförs korrekt. Bilden nedan visar till exempel en serverlös pool SQL använder 4 beräkningsnoder för att köra en fråga.

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

Den Azure Synapse SQL Control-noden 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 göra sitt arbete parallellt.

Noden för serverlös SQL-poolkontroll 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å Compute-noder. Varje liten fråga kallas aktivitet och representerar en distribuerad körningsenhet. Den läser filer från lagring, ansluter resultat från andra uppgifter, grupper eller beställer data som hämtats från andra aktiviteter.

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 när du använder Synapse SQL kan du dra nytta av oberoende storlek på beräkningskraften oavsett dina lagringsbehov. För serverlös SQL görs skalningen av poolen automatiskt, medan du kan göra följande SQL dedikerade SQL poolen:

• Öka eller minska beräkningskraften inom 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 utnyttjar Azure Storage för att skydda dina användardata. Eftersom dina data lagras och hanteras av Azure Storage debiteras lagringsförbrukningen separat.

Med en SQL serverlös pool kan du köra frågor mot dina datasjöfiler, medan dedikerade 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 SQL dedikerad 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 koordinera parallella frågor. När du skickar en T-SQL-fråga till SQL dedikerad 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 med filer som ska bearbetas av varje nod.

Beräkningsnoder

Beräkningsnoderna ger dataresurser.

I dedikerad SQL mappning till beräkningsnoder för bearbetning. När du betalar för fler beräkningsresurser mappar poolen om distributionerna till de tillgängliga beräkningsnoderna. Antalet beräkningsnoder sträcker sig från 1 till 60 och bestäms av servicenivån för den dedikerade SQL poolen. Varje beräkningsnod har ett nod-ID som visas i systemvyer. Du kan se Beräkningsnod-ID genom att leta efter 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 en 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 den frågeanvändare som skickats. Automatisk skalning används för att se till att tillräckligt med beräkningsnoder används för att köra användarfrågor.

Data Movement Service

Data Movement Service (DMS) är datatransporttekniken i den dedikerade SQL som samordnar dataflyttningen mellan beräkningsnoderna. Vissa frågor kräver dataförflyttning för att säkerställa att parallella frågor returnerar korrekta resultat. När dataförflyttning krävs ser DMS till att rätt data kommer till rätt plats.

Distributioner

En distribution är den grundläggande lagringsenheten och bearbetningen för parallella frågor som körs på distribuerade data i en dedikerad SQL pool. När dedikerade SQL en pool kör en fråga delas arbetet in 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 med maximalt antal beräkningsresurser har en distribution per beräkningsnod. En dedikerad SQL med minsta 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 dela upp data i en hash-distribuerad tabell använder dedikerade SQL 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.

• Varje rad tillhör en distribution.
• En deterministisk hash-algoritm tilldelar varje rad till en distribution.
• Antalet tabellrader per distribution varierar beroende på tabellstorlekarna.

Det finns prestandaöverväganden för valet av en distributionskolumn, till exempel distinkthet, dataskevhet 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 distribution 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 för resursallokeringstabeller kräver omsuffring av data, vilket tar ytterligare 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. När du replikerar en tabell behöver du alltså inte överföra data mellan beräkningsnoder före en koppling eller aggregering. Replikerade tabeller används bäst med små tabeller. Extra lagring krävs och det tillkommer ytterligare kostnader vid skrivning av data, vilket gör stora tabeller opraktiska.

Diagrammet nedan visar en replikerad tabell 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 serverlös SQL pool. Om du inte har erfarenhet av Azure kan Azure-ordlistan vara till hjälp om du stöter på ny terminologi.