Распределённая обработка больших объёмов данных: тот случай, когда данные не помещаются на одну машину.
Ключевые тезисы
- Ленивые вычисления: план строится целиком и оптимизируется перед запуском.
- Главный враг производительности — shuffle: перераспределение данных между узлами.
- Перекос ключей (data skew) делает одну задачу в сто раз дольше остальных — лечится солью в ключе.
Подробный разбор
2 подтем — раскройте любую, чтобы увидеть объяснение, формулы, примеры и интерактивные графики.
1Shuffle — главный источник тормозов
Что происходит при join и groupBy.
Shuffle перераспределяет данные между узлами по ключу: это сеть, диск и сериализация. Один лишний shuffle может удвоить время джоба.
- Broadcast join: если одна таблица мала (сотни мегабайт), её рассылают на все узлы — shuffle не нужен.
- Перекос ключей: добавьте «соль» к ключу и агрегируйте в два этапа.
- Партиционирование заранее:
repartitionпо ключу джойна экономит shuffle в цепочке операций.
2Ленивые вычисления и план
Почему ошибка вылезает не там, где написана.
Трансформации только строят план; выполнение начинается при action (count, write, collect). Поэтому исключение возникает в момент действия, а стек указывает не на проблемную строку кода.
df.explain() показывает физический план — по нему видно, будет ли broadcast join, сколько shuffle и какие фильтры протолкнулись к источнику.
Связанные темы
Платформа данных
Warehouse, Lake, Lakehouse80%
Хранилище, озеро, lakehouse · Инженерия данныхТри способа хранить аналитические данные: строгая схема, сырые файлы или гибрид с транзакциями поверх объектного хранилища.
File Formats80%
Форматы хранения · Инженерия данныхКолоночные форматы против строковых: почему Parquet почти всегда лучше CSV для аналитики.
Partitioning80%
Партиционирование · Инженерия данныхРазделение данных по ключу (обычно по дате), чтобы запрос читал минимум файлов.
Analytical SQL80%
Аналитический SQL · Инженерия данныхОконные функции, агрегации и CTE — основной инструмент подготовки признаков на больших данных.
ETL vs ELT80%
ETL и ELT · Инженерия данныхПреобразовывать данные до загрузки или уже внутри хранилища — и почему индустрия сместилась ко второму.
Batch and Streaming80%
Батч и стриминг · Инженерия данныхОбработка по расписанию против непрерывной обработки событий. Разные задержки, разные гарантии, разная стоимость.
Orchestration80%
Оркестрация пайплайнов · Инженерия данныхПланировщик, который знает зависимости между задачами, повторяет упавшие и не даёт запускать одно и то же дважды.
Kafka80%
Kafka · Инженерия данныхРаспределённый журнал событий: основа потоковой архитектуры и источник данных для онлайн-признаков.
ML Pipelines80%
ML-пайплайны · MLOpsОформление обучения как воспроизводимой последовательности шагов вместо разрозненных ноутбуков.
Data Versioning80%
Версионирование данных · MLOpsДанные меняются чаще кода — без их версий эксперимент не воспроизвести.