Infrastruktur Spark-kapacitet og klyngeplanlægning

Denne artikel indeholder praktisk vejledning til planlægning af kapacitet og beregning for Spark-arbejdsbelastninger i Microsoft Fabric, der dækker udviklings-, migrerings- og produktionsscenarier.

Retningslinjer for dimensionering

Dette afsnit giver praktisk vejledning til dimensionering og konfiguration af Spark-arbejdsbelastninger i Fabric. Den dækker scenarier som ny udvikling, migration fra Azure Synapse og kapacitetsjustering til produktionsbrug.

Scenarie: Du er ny bruger af Fabric og har brug for vejledning om kapacitetsplanlægning.

Start med prøvekapacitet: Hvis du er ny bruger af Fabric, skal du starte med prøvekapaciteten. Den tilbyder enten F4-kapacitet (4 kapacitetsenheder) eller F64-kapacitet (64 kapacitetsenheder) i 60 dage. Denne opsætning er ideel til udvikling og test af Spark-arbejdsbelastninger. For at estimere din nødvendige kapacitet, gå til Plan din kapacitetsstørrelse og Fabric SKU Estimator (forhåndsvisning).

Valg af startpulje vs. brugerdefineret pulje: 

Starter puljer: Typisk vil du bruge startpuljer til dine Spark-arbejdsbelastninger. Fabric forbereder disse pools og sikrer hurtige opstartstider for sessionerne. De er ideelle til udviklingsmiljøer, hvor du ikke har brug for brugerdefinerede biblioteker, Managed Private Endpoint (MPE) eller Private Link (PL). Startpuljer kan forbedre udviklerproduktiviteten betydeligt.

Brugerdefinerede puljer: Brug brugerdefinerede grupper, når du aktiverer MPE (Managed Private Endpoint) eller Private Link (PL). 

Du kan få mere at vide om startgrupper og brugerdefinerede grupper i dokumentationen til Apache Spark-beregning til datateknik og datavidenskab.  

Profilering af Spark Notebooks: 

• Hvis du vil overvåge Spark-programmer i Fabric, kan du bruge:

  • Spark History Server: til at analysere detaljer om enkelte programmer og mere detaljeret faseniveau, opgaveniveau, skævheder, logisk plan, fysisk plan.

  • Brugergrænseflade for ressourceforbrug: Til at analysere eksekutorudnyttelse og antallet af eksekutorer, der skaleres op eller ned efter hver fase.

  • Overvågningsbrugergrænseflade: 30-dages målepunkter for Notebook/Spark Job Definition (SJD)/pipeline-udførelsesdetaljer på højt niveau, f.eks. udførelsestid, status, indsendt af osv. Overvågning af brugergrænsefladen er god til synlighed på tværs af apps.

  • Udvidelse til diagnosticeringssender: Sådan udsender du logge til destinationer som Azure Log Analytics, Azure Storage og Azure-hændelseshubs. Dette er fantastisk til langsigtet trendanalyse.

• Generelt skal du begynde at profilere dit program med startpuljer (mellemstore Spark-puljer (8 vCores og 64 GB hukommelse)). Begynd med mindst én node og observer udførelsestiden. 

• Hvis du vil observere ressourceforbruget, skal du gå til brugergrænsefladen for Spark-ressourceforbrug. Hvis de allokerede forekomster i brugergrænsefladen for ressourceforbrug er færre end det maksimale antal forekomster i fasen med det højeste antal opgaver, skal du reducere det maksimale antal noder i automatisk skalering af Spark, så det stemmer overens med de allokerede forekomster.  

  

• Hvis det maksimale antal og de allokerede forekomster overlapper hinanden, kan du overveje at øge konfigurationen af det maksimale antal noder for at forbedre paralleliteten og ydeevnen. 

  

Håndtering af dataskævhed:

• Hvis du opdager dataskævhed, hjælper det måske ikke blot at tilføje flere ressourcer. Adresser skævheder ved hjælp af teknikker som ompartitionering, når ujævn datadistribution forårsager skævheden.
• Se artiklen om udvikling og overvågning i denne serie for at få vejledning til at identificere og håndtere skævheder. 

Evaluering af udnyttelse: Brug appen Kapacitetsmålepunkter til at evaluere udnyttelsen og estimere den optimale kapacitetsstørrelse for dine arbejdsbelastninger. Se dokumentationen til Overvåg Apache Spark-kapacitetsforbrug for at få flere oplysninger. Når du har analyseret kapacitetsudnyttelsen af prøveversionen, skal du vælge den relevante betalt efter forbrug-kapacitet til dine PoC'er og derefter flytte til kapacitet, der understøttes af en reservationer eller automatisk skaleringsfakturering. RI er en årelang forpligtelse. En pay-as-you-go-kapacitet kan annulleres når som helst. RI tilbyder omkring 40% rabat sammenlignet med pay-as-you-go-kapacitet.

Scenarie: Kørsel af Spark-arbejdsbelastninger på betalt efter forbrug-kapacitet. Hvad er den optimale kapacitetsmodel at vælge?

Hvis du kører Spark-arbejdsbelastninger på en betalt efter forbrug-kapacitet, kan du overveje at skifte til autoskalering. Autoskalering giver den samme kontraktmæssige fleksibilitet som betalt efter forbrug, men med den fordel, at risikoen for begrænsning fjernes. Job vil dog stå i kø, hvis der ikke er tilstrækkelige ressourcer og til en lavere pris.

Du kan også overveje en hybridmodel, der bruger en reservation til stabile arbejdsbelastninger og autoskalering til mere variable arbejdsbelastninger. Reservationer giver den bedste omkostningsydelse, så længe kapaciteten forbliver godt udnyttet (mere end 75% i gennemsnit i kontraktens løbetid).

Generelt er der ikke mange grunde til, at du måske foretrækker pay-as-you-go frem for de tidligere diskuterede muligheder:

• Du har allerede en pay-as-you-go-kapacitet, der kører ikke-Spark-arbejdsbelastninger, der har flere frihøjde til at køre dine Spark-job – de marginale omkostninger ved at føje endnu et job til en kapacitet er 0 (selvom du kan begrænse dem, hvis du tilføjer for mange). Selv her bør du dog overveje at reservere i et år til en reduceret pris, hvis det er muligt.

• Du har et kortsigtet PoC- eller udviklingsprojekt, hvor omkostningsforudsigelighed er vigtigere end omkostningseffektivitet - med en kapacitet betaler du et fast beløb hver måned. Hvis du overforbruger kapaciteten, bliver du ikke opkrævet mere, i stedet bliver du begrænset. Med Autoskalering bliver du opkrævet for det, du bruger, hvilket kan medføre omkostningsoverskridelser, hvis der køres skadelig kode i dit udviklingsmiljø. For et udviklingsprojekt med et stramt administreret budget kan dette være en værdifuld afvejning.

Sådan optimerer du ressourceforbruget yderligere:

• Du kan køre flere Spark-notesbøger i en enkelt Spark-session med høj samtidighed for at optimere ressourceforbruget.

• Aktivér Native Execution Engine (NEE) for at øge ydeevnen betydeligt.

Scenarie: Du migrerer arbejdsbelastninger fra Azure Synapse til Fabric.

Hvis du migrerer arbejdsbelastninger fra Azure Synapse til Fabric, undrer du dig måske over, hvad der ændres, hvad der forbliver det samme, og om du kan genbruge din eksisterende Synapse-størrelse. 

Migrering og optimering: 

• Brug Azure Synapse to Fabric migrationsværktøjet til at flytte dine arbejdsbelastninger. 

• Aktivér autoskalering af fakturering for Spark. Hvis miljøet og lakehouse er det samme, kør notebooks eller pipelines i høj samtidighedstilstand (en funktion, der ikke er tilgængelig i Synapse) for bedre ydeevne. 

• Profiler notebooks ved hjælp af Native Execution Engine (NEE) for at optimere ydeevnen til dine arbejdsbelastninger. 

Generelle retningslinjer for konfiguration af beregning: 

Relateret indhold

• Oversigt over bedste praksis for Fabric Spark
• Sikkerhed i stof Spark
• Udvikling og overvågning