А если бы был один, то не было бы параллелизма или вообще бы не работало?

Если честно, то потому что выкидывало ексепшн: Task not serializable java.io.NotSerializableException

т.е. ещё и фича: типа распаралелил

понял, спасибо

@KickerMario основной код выполняется на драйвере, соответвенно если вы его создадите там, а потом используете в блоке перпартишен, то значит его нужно сериализовать, передать на воркер, десериализовать и использовать

Но так как он держит коннекты на саму кафку, то логично что нельзя так просто с ним обращать :) где создал там и используй

Лямбда в перпартишен сериализуется и выполняется на воркерах

не сериализуются продюсеры

исчерпывающе, спасибо)

/apps/hbase/data/.hbck можно очистить без последствий? как правильно?

HeapSize для Namenode, Datanode и JournalNode (всего hdfs-ового) задаётся в hadoop-env.sh в HADOOP_HEAPSIZE. Получается, если я выставляю большой хип для NN, то JN, установленный на ту же тачку также получает maxHeap как и у неймноды.
Пока есть идея только в OPTS прибить флажками минимальный размер хипа для JN поменьше
1. Есть нормальные идеи, как это исправить?)
2. И вообще, сколько нужно оперативы под журнал?
3. И чисто ради интереса, что будет, если к одному процессу дважды указать Xmx разного размера? Какой из них он возьмёт? 😂

Как разворачиваете?

Клоудера под каждый сервис на каждом рестарте создаёт папку с конфигами и указывает использовать конкретному сервису именно её

export HADOOP_NAMENODE_OPTS="-Xmx8192m $HADOOP_NAMENODE_OPTS"

ваниль

У амбари насколько помню так же можнл

если я так напишу, то он возьмёт HADOOP_HEAPSIZE и добавит туда 8192

то есть будет два Xmx флажка

Вариант ещё что Виталий кинул: не использовать хипсайз напрямую, но использовать специфические опции для каждого сервиса

Выиграет последний ;)

но это не точно?)