Альтернативные языки запросов

Использование альтернативных языков запросов в ClickHouse

Помимо стандартного SQL, ClickHouse поддерживает различные альтернативные языки запросов для работы с данными.

В настоящее время поддерживаются следующие диалекты:

• clickhouse: Диалект SQL, используемый в ClickHouse по умолчанию
• prql: конвейерный реляционный язык запросов (PRQL)
• kusto: язык запросов Kusto (KQL)
• trino: Trino SQL

Используемый язык запросов задаётся параметром dialect.

​

Стандартный SQL

Стандартный SQL — язык запросов ClickHouse по умолчанию.

SET dialect = 'clickhouse'

​

Конвейерный реляционный язык запросов (PRQL)

Чтобы включить PRQL:

SET allow_experimental_prql_dialect = 1; -- этот оператор SET требуется только для версий ClickHouse >= v25.1
SET dialect = 'prql'

Пример PRQL-запроса:

from trips
aggregate {
    ct = count this
    total_days = sum days
}

ClickHouse использует транспиляцию из PRQL в SQL для выполнения запросов PRQL.

​

Язык запросов Kusto (KQL)

Чтобы включить KQL:

SET allow_experimental_kusto_dialect = 1; -- этот оператор SET требуется только для версий ClickHouse >= 25.1
SET dialect = 'kusto'

Query

numbers(10) | project number

Response

┌─number─┐
│      0 │
│      1 │
│      2 │
│      3 │
│      4 │
│      5 │
│      6 │
│      7 │
│      8 │
│      9 │
└────────┘

Обратите внимание, что KQL-запросы могут не поддерживать все функции, определённые в ClickHouse.

​

Trino SQL

Чтобы включить диалект Trino:

SET enable_trino_dialect = 1;
SET dialect = 'trino'

Специфичный для Trino синтаксис преобразуется в ClickHouse SQL, а имена функций Trino сопоставляются с их эквивалентами в ClickHouse:

Query

SELECT approx_distinct(x) FROM (VALUES 1, 2, 2) AS t(x)

Response

┌─uniq(x)─┐
│       2 │
└─────────┘

Трансляция охватывает, в частности, литералы ARRAY[...], TRY_CAST, UNNEST (транслируется в ARRAY JOIN), конструкторы и типы ROW, таблицы VALUES, OFFSET перед LIMIT, BETWEEN SYMMETRIC, а также несколько сотен функций, включая те, имена которых есть в обеих системах, но с разной семантикой (например, в Trino length считает кодовые точки Unicode и транслируется в lengthUTF8). Функции ClickHouse, имена которых не конфликтуют с именами Trino, остаются доступными, поэтому оба семейства функций можно смешивать в одном запросе.

Значения JSON из Trino отображаются на тип ClickHouse JSON: литералы JSON '...' и json_parse превращаются в приведение к JSON, json_format — в toJSONString, а функции работы с путями (json_extract, json_extract_scalar, json_value, json_query, json_exists, json_size) транслируются в свои аналоги в ClickHouse. Поскольку тип JSON в ClickHouse хранит объекты, документы, не являющиеся объектами (массивы и скалярные значения верхнего уровня), отклоняются при материализации в виде значений JSON; функции работы с путями принимают любой JSON-текст.

Некоторые особенности семантики Trino невозможно выразить в тексте транслированного запроса — вместо этого они применяются к контексту запроса: внешние соединения дают NULL (join_use_nulls), операции над множествами используют числовой супертип, а не Variant (use_variant_as_common_type), и требуется query analyzer (enable_analyzer). Явно указанная в запросе секция SETTINGS по-прежнему имеет приоритет над этими значениями.

Семантика, которую нельзя исправить трансляцией на уровне запроса, остаётся семантикой ClickHouse. В первую очередь это касается оператора деления /: в Trino он выполняет целочисленное деление, а в ClickHouse — деление с плавающей точкой; кроме того, round в ClickHouse для аргументов типа Float использует банковское округление.

Используйте EXPLAIN SYNTAX, чтобы увидеть, как транслируется запрос.