Synapse POC-spelbok: Datalagerhantering med dedikerad SQL-pool i Azure Synapse Analytics
I den här artikeln beskrivs en metod på hög nivå för att förbereda och köra ett effektivt POC-projekt (Proof of Concept) för Azure Synapse Analytics för en dedikerad SQL-pool.
Kommentar
Den här artikeln är en del av Azure Synapse proof of concept-spelboksserien med artiklar. En översikt över serien finns i Spelboken om konceptbevis i Azure Synapse.
Dricks
Om du inte har använt dedikerade SQL-pooler tidigare rekommenderar vi att du går igenom utbildningsvägen Arbeta med informationslager med Azure Synapse Analytics .
Förbereda för POC
Innan du bestämmer dig för dina Azure Synapse POC-mål rekommenderar vi att du först läser artikeln om Azure Synapse SQL-arkitektur för att bekanta dig med hur en dedikerad SQL-pool separerar beräkning och lagring för att ge branschledande prestanda.
Identifiera sponsorer och potentiella blockerare
När du är bekant med Azure Synapse är det dags att se till att din POC har det stöd som krävs och inte stöter på några hinder. Du bör:
- Identifiera eventuella begränsningar eller principer som din organisation har om att flytta data till och lagra data i molnet.
- Identifiera chefs- och företagsponsring för ett molnbaserat informationslagerprojekt.
- Kontrollera att din arbetsbelastning är lämplig för Azure Synapse. Mer information finns i Dedikerad SQL-poolarkitektur i Azure Synapse Analytics.
Ange tidslinjen
En POC är en begränsad, tidsbegränsad övning med specifika, mätbara mål och mått som definierar framgång. Helst bör den ha en viss grund i affärsverkligheten så att resultaten är meningsfulla.
POCs har det bästa resultatet när de är tidsboxade. Tidsboxning allokerar en fast och maximal tidsenhet till en aktivitet. Enligt vår erfarenhet ger två veckor tillräckligt med tid för att slutföra arbetet utan belastningen av för många användningsfall eller komplexa testmatriser. När du arbetar inom den här fasta tidsperioden rekommenderar vi att du följer den här tidslinjen:
- Datainläsning: Tre dagar eller mindre
- Fråga: Fem dagar eller mindre
- Mervärdestester: Två dagar eller mindre
Här följer några tips:
- Gör realistiska uppskattningar av den tid som du behöver för att slutföra uppgifterna i din plan.
- Se att tiden för att slutföra din POC beror på storleken på din datauppsättning, antalet databasobjekt (tabeller, vyer och lagrade procedurer), databasobjektens komplexitet och antalet gränssnitt som du ska testa.
- Om du uppskattar att din POC kommer att köras längre än fyra veckor kan du överväga att minska omfånget för att endast fokusera på de viktigaste målen.
- Få support från alla leadresurser och sponsorer för tidslinjen innan du börjar med POC.
När du har fastställt att det inte finns några omedelbara hinder och du har angett tidslinjen kan du begränsa en arkitektur på hög nivå.
Skapa en arkitektur med övergripande omfång
En framtida arkitektur på hög nivå innehåller sannolikt många datakällor och datakonsumenter, stordatakomponenter och eventuellt maskininlärning och AI-datakonsumenter. För att hålla dina POC-mål uppnåeliga (och inom gränserna för din angivna tidslinje) bestämmer du vilka av dessa komponenter som ska ingå i POC och vilka som ska undantas.
Om du redan använder Azure identifierar du dessutom följande:
- Alla befintliga Azure-resurser som du kan använda under POC. Resurser kan till exempel innehålla Microsoft Entra-ID eller Azure ExpressRoute.
- Vilka Azure-regioner din organisation föredrar.
- En prenumeration som du kan använda för POC-arbete som inte är produktion.
- Dataflödet för nätverksanslutningen till Azure.
Viktigt!
Kontrollera att din POC kan förbruka en del av det dataflödet utan att ha en negativ effekt på produktionslösningarna.
Använda migreringsalternativ
Om du migrerar från ett äldre informationslagersystem till Azure Synapse kan du tänka på följande:
- Migrerar du och vill göra så få ändringar i befintliga processer för extrahering, transformering och inläsning (ETL) och informationslagerförbrukning som möjligt?
- Migrerar du men vill göra några omfattande förbättringar på vägen?
- Skapar du en helt ny dataanalysmiljö (kallas ibland ett greenfield-projekt)?
Därefter måste du överväga dina smärtpunkter.
Identifiera aktuella smärtpunkter
Din POC bör innehålla användningsfall för att bevisa potentiella lösningar för att hantera dina aktuella smärtpunkter. Här är några frågor att överväga:
- Vilka luckor i din nuvarande implementering förväntar du dig att Azure Synapse ska fylla?
- Vilka nya affärsbehov måste du stödja?
- Vilka serviceavtal måste du uppfylla?
- Vad blir arbetsbelastningarna (till exempel ETL, batchfrågor, analys, rapporteringsfrågor eller interaktiva frågor)?
Därefter måste du ange dina POC-framgångsvillkor.
Ange villkor för POC-framgång
Identifiera varför du gör en POC och se till att definiera tydliga mål. Det är också viktigt att veta vilka utdata du vill ha från din POC och vad du planerar att göra med dem.
Tänk på att en POC bör vara en kort och fokuserad insats för att snabbt bevisa eller testa en begränsad uppsättning begrepp. Om du har en lång lista med objekt att bevisa kanske du vill undersöka dem i flera POCs. POCs kan ha portar mellan sig så att du kan avgöra om du ska gå vidare till nästa POC.
Här är några exempel på POC-mål:
- Vi behöver veta att frågeprestandan för våra stora komplexa rapporteringsfrågor uppfyller våra nya serviceavtal.
- Vi behöver veta frågeprestanda för våra interaktiva användare.
- Vi behöver veta om våra befintliga ETL-processer passar bra och var förbättringar behöver göras.
- Vi behöver veta om vi kan förkorta våra ETL-körningar och med hur mycket.
- Vi behöver veta att Synapse Analytics har tillräckliga säkerhetsfunktioner för att skydda våra data på ett tillfredsställande sätt.
Därefter måste du skapa en testplan.
Skapa en testplan
Använd dina mål och identifiera specifika tester som ska köras för att stödja dessa mål och tillhandahålla dina identifierade utdata. Det är viktigt att se till att du har minst ett test för varje mål och förväntade utdata. Identifiera specifika frågor, rapporter, ETL och andra processer som du ska köra för att ge kvantifierbara resultat.
Förfina dina tester genom att lägga till flera testscenarier för att klargöra eventuella frågor om tabellstruktur som uppstår.
Bra planering definierar vanligtvis en effektiv POC-körning. Se till att alla intressenter är överens om en skriftlig testplan som kopplar varje POC-mål till en uppsättning tydligt angivna testfall och mått på framgång.
De flesta testplaner handlar om prestanda och den förväntade användarupplevelsen. Vad som följer är ett exempel på en testplan. Det är viktigt att anpassa testplanen så att den uppfyller dina affärskrav. Att tydligt definiera vad du testar kommer att ge utdelning senare i den här processen.
| Mål | Testa | Förväntade utfall |
|---|---|---|
| Vi behöver veta att frågeprestandan för våra stora komplexa rapporteringsfrågor uppfyller våra nya serviceavtal | – Sekventiellt test av komplexa frågor – Samtidighetstest av komplexa frågor mot angivna serviceavtal |
– Frågorna A, B och C slutfördes på 10, 13 respektive 21 sekunder – Med 10 samtidiga användare har frågorna A, B och C slutförts på 11, 15 och 23 sekunder i genomsnitt |
| Vi behöver veta frågeprestanda för våra interaktiva användare | – Samtidighetstest av valda frågor på en förväntad samtidighetsnivå på 50 användare. – Kör föregående fråga med cachelagring av resultatuppsättningar |
– Vid 50 samtidiga användare förväntas den genomsnittliga körningstiden vara under 10 sekunder och utan cachelagring av resultatuppsättningar – Vid 50 samtidiga användare förväntas den genomsnittliga körningstiden vara under fem sekunder med cachelagring av resultatuppsättningar |
| Vi behöver veta om våra befintliga ETL-processer kan köras i serviceavtalet | – Kör en eller två ETL-processer för att efterlikna produktionsbelastningar | – Inläsning inkrementellt i en faktatabell måste slutföras på mindre än 20 minuter (inklusive mellanlagring och datarensning) – Dimensionsbearbetningen måste ta mindre än fem minuter |
| Vi behöver veta att informationslagret har tillräckliga säkerhetsfunktioner för att skydda våra data | – Granska och aktivera nätverkssäkerhet (VNet och privata slutpunkter), åtkomstkontroll (säkerhet på radnivå, dynamisk datamaskering) | - Bevisa att data aldrig lämnar vår klientorganisation. – Se till att kundinnehållet är enkelt att skydda |
Därefter måste du identifiera och verifiera POC-datauppsättningen.
Identifiera och verifiera POC-datauppsättningen
Med hjälp av de begränsade testerna kan du nu identifiera den datauppsättning som krävs för att köra dessa tester i Azure Synapse. Granska datauppsättningen genom att tänka på följande:
- Kontrollera att datamängden representerar din produktionsdatauppsättning på ett tillfredsställande sätt när det gäller innehåll, komplexitet och skala.
- Använd inte en datauppsättning som är för liten (mindre än 1 TB), eftersom du kanske inte uppnår representativa prestanda.
- Använd inte en datauppsättning som är för stor eftersom POC inte är avsedd att slutföra en fullständig datamigrering.
- Identifiera distributionsmönstret, indexeringsalternativet och partitioneringen för varje tabell. Om det finns frågor om distribution, indexering eller partitionering lägger du till tester i din POC för att besvara dem. Tänk på att du kanske vill testa fler än ett distributionsalternativ eller indexeringsalternativ för vissa tabeller.
- Kontakta företagsägarna om det finns några blockerare för att flytta POC-datamängden till molnet.
- Identifiera eventuella säkerhets- eller sekretessproblem.
Viktigt!
Kontrollera att du kontrollerar eventuella blockerare med företagsägare innan du flyttar data till molnet. Identifiera eventuella säkerhets- eller sekretessproblem eller eventuella datafördunklingsbehov som bör göras innan data flyttas till molnet.
Därefter måste du sätta ihop expertteamet.
Montera teamet
Identifiera teammedlemmarna och deras engagemang för att stödja din POC. Gruppmedlemmar bör inkludera:
- En projektledare som ska köra POC-projektet.
- En företagsrepresentant som övervakar krav och resultat.
- En programdataexpert som hämtar data för POC-datauppsättningen.
- En Azure Synapse-specialist.
- En expertrådgivare för att optimera POC-testerna.
- Alla personer som kommer att krävas för specifika POC-projektaktiviteter men som inte krävs under hela dess varaktighet. Dessa stödresurser kan omfatta nätverksadministratörer, Azure-administratörer eller Microsoft Entra-administratörer.
Dricks
Vi rekommenderar att du engagerar en expertrådgivare för att hjälpa till med din POC. Microsofts partnercommunity har global tillgänglighet för expertkonsulter som kan hjälpa dig att utvärdera, utvärdera eller implementera Azure Synapse.
Nu när du är helt förberedd är det dags att omsätta din POC i praktiken.
Omsätta POC i praktiken
Det är viktigt att ha följande i åtanke:
- Implementera ditt POC-projekt med disciplin och stränghet för alla produktionsprojekt.
- Kör POC enligt plan.
- Ha en process för ändringsbegäran på plats för att förhindra att ditt POC-omfång växer eller ändras.
Innan testerna kan starta måste du konfigurera testmiljön. Det omfattar fyra steg:
- Konfiguration
- Läsa in data
- Fråga
- Tester för mervärde
Konfiguration
Du kan konfigurera en POC på Azure Synapse genom att följa dessa steg:
- Använd den här snabbstarten för att etablera en Synapse-arbetsyta och konfigurera lagring och behörigheter enligt POC-testplanen.
- Använd den här snabbstarten om du vill lägga till en dedikerad SQL-pool på Synapse-arbetsytan.
- Konfigurera nätverk och säkerhet enligt dina krav.
- Bevilja lämplig åtkomst till POC-teammedlemmar. Se den här artikeln om autentisering och auktorisering för åtkomst till dedikerade SQL-pooler.
Dricks
Vi rekommenderar att du utvecklar kod- och enhetstestning med hjälp av DW500c-tjänstnivån (eller nedan). Vi rekommenderar att du kör belastnings- och prestandatester med hjälp av DW1000c-tjänstnivån (eller senare). Du kan när som helst pausa beräkningen av den dedikerade SQL-poolen för att upphöra med beräkningsfakturering, vilket sparar på kostnaderna.
Läsa in data
När du har konfigurerat den dedikerade SQL-poolen kan du följa dessa steg för att läsa in data:
- Läs in data i Azure Blob Storage. För en POC rekommenderar vi att du använder ett allmänt V2-lagringskonto med lokalt redundant lagring (LRS). Det finns flera verktyg för att migrera data till Azure Blob Storage, men det enklaste sättet är att använda Azure Storage Explorer, som kan kopiera filer till en lagringscontainer.
- Läs in data i den dedikerade SQL-poolen. Azure Synapse stöder två T-SQL-inläsningsmetoder: PolyBase och COPY-instruktionen. Du kan använda SSMS för att ansluta till den dedikerade SQL-poolen för att använda någon av metoderna.
När du läser in data i den dedikerade SQL-poolen för första gången måste du överväga vilket distributionsmönster och indexalternativ som ska användas. Även om en dedikerad SQL-pool stöder en mängd olika båda, är det en bra idé att förlita sig på standardinställningarna. Standardinställningarna använder resursallokeringsdistribution och ett grupperat kolumnlagringsindex. Om det behövs kan du justera de här inställningarna senare, vilket beskrivs senare i den här artikeln.
I följande exempel visas metoden COPY-inläsning:
--Note when specifying the column list, input field numbers start from 1
COPY INTO
test_1 (Col_1 default 'myStringDefault' 1, Col_2 default 1 3)
FROM
'https://myaccount.blob.core.windows.net/myblobcontainer/folder1/'
WITH (
FILE_TYPE = 'CSV',
CREDENTIAL = (IDENTITY = 'Storage Account Key' SECRET = '<Your_Account_Key>'),
FIELDQUOTE = '"',
FIELDTERMINATOR = ',',
ROWTERMINATOR = '0x0A',
ENCODING = 'UTF8',
FIRSTROW = 2
);
Fråga
Det primära syftet med ett informationslager är att utföra analyser, vilket kräver att du frågar informationslagret. De flesta POC:er börjar med att köra ett litet antal representativa frågor mot informationslagret, först sekventiellt och sedan samtidigt. Du bör definiera båda metoderna i testplanen.
Sekventiella frågetester
Det är enkelt att köra sekventiella frågetester i SSMS. Det är viktigt att köra dessa tester med hjälp av en användare med en tillräckligt stor resursklass. En resursklass är en fördefinierad resursgräns i en dedikerad SQL-pool som styr beräkningsresurser och samtidighet för frågekörning. För enkla frågor rekommenderar vi att du använder den fördefinierade resursklassen staticrc20 . För mer komplexa frågor rekommenderar vi att du använder den fördefinierade staticrc40-resursklassen .
Observera att följande första fråga använder en frågeetikett för att tillhandahålla en mekanism för att hålla reda på frågan. Den andra frågan använder den sys.dm_pdw_exec_requests dynamiska hanteringsvyn för att söka efter etiketten.
/* Use the OPTION(LABEL = '') Syntax to add a query label to track the query in DMVs */
SELECT TOP (1000)
*
FROM
[dbo].[Date]
OPTION (LABEL = 'Test1');
/* Use sys.dm_pdw_exec_requests to determine query execution duration (ms) */
SELECT
Total_elapsed_time AS [Elapsed_Time_ms],
[label]
FROM
sys.dm_pdw_exec_requests
WHERE
[label] = 'Test1';
Samtidiga frågetester
När du har spelat in sekventiella frågeprestanda kan du sedan köra flera frågor samtidigt. På så sätt kan du simulera en business intelligence-arbetsbelastning som körs mot den dedikerade SQL-poolen. Det enklaste sättet att köra det här testet är att ladda ned ett stresstestverktyg. Det mest populära verktyget är Apache JMeter, som är ett öppen källkod verktyg från tredje part.
Verktyget rapporterar om minsta, högsta och medianfrågevaraktigheter för en viss samtidighetsnivå. Anta till exempel att du vill simulera en Business Intelligence-arbetsbelastning som genererar 100 samtidiga frågor. Du kan konfigurera JMeter för att köra dessa 100 samtidiga frågor i en loop och sedan granska körningen av stabilt tillstånd. Det kan göras med cachelagring av resultatuppsättningar på eller av för att utvärdera funktionens lämplighet.
Se till att dokumentera dina resultat. Här är ett exempel på några resultat:
| Samtidighet | # Frågor körs | DWU | Minsta varaktighet | Maximal varaktighet(S) | Medianvaraktighet |
|---|---|---|---|---|---|
| 100 | 1 000 | 5 000 | 3 | 10 | 5 |
| 50 | 5 000 | 5 000 | 3 | 6 | 4 |
Blandade arbetsbelastningstester
Testning av blandade arbetsbelastningar är ett tillägg till de samtidiga frågetesterna. Genom att lägga till en datainläsningsprocess i arbetsbelastningsmixen simulerar arbetsbelastningen bättre en verklig produktionsarbetsbelastning.
Optimera data
Beroende på vilken frågearbetsbelastning som körs i Azure Synapse kan du behöva optimera informationslagrets distributioner och index och köra testerna igen. Mer information finns i Metodtips för dedikerade SQL-pooler i Azure Synapse Analytics.
De vanligaste misstagen under installationen är:
- Stora frågor körs med en resursklass som är för låg.
- De dedikerade SQL-pooltjänstnivå-DWU:erna är för låga för arbetsbelastningen.
- Stora tabeller kräver hash-distribution.
För att förbättra frågeprestandan kan du:
- Skapa materialiserade vyer, vilket kan påskynda frågor som involverar vanliga aggregeringar.
- Replikera tabeller, särskilt för små dimensionstabeller.
- Hash distribuerar stora faktatabeller som är anslutna eller aggregerade.
Tester för mervärde
När frågeprestandatestningen är klar är det dags att testa specifika funktioner för att kontrollera att de uppfyller dina avsedda användningsfall. Dessa funktioner omfattar bland annat:
- Säkerhet på radnivå
- Säkerhet på kolumnnivå
- Dynamisk datamaskning
- Skalning mellan kluster via arbetsbelastningsisolering
Slutligen måste du tolka dina POC-resultat.
Tolka POC-resultaten
När du har testresultat för ditt informationslager är det viktigt att tolka dessa data. En vanlig metod du kan använda är att jämföra körningarna när det gäller pris/prestanda. Enkelt uttryckt tar pris/prestanda bort skillnaderna i pris per DWU eller tjänstmaskinvara och ger ett enda jämförbart tal för varje prestandatest.
Här är ett exempel:
| Testa | Testlängd | DWU | $/hr för DWU | Kostnad för test |
|---|---|---|---|---|
| Test 1 | 10 min | 1000 | $12/tim | 2 USD |
| Test 2 | 30 min | 500 | $6/tim | $3 |
Det här exemplet gör det enkelt att se att test 1 på DWU1000 är mer kostnadseffektivt vid $2 per testkörning jämfört med $3 per testkörning.
Kommentar
Du kan också använda den här metoden för att jämföra resultat mellan leverantörer i en POC.
Sammanfattningsvis är du redo att utvärdera resultatet när du har slutfört alla POC-tester. Börja med att utvärdera om POC-målen har uppfyllts och de önskade utdata som samlats in. Notera var ytterligare testning är berättigad och ytterligare frågor som har ställts.