#зачем_нужно #вести_с_полей REPLACE TABLE в Delta lake вместо DROP + RECREATE 1/2 🔸 Дата инженеры работают с большими и очень большими данными, поэтому для хранения и обработки всё меньше подходят CSV и JSON. Даже Parquet и ORC заменяются Hudi, Iceberg и Delta таблицами. С последними я пилю текущий проект на работе, поэтому иногда буду писать о встреченных фишках. 🔸 Например, в случае пересчёта таблицы есть несколько обычных стратегий: . drop + create, пересоздать объект с нуля, если есть несовместимые изменения схемы данных . insert overwrite partition, если изменилась логика или обновился источник и можем пересчитать по партиции за раз . create + rename + drop, создать рядом промежуточную таблицу, прогрузить её данными, а потом "свопнуть", т.е. поменять местами с текущей таблицей — актуально для тяжёлых витрин с непозволительностью даунтайма для технических работ 🔸 Однако каждый из этих способов обладает своими недостатками: . в первом случае будет даунтайм на период просчёта, и, в случае ошибки создания новой версии, пользователи и пайплайны будут заблокированы . во втором случае запросы над несколькими партициями сразу могут возвращать несогласованные данные до окончания операции просчёта; или объект блокируется целиком на время всего пересчёта -> снова даунтайм . третий подход выглядит хорошо (и может быть вариантом реализации online schema evolution), но редко встречается "из коробки" и его приходится писать, например, в виде кастомной материализации в dbt