Optimera prestanda för Azure Integration Runtime
Dataflöden körs på Spark-kluster som spunnits upp vid körning. Konfigurationen för det kluster som används definieras i aktivitetens integreringskörning (IR). Det finns tre saker att tänka på när du definierar din integreringskörning: klustertyp, klusterstorlek och tid att leva.
Mer information om hur du skapar en integrationskörning finns i Integration Runtime.
Det enklaste sättet att komma igång med dataflödesintegreringskörningar är att välja liten, medel eller stor från väljaren för beräkningsstorlek. Se mappningar till klusterkonfigurationer för dessa storlekar nedan.
Klusterstorlek
Dataflöden distribuerar databehandlingen över olika kärnor i ett Spark-kluster för att utföra åtgärder parallellt. Ett Spark-kluster med fler kärnor ökar antalet kärnor i beräkningsmiljön. Fler kärnor ökar dataflödets bearbetningskraft. Att öka storleken på klustret är ofta ett enkelt sätt att minska bearbetningstiden.
Standardklusterstorleken är fyra drivrutinskärnor och fyra arbetskärnor (små). När du bearbetar mer data rekommenderas större kluster. Nedan visas möjliga storleksalternativ:
| Arbetskärnor | Drivrutinskärnor | Totalt antal kärnor | Kommentar |
|---|---|---|---|
| 4 | 4 | 8 | Litet |
| 8 | 8 | 16 | Medel |
| 16 | 16 | 32 | Stort |
| 32 | 16 | 48 | |
| 64 | 16 | 80 | |
| 128 | 16 | 144 | |
| 256 | 16 | 272 |
Dataflöden prissätts till virtuella kärnor, vilket innebär att både klusterstorlek och körningstidsfaktor ingår i detta. När du skalar upp ökar klusterkostnaden per minut, men den totala tiden minskar.
Dricks
Det finns ett tak för hur mycket storleken på ett kluster påverkar prestanda för ett dataflöde. Beroende på storleken på dina data finns det en punkt där en ökning av storleken på ett kluster slutar att förbättra prestandan. Om du till exempel har fler kärnor än partitioner av data hjälper det inte att lägga till ytterligare kärnor. En bra idé är att börja små och skala upp för att uppfylla dina prestandabehov.
Anpassad shuffle-partition
Dataflödet delar upp data i partitioner och transformerar dem med hjälp av olika processer. Om datastorleken i en partition är mer än vad processen kan lagra i minnet misslyckas processen med OOM-fel (slut på minne). Om dataflödet innehåller stora mängder data som har kopplingar/aggregeringar kanske du vill prova att ändra shuffle-partitioner på ett inkrementellt sätt. Du kan ange den från 50 till 2000 för att undvika OOM-fel. Beräkningsanpassade egenskaper i dataflödeskörning är ett sätt att styra dina beräkningskrav. Egenskapsnamnet är Shuffle-partitioner och är heltalstyp. Den här anpassningen bör endast användas i kända scenarier, annars kan det orsaka onödiga dataflödesfel.
När du ökar shuffle-partitionerna kontrollerar du att data är spridda över väl. Ett grovt tal är att ha cirka 1,5 GB data per partition. Om data är skeva är det inte bra att öka "Shuffle-partitionerna". Om du till exempel har 500 GB data bör ett värde mellan 400 och 500 fungera. Standardgränsen för shuffle-partitioner är 200 vilket fungerar bra för cirka 300 GB data.
- Från ADF-portalen under Hantera väljer du en anpassad integrationskörningstid och går till redigeringsläge.
- Under fliken körningstid för dataflöde går du till avsnittet Beräkning av anpassade egenskaper .
- Välj Blanda partitioner under Egenskapsnamn , valfritt indatavärde, t.ex. 250, 500 osv.
Du kan göra samma sak genom att redigera JSON-filen med körning genom att lägga till en matris med egenskapsnamn och värde efter en befintlig egenskap som rensningsegenskap .
Time to live
Som standard startar varje dataflödesaktivitet ett nytt Spark-kluster baserat på Azure IR-konfigurationen. Starttiden för kalla kluster tar några minuter och databehandlingen kan inte starta förrän den är klar. Om dina pipelines innehåller flera sekventiella dataflöden kan du aktivera ett TTL-värde (time to live). Om du anger ett time to live-värde hålls ett kluster vid liv under en viss tid efter att körningen har slutförts. Om ett nytt jobb börjar använda IR under TTL-tiden återanvänds det befintliga klustret och starttiden minskas avsevärt. När det andra jobbet har slutförts kommer klustret återigen att hålla sig vid liv under TTL-tiden.
Men om de flesta av dina dataflöden körs parallellt rekommenderar vi inte att du aktiverar TTL för den IR som du använder för dessa aktiviteter. Endast ett jobb kan köras på ett enda kluster i taget. Om det finns ett tillgängligt kluster, men två dataflöden startar, kommer endast ett att använda det aktiva klustret. Det andra jobbet startar ett eget isolerat kluster.
Kommentar
Time to live är inte tillgängligt när du använder integrationskörningen för automatisk lösning (standard).
Relaterat innehåll
Se andra Dataflöde artiklar om prestanda: