Идемпотентная загрузка: повторный запуск не должен менять данные

Что такое идемпотентность на практике

Повторный запуск загрузки за тот же период не меняет результат. Ни строк, ни сумм, ни версий. Это не свойство платформы, а свойство конвейера, и его надо проектировать.

Три вещи, которые её ломают

1. Вставка без удаления предыдущей загрузки того же периода.
2. Счётчики, которые инкрементируются при каждом запуске.
3. Зависимость от текущего времени вместо даты среза.

Как это выглядит в схеме

• у загрузки есть граница: дата или номер пакета, по которой она удаляет свой предыдущий результат;
• ошибочные строки не отбрасываются, а уходят в отдельный журнал с причиной;
• порядок шагов одинаков: подготовка, загрузка, проверка, публикация;
• проверка сходится: число строк и контрольные суммы совпадают с ожидаемыми.

Журнал ошибок нужен не для отчётности: без него повторный запуск «успешен», а часть данных молча отсутствует.

Как проверить

Загрузка запускается дважды подряд на одном и том же срезе. Результат должен совпасть построчно. Затем запускается на срезе с заведомо испорченной строкой: она должна попасть в журнал, а остальные данные — загрузиться.

Эти две проверки дешевле любого разбора инцидента и делаются до первого боевого запуска.

Ограничение

Идемпотентность не решает проблему изменений в источнике: если источник переписал историю, конвейер честно загрузит новую версию. Бороться с этим нужно на входе — сверкой и историчностью, а не повторными запусками.