Optimera mottagare

När dataflöden skrivs till mottagare sker eventuell anpassad partitionering omedelbart före skrivning. Precis som källan rekommenderar vi i de flesta fall att du behåller Använd aktuell partitionering som det valda partitionsalternativet. Partitionerade data skriver betydligt snabbare än icke-partitionerade data, inte ens målet är partitionerat. Nedan visas de enskilda övervägandena för olika mottagartyper.

Azure SQL Database handfat

Med Azure SQL Database bör standardpartitioneringen fungera i de flesta fall. Det finns en risk att mottagaren har för många partitioner för SQL databas att hantera. Om du stöter på detta minskar du antalet partitioner som matas ut av din SQL Database mottagare.

Bästa praxis för att ta bort rader i mottagare baserat på saknade rader i källan

Här är en video som går igenom hur du använder dataflöden med finns, ändrar rad- och mottagartransformeringar för att uppnå det här vanliga mönstret:

Effekten av felradshantering för prestanda

När du aktiverar hantering av felrader ("fortsätt vid fel") i kanalmottagarens transformering tar tjänsten ytterligare ett steg innan de kompatibla raderna skrivs till måltabellen. Det här ytterligare steget har ett litet prestandastraff som kan vara inom intervallet 5 % som lagts till för det här steget med ytterligare en liten prestandaträff som också läggs till om du anger alternativet att även skriva de inkompatibla raderna till en loggfil.

Inaktivera index med hjälp av ett SQL-skript

Om du inaktiverar index före en inläsning i en SQL databas kan det avsevärt förbättra prestanda vid skrivning till tabellen. Kör kommandot nedan innan du skriver till din SQL mottagare.

ALTER INDEX ALL ON dbo.[Table Name] DISABLE

När skrivning har slutförts återskapar du indexen med följande kommando:

ALTER INDEX ALL ON dbo.[Table Name] REBUILD

Dessa kan både göras internt med hjälp av pre- och SQL-skript i en Azure SQL DB- eller Synapse-mottagare i mappning av dataflöden.

Disable indexes

Varning

När du inaktiverar index tar dataflödet effektivt kontroll över en databas och frågorna kommer sannolikt inte att lyckas just nu. Därför utlöses många ETL-jobb mitt i natten för att undvika den här konflikten. Mer information finns i avsnittet om begränsningar för inaktivering av SQL index

Skala upp databasen

Schemalägg en storleksändring av källan och mottagaren Azure SQL DB och DW innan pipelinekörningen för att öka dataflödet och minimera Azure-begränsningen när du når DTU-gränserna. När pipelinekörningen är klar ändrar du storlek på databaserna till den normala körningshastigheten.

Azure Synapse Analytics-mottagare

När du skriver till Azure Synapse Analytics kontrollerar du att Aktivera mellanlagring är inställt på sant. På så sätt kan tjänsten skriva med hjälp av kommandot SQL COPY som läser in data massvis. Du måste referera till ett Azure Data Lake Storage gen2- eller Azure Blob Storage-konto för mellanlagring av data när du använder mellanlagring.

Förutom Mellanlagring gäller samma metodtips för Azure Synapse Analytics som Azure SQL Database.

Filbaserade mottagare

Dataflöden stöder en mängd olika filtyper, men Det Spark-inbyggda Parquet-formatet rekommenderas för optimala läs- och skrivtider.

Om data är jämnt fördelade är Använd aktuell partitionering det snabbaste partitioneringsalternativet för att skriva filer.

Filnamnsalternativ

När du skriver filer kan du välja namnalternativ som var och en har en prestandapåverkan.

Sink options

Om du väljer alternativet Standard skrivs det snabbaste. Varje partition motsvarar en fil med Spark-standardnamnet. Detta är användbart om du bara läser från mappen med data.

Om du anger ett namngivningsmönster får varje partitionsfil ett mer användarvänligt namn. Den här åtgärden utförs efter skrivning och är något långsammare än när du väljer standardinställningen.

Per partition kan du namnge varje enskild partition manuellt.

Om en kolumn motsvarar hur du vill mata ut data kan du välja Namnfil som kolumndata. Detta omdelar data och kan påverka prestanda om kolumnerna inte är jämnt fördelade.

Om en kolumn motsvarar hur du vill generera mappnamn väljer du Namnmapp som kolumndata.

Utdata till en enskild fil kombinerar alla data till en enda partition. Detta leder till långa skrivtider, särskilt för stora datamängder. Det här alternativet rekommenderas inte om det inte finns en uttrycklig affärsorsak att använda det.

Azure Cosmos DB-mottagare

När du skriver till Azure Cosmos DB kan du förbättra prestandan genom att ändra dataflöde och batchstorlek under dataflödeskörningen. Dessa ändringar börjar bara gälla under körningen av dataflödesaktiviteten och återgår till de ursprungliga samlingsinställningarna efter avslutningen.

Batchstorlek: Vanligtvis räcker det att börja med standard batchstorleken. Om du vill justera det här värdet ytterligare beräknar du den ungefärliga objektstorleken för dina data och kontrollerar att objektstorleken * batchstorleken är mindre än 2 MB. I så fall kan du öka batchstorleken för att få bättre dataflöde.

Genomströmning: Ange en inställning för högre dataflöde här så att dokument kan skriva snabbare till Azure Cosmos DB. Tänk på de högre RU-kostnaderna baserat på en inställning för högt dataflöde.

Skriv dataflödesbudget: Använd ett värde som är mindre än totalt antal RU:er per minut. Om du har ett dataflöde med ett stort antal Spark-partitioner ger ett budgetgenomflöde mer balans mellan dessa partitioner.

Nästa steg

Se andra Dataflöde artiklar om prestanda: