Otázky K Pohovoru PySpark

Autor: Aaron Cao · Aktualizováno

Otázky K Pohovoru PySpark
Pohovory na PySpark se soustředí na model provádění a na výkon. Očekávejte vysvětlení rozdílu mezi transformation a action, určení, které operace způsobují shuffle, volbu broadcast joinu, diagnózu data skew, zdůvodnění cachování a popis, jak byste doladili job, kterému dochází paměť.

Pohovory na PySpark se soustředí na model provádění a na výkon. Očekávejte vysvětlení rozdílu mezi transformation a action, určení, které operace způsobují shuffle, volbu broadcast joinu, diagnózu data skew, zdůvodnění cachování a popis, jak byste doladili job, kterému dochází paměť.

Na co se tazatelé ptají ohledně modelu provádění?

Umíte napsat funkční PySpark a přesto tu můžete klopýtnout, protože tyto otázky se ptají, co dělá engine, ne co říká váš kód. Tazatelé jimi otevírají právě proto, že oddělují lidi, kteří job doladili, od těch, kteří ho jen spustili. Tato část pokrývá modelové otázky a to, co obsahuje úplná odpověď.

  • Transformation nebo action, jaký je rozdíl? Transformation sestaví plán a lazy vrátí nový DataFrame; action jako count, collect nebo zápis spustí provedení. Nic se nepočítá, dokud si action nevyžádá výsledek.
  • Proč je lazy chování užitečné? Optimizer vidí celý řetězec před spuštěním, takže může přeuspořádat filtry, ořezat sloupce a spojit kroky.
  • Narrow nebo wide transformace? Narrow operace jako filter a select udržují každou výstupní partition závislou na jedné vstupní partition. Wide operace jako groupBy, join a distinct přerozdělují data mezi partitions, což je shuffle.
  • Co je shuffle a proč záleží? Data se přesouvají po síti a dotknou se disku, čímž vzniká hranice stage. Obvykle je to nejnákladnější věc, kterou job dělá.
  • Vysvětlete job, stage a task. Action spustí job, hranice shuffle ho rozdělí na stages a každý stage spustí jeden task na partition.
  • RDD, DataFrame nebo Dataset? Upřednostněte DataFrame, protože tam platí Catalyst optimizer a sloupcové provádění. RDD zůstávají pro nízkoúrovňovou kontrolu. Typované Dataset jsou koncept JVM, takže v Pythonu je poctivá odpověď, že se neuplatňují.

Vyslovte slova shuffle a stage, když patří do odpovědi. Tazatelé je používají jako zkratku k tomu, zda jste někdy četli Spark UI.

Jak odpovídat na otázky o výkonu?

Většina seniorních pohovorů na PySpark jsou pohovory o výkonu. Otázky přicházejí jako scénáře, ne jako definice.

  • Join je pomalý. Co zkontrolujete? Nejprve velikost každé strany. Pokud se jedna vejde do paměti executoru, udělejte jí broadcast a shuffle úplně přeskočte. Jinak se před sáhnutím na velikost clusteru podívejte na partitioning a skew.
  • Co je data skew a jak to opravit? Několik key drží většinu řádků, takže jeden task běží dlouho poté, co ostatní skončí. Řešení zahrnují salting hot key, broadcast menší strany nebo filtrování null hodnot, které se všechny hashují na stejné místo. Diagnostickým signálem je rozptyl doby trvání tasků ve Spark UI.
  • Kdy použijete cache nebo persist? Když se DataFrame znovu používá napříč více action a přepočítání by bylo nákladné. Cachování něčeho použitého jednou plýtvá pamětí a unpersist má význam u dlouhých jobů.
  • Repartition nebo coalesce? Repartition dělá shuffle a může partitions rovnoměrně zvýšit nebo snížit; coalesce slučuje bez plného shuffle, což je levnější způsob, jak snížit počet výstupních souborů.
  • Proč se vyhýbat Python UDF? Řádky se serializují mezi JVM a procesem Pythonu a optimizer nevidí dovnitř funkce. Upřednostněte vestavěné funkce a k vectorized UDF sáhněte, jen když vestavěná neexistuje.
  • Proč je collect nebezpečný? Stáhne celý výsledek na driver a může vyčerpat jeho paměť.
  • Job selže s out of memory. Jaké je vaše pořadí zkoumání? Zda je to driver nebo executor, pak skew, pak velikost partitions, pak konfigurace paměti. Zvýšení paměti jako první krok je odpověď signalizující nedostatek zkušeností.

Data engineera, který měl pohovor pro platformový tým, se zeptali, proč noční job běžící rok najednou trval čtyři hodiny. Odpovědí, která zabodovala, nebyla změna konfigurace, ale to, že jeden upstream partner začal posílat null v join key, takže se každý null řádek hashoval do stejné partition. Tazatelé odměňují právě toto pořadí: podívat se na data před clusterem.

Související banky otázek podle role najdete pod interview questions by role.

Jaké praktické otázky a otázky o zpracování dat se objevují?

Zbývající otázky ověřují, zda jste nasadili pipeline, a ne jen dokončili tutorial.

  • Jak efektivně čtete data? Sloupcové formáty jako Parquet, partition pruning na filtrovaném sloupci a predicate pushdown. Vysvětlete, proč je čtení méně bytů lepší než optimalizace toho, co se děje potom.
  • Proč definovat schema místo jeho odvozování? Inference stojí extra průchod daty a může mezi běhy nekonzistentně hádat typy.
  • Jak řešíte null hodnoty a duplicity? Relevantní funkce a k tomu fakt, že join key plné null hodnot vytvářejí skew.
  • K čemu se používají window function? Řazení, běžící součty a deduplikace na nejnovější záznam podle key, velmi běžný úkol pipeline.
  • Jak zapíšete výstup bez tisíců malých souborů? Coalesce nebo repartition před zápisem a partitionování výstupu podle sloupce s rozumnou kardinalitou.
  • Jak testujete kód PySpark? Malé lokální session s fixture DataFrame a business logika rozdělená do funkcí, které přijímají a vracejí DataFrame.
  • Jak job odešlete a nakonfigurujete? Počet executorů, jader a paměti a úvaha, že jak příliš mnoho malých executorů, tak příliš málo velkých plýtvá kapacitou.

Jak byste se měli připravovat před pohovorem?

Odpovědi na PySpark selhávají nahlas rozpoznatelným způsobem. Kandidát ví, že shuffle je nákladný, ale neumí říct, které operace ho způsobují, takže odpověď se stane seznamem přídavných jmen. Čtení banky otázek vytváří rozpoznání, a rozpoznání není totéž co vysvětlení podané, zatímco někdo čeká.

Vezměte si jednu pipeline, kterou jste postavili, a odvyprávějte ji od začátku do konce: read, každou transformation, kde padají hranice stage a co byste zkontrolovali jako první, kdyby se zpomalila. Dělejte to nahlas, dokud nepřestanete začínat znovu. Trénování těchto podnětů proti AI tazateli, který se doptá dál, je blíž skutečnému kolu než opětovné čtení poznámek, a přesně na to je postavený režim mock interview.

Aaron Cao, zakladatel SubcueAI, postavil trénink kolem této mezery v mluvení, ne kolem dodávání dalších otázek. V živém pohovoru mohou desktopová aplikace a Side Panel v rozšíření prohlížeče vynést strukturu na povrch, zatímco tazatel mluví, což pomáhá nejvíc u materiálu, který jste si už procvičili. Nastavení trvá pár minut a je popsané na stránce tutorial.

Časté dotazy

Zahrnují pohovory na PySpark živé kódování?

Často ano. Běžným úkolem je join plus agregace, nebo deduplikace na nejnovější řádek podle key pomocí window function. Tazatelé sledují, zda sáhnete po vestavěných funkcích místo UDF a zda partitioning zmíníte bez vyzvání.

Kolik SQL potřebuji pro roli PySpark?

Docela dost. Spark SQL a DataFrame API vyjadřují stejné operace a mnoho týmů píše joiny a window function přímo v SQL. Počítejte s alespoň jednou otázkou, na kterou dokážete odpovědět oběma způsoby.

Měl bych se učit Scalu na pohovor o Sparku?

Ne pro roli PySpark. Pomůže vědět, že Spark běží na JVM a že Python UDF platí náklady na serializaci přes tuto hranici, přesně proto se upřednostňují vestavěné funkce.

Jaká je nejčastější chyba na pohovoru o PySpark?

Odpovídat na otázky o výkonu velikostí clusteru. Tazatelé chtějí, aby se nejdřív prozkoumala data: velikosti partitions, skew, strategie joinu a kolik se čte. Přidání executorů jako první krok signalizuje omezenou produkční zkušenost.

Může mi AI asistent pomoct během živého pohovoru na data engineering?

Může vynést strukturu na povrch, zatímco tazatel mluví, což je nejužitečnější u materiálu, který už znáte. Nenahrazuje nácvik a sdílení obrazovky, nahrávané session, hlídané testy a firemní notebooky zůstávají mimo rozsah.

Související otázky

← Více o Otázky k pohovoru podle role a tématu