Очень часто, когда анализируются большие данные, где много уникальных значений и уникальных событий, где речь идет, например, о посещениях какого-то сервиса, о конверсиях, о курьерских поездках, заказах, покупках, встает всегда вопрос о времени:

• Как обстоят дела со временем доставки? 
• Со временем посещения той или иной веб-страницы? 

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

Сейчас поработаем с временем, обратившись к SQL-редактору. Воспользуемся визуализацией Speedometer.

Выберем в качестве куба Academy и нажмем на кнопку «Редактировать куб».

Добавим новое поле в SQL-редактор, в куб, в котором изначальных данных нет. Нажмем на кнопку «Выполнить запрос».

Когда осуществляется работа с загруженными файлами в Luxms BI, по умолчанию используем диалект СУБД PostgreSQL. В случае, если бы работали с какой-нибудь другой СУБД, то есть с ClickHouse, Greenplum, с Microsoft-сервером, использовался бы диалект этих СУБД.

Создадим новое поле - столбцы типа timestamp, которые позволяют понять, когда заказ был создан и когда заказ был доставлен. Интересно узнать, каково среднее время доставки. 

Итак, создадим новое поле после created_at.

Используем заранее скопированную формулу, чтобы долго ее не писать, но подробно объясним, что она означает и для чего нужна, предварительно заменим только префикс.

Чтобы корректно работать с датой и временем, следует с помощью специальной функции PostgreSQL сначала выявить разницу между датами доставки и датами создания заказа, преобразовать ее в нужный формат, а затем разделить на 60, чтобы получились минуты. 

Итак, необходимо вычесть из времени, в которое заказ был доставлен, столбец с временем, когда заказ был создан.

Выполним SQL-запрос и увидим дельту, время доставки каждого заказа.

Здесь везде 30, потому что это один и тот же заказ. Если посмотреть на большее количество строк, то будет видно, что это значение будет у разных заказов разное. 25, 35 и так далее.

У кого-то нет вообще, потому что заказа не было как такового. С этим сейчас будем работать.

Чтобы данный столбец существовал не только в кубе, но и можно было с ним работать в BI, его нужно создать в том числе и в контексте BI-системы. Копируем новое поле Delta. Переходим на вкладку столбцы. Нажимаем на плюс, создаем новый столбец.

Присваиваем ему тип данных «число», потому что это количество минут, больше это не время и не интервал, это число. Для удобства можно присвоить ему агрегационную функцию чтобы она всплывала в подсказках.

Добавляем и сохраняем. Закрываем SQL редактор.

Теперь при клике на поле факт видим поле дельта в агрегационных функциях в фактах.

Выберем его и применим к нему агрегационную функцию среднее.

Теперь настроим диапазон в рамках которого будет отрисовываться зона - это нужно для корректного отображения цветовой разбивки. Минимум - 25, а максимум - 60.

Теперь настроим условное форматирование. Переходим в цветовые зоны, добавляем зону: пускай менее 35 - будет хорошее время, между 35 и 45 минут будет приемлемое время отметим его желтым, и больше 45 минут - будет неприемлемое время доставки.

Озаглавим этот дэш как среднее время доставки в минутах. Зададим ему фон верхней панели, такой, который был ранее.