Сведения о настройке
Управление пользователями и ролями
default; вместо этого создайте отдельного пользователя исключительно для этого пункта назначения Fivetran. Следующие команды, выполненные от имени пользователя default, создадут нового пользователя fivetran_user с необходимыми привилегиями.
fivetran_user доступ к определённым базам данных.
Например, выполнив следующий оператор, мы ограничим доступ к базе данных default:
Расширенная конфигурация
Эта конфигурация полностью необязательна. Если файл не загружен, пункт назначения использует подходящие параметры по умолчанию, которые хорошо работают в большинстве сценариев.
Все поля необязательны. Если поле не указано, используется значение по умолчанию.
Если значение выходит за пределы допустимого диапазона, коннектор назначения сообщит об ошибке во время синхронизации.
Неизвестные поля игнорируются без уведомления (при этом в журнал записывается предупреждение) и не вызывают ошибок, что обеспечивает совместимость при добавлении новых настроек.
Пример:
Сопоставление преобразования типов
- BINARY, XML, LOCALTIME и JSON хранятся как String, поскольку тип
Stringв ClickHouse может представлять произвольный набор байтов. Пункт назначения добавляет комментарий к столбцу, чтобы указать исходный тип данных. Тип данных JSON в ClickHouse не используется, так как он был помечен как устаревший и никогда не рекомендовался для использования в продакшн. ** ПРИМЕЧАНИЕ: Задача для отслеживания поддержки типа LOCALTIME: clickhouse-fivetran-destination #15.
Диапазоны значений даты и времени
- Верхняя граница для INSTANT — 2262-04-11 23:47:16, поскольку DateTime64(9) хранит наносекунды с epoch в формате int64, а 2^63 - 1 наносекунд соответствует этой дате. Сам ClickHouse поддерживает DateTime64 с precision <= 9 вплоть до 2299-12-31 23:59:59.
- Верхняя граница для LOCALDATETIME также ограничена значением 2262-04-11 23:47:16 из-за известной ошибки в Go-драйвере ClickHouse:
time.Time.UnixNano()вызывается для всех значений precision у DateTime64 до scaling, что приводит к overflow int64 для дат после 2262 года даже при precision 0.
Целевые таблицы
SharedReplacingMergeTree) с версионированием по столбцу _fivetran_synced.
Каждый столбец, кроме первичных (сортировочных) ключей и столбцов метаданных Fivetran, создается
как Nullable(T), где T — это
тип ClickHouse Cloud на основе сопоставления типов данных.
Структура таблицы различается в зависимости от режима
синхронизации,
настроенного для коннектора: мягкое удаление (по умолчанию) или режим истории (SCD Type 2).
Режим мягкого удаления
Один первичный ключ в исходной таблице
users содержит столбец первичного ключа id (INT) и обычный столбец name (STRING).
Целевая таблица будет определена следующим образом:
id выбран в качестве ключа сортировки таблицы.
Несколько первичных ключей в исходной таблице
items со столбцами первичного ключа id (INT) и name (STRING), а также дополнительным обычным столбцом description (STRING). Целевая таблица будет определена следующим образом:
id и name выбраны в качестве ключей сортировки таблицы.
В исходной таблице нет первичных ключей
_fivetran_id.
Рассмотрим таблицу events, в которой есть только столбцы event (STRING) и timestamp (LOCALDATETIME).
В этом случае целевая таблица будет выглядеть следующим образом:
_fivetran_id уникален и других вариантов первичного ключа нет, он используется в качестве ключа сортировки таблицы.
Режим истории (SCD Type 2)
Столбец
_fivetran_start всегда включается в предложение ORDER BY как последний элемент составного ключа сортировки.
Это позволяет нескольким версиям одной и той же записи (с разным временем начала) сосуществовать в таблице.
Когда запись обновляется:
- Для предыдущей версии значение
_fivetran_endустанавливается равным значению_fivetran_startновой версии минус одна наносекунда, а_fivetran_activeустанавливается вfalse. - Новая версия вставляется со значением
_fivetran_active, установленным вtrue, и значением_fivetran_end, установленным в2262-04-11 23:47:16.000000000(максимальное значениеDateTime64(9)).
Один первичный ключ в исходной таблице
users есть столбец первичного ключа id (INT) и обычные столбцы name (STRING) и status (STRING).
Целевая таблица в режиме истории будет определена следующим образом:
id и _fivetran_start образуют составной ключ сортировки.
После нескольких синхронизаций таблица может содержать следующие данные:
У записи
id=1 есть две версии: исходная (name 1, неактивная) и обновлённая (name 11, активная).
У записи id=2 есть только одна версия, и сейчас она активна.
Несколько первичных ключей в исходной таблице
ORDER BY, а _fivetran_start указывается последним элементом.
Например, есть исходная таблица items со столбцами первичного ключа id (INT) и name (STRING), а также
дополнительным обычным столбцом description (STRING). Целевая таблица в режиме истории определяется следующим образом:
id, name и _fivetran_start образуют составной ключ сортировки.
В исходной таблице нет первичных ключей
_fivetran_id,
а _fivetran_start будет добавлен в ключ сортировки.
Рассмотрим таблицу events, в которой в источнике есть только столбцы event (STRING) и timestamp (LOCALDATETIME).
Целевая таблица в режиме истории выглядит следующим образом:
_fivetran_id и _fivetran_start образуют составной ключ сортировки.
Выбор последней версии данных без дубликатов
SharedReplacingMergeTree выполняет фоновую дедупликацию данных
только во время слияний и в непредсказуемый момент времени.
Однако получить последнюю версию данных без дубликатов по запросу можно с помощью ключевого слова FINAL:
Повторные попытки при сетевых сбоях
SharedReplacingMergeTree.