kql

Официальный skill Microsoft для Kusto Query Language помогает писать, проверять и отлаживать запросы в Azure Data Explorer, Microsoft Fabric Real-Time Intelligence, EventHouse, Azure Monitor Log Analytics и связанных сервисах. Его назначение — не отдельный клиент или библиотека, а практическая работа с самим языком и его типичными ловушками. В основе KQL лежит потоковая форма: таблица или оператор подаются слева, затем результат последовательно проходит через where, summarize, top, project и другие операторы, соединённые вертикальной чертой. Такой порядок удобно читать как конвейер преобразований и использовать для анализа логов, событий, временных рядов и данных наблюдаемости. Карточка отдельно различает два плана выполнения. Запрос может начинаться таблицей, let, print или datatable, а управляющая команда — точкой, например .show, .create, .set, .drop или .alter. Управляющие команды могут отдавать табличный результат для дальнейшей обработки, но обычный запрос нельзя продолжить управляющей командой после pipe-forward цепочки. Это ограничение важно проверять до запуска, потому что ошибка здесь относится к форме запроса, а не к данным. Большой раздел посвящён dynamic-типу. Если динамическое значение используется в группировке summarize, сортировке order by или ключе join, его нужно явно привести к подходящему типу, например tostring, tolong или todouble. Для join skill фиксирует ещё два ограничения: условие соединения должно использовать равенство, а обе стороны должны ссылаться на выбранные колонки, а не на произвольные выражения. Диапазонные соединения предлагается предварительно сводить к общим корзинам через bin; перед крупным join следует проверить кардинальность обеих сторон, чтобы не получить неконтролируемый рост результата. Для регулярных выражений описан важный нюанс extract_all: шаблон должен содержать захватывающую группу. Для оконных функций вроде row_number, row_cumsum, prev и next входные строки должны быть сериализованы; этого добиваются через serialize или подходящую сортировку. Практика безопасного выполнения строится от предварительного count и ограниченного take к фильтрации по времени и ключу до summarize. Для больших таблиц рекомендуется сокращать число колонок, не делать дорогой dcount без предварительного фильтра и применять materialize только для действительно повторно используемых подзапросов. Skill полезен при расследовании ошибок dynamic type, E_LOW_MEMORY_CONDITION и E_RUNAWAY_QUERY, при подготовке joins и при постепенном расширении исследовательского запроса. Он также требует дисциплины размера ответа: для разведочных запросов использовать take, для агрегатов — top, для широких строк — project только нужные поля; векторы и другие объёмные значения не следует вытаскивать без необходимости. Ограничение карточки простое: она описывает язык и безопасные паттерны построения запросов, но не заменяет проверку схемы конкретного кластера, разрешений, объёма данных или актуальной документации сервиса. Для production-запроса всё равно нужно проверить реальную схему, диапазон времени и стоимость выполнения на целевой платформе.