PySpark Sollicitatievragen

Door Aaron Cao · Bijgewerkt op

PySpark Sollicitatievragen
PySpark-sollicitatiegesprekken draaien vooral om het executiemodel en om performance. Verwacht dat u transformaties en actions kunt uitleggen, kunt aangeven welke operaties een shuffle veroorzaken, een broadcast join kunt kiezen, data skew kunt diagnosticeren, caching kunt rechtvaardigen en kunt beschrijven hoe u een job zou afstemmen die zonder geheugen komt te zitten.

PySpark-sollicitatiegesprekken draaien vooral om het executiemodel en om performance. Verwacht dat u transformaties en actions kunt uitleggen, kunt aangeven welke operaties een shuffle veroorzaken, een broadcast join kunt kiezen, data skew kunt diagnosticeren, caching kunt rechtvaardigen en kunt beschrijven hoe u een job zou afstemmen die zonder geheugen komt te zitten.

Wat vragen interviewers over het executiemodel?

U kunt werkende PySpark schrijven en hier toch struikelen, omdat deze vragen gaan over wat de engine doet, niet over wat uw code zegt. Interviewers openen hiermee juist omdat het onderscheid maakt tussen mensen die een job hebben afgesteld en mensen die er alleen maar een hebben gedraaid. Deze sectie behandelt de modelvragen en wat een volledig antwoord bevat.

  • Transformatie of action, wat is het verschil? Transformaties bouwen een plan op en geven lazy een nieuwe DataFrame terug; actions zoals count, collect of een write triggeren de uitvoering. Er wordt niets berekend tot een action om een resultaat vraagt.
  • Waarom is laziness nuttig? De optimizer ziet de hele keten voordat hij die uitvoert, zodat hij filters kan herschikken, kolommen kan prunen en stappen kan combineren.
  • Narrow of wide transformatie? Narrow operaties zoals filter en select houden elke output-partitie afhankelijk van één input-partitie. Wide operaties zoals groupBy, join en distinct herverdelen data over partities, en dat is een shuffle.
  • Wat is een shuffle en waarom is dat belangrijk? Data beweegt over het netwerk en raakt de schijf aan, wat een stage-grens vormt. Het is meestal het duurste dat een job doet.
  • Leg job, stage en task uit. Een action start een job, shuffle-grenzen splitsen die in stages, en elke stage draait één task per partitie.
  • RDD, DataFrame of Dataset? Geef de voorkeur aan DataFrames, omdat de Catalyst-optimizer en kolomgewijze uitvoering daar gelden. RDD's blijven bestaan voor laagniveau controle. Getypeerde Datasets zijn een JVM-concept, dus in Python is het eerlijke antwoord dat ze niet van toepassing zijn.

Gebruik de woorden shuffle en stage wanneer ze in het antwoord thuishoren. Interviewers gebruiken ze als kortere weg om te zien of u ooit een Spark UI hebt gelezen.

Hoe beantwoordt u de performancevragen?

De meeste senior PySpark-sollicitatiegesprekken zijn performancegesprekken. De vragen komen als scenario's, niet als definities.

  • Een join is traag. Wat controleert u? Eerst de grootte van elke kant. Als de ene past in het executor-geheugen, broadcast die dan en sla de shuffle helemaal over. Kijk anders naar partitioning en skew voordat u aan de clustergrootte komt.
  • Wat is data skew en hoe lost u het op? Een paar keys bevatten het merendeel van de rijen, waardoor één task lang doorloopt nadat de rest klaar is. Oplossingen zijn onder meer salting van de hot key, broadcasten van de kleine kant, of het filteren van nulls die allemaal naar dezelfde plek hashen. Het diagnostische signaal is de spreiding van taakduur in de Spark UI.
  • Wanneer cachet of persisteert u? Wanneer een DataFrame over meerdere actions wordt hergebruikt en herberekening kostbaar zou zijn. Iets cachen dat maar één keer wordt gebruikt, verspilt geheugen, en unpersisten is belangrijk bij lange jobs.
  • Repartition of coalesce? Repartition shufflet en kan partities gelijkmatig verhogen of verlagen; coalesce voegt samen zonder volledige shuffle, wat de goedkopere manier is om outputbestanden te verminderen.
  • Waarom een Python UDF vermijden? Rijen worden geserialiseerd tussen de JVM en een Python-proces, en de optimizer kan niet in de functie kijken. Geef de voorkeur aan ingebouwde functies, en grijp alleen naar een vectorized UDF als er geen ingebouwde bestaat.
  • Waarom is collect gevaarlijk? Het haalt het volledige resultaat naar de driver en kan diens geheugen uitputten.
  • Een job faalt met out of memory. Wat is uw onderzoeksvolgorde? Of het driver of executor is, dan skew, dan partitiegrootte, dan de geheugenconfiguratie. Als eerste stap geheugen verhogen is het antwoord dat op onervarenheid wijst.

Een data engineer die solliciteerde bij een platformteam kreeg de vraag waarom een nachtelijke job die al een jaar draaide plotseling vier uur duurde. Het antwoord dat aansloeg was geen configuratiewijziging, maar dat één upstream-partner nulls begon te sturen in de join-key, waardoor elke null-rij naar dezelfde partitie hashte. Interviewers belonen die volgorde: kijk naar de data voordat u naar het cluster kijkt.

Gerelateerde vragenbanken per rol staan onder interview questions by role.

Welke praktische en data-gerelateerde vragen komen voor?

De resterende vragen controleren of u een pipeline hebt uitgeleverd in plaats van een tutorial hebt afgemaakt.

  • Hoe leest u data efficiënt? Kolomgewijze formaten zoals Parquet, partition pruning op de filterkolom, en predicate pushdown. Leg uit waarom minder bytes lezen beter is dan optimaliseren wat daarna gebeurt.
  • Waarom een schema definiëren in plaats van laten inferren? Inferentie kost een extra doorgang over de data en kan types inconsistent raden tussen runs.
  • Hoe gaat u om met nulls en duplicaten? De relevante functies, plus het punt dat null-zware join-keys skew veroorzaken.
  • Waar worden window-functies voor gebruikt? Ranking, lopende totalen en dedupliceren naar het laatste record per key, een heel gangbare pipelinetaak.
  • Hoe schrijft u output zonder duizenden kleine bestanden te produceren? Coalesce of repartition vóór het schrijven, en partitioneer de output op een kolom met verstandige cardinaliteit.
  • Hoe test u PySpark-code? Kleine lokale sessies met fixture-DataFrames, en bedrijfslogica opgesplitst in functies die DataFrames aannemen en teruggeven.
  • Hoe dient u een job in en configureert u die? Aantal executors, cores en geheugen, en de redenering dat zowel te veel kleine executors als te weinig grote beide capaciteit verspillen.

Hoe moet u oefenen vóór het gesprek?

PySpark-antwoorden falen hardop op een herkenbare manier. De kandidaat weet dat een shuffle duur is maar kan niet zeggen welke operaties er één veroorzaken, waardoor het antwoord een lijst bijvoeglijke naamwoorden wordt. Een vragenbank lezen levert herkenning op, en herkenning is niet hetzelfde als een uitleg die u geeft terwijl iemand wacht.

Neem één pipeline die u hebt gebouwd en vertel die van begin tot eind: de read, elke transformatie, waar de stage-grenzen vallen, en wat u als eerste zou controleren als hij trager werd. Doe het hardop tot u stopt met opnieuw beginnen. Deze prompts oefenen tegen een AI-interviewer die de vervolgvraag stelt, komt dichter bij een echte ronde dan aantekeningen herlezen, en daarvoor is de mock interview-modus gebouwd.

Aaron Cao, oprichter van SubcueAI, bouwde de oefening rond dat spreekgat in plaats van rond het aanleveren van nog meer vragen. Tijdens een live gesprek kunnen de desktopapp en het Side Panel van de browserextensie structuur laten zien terwijl de interviewer spreekt, wat het meest helpt bij materiaal dat u al hebt geoefend. De installatie duurt een paar minuten en staat beschreven op de tutorial-pagina.

FAQ

Bevatten PySpark-sollicitatiegesprekken live coderen?

Vaak wel. Een gangbare taak is een join plus een aggregatie, of dedupliceren naar de laatste rij per key met een window-functie. Interviewers letten op of u naar ingebouwde functies grijpt in plaats van een UDF, en of u partitioning ongevraagd noemt.

Hoeveel SQL heb ik nodig voor een PySpark-functie?

Behoorlijk veel. Spark SQL en de DataFrame API drukken dezelfde operaties uit, en veel teams schrijven joins en window-functies rechtstreeks in SQL. Verwacht minstens één vraag die u in beide vormen kunt beantwoorden.

Moet ik Scala leren voor een Spark-gesprek?

Niet voor een PySpark-functie. Het helpt om te weten dat Spark op de JVM draait en dat Python UDF's een serialisatiekost betalen over die grens, precies waarom ingebouwde functies de voorkeur krijgen.

Wat is de meest gemaakte PySpark-sollicitatiefout?

Performancevragen beantwoorden met clustergrootte. Interviewers willen dat de data eerst wordt onderzocht: partitiegroottes, skew, join-strategie en hoeveel er wordt gelezen. Als eerste zet executors toevoegen wijst op beperkte productie-ervaring.

Kan een AI-assistent me helpen tijdens een live data-engineeringgesprek?

Die kan structuur laten zien terwijl de interviewer spreekt, wat het nuttigst is bij materiaal dat u al kent. Het vervangt geen oefening, en schermdelen, opgenomen sessies, proctored assessments en door het bedrijf beheerde laptops blijven buiten scope.

Gerelateerde vragen

← Meer over Sollicitatievragen per functie & onderwerp