Как стать автором
Обновить
0
Modus BI
Российский разработчик аналитических решений

Графический интерфейс workflow и составные наборы данных

Время на прочтение4 мин
Количество просмотров4K

Привет, Хабр! На связи Александр Чебанов, product owner аналитических решений компании Modus. Сегодня я расскажу об одном блоке в нашем облачном Modus BI Cloud — графическом интерфейсе для работы с составными наборами данных, о том, как он устроен и для чего нужен. Поехали!

Что такое графический редактор Workflow?

Для того, чтобы пользователям было проще проектировать свои наборы данных, мы приняли решение использовать графический редактор и не опираться на конфигурирование кода.

Графический интерфейс
Графический интерфейс

Со временем в Modus BI Cloud будет применяться как классический запрос с помощью кода из запросов SQL, так и составной набор данных. Составной набор данных содержит описание модели — пользователь может генерировать запрос к данным динамически, оперируя теми объектами, которые выбирает на дашборде.

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

Workflow в аналитическом портале предназначен для работы с таблицами на уровне их визуализации. Это значит, что мы не применяем сложные модели и пользуемся схемой «звезда».

Схема звезда — это когда одна большая таблица фактов объединяется крайними частями с таблицей справочников. И выбирая нужные поля из таблиц справочников, наш запрос автоматически строится для того, чтобы выбрать нужную сущность.

"Звезда" и "снежинка"

Есть несколько типов организации связи между таблицами:

  • Звезда — одна большая таблица фактов объединяется крайними частями с таблицей справочников, для чего используется только одна ссылка для каждой таблицы. Это более простая конструкция, которая значительно упрощает написание сложных запросов.

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

В перспективе мы планируем выполнять частичную материализацию. То есть данные у нас будут организованы в схему, а материализированы, то есть записаны на диск. Такая схема должна сокращать количество запросов и возвращаться либо к схеме звезды, либо использовать денормализированную таблицу.

Денормализированная витрина таблицы — это такая таблица, которая содержит в себе сразу все связи, которые можно построить, и работает с ними. Она хорошо подходит для ClickHouse, на котором организовано наше хранилище.

Мы планируем развивать оба механизма: «звезду» с использованием элементов dictionary и, когда dictionary не исправляются, денормализованные таблицы.

Базовый синтаксис объединения таблиц

Таблицы могут быть объединены между собой четырьмя способами:

  • left join — соединение всех записей таблицы слева и только тех записей таблицы справа, которые удовлетворяют условию

  • right join — соединение записей таблицы слева, который удовлетворяют условию, и всех записей таблицы справа

  • inner join — внутреннее соединение таблиц по методу пересечения, т. е. из двух таблиц выбираются только записи, удовлетворяющие условию

  • outer join — это внешнее соединение, означает то, что левая и правая таблица выбираются полностью, и совпадения соединяются. А там, где они не соединятся, соответственно, слева появятся пустые правые колонки, а справа появятся пустые левые колонки.

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

Когда пользователь выбирает поле из таблицы A и из таблицы B, то графический интерфейс, зная схему, строит соединение с учетом тех связей, которые указаны.

Если этот функционал реализовать с помощью кода, то он будет менее гибким и будет всегда отображать данные с заданными условиями. Например, нужно выбрать данные таблицы продаж и номенклатуры из таблицы складов и соединить их вместе. Если бы мы писали код запроса, то при выборе данных продаж всегда отображалась бы и справочная информация по складам, и справочная информация по товарам.

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

Параллельно мы развиваем шаблонизаторы запросов. В системах визуализации может использоваться не только чистый SQL, а SQL с некоторым кодом.

У нас для этого есть пользовательские переменные на SQL‑запросе: если выбрано какое‑то переменное условие, оно срабатывает, отрабатывает один текст запроса, а в итоговый запрос летит либо одна, либо вторая часть запроса. И таких же блоки есть в ApacheSuperset. Это синтаксис на Python и специальная библиотека, которая позволяет таким образом шаблонизировать запрос и работать.

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

Теги:
Хабы:
Всего голосов 5: ↑2 и ↓3+1
Комментарии4

Публикации

Информация

Сайт
modusbi.ru
Дата регистрации
Дата основания
Численность
51–100 человек
Местоположение
Россия

Истории