Если мы говорим о экосистеме, то она больше

Просто когда говорят про хадуп, то мне всегда интересно про какую часть. Hdfs, yarn, zookeeper, вычислительный фреймворк который запускаешь внутри

Я в основном имею ввиду все сразу

И чем тебе Грааль в ярне поможет, ничем сильно, только при запуске локализации быстрее отработает, за счёт субстратвм. Сам ярн совсем легкий, там вся логика в том как ресурсы резать и ТД. Вот в hdfs уже что-то может и выдаст, если промахнулись с локалити или пишем много (а там ещё и рейд на нем сейчас запили).  Все остальное уже просто вопросы к продуктам

Мне в ярне вряд ли, а вот для спарк джоб надо проверить гипотезу

В параметрах к ярн джобе можна на отправке указать какую jvm использовать для запуска задач

В итоге вроде хадуп останется на своих местах, а Спарк уже на нужной тебе полетит

Если честно, то я не работал на проектах с проблемами производительности, требующими такой оптимизации. Из оптимизаций было только нужно на одном проекте перейти на реактивный подход из-за >500>35к HTTP запросов на разные удаленные сервисы с каждого HTTP запроса пользователя.

Какой ты видишь юз-кейс?

Потому что использовать native-image ещё как минимум пару лет пионерство, мне кажется, you code it, you own it. Чтобы получить пользу, я вангую, надо чтобы он вообще не тормозил разработку ни из-за learning curve, ни через неожиданные поведения.

Если говорить про спарк, то там много кодогенерации если slarksql используешь, периодически даже ловишь ексеплен на больших sql что не могу скомпилировать метод, больше 64к байт (он генерит Java класс и компилирует на лету), в итоге можно предложить что там за границы 8к байт на метод выскакивает он регулярно когда jit уже отключается

Вот тут мне и интересно как Грааль себя поведет, какие у него максимальные лимиты на входной метод

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

Надо будет попробовать на реальных юзкейсах, you don't know what you don't know :) Я вряд ли смогу, так как у меня только Spark ML на питоне.

прост в хадупных проектах ужасное качество кода само по себе, и это скорее всего перевесит то что может дать грааль (в отличие от того что удалось со скалкой получить твиттеру)

@optician_owl а можно более обоснованно и по пунктам?

* Те сорцы, что я смотрел сделаны весьма странно и наполнены всяким легаси кодом, который никто не поправил (но хадуп 3ий и новый хбейз к примеру я уже не видел, правда и иллюзий не питаю). ОБычно там логика либо совсем ненужная (дублирующиеся проверки, странные решения в принципе, там где можно сделать проще), либо как шрам от рефакторинга с соответствующими комментами (типа давайте сделаем еще что нить здесь).
* Со скалкой основной траблой производительности являются лишние аллокации, вызванные врапперами. Это по-крайней мере понятно как можно в рантайме оптимизировать. А вот целую логику уже не переписать, не зная предметной области (формальной спеки).

т.е. эт вообще проблемы разного порядка
принципиальная общая трабла одного компиллятора, которая есть везде и специфичное для конкретного приложения

Ну хз, из того что я видел в хадупе не все идеально, но имеет смысл зачастую

Проверки да, бывают дублирующиеся в разных методах