Stitch → PostgreSQL → Metabase: загрузка и проверка данных

Stitch → PostgreSQL → Metabase: загрузка и проверка данных

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

Stitch переносит данные в аналитическую базу, PostgreSQL хранит таблицы, Metabase строит запросы и дашборды. Такая архитектура возможна и для данных Битрикс24, но нельзя подключить входящий вебхук CRM в произвольное поле Stitch и получить готовую репликацию всех сущностей.

Откуда Stitch получает данные

Для поддерживаемого источника используйте его документированный коннектор. Для собственного источника Stitch описывает Import API, Singer и приём вебхуков. Import API принимает отправленные ему данные. Значит, внешняя программа всё равно должна прочитать CRM, пройти страницы ответа и передать записи в Stitch.

Перед выбором стороннего tap-bitrix24 проверьте конкретный репозиторий: дату обновления, поддерживаемые сущности, способ авторизации, сохранение состояния и обработку удалений. Название пакета в статье не является доказательством наличия поддерживаемого коннектора.

Что должен делать загрузчик Битрикс24

  1. Авторизоваться через поддерживаемый механизм REST — например, входящий вебхук или OAuth приложения. Секрет хранить вне кода и журналов.
  2. Получить полный начальный набор нужных сущностей с пагинацией и повтором временно неудачных запросов.
  3. Для последующих запусков использовать доступное поле изменения, например DATE_MODIFY для сделок, и сохранять контрольную точку только после успешной передачи данных.
  4. Обрабатывать повторные записи по стабильному ключу. Удаления получать отдельным механизмом или выявлять сверкой ключей.

Режим log-based replication относится к источникам, которые действительно предоставляют журнал изменений. Его нельзя включить настройкой и получить CDC из обычного REST API Битрикс24. Сбой контрольной точки также не повод безусловно удалять файл состояния: это может запустить дорогую повторную выгрузку.

Подготовка PostgreSQL и Metabase

Создайте назначение по инструкции Stitch для PostgreSQL. Требования к роли загрузчика определяет коннектор: ему могут понадобиться создание объектов и дополнительные операции, поэтому универсального набора «только INSERT и UPDATE» недостаточно.

Читай также:  Albato → PostgreSQL → DataLens: проверяемый отчёт по CRM

Сначала посмотрите фактические имена таблиц, типы и служебные поля, затем пишите SQL витрин. Не предполагайте, что любые данные CRM автоматически появятся в таблице stage.stitch_bitrix24_deal с колонкой data. Суммы переводите в numeric, храните валюту отдельно; локализованный тип money не решает валютный учёт.

У Metabase есть собственная база приложения для пользователей, настроек и сохранённых вопросов. Подключение к ней через MB_DB_* не добавляет автоматически аналитический источник. PostgreSQL с витринами нужно отдельно подключить в Metabase, обычно учётной записью для чтения. Эти две роли лучше разделить.

Как проверить отчёт по продажам

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

Срез текущих стадий показывает распределение сделок сейчас. Чтобы рассчитать прохождение от одной стадии к другой за прошлый квартал, нужна история переходов; группировка текущего поля стадии её не восстанавливает. Если используете материализованные представления, организуйте их обновление после успешной загрузки и проверьте требуемые индексы для CONCURRENTLY.

Для начала достаточно обычных SQL-вопросов и дашборда. Наличие AI-функций зависит от версии и редакции Metabase; обещать встроенный бесплатный чат для любой установки некорректно. Оцените тариф Stitch, обслуживание PostgreSQL и частоту загрузки. Если задача ограничена отчётом Power BI по CRM, сравните эту цепочку с прямым подключением BI Data Connector.