Делать атомарную заливку?

Где дата кволити?

Что понимается под атомарной заливкой? В смысле или выполнились все шаги или откатили все?

везде

Вернее это проблема не связанная с идемпотентностью

Вы приняты..

без вопроса про зряплату? 😊

А собственно, кто знает джоб борды для дата инженгров в телеге? (В личку)

Коллеги, добрый день! Помогите решить архитектурную проблему организации правильного надежного пайплайна.
Дано: есть один source данных и два sink'а (две разных таблицы в одном DWH) и работает это через staging.
При этом необходимо обеспечить, чтобы данные в таблицах разбегались как можно меньше, плюс максимально сократить число обращений к источнику.
Разумеется предполагается, что пайплайн может упасть на любой операции: чтение из источника в staging, переливка из staging'а в таблицу 1 или переливка из staging'а в таблицу 2. Например, в ситуации, когда в таблицу 1 данные успели перелиться, а в таблицу 2 – нет, данные разбегутся, но нужно каким-то образом уметь повторять переливку только в таблицу 2 ровно тех данных, что перелились в таблицу 1. При этом по умолчанию сейчас staging очищается перед стартом пайплайна.
У кого-то был опыт в решении подобной задачи? Как правильно это сделать? Меня интересуют не инструменты, а "принципиальная схема" решения.

если у вас нет возможности сделать нормальное окно на заливку то можно открывать доступ к новым данным в таблицах обновляя слой вьюшек, смотреть на job_id или processing_ts или что-то похожее

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

Ну тут не так много вариантов, если надо надежно.
1. Атомарный коммит, если есть на стороне sink.
2. Идемпотентная запись с устранением дублей (at least once). Техника следующая. Выполняете ваш пайплайн, записывая данные в две таблицы. Если упали на любом из шагов, начинаете сначала (на тех же данных). Записывая кусок заново. Перед использованием данных нужно удалить дубли (для этого у вас должны быть unique_id в каждой записи на stage).

Да, все так