Модели данных в BI-платформах: физика против логики

Сегодня поговорим о том, как устроены модели данных в BI-платформах. Рассмотрим два основных типа моделей данных, которые используются в BI: физическую и логическую.

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

Физическая модель

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

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

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

Оптимальное использование:

Физическая модель подходит для работы с простыми моделями, такими как звезда и снежинка или одна готовая денормализованная витрина.

Ограничения:

1. Работа со сложной структурой данных. Реализация сложной модели с несколькими фактовыми таблицами (например, созвездие) невозможна.

2. Гибкость. Изменение требований к дашборду требует пересмотра всей модели: от уровня детализации до разреза данных.

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

Логическая модель

Логическая модель данных — это более гибкий подход к организации данных в BI, при котором SQL-запросы генерируются динамически для каждой визуализации и задействуют только ту часть модели, которая содержит необходимые данные. Связи между таблицами описываются на уровне метаданных модели, но вместо объединения всех данных сразу в единый запрос, связи активируются только при использовании данных этой таблицы в визуализации. Таким образом, логическая модель добавляет новый уровень абстракции над данными.

Преимущества:

• Производительность.

  • Меньший объем обрабатываемых данных в запросе позволяет снизить нагрузку на КХД/внутренний движок платформы.

  • Ускорение работы слайсеров при работе со справочниками уникальных значений.

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

• Гибкость. Логическую модель можно легко адаптировать к изменениям в бизнес-требованиях. Новые поля или таблицы могут быть добавлены в модель без необходимости пересмотра всех существующих связей и таблиц, поскольку добавление новой таблицы не повлечет за собой дублирования данных или изменений в структуре итоговой таблицы.

Ограничения:

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

Компромиссное решение

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

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

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

Преимущества:

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

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

Ограничения:

• Не заменяет полноценные связи. Если требуется подтянуть информацию из другой таблицы или объединить данные из разных датасетов, глобальные фильтры      не помогут.

• Зависимость от нейминга полей. Для работы этой системы необходимо, чтобы поля в разных таблицах имели одинаковые названия, иначе авто-фильтрация не сработает.

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

Сравнение моделей

Применимость разных моделей

Физическая модель будет оптимальной для:

• Простых моделей данных.

• Малых и средних объёмов данных, где производительность не является критичной

• Отчетов, где данные уже были рассчитаны и подготовлены на стороне СУБД, и нужно просто построить дашборд на готовой витрине.

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

Пример 2: Ежемесячный отчет по продажам, в котором отображается сводка по выручке и количеству проданных единиц товара по каждому клиенту.

Компромиссное решение с фильтрами подойдёт для:

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

• Связанных логически данных, в случае если не нужно делать общие расчеты на основе нескольких датасетов

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

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

Логическая модель необходима для:

• Сложных моделей данных с несколькими фактами (например, созвездие).

• Больших объёмов информации, где важно контролировать производительность запросов.

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

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

Пример 2: В сети супермаркетов требуется аналитическая система для анализа Sell-Out и Sell-In, которые являются отдельными бизнес-процессами, но используют общие справочники, такие как «Товары», «Клиенты» и др.

Реализация моделей в BI-платформах

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

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

В то же время Power BI, который имеет одну из самых продвинутых логических моделей на рынке, помимо поддержки моделей данных любой сложности, включая созвездие, позволяет еще и «на лету» подменять используемое соединение между двумя таблицами. Так, например, в одной визуализации (меры) таблица1 и таблица2 будут связываться по id1, а для другой визуализации (меры) связь произойдет по id2.

Мировые лидеры среди BI-платформ, такие как Power BI, Tableau, QlikSense и другие, используют логическую модель данных. В большинстве российских и Open-Source платформах реализована дополненная глобальными фильтрами физическая модель, но также есть и платформы с логической моделью (например Дельта BI, Fine BI, PIX BI). Кроме того, есть платформы, реализующие логическую модель с помощью OLAP-кубов, например Форсайт, Alpha BI, Visiology v2.

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