а как жава в контейнерах связана с хостом?

Дойду до компа скину команду какой запускал, в тикете осталась, больше рнд задача была, в контексте насколько реально запускать pyspark с нативными либами

Всё реально и работало, но так как по быстрому пофиксилось установкой этих либ на хосты и только 1 человеку это нужно было, то дальше не копали

а что в контейнерах спарковых?

Спарк или что?

типа хочу чтоб и спарки разные под раны разные

Прямо что Кривда говолил:
Ноде менеджер пихает java_home который у него, внутри контейнеров это может быть совершенно другая jvm была, по идее без проблем с хост системы тоже можно монтировать

Там просто несколько идей сразу проверялось

Спарк у нас вообще зоопарк версий, правда все они на hdfs лежат и в момент сабмита указывается какую версию брать

Докер тут не нужен

Почти пустой, только java стояла и так говно по мелочи

звучит короче ниоч чёт

)))

ну хорошо что работает!

Ну спарк у нас уже давно проблема решена, чтобы её решать ещё раз :)

А расскажи как?

Через пол часика как до компа дойду

вот есть у меня кластер ярна

хочу пускать там изолированые жобы в контейнерах

интересно как с хдфс спарк ярном тягать

По мне это разные 2 задачи :)

если совсем кратко

spark.yarn.jars - jars для самого спарка,
spark.jars - доп jar уже пользователей

моя команда собирает спарк с некоторыми нашими agoda specific патчами и либами + бывают бекпорты мелкие в одну spark_assembly.jar и за кидывает в хдфс по условно фиксированному пути /home/spark/assembly/${version}/spark_assembly.jar

дальше мы поддерживаем sbt plugin который добавляет 2 новые команды
run и coordinator

когда пользователь делает run/coordinator то проходят следующие операции:
1) собирается dependencies.jar из всех зависимостей и загружается на hdfs
2) собирается assembly.jar с пользовательским кодом и загружается на hdfs
3) генерируется oozie workflow с правильно проставленными spark.yarn.jars и spark.jars (в первый путь строится на основе указанной версии спарка, второй на основе куда мы загрузили файлы)
4) если это run то просто запуск прямо здесь и сейчас, если это coordinator то ставится в скедулинг в узи на указанные даты

то есть сам спарка всегда на хдфс лежит

чтобы уменьшить загружаемый объем 2 режима работы с dependencies.jar
1) release - мы создаем новый фолдер и туда загружаем dependencies.jar + assembly.jar, всё работает годами, так же проверяем что в момент деплоя нету незакомиченных изменений, без этого ошибка

2) default - после упаковки dependencies.jar считаем хешсумму, переименовываем в dependencies-{hash}.jar, проверяем есть ли на хдфс, если нету, то загружаем, если есть то только небольшой assembly.jar уходит в кластер, фолдер с dependencies-{hash}.jar чистим регулярно по ттл, поэтому для прод не подходит, но для разработки при передеплое приложения в кластер уходят килобайты

есть команда notebook которая как default заливает всё на хрдс + создаёт notebook в jupyter с корректно проставленными параметрами
пользователь смело переходит в него, запускает кернел и продолжает интерактивную разработку


apache livy (под капотом она дёргает spark-submit для запуска спарков, используем для интерактивных нодебуков в связке со sparkmagic)
в случае если в конфиге на отправку видит spark.yarn.jars и spark.jars, то генерит корректный конфиг и не пытается загружать спарк из класспаса, поэтому одна версия спарка 2.х может скедулить любое количество версий

проблемы только в том что в 3й версии спарка они один проперти файл разделили на 2
поэтому второй спарк может сабмитить только второго
третий только третьего

пришлось поднять второй сервер ливви с третьим спарком

@pomadchin =) как-то так