Mga Tanong sa Interview ng PySpark

Puwede kang makasulat ng gumaganang PySpark pero madapa pa rin dito, dahil ang mga tanong na ito ay tungkol sa ginagawa ng engine, hindi sa sinasabi ng code mo. Madalas dito nagsisimula ang mga interviewer dahil doon nakikita nila ang pagkakaiba ng mga taong nag-tune na ng job at ng mga taong isang beses lang nag-run nito. Sinasaklaw ng section na ito ang mga tanong tungkol sa execution model at kung ano ang dapat nasa isang kumpletong sagot.

• Ano ang pagkakaiba ng transformation at action? Ang transformation ay bumubuo ng plano at nagbabalik ng bagong DataFrame nang lazy; ang mga action tulad ng count, collect, o isang write ang nag-tra-trigger ng execution. Walang mako-compute hangga't walang action na humihiling ng resulta.
• Bakit kapaki-pakinabang ang lazy evaluation? Nakikita ng optimizer ang buong chain bago ito patakbuhin, kaya kaya nitong ayusin ulit ang filter, alisin ang hindi kailangang column, at pagsamahin ang mga hakbang.
• Narrow o wide na transformation? Ang mga narrow operation tulad ng filter at select ay nagpapanatili sa bawat output partition na umaasa lang sa isang input partition. Ang mga wide operation tulad ng groupBy, join, at distinct ay muling namamahagi ng data sa mga partition, at iyon ang shuffle.
• Ano ang shuffle at bakit ito mahalaga? Dumadaan ang data sa network at umaabot sa disk, na bumubuo ng hangganan ng stage. Kadalasan ito ang pinakamamahaling gawain ng isang job.
• Ipaliwanag ang job, stage, at task. Sinisimulan ng action ang isang job, hinahati ito ng hangganan ng shuffle sa mga stage, at bawat stage ay nagpapatakbo ng isang task kada partition.
• RDD, DataFrame, o Dataset? Mas mainam ang DataFrame, dahil applicable dito ang Catalyst optimizer at ang columnar execution. Ginagamit pa rin ang RDD para sa low-level na kontrol. Ang typed Dataset ay konsepto ng JVM, kaya sa Python, ang tapat na sagot ay hindi ito applicable.

Sabihin ang mga salitang shuffle at stage kapag talagang bagay ito sa sagot. Ginagamit ito ng mga interviewer bilang madaling paraan para malaman kung nabasa mo na ba talaga ang Spark UI.

Karamihan sa mga senior na interview sa PySpark ay talagang interview tungkol sa performance. Dumarating ang mga tanong bilang senaryo, hindi bilang depinisyon.

• Mabagal ang isang join. Ano ang che-check mo? Una, ang laki ng bawat side. Kung kasya ang isa sa memory ng executor, i-broadcast ito at laktawan ang shuffle nang buo. Kung hindi, tingnan ang partitioning at skew bago galawin ang laki ng cluster.
• Ano ang data skew at paano ito aayusin? Iilang key lang ang may hawak ng karamihan ng row, kaya isang task ang tumatakbo nang matagal kahit tapos na ang iba. Kasama sa mga solusyon ang pag-salt sa hot key, pag-broadcast sa mas maliit na side, o pag-filter ng null na lahat ay parehong hash. Ang diagnostic signal ay ang pagkakaiba-iba ng task duration sa Spark UI.
• Kailan gagamitin ang cache o persist? Kapag ginagamit ulit ang DataFrame sa maraming action at magiging mahal ang muling pag-compute. Ang pag-cache ng isang bagay na minsan lang gagamitin ay nagsasayang ng memory, at mahalaga ang unpersist sa mahahabang job.
• repartition o coalesce? Nagdudulot ng shuffle ang repartition at kayang tumaas o bumaba nang pantay-pantay ang mga partition; pinagsasama ng coalesce nang walang buong shuffle, na mas mura para bawasan ang bilang ng output file.
• Bakit iiwasan ang Python UDF? Nag-se-serialize ang mga row sa pagitan ng JVM at isang Python process, at hindi makikita ng optimizer ang loob ng function. Mas piliin ang built-in function, at gamitin ang vectorized UDF lang kapag walang built-in na available.
• Bakit delikado ang collect? Hinihila nito ang buong resulta papunta sa driver at puwede nitong maubos ang memory nito.
• Nabigo ang isang job dahil naubusan ng memory. Anong pagkakasunod-sunod ang gagamitin mo sa imbestigasyon? Alamin muna kung driver o executor ang problema, pagkatapos ay ang skew, saka ang laki ng partition, at panghuli ang configuration ng memory. Ang agad na pagdagdag ng memory bilang unang hakbang ang sagot na nagpapakita ng kakulangan sa karanasan.

May isang data engineer na nag-i-interview para sa isang platform team na tinanong kung bakit apat na oras na bigla ang tinagal ng nightly job na matagal nang stable sa loob ng isang taon. Ang sagot na tumama ay hindi pagbabago sa configuration, kundi ang isang upstream partner na nagsimulang magpadala ng null sa join key, kaya bawat null row ay na-hash papunta sa iisang partition. Ginagantimpalaan ng mga interviewer ang pagkakasunod-sunod na iyon: tingnan muna ang data bago ang cluster.

Ang mga kaugnay na koleksyon ng tanong ayon sa role ay nasa mga tanong sa interview ayon sa role.

Sinusuri ng mga natitirang tanong kung nailunsad mo na ba talaga ang isang pipeline, hindi lang natapos mo ang isang tutorial.

• Paano magbasa ng data nang episyente? Mga columnar na format tulad ng Parquet, partition pruning sa filter column, at predicate pushdown. Ipaliwanag kung bakit mas mainam ang pagbasa ng mas kaunting byte kaysa sa pag-optimize ng mangyayari pagkatapos.
• Bakit magdedeklara ng schema sa halip na ipahiwatig na lang ito? Ang inference ay may dagdag na pass sa data at maaaring magbunyag ng iba't ibang hula sa type sa bawat run.
• Paano hawakan ang null at duplicate? Ang mga kaugnay na function, kasama na ang punto na ang join key na maraming null ay lumilikha ng skew.
• Para saan ginagamit ang window function? Para sa ranking, running total, at pag-deduplicate papunta sa pinakabagong record kada key, isang napakakaraniwang gawain sa pipeline.
• Paano isulat ang output nang hindi gumagawa ng libu-libong maliliit na file? Mag-coalesce o mag-repartition bago sumulat, at i-partition ang output ayon sa column na may makatuwirang cardinality.
• Paano tina-test ang PySpark code? Gamit ang maliliit na local session na may fixture na DataFrame, at business logic na inilagay sa mga function na tumatanggap at nagbabalik ng DataFrame.
• Paano mag-submit at mag-configure ng job? Ang bilang ng executor, cores, at memory, kasama ang katwiran na parehong nagsasayang ng capacity ang sobrang daming maliliit na executor at ang sobrang kaunting malalaking executor.

Ang mga sagot sa PySpark ay bumabagsak kapag binibigkas nang may kilalang paraan. Alam ng kandidato na mahal ang shuffle pero hindi niya masabi kung aling mga operation ang sanhi nito, kaya nagiging listahan na lang ng mga adjective ang sagot. Ang pagbabasa ng question bank ay lumilikha ng pagkakakilala, at hindi ito kapareho ng pagbibigay ng paliwanag habang may naghihintay.

Kumuha ng isang pipeline na ginawa mo at isalaysay ito mula simula hanggang katapusan: ang read, bawat transformation, kung saan bumabagsak ang hangganan ng stage, at kung ano ang unang che-check mo kung bumagal ito. Gawin ito nang malakas hanggang hindi ka na paulit-ulit na nagsisimula. Ang pagsasanay sa mga tanong na ito laban sa isang AI interviewer na nagtatanong ng follow-up ay mas malapit sa totoong round kaysa sa pagbabasa ulit ng notes, at iyon ang layunin ng mode na mock interview.

Si Aaron Cao, founder ng SubcueAI, ay bumuo ng pagsasanay sa paligid ng puwang na iyon sa pagsasalita sa halip na sa pagdaragdag lang ng mas maraming tanong. Sa isang live na interview, ang desktop app at ang Side Panel ng browser extension ay puwedeng ipakita ang structure habang nagsasalita ang interviewer, na pinakanakakatulong sa materyal na na-praktis mo na. Ilang minuto lang ang setup at nakasaad ito sa page na tutorial.