Комментарии 2
Крутая статья! Анастасия,подскажите в статье упоминается, что в большинстве российских BI-платформ используется дополненная глобальными фильтрами физическая модель. Какие основные трудности возникают у вендоров при переходе к реализации логической модели данных?
Добрый день, хороший вопрос! При подготовке к статье я обратилась к одному из Российских вендоров, чтобы узнать из первых рук причины выбора именно физической модели. Вот такие аргументы привел вендор, ниже дополнила своими комментариями.
Мы можем обеспечить высокую скорость выборки данных.
Здесь речь идет о том, что если для каждой визуализации не нужно составлять свой отдельный запрос, отбирая только нужные таблицы, а оставлять 1 запрос со всеми джоинами, то это может ускорить формирование запроса к БД поскольку запрос не будет составлять дианмически. Тем не менее, запрос с избыточными джоинами будет отрабатывать дольше, чем запрос с меньшим количеством джоинов.
Логическую связь можно вынести на уровень визуализаций. В нашем случае на уровне дашборда можно связать между собой виджеты (визуализации), которые построены на разных физических моделях, если у них есть общие для связи поля. Это закрывает 80% потребностей.
Здесь говорится об использовании "компромиссной модели", когда мы можем передать фильтры из дашборда в две разные модели и синхронно фильтровать данные. Это действительно решает часть проблем физической модели, но все же не заменяет настоящих логических связей между моделями.
за счёт LOD выражений и ряда других агрегатов можно существенно снизить самый большой минус физической модели
LOD-выражения в BI-платформе обычно реализуются с помощью оконных функций или CTE. Это не устраняет изначальную проблему с задубливанием или с излишней дателизацией данных, но предлагает действенный, хоть и не оптимальный способ сделать расчет корректным. Однако нужно понимать, что не все ограничения физической модели можно обойти с помощью LOD-выражений.
потребность иногда замножать данные. Замножать данные приходится, если надо в одну физическую модель сложить данные с разной гранулярностью: например, ежедневные факты по продажам и ежемесячные планы по продажам.
При соединии двух фактовых таблиц, обе модели: и физическая и логическая будут вести себя одинаково, а именно - задублят данные. Поскольку принцип работы джоина двух таблиц не меняется от способа реализации модели и происходим типичным для любой РСУБД образом, то и результат джоина будет одинаковый. Другой вопрос, что если связь между фактовыми таблицами не нужна для визуализации/расчета, то логическая модель ее не создаст, в то время как физическая модель всегда использует все джоины и таблицы, которые в ней созданы.
Кроме того, вендор поделился сложностями реализации логической модели:
Такая модель сложнее в реализации в плане разработки, так как на круг надо больше логики предусмотреть:
— визуализации теперь опираются на измерения и агрегаты, которые могут храниться в разных моделях.
— некоторые функции необходимо адаптировать для работы по логическим связям
— необходимо пересмотреть логику взаимофильтрации визуализаций на дашборде
По итогу, реализация физической модели обходится вендору существенно дешевле с точки зрения разработки и при этом позволяет закрыть довольно большой пласт требований. Тем не менее, логическая модель - это, несомненно, другой уровень гибкости в работе с данными в BI-платформе. Многие вендоры понимают это и включают реализацию логической модели в роадмэп будущего развития своей платформы.
Модели данных в BI-платформах: физика против логики