Как снизить счёт за Databricks/EMR/Glue, ничего не сломав?

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

Низкий риск — начните с этого

• Подбирайте число инстансов по реальной утилизации, а не по пику, под который вы однажды заложились. Если средняя загрузка CPU по executor'ам задачи держится ниже 40%, вы почти наверняка переплачиваете за ресурсы — это почти бесплатный выигрыш, поскольку вообще не меняет логику задачи.
• Включите автомасштабирование, если ещё не включили. Фиксированный размер кластера означает круглосуточную оплату пиковой мощности. Большинство управляемых Spark-платформ (Databricks, EMR) поддерживают это из коробки с минимальной настройкой.
• Переносите подходящие батчевые нагрузки на spot/preemptible-инстансы. Повторяемая, чекпоинтящаяся батчевая задача (не долгая stateful-потоковая) обычно хороший кандидат, часто с экономией 60-90% по сравнению с on-demand ценой.

Средний риск — сначала протестируйте

• Снижайте число shuffle-партиций, если оно выставлено с запасом. Меньше, но крупнее партиции — меньше накладных расходов на планирование задач, но перебор снова создаёт проблемы с нагрузкой на память, ради избежания которых высокое число, вероятно, и было выставлено — проверяйте по времени GC и объёму сброса на диск после изменения, а не только по итоговому времени выполнения.
• Объединяйте мелкие частые задачи в меньшее число крупных прогонов. Время старта/прогрева кластера — фиксированные накладные расходы, оплачиваемые при каждом запуске; задача, запускающаяся каждые 5 минут, платит эти расходы в 12 раз чаще той же работы, собранной почасово.

Более высокий риск — нужна реальная проверка

• Смена семейства инстансов (например, memory-optimized на general-purpose) меняет соотношение память/ядро, под которое задача была неявно настроена — экономия на бумаге может на практике обернуться регрессией производительности или OOM.
• Агрессивные изменения TTL/lifecycle для промежуточного хранилища экономят на хранении, но могут незаметно сломать всё, что дальше по цепочке полагалось на наличие этих данных.