Prestatieknelpunten in Azure Databricks

In dit artikel wordt beschreven hoe u bewakingsdashboards gebruikt om prestatieknelpunten te vinden in Spark-taken op Azure Databricks.

Azure Databricks is een op Apache Sparkgebaseerde analyseservice die het eenvoudig maakt om snel analyses te ontwikkelen en big data implementeren. Het bewaken en oplossen van prestatieproblemen is essentieel bij het uitvoeren van Azure Databricks workloads. Als u veelvoorkomende prestatieproblemen wilt identificeren, is het handig om bewakingsvisualisaties te gebruiken op basis van telemetriegegevens.

Vereisten

De Grafana-dashboards instellen die in dit artikel worden weergegeven:

• Configureer uw Databricks-cluster om telemetrie te verzenden naar een Log Analytics-werkruimte met behulp van Azure Databricks Monitoring Library. Zie het leesmij-GitHub voor meer informatie.

• Grafana implementeren in een virtuele machine. Zie Dashboards gebruiken om de metrische gegevens Azure Databricks visualiseren.

Het Grafana-dashboard dat wordt geïmplementeerd, bevat een set tijdreeksvisualisaties. Elke grafiek is een tijdreeksplot van metrische gegevens met betrekking tot een Apache Spark job, de fasen van de job en taken waar elke fase deel van uit maakt.

Azure Databricks overzicht van de prestaties

Azure Databricks is gebaseerd op Apache Spark, een gedistribueerd computingsysteem voor algemeen gebruik. Toepassingscode, ook wel een taak genoemd, wordt uitgevoerd op een Apache Spark cluster, gecoördineerd door clusterbeheer. Over het algemeen is een taak de rekeneenheid op het hoogste niveau. Een taak vertegenwoordigt de volledige bewerking die wordt uitgevoerd door de Spark-toepassing. Een typische bewerking is het lezen van gegevens uit een bron, het toepassen van gegevenstransformaties en het schrijven van de resultaten naar de opslag of een andere bestemming.

Taken worden onderverdeeld in fasen. De taak doormaakt de fasen opeenvolgend, wat betekent dat latere fasen moeten wachten tot eerdere fasen zijn voltooid. Fasen bevatten groepen identieke taken die parallel kunnen worden uitgevoerd op meerdere knooppunten van het Spark-cluster. Taken zijn de meest gedetailleerde uitvoeringseenheid die plaatsvindt op een subset van de gegevens.

In de volgende secties worden enkele dashboardvisualisaties beschreven die handig zijn voor het oplossen van prestatieproblemen.

Taak- en faselatentie

Taaklatentie is de duur van de uitvoering van een taak vanaf het moment dat deze wordt gestart totdat deze is voltooid. Het wordt weergegeven als percentielen van de uitvoering van een taak per cluster en toepassings-id, zodat uitbijten kunnen worden gevisualisatied. In het volgende diagram ziet u een taakgeschiedenis waarbij het 90e percentiel 50 seconden heeft bereikt, ook al was het 50e percentiel consistent rond de 10 seconden.

Onderzoek de taakuitvoering per cluster en toepassing, op zoek naar pieken in latentie. Zodra clusters en toepassingen met hoge latentie zijn geïdentificeerd, gaat u verder met het onderzoeken van faselatentie.

Faselatentie wordt ook weergegeven als percentielen om de visualisatie van uitbijten toe te staan. Faselatentie wordt uitgesplitsd naar cluster-, toepassings- en fasenaam. Identificeer pieken in de taaklatentie in de grafiek om te bepalen welke taken de voltooiing van de fase in de weg staan.

De clusterdoorvoergrafiek toont het aantal taken, fasen en taken dat per minuut is voltooid. Dit helpt u om inzicht te krijgen in de workload in termen van het relatieve aantal fasen en taken per job. Hier ziet u dat het aantal taken per minuut varieert tussen 2 en 6, terwijl het aantal fasen ongeveer 12 – 24 per minuut is.

Som van latentie bij taakuitvoering

Deze visualisatie toont de som van de latentie bij het uitvoeren van taken per host die wordt uitgevoerd op een cluster. Gebruik deze grafiek om taken te detecteren die langzaam worden uitgevoerd als gevolg van vertraging van de host op een cluster of een onjuiste toewijzing van taken per uitvoerder. In de volgende grafiek hebben de meeste hosts een som van ongeveer 30 seconden. Twee van de hosts hebben echter sommen die ongeveer 10 minuten aanwijzen. De hosts worden traag uitgevoerd of het aantal taken per uitvoerder is onjuist toegewezen.

Het aantal taken per uitvoerder laat zien dat aan twee uitvoerders een onevenredig aantal taken is toegewezen, waardoor een knelpunt wordt veroorzaakt.

Metrische gegevens van taken per fase

De visualisatie met metrische gegevens van de taak geeft de kostenuitsplitsing voor de uitvoering van een taak. U kunt deze gebruiken om de relatieve tijd te zien die wordt besteed aan taken zoals serialisatie en deserialisatie. Deze gegevens kunnen bijvoorbeeld mogelijkheden bieden om te optimaliseren door broadcast-variabelen te gebruiken — om verzending van gegevens te voorkomen. De metrische gegevens van de taak tonen ook de grootte van de willekeurige gegevens voor een taak en de lees- en schrijftijden in willekeurige volgorde. Als deze waarden hoog zijn, betekent dit dat er veel gegevens via het netwerk worden verplaatst.

Een andere metrische taak is de scheduler-vertraging, die meet hoe lang het duurt om een taak te plannen. Idealiter moet deze waarde laag zijn in vergelijking met de rekentijd van de uitvoerder. Dit is de tijd die daadwerkelijk wordt besteed aan het uitvoeren van de taak.

In het volgende diagram ziet u een scheduler-vertragingstijd (3,7 s) die de rekentijd van de uitvoerder (1,1 s) overschrijdt. Dit betekent dat er meer tijd wordt besteed aan het wachten tot taken worden gepland dan dat er daadwerkelijk wordt gewerkt.

In dit geval is het probleem veroorzaakt door te veel partities, wat veel overhead heeft veroorzaakt. Door het aantal partities te verminderen, is de vertragingstijd van de scheduler verlaagd. In het volgende diagram ziet u dat het grootste deel van de tijd wordt besteed aan het uitvoeren van de taak.

Streamingdoorvoer en latentie

Streamingdoorvoer is rechtstreeks gerelateerd aan gestructureerd streamen. Er zijn twee belangrijke metrische gegevens gekoppeld aan streamingdoorvoer: invoerrijen per seconde en verwerkte rijen per seconde. Als invoerrijen per seconde verwerkte rijen per seconde overblijven, betekent dit dat het stroomverwerkingssysteem achterop loopt. Als de invoergegevens afkomstig zijn van Event Hubs of Kafka, moeten invoerrijen per seconde de opnamesnelheid van gegevens aan de front-end bij houden.

Twee taken kunnen een vergelijkbare clusterdoorvoer hebben, maar zeer verschillende streaming-metrische gegevens. In de volgende schermopname ziet u twee verschillende workloads. Ze zijn vergelijkbaar wat betreft clusterdoorvoer (taken, fasen en taken per minuut). Bij de tweede run worden echter 12.000 rijen per seconde verwerkt, vergeleken met 4000 rijen per seconde.

Streamingdoorvoer is vaak een betere zakelijke metriek dan clusterdoorvoer, omdat deze het aantal verwerkte gegevensrecords meet.

Resourceverbruik per uitvoerder

Deze metrische gegevens geven inzicht in het werk dat elke uitvoerder uitvoert.

Metrische percentagegegevens meten hoeveel tijd een uitvoerder aan verschillende dingen besteedt, uitgedrukt als een verhouding van de tijd die wordt besteed ten opzichte van de totale rekentijd van de uitvoerder. Deze metrische gegevens zijn:

• % tijd serialiseren
• % tijd deserialiseren
• % CPU-uitvoertijd
• % JVM-tijd

Deze visualisaties laten zien hoeveel deze metrische gegevens bijdragen aan de algehele verwerking van uitvoerders.

Metrische gegevens in willekeurige volgorde zijn metrische gegevens die betrekking hebben op het inseuffren van gegevens over de uitvoerders.

• I/O in willekeurige volgorde
• Geheugen in willekeurige volgorde
• Bestandssysteemgebruik
• Schijfgebruik

Veelvoorkomende prestatieknelpunten

Twee veelvoorkomende prestatieknelpunten in Spark zijn taak-stragglers en een niet-optimaal aantal shufflepartities.

Taak achterblijvers

De fasen in een taak worden opeenvolgend uitgevoerd, met eerdere fasen die latere fasen blokkeren. Als een taak een shuffle-partitie langzamer uitvoert dan andere taken, moeten alle taken in het cluster wachten tot de trage taak is inhalen voordat de fase kan worden afgesloten. Dit kan de volgende oorzaken hebben:

1. Een host of groep hosts wordt langzaam uitgevoerd. Symptomen: Hoge taak-, fase- of taaklatentie en lage clusterdoorvoer. De optelsom van takenlatentie per host wordt niet gelijkmatig verdeeld. Resourceverbruik wordt echter gelijkmatig verdeeld over uitvoerders.

2. Taken hebben een dure aggregatie om uit te voeren (gegevensscheefheid). Symptomen: Hoge latentie van taken, latentie in hoge fase, hoge taaklatentie of lage clusterdoorvoer, maar de optelsom van latentie per host is gelijkmatig verdeeld. Resourceverbruik wordt gelijkmatig verdeeld over uitvoerders.

3. Als partities ongelijke grootte hebben, kan een grotere partitie leiden tot taakuitvoering (partitiesche scheefheid). Symptomen: Het verbruik van uitvoerdersresources is hoog in vergelijking met andere uitvoerders die op het cluster worden uitgevoerd. Alle taken die op die uitvoerder worden uitgevoerd, worden traag uitgevoerd en houden de uitvoering van de fase in de pijplijn in stand. Deze fasen zijn naar eigen zeggen fasebarrières.

Niet-optimaal aantal partities in willekeurige volgorde

Tijdens een gestructureerde streamingquery is de toewijzing van een taak aan een uitvoerder een resource-intensieve bewerking voor het cluster. Als de gegevens in willekeurige volgorde niet de optimale grootte hebben, heeft de hoeveelheid vertraging voor een taak een negatieve invloed op de doorvoer en latentie. Als er te weinig partities zijn, worden de kernen in het cluster te weinig gebruikt, wat kan leiden tot inefficiëntie van de verwerking. Als er daarentegen te veel partities zijn, is er veel beheeroverhead voor een klein aantal taken.

Gebruik de metrische gegevens over resourceverbruik om problemen met partitieverscheping en onjuiste toewijzing van uitvoerders op het cluster op te lossen. Als een partitie scheef is, worden executor-resources verhoogd in vergelijking met andere uitvoerders die op het cluster worden uitgevoerd.

In de volgende grafiek ziet u bijvoorbeeld dat het geheugen dat wordt gebruikt door shuffling op de eerste twee uitvoerders 90 X groter is dan de andere uitvoerders: