Observerbarhetsmönster och mått för prestandajustering

Den här lösningen visar observerbarhetsmönster och mått för att förbättra bearbetningsprestandan för ett stordatasystem som använder Azure Databricks.

Arkitektur

Ladda ned en Visio-fil med den här arkitekturen.

Arbetsflöde

Lösningen omfattar följande steg:

1. Servern skickar en stor GZIP-fil som grupperas efter kund till källmappen i Azure Data Lake Storage (ADLS).

2. ADLS skickar sedan en extraherad kundfil till Azure Event Grid, som omvandlar kundfildata till flera meddelanden.

3. Azure Event Grid skickar meddelandena till Azure Queue Storage-tjänsten, som lagrar dem i en kö.

4. Azure Queue Storage skickar kön till Azure Databricks-dataanalysplattformen för bearbetning.

5. Azure Databricks packar upp och bearbetar ködata till en bearbetad fil som skickas tillbaka till ADLS:

   1. Om den bearbetade filen är giltig hamnar den i mappen Landning .

   2. Annars hamnar filen i mappträdet Felaktig . Inledningsvis hamnar filen i undermappen Försök igen och ADLS försöker bearbeta kundfilen igen (steg 2). Om ett par återförsök fortfarande leder till att Azure Databricks returnerar bearbetade filer som inte är giltiga, hamnar den bearbetade filen i undermappen Fel .

6. När Azure Databricks packar upp och bearbetar data i föregående steg skickar det även programloggar och mått till Azure Monitor för lagring.

7. En Azure Log Analytics-arbetsyta tillämpar Kusto-frågor i programloggarna och måtten från Azure Monitor för felsökning och djupdiagnostik.

Komponenter

• Azure Data Lake Storage är en uppsättning funktioner som är dedikerade till stordataanalys.
• Med Azure Event Grid kan utvecklare enkelt skapa program med händelsebaserade arkitekturer.
• Azure Queue Storage är en tjänst för att lagra ett stort antal meddelanden. Det ger åtkomst till meddelanden var som helst i världen via autentiserade anrop med HTTP eller HTTPS. Du kan använda köer för att skapa en kvarvarande arbetslogg för att bearbeta asynkront.
• Azure Databricks är en dataanalysplattform som är optimerad för Azure-molnplattformen. En av de två miljöer som Azure Databricks erbjuder för att utveckla dataintensiva program är Azure Databricks Workspace, en Apache Spark-baserad enhetlig analysmotor för storskalig databearbetning.
• Azure Monitor samlar in och analyserar apptelemetri, till exempel prestandamått och aktivitetsloggar.
• Azure Log Analytics är ett verktyg som används för att redigera och köra loggfrågor med data.

Information om scenario

Utvecklingsteamet kan använda observerbarhetsmönster och mått för att hitta flaskhalsar och förbättra prestandan för ett stordatasystem. Ditt team måste utföra belastningstestning av en högvolymström med mått i ett storskaligt program.

Det här scenariot ger vägledning för prestandajustering. Eftersom scenariot utgör en prestandautmaning för loggning per kund använder det Azure Databricks, som kan övervaka dessa objekt på ett robust sätt:

• Anpassade programmått
• Strömmande frågehändelser
• Programloggmeddelanden

Azure Databricks kan skicka dessa övervakningsdata till olika loggningstjänster, till exempel Azure Log Analytics.

Det här scenariot beskriver inmatningen av en stor uppsättning data som har grupperats av kunden och lagrats i en GZIP-arkivfil. Detaljerade loggar är inte tillgängliga från Azure Databricks utanför Apache Spark-användargränssnittet™ i realtid, så ditt team behöver ett sätt att lagra alla data för varje kund och sedan jämföra och jämföra dem. Med ett scenario med stora data är det viktigt att hitta en optimal kombinationskörningspool och vm-storlek (vm) för den snabbaste bearbetningstiden. I det här affärsscenariot förlitar sig det övergripande programmet på hastigheten för inmatnings- och frågekrav, så att systemets dataflöde inte försämras oväntat med ökad arbetsvolym. Scenariot måste garantera att systemet uppfyller serviceavtal (SLA) som upprättas med dina kunder.

Potentiella användningsfall

Scenarier som kan dra nytta av den här lösningen är:

• Övervakning av systemhälsa.
• Prestandaunderhåll.
• Övervaka den dagliga systemanvändningen.
• Upptäcka trender som kan orsaka framtida problem om de inte åtgärdas.

Att tänka på

Dessa överväganden implementerar grundpelarna i Azure Well-Architected Framework, som är en uppsättning vägledande grundsatser som kan användas för att förbättra kvaliteten på en arbetsbelastning. Mer information finns i Microsoft Azure Well-Architected Framework.

Tänk på följande när du överväger den här arkitekturen:

• Azure Databricks kan automatiskt allokera de databehandlingsresurser som krävs för ett stort jobb, vilket undviker problem som andra lösningar introducerar. Med Databricks-optimerad autoskalning på Apache Spark kan överdriven etablering till exempel orsaka en suboptimal användning av resurser. Eller så kanske du inte känner till antalet utförare som krävs för ett jobb.

• Ett kömeddelande i Azure Queue Storage kan vara upp till 64 kB stort. En kö kan innehålla miljontals kömeddelanden, upp till den totala kapacitetsgränsen för ett lagringskonto.

Kostnadsoptimering

Kostnadsoptimering handlar om att titta på sätt att minska onödiga utgifter och förbättra drifteffektiviteten. Mer information finns i Översikt över kostnadsoptimeringspelare.

Använd Priskalkylatorn för Azure för att beräkna kostnaden för att implementera den här lösningen.

Distribuera det här scenariot

Om du vill hämta alla loggar och information om processen konfigurerar du Azure Log Analytics och Azure Databricks-övervakningsbiblioteket. Övervakningsbiblioteket strömmar händelser på Apache Spark-nivå och Spark Structured Streaming-mått från dina jobb till Azure Monitor. Du behöver inte göra några ändringar i programkoden för dessa händelser och mått.

Stegen för att konfigurera prestandajustering för ett stordatasystem är följande:

1. Skapa en Azure Databricks-arbetsyta i Azure-portalen. Kopiera och spara Azure-prenumerations-ID (en globalt unik identifierare (GUID)), resursgruppsnamn, Databricks-arbetsytenamn och url för arbetsyteportalen för senare användning.

2. I en webbläsare går du till Databricks-arbetsytans URL och genererar en personlig databricks-åtkomsttoken. Kopiera och spara tokensträngen som visas (som börjar med och ett hexadecimalt värde på dapi 32 tecken) för senare användning.

3. Klona GitHub-lagringsplatsen mspnp/spark-monitoring till den lokala datorn. Den här lagringsplatsen har källkoden för följande komponenter:

   • Azure Resource Manager-mallen (ARM) för att skapa en Azure Log Analytics-arbetsyta, som även installerar fördefinierade frågor för att samla in Spark-mått
   • Azure Databricks-övervakningsbibliotek
   • Exempelprogrammet för att skicka programmått och programloggar från Azure Databricks till Azure Monitor

4. Använd Azure CLI-kommandot för att distribuera en ARM-mall och skapa en Azure Log Analytics-arbetsyta med fördefinierade Spark-måttfrågor. Från kommandots utdata kopierar och sparar du det genererade namnet för den nya Log Analytics-arbetsytan (i formatet spark-monitoring-randomized-string><).

5. I Azure-portalen kopierar och sparar du ditt Log Analytics-arbetsyte-ID och nyckel för senare användning.

6. Installera Community Edition av IntelliJ IDEA, en integrerad utvecklingsmiljö (IDE) som har inbyggt stöd för Java Development Kit (JDK) och Apache Maven. Lägg till Scala-plugin-programmet.

7. Använd IntelliJ IDEA och skapa Azure Databricks-övervakningsbiblioteken. Om du vill utföra det faktiska byggsteget väljer du Visa>verktyget Windows>Maven för att visa Maven-verktygsfönstret och väljer sedan Kör Maven Goal>mvn-paketet.

8. Med hjälp av ett Installationsverktyg för Python-paket installerar du Azure Databricks CLI och konfigurerar autentisering med databricks personliga åtkomsttoken som du kopierade tidigare.

9. Konfigurera Azure Databricks-arbetsytan genom att ändra Init-skriptet för Databricks med de Databricks- och Log Analytics-värden som du kopierade tidigare och sedan använda Azure Databricks CLI för att kopiera init-skriptet och Azure Databricks-övervakningsbiblioteken till din Databricks-arbetsyta.

10. I databricks-arbetsyteportalen skapar och konfigurerar du ett Azure Databricks-kluster.

11. I IntelliJ IDEA skapar du exempelprogrammet med Maven. Kör sedan exempelprogrammet i Databricks-arbetsyteportalen för att generera exempelloggar och mått för Azure Monitor.

12. Medan exempeljobbet körs i Azure Databricks går du till Azure-portalen för att visa och fråga händelsetyperna (programloggar och mått) i Log Analytics-gränssnittet:

    1. Välj Tabeller>Anpassade loggar för att visa tabellschemat för Spark-lyssnarhändelser (SparkListenerEvent_CL), Spark-loggningshändelser (SparkLoggingEvent_CL) och Spark-mått (SparkMetric_CL).
    2. Välj Frågeutforskaren>Sparade frågor>Spark-mått för att visa och köra de frågor som lades till när du skapade Log Analytics-arbetsytan.

    Läs mer om att visa och köra fördefinierade och anpassade frågor i nästa avsnitt.

Fråga loggarna och måtten i Azure Log Analytics

Åtkomst till fördefinierade frågor

Nedan visas de fördefinierade frågenamnen för att hämta Spark-mått.

Skriva anpassade frågor

Du kan också skriva egna frågor i Kusto-frågespråk (KQL). Välj bara det övre mittenfönstret, som kan redigeras, och anpassa frågan efter dina behov.

Följande två frågor hämtar data från Spark-loggningshändelserna:

SparkLoggingEvent_CL | where logger_name_s contains "com.microsoft.pnp"

SparkLoggingEvent_CL
| where TimeGenerated > ago(7d)
| project TimeGenerated, clusterName_s, logger_name_s
| summarize Count=count() by clusterName_s, logger_name_s, bin(TimeGenerated, 1h)

Och de här två exemplen är frågor i Spark-måttloggen:

SparkMetric_CL
| where name_s contains "executor.cpuTime"
| extend sname = split(name_s, ".")
| extend executor=strcat(sname[0], ".", sname[1])
| project TimeGenerated, cpuTime=count_d / 100000

SparkMetric_CL
| where name_s contains "driver.jvm.total."
| where executorId_s == "driver"
| extend memUsed_GB = value_d / 1000000000
| project TimeGenerated, name_s, memUsed_GB
| summarize max(memUsed_GB) by tostring(name_s), bin(TimeGenerated, 1m)

Frågeterminologi

I följande tabell beskrivs några av de termer som används när du skapar en fråga med programloggar och mått.

Följande avsnitt innehåller de typiska mått som används i det här scenariot för övervakning av systemets dataflöde, Status för Spark-jobbkörning och användning av systemresurser.

Systemdataflöde

Status för Spark-jobb som körs

Användning av systemresurser

Bestäm hur du ska relatera kundens indata, som kombinerades till en GZIP-arkivfil, till en viss Azure Databricks-utdatafil, eftersom Azure Databricks hanterar hela batchåtgärden som en enhet. Här tillämpar du kornighet på spårningen. Du använder också anpassade mått för att spåra en utdatafil till den ursprungliga indatafilen.

Mer detaljerade definitioner av varje mått finns i Visualiseringar på instrumentpanelerna på den här webbplatsen eller i avsnittet Mått i Apache Spark-dokumentationen.

Utvärdera prestandajusteringsalternativ

Originalplansdefinition

Du och utvecklingsteamet bör upprätta en baslinje så att du kan jämföra programmets framtida tillstånd.

Mät programmets prestanda kvantitativt. I det här scenariot är nyckelmåttet jobbfördröjning, vilket är typiskt för de flesta dataförbearbetning och inmatning. Försök att påskynda databehandlingstiden och fokusera på att mäta svarstiden, som i diagrammet nedan:

Mät körningssvarstiden för ett jobb: en grov vy över övergripande jobbprestanda och varaktigheten för jobbkörning från start till slutförande (mikrobatchtid). I diagrammet ovan, vid 19:30-markering, tar det cirka 40 sekunder att bearbeta jobbet.

Om du tittar närmare på dessa 40 sekunder ser du data nedan för steg:

Vid 19:30-märket finns det två steg: en orange fas på 10 sekunder och en grön fas på 30 sekunder. Övervaka om en fas toppar, eftersom en topp indikerar en fördröjning i ett stadium.

Undersök när en viss fas körs långsamt. I partitioneringsscenariot finns det vanligtvis minst två steg: en fas för att läsa en fil och den andra fasen för att blanda, partitionera och skriva filen. Om du oftast har långa svarstider i skrivfasen kan det uppstå problem med flaskhalsar under partitioneringen.

Observera aktiviteterna när stegen i ett jobb körs sekventiellt, med tidigare steg som blockerar senare steg. Om en aktivitet kör en shuffle-partition långsammare än andra aktiviteter inom ett stadium, måste alla aktiviteter i klustret vänta tills den långsammare aktiviteten har slutförts för att fasen ska slutföras. Uppgifter är sedan ett sätt att övervaka datasnedställning och möjliga flaskhalsar. I diagrammet ovan kan du se att alla uppgifter är jämnt fördelade.

Övervaka nu bearbetningstiden. Eftersom du har ett strömningsscenario kan du titta på dataflödet för direktuppspelning.

I diagrammet för strömmande dataflöde/batchsvarstid ovan representerar den orange linjen indatahastighet (indatarader per sekund). Den blå linjen representerar bearbetningshastigheten (bearbetade rader per sekund). Vid vissa tillfällen fångar inte bearbetningsfrekvensen indatahastigheten. Det potentiella problemet är att indatafiler samlas i kön.

Eftersom bearbetningshastigheten inte matchar indatahastigheten i diagrammet kan du försöka förbättra processhastigheten så att den täcker indatahastigheten helt. En möjlig orsak kan vara obalansen mellan kunddata i varje partitionsnyckel som leder till en flaskhals. För ett nästa steg och en potentiell lösning kan du dra nytta av skalbarheten för Azure Databricks.

Partitioneringsundersökning

Börja med att identifiera rätt antal skalningsexekutorer som du behöver med Azure Databricks. Använd tumregeln för att tilldela varje partition med en dedikerad CPU i körbara körbara filer. Om du till exempel har 200 partitionsnycklar ska antalet processorer multiplicerat med antalet utförare vara lika med 200. (Till exempel skulle åtta processorer i kombination med 25 utförare vara en bra matchning.) Med 200 partitionsnycklar kan varje utförare bara arbeta med en uppgift, vilket minskar risken för en flaskhals.

Eftersom vissa långsamma partitioner finns i det här scenariot undersöker du den höga variansen i varaktigheten för aktiviteter. Sök efter toppar i aktivitetens varaktighet. En uppgift hanterar en partition. Om en aktivitet kräver mer tid kan partitionen vara för stor och orsaka en flaskhals.

Felspårning

Lägg till en instrumentpanel för felspårning så att du kan upptäcka kundspecifika datafel. I förbearbetning av data finns det tillfällen då filer är skadade och poster i en fil inte matchar dataschemat. Följande instrumentpanel fångar upp många felaktiga filer och felaktiga poster.

Den här instrumentpanelen visar felantal, felmeddelande och uppgifts-ID för felsökning. I meddelandet kan du enkelt spåra felet tillbaka till felfilen. Det finns flera felfiler vid läsning. Du granskar den översta tidslinjen och undersöker de specifika punkterna i vårt diagram (16:20 och 16:40).

Andra flaskhalsar

Fler exempel och vägledning finns i Felsöka flaskhalsar för prestanda i Azure Databricks.

Sammanfattning av utvärdering av prestandajustering

I det här scenariot identifierade dessa mått följande observationer:

• I diagrammet för svarstid för steg tar det mesta av bearbetningstiden att skriva faser.
• I diagrammet för aktivitetssvarstid är svarstiden stabil.
• I diagrammet för strömmande dataflöde är utdatahastigheten lägre än indatahastigheten vid vissa punkter.
• I aktivitetens varaktighetstabell finns det aktivitetsavvikelse på grund av obalans i kunddata.
• För att få optimerad prestanda i partitioneringssteget ska antalet skalningsexekutorer matcha antalet partitioner.
• Det finns spårningsfel, till exempel felaktiga filer och felaktiga poster.

För att diagnostisera dessa problem använde du följande mått:

• Svarstid för jobb
• Svarstid för steg
• Svarstid för aktivitet
• Strömmande dataflöde
• Varaktighet för aktiviteten (max, medelvärde, min) per fas
• Felspårning (antal, meddelande, aktivitets-ID)

Deltagare

Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.

Huvudförfattare:

• David McGhee | Programhanteraren för huvudnamn

Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.

Nästa steg

• Läs Log Analytics-självstudien.
• Övervaka Azure Databricks på en Azure Log Analytics-arbetsyta
• Distribution av Azure Log Analytics med Spark-mått
• Observerbarhetsmönster

Relaterade resurser

• Skicka Azure Databricks-programloggar till Azure Monitor
• Visualisera Azure Databricks-mått med instrumentpaneler
• Metodtips för övervakning av molnprogram
• Återförsöksmönster