# Spark Engineering

> Применяйте при диагностике или оптимизации задания Spark по фактическому выполнению; исследуйте кратность соединений, перекос данных, shuffle, spill, безопасность broadcast, разделение данных и сопоставимость измерений производительности.

- Skill: `fbakiyev/spark-engineering` (Agent Skill)
- Install (CLI): `npx skillmds@latest add fbakiyev/spark-engineering`
- Raw SKILL.md: https://api.skillmd.com/api/skills/fbakiyev/spark-engineering/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: fbakiyev (https://skillmd.com/u/fbakiyev)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/fbakiyev/spark-engineering

---


# Разработка и оптимизация Spark

## Поиск узкого места

- Изучите развёрнутые версии Spark и платформы, структуру данных, размещение файлов, план выполнения и значимые метрики стадий: распределение задач, shuffle, spill, нехватку памяти и объёмы чтения и записи.
- Отличайте оценки от фактических измерений. Проверяйте зависящие от версии API и настройки по официальной документации развёрнутой среды.

## Ключевые решения

1. До оптимизации проверьте ключи соединения, кратность, поведение пустых значений и нужную гранулярность результата. Непреднамеренное размножение строк является ошибкой корректности; ускорение такого расчёта её не исправляет.
2. Сравните медленные разделы с типичными, чтобы найти перекос данных или слишком крупные задачи. Выбирайте переразбиение, предварительную агрегацию или обработку перекоса по распределению ключей и физическому плану, сохраняя смысл соединения.
3. Используйте broadcast только после оценки верхней границы размера рассылаемой таблицы и потребности в памяти каждого исполнителя; малая выборка не ограничивает размер полной таблицы. Проверяйте фактический план, а не предполагайте, что подсказка или адаптивное выполнение гарантируют нужную стратегию.
4. Кешируйте данные только при подтверждённом повторном использовании и достаточном бюджете памяти; учитывайте стоимость материализации. Выбирайте разделение результата и размеры файлов по последующему доступу и способу записи, а не по универсальному фиксированному числу разделов.

## Результат и проверка

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

## Ограничения

- Не собирайте неограниченный распределённый набор данных в драйвере и не делайте вывод о достаточности памяти в production по малой выборке.
- Не заявляйте об улучшении только по виду кода и не жертвуйте корректностью ради скорости без явного указания.

## Источник

- [Настройка производительности Spark SQL](https://spark.apache.org/docs/latest/sql-performance-tuning.html); используйте документацию развёрнутой версии.