Да, все верно. BI-система становится прежде всего фронт-эндом. Описанное решение показывает подход, как минимизировать зависимость от функционала конкретной BI-платформы, и при этом не закопаться в изучении сложных новых инстурментов.
Что значит "переизобретать", если он уже изобретен? 25 лет истории продукта так-то. Ну и не забывайте, что статья написана в контексте импортозамещения. Для ситуации когда привычный ETL (для меня это скрипт Qlik Sense) не доступен.
Я действительно не знаком с линейкой продуктов PBI. Допустим, что для нелицензионного использования остается удобный способ шаринга отчетов. Но это не снимает вопросы архитектуры, масштабирования, хранения аналитических данных. И эти вопросы не решаются полноценно в PBI (в отличие от Qlik, например).
Сделав все правильно в специализированных инструментах, будет уже не так важно, визуализировать в PBI или где-то еще. А специализированные инструменты для построения архитектуры высокого качества и с низким порога входа доступны в библиотеке российского софта.
вопрос не только в продвинутости, но и в том какие инфраструктурные возможности он имеет. Десктопный PBI - это локальный инструмент аналитика прежде всего, не смотря на всю его продвинутость. Единую систему управления компанией на нем не выстроишь. Малый бизнес безусловно будет всеми правдами и неправдами на нем сидеть. Хостить его на выделенном сервере и подключаться по RDP, или что там еще люди придумывают)
Ну и продвинутость - это весьма условный критерий. В успешной масштабируемой аналитике самое главное - стандарты подготовки, хранения, и моделирования данных. Все эти вещи обеспечиваются с помощью Loginom - отличного продукта в своем классе, без скидок на импортозамещение. Где эти данные потом будут визуализированы - дело глубоко вторичное.
Взрослое использование PBI точно также начинается с внедрения хранилища. А раз есть хранилище - должны быть стандарты подготовки и хранения. Тут уже в режиме тяп-ляп-селф-сервиса не особо поработаешь. В этом плане PBI напоминает мне плагины для программ звукозаписи. Например всякие эмуляторы гитарных усилителей. Да, можно на любой комп установить, воткнуть гитару из дсп, и записать свое "дж-дж-дж". И оно даже будет нормально звучать. Пока не сравнишь свое "дж-дж-дж" с тем, которое было записано на студии). А студийное "дж-дж-дж" звучит так, потому что там и оборудование, и исполнитель, и инструмент, и персонал звукозаписи, и опыт. инфраструктура, короче.
В переводе на мир аналитики, PBI без инфраструктуры годится для быстрого несистемного селфсервиса, на уровне "сделать демку". Я ориентируюсь на проекты так сказать промышленного производства аналитики - где пользователей отчетов минимум десятки и сотни, есть несколько параллельно работающих аналитиков, которым нужно обеспечить переиспользование данных и синхронизировать их работу, чтобы их отчёты были совместимыми между собой. Чтобы добавление новых условий, о которых еще вчера не было известно, не приводило к необходимости переделывать то что создавалось предыдущие пол-года.
При таком подходе главное - инжиниринг и моделирование данных. И его можно делать вне PBI ничего не теряя. А даже приобретая. И визуализировать итоговые данные где хочется, а не замыкаться в рамках PBI, в котором набахали обработок Power Query, и закрутили навороченную реляционную модель, которую кроме PBI ни один инструмент не возьмет, в т.ч. Qlik и Tableau.
Это наш скрипт, который интегрируется с каталогом таблиц хранилища, и позволяет в режиме конструктора собрать любую модель данных в топологии Звезда. Сейчас реализован как компонент на Loginom.
Хмм, а разве полноценный PBI не завязан жестко на облако? Как его пиратить?) На самом деле, предлагаемая архитектура хороша тем, что BI-система в ней не является главным инструментом инжиниринга данных и моделей. А визуализирует максимально подготовленные данные. Это позволяет в т.ч. несколько BI-систем одновременно и они будут работать в одинаковой логике. Например, Visiology для регламентной отчетности и PBI для декстопных исследований у аналитика, который к нему привык.
Зависит от того, насколько проще его жизнь сделается со звездой. Реляционная схема хороша на простых моделях и аналитики в режиме "для себя" - быстро загрузил данные, быстро собрал в модель, быстро пересобрал.
Когда нужно делать промышленное решение, в котором важна не только первичная скорость сборки, но и целостность архитектуры при дальнейшем масштабировании, гибкость этого самого масштабирования, многопользовательская работа в режиме self-service - тогда автоматически генерируемая звезда позволяет экономить очень много высококвалифицированных ресурсов и снижать планку входа в бизнес-аналитику.
Все так) Звезда - это название модели. Просто мы написали функционал для ее автоматической генерации в любой SQLной СУБД, чтобы закрыть пробел между подготовкой данных в Loginom и визуализации в BI-системах.
В PBI технически можно обойтись без звезды, но на сложных моделях и при внедрении самообслуживания, а также аналитики в разных подразделениях поддерживать реляционную модель будет очень сложно. Можете в статье посмотреть на диаграмму прирастания ландшафта данных. Там всего 52 таблицы. Представьте каково работать с моделью когда "это" и есть ваша модель данных.
Структура модели "как в транзакционном источнике" для задач BI маловероятна, потому что BI аналитика как правило объединяет данные нескольких источников. И для обеспечения нужной логики визуализации данных как правило требуется организовывать таблицы иначе, чем они хранятся в источнике.
Column store кстати так или иначе во всех BI с in-memory движками используется, это не PBI эксклюзив.
Автоматизация построения звезды как раз позволяет не тратить на нее время и ресурсы, а сразу получить преимущества. Мы придерживаемся этой стратегии, потому что нам важно:
1) Иметь предсказуемый, готовый к добавлению новых источников ландшафт данных, без избыточного проектирования и рисков рефакторинга модели;
2) Снижать порог входа в разработку сложных моделей для не-экспертов, максимально отчуждать эти компетенции на сторону клиентов;
3) Обеспечить целостность аналитики при самостоятельной разработке отчетов бизнес-пользователями;
4) Снижать кадровые риски, когда аналитик нагородил реляционного осьминога в качестве модели и уволился;
5) Легко дорабатывать проекты, которые не трогали несколько месяцев;
6) Строить интерактивную документацию аналитического ландшафта в автоматическом режиме;
7) Не иметь привязку этих методик к какому то одному инструменту. Возможность анализа данных сразу несколькими инструментами с сохранением целостной картины. Простая миграция между инструментами.
Цитата Кимбола: "Мы использовали этот подход для построения аналитических хранилищ поверх строчных баз данных, чтобы [получить хоть какой-то вменяемый 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 году насколько я помню.
Витрина, аналитическая таблица - плоская таблица с данными, предобработанными для использования в инструментах BI. На основе нескольких витрин собирается модель данных, которая используется BI-инструментом для визуализации взаимосвязей данных в витринах. Для визуализации данных такой таблицы не требуется сложных функций на стороне BI-инструмента.
Например, у нас есть транзакционная таблица с продажами - данные в ней простые, показатели рассчитываются простыми агрегациями типа sum(). Это ваша первая витрина. Вам ставят задачу - выводить менеджерам по продажам рекомендации, какому клиенту что можно допродать дополнительно, на основе их истории покупок. Ваш BI-инструмент не имеет встроенных функций для таких вычислений. Поэтому вы используете инструмент, который может выполнить соответствующие расчеты (например, Loginom, или Python, в общем что вам ближе). На выходе получаете плоскую таблицу рекомендаций, сохраняете ее в аналитическую БД, с которой работает BI - вот уже у вас 2 витрины. Нужен прогноз продаж? Аналогично, в специализированном инструменте формируем новую плоскую таблицу, скармливаем все 3 витрины в BI - и вот у нас уже всесторонний анализ продаж.
1) Структура данных любой сложности реализуется за фиксированное количество стандартных шагов. В теме бизнес-аналитики это важно, потому что структура данных может поменяться внезапно и непредсказуемо. Добавится новый источник, или сгенерятся данные на основе имеющихся, потому что бизнес попросил. Кроме того, внутри бизнеса может использоваться несколько моделей данных - например для продаж, маркетинга и финансов. И хотя в этих моделях не анализируются сразу все доступные данные, полезно иметь возможность в любой момент добавить к модели любые другие данные без нарушения целостности аналитического ландшафта.
2) У BI-систем с in-memory движками специфика работы основана на логике "простые запросы - большие выборки". В то время как у транзакционных систем, где тоже есть модель данных (реляционная) логика выдачи запросов из серии "сложные запросы - маленькие выборки". Т.е. транзакционка может вывести на экран результат визуализации, который по факту будет образован выполнением нескольких запросов, и еще полирнуть какой-нибудь логикой поверх. Но на ограниченной выборке - например только в карточке одного клиента. А BI система (я имею ввиду настоящую аналитическую систему для самообслуживания, а не набор визов с конструктором SQL-запросов и настройками на грани программирования) такие запросы на лету не выполняет - ей нужно подать максимально простую модель где все что нужно связано непосредственно с тем что нужно. И звезда тут отлично подходит.
Да, все верно. BI-система становится прежде всего фронт-эндом. Описанное решение показывает подход, как минимизировать зависимость от функционала конкретной BI-платформы, и при этом не закопаться в изучении сложных новых инстурментов.
Набирает обороты) А вообще его в т.ч. и в российских вузах изучают.
Что значит "переизобретать", если он уже изобретен? 25 лет истории продукта так-то. Ну и не забывайте, что статья написана в контексте импортозамещения. Для ситуации когда привычный ETL (для меня это скрипт Qlik Sense) не доступен.
Я действительно не знаком с линейкой продуктов PBI. Допустим, что для нелицензионного использования остается удобный способ шаринга отчетов. Но это не снимает вопросы архитектуры, масштабирования, хранения аналитических данных. И эти вопросы не решаются полноценно в PBI (в отличие от Qlik, например).
Сделав все правильно в специализированных инструментах, будет уже не так важно, визуализировать в PBI или где-то еще. А специализированные инструменты для построения архитектуры высокого качества и с низким порога входа доступны в библиотеке российского софта.
вопрос не только в продвинутости, но и в том какие инфраструктурные возможности он имеет. Десктопный PBI - это локальный инструмент аналитика прежде всего, не смотря на всю его продвинутость. Единую систему управления компанией на нем не выстроишь. Малый бизнес безусловно будет всеми правдами и неправдами на нем сидеть. Хостить его на выделенном сервере и подключаться по RDP, или что там еще люди придумывают)
Ну и продвинутость - это весьма условный критерий. В успешной масштабируемой аналитике самое главное - стандарты подготовки, хранения, и моделирования данных. Все эти вещи обеспечиваются с помощью Loginom - отличного продукта в своем классе, без скидок на импортозамещение. Где эти данные потом будут визуализированы - дело глубоко вторичное.
Взрослое использование PBI точно также начинается с внедрения хранилища. А раз есть хранилище - должны быть стандарты подготовки и хранения. Тут уже в режиме тяп-ляп-селф-сервиса не особо поработаешь. В этом плане PBI напоминает мне плагины для программ звукозаписи. Например всякие эмуляторы гитарных усилителей. Да, можно на любой комп установить, воткнуть гитару из дсп, и записать свое "дж-дж-дж". И оно даже будет нормально звучать. Пока не сравнишь свое "дж-дж-дж" с тем, которое было записано на студии). А студийное "дж-дж-дж" звучит так, потому что там и оборудование, и исполнитель, и инструмент, и персонал звукозаписи, и опыт. инфраструктура, короче.
В переводе на мир аналитики, PBI без инфраструктуры годится для быстрого несистемного селфсервиса, на уровне "сделать демку". Я ориентируюсь на проекты так сказать промышленного производства аналитики - где пользователей отчетов минимум десятки и сотни, есть несколько параллельно работающих аналитиков, которым нужно обеспечить переиспользование данных и синхронизировать их работу, чтобы их отчёты были совместимыми между собой. Чтобы добавление новых условий, о которых еще вчера не было известно, не приводило к необходимости переделывать то что создавалось предыдущие пол-года.
При таком подходе главное - инжиниринг и моделирование данных. И его можно делать вне PBI ничего не теряя. А даже приобретая. И визуализировать итоговые данные где хочется, а не замыкаться в рамках PBI, в котором набахали обработок Power Query, и закрутили навороченную реляционную модель, которую кроме PBI ни один инструмент не возьмет, в т.ч. Qlik и Tableau.
Это наш скрипт, который интегрируется с каталогом таблиц хранилища, и позволяет в режиме конструктора собрать любую модель данных в топологии Звезда. Сейчас реализован как компонент на Loginom.
Хмм, а разве полноценный PBI не завязан жестко на облако? Как его пиратить?) На самом деле, предлагаемая архитектура хороша тем, что BI-система в ней не является главным инструментом инжиниринга данных и моделей. А визуализирует максимально подготовленные данные. Это позволяет в т.ч. несколько BI-систем одновременно и они будут работать в одинаковой логике. Например, Visiology для регламентной отчетности и PBI для декстопных исследований у аналитика, который к нему привык.
Зависит от того, насколько проще его жизнь сделается со звездой. Реляционная схема хороша на простых моделях и аналитики в режиме "для себя" - быстро загрузил данные, быстро собрал в модель, быстро пересобрал.
Когда нужно делать промышленное решение, в котором важна не только первичная скорость сборки, но и целостность архитектуры при дальнейшем масштабировании, гибкость этого самого масштабирования, многопользовательская работа в режиме self-service - тогда автоматически генерируемая звезда позволяет экономить очень много высококвалифицированных ресурсов и снижать планку входа в бизнес-аналитику.
Все так) Звезда - это название модели. Просто мы написали функционал для ее автоматической генерации в любой SQLной СУБД, чтобы закрыть пробел между подготовкой данных в Loginom и визуализации в BI-системах.
В PBI технически можно обойтись без звезды, но на сложных моделях и при внедрении самообслуживания, а также аналитики в разных подразделениях поддерживать реляционную модель будет очень сложно. Можете в статье посмотреть на диаграмму прирастания ландшафта данных. Там всего 52 таблицы. Представьте каково работать с моделью когда "это" и есть ваша модель данных.
Структура модели "как в транзакционном источнике" для задач BI маловероятна, потому что BI аналитика как правило объединяет данные нескольких источников. И для обеспечения нужной логики визуализации данных как правило требуется организовывать таблицы иначе, чем они хранятся в источнике.
Column store кстати так или иначе во всех BI с in-memory движками используется, это не PBI эксклюзив.
Автоматизация построения звезды как раз позволяет не тратить на нее время и ресурсы, а сразу получить преимущества. Мы придерживаемся этой стратегии, потому что нам важно:
1) Иметь предсказуемый, готовый к добавлению новых источников ландшафт данных, без избыточного проектирования и рисков рефакторинга модели;
2) Снижать порог входа в разработку сложных моделей для не-экспертов, максимально отчуждать эти компетенции на сторону клиентов;
3) Обеспечить целостность аналитики при самостоятельной разработке отчетов бизнес-пользователями;
4) Снижать кадровые риски, когда аналитик нагородил реляционного осьминога в качестве модели и уволился;
5) Легко дорабатывать проекты, которые не трогали несколько месяцев;
6) Строить интерактивную документацию аналитического ландшафта в автоматическом режиме;
7) Не иметь привязку этих методик к какому то одному инструменту. Возможность анализа данных сразу несколькими инструментами с сохранением целостной картины. Простая миграция между инструментами.
Давайте обсудим :)
Цитата Кимбола: "Мы использовали этот подход для построения аналитических хранилищ поверх строчных баз данных, чтобы [получить хоть какой-то вменяемый 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 году насколько я помню.
Считаете, если основы методологии разработаны кем-то давно, не нужно заниматься их адаптацией под современные условия и инструменты?
Витрина, аналитическая таблица - плоская таблица с данными, предобработанными для использования в инструментах BI. На основе нескольких витрин собирается модель данных, которая используется BI-инструментом для визуализации взаимосвязей данных в витринах. Для визуализации данных такой таблицы не требуется сложных функций на стороне BI-инструмента.
Например, у нас есть транзакционная таблица с продажами - данные в ней простые, показатели рассчитываются простыми агрегациями типа sum(). Это ваша первая витрина. Вам ставят задачу - выводить менеджерам по продажам рекомендации, какому клиенту что можно допродать дополнительно, на основе их истории покупок. Ваш BI-инструмент не имеет встроенных функций для таких вычислений. Поэтому вы используете инструмент, который может выполнить соответствующие расчеты (например, Loginom, или Python, в общем что вам ближе). На выходе получаете плоскую таблицу рекомендаций, сохраняете ее в аналитическую БД, с которой работает BI - вот уже у вас 2 витрины. Нужен прогноз продаж? Аналогично, в специализированном инструменте формируем новую плоскую таблицу, скармливаем все 3 витрины в BI - и вот у нас уже всесторонний анализ продаж.
Звезда для BI систем хороша по двум причинам:
1) Структура данных любой сложности реализуется за фиксированное количество стандартных шагов. В теме бизнес-аналитики это важно, потому что структура данных может поменяться внезапно и непредсказуемо. Добавится новый источник, или сгенерятся данные на основе имеющихся, потому что бизнес попросил. Кроме того, внутри бизнеса может использоваться несколько моделей данных - например для продаж, маркетинга и финансов. И хотя в этих моделях не анализируются сразу все доступные данные, полезно иметь возможность в любой момент добавить к модели любые другие данные без нарушения целостности аналитического ландшафта.
2) У BI-систем с in-memory движками специфика работы основана на логике "простые запросы - большие выборки". В то время как у транзакционных систем, где тоже есть модель данных (реляционная) логика выдачи запросов из серии "сложные запросы - маленькие выборки". Т.е. транзакционка может вывести на экран результат визуализации, который по факту будет образован выполнением нескольких запросов, и еще полирнуть какой-нибудь логикой поверх. Но на ограниченной выборке - например только в карточке одного клиента. А BI система (я имею ввиду настоящую аналитическую систему для самообслуживания, а не набор визов с конструктором SQL-запросов и настройками на грани программирования) такие запросы на лету не выполняет - ей нужно подать максимально простую модель где все что нужно связано непосредственно с тем что нужно. И звезда тут отлично подходит.
Не так громко, товарищ! Не надо разрушать индустрию :)