PostgreSQL → ClickHouse → Superset: репликация для аналитики

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

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

Выберите способ переноса

Есть три разных подхода: периодическая пакетная загрузка, CDC через отдельный коннектор и движок MaterializedPostgreSQL. Они отличаются задержкой, переносом удалений, работой с изменениями схемы и сложностью восстановления. Если отчёт обновляется раз в сутки, минимальная задержка CDC может не оправдать его сопровождение.

На дату проверки MaterializedPostgreSQL отмечен как экспериментальный движок базы. Он выполняет начальный снимок и затем читает изменения из WAL PostgreSQL. Для ClickHouse Cloud документация рекомендует ClickPipes for Postgres. Нельзя считать экспериментальный движок универсальной заменой поддерживаемого промышленного коннектора.

Что было неверно в коротких инструкциях

У MaterializedPostgreSQL адрес и реквизиты передаются аргументами движка. Настройки host, dbname и произвольное имя replication slot после SETTINGS не заменяют документированный синтаксис. Для экспериментального движка базы применяется настройка allow_experimental_database_materialized_postgresql; флаг похожего движка таблицы — другая настройка.

До пилота проверьте требования выбранного механизма: logical WAL, доступ и права учётной записи, идентификатор строки для обновлений и удалений, лимиты слотов, совместимость типов. Не меняйте эти параметры в рабочей CRM по универсальному примеру без согласованного окна и плана возврата.

Не путайте реплику и аналитическую витрину

Реплика должна сохранять согласованное состояние источника. Витрина может объединять таблицы, агрегировать события и хранить иной набор полей. Эти слои лучше разделить: тогда изменение определения показателя не требует заново настраивать приём CDC.

Например, если по сделке пришли версии с суммами 10 000 и 12 000 рублей, отчёт текущей воронки должен показывать 12 000, а не 22 000. Способ выбора актуальной версии определяется конкретной схемой целевой таблицы и коннектором. Служебные поля версии и удаления нельзя игнорировать или переносить из примера для другого механизма репликации.

Удаление старых строк по TTL меняет полноту данных. Не включайте его в копии «всей CRM», если отчёт должен сравнивать прошлые годы. Сроки хранения исходных записей, версий и агрегатов задаются отдельно.

Подключение Superset

Установите в окружении Superset драйвер, совместимый с выбранным подключением ClickHouse, и используйте строку подключения из его документации. HTTP-интерфейс и нативный протокол ClickHouse используют разные порты. Подстановка нативного порта 9000 в строку HTTP-драйвера не делает соединение рабочим.

Добавьте отдельное подключение, создайте датасеты и проверьте типы дат, часовой пояс, Decimal и Nullable. Перевод существующего дашборда с PostgreSQL требует проверки SQL и показателей. Универсального переключателя, который переписывает PostgreSQL-запросы в ClickHouse без проверки, ожидать не следует.

Как принять пилот

1. Сверьте число ключей и суммы после начальной загрузки за несколько фиксированных периодов.
2. Проверьте вставку, несколько изменений одной строки, удаление и повторную доставку.
3. Прервите доставку и измерьте время догрузки после восстановления. Следите за удерживаемым WAL на PostgreSQL: отставший слот может увеличивать расход диска.
4. Проверьте добавление колонки и новой таблицы. В MaterializedPostgreSQL новые таблицы не подключаются автоматически, а некоторые изменения схемы останавливают обновление затронутой таблицы.
5. Сравните скорость одинаковых отчётов при одинаковой полноте данных и зафиксируйте стоимость сопровождения.

В рабочий дашборд полезно вывести время последней успешной доставки. Быстрый ответ по устаревшей копии не решает задачу оперативной аналитики.