Framgångsmetod för Synapse-implementering: Utvärdera serverlös SQL-pooldesign

Kommentar

Den här artikeln är en del av azure Synapse-implementeringen genom att designa artiklar. En översikt över serien finns i Azure Synapse-implementeringen lyckades avsiktligt.

Du bör utvärdera din serverlösa SQL-pooldesign för att identifiera problem och verifiera att den uppfyller riktlinjer och krav. Genom att utvärdera designen innan lösningsutvecklingen börjar kan du undvika blockerare och oväntade designändringar. På så sätt skyddar du projektets tidslinje och budget.

Arkitekturseparationen av lagring och beräkning för moderna data, analysplattformar och tjänster har varit ett trendigt och ofta använt mönster. Det ger kostnadsbesparingar och mer flexibilitet som möjliggör oberoende skalning på begäran av din lagring och beräkning. Synapse SQL serverless utökar det här mönstret genom att lägga till funktionen för att fråga data lake-data direkt. Du behöver inte bekymra dig om beräkningshantering när du använder självbetjäningstyper av arbetsbelastningar.

Anpassa gapanalys

När du planerar att implementera SQL-serverlösa pooler i Azure Synapse måste du först se till att serverlösa pooler passar dina arbetsbelastningar. Du bör överväga driftseffektivitet, prestandaeffektivitet, tillförlitlighet och säkerhet.

Driftsäkerhet

Utvärdera följande punkter för driftskvalitet.

• Lösningsutvecklingsmiljö: I den här metoden finns en utvärdering av utvecklingsmiljön för lösningen. Identifiera hur miljöer (utveckling, testning och produktion) är utformade för att stödja lösningsutveckling. Vanligtvis hittar du en produktions- och icke-produktionsmiljö (för utveckling och testning). Du bör hitta Synapse-arbetsytor i alla miljöer. I de flesta fall är du skyldig att separera dina produktions- och utvecklings-/testanvändare och arbetsbelastningar.
• Synapse-arbetsytedesign: I den här metoden finns en utvärdering av Synapse-arbetsytedesignen. Identifiera hur arbetsytorna har utformats för din lösning. Bekanta dig med designen och vet om lösningen använder en enda arbetsyta eller om flera arbetsytor ingår i lösningen. Ta reda på varför en enskild eller flera arbetsytedesign har valts. En design för flera arbetsytor väljs ofta för att framtvinga strikta säkerhetsgränser.
• Distribution: SQL Serverless är tillgängligt på begäran med varje Synapse-arbetsyta, så det kräver inga särskilda distributionsåtgärder. Kontrollera den regionala närheten till tjänsten och azure Data Lake Storage Gen2-kontot (ADLS Gen2) som den är ansluten till.
• Övervakning: Kontrollera om inbyggd övervakning är tillräcklig och om några externa tjänster måste införas för att lagra historiska loggdata. Med loggdata kan du analysera prestandaändringar och du kan definiera aviseringar eller utlösta åtgärder för specifika omständigheter.

Prestandaeffektivitet

Till skillnad från traditionella databasmotorer förlitar sig INTE SQL Serverless på ett eget optimerat lagringslager. Därför är dess prestanda starkt beroende av hur data organiseras i ADLS Gen2. Utvärdera följande punkter för prestandaeffektivitet.

• Datainmatning: Granska hur data lagras i datasjön. Filstorlekar, antalet filer och mappstrukturen påverkar alla prestanda. Tänk på att även om vissa filstorlekar kan fungera för SQL serverlös kan de medföra problem för effektiv bearbetning eller förbrukning av andra motorer eller program. Du måste utvärdera datalagringsdesignen och verifiera den mot alla datakonsumenter, inklusive SQL Serverless och andra dataverktyg som ingår i din lösning.
• Dataplacering: Utvärdera om din design har enhetliga och definierade vanliga mönster för dataplacering. Se till att katalogförgrening kan stödja dina säkerhetskrav. Det finns några vanliga mönster som kan hjälpa dig att hålla tidsseriedata organiserade. Oavsett val ser du till att det även fungerar med andra motorer och arbetsbelastningar. Kontrollera också om det kan hjälpa partitionering av automatisk identifiering för Spark-program och externa tabeller.
• Dataformat: I de flesta fall ger SQL serverless bästa prestanda och bättre kompatibilitet med hjälp av ett Parquet-format. Kontrollera dina prestanda- och kompatibilitetskrav, eftersom även om Parquet förbättrar prestanda – tack vare bättre komprimering och minskning av I/O (genom att bara läsa de kolumner som krävs för analys) – kräver det mer beräkningsresurser. Eftersom vissa källsystem inte har inbyggt stöd för Parquet som exportformat kan det också leda till fler omvandlingssteg i dina pipelines och/eller beroenden i din övergripande arkitektur.
• Utforskning: Varje bransch är annorlunda. I många fall finns det dock vanliga dataåtkomstmönster i de vanligaste frågorna. Mönster omfattar vanligtvis filtrering och aggregeringar efter datum, kategorier eller geografiska regioner. Identifiera dina vanligaste filtreringsvillkor och relatera dem till hur mycket data som läses/ignoreras av de vanligaste frågorna. Kontrollera om informationen på datasjön är organiserad för att gynna dina utforskningskrav och förväntningar. För de frågor som identifieras i din design och i utvärderingen kan du se om du kan eliminera onödiga partitioner i sökvägsparametern OPENROWSET eller – om det finns externa tabeller – om det kan vara till hjälp att skapa fler index.

Tillförlitlighet

Utvärdera följande punkter för tillförlitlighet.

• Tillgänglighet: Verifiera eventuella tillgänglighetskrav som identifierades under utvärderingsfasen. Det finns inga specifika serviceavtal för SQL serverlös, men det finns en tidsgräns på 30 minuter för frågekörning. Identifiera de frågor som körs längst från utvärderingen och verifiera dem mot din serverlösa SQL-design. En tidsgräns på 30 minuter kan bryta förväntningarna på din arbetsbelastning och visas som ett tjänstproblem.
• Konsekvens: SQL Serverless är främst utformat för läsarbetsbelastningar. Kontrollera därför om alla konsekvenskontroller har utförts under datasjöens etablerings- och skapandeprocess. Håll dig uppdaterad om nya funktioner, till exempel Lagringslager med öppen källkod i Delta Lake , som ger stöd för ACID-garantier (atomicitet, konsekvens, isolering och hållbarhet) för transaktioner. Med den här funktionen kan du implementera effektiva lambda- eller kappa-arkitekturer för både strömnings- och batchanvändningsfall. Se till att utvärdera din design för möjligheter att tillämpa nya funktioner, men inte på bekostnad av projektets tidslinje eller kostnad.
• Säkerhetskopiering: Granska eventuella haveriberedskapskrav som identifierades under utvärderingen. Verifiera dem mot din sql-serverlösa design för återställning. SJÄLVA SQL Serverless har inte ett eget lagringslager och det skulle kräva hantering av ögonblicksbilder och säkerhetskopior av dina data. Datalagret som nås av serverlös SQL är externt (ADLS Gen2). Granska återställningsdesignen i projektet för dessa datauppsättningar.

Säkerhet

Organisationen av dina data är viktig för att skapa flexibla säkerhetsgrunder. I de flesta fall kräver olika processer och användare olika behörigheter och åtkomst till specifika underområden i datasjön eller det logiska informationslagret.

Utvärdera följande punkter för säkerhet.

• Datalagring: Med hjälp av den information som samlats in under utvärderingssteget kan du identifiera om typiska områden med rådata, faser och kuraterade datasjöar måste placeras på samma lagringskonto i stället för oberoende lagringskonton. Det senare kan leda till mer flexibilitet när det gäller roller och behörigheter. Den kan också lägga till fler indata-/utdataåtgärder per sekund (IOPS)-kapacitet som kan behövas om arkitekturen måste ha stöd för tunga och samtidiga läs-/skrivarbetsbelastningar (till exempel realtids- eller IoT-scenarier). Kontrollera om du behöver separera ytterligare genom att behålla dina sandbox-områden och huvuddataområden på separata lagringskonton. De flesta användare behöver inte uppdatera eller ta bort data, så de behöver inte skrivbehörighet till datasjön, förutom sandbox-områden och privata områden.
• I din utvärderingsinformation kan du identifiera om några krav är beroende av säkerhetsfunktioner som Always Encrypted, Dynamisk datamaskering eller säkerhet på radnivå. Verifiera tillgängligheten för dessa funktioner i specifika scenarier, till exempel när de används med funktionen OPENROWSET. Förutse potentiella lösningar som kan krävas.
• I din utvärderingsinformation kan du identifiera vilka som är de bästa autentiseringsmetoderna. Överväg Microsoft Entra-tjänstens huvudnamn, signatur för delad åtkomst (SAS) och när och hur autentiseringsgenomströmning kan användas och integreras i det utforskningsverktyg som kunden väljer. Utvärdera designen och verifiera att den bästa autentiseringsmetoden som en del av designen.

Övrigt att tänka på

Granska din design och kontrollera om du har infört metodtips och rekommendationer. Ägna särskild uppmärksamhet åt filteroptimering och sortering för att säkerställa att predikat-pushdown fungerar korrekt.

Nästa steg

I nästa artikel i Azure Synapse lyckades med designserien får du lära dig hur du utvärderar din Spark-pooldesign för att identifiera problem och verifiera att den uppfyller riktlinjer och krav.