Идемпотентный ETL-конвейер

Начни со скучной, честной версии: прочитай каждую строку из источника — таблицы, CSV или Parquet-файла — и вставь её в staging-таблицу в хранилище. Пока без инкрементальной логики, без дедупликации, просто полная загрузка, которую можно прочитать от начала до конца. Смысл начать отсюда — сделать форму данных и контракт источника явными до любой оптимизации: какой у строки естественный ключ, какая колонка говорит, когда она изменилась, и источник — это снимок или append-only лог? Эти три ответа определяют каждое последующее решение, и ошибиться в них — самая дорогая ошибка во всём конвейере. Держи extract, transform и load отдельными шагами, чтобы рассуждать о каждом; не поддавайся искушению свернуть их в один хитрый запрос.

Теперь запусти полную загрузку дважды и посмотри, как растут дубликаты — именно этот баг призван убить данный этап. Идемпотентная загрузка даёт одну и ту же итоговую таблицу, запустилась она раз или пять, а значит load должен быть по ключу, а не append. Замени слепой INSERT на upsert: INSERT ... ON CONFLICT (natural_key) DO UPDATE в Postgres или MERGE. Глубокая мысль в том, что конвейеры живут в мире at-least-once — планировщики делают retry, операторы перезапускают, частичный сбой бросает тебя на середине загрузки, — поэтому корректность не может зависеть от того, что джоб выполнится ровно один раз. Осознанно реши, что значит «конфликт»: повторно увиденный ключ — это no-op, last-writer-wins или ошибка? Каждый выбор кодирует свою правду об источнике, и неверный тихо портит историю.

Перечитывать весь источник на каждом прогоне нормально на 10 тысячах строк и катастрофа на 10 миллиардах. Решение — watermark: маленький кусочек устойчивого состояния (максимальный change-timestamp или sequence id, который ты успешно обработал), позволяющий следующему прогону извлекать только строки новее этой отметки. Храни его транзакционно, чтобы watermark продвигался только если покрываемая им загрузка действительно закоммитилась; иначе сбой между «load прошёл» и «watermark сохранён» навсегда пропустит данные. Здесь идемпотентность и инкрементальность обязаны сотрудничать: поскольку перезапуски всё равно могут повторно забрать граничную строку, именно upsert из прошлого этапа делает это перекрытие безвредным. Выбирай границу аккуратно — бери замкнутый интервал и смирись с переобработкой края, потому что пропуск строки — это тихая потеря данных, а переобработка под идемпотентной загрузкой бесплатна.

Конвейер, который грузит что угодно, хуже отсутствия конвейера, потому что он отмывает плохие данные в доверенные таблицы, на которых строят другие. Добавь проверки качества данных, которые запускаются между transform и load и имеют право прервать загрузку: число строк в ожидаемом коридоре, естественный ключ в батче уникален и не null, обязательные колонки не null, числовая колонка в разумных границах. Сложный вопрос дизайна — что должен делать «провал»: остановить всю загрузку или отправить проблемные строки в карантин и загрузить остальное? Остановка защищает корректность, но тормозит бизнес; карантин держит поток данных, но требует пути для переобработки отложенного. В любом случае проверки должны быть громкими: тихий провал качества — самый опасный баг в дата-инженерии, ведь его находят недели спустя в дашборде, которому уже никто не верит.

Две сеньорные реальности ломают аккуратную forward-only модель. Первая — бэкфилл: кому-то нужно перезалить прошлый март, потому что трансформация была неверной, поэтому твой джоб должен принимать явный диапазон дат и переобрабатывать его, не задваивая сегодняшние строки и не ломая живой watermark. Вторая — поздно приходящие данные: строка со вчерашним временем появляется после того, как сегодняшний watermark её уже миновал, и наивная инкрементальная выгрузка пропустит её навсегда. Обе проблемы — на самом деле один урок: watermark это оптимизация, а не источник истины, и именно идемпотентность загрузки позволяет безопасно переобработать любое окно. Реши их, сделав бэкфилл ограниченным идемпотентным перезапуском по выбранному интервалу и расширив инкрементальное окно небольшим допуском на опоздание (перечитывай хвостовой буфер), чтобы строки не по порядку получили второй шанс лечь ровно один раз.