← вся теориятеория к собесу · Spark и большие данные

Когда Spark, а когда pandas

Зачем это спрашивают

«Когда Spark, а когда pandas» - проверка инженерной трезвости DS: кластер под 2 ГБ CSV выдаёт человека, который путает инструмент с религией.

// Рамка ответа: Spark - экскаватор для подготовки данных, а не замена ноутбуку.

Когда Spark оправдан

Spark нужен, когда данные не помещаются на одну машину или считаются на ней часами: распределённые джойны и агрегаты по терабайтам. На гигабайтах pandas, Polars или DuckDB быстрее и проще.

Второй аргумент - данные уже лежат распределённо (S3/HDFS, партиции): вычисление едет к данным. Тянуть терабайт по сети в pandas - антипаттерн сам по себе.

// Overhead Spark фиксированный: подъём джобы, планирование, шаффлы. На маленьких данных он проигрывает ноутбуку на порядки - судить о его скорости по гигабайту нельзя.

shared storage: данные в S3/HDFS (Hadoop Distributed File System) партициями; вычисление едет к ним

Драйвер и экзекьюторы

Драйвер строит план и координирует; экзекьюторы обрабатывают свои партиции параллельно. Всё, что «собрать на драйвер» - collect(), toPandas() - ограничено его памятью.

collect() всего датафрейма «чтобы посмотреть» - классический OOM (out of memory) драйвера. Смотреть это show(n) или limit.

// Типовой DS-путь: тяжёлое сырьё агрегируется Spark'ом до компактного датасета → дальше pandas и sklearn локально.

driver / executors: план и координация / параллельная обработка партиций

Альтернативы до кластера

Прежде чем поднимать кластер: сэмплирование (дорабатывай логику на доле данных), агрегация на стороне БД или ClickHouse, DuckDB прямо по паркетам на ноутбуке.

Эти три хода закрывают удивительную долю «биг-дата» задач без распределёнки вовсе.

// «У нас всё в Spark» - организационная привычка, не технический аргумент. Умение сказать «тут кластер не нужен» ценится на собесе выше знания конфигов.

Как отвечать: «Когда возьмёшь Spark, а когда pandas?»

Критерий двойной: объём и место хранения. Если данные помещаются в память одной машины или считаются на ней за разумное время - pandas/Polars, а по паркетам - DuckDB: без оверхеда кластера это быстрее на порядки. Spark беру, когда терабайты лежат распределённо и нужны тяжёлые джойны-агрегаты по ним - вычисление едет к данным. Мой типовой паттерн: Spark как экскаватор готовит компактный датасет, финальная работа с моделью - локально. И перед кластером всегда проверяю дешёвые ходы: сэмпл, агрегация в базе, DuckDB.

Критерий, паттерн и готовность не брать кластер - трезвость, которую вопрос и проверяет.

На чём валят

−Кластер под 2 ГБ CSV - DuckDB на ноутбуке сделает за секунды.
−collect() всего датафрейма «посмотреть» - OOM драйвера.
−Судить о скорости Spark по маленьким данным - фиксированный overhead съедает всё.
−Тянуть сырые данные к модели вместо агрегации на стороне данных.

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 9, остальные разбираются в тренажёре.

#spark_when1 / 5
Для модели нужны агрегаты по 2 млрд событий, но итоговая таблица — 50 тыс. строк. Как правильно поделить работу между Spark и pandas?
A)Отфильтровать и агрегировать в Spark, а в pandas забрать уже маленький результат через toPandas()
B)Выгрузить все 2 млрд строк в pandas через toPandas() и там посчитать агрегаты привычными методами
C)Считать всё в Spark и в pandas не уходить — смешивать два инструмента в одном пайплайне не получится
D)Выгрузить события в CSV кусками и склеить их в pandas циклом for перед подсчётом
показать ответ и разбор
+A)Отфильтровать и агрегировать в Spark, а в pandas забрать уже маленький результат через toPandas()
// разбор: Принцип «сначала сузь в Spark»: тяжёлую фильтрацию и агрегацию делает распределённый движок, а на драйвер (в pandas) уходит уже компактный результат. toPandas() на 2 млрд строк стянул бы всё на драйвер и уронил его.
#spark_when2 / 5
На каком этапе типового DS-пайплайна Spark приносит больше всего пользы?
A)На обучении самой модели — Spark распараллеливает градиентный спуск нейросети между всеми исполнителями кластера
B)На сборе и подготовке данных: достать, отфильтровать, сджойнить и агрегировать большие таблицы в выборку
C)На подборе гиперпараметров — по сути заменяет собой кросс-валидацию
D)На отрисовке графиков — рисует их заметно быстрее matplotlib
показать ответ и разбор
+B)На сборе и подготовке данных: достать, отфильтровать, сджойнить и агрегировать большие таблицы в выборку
// разбор: Spark в DS — инструмент этапа данных: собрать обучающую выборку из больших распределённых таблиц (фильтры, джойны, агрегаты). Обучение моделей, тюнинг и графики живут в другом стеке (sklearn/torch, matplotlib).
#spark_when3 / 5
Джун уверен: «Spark всегда быстрее pandas, он же распределённый». В чём он неправ?
A)Он прав: благодаря кластеру и параллелизму Spark обгоняет pandas на данных большого и малого размера
B)Неправ, потому что pandas умеет то, чего Spark не умеет, — джойны и группировки
C)Неправ: у распределённости есть оверхед (координация, shuffle); на малых данных pandas в одной памяти быстрее
D)Неправ, потому что Spark работает с Parquet и не читает другие форматы
показать ответ и разбор
+C)Неправ: у распределённости есть оверхед (координация, shuffle); на малых данных pandas в одной памяти быстрее
// разбор: Распределённость не бесплатна: планирование, сериализация, shuffle между узлами. На данных, влезающих в память, pandas без этих расходов быстрее. Spark выигрывает, когда данные не помещаются на одну машину, а не по умолчанию.
#spark_when4 / 5
Коллега поднял Spark в локальном режиме на одном ноутбуке для данных в 500 МБ «чтобы масштабировалось потом». Что не так?
A)На одном узле с малыми данными остаётся лишь оверхед Spark — быстрее pandas/Polars/DuckDB
B)Всё правильно: на одной машине Spark задействует все ядра и оттого стабильно обгоняет pandas
C)Ошибка в том, что локальный режим Spark не предназначен для анализа данных
D)Проблема лишь в том, что не задано число исполнителей
показать ответ и разбор
+A)На одном узле с малыми данными остаётся лишь оверхед Spark — быстрее pandas/Polars/DuckDB
// разбор: Ценность Spark — распределение по кластеру; на одном узле с данными, влезающими в память, остаётся только его цена: старт JVM, построение планов, сериализация между Python и JVM. Для 500 МБ pandas/Polars/DuckDB обычно быстрее и проще. «Масштабируется потом» не оправдывает оверхед здесь и сейчас — переходят на Spark, когда данные реально перестают помещаться на одной машине.
#spark_when5 / 5
Ты знаешь pandas, но данные не влезают в память и нужен Spark. Что даёт pandas API on Spark (pyspark.pandas)?
A)Он превращает Spark обратно в однопоточный pandas, теряя при этом всякую распределённость обработки
B)Он переносит все данные в память драйвера
C)pandas-подобный синтаксис поверх распределённого Spark: код как в pandas, счёт на кластере
D)Это отдельная библиотека, не связанная со Spark
показать ответ и разбор
+C)pandas-подобный синтаксис поверх распределённого Spark: код как в pandas, счёт на кластере
// разбор: pyspark.pandas (бывший Koalas) даёт знакомый pandas-интерфейс, транслируя операции в распределённый Spark. Это снижает порог входа: аналитик пишет почти как в pandas, но обработка идёт на кластере и данные не обязаны помещаться в память. Оговорки: часть pandas-поведения (гарантированный порядок строк, некоторые методы) реализована иначе или отсутствует — это стоит держать в голове.

дальше

Теорию прочитали. Навык ставится повторением

В Сеньорчике эта подтема идёт в ежедневных сессиях: движок возвращает её, пока ответы не станут уверенными, и ведёт прогресс отдельно по каждой подтеме. Теория внутри тоже бесплатна, лимит только на количество вопросов в день.

Открыть тренажёр Вся тема: Spark и большие данные