Насколько хорошо знаком со Spark

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

Спрашивают не про строчку в резюме, а где проходит граница вашего опыта: писали ли вы задачи, которые падали на проде, и понимаете ли модель исполнения. По ответу решают, доверят ли вам пайплайн на терабайты или оставят на ноутбуке с pandas.

Как отвечать

Сначала честная шкала: читал и пробовал, писал батчи в проде, занимался тюнингом и разбором падений. Дальше конкретика:

• модель исполнения: драйвер строит план, исполнители считают партиции, трансформации ленивые, работа начинается только на действии (count, collect, write);
• API: DataFrame проходит через оптимизатор запросов, RDD оставляют там, где нужен низкий уровень. На Python пользовательская функция дороже встроенных из-за сериализации, векторизованный вариант заметно дешевле;
• перемешивание данных: join и groupBy гоняют данные между узлами, это главный источник тормозов. Отсюда broadcast для маленькой таблицы, перепартиционирование по ключу, борьба с перекосом;
• хранение: колоночные форматы, партиционирование, мелкие файлы убивают чтение;
• диагностика: интерфейс Spark, стадии, сброс на диск, сборка мусора, одна задача длиннее остальных.

Если работали со стримингом, уточните, с каким именно: структурированный стриминг с чекпоинтами и водяным знаком, а не абстрактная «потоковая обработка».

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

Отвечают «два года опыта» и не могут объяснить разницу между cache() и persist() или зачем нужен чекпоинт. Стаж без модели исполнения читается как «запускал чужие джобы по инструкции».

Второе: приносят выдуманный прирост качества модели от библиотеки машинного обучения внутри Spark. Spark решает задачу масштаба данных, а не точности, и такая цифра сразу тянет вопрос про методику замера.

Третье: путают ленивость с отсутствием работы. Вызывают collect() на большом наборе, роняют драйвер по памяти и идут искать проблему в настройках кластера вместо своего кода.