Framgångsmetod för Synapse-implementering: Utvärdera arbetsytedesign

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.

Synapse-arbetsytan är en enhetlig grafisk användarupplevelse som sammanfogar dina analys- och databearbetningsmotorer, datasjöar, databaser, tabeller, datauppsättningar och rapporteringsartefakter tillsammans med kod- och processorkestrering. Med tanke på antalet tekniker och tjänster som är integrerade i Synapse-arbetsytan bör du se till att de viktigaste komponenterna ingår i din design.

Designgranskning av Synapse-arbetsyta

Identifiera om din lösningsdesign omfattar en Synapse-arbetsyta eller flera arbetsytor. Fastställ drivrutinerna för den här designen. Det kan finnas olika orsaker, men i de flesta fall är orsaken till flera arbetsytor antingen säkerhetssegregering eller faktureringssegregering. När du fastställer antalet arbetsytor och databasgränser bör du tänka på att det finns en gräns på 20 arbetsytor per prenumeration.

Identifiera vilka element eller tjänster inom varje arbetsyta som måste delas och med vilka resurser. Resurser kan omfatta datasjöar, integreringskörningar (IR), metadata eller konfigurationer och kod. Ta reda på varför just den här designen valdes när det gäller potentiella synergieffekter. Fråga dig själv om dessa synergieffekter motiverar extra kostnader och hanteringskostnader.

Designgranskning av Data Lake

Vi rekommenderar att datasjön (om en del av lösningen) är korrekt nivåindelad. Du bör dela upp din datasjö i tre huvudområden som är relaterade till datauppsättningarna Brons, Silver och Guld . Bronze – eller råskiktet – kan finnas på ett eget separat lagringskonto eftersom det har strängare åtkomstkontroller på grund av omaskerade känsliga data som det kan lagra.

Granskning av säkerhetsdesign

Granska säkerhetsdesignen för arbetsytan och jämför den med den information som du samlade in under utvärderingen. Se till att alla krav uppfylls och att alla begränsningar har beaktats. För enkel hantering rekommenderar vi att användarna organiseras i grupper med lämplig behörighetsprofilering: du kan förenkla åtkomstkontrollen med hjälp av säkerhetsgrupper som överensstämmer med roller. På så sätt kan nätverksadministratörer lägga till eller ta bort användare från lämpliga säkerhetsgrupper för att hantera åtkomst.

Serverlösa SQL-pooler och Apache Spark-tabeller lagrar sina data i en Azure Data Lake Gen2-container (ADLS Gen2) som är associerad med arbetsytan. Användarinstallerade Apache Spark-bibliotek hanteras också i samma lagringskonto. För att aktivera dessa användningsfall måste både användare och den hanterade tjänstidentiteten för arbetsytan (MSI) läggas till i rollen Storage Blob Data Contributor för ADLS Gen2-lagringscontainern. Kontrollera detta krav mot dina säkerhetskrav.

Dedikerade SQL-pooler ger en omfattande uppsättning säkerhetsfunktioner för att kryptera och maskera känsliga data. Både dedikerade och serverlösa SQL-pooler möjliggör hela ytan för SQL Server-behörigheter, inklusive inbyggda roller, användardefinierade roller, SQL-autentisering och Microsoft Entra-autentisering. Granska säkerhetsdesignen för lösningens dedikerade SQL-pool och serverlös ÅTKOMST och data för SQL-pooler.

Granska säkerhetsplanen för din datasjö och alla ADLS Gen2-lagringskonton (och andra) som ingår i din Azure Synapse Analytics-lösning. ADLS Gen2-lagring är inte i sig en beräkningsmotor och har därför inte någon inbyggd möjlighet att selektivt maskera dataattribut. Du kan använda ADLS Gen2-behörigheter på lagringskonto- eller containernivå med hjälp av rollbaserad åtkomstkontroll (RBAC) och/eller på mapp- eller filnivå med hjälp av åtkomstkontrollistor (ACL). Granska designen noggrant och sträva efter att undvika onödig komplexitet.

Här följer några saker att tänka på när det gäller säkerhetsdesignen.

• Kontrollera att microsoft Entra-ID:ts krav för konfiguration ingår i designen.
• Sök efter scenarier mellan klientorganisationer. Sådana problem kan uppstå eftersom vissa data finns i en annan Azure-klientorganisation, eller att de måste flyttas till en annan klientorganisation, eller så måste de nås av användare från en annan klientorganisation. Se till att dessa scenarier beaktas i din design.
• Vilka är rollerna för varje arbetsyta? Hur använder de arbetsytan?
• Hur är säkerheten utformad på arbetsytan?
  • Vem kan visa alla skript, notebook-filer och pipelines?
  • Vem kan köra skript och pipelines?
  • Vem kan skapa/pausa/återuppta SQL- och Spark-pooler?
  • Vem kan publicera ändringar på arbetsytan?
  • Vem kan checka in ändringar i källkontrollen?
• Kommer pipelines att komma åt data med hjälp av lagrade autentiseringsuppgifter eller arbetsytans hanterade identitet?
• Har användarna rätt åtkomst till datasjön för att bläddra bland data i Synapse Studio?
• Skyddas datasjön korrekt med hjälp av lämplig kombination av RBAC och ACL:er?
• Har användarbehörigheterna för SQL-poolen angetts korrekt för varje roll (dataexpert, utvecklare, administratör, företagsanvändare och andra)?

Designgranskning av nätverk

Här är några saker att tänka på för nätverksdesignen.

• Är anslutningen utformad mellan alla resurser?
• Vilken nätverksmekanism ska användas (Azure ExpressRoute, offentligt Internet eller privata slutpunkter)?
• Behöver du kunna ansluta säkert till Synapse Studio?
• Har dataexfiltrering beaktats?
• Behöver du ansluta till lokala datakällor?
• Behöver du ansluta till andra molndatakällor eller beräkningsmotorer, till exempel Azure Machine Learning?
• Har Azure-nätverkskomponenter, till exempel nätverkssäkerhetsgrupper (NSG:er), granskats för korrekt anslutning och dataflytt?
• Har integrering med de privata DNS-zonerna beaktats?
• Behöver du kunna bläddra i datasjön inifrån Synapse Studio eller bara köra frågor mot data i datasjön med serverlös SQL eller PolyBase?

Slutligen kan du identifiera alla dina datakonsumenter och kontrollera att deras anslutning redovisas i designen. Kontrollera att nätverks- och säkerhets-utposter tillåter att tjänsten får åtkomst till nödvändiga lokala källor och att dess autentiseringsprotokoll och mekanismer stöds. I vissa scenarier kan du behöva ha mer än en lokalt installerad IR eller datagateway för SaaS-lösningar, till exempel Microsoft Power BI.

Granskning av övervakningsdesign

Granska utformningen av övervakningen av Azure Synapse-komponenterna för att säkerställa att de uppfyller de krav och förväntningar som identifierades under utvärderingen. Kontrollera att övervakningen av resurser och dataåtkomst har utformats och att den identifierar varje övervakningskrav. En robust övervakningslösning bör införas som en del av den första distributionen till produktion. På så sätt kan fel identifieras, diagnostiseras och åtgärdas i tid. Förutom basinfrastrukturen och pipelinekörningarna bör data också övervakas. Beroende på vilka Azure Synapse-komponenter som används identifierar du övervakningskraven för varje komponent. Om Spark-pooler till exempel ingår i lösningen övervakar du det felaktiga postarkivet. 

Här följer några saker att tänka på när det gäller övervakningsdesignen.

• Vem kan övervaka varje resurstyp (pipelines, pooler och andra)?
• Hur länge måste databasaktivitetsloggar behållas?
• Kommer kvarhållning av arbetsytor och databasloggar att använda Log Analytics eller Azure Storage?
• Utlöses aviseringar i händelse av ett pipelinefel? I så fall, vem ska då meddelas?
• Vilken tröskelvärdesnivå för en SQL-pool ska utlösa en avisering? Vem bör meddelas?

Designgranskning av källkontroll

Som standard tillämpar en Synapse-arbetsyta ändringar direkt på Synapse-tjänsten med hjälp av den inbyggda publiceringsfunktionen. Du kan aktivera källkontrollintegrering, vilket ger många fördelar. Fördelarna är bättre samarbete, versionshantering, godkännanden och versionspipelines för att främja ändringar i utvecklings-, test- och produktionsmiljöer. Azure Synapse tillåter en lagringsplats för en enda källkontroll per arbetsyta, som kan vara antingen Azure DevOps Git eller GitHub.

Här följer några saker att tänka på för källkontrolldesignen.

• Om du använder Azure DevOps Git, är Synapse-arbetsytan och dess lagringsplats i samma klientorganisation?
• Vem kommer att kunna komma åt källkontrollen?
• Vilka behörigheter beviljas varje användare i källkontrollen?
• Har en förgrenings- och sammanslagningsstrategi utvecklats?
• Kommer versionspipelines att utvecklas för distribution till olika miljöer?
• Kommer en godkännandeprocess att användas för sammanslagning och för versionspipelines?

Kommentar

Utformningen av utvecklingsmiljön är av avgörande betydelse för projektets framgång. Om en utvecklingsmiljö har utformats utvärderas den i ett separat steg i den här metoden.

Nästa steg

I nästa artikel i Azure Synapse lyckades med designserien får du lära dig hur du utvärderar dataintegreringsdesignen och verifierar att den uppfyller riktlinjer och krav.