Там были не квоты а флаги для jvm

так как глю не давал прокидывать флаги и у нас джобы на кодогенерации падали

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

у меня есть пара багов от имени довольно крупных (в своих отраслях) компаний, которые повисели 90 дней, и пришел отлуп - не смогла

одна прям на IAM есть, там кондишены в определенной комбинации не работали

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

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

и потом писать регулярно статьи вида

“ну вот сейчас мы точно уже почти догнали yarn и hdfs, осталось совсем чуть-чуть”
https://www.datamechanics.co/blog-post/apache-spark-performance-benchmarks-show-kubernetes-has-caught-up-with-yarn

так это нормальная статья: general purpose технология с большой распространенностью уже догоняет специализированную легаси технологию на кейсе родном для этой легаси технологии, ура, скоро выкинем легаси - чем плохо?

“скоро выкинем” и “зачем нам сейчас” это разные вещи =)

особенно если по хадуп кластеру 50к+ джобов в день гоняется на петабайтах данных
вот когда догонят и можно будет выкидывать, тогда и можно будет говорить что hdfs/yarn не нужен
пока же “всё сложно"

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

для большинства кубик в клауде за глаза
тут я согласен

так они сравнивают yarn и k8, файлы то все равно в hdfs в этом тесте, вот если бы они вместо dfsчто-то s3-like тестировали, было бы интереснее

там не было про хдфс
вроде как в гугловом сторейдже

так как сама компания занимается предоставлением server less спарка

что уже потеря многих фишек от даталокалити

непонятный бенч. я так и не понял что с чем сравнивают. получается, сейчас куб дает забирает 5% перформанса на ровном месте что-ли
тест же на локальных ссд

про локальные диски там было в контексте оптимизаций

что для шафла лучше использовать их, так как даёт более адекватную прозводительность
но в клауде зачастую подключаются remote, скорость которых пропорциональна размеру

поэтому или используйте локальные
или уже побольше размер для ремоут дисков запрашивайте

As we've shown, local SSDs perform the best, but here's a little configuration gotcha when running Spark on Kubernetes.

Simply defining and attaching a local disk to your Kubernetes is not enough: they will be mounted, but by default Spark will not use them. On Kubernetes, a hostPath is required to allow Spark to use a mounted disk.

то есть в случае кубика доп манипуляции с необходимы
без этого ещё больше разница будет чем 5%

@barloc там же линк на их сессию со спарк саммита, где более подробно рассказывают

https://databricks.com/session_na20/running-apache-spark-on-kubernetes-best-practices-and-pitfalls

хотя пару слайдов попахивают булшитом
особенно когда рассказывают про глобальную версию спарка во всём ярн кластере

по ней и писалась статья
ну или доклад готовили на основе статьи

=)

обмен фишек даталокалити на фишки распределенного масштабируемого объектного стораджа