Зачем новой системе нужна дозагрузка истории, где проходит граница с текущими изменениями и как проверить итог.
Когда новая система видит только сегодняшний день
Компания запускает новый отчёт по заказам. С утра в него поступают свежие покупки, но директор хочет сравнить текущую неделю с предыдущим месяцем. Старые заказы в новой системе отсутствуют. Чтобы заполнить этот пробел, команда отдельно переносит или пересчитывает данные за прошлый период. Такой процесс называют backfill, или дозагрузкой истории.
Это не то же самое, что обычное ежедневное обновление. Текущий поток приносит новые изменения, а backfill заполняет уже существовавшие записи или результаты расчётов. Google Cloud Datastream описывает историческую загрузку как получение существующих данных источника отдельно от потока текущих изменений. Оба процесса могут идти одновременно, но их границу нужно понимать заранее.
Сначала определяют недостающий период
Не вся история одинаково нужна. Для сравнения продаж за месяц могут понадобиться предыдущие месяцы; для годового отчёта — более длинный период. Команда уточняет, какие таблицы и показатели отсутствуют, за какие даты их можно восстановить и насколько изменились правила расчёта. Если старые события не сохранялись вовсе, backfill не сможет создать их из воздуха.
Важно договориться о точке начала текущего потока. Иначе часть заказов попадёт и в историческую дозагрузку, и в обычное обновление. Обратная ошибка оставит пустой промежуток между ними. AWS DMS различает загрузку существующих данных и последующее воспроизведение изменений; в сочетании сервис сначала заполняет базу, затем применяет накопившиеся изменения. Конкретная схема зависит от системы, но вопрос о стыке периодов остаётся общим.
Условный пример с заказами
Допустим, новый отчёт стартовал первого сентября, а история в старой системе хранится с первого января. Команда хочет показывать продажи за календарный год. Она переносит записи с января по август и отдельно сверяет, как учесть возвраты, отмены и исправления заказов. Если в июле изменилось определение «оплаченного заказа», нельзя без обсуждения складывать старые и новые числа в один ряд. Нужно либо пересчитать историю по единому правилу, либо явно обозначить разрыв методики.
Проверка начинается с простых вопросов: совпадает ли число заказов за выбранные дни с исходной системой, нет ли одинаковых заказов дважды, правильно ли обработаны возвраты? Для итоговых показателей сверяют не только общее число строк, но и смысл сумм. Эти шаги относятся к качеству результата, а не к выбору конкретного инструмента переноса.
Почему дозагрузка может мешать текущей работе
Исторический объём иногда велик. Чтение многих старых записей нагружает исходную систему, сеть и место хранения. В справке Datastream отмечается, что массовая историческая загрузка способна ощутимо влиять на источник, поэтому сервис ограничивает число одновременных задач. В собственной системе команда тоже должна выбрать время и объём порций с учётом текущей нагрузки.
Повторный запуск требует особой осторожности. Если дозагрузка прервалась на середине, нельзя просто предположить, что никакие записи не успели сохраниться. Нужны контроль уже обработанного периода и понятное правило повторной обработки. О том, почему повтор может создать дубли, подробнее рассказывает статья о повторной загрузке данных.
Что считать завершением
Backfill завершён не тогда, когда прогресс на экране дошёл до конца, а когда подтверждены полнота периода, отсутствие дублей и согласованность расчётов. После этого команда проверяет, что новые события продолжают поступать. Разницу между разовой полной и регулярной частичной загрузкой объясняет материал о полной и инкрементальной загрузке.
Инженеру данных важно уметь планировать такой переход вместе с владельцем отчёта: бизнес определяет нужную историю и смысл показателей, инженер отвечает за перенос и проверяемость. Если вы выбираете путь в профессии, посмотрите курс Data Engineer для начинающих и оцените, как в программе раскрываются реальные задачи качества и доставки данных.
