Debezium и Kafka → PostgreSQL → Superset: как устроен CDC

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

CDC переносит изменения из журнала базы в другие системы. В рассматриваемой схеме Debezium читает источник, Kafka хранит поток событий, sink-коннектор применяет его к PostgreSQL, а Superset запрашивает витрины. Это требует доступа к журналу исходной БД: для облачного Битрикс24 такой путь нельзя считать доступным по умолчанию.

Определите реальный источник

Для самостоятельной установки CRM сначала проверьте СУБД, поддержку выбранного коннектора и допустимость нагрузки. MySQL-коннектор Debezium читает binlog и выполняет начальный снимок. PostgreSQL-коннектор использует свой механизм логического декодирования. WAL PostgreSQL и binlog MySQL нельзя смешивать в настройках и диагностике.

Если доступен только REST API, проектируйте API-загрузчик и обработку событий приложения. Установка Kafka не открывает доступ к журналу облачной CRM и не отменяет её ограничения.

Применение событий в PostgreSQL

Выберите конкретный sink: например, Debezium JDBC либо другой JDBC-коннектор. Их параметры и обработка структуры события различаются. У Debezium JDBC документированы UPSERT, ключи и удаление записей. Фрагмент его конфигурации для текущего состояния может выглядеть так:

{
  "insert.mode": "upsert",
  "primary.key.mode": "record_key",
  "delete.enabled": "true"
}

Это только часть конфигурации: нужны адрес назначения, доступ, топики, типы данных и настройки конкретной версии. Ключ сообщения должен однозначно определять запись. Для составного ключа проверьте все его поля и соответствующий ключ таблицы.

Повторная доставка возможна. UPSERT помогает сделать применение одной версии повторяемым, но не решает все проблемы порядка событий, нескольких источников и изменения ключа. Удаление должно пройти весь путь от source-события до удаления либо отметки в целевой таблице; одной настройки tombstone недостаточно.

Согласованность и история

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

Читай также: Коннектор BI Data: выгрузка Битрикс24 в PostgreSQL, MySQL и MS SQL

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

Что измерять

Разницу между временем изменения в источнике и временем применения в хранилище.
Состояние задач source и sink, ошибки преобразования типов и очередь необработанных событий.
Отставание потребителя Kafka, свободный диск и срок хранения журналов источника.
Свежесть витрины и кэша Superset: успешный sink ещё не означает обновлённый экран.

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

Приёмка потока

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

Задержку измеряйте на своём потоке, включая витрину и BI. Обещания «сотые доли секунды», фиксированного числа копий Kafka или отсутствия администрирования не описывают свойства такой системы. Если достаточно периодической CRM-выгрузки, сравните CDC с более простой интеграцией для аналитики по стоимости поддержки и требованиям к свежести.