Когда данные переносят целиком, когда — только изменения, какие ошибки возможны и что проверить перед выбором способа загрузки.
Отчёт обновляется каждый день
Представим условный магазин: в его системе хранится история заказов, а отдельная аналитическая система готовит ежедневный отчёт. В первый день историю нужно перенести целиком. На следующий день большинство старых заказов не изменится, но появятся новые и часть прежних будет отменена. Как обновить аналитическую копию — заново перенести всё или взять только изменения?
Это и есть выбор между полной и инкрементальной загрузкой. Он касается объёма переносимых данных и способа поддерживать актуальность результата. Само название подхода не говорит, что отчёт автоматически станет верным: нужны правила для изменённых записей, удаления и проверки итога.
Полная загрузка возвращается ко всему набору
При полной загрузке процесс заново берёт весь выбранный набор из источника и формирует целевую копию. Условно: если для отчёта нужны заказы за год, на очередном запуске снова рассматривают эти заказы. Подход проще объяснить и полезен, когда набор невелик или требуется сверить результат после ошибки.
Учебный модуль Microsoft Fabric рассматривает выбор между полным и инкрементальным переносом как часть стратегии загрузки в аналитическое хранилище. Но полная загрузка тоже требует аккуратности: нельзя оставлять пользователю наполовину заменённый отчёт, если процесс остановился в середине. Как именно избежать такого состояния, зависит от устройства конкретной системы.
Инкрементальная загрузка переносит изменения
При инкрементальной загрузке после первого полного переноса берут только новые или изменённые данные. В условном магазине это сегодняшние заказы и исправления вчерашних. Такой способ может уменьшить повторную работу при большом наборе, но ему нужен надёжный признак изменений.
Документация Azure Data Factory описывает, например, перенос по отметке последнего изменения или по механизму отслеживания изменений. Один лишь момент создания записи недостаточен, если старый заказ можно отменить позже. Команде нужно понять, как источник сообщает об исправлениях и удалениях, и что произойдёт при задержке передачи.
Условный расчёт показывает объём, но не весь риск
Допустим, в источнике 100 тысяч заказов, а за день добавилось 300 и изменилось 20 старых. Полный перенос рассматривает весь выбранный набор; инкрементальный — только 320 изменений, если источник умеет их надёжно выделять. Это условный пример объёма работы, а не обещание ускорения в 312 раз: время зависит также от поиска изменений, передачи, проверок и записи результата.
Если один запуск не завершился, следующему нужно знать, какие изменения уже попали в итог. Если источник поздно сообщает об отмене, её нельзя потерять за пределами выбранного периода. Иногда для восстановления разумно повторить более широкий участок или выполнить полную сверку.
Как выбирать подход
Сначала выясните размер набора и частоту обновления, затем — можно ли достоверно находить изменения. Отдельно обсудите удалённые записи и время, в течение которого исправления могут приходить позже. Для маленькой таблицы полная загрузка может быть понятнее и дешевле в сопровождении, даже если переносит лишние строки.
Инкрементальный способ полезен там, где повторная полная обработка тяжела, а источник предоставляет надёжный сигнал изменений. Независимо от выбора команда должна уметь сравнить итог с источником и восстановиться после сбоя. Эти проверки относятся к качеству процесса, а не к одному конкретному инструменту.
Почему «только новые записи» бывает недостаточно
Условный заказ может измениться после создания: покупатель отменил покупку, а бухгалтерия исправила сумму. Если процесс смотрит лишь на дату появления заказа, отчёт сохранит старое значение. Поэтому важно различать новые записи и любые значимые изменения существующих, включая удаление или отмену.
Отдельный механизм отслеживания изменений — один из способов решить эту задачу, но не обязательная часть каждой инкрементальной загрузки. Выбор зависит от возможностей источника. В разговоре с командой полезно попросить показать не только обычный день, но и то, как результат восстановится после пропущенного запуска.
По теме
Следующий шаг
Если хотите развить навыки в этой области, посмотрите Data Engineer для начинающих и сопоставьте программу со своими задачами. Материал помогает понять отдельный вопрос, но не заменяет практику и обсуждение конкретной ситуации с вашей командой.
