В этой статье расскажем про новую адаптивную модель данных в Luxms BI. Мы реализовали подход, при котором модель сама понимает, какие таблицы и связи нужны под конкретный дэшборд, и строит оптимальный SQL-запрос. Это делает аналитику быстрее, а работу с данными — действительно self-service. В этой статье покажем, как это работает, чем отличается от старого подхода и какие преимущества дает аналитикам и бизнесу.

А в этой статье разобрали, как на практике построить такую модель на примере небольшого проекта.

А уже скоро мы опубликуем материал, в котором покажем наглядный пример работы с одними и теми же данными на нашей модели и в Qlik Sense.

Предыстория

В старых BI-сравнениях фанаты Qlik любили показывать интересный кейс: брали Excel-файл с таблицей фактов, справочниками и еще одной таблицей фактов. Все это загружалось в Qlik, и оттуда на дэшборд выводились столбцы из разных таблиц — например, фамилия сотрудника и остатки на складе.

На первый взгляд — странная выборка, непонятно, как эти данные связаны. Но… Qlik показывал логичный, понятный  результат. Хотя никто даже “не объяснял”, как эти таблицы связаны между собой.

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

Мы сделали то же самое. С динамическими связями. С реальными источниками. С умной генерацией запроса прямо под контекст визуализации. Без лишних JOIN’ов. И это не магия — это новая модель данных в Luxms BI.

Мы сделали то, чего не сделал никто в России

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

Мы пошли другим путем. Мы прислушались к опыту Qlik и реализовали эту идею в новой адаптивной модели данных Luxms BI. Причем, на текущий момент мы — единственные среди 100+ российских BI-систем, кто сделал такую динамическую модель запросов по-настоящему. Модель, которая понимает, какие данные действительно нужны, и строит запрос только по ним. Это меняет сам подход к аналитике.

Новая BI-модель

Адаптивная модель данных в Luxms BI — это визуально-логическая модель с генерацией запросов «на лету» с учетом связей между таблицами. Модель уже доступна в бета-версии, и наши пользователи уже могут создавать проекты с новой моделью.

Адаптивная модель данных поддерживает схемы «звезда» и «снежинка», обычные и иерархические справочники. Это покрывает более 90% всех BI-сценариев.

Давайте сравним как работали “старые кубы” и новая модель

Как работало раньше

Чтобы создать куб, нужно было выбрать таблицы-источники и перенести их на рабочее поле — «листик в клеточку». После этого автоматически генерировался SQL-запрос (SELECT), который при необходимости можно было подредактировать вручную: добавить JOIN’ы, добавить фильтры или полностью переписать запрос под свои задачи. После этого настраивались поля — указывались типы, ставились метки для UI. Затем куб сохранялся и был готов к работе.

Как происходила генерация SQL-запроса при помощи “старого” куба

У нас есть дэш, в котором выбран список столбцов, фильтры и сортировки. И есть SELECT-запрос, который мы настроили на предыдущем шаге. И этот SELECT выступает в качестве подзапроса. То есть куб был своего рода виртуальной таблицей, из которой уже брались данные для визуализации - фильтровались, агрегировались и сортировались.

Как работает новая адаптивная модель

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

Важно: все остальные таблицы должны быть напрямую или косвенно связаны с этой таблицей фактов — именно от нее модель начнет формировать запрос.

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

В левой верхней панели можно переключиться на физическое представление модели — там отображаются реальные названия столбцов из базы данных. Так же доступно JSON-представление всей модели.

В логическом представлении, наоборот, все ориентировано на self service пользователя — названия столбцов можно задать простым двойным кликом, на русском языке, в удобной форме (подробнее об этом напишу чуть ниже).

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

Как происходит генерация SQL-запроса в новой модели

У нас есть дэш, в котором мы выбираем накидываем столбцы из модели на оси. Модель сама анализирует, какие именно поля и таблицы задействованы, и на их основе формирует итоговый запрос. При этом в блок FROM попадают только те таблицы, которые реально участвуют в визуализации — ничего лишнего.

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

Умные джойны — только нужное

Допустим, в дэше используются только три таблицы: department, location и country. Все они связаны между собой, поэтому адаптивная модель включит в FROM только их.

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

Что меняется на практике

Если выбрать, например, отдел и менеджера отдела, результат в старом кубе и в новой модели совпадает. 

Но если выбрать только менеджеров, можно увидеть разницу:

Во-первых, в кубе появится пустая строка — это потому, что, скажем, у московского отдела менеджер не был назначен, и в SELECT попал NULL. Куб работает с виртуальной таблицей, в которой этот NULL уже был зафиксирован как значение.

Во-вторых, в адаптивной модели вместо строки с NULL будет строка  с уволенным менеджером, который не привязан ни к одному отделу. Новая модель формирует запрос напрямую к таблице, а не к подселекту, поэтому такие "висящие" данные не теряются. Это делает аналитику более гибкой и позволяет видеть всю картину.

Адаптивная модель адаптируется к данным

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

Адаптивная модель не фиксирует жестко связи, а формирует запросы динамически, включая только те таблицы, которые реально используются. Никаких лишних JOIN’ов – быстрее и эффективнее. Снижается нагрузка на источник, база работает меньше, результат приходит быстрее.

Модель не использует in-memory-движок — запросы идут напрямую в источник.

Все работает автоматически

Сейчас модель работает автоматизированно. Пользователю не нужно ничего настраивать, система сама понимает, какие таблицы нужны, и строит запрос.

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

Полная совместимость со «старыми» кубами

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

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

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

Если в новых проектах вы начнёте использовать адаптивную модель, старые проекты не нужно переделывать, конвертировать или донастраивать. В рамках одной инсталляции адаптивная модель и старые кубы могут использоваться совместно. Вплоть до того, что на одном дэшборде половина дэшей используют кубы, а другая половина дэшей - новые модели.

Удобство работы

Переименование полей прямо в интерфейсе

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

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

Для каждого столбца доступна служебная информация: можно посмотреть его происхождение и связи с другими элементами модели. Это экономит время при работе с большими схемами.

Привычный синтаксис

Мы обновили синтаксис выражений, теперь для обращения к полям используются [квадратные скобки], как в большинстве популярных BI-систем. Это сделано для удобства пользователей — не нужно переучиваться, все знакомо.

Модель редактируется и после сохранения

Адаптивную модель можно менять на “листике в клеточку” и до, и после того, как она сохранена.

Гибкие фильтры

Важная часть новой адаптивной модели – функционал гибких фильтров, аналог «зеленых фильтров» в Qlik Sense. Они уже работают в «коробке». Их можно вынести в верхнюю панель, включив соответствующую опцию в верхнем меню — это визуально подчеркивает контекст текущего анализа, позволяя пользователю всегда видеть выбранные значения. При выборе одних значений в фильтрах, другие становятся неактивными, чтобы избежать нелогичных выборок. Этот функционал будет развиваться, появится более сложная логика, зависимости, подсветка ассоциированных и исключенных значений.

Поддержка MDX-запросов

Мы уже реализовали поддержку MDX-запросов (можно об этом подробнее прочитать здесь), и это стало возможным как раз благодаря новой модели. Один и тот же механизм на основе LPE, позволяет строить и SQL, и MDX-запросы.

MDX (Multidimensional Expressions) — язык запросов для работы с многомерными данными.

В основе адаптивной модели лежит собственная технология LPE, которая отвечает за построение запросов и демонстрирует свою гибкость как в SQL-сценариях, так и при работе с многомерными источниками. И если интерфейс новой адаптивной модели пока работает только в бете, то «мозг» уже и на продакшене.

Мы полностью контролируем технологический стек

Алгоритмы построения запросов в источники - это сердце любого BI. Для разработки этой важнейшей подсистемы, мы не используем сторонние библиотеки, интерпретаторы и SDK. Всю логику написания запросов мы реализовали с помощью технологии LPE - это компактная, но мощная библиотека, дающая гибкость и действительно широкие возможности для построения интерпретаторов, DSL, преобразователей символьных выражений, калькуляторов и т.д..

Построение SQL и MDX запросов работает как вычисление ответа с помощью интерпретатора кода, примерно как интерпретация программ на BASIC. На входе у нас описание модели в JSON формате и запрос из дэша за данными, тоже в виде JSON. В запросе перечислены необходимые столбцы, формулы с использованием столбцов, фильтры и другая подобная информация. LPE - это универсальный программируемый интерпретатор S-выражений, с помощью которого мы загружаем описание модели в память и инициализируем “среду компиляции” запросов. Затем мы превращаем запрос из дэша в S-выражения (текст программы) и запускаем инициализированный интерпретатор, который интерпретирует программу и “вычисляет” результат. В нашем случае в результате вычислений получается готовый SQL или MDX запрос.

Благодаря LPE мы:

• поддерживаем работу с 8 разными СУБД и два разных диалекта: SQL и MDX

• быстро добавляем новый функционал

• не зависим от обновлений сторонних библиотек

Это полностью оригинальная, созданная нами технология. Мы точно знаем, как она устроена, и можем в любой момент внести изменения. Это позволяет нам быстро добавлять поддержку новых источников, оптимизировать поведение, экспериментировать, и просто не ждать, пока кто-то «там» обновит библиотеку или одобрит наши MR на github. Это дает нам технологическую свободу, которой нет у большинства BI-вендоров.

Что дает новая модель: для бизнеса, для пользователей, для системы

Настоящая self-service модель

Новая визуально-логическая модель — это не просто обновление интерфейса. Это полноценный self-service подход к проектированию витрин и моделей. То, что раньше требовало участия разработчика или BI-специалиста, теперь может сделать аналитик — быстро, понятно и без кода. Пользователь:

• Сам настраивает модель - соединяет таблицы, создает схему «звезда» или «снежинка», просто мышкой

• Переименовывает поля прямо в интерфейсе, на русском языке, с контролем уникальности – тоже просто мышкой и клавиатурой

• Не пишет SQL — система сама формирует корректные запросы

Это меняет подход к работе, это экономит время, это снижает нагрузку на команду и напрямую влияет и на скорость принятия решений и на эффективность.

Гибкие фильтры

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

Быстрее, умнее, эффективнее

Даже при том, что Luxms BI и раньше показывал действительно очень высокую скорость, новая модель делает работу с запросами еще эффективнее. В условиях, когда объемы данных растут, источников становится все больше, а аналитика усложняется, снижение нагрузки на базу и точечные запросы без лишних JOIN’ов — это не просто приятно, а действительно важно.

Итог: меньше вычислений, быстрее результат, устойчивость при росте объёма данных

Что дальше?

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

Также появится возможность использовать старые кубы в качестве источников данных внутри новой модели - можно будет перетащить куб на “листик в клеточку” и он станет частью новой модели.

И еще одна фича, над которой работаем - возможность загружать сразу несколько Excel-файлов прямо в модель и соединять их между собой так же, как любые другие таблицы. Это будет особенно удобно в сценариях, где справочники хранятся в Excel, а данные в СУБД и их нужно быстро собрать и проанализировать.

Подытожим

Новая визуально-логическая модель в Luxms BI — это:

• Визуальное проектирование модели данных

• Поддержка схем «звезда» и «снежинка»

• Умная динамическая генерация запросов

• Никаких лишних JOIN'ов - только то, что нужно для визуализации

• Настоящий Self service при подготовке данных

• Совместимость с функционалом кубов из прошлых версий Luxms BI

• Независимость от стороннего ПО в ключевых компонентах Luxms BI

• Быстрый и гибкий движок построения запросов на базе собственной технологии LPE

Все это уже работает. А дальше будет работать еще лучше.

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