Performance problemen in Databricks? Zo voorkom je ze eenvoudig
Het verwerken van grote hoeveelheden data zou tegenwoordig een koud kunstje moeten zijn – vooral met handige tools als Azure Databricks. Maar dan moet je wel weten hoe je voor een zo goed mogelijke performance zorgt. Saskia van Doormalen, Data Engineer bij Riviq, legt uit hoe je voorkomt dat je uren moet wachten op datatransformaties.
Voor degenen die ‘ooit weleens’ hebben gehoord van Azure Databricks, eerst even een korte introductie. Op het open-source platform Databricks kun je grote hoeveelheden data vanuit verschillende bronnen samenbrengen, zodat data scientists er vervolgens mee kunnen werken. Databricks maakt gebruik van de engine Apache Spark, waarmee je een forse bulk data in clusters kunt verwerken. De engine maakt gebruik van drivers en workers; de driver stuurt een transformatie aan, de workers voeren het uit. De programmeertaal die je gebruikt om Spark aan te sturen, heet PySpark, een combinatie van Python en Spark.
Een betere performance van Databricks
Data engineers die vaker met Databricks werken, herkennen vast dat sommige jobs lang kunnen duren. Of dat taken het simpelweg niet doen. De oorzaak ervan is lang niet altijd meteen duidelijk. Soms lijkt de oorzaak zelfs oppervlakkig, terwijl er een veel dieperliggend probleem in je code zit. Voordat dat je weet, ben je drie uur verder met een datatransformatie die hooguit vijftien minuten zou moeten kosten. Zijn die performanceproblemen te voorkomen? Jazeker! Op deze drie vlakken kun je slimme dingen doen:
1. Datatransformaties
Wil je datatransformaties uitvoeren? Maak de datasets dan zo klein mogelijk en voer alles parallel uit.
Kleine datasets
Denk goed na over de volgorde waarin je bewerkingen uitvoert. Voer bijvoorbeeld eerst een .filter uit en daarna een .join, niet andersom. Een .join is een zware taak. Door eerst te filteren, maak je de dataset kleiner waardoor de .join al minder zwaar wordt en dus sneller klaar zal zijn.
Werk parallel
De kracht van Databricks en PySpark is dat je bewerkingen parallel kunt uitvoeren in clusters – met een driver en workers. Maar sommige functies die je waarschijnlijk vaak gebruikt in andere systemen, zoals pandas, zorgen ervoor dat je dit principe juist ondermijnt.
Vermijd daarom de volgende functies in je PySpark-jobs:
• for loops
• .collect()
• User Defined Functions (UDF’s)
Deze functies zorgen ervoor dat je transformaties sequentieel uitvoert in plaats van parallel. En dat is niet waar clustering voor is bedoeld. Maar ja, for loops is natuurlijk wel een van de meest handige functies tijdens het programmeren. Dus hoe vermijd je dat in vredesnaam? Gebruik list comprehensions. Technisch gezien, is dat een for loop waarmee je een lijst maakt op één regel. Daarmee krijg je exact hetzelfde resultaat. Hoe je dat precies doet, leg ik uit in dit gedeelte van het webinar PySpark in Databricks.
2. Data partitioning
Als je niet goed nadenkt over data partitioning kunnen dataverwerkingen heel snel fout gaan. Hoe beter je data splitst in een heldere mappenstructuur, hoe sneller workers de benodigde data kunnen vinden en verwerken. Bovendien houd je je daarmee ook aan de eerste tip: de workers hoeven op deze manier namelijk slechts kleine datasets in te lezen.
Het klinkt logisch, maar nog te veel data engineers hechten er te weinig waarde aan. Vaak vertrouwen ze te veel op brute rekenkracht, maar compute is duur en kost veel tijd. Een goede data partitioning op grote hoeveelheden data kan al gauw het verschil maken tussen een uur verwerkingstijd of tien minuten.
Best practices voor data partitioning zijn moeilijk te geven. Het hangt namelijk compleet af van waar je data voor gaat gebruiken. Ga je aan de slag met datawarehousing? Dan kun je bijvoorbeeld een verdeling maken op basis van de laatst gewijzigde data. Wil je data voor machine learning gebruiken? Dan is een verdeling op basis van gebeurtenissen een mogelijke optie. Wat je ook doet: zorg dat je er goed over nadenkt en een verdeling kiest die logisch is voor jouw use case.
Meer van dit in je mailbox?
We sturen je circa 6x per jaar een email met handpicked cases, blogs en tips.
3. Cluster setup & monitoring
Als het gaat over de setup van clusters en hoe je prestaties in de gaten kunt houden, zijn twee adviezen van cruciaal belang:
Zet autoscaling uit
Met autoscaling geef je Databricks de vrijheid om extra workers in te zetten als een job veel werk kost. Dat lijkt ideaal, maar dat is het niet. Zo heb je namelijk vrijwel niet door wanneer er zich een performance probleem voordoet.
Stel, Databricks schaalt op naar acht workers voor een job, dan kun je al gauw denken dat het gewoon een zware klus is en dus laat je Databricks maar werken. Maar wat je dan niet doorhebt, is dat voor diezelfde job misschien slechts twee workers voldoende waren en dat er gewoon een fout in je code zit. Een ander nadeel is dat wanneer Databricks zoveel moet opschalen de kosten voor compute ook al gauw de pan uitrijzen.
Zorg voor inzicht
Om beter te weten wat er precies gebeurt tijdens jobs moeten data engineers inzicht hebben in de prestaties van clusters. Binnen Databricks zijn dat de zogeheten Ganglia Metrics. Daarmee kun je fouten signaleren terwijl ze gebeuren. Je moet dan uiteraard wel de rechten hebben om de metrics in te mogen zien.
Van links naar rechts zie je het volgende:
– Cores & Tasks
De rode lijn is het aantal cores en de blauwe lijn is het aantal taken. Gaat de blauwe lijn boven de rode lijn? Dan gaat er iets niet goed.
– In-memory
De rode lijn is het totaal aan geheugen en de groene lijn geeft de cache aan. Zie je geen transparant groen onder de rode lijn? Dan gaat er iets fout. Als er een paarse rand vlak boven de rode lijn verschijnt, worden er taken niet parallel uitgevoerd.
– CPU
Dit overzicht geeft aan hoeveel compute kracht een job vraagt.
– Data transfer
Dit overzicht geeft aan hoeveel data er wordt ingelezen en weggeschreven.
Nette en zo goed mogelijk werkende code
Het verwerken van grote hoeveelheden data moet soepel gaan – hoe groot de bulk ook is. Zo houd je vaart in je project en behoed je jezelf voor blinde paniek wanneer een job opeens acht uur duurt. Probeer daarom zoveel mogelijk performance problemen te voorkomen met behulp van deze concrete tips. Bovendien lever je zo een nette en zo goed mogelijk werkende code op – wel zo fijn voor degene die na jou met die code aan de slag moet. Wil je wat meer de diepte in over PySpark en Databricks? Kijk dan mijn webinar terug.
Geschreven door
Saskia van Doormalen
Data engineer
Op de hoogte blijven van de laatste ontwikkelingen en webinars?
Schrijf je dan in voor de nieuwsbrief en ontvang circa 6x per jaar een selectie van blogs, cases, webinars en nieuws in je mailbox.
Meer over dit onderwerp
Copilot voor Power BI. Je persoonlijke assistent voor rapportages?
Is Copilot voor Power BI een volwassen tool en hoe bruikbaar is het?Copilot voor Microsoft Fabric is sinds juni 2024 algemeen beschikbaar in Power BI. Tijdens introductie waren er hoge verwachtingen! In verschillende artikelen, guides en tutorials werden de...
Altijd keurige code met SQLFluff in DBT. Zo werkt deze handige linter
SQL-code reviews kunnen behoorlijk tijdrovend zijn. Zeker als al je collega’s code op een andere manier schrijven. Bijvoorbeeld omdat je er geen afspraken over hebt gemaakt of niet iedereen zich aan de afspraken houdt. Met SQLFluff in dbt voorkom je dat. Data engineer...
Is Microsoft Fabric de moeite waard? Dit zijn onze bevindingen
Microsoft Fabric biedt op het eerste oog ongekende mogelijkheden, maar maakt het de verwachtingen waar? Data engineer Koen Kurver zocht het uit.