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

а логи гц вообще нужно включать всегда опциями на жвм

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

Ребята, как мне проверить работу чекпоинта при сбое драйвера в yarn?

Всем привет!
Есть проект с хадупом/постгрессом и постргрессом в качестве некоего dwh, в который смотрит BI.
На постгрессе выполнялись всякие агрегации/расчёты, но постгресса стало не хватать. Компания, которая разрабатывала «общее» решение, предлагает постгресс заменить на гринплам и переписать агрегации/расчёты под гринплам же.
Мы же хотим расчёты перенести на scala/spark (опыт есть).

Может кто помочь с аргументами против GP?

Или GP — очень даже кошерное решение?

какие объемы?

как организовано двх? Нормализованное хранилище?

Звезда. Скажем так, по большей части нормализованное.

чем льёте туда?

что за BI? у ваше bi какой движок: свой или пушдаун в пг?

BI — сторонняя компания занимается, со своим продуктом импортозамещённым. Они из пг забирают сами.

У вас уже есть подрядчик который все это делает?
Вы хотите  у них забрать и переписать на спарк?

По объёмам и как конкретно из хадупа переливается — чуть позже скажу

забираю то ладно, а варят у себя внутри или на пг?

Подрядчик есть, но они тоже колеблются как именно они хотят свой инструмент делать.

Сейчас из хадупа всё переливается в PG и самое заковыристо-расчётное проводится там.

От их решения зависит то, где именно свою часть будем делать мы. В GP или Spark’е. Нам хочется в спарке

но если у вас уже звезда то я б GP выбрал

ибо зачем тогда мучатся и ее строить

Прирост ≈5kk записей в день, но проблема в том, что приходится делать пересчёт минимум за год. Обновился день, обсчитывается полностью весь год.