Kusto Query Language (KQL) в ClickHouse

SET allow_experimental_kusto_dialect = 1;
SET dialect = 'kusto';

StormEvents
| where State == 'FLORIDA' and DamageProperty > 0
| summarize Total = sum(DamageProperty) by EventType
| top 5 by Total

​

Что поддерживается

let MultiplyByN = (val: long, n: long = 2) { val * n };
let RecentErrors = (since: timespan) { Logs | where Level == 'Error' and Timestamp > ago(since) };

RecentErrors(1h) | summarize Count = count() by Component

SET dialect = 'kusto';

StormEvents
| extend Bucket = toStartOfHour(StartTime), Fingerprint = cityHash64(EventType)
| summarize Events = count() by Bucket

​

Покрытие относительно справочника Kusto

​

Что не поддерживается

• Операторы: search, parse, mv-apply, lookup, evaluate, invoke, facet, top-nested, make-series, sample, serialize, partition, range в качестве оператора.
• Функции: семейство series_*, bag_* / pack_*, parse_url, parse_csv, parse_json, todynamic, toscalar, format_timespan, format_datetime, extract_all, range, семейство percentiles* и оконные функции row_*. (format_datetime и extract_all отклоняются, а не аппроксимируются: спецификаторы формата yyyy-MM-dd в Kusto отличаются от используемых в ClickHouse, а extract_all в Kusto возвращает по одному массиву на каждую группу захвата.)
• Имена Kusto, совпадающие с функциями ClickHouse, но имеющие другое значение: range (указана выше), repeat, replace, translate и materialize. Их прямое преобразование незаметно дало бы другой результат: repeat(1, 3) в Kusto создаёт массив [1, 1, 1], тогда как repeat в ClickHouse повторяет строку, поэтому все эти имена отклоняются.
• Геопространственные функции, принимающие или возвращающие GeoJSON: все geo_*_to_central_point и всё, что работает с полигонами и линиями. Функции для точек, Geohash и H3, работающие с обычными значениями долготы и широты, поддерживаются. geo_point_to_s2cell не поддерживается: в ClickHouse нет представления S2 в виде токена.
• Объекты dynamic (dynamic({"a": 1})), доступ к членам (x.y) и поиск по ключу (x['k']). Сопоставляются только массивы dynamic — с Array в ClickHouse. dynamic как объявленный тип — в схеме datatable, typeof(...) или параметре функции — также отклоняется: аннотация не содержит тип элемента, поэтому его невозможно сопоставить без потери точности.
• Межкластерные и межбазовые ссылки, такие как cluster(...) и database(...).
• Подсказки для запросов и join (hint.strategy, hint.shufflekey, …).
• Параметры операторов: mv-expand ... to typeof(T) / limit N / bagexpansion, подсказки summarize, union kind= / withsource= / isfuzzy=, join hint.*.
• Шаблоны столбцов с подстановочными знаками в project-away и project-keep (project-away Tmp*): для раскрытия такого шаблона нужна схема, которая недоступна при разборе. Перечислите столбцы явно.
• Механизм плагинов evaluate целиком, а вместе с ним bag_unpack, pivot, narrow, python, R и остальные.
• Операторы приложения: alias database, declare pattern, declare query_parameters, restrict access to.
• Обфусцированные строковые литералы (h"...") и многострочные литералы (тройные обратные апострофы).

​

Важные особенности поведения

• Временные интервалы — это значения Interval. 1d преобразуется в toIntervalNanosecond(86400000000000). Чтобы отображать их в формате Kusto (1.00:00:00), а не в виде числа, задайте interval_output_format = 'kusto'.
• Деление выполняется как в Kusto: 7 / 2 равно 3, поскольку оба операнда — целые числа, а результат деления временного интервала на временной интервал — вещественное отношение (15ms / 10ms равно 1.5). Это реализовано в kqlDivide, которая определяет поведение по типам аргументов.
• Вычитание двух значений даты и времени даёт число секунд, тогда как Kusto возвращает временной интервал. Сложение и вычитание временных интервалов работают ожидаемым образом.
• sort по умолчанию сортирует по убыванию, в отличие от SQL, и помещает null-значения в начало.
• project-rename перемещает переименованный столбец в конец строки. Kusto сохраняет его исходную позицию; для воспроизведения этого потребовалось бы знать схему при разборе.
• union требует, чтобы операнды имели совместимые схемы. Kusto расширяет схему до объединения всех столбцов и дополняет отсутствующие значения null; UNION ALL в ClickHouse этого не делает.
• Строковые операторы — это функции сопоставления, а не шаблоны LIKE. contains '50%' ищет буквальный знак процента.
• geo_* принимает долготу перед широтой, как и Kusto. geo_distance_2points использует greatCircleDistance ClickHouse — быстрое приближение, которое отличается от Kusto в четвёртой значащей цифре — примерно на 600 м при расстоянии 1500 км, — а use_spheroid = true выбирает geoDistance, формулу эллипсоида, как в Kusto. Точное совпадение не является целью: эти функции обычно используются для фильтрации, а не для отчётности. Обратите внимание, что координата вне диапазона [-180, 180] или [-90, 90] даёт бессмысленное число, а не null, который возвращает Kusto: ни одна из функций ClickHouse не проверяет диапазон аргументов, а такая проверка потребовала бы восьми сравнений на строку.
• dayofweek() возвращает временной интервал, а не число: понедельник — это 1.00:00:00.
• tohex() выводит отрицательное значение с разрядностью 64 бита. Kusto выводит его с разрядностью, соответствующей типу самого аргумента, который не виден при разборе.
• Значения даты и времени — это настоящие значения DateTime64, поэтому они выводятся в формате ClickHouse (2017-01-01 00:00:00), а не в формате Kusto (2017-01-01T00:00:00.0000000). Предыдущая реализация создавала форматированную строку, которая выглядела как в Kusto, но не сравнивалась и не сортировалась как дата и время.
• Параметрические агрегатные функции ClickHouse (quantileExact(0.5)(x)) не имеют аналога в KQL. Используйте именованную альтернативу, например medianExact(x).

​

Сообщение о проблеме