Новая парадигма «унифицированной схемы звезды» в обзоре моделирования данных Google Analytics
Изобретена Ф. Пуппини и доработана Б. Инмоном, претендует на то, чтобы стать революцией в самообслуживании BI.
Введение
Недавно я случайно наткнулся на новую книгу Билла Инмона и Франческо Пуппини под названием «Унифицированная схема звезда» (она будет называться нисходящим потоком USS). Мое внимание в 2020 году привлекла эта новая книга от отца хранилищ данных, я купил ее и прочитал в течение следующих 3 дней с большим энтузиазмом. Оказалось, что автором концепции является Франческо Пуппини, а Билл Инмон является ее сторонником и пропагандистом, но это не умаляет ценности нового подхода к моделированию и организации данных.
Вначале я был настроен скептически. Замена традиционной размерной модели, проверенной десятилетиями, меня не устроила. Но книга открыла мне новый взгляд на модель данных. Теперь я считаю, что это можно рассматривать не как замену традиционного размерного моделирования (несмотря на то, что автор утверждает, что это так и есть), а как хорошее ее обогащение. Итак, давайте вкратце рассмотрим этот вопрос.
Обзор подхода USS
Сдвиг в философии отношений
Автор предлагает гениально простой подход к управлению связями (отношениями) между сущностями в базе данных аналитики: вместо сети взаимосвязей ввести суперкоммутатор и управлять всеми подключениями через него:
Изображение взято из книги USS. Ссылка ниже
Если мы переведем это утверждение в модель данных хранилища данных, это будет означать замену галактической схемы (набора схем «звезда», соединенных через согласованные измерения) одной суперзвездой, где все таблицы (как фактические, так и измерения) объединены через одну большую вспомогательную таблицу под названием «Bridge» (названа так автором) или «Puppini Bridge» (названа так Инмоном; она мне нравится больше, поэтому буду использовать ее :) как на картинке ниже:
Изображение автора
Puppini Bridge используется исключительно для соединения таблиц друг с другом, он не имеет коммерческой ценности и его рекомендуется скрывать от конечных клиентов.
Как строится мост Puppini Bridge
Как строится волшебная таблица? Это нетривиальная вещь, так что давайте рассмотрим ее в деталях.
Предварительное условие: каждая таблица в хранилище данных должна иметь первичный ключ, построенный на одном столбце. Рекомендуется соблюдать соглашение об именах: используйте префикс_KEY_, за которым следует имя таблицы.
Таблица Puppini Bridge представляет собой матричную таблицу, в которой:
- Столбцы – это список первичных ключей каждой таблицы хранилища данных (фактических или измерений) плюс один дополнительный столбец, называемый Stage . Таким образом, количество столбцов равно количеству таблиц в хранилище данных (измерения и фактические данные) плюс один.
- Строки – результат объединения операции union all для таблиц хранилища данных, содержащих только ключевые столбцы. Таким образом, количество строк в таблице Bridge – это сумма всех записей в хранилище данных (фактические данные и измерения).
Для заполнения таблицы Bridge нам потребуется разбить процесс на этапы, где каждый этап – это загрузка данных из одной из таблиц хранилища данных. Для каждой таблицы нам нужно установить значение столбца «Stage» равным имени таблицы хранилища данных и загрузить:
- Первичный ключ таблицы хранилища данных.
- Все внешние ключи к другой таблице хранилища данных; прямые внешние ключи и производные.
В приведенном выше примере начальные отношения между таблицами фактов и измерений приведут к следующему выполнению Puppini Bridge (темно-красные ячейки содержат производные внешние ключи):
Изображение автора
Имея такую промежуточную таблицу мостов, мы могли бы объединить любые две таблицы хранилища данных, используя соответствующие ключевые столбцы. Например, чтобы сгруппировать заказы и прогнозируемые суммы продаж по категориям продуктов и объединить результаты, нам потребуется выполнить левое соединение с таблицей Puppini Bridge следующим образом:
select pc.CategoryName,
sum(so.SalesAmount),
sum(sf.ForecastedAmount) from _PuppiniBridge pb
left join SalesOrders so
on pb._KEY_SalesOrders = so._KEY_SalesOrders
left join SalesForecast sf
on pb._KEY_SalesForecast = sf._KEY_SalesForecast
left join ProductCategory pc
on pc._KEY_ProductCategory = pc._KEY_ProductCategory
group by
pc.CategoryName
Основные преимущества USS
Вся книга «Unified Star Schema» посвящена преимуществам USS в самообслуживании BI. Под самостоятельной бизнес-аналитикой подразумевается возможность исследования и обнаружения данных на любой современной платформе бизнес-аналитики, такой как Tableau, Qlik View/Qlik Sense, Tibco SpotFire, MS PowerBI, аналитиками данных и представителями бизнеса.
Схема «галактика» всегда содержит петлевые соединения (если только она не является тривиальной), что приводит к двусмысленности. Вот почему платформа BI ограничивает возможности для соединений таблиц между собой, чтобы избежать зацикливания, и это приводит к ограничению возможностей исследования данных или необходимости поиска обходных путей на стороне модели данных.
Преобразование схемы «галактика» в USS, которая представляет собой простую схему «звезда», устраняет набор ограничений, накладываемых платформами BI.
Схема USS помогает решить следующие проблемы:
- Петли
- Ловушка «вентилятор»
- Ловушка «пропасть»
- Соединения с несогласованной степенью детализации
Подробное объяснение этих проблем вместе с подробными описаниями и примерами вы можете найти в книге.
Другие стороны USS
Помимо самостоятельной бизнес-аналитики, существуют и другие аспекты сценариев использования данных хранилища данных, поэтому давайте попробуем взглянуть на USS с другой точки зрения
Нефункциональные проблемы
Масштабируемость
Моя основная проблема, связанная с USS – это эффективность операций соединения и масштабируемость подхода в целом.
Поскольку таблица Puppini Bridge представляет собой надмножество всех таблиц хранилища данных, включая таблицы фактов, это будет большая таблица. Поэтому, в случае запроса хотя бы одной таблицы фактов у нас всегда будет соединение между двумя большими таблицами (мост с таблицей фактов), что всегда является проблемой для реляционной базы данных. Мы могли бы подумать об объединении слиянием для оптимизации результат, но, скорее всего, это будет невозможно, поскольку упорядочение для одной таблицы фактов не будет работать для другой таблицы фактов и т. д.
Аналогичная проблема связана с распределением данных для развертываний кластеров. Если мы распределим большую таблицу фактов в соответствии с определенным правилом, мы не сможем применить то же правило для таблицы Puppini Bridge. Даже если мы можем сделать это для одной таблицы фактов, мы не сможем сделать это для другой таблицы фактов. Таким образом, это приводит к той же проблеме эффективности объединения между _Puppini_Bridge и другой большой таблицей фактов в кластерах базы данных.
Расширение схемы
Расширение схемы всегда является довольно сложным аспектом решения для хранилища данных.
Когда мы вводим новую предметную область в хранилище данных или новый набор бизнес-процессов традиционным способом, мы вводим новый набор таблиц (новый набор схем-звезд).
В случае с USS помимо этого, нам нужно будет выполнить действительно сложные операции по подъему над таблицей Bridge:
- изменение, добавляя список новых столбцов с соответствующими ключевыми столбцами
- заполнение надлежащей информацией о подключении
Таким образом, в случае большого хранилища данных, соблюдение этого правила, как правило, очень сложная операция.
Функциональные проблемы
Если выйти за рамки самообслуживания BI и подумать о предопределенных отчетах или действиях пользователях, направленных на исследование данных, было бы более естественно, логично и проще присоединить таблицу фактов непосредственно к связанным таблицам измерений, используя внутреннее соединение, избегая левого (или правого)) присоединяется к таблице Bridge.
Даже если необходимо соединить между собой две таблицы фактов, опытный инженер по данным сделает это эффективнее, чем с помощью таблицы Bridge. В таком случае будет объединение двух больших таблиц вместо объединения трех больших таблиц.
Ниша USS
На мой взгляд, USS – действительно отличное решение для самообслуживания BI. После создания таблицы Puppini Bridge аналитики данных и бизнес-пользователи смогут выполнять свою работу на платформе BI, концентрируясь на аналитических данных, а не на проблемах подключения к данным, избегая при этом множества возможных ловушек.
В других областях использования данных это может казаться не столь полезным и увеличивает усилия по обслуживанию.
Бесплатный вариант
Подход USS с его Puppini Bridge, на мой взгляд, можно использовать в дополнение к традиционной размерной модели данных в качестве большого бонуса для Self Service BI.
Пока все таблицы фактов и измерений имеют первичный ключ на основе одного столбца, что на самом деле является одним из лучших методов многомерного моделирования, можно реализовать таблицу моста Puppini и использовать ее для SelfService BI.
Заключение
Я постарался кратко рассмотреть подход. USS – действительно новый, интересный и еще не проверенный отраслью способ построения аналитики. Сама идея очень интересна и действительно стоит того, чтобы ее оценить. Если вы создаете решение бизнес-аналитики для самообслуживания, оно определенно заслуживает того, чтобы его опробовали.
Идея получила благословение самого Билла Инмона, так что она должен оказаться жизнеспособной :)