Вопросы на собеседовании по PySpark

Можно писать рабочий код на PySpark и всё равно спотыкаться здесь, потому что эти вопросы касаются того, что делает движок, а не того, что написано в коде. Интервьюеры часто начинают именно с них, потому что такие вопросы отделяют тех, кто настраивал job, от тех, кто просто один раз его запустил. В этом разделе рассматриваются вопросы о модели выполнения и то, что должен включать полный ответ.

• В чём разница между transformation и action? Transformation строит план и лениво возвращает новый DataFrame; такие action, как count, collect или запись, запускают выполнение. Ничего не вычисляется, пока action не запросит результат.
• Чем полезны ленивые вычисления? Оптимизатор видит всю цепочку до её выполнения, поэтому может переставить фильтры, убрать ненужные столбцы и объединить шаги.
• Узкая или широкая трансформация? Узкие операции, такие как filter и select, оставляют каждую выходную партицию зависимой от одной входной. Широкие операции, такие как groupBy, join и distinct, перераспределяют данные между партициями, а это и есть shuffle.
• Что такое shuffle и почему это важно? Данные передаются по сети и попадают на диск, формируя границу stage. Обычно это самая затратная часть работы job.
• Объясните, что такое job, stage и task. Action запускает job, границы shuffle делят его на stage, а каждый stage запускает по одному task на партицию.
• RDD, DataFrame или Dataset? Предпочтительнее DataFrame, поскольку к нему применяются оптимизатор Catalyst и колоночное выполнение. RDD остаются нужны для низкоуровневого контроля. Типизированный Dataset представляет собой концепцию JVM, поэтому в Python честный ответ такой: он не применим.

Произносите слова shuffle и stage, когда они уместны в ответе. Интервьюеры используют их как быстрый способ понять, смотрели ли вы вообще в Spark UI.

Большинство senior-собеседований по PySpark по сути являются собеседованиями о производительности. Вопросы приходят в виде сценариев, а не определений.

• Join выполняется медленно. Что вы проверяете? Сначала размер каждой стороны. Если одна сторона помещается в память executor, её можно передать через broadcast и полностью избежать shuffle. Если нет, стоит посмотреть на партиционирование и перекос, прежде чем менять размер кластера.
• Что такое перекос данных и как его исправить? Несколько ключей содержат большую часть строк, поэтому один task работает ещё долго после того, как остальные уже завершились. Способы исправления включают salting горячего ключа, broadcast меньшей стороны или отфильтровывание значений null, которые все хешируются в одно место. Диагностический сигнал: разброс длительности task в Spark UI.
• Когда использовать cache или persist? Когда DataFrame повторно используется в нескольких action и пересчёт был бы затратным. Кэширование того, что используется один раз, тратит память впустую, а своевременный unpersist важен в длительных job.
• repartition или coalesce? repartition вызывает shuffle и может равномерно увеличивать или уменьшать число партиций; coalesce объединяет их без полного shuffle, что дешевле для уменьшения числа выходных файлов.
• Почему стоит избегать Python UDF? Строки сериализуются между JVM и процессом Python, а оптимизатор не видит, что происходит внутри функции. Предпочтительнее встроенные функции, а к vectorized UDF стоит обращаться только тогда, когда встроенной функции не существует.
• Почему collect опасен? Он забирает весь результат на driver и может исчерпать его память.
• Job падает с ошибкой нехватки памяти. В каком порядке вы будете разбираться? Сначала выяснить, driver это или executor, затем перекос, затем размер партиций, и только потом конфигурацию памяти. Увеличение памяти в качестве первого шага выдаёт недостаток опыта.

Data engineer, проходившего собеседование в platform team, спросили, почему ночной job, стабильно работавший год, вдруг стал занимать четыре часа. Ответ, который сработал, был не про изменение конфигурации: один из upstream-партнёров начал присылать значения null в join key, из-за чего каждая null-строка хешировалась в одну и ту же партицию. Интервьюеры ценят именно такой порядок: сначала посмотреть на данные, а потом на кластер.

Связанные подборки вопросов по ролям находятся в разделе вопросы на собеседовании по ролям.

Остальные вопросы проверяют, действительно ли вы выкатывали pipeline в production, а не просто прошли учебник.

• Как эффективно читать данные? Колоночные форматы вроде Parquet, partition pruning по столбцу фильтрации и predicate pushdown. Объясните, почему чтение меньшего числа байт выгоднее, чем оптимизация того, что происходит после.
• Почему лучше задавать schema явно, а не выводить её автоматически? Автоматический вывод требует лишнего прохода по данным и может по-разному угадывать типы между запусками.
• Как обрабатывать null и дубликаты? Соответствующие функции, а также то, что join key с большим количеством null создают перекос.
• Для чего используются window function? Для ранжирования, накопительных итогов и удаления дубликатов с сохранением самой свежей записи по каждому ключу, это очень частая задача в pipeline.
• Как записать результат, не создав тысячи мелких файлов? Выполнить coalesce или repartition перед записью и партиционировать вывод по столбцу с разумной кардинальностью.
• Как тестировать код на PySpark? С помощью небольших локальных сессий с тестовыми DataFrame и бизнес-логики, вынесенной в функции, которые принимают и возвращают DataFrame.
• Как отправить и настроить job? Количество executor, число ядер и память, а также обоснование того, что и слишком много маленьких executor, и слишком мало больших одинаково расходуют ресурсы впустую.

Ответы по PySpark проваливаются вслух узнаваемым образом. Кандидат знает, что shuffle затратен, но не может сказать, какие операции его вызывают, поэтому ответ превращается в набор прилагательных. Чтение подборки вопросов создаёт узнавание, а узнавание не то же самое, что объяснение, которое даётся, пока кто-то ждёт.

Возьмите один pipeline, который вы сами построили, и расскажите его от начала до конца: чтение, каждую transformation, где проходят границы stage, и что вы проверили бы в первую очередь, если бы всё замедлилось. Проговаривайте это вслух, пока не перестанете начинать заново. Отработка таких вопросов с AI-интервьюером, который задаёт уточняющие вопросы, ближе к настоящему собеседованию, чем перечитывание конспектов, и именно для этого создан режим mock interview.

Aaron Cao, основатель SubcueAI, построил тренировку именно вокруг этого разрыва в устной речи, а не вокруг добавления новых вопросов. На реальном собеседовании десктопное приложение и Side Panel браузерного расширения могут показывать структуру, пока говорит интервьюер, и это помогает больше всего на материале, который вы уже отрепетировали. Настройка занимает несколько минут и описана на странице tutorial.