Коллеги, нужно при создании спарк сессии версии 2.4.0 указывать .enableHiveSupport?  Работа с таблицами Hive  обязательно нужна. Если нет, то с какой версии это стало необязательно?

Наоборот, это новый апи вместо хайв сешн

Спасибо, тогда есть конфликт, зависимость org.apache.spark spark-hive 2.4.0 некорректно работает с org.apache.hadoop hadoop-minicluster версии 3.1.1, ошибка Unrecognized Hadoop major version number 3.1.1.

Судя по стектрейсу, ошибка приходит из org.spark_project.hive hive-exec, последняя версия 1.2.1, новее нет.

Как настроить зависимости для тестов, если используется spark 2.4.0, Hadoop 3.1.1, hive 3.1.2?

Попробуйте использовать не стандартный хайв, а загружать с диска или мейвена хайв клиента

Нужной версии

У вас дефолт builtin 1.2.1 который не знает рэпро третий хадуп

Для юнит тестов maven поставьте вместо builtin и версию вашу 3.1.2

Добрый  день, господа! Кто-нибудь спаривал janusgraph и solr?

Всем привет. Есть вопрос по оптимизации spark джобы. Процессится некий большой датасет. Происходит три трансформации:
1. join с другим большим датасетом по некому полю
2. затем аггрегация (groupBy + sum) по нескольким полям (не являющимся ключами при джойне из пункта 1)
3. затем window функция по ещё одному полю (также не являющемся ключом для пунктов 1,2)

Вопрос - как такое оптимизировать? Правильно ли я понимаю, что нужно понять при какой операции (1,2,3) происходит больше всего шаффлинга и провести бакетинг по необходимым ключам и оптимизировать конкретный пункт? А остальные два пункта так и останутся с неизбежным шаффлингом.
И второй вопрос - является ли это звоночком к тому, что это проблема в данных и такого быть не должно?

Спасибо, читаю, буду применять

Мне кажется, что бакетинг на уровне файлов сможет использоваться только в п.1, а дальше не отнаследуется

то есть бакетинг при, например,  groupBy не поможет?

Думаю да, после join будет распределение по ключу соединения и бакетирование для другого поля не сохранится

да, теперь понял ваш ответ. то есть имеет смысл делать бакетинг только по полю соединения при джойне в любом случае. и терпеть гигабайты шафлинга в 2-3 пунктах :(

Да, может являться проблемой с данными. Джойн двух больших датасетов всегда проблема и надо стараться такого избегать. Если бы была склейка в широкую таблицу на шаге 1 - было бы прилично быстрее

Ребят, а никто вот это сатанинское поделье не трогал? У нас хотят втащить попробовать, может есть у кого экспирьенс

https://dkron.io/

на счет Impala и spill to disk, добрался до админки - вроде все включено, вижу что у здоровых запросов счетчики spill более нуля. значит работает. но все равно регулярно получаем вылеты по памяти. из недавнего селект * без джоина на  табличку в 40мб отожрал 20гб и вылител по лимиту. единственно там статистики не было совсем, сбор статистики выправил ситуацию.
может после каждой загрузки стоит тотально на все собирать статистики ?

Проверил. Выдает 40 строк, а не 100