Архитектура отказоустойчивого планировщика задач. Доклад Яндекса

[virrus]

Интересно про требование отсутствия side effect у джобы. Запись результата во внешнее хранилище вполне себе side effect. Что у вас случается, если от момента записи результата до получения контроллером сообщения об окончании джобы вдруг что-то сломается на ноде? Ну там, электричество закончится.

[Zlobober]

Это хороший вопрос. Большая часть вычислений на кластерах YT это честная batch-обработка данных, находящихся в YT. Для таких классических мапов и редьюсов запись результата производится штатными средствами YT, а они обеспечивают exactly-once семантику, т.к. интегрированны со встроенным в YT механизмом транзакций. Таким образом, если на ноде что-то сломается до сообщения об окончании джоба, записанные, но не закоммиченные выходные данные через какое-то время будут физически подчищены и никуда не попадут.

Если джобы операции по каким-то причинам ходит в по-настоящему внешние сервисы (скажем, сторонние базы данных), то тут ответственность за правильную реакцию на перезапуски джобов ложится на разработчика этой операции. Иногда бывает так, что сайд-эффект является идемпотентным, например, запись по ключу какого-то детерминированного значения — такой сайд-эффект ретраить не страшно.

Если сайд-эффекты неизбежны, а к перезапускам джобов операция не готова, то на этот случай в YT есть возможность заказать тот или иной режим работы «без перезапусков»: планировщик может либо просто игнорировать не завершившиеся успешно джобы, либо тут же аварийно завершать всю операцию.