Apache Spark-poolkonfigurationer i Azure Synapse Analytics
En Spark-pool är en uppsättning metadata som definierar beräkningsresurskraven och tillhörande beteendeegenskaper när en Spark-instans instans instansieras. Dessa egenskaper omfattar men är inte begränsade till namn, antal noder, nodstorlek, skalningsbeteende och time to live. En Spark-pool i sig förbrukar inga resurser. Det tillkommer inga kostnader för att skapa Spark-pooler. Avgifter tillkommer bara när ett Spark-jobb körs på Spark-målpoolen och Spark-instansen instansieras på begäran.
Du kan läsa om hur du skapar en Spark-pool och ser alla deras egenskaper här Kom igång med Spark-pooler i Synapse Analytics
Isolerad beräkning
Alternativet Isolerad beräkning ger större säkerhet för Spark-beräkningsresurser från ej betrodda tjänster genom att dedikera den fysiska beräkningsresursen till en enda kund. Alternativet isolerad beräkning passar bäst för arbetsbelastningar som kräver en hög grad av isolering från andra kunders arbetsbelastningar av orsaker som omfattar att uppfylla efterlevnads- och regelkrav. Alternativet Isolera beräkning är endast tillgängligt med nodstorleken XXXLarge (80 vCPU/504 GB) och är endast tillgängligt i följande regioner. Det isolerade beräkningsalternativet kan aktiveras eller inaktiveras när poolen har skapats, även om instansen kan behöva startas om. Om du förväntar dig att aktivera den här funktionen i framtiden kontrollerar du att din Synapse-arbetsyta skapas i en isolerad beräkningsregion som stöds.
- East US
- USA, västra 2
- USA, södra centrala
- US Gov, Arizona
- US Gov, Virginia
Noder
Apache Spark-poolinstansen består av en huvudnod och två eller flera arbetsnoder med minst tre noder i en Spark-instans. Huvudnoden kör extra hanteringstjänster som Livy, Yarn Resource Manager, Zookeeper och Spark-drivrutinen. Alla noder kör tjänster som Node Agent och Yarn Node Manager. Alla arbetsnoder kör Spark Executor-tjänsten.
Nodstorlekar
En Spark-pool kan definieras med nodstorlekar som sträcker sig från en liten beräkningsnod med 4 virtuella kärnor och 32 GB minne upp till en XXLarge-beräkningsnod med 64 virtuella kärnor och 432 GB minne per nod. Nodstorlekar kan ändras när poolen har skapats, även om instansen kan behöva startas om.
| Storlek | V-kärna | Minne |
|---|---|---|
| Liten | 4 | 32 GB |
| Medel | 8 | 64 GB |
| Stor | 16 | 128 GB |
| XLarge | 32 | 256 GB |
| XXLarge | 64 | 432 GB |
| XXX Stor (isolerad beräkning) | 80 | 504 GB |
Automatisk skalning
Med autoskalning för Apache Spark-pooler kan du automatiskt skala upp och ned beräkningsresurser baserat på mängden aktivitet. När autoskalningsfunktionen är aktiverad anger du det lägsta och högsta antalet noder som ska skalas. När autoskalningsfunktionen är inaktiverad förblir antalet noder fasta. Den här inställningen kan ändras när poolen har skapats, även om instansen kan behöva startas om.
Elastisk poollagring
Apache Spark-pooler stöder nu elastisk poollagring. Med elastisk poollagring kan Spark-motorn övervaka tillfällig lagring av arbetsnoder och ansluta extra diskar om det behövs. Apache Spark-pooler använder tillfällig disklagring medan poolen instansieras. Spark-jobb skriver shuffle map-utdata, blanda data och spillda data till lokala VM-diskar. Exempel på åtgärder som kan använda lokala diskar är sortering, cachelagring och beständighet. När det tillfälliga diskutrymmet på den virtuella datorn tar slut kan Spark-jobb misslyckas på grund av felet "Slut på diskutrymme" (java.io.IOException: Inget utrymme kvar på enheten). Med fel om "slut på diskutrymme" är mycket av arbetet med att förhindra att jobb misslyckas skift till kunden för att konfigurera om Spark-jobben (till exempel justera antalet partitioner) eller kluster (till exempel lägga till fler noder i klustret). De här felen kanske inte är konsekventa och det kan hända att användaren experimenterar mycket genom att köra produktionsjobb. Den här processen kan vara dyr för användaren i flera dimensioner:
- Bortkastad tid. Kunder måste experimentera mycket med jobbkonfigurationer via utvärdering och fel och förväntas förstå Sparks interna mått för att fatta rätt beslut.
- Resurser som har slösats bort. Eftersom produktionsjobb kan bearbeta varierande datamängder kan Spark-jobb misslyckas icke-deterministiskt om resurserna inte överetablerad. Tänk till exempel på problemet med datasnedställning, vilket kan leda till att några noder kräver mer diskutrymme än andra. För närvarande i Synapse får varje nod i ett kluster samma storlek på diskutrymmet och att öka diskutrymmet över alla noder är inte en idealisk lösning och leder till enormt slöseri.
- Långsammare jobbkörning. I det hypotetiska scenariot där vi löser problemet genom automatisk skalning av noder (förutsatt att kostnaderna inte är ett problem för slutkunden) är det fortfarande dyrt att lägga till en beräkningsnod (tar några minuter) i stället för att lägga till lagring (tar några sekunder).
Ingen åtgärd krävs av dig, plus att du bör se färre jobbfel som ett resultat.
Anteckning
Azure Synapse Elastic Pool Storage finns för närvarande i offentlig förhandsversion. Under den allmänt tillgängliga förhandsversionen debiteras du inte för användning av elastisk poollagring.
Automatisk paus
Funktionen för automatisk paus släpper resurser efter en viss inaktivitetsperiod, vilket minskar den totala kostnaden för en Apache Spark-pool. Antalet minuter av inaktivitetstid kan anges när den här funktionen är aktiverad. Funktionen för automatisk paus är oberoende av autoskalningsfunktionen. Resurser kan pausas oavsett om autoskalningen är aktiverad eller inaktiverad. Den här inställningen kan ändras när poolen har skapats, även om aktiva sessioner måste startas om.