Felsöka prestandaflaskhalsar i Azure Databricks

Den här artikeln beskriver hur du använder instrumentpaneler för övervakning för att hitta flaskhalsar för prestanda i Spark-jobb Azure Databricks.

Azure Databricks är en Apache Spark-baserad analystjänst som gör det enkelt att snabbt utveckla och distribuera stordataanalys. Övervakning och felsökning av prestandaproblem är en viktig faktor när du Azure Databricks produktionsarbetsbelastningar. För att identifiera vanliga prestandaproblem är det bra att använda övervakningsvisualiseringar baserat på telemetridata.

Förutsättningar

Konfigurera Grafana-instrumentpanelerna som visas i den här artikeln:

• Konfigurera Databricks-klustret så att det skickar telemetri till en Log Analytics-arbetsyta med Azure Databricks Monitoring Library. Mer information finns i GitHub readme.

• Distribuera Grafana på en virtuell dator. Se Använda instrumentpaneler för att Azure Databricks mått.

Grafana-instrumentpanelen som distribueras innehåller en uppsättning tidsserievisualiseringar. Varje diagram är tidsseriediagram över mått som är relaterade Apache Spark jobb, jobbfaserna och uppgifter som utgör varje fas.

Azure Databricks prestandaöversikt

Azure Databricks baseras Apache Spark, ett distribuerat databehandlingssystem för generell användning. Programkoden, som kallas ett jobb,körs på ett Apache Spark kluster, samordnat av klusterhanteraren. I allmänhet är ett jobb den högsta beräkningsenheten. Ett jobb representerar den fullständiga åtgärd som utförs av Spark-programmet. En typisk åtgärd är att läsa data från en källa, tillämpa datatransformering och skriva resultaten till lagring eller ett annat mål.

Jobben är uppdelade i faser. Jobbet går framåt i stegen sekventiellt, vilket innebär att senare steg måste vänta tills tidigare steg har slutförts. Faser innehåller grupper med identiska uppgifter som kan köras parallellt på flera noder i Spark-klustret. Uppgifter är den mest detaljerade körningsenheten som sker på en delmängd av data.

I nästa avsnitt beskrivs några visualiseringar av instrumentpaneler som är användbara för prestandafelsökning.

Jobb- och fasfördröjning

Jobbets svarstid är varaktigheten för en jobbkörning från när den startar tills den har slutförts. Den visas som percentiler av en jobbkörning per kluster och program-ID, för att tillåta visualisering av avvikande värden. Följande diagram visar en jobbhistorik där den 90:e percentilen nådde 50 sekunder, även om den 50:e percentilen konsekvent var cirka 10 sekunder.

Undersök jobbkörningen efter kluster och program och leta efter toppar i svarstiden. När kluster och program med lång svarstid identifieras går du vidare för att undersöka fasfördröjningen.

Fasfördröjning visas också som percentiler för att tillåta visualisering av avvikande värden. Fasfördröjningen delas upp efter kluster, program och fasnamn. Identifiera toppar i aktivitetsfördröjningen i diagrammet för att avgöra vilka uppgifter som håller tillbaka slutförandet av fasen.

Diagrammet med klustergenomflöde visar antalet jobb, faser och uppgifter som har slutförts per minut. Detta hjälper dig att förstå arbetsbelastningen när det gäller det relativa antalet faser och uppgifter per jobb. Här kan du se att antalet jobb per minut sträcker sig mellan 2 och 6, medan antalet faser är cirka 12–24 per minut.

Summa av svarstid för uppgiftskörning

Den här visualiseringen visar summan av svarstiden för uppgiftskörning per värd som körs i ett kluster. Använd det här diagrammet för att identifiera aktiviteter som körs långsamt på grund av att värden blir långsammare i ett kluster eller på grund av en felallokering av uppgifter per utförare. I följande diagram har de flesta värdar en summa på cirka 30 sekunder. Två av värdarna har dock summor som hovrar runt 10 minuter. Antingen körs värdarna långsamt eller så är antalet uppgifter per utförare felallokerat.

Antalet uppgifter per utförare visar att två utförare tilldelas ett oproportionerlig antal uppgifter, vilket orsakar en flaskhals.

Uppgiftsmått per fas

Visualiseringen för uppgiftsmått ger kostnadsuppdelning för en uppgiftskörning. Du kan använda den för att se den relativa tid som ägnats åt aktiviteter som serialisering och deserialisering. Dessa data kan visa möjligheter att optimera , till exempel genom att använda broadcast-variabler för att undvika leveransdata. Uppgiftsmåtten visar även shuffle-datastorleken för en uppgift och shuffle-läs- och skrivtiderna. Om dessa värden är höga innebär det att mycket data flyttas över nätverket.

Ett annat uppgiftsmått är schemaläggarfördröjningen, som mäter hur lång tid det tar att schemalägga en aktivitet. Vi rekommenderar att det här värdet är lågt jämfört med körningens beräkningstid, vilket är den tid som faktiskt ägnats åt att köra uppgiften.

I följande diagram visas en tidsfördröjning för schemaläggaren (3,7 s) som överskrider körningens beräkningstid (1,1 s). Det innebär att mer tid läggs på att vänta på att aktiviteter schemaläggs än att utföra det faktiska arbetet.

I det här fallet orsakades problemet av att det fanns för många partitioner, vilket orsakade mycket omkostnader. Genom att minska antalet partitioner sänks tidsfördröjningen för schemaläggaren. I nästa diagram ser du att den största delen av tiden ägnats åt att köra uppgiften.

Strömmande dataflöde och svarstid

Dataflödet för direktuppspelning är direkt relaterat till strukturerad strömning. Det finns två viktiga mått som är associerade med strömmande dataflöde: Indatarader per sekund och bearbetade rader per sekund. Om indatarader per sekund överträffar bearbetade rader per sekund innebär det att dataströmbearbetningssystemet ligger efter. Om indata kommer från Event Hubs kafka bör indatarader per sekund dessutom hålla takten med datainmatningshastigheten i frontend.

Två jobb kan ha liknande klusterdataflöde men mycket olika strömningsmått. Följande skärmbild visar två olika arbetsbelastningar. De liknar klusterflödet (jobb, faser och aktiviteter per minut). Men den andra körningen bearbetar 12 000 rader/sek jämfört med 4 000 rader/sek.

Strömmande dataflöde är ofta ett bättre affärsmått än klusterdataflöde, eftersom det mäter antalet dataposter som bearbetas.

Resursförbrukning per utförare

De här måtten hjälper till att förstå det arbete som varje utförare utför.

Procentmått mäter hur lång tid en utförare lägger på olika saker, uttryckt som ett förhållande mellan den tid som spenderas och den övergripande beräkningstiden för utföraren. Måtten är:

• % serialiseringstid
• % deserialiseringstid
• % CPU-körtid
• % JVM-tid

Dessa visualiseringar visar hur mycket var och en av dessa mått bidrar till övergripande körbearbetning.

Shuffle-mått är mått som är relaterade till data som blandas mellan utförare.

• Blanda I/O
• Blanda minne
• Filsystemsanvändning
• Diskanvändning

Vanliga prestandaflaskhalsar

Två vanliga prestandaflaskhalsar i Spark är uppgifts stragglers och ett icke-optimalt blandningspartitionsantal.

Uppgifts stragglers

Stegen i ett jobb körs sekventiellt, och tidigare steg blockerar senare steg. Om en uppgift kör en shuffle-partition långsammare än andra uppgifter måste alla aktiviteter i klustret vänta tills den långsamma uppgiften hinner ikapp innan fasen kan avslutas. Detta kan inträffa av följande skäl:

1. En värd eller grupp med värdar körs långsamt. Symptom: Hög aktivitets-, fas- eller jobbsvarstid och lågt klustergenomflöde. Sammanfattningen av aktiviteternas svarstider per värd fördelas inte jämnt. Resursförbrukningen fördelas dock jämnt mellan utförare.

2. Uppgifter har en dyr aggregering att köra (dataskev. Symptom: Hög uppgiftsfördröjning, lång fördröjning i fasen, hög jobbsvarstid eller lågt klustergenomflöde, men sammanfattningen av svarstider per värd är jämnt fördelad. Resursförbrukningen fördelas jämnt mellan utförare.

3. Om partitionerna är ojämna kan en större partition orsaka obalanserad uppgiftskörning (partitionsskevhet). Symptom: Förbrukningen av körresurser är hög jämfört med andra utförare som körs i klustret. Alla uppgifter som körs på den utföraren körs långsamt och håller faskörningen i pipelinen. Dessa steg sägs vara fasbarriärer.

Icke-optimalt antal shuffle-partitioner

Under en strukturerad direktuppspelningsfråga är tilldelningen av en uppgift till en utförare en resursintensiv åtgärd för klustret. Om shuffle-data inte har den optimala storleken påverkar fördröjningen för en aktivitet dataflödet och svarstiden negativt. Om det finns för få partitioner kommer kärnorna i klustret att underutnyttjas, vilket kan leda till ineffektivitet i bearbetningen. Om det däremot finns för många partitioner, så finns det en stor mängd hanteringskostnader för ett litet antal uppgifter.

Använd måtten för resursförbrukning för att felsöka partitionssneddelning och felaktig placering av utförare i klustret. Om en partition är skev höjs körningsresurserna i jämförelse med andra utförare som körs i klustret.

Följande diagram visar till exempel att det minne som används genom att blanda de två första utförarna är 90 gånger större än de andra utförarna: