Albato → PostgreSQL → Superset: загрузка сделок без дублей

Обновлено 2 сентября 2026 года.

Albato связывает события и действия сервисов, PostgreSQL хранит подготовленные данные, Superset показывает отчёты. Для небольшой команды такая схема может упростить интеграцию, но сценарий из нескольких шагов ещё не является полноценной копией CRM. Нужны первоначальная загрузка, обновления, удаление и сверка.

Что действительно умеет подключение

В инструкции Albato для PostgreSQL перечислены создание строк, поиск, обновление и пользовательский запрос. Наличие этих действий не означает, что сервис сам создаст правильную таблицу или выполнит атомарный UPSERT по произвольному ключу. Проверьте доступные действия и их параметры в вашем подключении.

Подготовьте таблицу заранее, укажите реальный адрес, порт, базу и схему. PostgreSQL использует собственный протокол подключения; обычная база не принимает INSERT на HTTPS-адрес. Если выбран HTTP-приёмник, это отдельный сервис, который проверяет запрос и выполняет SQL. Для облачного Albato локальное имя Docker-сервиса postgres не является доступным адресом.

Контракт сделки

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

Ключ должен оставаться стабильным при смене стадии и ответственного. Если порталов несколько, одного ID сделки недостаточно. UUID нельзя безусловно преобразовать в bigint: тип выбирают по источнику.

Повтор и порядок событий

Поиск строки и последующая вставка в разных шагах могут столкнуться при одновременных событиях. Уникальное ограничение в базе обязательно, а способ обработки конфликта нужно настроить явно. Для атомарной записи можно использовать проверенный параметризованный запрос или серверный обработчик с INSERT ... ON CONFLICT ... DO UPDATE, если выбранная интеграция это поддерживает.

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

Не отсекайте из загрузки все стадии, кроме NEW и WON, если отчёту нужна полная воронка. Сделка, перешедшая в исключённую стадию, иначе может навсегда остаться в старом состоянии в вашей копии. Ограничения применяйте осознанно, со способом удаления выпавших из выборки записей.

Первая витрина Superset

Начните с отчёта текущих сделок по воронке, стадии и валюте. Суммы в разных валютах не складывайте без установленного курса и даты пересчёта. Для графика новых сделок используйте дату создания; для истории переходов сохраняйте события или снимки отдельно.

Создайте представление PostgreSQL с понятными типами и именами полей, подключите его в Superset ролью чтения и зарегистрируйте датасет. Одно подключение к базе не задаёт формулы показателей и права каждого зрителя. Проверьте ограничения доступа под обычным сотрудником.

Для материализованной витрины требуется отдельный refresh после загрузки. Встроенная pg_matviews не содержит универсального времени последнего обновления: записывайте успешный запуск в собственный журнал. Уведомления и рассылки Superset требуют настройки соответствующих фоновых компонентов по документации Alerts and Reports.

Приёмка и стоимость

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

Стоимость оценивайте по числу выполняемых шагов, объёму первичной миграции, повторов, хостингу и сопровождению BI. В описании Albato транзакции связаны с выполнением шагов. Обещание цены «за одну сделку» без состава сценария вводит в заблуждение. Условия обработки данных проверяются для конкретных сервисов и договора, а не по языку интерфейса.