Комментарии 4
Спасибо за статью. Про "удаления полей из объекта" не понял, все таки если поле уже не нужно или в источнике его теперь уже нет - это изменение доходит до data lake/data mart?
Если поле ранее загружалось и необходимость в нем отпала или оно пропало в источнике, мы отключаем его загрузку через конфигурацию. И когда пайплайн начнет в следующий раз загрузку, это отключенное поле будет пропущенно из запроса, а в целевую таблицу зальется значение NULL что в Data lake, что в Data Mart. Конечно, с извещением пользователей.
Т.е. мы не удаляем отключенное поле из схем целевых таблиц, чтобы избежать обязательной в таких случаях миграции исторических данных.
В нашем продукте эта задача решается схожим образом, но конфигурации задаются пользователем через UI, метаданные версионируються, данные тоже, в любой момент времени единицу объекта можно поднять по истории вверх или окатить вниз.
Источниками данных служит абстракция коннекторов которые могут как получать так и отдавать данные, не только в наше хранилище, но и в любое допустимое из списка коннекторов.
В итоге мы можем проинтегрирорвать всё со всем, буквально в пару кликов. Главное можем передать это пользователю, простая трансформация без инъекций кода накидываеться пользователем самостоятельно
Автоконфигурируемость ETL: как мы сделали ETL устойчивым к постоянным изменениям в структуре входных данных