Întrebări Interviu PySpark

Puteți scrie PySpark funcțional și tot să vă poticniți aici, pentru că aceste întrebări cer ce face motorul, nu ce spune codul dvs. Intervievatorii deschid tocmai cu ele fiindcă separă oamenii care au reglat un job de cei care doar l-au rulat. Această secțiune acoperă întrebările de model și ce include un răspuns complet.

• Transformation sau action, care e diferența? Transformation construiește un plan și returnează lazy un DataFrame nou; action-uri precum count, collect sau o scriere declanșează execuția. Nimic nu se calculează până când un action nu cere un rezultat.
• De ce este utilă lazyness-ul? Optimizatorul vede întregul lanț înainte de a-l rula, deci poate reordona filtrele, elimina coloane și combina pași.
• Transformation narrow sau wide? Operațiile narrow precum filter și select mențin fiecare partiție de ieșire dependentă de o singură partiție de intrare. Operațiile wide precum groupBy, join și distinct redistribuie datele între partiții, ceea ce e un shuffle.
• Ce este un shuffle și de ce contează? Datele se mută prin rețea și ating discul, formând o graniță de stage. De obicei e cel mai costisitor lucru pe care îl face un job.
• Explicați job, stage și task. Un action pornește un job, granițele de shuffle îl împart în stages, iar fiecare stage rulează un task per partiție.
• RDD, DataFrame sau Dataset? Preferați DataFrame, deoarece optimizatorul Catalyst și execuția columnară se aplică acolo. RDD-urile rămân pentru control la nivel scăzut. Dataset-urile tipizate sunt un concept JVM, deci în Python răspunsul onest e că nu se aplică.

Spuneți cuvintele shuffle și stage atunci când aparțin răspunsului. Intervievatorii le folosesc drept scurtătură pentru a vedea dacă ați citit vreodată un Spark UI.

Majoritatea interviurilor PySpark de nivel senior sunt interviuri de performanță. Întrebările vin ca scenarii, nu ca definiții.

• Un join este lent. Ce verificați? Mai întâi dimensiunea fiecărei părți. Dacă una încape în memoria executorului, faceți-i broadcast și evitați complet shuffle-ul. Altfel, priviți partitioning și skew înainte de a atinge dimensiunea clusterului.
• Ce este data skew și cum îl reparați? Câteva key-uri conțin majoritatea rândurilor, așa că un task rulează mult timp după ce restul s-au terminat. Remediile includ salting pentru hot key, broadcast pentru partea mică, sau filtrarea valorilor null care se hash-uiesc toate în același loc. Semnalul de diagnostic este distribuția duratei task-urilor în Spark UI.
• Când faceți cache sau persist? Când un DataFrame este refolosit în mai multe action-uri și recalcularea ar fi costisitoare. Cache-uirea a ceva folosit o singură dată risipește memorie, iar unpersist contează în joburile lungi.
• Repartition sau coalesce? Repartition face shuffle și poate crește sau scădea partițiile uniform; coalesce le combină fără un shuffle complet, modul mai ieftin de a reduce fișierele de ieșire.
• De ce să evitați un UDF Python? Rândurile se serializează între JVM și un proces Python, iar optimizatorul nu poate vedea în interiorul funcției. Preferați funcțiile built-in și apelați la un UDF vectorizat doar când nu există una built-in.
• De ce este collect periculos? Trage întregul rezultat către driver și îi poate epuiza memoria.
• Un job eșuează cu out of memory. Care este ordinea investigației dvs.? Dacă e driver sau executor, apoi skew, apoi dimensionarea partițiilor, apoi configurarea memoriei. Creșterea memoriei ca prim pas este răspunsul care semnalează lipsă de experiență.

Un data engineer care intervieva pentru o echipă de platformă a fost întrebat de ce un job de noapte care rulase timp de un an a durat brusc patru ore. Răspunsul potrivit nu a fost o schimbare de configurare, ci faptul că un partener upstream a început să trimită null-uri în cheia de join, astfel încât fiecare rând null se hash-uia în aceeași partiție. Intervievatorii recompensează această ordine: priviți datele înainte de cluster.

Băncile de întrebări conexe pe rol se află sub interview questions by role.

Întrebările rămase verifică dacă ați lansat un pipeline, nu doar ați terminat un tutorial.

• Cum citiți datele eficient? Formate columnare precum Parquet, partition pruning pe coloana de filtrare și predicate pushdown. Explicați de ce a citi mai puțini bytes este mai bine decât a optimiza ce se întâmplă după.
• De ce să definiți o schemă în loc să o deduceți? Deducerea costă o trecere suplimentară prin date și poate ghici tipuri inconsistent între rulări.
• Cum gestionați valorile null și duplicatele? Funcțiile relevante, plus faptul că cheile de join încărcate cu null creează skew.
• Pentru ce se folosesc window function? Ranking, totaluri cumulative și deduplicare la cea mai recentă înregistrare per key, o sarcină de pipeline foarte comună.
• Cum scrieți output-ul fără a produce mii de fișiere mici? Coalesce sau repartition înainte de scriere și partiționați output-ul după o coloană cu o cardinalitate rezonabilă.
• Cum testați cod PySpark? Sesiuni locale mici cu DataFrame-uri fixture, iar logica de business descompusă în funcții care primesc și returnează DataFrame-uri.
• Cum trimiteți și configurați un job? Numărul de executori, core-uri și memorie, plus argumentul că prea mulți executori mici și prea puțini mari risipesc ambii capacitate.

Răspunsurile PySpark eșuează cu voce tare într-un mod ușor de recunoscut. Candidatul știe că un shuffle e costisitor, dar nu poate spune ce operații îl provoacă, așa că răspunsul devine o listă de adjective. Citirea unei bănci de întrebări produce recunoaștere, iar recunoașterea nu e același lucru cu o explicație oferită în timp ce cineva așteaptă.

Luați un pipeline pe care l-ați construit și povestiți-l de la un capăt la altul: citirea, fiecare transformation, unde cad granițele de stage și ce ați verifica primul dacă s-ar încetini. Faceți-o cu voce tare până când nu mai reîncepeți. Exersarea acestor prompt-uri împotriva unui intervievator AI care pune întrebarea de follow-up e mai aproape de o rundă reală decât recitirea notițelor, și exact pentru asta a fost construit modul mock interview.

Aaron Cao, fondatorul SubcueAI, a construit exercițiul în jurul acestui decalaj de vorbire, nu în jurul furnizării mai multor întrebări. Într-un interviu live, aplicația desktop și Side Panel-ul din extensia de browser pot scoate la suprafață structura pe măsură ce intervievatorul vorbește, ceea ce ajută cel mai mult pe materialul deja repetat. Configurarea durează câteva minute și este descrisă pe pagina tutorial.