В чем разница Spark и MapReduce?

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

Понимаете ли вы, откуда у Spark преимущество, или повторяете лозунг «в сто раз быстрее». Для аналитика следом идёт практика: что такое ленивые вычисления, когда нужен cache() и почему упал драйвер после toPandas().

Как отвечать

Сравнивайте по сути, а не по списку фич:

• модель вычислений: MapReduce делит работу на map, shuffle и reduce. Сложный расчёт это цепочка отдельных задач, и между ними промежуточный результат пишется в HDFS и читается обратно. Spark строит из запроса один DAG, режет его на стадии по границам shuffle и не пишет промежуточные итоги в HDFS;
• память: между шагами Spark может держать данные в памяти через cache() или persist(), это сильно ускоряет итеративные задачи и повторные запросы к одному датасету;
• оптимизатор: DataFrame и Spark SQL проходят через Catalyst, который переставляет фильтры и отсекает лишние колонки и партиции при чтении Parquet. В MapReduce оптимизацию пишете вы сами;
• API: вместо Java-классов Mapper и Reducer аналитик пишет Spark SQL или PySpark, с джойнами и оконными функциями;
• отказоустойчивость: MapReduce перезапускает задачу по данным из HDFS, Spark пересчитывает потерянные партиции по lineage, цепочке преобразований;
• потоки: Structured Streaming работает микробатчами с задержкой порядка секунд, MapReduce только пакетный.

Сегодня MapReduce почти везде легаси. Spark часто живёт поверх той же инфраструктуры: данные в HDFS или S3, ресурсы от YARN или Kubernetes. Он заменил вычислительный движок, а не всю экосистему Hadoop.

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

Говорят «Spark всё держит в памяти». Shuffle у него тоже идёт через диск, то, что не влезло, сбрасывается туда же, а при перекосе данных исполнитель падает с нехваткой памяти.

Не понимают ленивости: трансформации только строят план, считает всё действие вроде count() или write. Без cache() каждое действие заново проходит всю цепочку.

Тянут большой результат на драйвер через collect() или toPandas() и роняют его.