Коннектор Vertica#

Коннектор Vertica позволяет запрашивать базу данных Vertica, также известную как OpenText Analytics Database, как внешний источник данных.

Требования#

Для подключения к Vertica необходимо:

Vertica 11.x или выше.
Сетевой доступ от координатора и workers к серверу Vertica. Порт по умолчанию — 5433.

Конфигурация#

Создайте файл свойств каталога в etc/catalog с именем example.properties, чтобы обращаться к настроенной базе данных Vertica в каталоге example. Замените example именем вашей базы данных или другим описательным именем каталога. Настройте использование коннектора, указав имя vertica, и замените свойства подключения в соответствии с вашей средой.

connector.name=vertica
connection-url=jdbc:vertica://example.net:5433/test_db
connection-user=root
connection-password=secret

connection-user и connection-password обычно обязательны и определяют учетные данные пользователя для подключения, часто сервисного пользователя. Можно использовать секреты, чтобы не хранить реальные значения в файлах свойств каталога.

Общие свойства конфигурации#

В следующей таблице описаны общие свойства конфигурации каталога для коннектора:

Имя свойства	Описание
`case-insensitive-name-matching`	Поддержка имен схем и таблиц без учета регистра. По умолчанию — `false`.
`case-insensitive-name-matching.cache-ttl`	Длительность, в течение которой кэшируются имена схем и таблиц при сопоставлении без учета регистра. По умолчанию — `1m`.
`case-insensitive-name-matching.config-file`	Путь к конфигурационному файлу сопоставления имен в формате JSON, который позволяет Trino различать схемы и таблицы с похожими именами в разных регистрах. По умолчанию — `null`.
`case-insensitive-name-matching.config-file.refresh-period`	Частота, с которой Trino проверяет конфигурационный файл сопоставления имен на изменения. Значение длительности по умолчанию — `0s` (обновление отключено).
`metadata.cache-ttl`	Длительность, в течение которой кэшируются метаданные, включая статистику таблиц и столбцов. По умолчанию — `0s` (кэширование отключено).
`metadata.cache-missing`	Кэшировать факт недоступности метаданных, включая статистику таблиц и столбцов. По умолчанию — `false`.
`metadata.schemas.cache-ttl`	Длительность, в течение которой кэшируются метаданные схем. По умолчанию равно значению `metadata.cache-ttl`.
`metadata.tables.cache-ttl`	Длительность, в течение которой кэшируются метаданные таблиц. По умолчанию равно значению `metadata.cache-ttl`.
`metadata.statistics.cache-ttl`	Длительность, в течение которой кэшируется статистика таблиц. По умолчанию равно значению `metadata.cache-ttl`.
`metadata.cache-maximum-size`	Максимальное число объектов, хранящихся в кэше метаданных. По умолчанию — `10000`.
`write.batch-size`	Максимальное число операторов в пакетном выполнении. Не меняйте это значение относительно значения по умолчанию. Нестандартные значения могут отрицательно повлиять на производительность. По умолчанию — `1000`.
`dynamic-filtering.enabled`	Проталкивать динамические фильтры в JDBC-запросы. По умолчанию — `true`.
`dynamic-filtering.wait-timeout`	Максимальная длительность, в течение которой Trino ожидает сбора динамических фильтров со стороны построения соединения перед запуском JDBC-запроса. Большой тайм-аут потенциально может дать более подробные динамические фильтры, но также может увеличить задержку некоторых запросов. По умолчанию — `20s`.

Добавление метаданных запроса#

Необязательный параметр query.comment-format позволяет настроить SQL-комментарий, который отправляется источнику данных с каждым запросом. Формат комментария может содержать любые символы и следующие метаданные:

$QUERY_ID: идентификатор запроса.
$USER: имя пользователя, отправившего запрос в Trino.
$SOURCE: идентификатор клиентского инструмента, использованного для отправки запроса, например trino-cli.
$TRACE_TOKEN: токен трассировки, настроенный в клиентском инструменте.

Комментарий может предоставить больше контекста о запросе. Эта дополнительная информация доступна в журналах источника данных. Чтобы включить в комментарий переменные окружения из кластера Trino, используйте синтаксис ${ENV:VARIABLE-NAME}.

Следующий пример задает простой комментарий, идентифицирующий каждый запрос, отправленный Trino:

query.comment-format=Query sent by Trino.

С такой конфигурацией запрос вроде SELECT * FROM example_table; отправляется источнику данных с добавленным комментарием:

SELECT * FROM example_table; /*Query sent by Trino.*/

Следующий пример улучшает предыдущий, используя метаданные:

query.comment-format=Query $QUERY_ID sent by user $USER from Trino.

Если Jane отправила запрос с идентификатором 20230622_180528_00000_bkizg, источнику данных отправляется следующая строка комментария:

SELECT * FROM example_table; /*Query 20230622_180528_00000_bkizg sent by user Jane from Trino.*/

Note

Некоторые настройки драйвера JDBC и конфигурации журналирования могут привести к удалению комментария.

Порог компактирования домена#

Проталкивание большого списка предикатов в источник данных может ухудшить производительность. По умолчанию Trino компактирует большие предикаты в более простой предикат диапазона, чтобы сохранить баланс между производительностью и проталкиванием предикатов. При необходимости порог такого компактирования можно увеличить, чтобы повысить производительность, когда источник данных способен эффективно использовать большие предикаты. Увеличение этого порога может улучшить проталкивание больших динамических фильтров. Свойство конфигурации каталога domain-compaction-threshold или свойство сеанса каталога domain_compaction_threshold можно использовать для изменения значения по умолчанию 256 для этого порога.

Сопоставление без учета регистра#

Когда case-insensitive-name-matching установлено в true, Trino может запрашивать схемы и таблицы с именами не только в нижнем регистре, поддерживая сопоставление имени в нижнем регистре с фактическим именем в удаленной системе. Однако если две схемы и/или таблицы имеют имена, различающиеся только регистром, например “customers” и “Customers”, Trino не сможет запрашивать их из-за неоднозначности.

В таких случаях используйте свойство конфигурации каталога case-insensitive-name-matching.config-file, чтобы указать конфигурационный файл, сопоставляющий эти удаленные схемы и таблицы с соответствующими схемами и таблицами Trino. Кроме того, JSON-файл должен включать оба свойства, schemas и tables, даже если они заданы только как пустые массивы.

{
  "schemas": [
    {
      "remoteSchema": "CaseSensitiveName",
      "mapping": "case_insensitive_1"
    },
    {
      "remoteSchema": "cASEsENSITIVEnAME",
      "mapping": "case_insensitive_2"
    }],
  "tables": [
    {
      "remoteSchema": "CaseSensitiveName",
      "remoteTable": "tablex",
      "mapping": "table_1"
    },
    {
      "remoteSchema": "CaseSensitiveName",
      "remoteTable": "TABLEX",
      "mapping": "table_2"
    }]
}

Запросы к одной из таблиц или схем, заданных в атрибутах mapping, выполняются к соответствующей удаленной сущности. Например, запрос к таблицам в схеме case_insensitive_1 перенаправляется в схему CaseSensitiveName, а запрос к case_insensitive_2 — в схему cASEsENSITIVEnAME.

На уровне сопоставления таблиц запрос к case_insensitive_1.table_1 в приведенной выше конфигурации перенаправляется к CaseSensitiveName.tablex, а запрос к case_insensitive_1.table_2 — к CaseSensitiveName.TABLEX.

По умолчанию после изменения конфигурационного файла сопоставления Trino нужно перезапустить, чтобы загрузить изменения. При необходимости можно задать case-insensitive-name-matching.config-file.refresh-period, чтобы Trino обновлял свойства без перезапуска:

case-insensitive-name-matching.config-file.refresh-period=30s

Сопоставление типов#

Поскольку Trino и Vertica поддерживают типы, которых нет в другой системе, этот коннектор изменяет некоторые типы при чтении или записи данных. Типы данных могут сопоставляться по-разному в направлениях между Trino и источником данных. В следующих разделах описано сопоставление типов для каждого направления.

Сопоставление типов Vertica с типами Trino#

Коннектор сопоставляет типы Vertica с соответствующими типами Trino согласно следующей таблице:

Сопоставление типов Vertica с типами Trino#
Тип Vertica	Тип Trino	Примечания
`BOOLEAN`	`BOOLEAN`
`BIGINT`	`BIGINT`	Vertica рассматривает TINYINT, SMALLINT, INTEGER и BIGINT как синонимы одного и того же 64-битного типа данных BIGINT
`DOUBLE PRECISION (FLOAT)`	`DOUBLE`	Vertica рассматривает FLOAT и REAL как один и тот же 64-битный IEEE FLOAT
`DECIMAL(p, s)`	`DECIMAL(p, s)`
`CHAR, CHAR(n)`	`CHAR, CHAR(n)`
`VARCHAR`, `LONG VARCHAR`, `VARCHAR(n)`, `LONG VARCHAR(n)`	`VARCHAR(n)`
`VARBINARY`, `LONG VARBINARY`, `VARBINARY(n)`, `LONG VARBINARY(n)`	`VARBINARY(n)`
`DATE`	`DATE`

Другие типы не поддерживаются.

Неподдерживаемые типы Vertica можно преобразовать в VARCHAR с помощью свойства сеанса vertica.unsupported_type_handling. Значение этого свойства по умолчанию — IGNORE.

SET SESSION vertica.unsupported_type_handling='CONVERT_TO_VARCHAR';

Сопоставление типов Trino с типами Vertica#

Коннектор сопоставляет типы Trino с соответствующими типами Vertica согласно следующей таблице:

Сопоставление типов Trino с типами Vertica#
Тип Trino	Тип Vertica
`BOOLEAN`	`BOOLEAN`
`TINYINT`	`BIGINT`
`SMALLINT`	`BIGINT`
`INTEGER`	`BIGINT`
`BIGINT`	`BIGINT`
`REAL`	`DOUBLE PRECISION`
`DOUBLE`	`DOUBLE PRECISION`
`DECIMAL(p, s)`	`DECIMAL(p, s)`
`CHAR`	`CHAR`
`VARCHAR`	`VARCHAR`
`VARBINARY`	`VARBINARY`
`DATE`	`DATE`

Другие типы не поддерживаются.

Свойства конфигурации сопоставления типов#

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

Имя свойства

Описание

Значение по умолчанию

unsupported-type-handling

Настраивает обработку неподдерживаемых типов данных столбцов:

IGNORE — столбец недоступен.
CONVERT_TO_VARCHAR — столбец преобразуется в неограниченный VARCHAR.

Соответствующее свойство сеанса каталога — unsupported_type_handling.

IGNORE

jdbc-types-mapped-to-varchar

Позволяет принудительно сопоставлять списки типов данных, разделенные запятыми, с неограниченным VARCHAR.

Поддержка SQL#

Коннектор предоставляет доступ на чтение и запись к данным и метаданным в Vertica. Помимо глобально доступных операторов и операторов чтения, коннектор поддерживает следующие возможности:

Управление данными
CREATE TABLE
CREATE TABLE AS
DROP TABLE
ALTER TABLE, кроме DROP COLUMN; см. также ALTER TABLE RENAME TO limitation
CREATE SCHEMA
DROP SCHEMA
Табличные функции

ALTER TABLE RENAME TO limitation#

The connector does not support renaming tables across multiple schemas. For example, the following statement is supported:

ALTER TABLE example.schema_one.table_one RENAME TO example.schema_one.table_two

The following statement attempts to rename a table across schemas, and therefore is not supported:

ALTER TABLE example.schema_one.table_one RENAME TO example.schema_two.table_two

Табличные функции#

Коннектор предоставляет специальные табличные функции для доступа к Vertica.

`query(VARCHAR) -> table`#

Функция query позволяет напрямую запрашивать базовую базу данных. Она требует синтаксис, родной для источника данных, поскольку весь запрос проталкивается вниз и обрабатывается в источнике данных. Это может быть полезно для доступа к нативным возможностям или для повышения производительности запросов в ситуациях, когда выполнение запроса нативно может быть быстрее.

Табличная функция query доступна в схеме system любого каталога, который использует коннектор Vertica, например example. Следующий пример передает myQuery в источник данных. myQuery должен быть допустимым запросом для источника данных и обязан возвращать таблицу в качестве результата:

SELECT
  *
FROM
  TABLE(
    example.system.query(
      query => 'myQuery'
    )
  );

Note

Движок запросов не сохраняет порядок результатов этой функции. Если переданный запрос содержит предложение ORDER BY, результат функции может быть упорядочен не так, как ожидается.

Производительность#

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

Pushdown#

Коннектор поддерживает pushdown для ряда операций:

Проталкивание соединений#

Свойство конфигурации каталога join-pushdown.enabled или свойство сеанса каталога join_pushdown_enabled управляет тем, проталкивает ли коннектор операции соединения. По умолчанию свойство имеет значение false, а включение проталкивания соединений может отрицательно повлиять на производительность некоторых запросов.

Статистика таблиц#

Оптимизатор на основе стоимости может использовать статистику таблиц из базы данных Vertica для повышения производительности запросов.

Поддержка статистики таблиц по умолчанию отключена. Ее можно включить с помощью свойства каталога statistics.enabled, установленного в true. Кроме того, connection-user, настроенный в каталоге, должен иметь права суперпользователя в Vertica, чтобы собирать и заполнять статистику.

Статистику можно просмотреть с помощью SHOW STATS.