PySpark इंटरव्यू सवाल

आप काम करने वाला PySpark कोड लिख सकते हैं, फिर भी यहां अटक सकते हैं, क्योंकि ये सवाल यह पूछते हैं कि engine असल में क्या करता है, न कि आपका कोड क्या कहता है। इंटरव्यूअर अक्सर यहीं से शुरुआत करते हैं, क्योंकि इससे उन लोगों को अलग किया जा सकता है जिन्होंने किसी job को tune किया है और उनसे जिन्होंने बस एक बार उसे चलाया है। यह सेक्शन execution model से जुड़े सवालों और एक पूरे जवाब में क्या शामिल होना चाहिए, इसे कवर करता है।

• Transformation और action में क्या फ़र्क़ है? Transformation एक plan बनाते हैं और lazy तरीक़े से एक नया DataFrame लौटाते हैं; count, collect जैसी actions या एक write ऑपरेशन execution को ट्रिगर करते हैं। जब तक कोई action result नहीं मांगता, तब तक कुछ भी compute नहीं होता।
• Lazy evaluation क्यों उपयोगी है? Optimizer इसे चलाने से पहले पूरी chain देख लेता है, इसलिए वह filter का क्रम बदल सकता है, ग़ैर-ज़रूरी column हटा सकता है और कई step को मिला सकता है।
• Narrow transformation या wide transformation? filter और select जैसे narrow operation में हर output partition सिर्फ़ एक input partition पर निर्भर रहता है। groupBy, join और distinct जैसे wide operation partitions के बीच data को फिर से बांटते हैं, यही shuffle है।
• Shuffle क्या है और यह क्यों मायने रखता है? Data नेटवर्क से होकर गुज़रता है और disk तक पहुंचता है, जिससे एक stage boundary बनता है। आमतौर पर यह किसी job का सबसे महंगा हिस्सा होता है।
• Job, stage और task समझाएं। एक action job शुरू करता है, shuffle boundary उसे stages में बांटती है, और हर stage हर partition के लिए एक task चलाता है।
• RDD, DataFrame या Dataset? DataFrame को प्राथमिकता दें, क्योंकि Catalyst optimizer और columnar execution यहां लागू होते हैं। RDD low-level control के लिए अब भी काम आता है। Typed Dataset एक JVM concept है, इसलिए Python में ईमानदार जवाब यही है कि यह लागू नहीं होता।

जब जवाब में shuffle और stage शब्द आने चाहिए, तब उन्हें ज़रूर बोलें। इंटरव्यूअर इन्हें यह जांचने के एक शॉर्टकट की तरह इस्तेमाल करते हैं कि क्या आपने कभी Spark UI देखा है।

ज़्यादातर senior PySpark इंटरव्यू असल में performance इंटरव्यू ही होते हैं। सवाल definition के रूप में नहीं, बल्कि scenario के रूप में आते हैं।

• एक join धीमा है। आप क्या जांचते हैं? पहले दोनों तरफ़ का data size देखते हैं। अगर एक तरफ़ executor memory में आ जाए, तो उसे broadcast कर दें और shuffle को पूरी तरह टाल दें। वरना cluster size बदलने से पहले partitioning और skew देखें।
• Data skew क्या है और इसे कैसे ठीक करें? कुछ ही key ज़्यादातर rows को अपने पास रखते हैं, जिससे बाक़ी task ख़त्म होने के बाद भी एक task चलता रहता है। इसे ठीक करने के तरीक़ों में hot key को salt करना, छोटे हिस्से को broadcast करना, या उन null को filter करना शामिल है जो सब एक ही जगह hash हो जाते हैं। diagnostic signal Spark UI में task duration की भिन्नता है।
• cache या persist का इस्तेमाल कब करें? जब एक DataFrame कई actions में दोबारा इस्तेमाल होता है और उसे फिर से compute करना महंगा पड़े। सिर्फ़ एक बार इस्तेमाल होने वाली चीज़ को cache करना memory बर्बाद करता है, और लंबे job में समय पर unpersist करना भी मायने रखता है।
• repartition या coalesce? repartition shuffle करता है और partitions को बराबर मात्रा में बढ़ा या घटा सकता है; coalesce बिना पूरे shuffle के मर्ज करता है, जो output files कम करने का सस्ता तरीक़ा है।
• Python UDF से क्यों बचें? Row, JVM और Python process के बीच serialize होते हैं, और optimizer function के अंदर नहीं देख पाता। built-in function को प्राथमिकता दें, और vectorized UDF का सहारा तभी लें जब कोई built-in मौजूद न हो।
• collect ख़तरनाक क्यों है? यह पूरा result driver पर खींच लाता है और उसकी memory ख़त्म कर सकता है।
• एक job memory ख़त्म होने से fail हो जाता है। आप किस क्रम में जांच करते हैं? पहले यह देखें कि driver है या executor, फिर skew, फिर partition का आकार, और सबसे आख़िर में memory configuration। सबसे पहले memory बढ़ा देना ऐसा जवाब है जो अनुभव की कमी दिखाता है।

एक data engineer, जो platform team के लिए इंटरव्यू दे रहा था, से पूछा गया कि एक साल से चल रहा nightly job अचानक चार घंटे क्यों लेने लगा। जो जवाब असर कर गया वह कोई configuration बदलाव नहीं था, बल्कि यह था कि किसी upstream partner ने join key में null भेजना शुरू कर दिया था, जिससे हर null row एक ही partition में hash हो रही थी। इंटरव्यूअर इसी क्रम की सराहना करते हैं: cluster से पहले data को देखना।

role के हिसाब से जुड़े सवालों के बैंक role के अनुसार इंटरव्यू सवाल में मिलते हैं।

बाक़ी सवाल यह जांचते हैं कि क्या आपने कभी असल में कोई pipeline production में भेजा है, न कि सिर्फ़ एक tutorial पूरा किया है।

• Data को कुशलता से कैसे पढ़ें? Parquet जैसे columnar format, filter column पर partition pruning, और predicate pushdown। बताएं कि कम bytes पढ़ना, बाद में होने वाले काम को optimize करने से बेहतर क्यों है।
• Schema को infer करने की बजाय ख़ुद क्यों define करें? Infer करने में data पर एक अतिरिक्त pass लगता है, और अलग-अलग run में type का अंदाज़ा अलग-अलग हो सकता है।
• null और duplicate को कैसे संभालें? जुड़े हुए functions, साथ ही यह बात कि बहुत सारे null वाली join key skew पैदा करती है।
• Window function किसलिए इस्तेमाल होते हैं? Ranking, running total, और हर key के लिए latest record तक deduplicate करने के लिए, जो pipeline में बहुत आम काम है।
• हज़ारों छोटी files बनाए बिना output कैसे लिखें? लिखने से पहले coalesce या repartition करें, और output को एक ऐसे column से partition करें जिसकी cardinality उचित हो।
• PySpark code को कैसे test करें? fixture DataFrame के साथ छोटे local session, और business logic को उन functions में अलग रखें जो DataFrame लेते और लौटाते हैं।
• Job को submit और configure कैसे करें? Executor count, cores और memory, साथ ही यह तर्क कि बहुत सारे छोटे executor और बहुत कम बड़े executor, दोनों ही capacity बर्बाद करते हैं।

PySpark के जवाब बोलते समय एक पहचानी जाने वाली तरह से फेल होते हैं। candidate को पता होता है कि shuffle महंगा है, लेकिन वह यह नहीं बता पाता कि कौन-से operation इसका कारण बनते हैं, इसलिए जवाब adjectives की एक सूची बनकर रह जाता है। question bank पढ़ने से चीज़ें जानी-पहचानी लगने लगती हैं, और यह पहचान किसी के इंतज़ार करते हुए explanation देने जैसा नहीं होता।

आपने जो एक pipeline बनाया है, उसे शुरू से अंत तक ज़ोर से बताएं: read, हर transformation, stage boundary कहां आती है, और अगर वह धीमा पड़ जाए तो आप सबसे पहले क्या जांचेंगे। इसे ज़ोर से तब तक बोलें जब तक आप बार-बार दोबारा शुरू करना बंद न कर दें। follow-up सवाल पूछने वाले AI interviewer के सामने इन सवालों का अभ्यास करना नोट्स दोबारा पढ़ने से कहीं ज़्यादा असली इंटरव्यू जैसा है, और mock interview mode इसी के लिए बनाया गया है।

SubcueAI के founder Aaron Cao ने अभ्यास को और सवाल जोड़ने के बजाय, बोलते समय आने वाली इसी कमी के इर्द-गिर्द बनाया है। असल इंटरव्यू में, desktop app और browser extension का Side Panel इंटरव्यूअर के बोलते समय structure सामने ला सकता है, जो उस सामग्री पर सबसे ज़्यादा मदद करता है जिसका आप पहले से अभ्यास कर चुके हैं। Setup में बस कुछ मिनट लगते हैं और इसकी जानकारी tutorial पेज पर दी गई है।