NiFi → PostgreSQL и ClickHouse → Superset: доставка в две базы

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

PostgreSQL и ClickHouse могут обслуживать разные запросы одного аналитического решения. Например, PostgreSQL хранит актуальные карточки, ClickHouse — большой журнал событий. NiFi доставляет данные, Superset показывает подготовленные датасеты. Две базы полезны только при понятном разделении ответственности и способе сверки.

Определите, что хранит каждая ветка

Текущее состояние и история изменений имеют разную гранулярность. В PostgreSQL одна строка может означать одну сделку, а в ClickHouse — одну версию или одно событие. Одинаковые названия колонок не делают эти наборы взаимозаменяемыми.

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

Рабочие компоненты NiFi

В официальном примере NiFi и ClickHouse используются JDBC-подключение, MergeRecord и PutDatabaseRecord. Имя PutClickHouseBatch из прежней инструкции не следует считать стандартным процессором без указания отдельного пакета и его документации.

Для PostgreSQL настройте отдельный пул подключения и PutDatabaseRecord под выбранную операцию. Поля Record Reader должны соответствовать колонкам таблицы, а обновление — существующему ключу. Выдайте роли необходимые права на фактические операции; INSERT без UPDATE недостаточен для обновления существующих строк.

Для ClickHouse используйте поддерживаемый JDBC-драйвер или явно настроенную отправку через HTTP-интерфейс. Формат тела должен соответствовать способу вставки: Avro-данные после ConvertRecord нельзя отправить как JSONEachRow без преобразования. Размер пакета определяйте испытанием, а не универсальным числом строк.

Полная загрузка и последующие изменения

Фильтр «изменено за последние 10 минут» потеряет данные после часового простоя. Используйте сохранённую контрольную точку, перекрытие границ, пагинацию и обработку повторов. Отдельно запланируйте первую загрузку и сверку удалений.

Один пакет должен иметь идентификатор и доступный для повторной обработки исходный набор. Состояние доставки храните отдельно для PostgreSQL и ClickHouse. Успех одной ветки не разрешает удалить единственную копию данных, не доставленных во вторую.

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

Датасеты Superset

Зарегистрируйте два подключения и создайте датасеты по назначению. SQL PostgreSQL и ClickHouse отличается: функции дат, типы, обработка NULL и особенности агрегирования нужно проверять. Переключение диалекта не происходит автоматически при совпадении имени таблицы.

Не рассчитывайте на выдуманное правило Dynamic Datasource «период больше трёх месяцев — переключить базу». Если требуется маршрутизация запросов, это отдельная задача архитектуры. Более простой вариант — явно названные графики текущего состояния и истории, с понятными периодами и датой актуальности.

Для HTTP-драйвера ClickHouse используйте соответствующий HTTP(S)-адрес; нативный порт 9000 не подходит автоматически. Проверяйте соединение из окружения Superset, а не только с рабочего компьютера.

Сверка и восстановление

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

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