Prestanda- och justeringsguide för mappning av dataflöden
GÄLLER FÖR: 
Azure Data Factory
Azure Synapse Analytics
Dataflödesmappning i Azure Data Factory och Synapse-pipelines ger ett kodfritt gränssnitt för att utforma och köra datatransformationer i stor skala. Om du inte är bekant med dataflödesmappning kan du gå till Översikt över dataflödesmappning. Den här artikeln beskriver olika sätt att finjustera och optimera dina dataflöden så att de uppfyller prestandatesterna.
Titta på videon nedan för att se några exempel på tidsinställningar för transformering av data med dataflöden.
Övervaka dataflödesprestanda
När du har verifierat din transformeringslogik i felsökningsläge kör du dataflödet från end-to-end som en aktivitet i en pipeline. Dataflöden operationaliseras i en pipeline med hjälp av körningsdataflödesaktiviteten. Dataflödesaktiviteten har en unik övervakningsupplevelse jämfört med andra aktiviteter som visar en detaljerad körningsplan och prestandaprofil för transformeringslogiken. Om du vill visa detaljerad övervakningsinformation för ett dataflöde klickar du på glasögonikonen i aktivitetskörningens utdata för en pipeline. Mer information finns i Övervaka mappning av dataflöden.
När du övervakar dataflödesprestanda finns det fyra möjliga flaskhalsar att hålla reda på:
- Starttid för kluster
- Läsa från en källa
- Transformeringstid
- Skriva till en mottagare
Starttiden för klustret är den tid det tar att starta ett Apache Spark kluster. Det här värdet finns i det övre högra hörnet på övervakningsskärmen. Dataflöden körs på en just-in-time-modell där varje jobb använder ett isolerat kluster. Den här starttiden tar vanligtvis 3–5 minuter. För sekventiella jobb kan detta minskas genom att aktivera ett time to live-värde. Mer information finns i avsnittet Time to live i avsnittet Integration Runtime prestanda.
Dataflöden använder en Spark-optimerare som sorterar om och kör affärslogiken i "steg" för att kunna köras så snabbt som möjligt. För varje mottagare som ditt dataflöde skriver till visar övervakningsutdata varaktigheten för varje transformeringssteg, tillsammans med den tid det tar att skriva data till mottagaren. Den tid som är störst är sannolikt flaskhalsen i ditt dataflöde. Om transformeringsfasen som tar störst innehåller en källa kan du titta på att ytterligare optimera lästiden. Om en transformering tar lång tid kan du behöva partitionera om eller öka storleken på din integreringskörning. Om bearbetningstiden för mottagaren är lång kan du behöva skala upp databasen eller kontrollera att du inte matar ut till en enda fil.
När du har identifierat flaskhalsen i ditt dataflöde använder du optimeringsstrategierna nedan för att förbättra prestandan.
Testa dataflödeslogik
När du utformar och testar dataflöden från användargränssnittet kan du med felsökningsläget interaktivt testa mot ett levande Spark-kluster. På så sätt kan du förhandsgranska data och köra dina dataflöden utan att vänta på att ett kluster ska värmas upp. Mer information finns i Felsökningsläge.
Fliken Optimera
Fliken Optimera innehåller inställningar för att konfigurera partitioneringsschemat för Spark-klustret. Den här fliken finns i varje transformering av dataflödet och anger om du vill partitionera om data efter att transformeringen har slutförts. Genom att justera partitioneringen får du kontroll över distributionen av dina data mellan beräkningsnoder och dataplatser som kan ha både positiva och negativa effekter på den övergripande dataflödesprestandan.
Som standard är Använd aktuell partitionering markerat, vilket instruerar tjänsten att behålla den aktuella utdatapartitioneringen av transformeringen. Eftersom det tar tid att partitionera om data rekommenderar vi att du använder aktuell partitionering i de flesta scenarier. Scenarier där du kanske vill partitionera om dina data inkluderar efter aggregeringar och kopplingar som avsevärt förvränger dina data eller när du använder källpartitionering på en SQL DB.
Om du vill ändra partitioneringen vid en transformering väljer du fliken Optimera och väljer alternativknappen Ange partitionering. Du ser en serie alternativ för partitionering. Den bästa metoden för partitionering skiljer sig beroende på dina datavolymer, kandidatnycklar, null-värden och kardinalitet.
Viktigt
En enda partition kombinerar alla distribuerade data till en enda partition. Det här är en mycket långsam åtgärd som också avsevärt påverkar all nedströmstransformering och skrivningar. Det här alternativet rekommenderas inte såvida det inte finns en uttrycklig affärsorsak till att använda det.
Följande partitioneringsalternativ är tillgängliga i varje transformering:
Resursallokering
Resursallokering distribuerar data jämnt mellan partitioner. Använd resursallokering när du inte har bra kandidater för att implementera en solid strategi för smart partitionering. Du kan ange antalet fysiska partitioner.
Hash
Tjänsten genererar en hash av kolumner för att skapa enhetliga partitioner så att rader med liknande värden hamnar i samma partition. När du använder hash-alternativet ska du testa möjliga partitionsskev. Du kan ange antalet fysiska partitioner.
Dynamiskt intervall
Det dynamiska intervallet använder dynamiska Spark-intervall baserat på de kolumner eller uttryck som du anger. Du kan ange antalet fysiska partitioner.
Fast intervall
Skapa ett uttryck som ger ett fast intervall för värden i dina partitionerade datakolumner. För att undvika partitionsskev partition bör du ha god förståelse för dina data innan du använder det här alternativet. De värden som du anger för uttrycket används som en del av en partitionsfunktion. Du kan ange antalet fysiska partitioner.
Nyckel
Om du har en god förståelse för dina datas kardinalitet kan nyckelpartitionering vara en bra strategi. Nyckelpartitionering skapar partitioner för varje unikt värde i kolumnen. Du kan inte ange antalet partitioner eftersom talet baseras på unika värden i data.
Tips
Genom att manuellt ange partitioneringsschemat balanseras data på ett annat sätt och fördelarna med Spark-optimeraren kan förskjutas. En bra metod är att inte manuellt ange partitionering om du inte behöver göra det.
Loggningsnivå
Om du inte behöver varje pipelinekörning av dina dataflödesaktiviteter för att fullständigt logga alla utförliga telemetriloggar kan du välja att ställa in din loggningsnivå på "Basic" eller "None". När du kör dina dataflöden i "utförligt" läge (standard) begär du att tjänsten fullständigt loggar aktivitet på varje enskild partitionsnivå under datatransformering. Detta kan vara en dyr åtgärd, så att bara aktivera utförlig när felsökning kan förbättra det övergripande dataflödet och pipelineprestandan. Läget "Basic" loggar endast omvandlingens varaktigheter medan "Ingen" endast ger en sammanfattning av varaktigheter.
Nästa steg
Se andra datainformationsartiklar Flow relaterade till prestanda: