Комментарии 18
Shiny + R - и никакой головной боли
Пробую делать звезду на таблю. За плечами опыт работы на когнос и самоделка на матлаб.
За 11 лет опыта давно пришел к выводу, что альтернатива звезде это самоделка, но. НО веб дашборд лучше, чем десктопная аппликация, следовательно звезда + готовый ВI продукт со временем выиграют.
Звезда для BI систем хороша по двум причинам:
1) Структура данных любой сложности реализуется за фиксированное количество стандартных шагов. В теме бизнес-аналитики это важно, потому что структура данных может поменяться внезапно и непредсказуемо. Добавится новый источник, или сгенерятся данные на основе имеющихся, потому что бизнес попросил. Кроме того, внутри бизнеса может использоваться несколько моделей данных - например для продаж, маркетинга и финансов. И хотя в этих моделях не анализируются сразу все доступные данные, полезно иметь возможность в любой момент добавить к модели любые другие данные без нарушения целостности аналитического ландшафта.
2) У BI-систем с in-memory движками специфика работы основана на логике "простые запросы - большие выборки". В то время как у транзакционных систем, где тоже есть модель данных (реляционная) логика выдачи запросов из серии "сложные запросы - маленькие выборки". Т.е. транзакционка может вывести на экран результат визуализации, который по факту будет образован выполнением нескольких запросов, и еще полирнуть какой-нибудь логикой поверх. Но на ограниченной выборке - например только в карточке одного клиента. А BI система (я имею ввиду настоящую аналитическую систему для самообслуживания, а не набор визов с конструктором SQL-запросов и настройками на грани программирования) такие запросы на лету не выполняет - ей нужно подать максимально простую модель где все что нужно связано непосредственно с тем что нужно. И звезда тут отлично подходит.
Я не знаком с русскоязычной терминологией , используемой вашим инструментом. Поясните, что значит витрина, пожалуйста.
Datamart, скорее всего, имелся в виду.
Основная единица для DWH, ориентированного на аналитиков, а не data-architect
Витрина, аналитическая таблица - плоская таблица с данными, предобработанными для использования в инструментах BI. На основе нескольких витрин собирается модель данных, которая используется BI-инструментом для визуализации взаимосвязей данных в витринах. Для визуализации данных такой таблицы не требуется сложных функций на стороне BI-инструмента.
Например, у нас есть транзакционная таблица с продажами - данные в ней простые, показатели рассчитываются простыми агрегациями типа sum(). Это ваша первая витрина. Вам ставят задачу - выводить менеджерам по продажам рекомендации, какому клиенту что можно допродать дополнительно, на основе их истории покупок. Ваш BI-инструмент не имеет встроенных функций для таких вычислений. Поэтому вы используете инструмент, который может выполнить соответствующие расчеты (например, Loginom, или Python, в общем что вам ближе). На выходе получаете плоскую таблицу рекомендаций, сохраняете ее в аналитическую БД, с которой работает BI - вот уже у вас 2 витрины. Нужен прогноз продаж? Аналогично, в специализированном инструменте формируем новую плоскую таблицу, скармливаем все 3 витрины в BI - и вот у нас уже всесторонний анализ продаж.
Некто Кимбалл (может слыхали?) писал об этом:
Куда более развернуто
Без привязки к местечковым реалиям
Лет 30 назад
Прошу прощения за возможный негатив моего комментария, но у меня с Вами идеологические разногласия.
Ральф Кимбал (один из отцов dimensional modeling, частью которого является схема "звезда"): "Мы использовали этот подход для построения аналитических хранилищ поверх строчных баз данных, чтобы [получить хоть какой-то вменяемый performance, не сожрав все вычислительные ресурсы] уменьшить количество джойнов и соединять различные метрики через conformed dimensions. Этот продукт удобно потреблять [если data modeler и ETL developer, которые это всё поддерживают и расширяют - это не вы :)], но с развитием in-memory и колоночных хранилищ используемые методы поменяются"
Microsoft (середина 2000-х): "Dimensional modeling - это, конечно, хорошо, но неинтуитивно и дорого поддерживать. Давайте купим создателей движка Vertipaq, который станет основой для наших columnstore индексов (для быстрых online запросов в режиме DirectQuery) и Tabular Data Model (которая в том числе обитает внутри Power BI)".
ClickHouse: "Колоночное хранение, компрессия, векторные вычисления и бесплатность продукта решают большинство проблем, для решения которых придумывали dimensional modeling"
Представитель Visiology: "Для работы с BI сегодня как никогда актуальна такая модель данных как “Звезда”. Мы создали концепцию перехода на “Звезду” для любых проектов, даже если изначально в них не подразумевалось использование такой модели данных"
не кажется ли Вам, что вы переоцениваете актуальность dimensional modeling в современной дата аналитике? я не отрицаю, что у нее остаются свои области применения, но такие броские фразы как "как никогда актуальна" и "для любых проектов", несколько смущают
и несколько вопросов по некоторым пунктам из статьи, которые я не совсем понял:
1. про фактовую таблицу (где вы описываете варианты звезды, вариант 2, собственно базовый, содержит ключи измерений и значения фактов) Вы пишете "Такая модель имеет меньше гибкости в сценариях связи (нельзя реализовать один ко многим, многие ко многим), потому что реализация этих сценариев подразумевает размножение строк в центральной таблице.". Насколько я помню, для построения "многие-ко-многим" использовались bridge tables, которые никак не влияют на количество фактов.
2. "По мере углубления практик BI использование такой модели данных как “Звезда” становится обязательным, если вы хотите сохранить гибкость." Гибкость в чем, в разработке? В статье "Visiology 3.0: реальная замена Microsoft Power BI или наш дерзкий маркетинговый ход?" от 6 июня Ваш коллега(?) пишет:
- "Как хорошо знают аналитики, львиная доля времени, уходящего на манипуляции с BI-платформой, приходится на настройку ETL и подготовку витрин. За счет DAX мы стремимся делать сложные расчеты на сырых данных практически в реальном времени."
- " Мы стремились создать простую и легко понятную модель данных. Ведь обычно очень много времени тратится на создание модели данных, ее доработку…а также на передачу другим аналитикам[...] В 3.0 можно будет загружать нормализованные таблицы и предусматривать между ними разные связи — не обязательно приводить к звезде."
Все эти слова для меня более созвучны с понятием "гибкость", чем dimensional modeling.
3. У вас на последней картинке в списке хранилищ данных есть ClickHouse. Вы и поверх него предлагаете навешивать звезду или это просто показывает, что у Вашего продукта к нему коннектор есть?
Давайте обсудим :)
Цитата Кимбола: "Мы использовали этот подход для построения аналитических хранилищ поверх строчных баз данных, чтобы [получить хоть какой-то вменяемый performance, не сожрав все вычислительные ресурсы] уменьшить количество джойнов и соединять различные метрики через conformed dimensions".
Возможно, в его времена мотив производительности был ключевым. Но этот подход также обеспечивает очень хорошие возможности управления структурами данных на пользовательском слое - когда к построению моделей можно допустить не только технарей, но и бизнес-пользователей.
Кроме того, технические особенности BI-платформ тоже вносят лепту в сохранение актуальности звезды. Возьмем например Qlik. Его in-memory движок использует ассоциативную модель. В связях между таблицами нет понятия направлений и типов связей (один ко многим/один к одному и т.д.). Этот подход дает ряд преимуществ на простых структурах при сборе модели данных. Но также несет и серьезное ограничение - если между таблицами будут циклические связи (таблица 1 ссылается на таблицу 2 по ключу 1, таблица 2 ссылается на таблицу 3 по ключу 2, таблица 3 ссылается на таблицу 1 по ключу 3), то такая структура просто не будет работать. Единственный способ поддерживать целостную модели в Qlik, готовую к любой логике связей данных - использовать звезду. Благо у Qlik есть собственный функционал дата-моделинга, и ему не требуется хранилища - формирование звезды можно делать на лету. Или вот еще жизненный кейсик из Qlik. Допустим у вас есть 2 таблицы - факт продаж и план продаж. В каждой таблице есть поле с датой - дата продажи и дата плана соответственно. Вы не сможете визуализировать эти данные на одной временной оси, пока не сделаете в модели одно сквозное поле с датами (canonical date), что эквивалентно созданию таблицы связей.
Возьмем Visiology v2. Там нет собственных инструментов создания модели в широком смысле этого слова. Можно загрузить готовые таблицы из источников, разметить между готовыми таблицами связи. Но как универсальная модель с прозрачной логикой связей это будет работать только в топологии звезда, причем только во втором варианте звезды (когда в центр помещены в т.ч. и меры).
Также на российском ландшафте полно инструментов, которые не поддерживают даже звезду - для них нужна просто плоская таблица со всеми данными, т.е. звезда со сджойненными справочниками. Что теперь, выкинуть их все за борт ? :)
Насчет Visiology 3.0 и PBI - там подразумевается реляционная модель, с направлениями связей и типами связей. Звезда действительно не является единственно возможной топологией. Но :) Вот вам пример такой модели из PBI. И это только одна система - amoCRM. http://powerbirussia.ru/wp-content/uploads/2018/08/014-1-1024x759.png. Представьте как интересно будет ее замерджить с еще несколькими источниками типа 1С, сохранив целостность всех связей. Да, схема звезды сама по себе не показывает логику связей - просто все таблицы втыкаются в одну центральную. Но т.к. наше решение генерирует запрос построения звезды, оно вдобавок выдает справочный массив данных, который можно визуализировать и построить реальную схему связей данных, что очень удобно для аудита и документации.
Насчет DAX (в Qlik - Set Analysis + Aggr), который позволяет выполнять сложные вычисления в реальном времени :) Если мы говорим о промышленной архитектуре аналитики, то все неизбежно сводится к максимальной подготовке данных на стороне ETL, чтобы на стороне визуального слоя применять максимально простые агрегации вроде sum, count, min, max и т.д. Если использовать вычисления на фронте со сложными формулами ради того, чтобы "срезать углы" на построении модели данных и ETL-подготовке - вы получаете немасштабируемые решения, которые будут тормозить уже на сотнях тысячах строк данных.
Применение DAX и реляционных моделей в таком контексте может звучать неплохо для селф-сервис аналитики, когда данные вывалили на одного аналитика и ему надо быстро что-то собрать на коленке, не задумываясь об архитектуре. Но когда речь идет о том, чтобы аналитику разрабатывали сразу несколько подразделений, чтобы она была согласована между собой, чтобы не рефакторить каждый месяц своего реляционного осьминога - добро пожаловать в звезду. Да, звезду тоже с кандачка не напишешь и поддерживать ее руками сложно. Но благодаря ее стандартности, весь этот процесс можно автоматизаровать, о чем я и рассказал в статье. Мы на авто-звездах больше 4-х лет. Нет ни одного проекта где модель данных создавалась бы руками. Только раньше это было на Qlik. А теперь эту методику можно применить для любого BI. Но нужно хранилище :).
Насчет клик-хауса. Мы не навешиваем звезду поверх хранилища. Мы создаем звезды внутри хранилища. Просто в базе появляется еще одна таблица, которая вместе с таблицами данных загружается в BI.
P.S. Коллеги, кто знаком с темой по Кимболу и его книгам тридцатилетней давности. Можете освежить тему, изучив более свежие материалы Билла Инмона и Франческо Пуппини - Unified Star Schema. Книга вышла в 21 году насколько я помню.
из того, что вы описали, правильно я понимаю, что можно перефразировать Ваше "почему вам обязательно нужна звезда" в "почему вам обязательно нужна звезда, если вы работаете с Qlik, который по-другому не умеет"? просто есть Power BI, который умеет по-другому, за счет того, что имеет внутри себя движок от Tabular SSAS со всеми фичами columnstore хранилищ, что позволяет иметь примерно один и тот же вид модели, как на реляционном "транзакционном" источнике, так и в аналитической модели, вместо того, чтобы тратить ресурсы на разработку и поддержку второй модели специально для аналитики.
В PBI технически можно обойтись без звезды, но на сложных моделях и при внедрении самообслуживания, а также аналитики в разных подразделениях поддерживать реляционную модель будет очень сложно. Можете в статье посмотреть на диаграмму прирастания ландшафта данных. Там всего 52 таблицы. Представьте каково работать с моделью когда "это" и есть ваша модель данных.
Структура модели "как в транзакционном источнике" для задач BI маловероятна, потому что BI аналитика как правило объединяет данные нескольких источников. И для обеспечения нужной логики визуализации данных как правило требуется организовывать таблицы иначе, чем они хранятся в источнике.
Column store кстати так или иначе во всех BI с in-memory движками используется, это не PBI эксклюзив.
Автоматизация построения звезды как раз позволяет не тратить на нее время и ресурсы, а сразу получить преимущества. Мы придерживаемся этой стратегии, потому что нам важно:
1) Иметь предсказуемый, готовый к добавлению новых источников ландшафт данных, без избыточного проектирования и рисков рефакторинга модели;
2) Снижать порог входа в разработку сложных моделей для не-экспертов, максимально отчуждать эти компетенции на сторону клиентов;
3) Обеспечить целостность аналитики при самостоятельной разработке отчетов бизнес-пользователями;
4) Снижать кадровые риски, когда аналитик нагородил реляционного осьминога в качестве модели и уволился;
5) Легко дорабатывать проекты, которые не трогали несколько месяцев;
6) Строить интерактивную документацию аналитического ландшафта в автоматическом режиме;
7) Не иметь привязку этих методик к какому то одному инструменту. Возможность анализа данных сразу несколькими инструментами с сохранением целостной картины. Простая миграция между инструментами.
Все в кучу. Название продукта "Звезда" схема данных "звезда".
Та модель данных, что вы описали - называется "снежинка". Она позволяет создавать дополнительные измерения, которые хранят связанные сущности в отдельной таблице и занимают в таблице фактов всего одно поле. А также можно хранить версии мастер-данных с различными временнозависимыми иерархиями. Это позволяет получать в отчете те данные и разрезы, которые были на момент сохранения записи в таблице фактов. Это может делать нормальная DWH платформа.
Но и "звезда" и "снежинка" перестали быть the state of art после появления in-memory решений, где произошел обратный переход к плоской таблице, которая содержит все факты. Это решение за счет сжатия не потребляет много памяти и также эффективно с точки зрения производительности..
Пока вижу попытку спозиционировать новую платформу и показать какая она хорошая. Но объективности ради, рынок BI очень стабилен и на нем несколько лет нет ничего особенно нового и интересного. Удачи вам, это не простой путь.
Интересно, а насколько сложно уговорить работать со "звездой" аналитика, который уже привык и залип в PowerBI?
Зависит от того, насколько проще его жизнь сделается со звездой. Реляционная схема хороша на простых моделях и аналитики в режиме "для себя" - быстро загрузил данные, быстро собрал в модель, быстро пересобрал.
Когда нужно делать промышленное решение, в котором важна не только первичная скорость сборки, но и целостность архитектуры при дальнейшем масштабировании, гибкость этого самого масштабирования, многопользовательская работа в режиме self-service - тогда автоматически генерируемая звезда позволяет экономить очень много высококвалифицированных ресурсов и снижать планку входа в бизнес-аналитику.
«Звезда» — оптимальная структура данных при переходе на российский BI