Могу предложить ещё разумный вариант в дополнение к уже высказанным Алексом: объедините два процесса в один, или даже два приложения в одно. Пусть и данные пишет и обрабатывает их. Про обновления процесс будет информирован, сможет почистить свои кеши. Устраните конкурентность, которая почти всегда зло, и проблема будет решена.
Я не так давно реализовал класс, который создаёт lazy val dataFrame, селектит его по переданным параметрам для проверки, мержит в него данные и сразу делает dataFrame.queryExecution.analyzed.refresh(). После происходит листинг и новые данные видны в том же lazy val. Мэджик))

Спасибо, решили попробовать сделать через delta lake

ну и я тоже "доигрался" (разобрался) - если через метастор, то делаем два раза alter table ... rename to: первый раз в пишущем приложении по окончании записи (тогда новые файлы пойдут в другую директорию), второй раз в читающем приложении (тогда на чтение не повлияет создание новых файлов писателем). Собственно, те же "директорные" операции, только в sql "обертке". Код могу сбросить куда-нить, если кому интересно. Но лучше как-то это "красивее/проще" учесть в самой логике всей конструкции 😊

в файлик сохраните плиз)

юпитер подойдет?

txt ))

Это то что я говорил с изменением location для екстернал таблицы

С переименование есть зазор по времени когда первую таблицу уже переименовали, а вторую на её место уже ещё нет

Запрос на установку нового location атомарен

да, это именно оно (про location), причем дважды...

alter table rename тоже (должен быть) атомарен - ибо это и есть изменение location (As of version 0.6, a rename on a managed table moves its HDFS location...) Но есть нюанс - не сработает, если location есть, вот тут и появляется "зазор" (между drop и rename), но его отлавливаем в читателе (см. код) - дожидаемся появления нового location.

Ну и, конечно, аккуратно с логикой и (очень похоже синхронизацию параллельных процессов - флаги и проч., здесь без них удалось обойтись 😊)

спасибо!! 🤝

Привет всем, есть вопрос, по какой причине Спарк может бросать class not found exception, если в самом fat jar класс присутствует
Для сборки использую sbt assembly, джобы сабмичу через Livy, предыдущая версия jar файла успешно отрабатывает, а собранная сейчас не хочет

Может у кого-то есть идеи, а то перепробовал все - а как exception валился так и валится

Проверьте полное название класса, путь

Может вы его переместили

Переезда на 3.1 не было?

Не было, пока 2.4.4 на Амазоне

Проверил, все на месте

Тогда хз, в 3.1 спарк перестал включать хадуп зависимости по дефолту в класспас, у наших многих полетели джобы даже с ливви

А какой класс не находит?

Мой, в котором код джобы