PySpark Állásinterjú Kérdések

Írhat működő PySparkot, és mégis megbotolhat itt, mert ezek a kérdések azt kérdezik, mit csinál a motor, nem azt, mit mond a kódja. Az interjúztatók pont ezekkel nyitnak, mert elválasztják azokat, akik hangoltak már egy jobot, azoktól, akik csak futtattak egyet. Ez a szakasz a modellkérdéseket és egy teljes válasz tartalmát tárgyalja.

• Transformation vagy action, mi a különbség? A transformation tervet épít, és lazy módon ad vissza egy új DataFrame-et; az olyan action, mint a count, a collect vagy egy write, elindítja a végrehajtást. Semmi nem számolódik ki, amíg egy action nem kér eredményt.
• Miért hasznos a laziness? Az optimizer a teljes láncot látja futtatás előtt, így átrendezheti a szűrőket, kivághat oszlopokat, és összevonhat lépéseket.
• Narrow vagy wide transformation? A narrow műveletek, mint a filter és a select, minden output partíciót egyetlen input partíciótól függővé tesznek. A wide műveletek, mint a groupBy, a join és a distinct, partíciók között osztják újra az adatot, ez a shuffle.
• Mi a shuffle, és miért számít? Az adat átmegy a hálózaton és eléri a lemezt, ami stage-határt képez. Ez általában a legköltségesebb dolog, amit egy job tesz.
• Magyarázza el a job, a stage és a task fogalmát. Egy action elindít egy jobot, a shuffle-határok stage-ekre bontják, és minden stage partíciónként egy taskot futtat.
• RDD, DataFrame vagy Dataset? Részesítse előnyben a DataFrame-et, mert ott érvényesül a Catalyst optimizer és az oszloporientált végrehajtás. Az RDD alacsony szintű kontrollra marad. A típusos Dataset egy JVM-fogalom, így Pythonban az őszinte válasz az, hogy nem alkalmazható.

Mondja ki a shuffle és a stage szavakat, ha odaillenek a válaszba. Az interjúztatók ezeket használják gyorsteszt gyanánt annak eldöntésére, hogy olvasott-e már Spark UI-t.

A legtöbb senior szintű PySpark interjú teljesítményinterjú. A kérdések forgatókönyvként érkeznek, nem definícióként.

• Egy join lassú. Mit ellenőriz? Először mindkét oldal méretét. Ha az egyik belefér az executor memóriájába, broadcastolja, és teljesen kerülje el a shuffle-t. Ellenkező esetben nézze meg a partitioning-ot és a skew-t, mielőtt a cluster méretéhez nyúlna.
• Mi a data skew, és hogyan javítja ki? Néhány key tartja a sorok többségét, így egy task sokkal tovább fut, mint a többi befejezése. A megoldások közé tartozik a hot key saltingja, a kisebbik oldal broadcastolása, vagy azoknak a null értékeknek a kiszűrése, amelyek mind ugyanoda hash-elődnek. A diagnosztikai jel a task időtartamok szórása a Spark UI-ban.
• Mikor használ cache-t vagy persist-et? Amikor egy DataFrame-et több action is újrahasznál, és az újraszámítás drága lenne. Egyszer használt dolgot cache-elni memóriát pazarol, és az unpersist számít a hosszú jobokban.
• Repartition vagy coalesce? A repartition shuffle-t végez, és egyenletesen növelheti vagy csökkentheti a partíciók számát; a coalesce teljes shuffle nélkül egyesít, ami az olcsóbb módja az output fájlok számának csökkentésének.
• Miért kerülje a Python UDF-et? A sorok szerializálódnak a JVM és egy Python-folyamat között, és az optimizer nem lát bele a függvénybe. Részesítse előnyben a beépített függvényeket, és vectorized UDF-hez csak akkor nyúljon, ha nincs beépített megoldás.
• Miért veszélyes a collect? A teljes eredményt behúzza a driverhez, és kimerítheti annak memóriáját.
• Egy job out of memory hibával leáll. Mi a vizsgálat sorrendje? Hogy driver vagy executor-e, aztán skew, aztán partícióméret, aztán a memóriakonfiguráció. A memória első lépésként való emelése a tapasztalatlanságot jelző válasz.

Egy platformcsapatra interjúzó data engineert megkérdezték, miért tartott hirtelen négy órát egy egy éve futó éjszakai job. A célba érő válasz nem konfigurációváltozás volt, hanem az, hogy egy upstream partner null értékeket kezdett küldeni a join key-ben, így minden null sor ugyanabba a partícióba hash-elődött. Az interjúztatók ezt a sorrendet jutalmazzák: nézze meg az adatot a cluster előtt.

A szerep szerinti kapcsolódó kérdésbankok itt találhatók: interview questions by role.

A fennmaradó kérdések azt ellenőrzik, kiadott-e egy pipeline-t, nem csak befejezett egy tutorialt.

• Hogyan olvas adatot hatékonyan? Oszloporientált formátumok, mint a Parquet, partition pruning a szűrőoszlopon, és predicate pushdown. Magyarázza el, miért jobb kevesebb byte-ot olvasni, mint az utána történőket optimalizálni.
• Miért definiáljon schema-t ahelyett, hogy hagyná inferálni? Az inference extra átjárást igényel az adaton, és futtatások között inkonzisztensen tippelheti meg a típusokat.
• Hogyan kezeli a null értékeket és a duplikátumokat? A releváns függvények, plusz az a tény, hogy a null-nal teli join key-ek skew-t okoznak.
• Mire használják a window function-öket? Rangsorolás, futó összegek és deduplikálás a legfrissebb rekordra key-enként, ez egy nagyon gyakori pipeline-feladat.
• Hogyan ír ki output-ot anélkül, hogy több ezer kis fájlt hozna létre? Coalesce vagy repartition írás előtt, és az output partícionálása egy ésszerű cardinalitású oszlop szerint.
• Hogyan tesztel PySpark kódot? Kis helyi session-ök fixture DataFrame-ekkel, és üzleti logika olyan függvényekre bontva, amelyek DataFrame-et fogadnak és adnak vissza.
• Hogyan küld be és konfigurál egy jobot? Executor-ok száma, magok és memória, valamint az érvelés, hogy mind a túl sok kis executor, mind a túl kevés nagy pazarolja a kapacitást.

A PySpark válaszok felmondás közben felismerhető módon buknak el. A jelölt tudja, hogy a shuffle költséges, de nem tudja megmondani, mely műveletek okozzák, így a válasz jelzők listájává válik. Egy kérdésbank olvasása felismerést hoz, a felismerés pedig nem ugyanaz, mint egy magyarázat, amelyet akkor ad, amikor valaki vár rá.

Vegyen egy pipeline-t, amelyet épített, és mesélje el elejétől a végéig: az olvasást, minden transformationt, hogy hol esnek a stage-határok, és mit ellenőrizne először, ha lelassulna. Csinálja hangosan, amíg abba nem hagyja az újrakezdést. Ezeknek a promptoknak a gyakorlása egy AI interjúztatóval szemben, amely felteszi a követő kérdést, közelebb áll egy valódi fordulóhoz, mint a jegyzetek újraolvasása, és pont erre épült a mock interview mód.

Aaron Cao, a SubcueAI alapítója e beszédbeli rés köré építette a gyakorlást, nem pedig több kérdés biztosítása köré. Egy élő interjúban a desktopalkalmazás és a böngészőbővítmény Side Panel-je felszínre hozhatja a struktúrát, miközben az interjúztató beszél, ami leginkább olyan anyagon segít, amelyet már begyakorolt. A beállítás pár percet vesz igénybe, és a tutorial oldalon van leírva.