Я тут волею случая начал работать с Databricks и задался вопросом, а что у них за ресурс менеджмент отвечает. Прочитал вот это https://databricks.com/blog/2017/06/07/databricks-serverless-next-generation-resource-management-for-apache-spark.html и не очень понял детали

@renardeinside можешь поделиться инсайдом?

могу, только у меня смутное ощущение что с 2017 эта фича переименовалась в High Concurrency Cluster. Дай внутри по докам полистаю, чтобы глупость не сморозить 🙂

Мой вопрос исключительно практический. Каким образом датабриксу удается работать в AWS на спотовых инстансах, как происходит менеджмент ресурсов и что там с шаффл сервисом. Если что NVIDIA - официальный кастомер датабрикса, поэтому если что-то непубличное, то можем отправить оффициальный реквест

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

Ок, спасибо

Интересно как они используют спотовые инстансы. Их же могут в любой момент забрать. Значит там нельзя хранить временные данные. Иначе эти данные пропадут при отключении. Выходит , что нужен обязательный шафл сервис, который будет жить уже не на спотовых или с репликацией. Иначе придется джобу с начала самого запускать , а не только таску перезапустить в случае terminate для спотового

Да-да, в этом и вопрос

почему же нельзя то. Спарк просто пересчитает потерянные партиции

воркерам норм быть в spot, драйвер в спотах лучше не брать, но это по понятным причинам

Ответ немного не в тему, так как про EMR, но, думаю, должно быть что-то похожее.

В обычном EMR у нод есть тег. Когда создаешь группу, указываешь CORE она или WORKER. WORKER делают работу и допускают Spot Instance. на CORE работает driver и они на on-demand машинах. То есть, фишка в тегах.
При этом я не в курсе тонкостей HDFS. В сеттинге EMR часто все данные хранят на S3, HDFS используется самим Spark для хранения temp данных. Или в вашем pipeline вы хотите посчитать что-то “полу-персистентное” (используй, если есть, посчитай и используй иначе).
Теоретически можно и CORE машины запускать на Spot’ах. Но если обычный Worker убили - просто пересчитаются несколько tasks, все произойдет прозрачно. Если убили драйвер - весь application придется перезапускать.

Hint: для Worker в проде используйте 2 разных типа spot машин, так как возможны каскадные отключения.

Что значит два разных типа машин и что такое каскадные отключения?

в emr разные конфигурации машин (память-процессор-диск), если у тебя спотовые машины, то возможно кто-то придет и попросит (заплатит больше) много машин этого типа в этом регионе, у тебя их заберут

Он же данные во время шафла запишет на локальные диски на воркере. И вот если он в следующим стэйдже начнет их читать , а они в это время пропадут , то перезапуск таска не поможет. Придется весь джоб пернзапускать

так должны пересчитаться те, части которых не хватает, почему весь джоб?

Наверное в идеале можно сделать , что если во время stage1 мы идём за файлом ,который сгенерил stage0, а там его нет , то нужно перезапустить таску X для stage0, но тогда что делать с тасками stage1 . Наверное нужно прекратить stage1. Перезапустить некоторые таски на stage0 . И так рекурсивно. А потом запустить stage1 вновь.

зачем прекращать, они просто ждут пока необходимые части появятся

Но это нестандартная логика. Он по умолчанию таски уже завершенных стэйджа не запускает заново. Только текущего.

Если ждать , то может дэдлок быть. Например у нас заняты все экзекьютеры. А мы запускаем таску для пересчёта, которая должна пересчитать то,чего мы ждём

на этом экзекетуре и пересчитываем нужную часть