я спрашивл - вроде так надо

один постоянно дописывает, второй - читает

ну вот и нужно уточнить у автора есть ли у него .mode(SaveMode.Append) =)

нет, данные могут меняться
там merge

append или overwrite?

overwrite

тогда не понимаю проблемы вообще - если overwrite - пишите в новую табличку и вообще никаких проблем быть не должно (я щас и это проверю, но с append я еще как-то могу понять проблему, с overwrite - не понимаю...)

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

но он хочет чтобы как-то работало =)

варианты тоже предлагались:
1. кастомные пляски с переключением location для external table
2. писать в разные таблицы
3. писать в формате iceberg/hudi/databricks delta

все равно непонятно (поэтому и полез разбираться): спарк пишет всегда в другую директорию и потом "атомарно" ее переименовывает. Это вроде как изначальная идея, над которой долго бился HDFS и которую не очень просто повторяют объектный стораджа. Поэтому (как я думал и пока остался при своем) при записи (будь то append, будь то overwrite) файлы появляются разом...
Либо в описанной ситуации что-то сложнее (я услышал слово merge, которое в случае overwrite мне не очень понятно), либо - наоборот - что-то сильно проще.
В моем примере мне на overwrite вообще не поймать: цикл записи заканчивается "записью", а начинается с overwrite (=удалить все), поэтому читатель тупо таблички вообще не видит (ибо ее нет, удалить писатель ее удалил, а новые данные "налить" еще не успел)
Мне интересно понять (для себя), дайте знать, если я зря это здесь... я не со зла 😊

@mvkorolev

Спарк в момент выборки и анализа запроса смотрит где расположена партиция

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

Начинает выполнение

Стейджей может быть много, и в какой-то момент (иногда быстро, иногда и через 10 минут) доходит до того где нужно прочитать файлы

В этот момент оказывается что другой процесс сделал overwrite и часть файлов уже отсутствуют

Запрос падает

Планирование и выполнение запроса разнесены во времени

да, спасибо, в-принципе понятно, но когда говоришь "вообще", то сложно бывает поймать ту суть, которую хочешь поймать 😊. В этом -нашем - случае приложение делает overwrite, и эта операция завершается. После ее завершения (=полного пересоздания таблицы) таблица готова, ее можно читать. Читать в момент следующего пересоздания (=когда пошел фактически процесс удаления, как работает overwrite) бессмысленно и тут дело не в спарк, а в сути происходящего (=параллельная работа с данными).

я наиграл на своем стенде (если подождать чуть после записи, то и получается поймать ситуацию), сейчас еще поиграюсь чуть

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

ок, спасибо Alex! всегда полезно узнать что-то новое...

все же еще один вопрос (если можно) - как поймать (туплю) эту ситуацию в питоне (когда произошло изменение файлов)? в шеле если read() не отработал (вывалился), выполняем refresh table и после этого можем читать... try что-то не ловит (или туплю)

Да, нужно делать рефреш

А вот про питон не скажу

а что в except указано?

Exception - не ловится... Но это не выход (чуть подумал) - count() долгая операция

я имею в виду, что в блоке try: ... except ...: указано в разделе except? может там просто исключение вылетает одно, а ловится другое