Åtgärda långa initieringstider i pipelineprocesser

Pipelines kan innehålla många datauppsättningar med många flöden för att hålla dem uppdaterade. Pipelines hanterar automatiskt uppdateringar och kluster för att uppdatera effektivt. Det finns dock vissa kostnader för att hantera ett stort antal flöden, och ibland kan detta leda till större initiering än förväntat eller till och med hanteringskostnader under bearbetningen.

Om du stöter på fördröjningar som väntar på att utlösta pipelines ska initieras, till exempel initieringstider under fem minuter, kan du överväga att dela upp bearbetningen i flera pipelines, även när datauppsättningarna använder samma källdata.

Anmärkning

Utlösta pipelines utför initieringsstegen varje gång de utlöses. Kontinuerliga pipelines utför endast initieringsstegen när de stoppas och startas om. Det här avsnittet är mest användbart för att optimera initieringen av en utlösad pipeline.

När du ska överväga att dela en pipeline

Det finns flera fall där det kan vara fördelaktigt att dela en pipeline av prestandaskäl.

• Faserna INITIALIZING och SETTING_UP_TABLES tar längre tid än du vill, vilket påverkar den totala pipelinetiden. Om detta tar över 5 minuter förbättras det ofta genom att din pipeline delas upp.
• Drivrutinen som hanterar klustret kan bli en flaskhals när man kör många (mer än 30–40) strömmande tabeller i en enda pipeline. Om drivrutinen inte svarar, kommer varaktigheterna för strömmande förfrågningar att öka, vilket påverkar den totala tiden för uppdateringen.
• En utlöst pipeline med flera strömmande tabellflöden kanske inte kan utföra alla parallelliserbara strömuppdateringar parallellt.

Information om prestandaproblem

I det här avsnittet beskrivs några av de prestandaproblem som kan uppstå vid många tabeller och flöden i en enda pipeline.

Flaskhalsar i faserna INITIERING och UPPSÄTTNING_AV_TABELLER

De inledande faserna i körningen kan vara en flaskhals för prestanda, beroende på pipelinens komplexitet.

INITIERINGsfas

Under den här fasen skapas logiska planer, inklusive planer för att skapa beroendediagrammet och bestämma ordningen på tabelluppdateringar.

SETTING_UP_TABLES-fasen

Under den här fasen utförs följande processer baserat på de planer som skapades i föregående fas:

• Schemaverifiering och lösning för alla tabeller som definierats i pipelinen.
• Skapa beroendediagrammet och bestämma ordningen på tabellkörningen.
• Kontrollera om varje datauppsättning är aktiv i pipelinen eller är ny sedan en tidigare uppdatering.
• Skapa strömmande tabeller i den första uppdateringen och för materialiserade vyer skapar du tillfälliga vyer eller säkerhetskopieringstabeller som krävs under varje pipelineuppdatering.

Varför initialisering och ställa in tabeller kan ta längre tid

Stora pipelines med många flöden för många datauppsättningar kan ta längre tid av flera orsaker:

• För pipelines med många flöden och komplexa beroenden kan dessa faser ta längre tid på grund av mängden arbete som ska utföras.
• Komplexa omvandlingar, inklusive Auto CDC transformeringar, kan orsaka en flaskhals för prestanda på grund av de åtgärder som krävs för att materialisera tabellerna baserat på de definierade omvandlingarna.
• Det finns också scenarier där ett stort antal flöden kan orsaka långsamhet, även om dessa flöden inte ingår i en uppdatering. Tänk dig till exempel en pipeline som har över 700 flöden, varav färre än 50 uppdateras för varje utlösare, baserat på en konfiguration. I det här exemplet måste varje körning gå igenom några av stegen för alla 700 tabeller, hämta dataramarna och sedan välja de som ska köras.

Flaskhalsar i föraren

Drivrutinen hanterar uppdateringarna inom processen. Den måste köra viss logik för varje tabell för att avgöra vilka instanser i ett kluster som ska hantera varje flöde. När du kör flera (mer än 30–40) strömmande tabeller i en enda pipeline kan drivrutinen bli en flaskhals för CPU-resurser när den hanterar arbetet i klustret.

Drivrutinen kan också stöta på minnesproblem. Detta kan inträffa oftare när antalet parallella flöden är 30 eller mer. Det finns inte ett specifikt antal flöden eller datauppsättningar som kan orsaka problem med drivrutinsminnet, men som beror på komplexiteten i de uppgifter som körs parallellt.

Strömningsflöden kan köras parallellt, men detta kräver att drivrutinen använder minne och CPU för alla strömmar samtidigt. I en utlöst pipeline kan drivrutinen bearbeta en delmängd strömmar parallellt i taget för att undvika minnes- och CPU-begränsningar.

I alla dessa fall kan delning av pipelines så att det finns en optimal uppsättning flöden i var och en påskynda initierings- och bearbetningstiden.

Kompromisser med att dela upp pipelines

När alla dina flöden är inom samma pipeline hanterar Lakeflow Spark Deklarativa Pipelines beroenden åt dig. När det finns flera pipelines måste du hantera beroendena mellan pipelines.

• Beroenden Du kan ha en nedströms-pipeline som är beroende av flera uppströms-pipelines (i stället för en). Om du till exempel har tre pipelines, pipeline_A, pipeline_B och pipeline_C, och pipeline_C är beroende av både pipeline_A och pipeline_B, vill du att pipeline_C uppdateras först efter att både pipeline_A och pipeline_B har slutfört sina respektive uppdateringar. Ett sätt att åtgärda detta är att samordna beroendena genom att göra varje pipeline till en uppgift i ett jobb med beroendena korrekt modellerade, så att pipeline_C endast uppdateras när både pipeline_A och pipeline_B är klara.

• Samtidighet Du kan ha olika flöden i en pipeline som tar mycket olika tid att slutföra, till exempel om flow_A uppdateringar på 15 sekunder och flow_B tar flera minuter. Det kan vara bra att titta på frågetiderna innan du delar dina pipelines och gruppera kortare frågor tillsammans.

Planera att dela upp dina pipelines

Du kan visualisera pipelinedelningen innan du börjar. Här är ett diagram över en källpipeline som bearbetar 25 tabeller. En enskild rotdatakälla är uppdelad i 8 segment, där var och en har 2 vyer.

När pipelinen har delats upp finns det två pipelines. En bearbetar den enskilda rotdatakällan och 4 segment och associerade vyer. Den andra pipelinen bearbetar de övriga 4 segmenten och deras associerade vyer. Den andra pipelinen förlitar sig på den första för att uppdatera rotdatakällan.

Dela pipelinen utan fullständig uppdatering

När du har planerat din pipelinedelning, skapar du de nya pipelines som behövs och flyttar tabeller mellan pipelines för att balansera belastningen i pipelinen. Du kan flytta tabeller utan att orsaka en fullständig uppdatering.

Mer information finns i Flytta tabeller mellan pipelines.

Det finns vissa begränsningar med den här metoden:

• Pipelines måste finnas i Unity-katalogen.
• Käll- och målpipelines måste finnas på samma arbetsyta. Flyttningar mellan arbetsytor stöds inte.
• Målpipelinen måste skapas och köras en gång (även om den misslyckas) före flytten.
• Du kan inte flytta en tabell från en pipeline som använder standardpubliceringsläget till en som använder det äldre publiceringsläget. Mer information finns i LIVE-schema (äldre).