#зачем_нужно #вести_с_полей 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
