Справка

SQL-движок и схема данных

Движок визуализации Pyrus использует ClickHouse — высокопроизводительную колоночно-ориентированную систему управления базами данных, идеально подходящую для сложных аналитических запросов (OLAP). Это позволяет быстро обрабатывать большие объемы данных и строить отчёты в реальном времени.

Как работает создание отчёта

Процесс преобразования вашего SQL-запроса в готовый виджет проходит несколько шагов.

  1. Вы пишите SQL-запрос в редакторе, который может включать псевдонимы и параметры.
  2. При нажатии кнопки Выполнить параметры заменяются на актуальные значения из интерфейса пользователя (например, выбранные фильтры, значения полей задачи).
  3. Финальный запрос отправляется в ClickHouse, который формирует выборку из таблиц #tasks или #events в единую таблицу.
  4. После получения ответа от ClickHouse распознаются и применяются псевдонимы (например, ID задачи преобразуется в активную ссылку на задачу).
  5. Итоговый, отформатированный результат выводится пользователю в виде виджета.

Обратите внимание: если запрос некорректен, система сразу сообщает об ошибке (например, об ошибках синтаксиса).

Терминология

В SQL-запросах используются два типа специальных маркеров, которые помогают связать статический запрос с динамическим контекстом Pyrus.

ТерминОписаниеИспользование в SQL
ПсевдонимыПреобразуют системные числовые ID (статусы, пользователи, этапы) в понятные человеку названия или ссылки после получения данных от ClickHouseИсключительно в секции SELECT AS.
ПараметрыДинамически встраивают в запрос актуальные значения из задач, а также выбранные в интерфейсе значения фильтров до отправки в ClickHouse.FROM, WHERE, HAVING, ORDER BY.

Источники данных

Для построения отчётов используются две основные таблицы, отличающиеся по своей природе: таблица текущего состояния #tasks и таблица истории событий #events.

Общие поля для #tasks и #events

В этом разделе представлены все поля, которые доступны для использования в обеих таблицах.

Обратите внимание: при использовании этих параметров с таблицей #tasks результатом будет актуальное состояние поля, при вызове в #events результатом будет значение в рассматриваемом временном интервале.

ПолеОписаниеТип ClickHouseЗначение по умолчанию
form_idID формыUInt32
task_idID задачиUInt32
${Выбор}Поле типа Выбор, ID значенияNullable(Int64)Null
${Галочка}Поле типа Галочка, true / falseNullable(Bool)Null
${Справочник:N}Поле типа Справочник, выбранное текстовое значение из N колонки справочникаArray(Nullable(String))Null
${Форма}Поле типа Форма, ID задачиNullable(Int64)Null
${Число}Поле типа Число, введенное числоNullable(Float64)Null
${Деньги}Поле типа Деньги, введенное числоNullable(Float64)Null
${Дата}Поле типа Дата, введенная датаNullable(DateTime64(9,'UTC'))Null
${Время}Поле типа Время, введенная датаNullable(DateTime64(9,'UTC'))Null
${Контакт}Поле типа Контакт, ID пользователяNullable(Int64)Null
is_closedПоле типа Открыта / Завершена, true / falseBoolFalse
responsible_idПоле типа Ответственный, ID пользователяInt320
create_dateПоле типа Дата созданияDateTime64(3,'UTC')
stepПоле типа Этап, ID этапаInt160
statusПоле типа Статус, ID статусаInt160

Таблица #tasks

Эта таблица содержит актуальное состояние задач (например, поля формы, статус задачи). Помимо системных полей, все поля, созданные в форме, доступны для выборки из этой таблицы через их параметры. Каждой задаче соответствует ровно одна строка. Поля, перечисленные в этом разделе, являются уникальными и не доступны к использованию в таблице #events.

Подсказка: используйте #tasks для анализа текущих показателей, например: сколько задач находится в работе, каково их текущее состояние и т.д.

ПолеОписаниеТип ClickHouseЗначение по умолчанию
dueПоле типа СрокDateTime64(3,'UTC')2200-01-01
is_overdueЗадача просроченаBoolFalse
creator_idИдентификатор автора задачиUInt32Система: 1730 Подпроцесс: 656701
last_note_idID последнего комментарияUInt64
last_modified_dateДата последнего измененияDateTime64(3,'UTC')
close_dateДата закрытия задачиDateTime64(3,'UTC')2200-01-01

Таблица #events

Эта таблица хранит хронологию всех изменений по задаче. Каждая строка — это отдельное зафиксированное системное событие (например, смена ответственного, добавление комментария, изменение статуса). При этом одной строке может соответствовать множество изменений внутри системы.

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

ПолеОписаниеТип ClickHouseЗначение по умолчанию
note_idИдентификатор комментарияUInt64
author_idИдентификатор автора событияUInt320
task_createdЗадача создана этим событиемBoolFalse
operator_replyОтвет оператора (исходящее сообщение во внешний канал)BoolFalse
task_dueПоле типа СрокDateTime64(3,'UTC')2200-01-01
is_task_overdueЗадача просрочена на момент событиBoolFalse
task_create_dateДата создания задачиDateTime64(3,'UTC')
task_creator_idИдентификатор создателя задачиUInt32Система: 1730 Подпроцесс: 656701

approval_type

Текущие значения:

0 – не указано

1 – утверждено

2 – отказано

3 – отложено

4 – просмотрено

Решение: Утверждено, Просмотрено и т.д.

Int8

0

spent_timeЗатраченное время на задачу, в минутахInt320
comment_as_role_idID роли, от имени которой комментарийInt320
is_step_changedЭтап изменился в данном событииBoolFalse
previous_stepПредыдущий этапInt16-1
seconds_in_stepСколько в секундах находились на прошлом этапеInt640
is_step_frozenЗаморожен ли SLA на прошлом этапеBoolFalse
is_step_overdueЗавершился ли прошлый этап после установленного для него срокаBool
is_status_changedСтатус изменился в данном событииBoolFalse
previous_statusПредыдущий статусInt16-1
is_status_frozenЗаморожен ли SLA на прошлом статусеBoolFalse
is_status_overdueИзменился ли прошлый статус после установленного для него срокаBoolFalse
is_responsible_changedОтветственный изменился в данном событииBoolFalse
previous_responsible_idПредыдущий ответственныйInt32-1

Не поддерживаются следующие поля формы в движке визуализации:

  • пользовательские поля: Текст, Телефон, Эл. почта;
  • оформительские поля: Таблица, Примечание.

Система псевдонимов и параметров

Псевдонимы и параметры — это специальные маркеры, которые позволяют связать статический SQL-запрос с динамическим контекстом Pyrus.

Псевдонимы (SELECT AS)

Псевдонимы используются только как алиасы (AS) в секции SELECT. Они преобразуют числовые данные в текст или ссылки.

Подсказка: если вы не используете псевдоним в алиасе, в колонке будет отображаться исходное числовое значение (ID, код статуса и т.д.).

Описание псевдонимаПсевдонимПрименение
ID пользователя → ФИО#person_full_name('Заголовок')responsible_id AS "#person_full_name('Ответственный')"
ID пользователя → Наименование подразделения#person_department('Заголовок')responsible_id AS "#person_department('Подразделение')"
ID статуса → Название статуса#status_name('Заголовок')status AS "#status_name('Статус')"
ID этапа → Название этапа#step_name('Заголовок')step AS "#step_name('Этап')"
ID поля типа выбор → Значение поля типа выбор#choice_name(${Код поля}) #choice_name(${Код поля}, 'Заголовок')${Канал} AS "#choice_name(${Канал},'Канал обращения')"
ID задачи → Название задачи#task('Заголовок')task_id AS "#task('Задача')"

Параметры (встраиваемые в SQL)

Параметры динамически влияют на то, что и как запрашивается из базы данных.

Описание псевдонимаПсевдонимПрименение
Выбор источника данных#tasks / #eventsFROM #tasks (для текущего состояния); FROM #events (для истории)
Начало/конец выбранного периода дат.@period_start / @period_endWHERE create_date >= @period_start
Выражение, соответствующее фильтрам, которые пользователь выбрал в интерфейсе сводки для запроса по текущему состоянию задачи#task_filtersWHERE #task_filters — применяет фильтры, выбранные пользователем в интерфейсе сводки.
Аналогично макросу #task_filters, но применяется в HAVING при запросах к историческим данным #events#event_filtersHAVING #event_filters — применяет фильтры, специфичные для работы с таблицей #events
Используется в ORDER BY для корректной сортировки статусов по их порядку в настройках формы#ordered_statusesORDER BY #ordered_statuses — обеспечивает корректную сортировку статусов в выводе согласно их порядку в настройках формы.

Ограничения

  • Все SQL-запросы к данным выполняются в режиме чтения. Доступны только операции SELECT.
  • Максимальное число строк в таблице результатов — 1000.
  • Максимальное время обработки SQL-запроса — 10 сек.

Далее рекомендуем ознакомиться с Примерами виджетов

Была ли эта статья полезной?