ПФ
Есть ещё путь собирать fat jar и он кажется самым логичным
Size: a a a
2021 October 04
NN
Так через spark.jars.package как нефиг делать его прокинуть, и не придется отдельного толстого собирать
ПФ
ну в смысле ничо особо не надо, ты просто передаёшь один джарник и всё, а иначе всё сложно становится
ПФ
версии там обновлять, транзитивные зависимости и так далее
NN
А какие могут быть проблемы с версиями и зависимостями, если ты как jars или jars.package кидаешь? Я прост не сталкивался.
ПФ
Ну я может чего не понимаю, но как Apache POI так воткнуть?
ПФ
А, package выкачивает!
ПФ
Тогда проблемы такие: туда нельзя подсунуть кастомный репозиторий
ПФ
по крайней мере я не смог
ПФ
Формально через —repoitories, но я не смог
ПФ
Эта штука должна подцеплять ivy config, но у нас не смогла
NN
У меня работало, когда spark.jars.ivy устанавливал нужный
ПФ
ну может мне рук не хватило, хрен знает. Но проблемы всё равно очевидные: с машины со спарком должна быть доступна репа, а этого может и не быть
NN
А чем тебя просто jar не устраивает? В чем будет лучше fat jar?
ПФ
ну вот в jar же нету зависимостей, а это плохо
ПФ
нельзя не только зашипать кастомные библиотеки, нельзя ещё и кастомный спарк зашипать
GP
ниясна что говоришь; кастомный Спарк - кастомный класспас
NN
А можно пример?
Я мб в мире пуспарка чето не так воспринимаю
Я мб в мире пуспарка чето не так воспринимаю
ПФ
Я в пайспарке вообще ничего не понимаю. Но вот я себе сделал кастомную читалку датафреймов из экселя с помощью apache poi, допустим. apache poi тащит за собой десятки библиотек. Как мне их шипнуть на кластер?
ПФ
вообще не обязательно! Можно на спарке 2.3 вполне крутить фэтджары с зашитым третьим спарком