Проектирование импорта данных: какой вариант выбрать

Импорт из внешней системы может занимать пять минут раз в сутки или передавать изменения почти в реальном времени. Ошибка выбора проявится не в диаграмме, а в продакшене: дубли, пропущенные обновления, перегруженный API и ручная сверка, которая съедает часы команды. Ниже сравниваем три рабочих подхода — пакетную загрузку файлов, инкрементальный импорт через API и CDC — и выбираем их по задержке, объёму, контролю ошибок и стоимости эксплуатации.

Сначала зафиксируйте контракт импорта

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

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

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

Идемпотентность¹ должна быть частью контракта, а не пожеланием к разработчику. Повторная доставка одной записи не должна создавать второй заказ, платёж или пользователя.

Самая дорогая часть импорта — не передача данных, а доказательство того, что после сбоя система ничего не потеряла и не записала дважды.

Три варианта доставки

1. Пакетные файлы

Источник формирует CSV, JSON, XML или другой согласованный файл по расписанию. Приёмник забирает его из хранилища, проверяет структуру, загружает во временную область и только потом применяет изменения к рабочим таблицам.

Это самый простой вариант для ежедневных каталогов, финансовых сверок и систем, где задержка в несколько часов приемлема. Его сильная сторона — воспроизводимость: конкретный файл можно сохранить, проверить и обработать повторно.

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

2. Инкрементальный импорт через API

Приёмник периодически запрашивает только изменения после последнего подтверждённого положения. Источник должен поддерживать устойчивый курсор, номер версии, временную метку с гарантированной точностью или другой способ получить следующий фрагмент данных.

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

Главная граница метода — история изменений. Если источник хранит только текущее состояние объекта и удаляет старые записи раньше, чем импорт успевает их забрать, восстановить пропуск будет трудно или невозможно.

3. CDC и поток событий

CDC, или Change Data Capture, читает журнал изменений базы данных и передаёт операции вставки, обновления и удаления в потребителей. Например, логическая репликация PostgreSQL 16 может быть частью такой схемы, а брокер сообщений — буфером между источником и несколькими приёмниками. Конкретная реализация зависит от СУБД и используемого коннектора.

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

CDC не превращает данные в магический поток без потерь. При сбое потребителя вам всё равно нужны смещение, повторная доставка, дедупликация и процедура сверки с источником.

Сравнение по цене и риску

Диапазоны задержки в таблице — не обещание конкретной системы. Их нужно подтвердить нагрузочным тестом на вашем объёме, железе, размере транзакций и настройках источника.

Как выбрать подход без гадания

1. Начните с допустимой потери свежести. Если данные могут устаревать до следующего утра, пакетный файл обычно дешевле потоковой схемы. Если устаревший остаток или статус заказа влияет на операцию пользователя, сравнивайте API и CDC.
2. Проверьте способ обнаружить удаление. Для API нужен явный признак удаления или отдельный endpoint. В файле должно быть понятно, означает ли отсутствие строки удаление. В CDC удаление должно приходить как отдельное событие.
3. Определите границу подтверждения. Сначала запишите данные и успешно завершите транзакцию, затем зафиксируйте курсор, имя файла или смещение. Обратный порядок создаёт окно потери.
4. Спроектируйте повтор. Используйте внешний идентификатор объекта, версию или ключ события. Повторный запуск должен обновлять ту же запись, а не создавать новую.
5. Заложите полную сверку. Нужны периодический пересчёт количества и сумм, отчёт о пропущенных объектах и возможность запросить источник повторно. Даже хороший поток иногда требует контрольной загрузки.

Что ломается первым

Дубликаты после тайм-аута

Приёмник записал данные, но ответ не дошёл до оркестратора. Тот повторил запрос, а система создала вторую запись. Лечение — уникальный ключ источника и безопасная операция повторной записи. Одной проверки по времени недостаточно: часы на серверах могут расходиться.

Потери на границе курсора

Импорт получил изменения с отметкой времени 12:00, а следующий запрос начал с 12:00 и использовал условие «строго больше». Часть событий исчезла. Надёжнее применять перекрывающийся диапазон и дедупликацию либо использовать курсор, который выдаёт сам источник.

Схема изменилась раньше потребителя

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

Источник перегружен импортом

Частые запросы без ограничения скорости создают конкуренцию с пользовательским трафиком. Нужны лимит параллельности, повтор с увеличивающейся паузой, случайная задержка между попытками и отдельный мониторинг ответов 429, 5xx и времени запроса. Точные названия и правила зависят от API источника.

Что измерять до и после запуска

Не ограничивайтесь статусом «джоба зелёная». Для каждого варианта зафиксируйте:

• задержку от появления изменения в источнике до записи в приёмнике;
• число принятых, отклонённых и повторно обработанных объектов;
• размер очереди или отставание курсора;
• длительность обработки и потребление CPU, памяти и диска;
• время восстановления после остановки потребителя;
• результат контрольной сверки количества и сумм.

Если замеров нет, не подставляйте в проект «типичную» производительность. Прогоните копию реального набора данных, отдельно проверьте пик, задержку источника и восстановление после разрыва связи. Для CDC дополнительно измеряйте отставание журнала и объём данных, который потребуется хранить при остановке потребителя.

Что делать дальше

Составьте короткий контракт импорта для одной сущности: идентификатор, версия, операции создания и удаления, формат ошибки, правило повтора и граница подтверждения. Затем проверьте его на трёх сценариях: тайм-аут после записи, изменение схемы и восстановление после простоя.

Для пакетного варианта изучите атомарную загрузку во временную область и контрольные суммы. Для API проверьте документацию конкретного источника о курсорах, лимитах и удалениях. Для PostgreSQL 16 и CDC начните с официального описания логической репликации, а затем отдельно спроектируйте хранение смещений и повторную доставку. Инвалидация кешей и согласование нескольких мастер-систем — отдельные темы; здесь важен именно надёжный импорт.

¹ Идемпотентность — свойство операции сохранять тот же результат при повторном выполнении с теми же данными.