А откуда эта картинка вообще? Кажется нет никакой юзер мемори. В спарке же unified memory management. Где есть storage и execution. Ну и offheap для всяких спарковских буфферов

я думаю, что под юзер мемори имеется ввиду условная часть хипа, в которой пользовательские обычные объекты, которые создаются в результате трансформаций над рдд и датасетами, или при вызове udf (все кроме встроенных sql операторов).

картинка похожа на эту
https://0x0fff.com/spark-memory-management/

Да, это одно из мест, где я ее встречал.

судя по описанию это
spark.memory.fraction expresses the size of M as a fraction of the (JVM heap space - 300MB) (default 0.6). The rest of the space (40%) is reserved for user data structures, internal metadata in Spark, and safeguarding against OOM errors in the case of sparse and unusually large records.
в 1.6 на это оставляли по умолчанию 0.25, в последних версиях 0.4

Похоже, что это как раз оно, спасибо.

Эта картинка пытливого наблюдателя скорее вводит в заблуждение.
Глядя на нее можно сделать предположение, что память выделяется для каждой области непрерывными диапазонами. Это конечно не так. Спарк не отслеживает никакие диапазоны адрессов потому, что он на JVM. Он отслеживает размер, но и то не всегда, а только когда может. А может он только тогда, когда сам и трэкает это. Т.е пользователь своим обьектом может скушать всю память в спарке вообще, но когда спарк сам запрашивает себе память для хранения итератора в памяти или выполнения группировки, то он проверит сколько он уже взял для этого и не даст больше лимитов.  
Т.е работает это примерно так. Есть память под хип. скажем 1G(systemMemory).Он будет считать, что 300mb(reservedMemory) всегда зарезервированно - set aside a fixed amount of memory for non-storage, non-execution purposes. А для мемори менеджера(фактически для execution и storage) доступно тогда (systemMemory - reservedMemory)*spark.memory.fraction (1024-300)*0.6 =434 mb. А для пользовательских обьектов 289 mb соответствено. Но пользователь может забрать при этом всю память, которая есть потому, что нет способа ограничить создание "пользовательских" обьектов
на JVM.

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

Ее нет в том смысле, что нет имени для нее, но память есть. Это
как про известно место ). И такая же ситуация была и при StaticMemoryManager. Менеджеры меняются, но  
но есть то, что неизменно.Жизненная ситуация ).  
А UnifiedMemoryManager он про другое. Его смысл как мы знаем такой же как и в мире
oracle. С offheap мемори ситуация такая же. т.е также трэкается через мемори менеджера, но у нее свой пул.

Меня этот вопрос, получается, интересовал применительно к spark.memory.fraction - насколько целесообразно такой большой объем выделять для пользовательских объектов, почти половина ресурсов? Наверное, конечно, неспроста в более поздних версиях коэффициент по умолчанию стал больше на 0.15, но все таки. Или тут такая же история, как и с execution/storage memory, и свободную память экзекутор при необходимости съест?

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

не совсем понятен вопрос, но тут можно посмотреть с другой стороны. как сделать так, как вы хотите на JVM? когда создается "user object"  он не может вытеснить ничего ненужного т.к нет механизма для реализации этого. И вот если я знаю, что мне нужно 200mb для моих "user object" как сделать так, что бы они были доступны для меня

Ну, по всей видимости, для пользователей вроде меня, которые не знают, сколько им нужно памяти для user object и в какой момент, и выделяется такой объем в памяти экзекутора, который он не может использовать для вычислений. Понятно.

менеджер спарка может же двигать execution|storage (в некоторых пределах), так же мог и с так называемой user memory: не занял, тогда я возьму.

Плюсую; ток путает эта картинка

Я даж не знаю в чем ценность ее

он когда двигает, то опирается на идею, что потом можно вытеснить "неважное", если нужно, а в user memory отдать обратно так не получиться. Вот допустим у нас 289 мегабайт. он взял их себе даже для storage,а дальше пользовательский код, который создает массив на 289 мегабайт. Тут нельзя никак сказать спарку, чтобы он отдал эти 289 мегов обратно.

Проблема в том, что я несколько раз на нее натыкался в разных местах, когда пытался разобраться в мемори менеджменте. И в одной презе датабрикса я слышал упоминание вот этой юзер мемори. И это путает, безусловно.

Очевидно (теперь) что это вымышленное название и все могут по разному трактовать