Skip to content

Возможности

Запись Greenplum -> ClickHouse

INSERT в foreign table пишут все сегменты Greenplum параллельно, каждый через свой локальный PXF, напрямую в ClickHouse. Координатор в этой работе не участвует - он подключается только в специальном режиме mpp_execute 'master', когда параллелизм не нужен.

Два режима отправки данных:

  • stream (по умолчанию) - один непрерывный HTTP-запрос на весь INSERT, без промежуточного буфера в памяти.
  • batch - данные копятся в памяти и уходят пакетами заданного размера, с паузой между ними. Это поведение как в ADB ClickHouse Connector 2.0.

Чтение ClickHouse -> Greenplum

SELECT из foreign table читает данные потоково: сегменты забирают свои срезы таблицы параллельно, без буферизации всего ответа целиком.

  • Таблица делится между сегментами по хэшу колонки (slice_mode hash), по диапазону значений (range) или читается одним сплошным потоком без деления (single).
  • Условия WHERE, которые Greenplum может передать удалённому источнику, уходят в ClickHouse как есть - меньше данных идёт по сети.
  • SELECT с указанием конкретных колонок запрашивает у ClickHouse только их, а не всю таблицу целиком.
  • Отмена запроса (pg_cancel_backend) закрывает соединение с ClickHouse и останавливает выполнение запроса на его стороне.

Транзакционный staging

Обычная запись в ClickHouse не связана с транзакцией Greenplum: если INSERT прервался на середине, часть строк, которые ClickHouse уже принял, останется в таблице - откат Greenplum их не уберёт.

Опция use_staging решает эту проблему. Каждый сегмент пишет во временную таблицу ClickHouse, и только на COMMIT транзакции Greenplum данные переносятся в целевую таблицу. При ROLLBACK временная таблица просто удаляется. Перенос делает сам ClickHouse - либо присоединением партиций (ATTACH PARTITION), либо INSERT ... SELECT, в зависимости от того, совпадает ли структура таблиц.

Если координатор Greenplum упал между записью во временную таблицу и переносом данных, такая таблица остаётся в ClickHouse - для очистки таких сирот есть функция clickhouse.cleanup_staging().

Совместимость с ADB ClickHouse Connector 2.0

DDL, написанный под tkh_fdw из ADB ClickHouse Connector 2.0, работает на этом коннекторе без изменений: те же имена foreign data wrapper, опций и уровней, тот же синтаксис CREATE SERVER/CREATE FOREIGN TABLE/CREATE USER MAPPING. Разбор с примерами - на странице Использование.

Типы данных

Коннектор сопоставляет типы Greenplum и ClickHouse в обе стороны: числа, строки, даты и время, numeric/Decimal без потери точности, bool, bytea как есть, побайтово, без перекодировки. Массивы (T[]) сопоставляются с Array(T), включая вложенные массивы и NULL-элементы (в ClickHouse для этого нужен Array(Nullable(T))).

Полная таблица соответствия типов - на странице Конфигурация.

Сеть, кластер, SSL

Коннектор умеет работать с несколькими хостами ClickHouse сразу, распределяя запросы между ними случайным образом или по кругу, и переключаться на другой хост при сетевой ошибке. Опция cluster расширяет список хостов репликами из system.clusters. Подключение по HTTPS настраивается через clickhouse_properties - выбор сертификата и режима проверки.

Метрики

Каждый хост PXF отдаёт метрики коннектора в формате Prometheus тем же портом, что и общее состояние PXF. Это счётчики записанных и прочитанных строк и байт, число успешных и неудачных батчей, ошибки по видам и время выполнения операций, включая staging.

Ограничения версии 1.1

  • Нет UPDATE/DELETE - только INSERT на запись и SELECT на чтение.
  • NULL в колонке типа String без Nullable ClickHouse молча превращает в пустую строку - это поведение самой ClickHouse, не коннектора.
  • NULL в колонке-массиве ClickHouse отклоняет ошибкой - массивы в ClickHouse не бывают Nullable.
  • Опция cluster требует явно заданного hosts - без стартового адреса опросить system.clusters не с чего, а адреса, которые вернёт system.clusters, должны быть достижимы с каждого сегмента.

Подробный разбор всех ограничений - на страницах Использование и Конфигурация.