Питання Співбесіди PySpark
Автор: Aaron Cao · Оновлено

Співбесіди з PySpark зосереджені на моделі виконання та на продуктивності. Очікуйте пояснення різниці між transformation і action, визначення, які операції спричиняють shuffle, вибору broadcast join, діагностики data skew, обґрунтування кешування та опису того, як ви налаштували б job, якому бракує пам'яті.
Що запитують інтерв'юери про модель виконання?
Можна писати робочий PySpark і все одно спіткнутися тут, бо ці питання про те, що робить рушій, а не про те, що каже ваш код. Інтерв'юери відкривають ними саме тому, що вони відрізняють людей, які налаштовували job, від тих, хто лише його запускав. Цей розділ охоплює питання про модель і те, що включає повна відповідь.
- Transformation чи action, у чому різниця? Transformation будує план і ліниво повертає новий DataFrame; action, як-от
count,collectабо запис, запускає виконання. Нічого не обчислюється, доки action не запросить результат. - Чому лінивість корисна? Optimizer бачить весь ланцюжок перед виконанням, тому може перевпорядкувати фільтри, обрізати колонки й об'єднати кроки.
- Narrow чи wide transformation? Narrow-операції, як-от
filterіselect, тримають кожну вихідну партицію залежною від однієї вхідної. Wide-операції, як-отgroupBy,joinіdistinct, перерозподіляють дані між партиціями, а це shuffle. - Що таке shuffle і чому це важливо? Дані рухаються мережею і торкаються диска, формуючи межу stage. Зазвичай це найдорожча дія, яку виконує job.
- Поясніть job, stage і task. Action запускає job, межі shuffle розбивають його на stages, і кожен stage запускає один task на партицію.
- RDD, DataFrame чи Dataset? Надавайте перевагу DataFrame, бо саме там діють optimizer Catalyst і колонкове виконання. RDD лишаються для низькорівневого контролю. Типізовані Dataset є концепцією JVM, тож у Python чесна відповідь у тому, що вони не застосовуються.
Вживайте слова shuffle і stage, коли вони доречні у відповіді. Інтерв'юери використовують їх як швидкий спосіб зрозуміти, чи читали ви коли-небудь Spark UI.
Як відповідати на питання про продуктивність?
Більшість співбесід з PySpark для senior-рівня є співбесідами про продуктивність. Питання надходять як сценарії, а не як означення.
- Join працює повільно. Що ви перевіряєте? Спершу розмір кожної сторони. Якщо одна вміщується в пам'ять executor, зробіть broadcast і повністю уникніть shuffle. Інакше подивіться на partitioning і skew, перш ніж чіпати розмір кластера.
- Що таке data skew і як це виправити? Декілька key утримують більшість рядків, тож один task виконується довго після того, як інші завершилися. Способи виправлення включають salting гарячого key, broadcast меншої сторони або фільтрацію null-значень, які всі хешуються в одне місце. Діагностичний сигнал: розкид тривалості task у Spark UI.
- Коли ви робите cache чи persist? Коли DataFrame повторно використовується в кількох action, а повторне обчислення було б дорогим. Кешування того, що використовується один раз, витрачає пам'ять даремно, а unpersist важливий у довгих jobs.
- Repartition чи coalesce? Repartition виконує shuffle і може рівномірно збільшити або зменшити кількість партицій; coalesce об'єднує без повного shuffle, що дешевший спосіб зменшити кількість вихідних файлів.
- Чому варто уникати Python UDF? Рядки серіалізуються між JVM і процесом Python, і optimizer не бачить середину функції. Надавайте перевагу вбудованим функціям, а до vectorized UDF звертайтеся, лише коли вбудованої немає.
- Чому
collectнебезпечний? Він тягне весь результат до driver і може вичерпати його пам'ять. - Job падає з помилкою out of memory. Який ваш порядок розслідування? Чи це driver чи executor, потім skew, потім розмір партицій, потім конфігурація пам'яті. Збільшення пам'яті першим кроком є відповіддю, яка вказує на брак досвіду.
Data engineer, який проходив співбесіду для платформної команди, спитали, чому нічний job, що працював рік, раптом почав тривати чотири години. Правильною відповіддю була не зміна конфігурації, а те, що один upstream-партнер почав надсилати null у ключі join, тож кожен null-рядок хешувався в одну партицію. Інтерв'юери винагороджують саме такий порядок: спершу подивіться на дані, потім на кластер.
Пов'язані банки питань за роллю розміщені під interview questions by role.
Які практичні питання й питання про обробку даних трапляються?
Решта питань перевіряють, чи випускали ви pipeline у продакшн, а не просто завершили tutorial.
- Як ефективно читати дані? Колонкові формати, як-от Parquet, partition pruning за колонкою фільтра та predicate pushdown. Поясніть, чому читання меншої кількості байтів краще за оптимізацію того, що відбувається потім.
- Чому визначати schema замість того, щоб її виводити? Виведення коштує додаткового проходу по даних і може непослідовно вгадувати типи між запусками.
- Як ви обробляєте null-значення й дублікати? Відповідні функції, плюс той факт, що ключі join, переповнені null, створюють skew.
- Для чого використовують window function? Ранжування, накопичувальні підсумки та дедуплікація до найновішого запису на key, дуже поширене завдання pipeline.
- Як записати вихідні дані без тисяч дрібних файлів? Coalesce або repartition перед записом, і партиціонування виходу за колонкою з розумною кардинальністю.
- Як ви тестуєте код PySpark? Невеликі локальні сесії з fixture-DataFrame та бізнес-логіка, розкладена на функції, що приймають і повертають DataFrame.
- Як ви подаєте й конфігуруєте job? Кількість executor, ядра й пам'ять, а також аргумент, що і забагато дрібних executor, і замало великих однаково витрачають потужність даремно.
Як варто готуватися перед співбесідою?
Відповіді з PySpark провалюються вголос упізнаваним чином. Кандидат знає, що shuffle дорогий, але не може сказати, які операції його спричиняють, тож відповідь перетворюється на список прикметників. Читання банку питань дає впізнавання, а впізнавання не є тим самим, що пояснення, яке дають, поки хтось чекає.
Візьміть один pipeline, який ви побудували, і розкажіть про нього від початку до кінця: read, кожну transformation, де падають межі stage, і що б ви перевірили першим, якби він сповільнився. Робіть це вголос, доки не перестанете починати спочатку. Тренування цих підказок проти AI-інтерв'юера, який ставить уточнювальне питання, ближче до реального раунду, ніж перечитування нотаток, і саме для цього створено режим mock interview.
Aaron Cao, засновник SubcueAI, побудував практику навколо цього розриву в мовленні, а не навколо постачання ще більшої кількості питань. На живій співбесіді десктопний застосунок і Side Panel розширення браузера можуть виводити структуру, поки говорить інтерв'юер, що допомагає найбільше на матеріалі, який ви вже репетирували. Налаштування займає кілька хвилин і описане на сторінці tutorial.
Часті запитання
Чи включають співбесіди з PySpark live coding?
Скільки SQL мені потрібно для ролі PySpark?
Чи варто вчити Scala для співбесіди зі Spark?
Яка найпоширеніша помилка на співбесіді з PySpark?
Чи може AI-асистент допомогти мені під час живої співбесіди з data engineering?
Схожі запитання
- Які типи запитань трапляються на співбесідах із програмування та як може допомогти ШІ-асистент?
- Які питання ставлять на відеоінтерв'ю HireVue?
- Яких питань про Databricks очікувати на співбесіді?
- Яких питань про .NET очікувати на співбесіді?
- Яких питань очікувати на співбесіді інженера з якості?
- Яких запитань очікувати на квант-співбесіді?