ПФ
Я переживаю
Size: a a a
2020 June 03
ПФ
Вот прямо сейчас
A
Там больше времени уходит на алокации ресурсов и последующий сбор самого кластера
A
Я переживаю
Можешь описать проблему, а то даже интересна причина
С хадупом работал достаточно, немного видел спарк на кубере
С хадупом работал достаточно, немного видел спарк на кубере
OS
Паша, вообще надо попробовать сделать так чтобы janino инициализировался в build-time
OS
и все что ему надо сделал
OS
и загрузил классы и все такое
OS
и потом не использовался
OS
разумно? я не знаю что такое janino но звучит что так могло бы
ПФ
Паша, вообще надо попробовать сделать так чтобы janino инициализировался в build-time
ну там он по природе динамический. Например у меня на вход может приходить какой-то параметр, который будет определять ветвление в маппинге. А маппинг вызывает кодогенрацию
A
Спарк разбирает запрос, строит его план, генерирует java код, janino как лёгкий и быстрый компилятор делает из него байткод, а он уже выполняется на воркерах
ПФ
Ну то есть ответ — нет, janino — это просто компилятор джавы специфический
A
@shelajevoleg поэтому тут вопрос был не просто запустить, но и последующая работа
ПФ
Можешь описать проблему, а то даже интересна причина
С хадупом работал достаточно, немного видел спарк на кубере
С хадупом работал достаточно, немного видел спарк на кубере
Ну я сделал kotlin-spark-api. Он отлично работате локально, но это занимает кучу времени. А я бы хотел показать демо того, как он эот может делать быстро
A
Для локал запуска да, имело бы смысл, но нет :)
ПФ
нелокал это не имеет никакого смысла вообще
ПФ
Ну точнее как какую-нить лямбду или типа того можно было бы использовать
ПФ
сама кодогенерация и компиляция — это очень быстро
A
Да, поэтому я и спросил, так как в кластере ресурсов дольше ждёшь на алокаторах