Работали ли вы с Apache Spark?

Что проверяют

Отличаете ли вы «запускал ноутбук с PySpark» от «понимаю, что происходит в кластере». Ответ ценится не списком компонентов, а рассказом про объёмы, шаффлы и то, как вы чинили медленную джобу.

Как отвечать

Сначала коротко про опыт: какие данные, какой объём, как запускалось (кластер YARN, Kubernetes, Databricks, EMR), на чём писали (PySpark, Scala, Spark SQL).

Затем покажите понимание модели выполнения:

• драйвер и исполнители: драйвер строит план, исполнители считают партиции;
• ленивость: трансформации только строят граф, работа стартует на действии вроде count() или write;
• узкие и широкие преобразования: filter и map идут внутри партиции, а groupBy и join вызывают шаффл, то есть передачу данных по сети. Шаффл и есть главная статья расходов;
• DataFrame против RDD: DataFrame и Spark SQL проходят через оптимизатор Catalyst и кодогенерацию Tungsten, поэтому в обычной работе выбирают их, а RDD остаётся для низкоуровневых случаев;
• потоковая обработка: сейчас это Structured Streaming, старый Spark Streaming на DStream считается устаревшим.

Сильная часть ответа это оптимизация: подобрать число партиций, отбирать колонки и фильтровать до соединения, использовать broadcast join для маленькой таблицы, кешировать переиспользуемый датафрейм и обязательно освобождать его, бороться с перекосом ключей (соль, разделение горячих ключей), смотреть Spark UI и план через explain.

Где спотыкаются

Собирают данные на драйвер через collect() и роняют его нехваткой памяти.

Кешируют всё подряд. Кеш занимает ту же память, что и вычисления, и лишний persist замедляет джобу.

Не могут объяснить, почему джоба «висит на последней задаче». Обычно это перекос данных: один ключ собрал большую часть строк.

Путают партиции Spark с партициями таблицы в хранилище.