я в курсе этой опции) она не мержила такие варианты раньше

а у вас какая версия спарка?

В общих чертах, как я буду делать задачу изменения атрибутов таблиц в Hadoop:
1. Определяем изменения и формально описываем их инстансом класса (кейс класса в scala)
2. Читаем кастомным FileSourceScanExec все файлы, имя файла при этом становится одним из атрибутов, который FileScanRdd добавит к данным, должны быть метаданные для сопоставления файлов конечной таблицы (которая ещё не поменялась) и исходной (которую изменили)
3. Читаем все требуемые поля, а также первичный ключ из таблицы, где изменены данные
4. Обеспечиваем полностью эквивалентные распределения RDD для SortMergeJoin
5. Производим SortMergeJoin, получаем RDD с новой схемой, в этом поможет класс из п.2
6. Записываем кастомным FileWriter, восстанавливая имя файла, во временную директорию
7. Заменяем содержимое таблицы записанными файлами
8. При необходимости правим Hive DDL

После этого должна получиться полностью консистентная таблица, эквивалентная источнику как по составу, так и по данным. Как ни прочитай, всё будет правильно))

Технологии нас обогнали)

хм, и правда мержит, даже в 2.4.5

сорян, был неправ

мержит или нет, если в таблице пара сотен тысяч файлов, то смотреть будет грустно(

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

эт да

Если работает, что не так с этим способом?

он пишет на диск всю таблицу и читает, чтобы только покастить схему

по сути только один большой «не так»

У тебя уже есть таблица от коллеги

Тебе-то её не нужно писать

не, у меня есть моя SCD2 таблица, на основе таблицы коллеги

коллега на изи перезаписывает свою таблицу каждый день, пересчитывая ее с нуля в ETL

у него все отлично

Так можно не писать, кинуть туда where(lit(false))

схема сохранится, данные - нет, спарк это хорошо умеет