Dwh olap что это
Введение в многомерный анализ
Некоторое время назад мне довелось организовывать новую группу разработки, которая должна была заняться развитием OLAP и BI продуктов в дружеской софтверной компании. А так как группа была собрана из свежих выпускников ВУЗов, то мне пришлось написать «краткий курс молодого бойца» для того чтобы максимально доступно дать начальные понятия об OLAP людям, которые ни разу с ним не сталкивались, но уже имели опыт программирования и работы с БД.
Выкладываю теперь это Введение в Общественное Достояние.
В статье несколько смешиваются понятия OLAP, Business Intelligence, и Data Warehouse, но и в жизни часто сложно понять, где проходит граница. А уж в реальных проектах, так и подавно, все они ходят рядом. Поэтому прошу не судить строго.
Введение
Информационные системы серьезного предприятия, как правило, содержат приложения, предназначенные для комплексного анализа данных, их динамики, тенденций и т.п. Соответственно, основными потребителями результатов анализа становится топ-менеджмент. Такой анализ, в конечном итоге, призван содействовать принятию решений. А чтобы принять любое управленческое решение необходимо обладать необходимой для этого информацией, обычно количественной. Для этого необходимо эти данные собрать из всех информационных систем предприятия, привести к общему формату и уже потом анализировать. Для этого создают хранилища данных (Data Warehouses).
Что такое хранилище данных?
Обычно — место сбора всей информации, представляющей аналитическую ценность. Требования для таких хранилищ соответствуют классическому определению OLAP, будут объяснены ниже.
Иногда Хранилище имеет еще одну цель – интеграция всех данных предприятия, для поддержания целостности и актуальности информации в рамках всех информационных систем. Т.о. хранилище накапливает не только аналитическую, а почти всю информацию, и может ее выдавать в виде справочников обратно остальным системам. Это так называемый УОД — Управление основными данными, оно же НСИ — Нормативно-Справочная Информация.
Типичное хранилище данных, как правило, отличается от обычной реляционной базы данных. Во-первых, обычные базы данных предназначены для того, чтобы помочь пользователям выполнять повседневную работу, тогда как хранилища данных предназначены для принятия решений. Например, продажа товара и выписка счета производятся с использованием базы данных, предназначенной для обработки транзакций, а анализ динамики продаж за несколько лет, позволяющий спланировать работу с поставщиками, — с помощью хранилища данных.
Во-вторых, обычные базы данных подвержены постоянным изменениям в процессе работы пользователей, а хранилище данных относительно стабильно: данные в нем обычно обновляются согласно расписанию (например, еженедельно, ежедневно или ежечасно — в зависимости от потребностей). В идеале процесс пополнения представляет собой просто добавление новых данных за определенный период времени без изменения прежней информации, уже находящейся в хранилище.
И, в-третьих, обычные базы данных чаще всего являются источником данных, попадающих в хранилище. Кроме того, хранилище может пополняться за счет внешних источников, например статистических отчетов.
Как строят хранилище?
ETL – базовое понятие: Extraction, Transformation, Loading. Три этапа:
Добавим еще один этап – очистка данных (Cleaning) – процесс отсеивания несущественных или исправления ошибочных данных на основании статистических или экспертных методов. Чтобы не формировать потом отчеты типа «Продажи за 20011 год».
Вернемся к анализу.
Что такое анализ и для чего он нужен?
Анализ – исследование данных с целью принятия решений. Аналитические системы так и называют — системы поддержки принятия решений (СППР).
Здесь стоит указать на отличие работы с СППР от простого набора регламентированных и нерегламентированных отчетов. Анализ в СППР практически всегда интерактивен и итеративен. Т.е. аналитик копается в данных, составляя и корректируя аналитические запросы, и получает отчеты, структура которых заранее может быть неизвестна. Более подробно к этому мы вернемся ниже, когда будем обсуждать язык запросов MDX.
Системы поддержки принятия решений обычно обладают средствами предоставления пользователю агрегатных данных для различных выборок из исходного набора в удобном для восприятия и анализа виде (таблицы, диаграммы и т.п.). Традиционный подход сегментирования исходных данных использует выделение из исходных данных одного или нескольких многомерных наборов данных (нередко называемый гиперкубом или метакубом), оси которых содержат атрибуты, а ячейки – агрегируемые количественные данные. (Причем храниться такие данные могут и в реляционных таблицах, но в данном случае мы говорим о логической организации данных, а не о физической реализации их хранения.) Вдоль каждой оси атрибуты могут быть организованы в виде иерархий, представляющих различные уровни их детализации. Благодаря такой модели данных пользователи могут формулировать сложные запросы, генерировать отчеты, получать подмножества данных.
Технология комплексного многомерного анализа данных получила название OLAP (On-Line Analytical Processing). OLAP — это ключевой компонент организации традиционных хранилищ данных. Концепция OLAP была описана в 1993 году Эдгаром Коддом, известным исследователем баз данных и автором реляционной модели данных. В 1995 году на основе требований, изложенных Коддом, был сформулирован так называемый тест FASMI (Fast Analysis of Shared Multidimensional Information — быстрый анализ разделяемой многомерной информации), включающий следующие требования к приложениям для многомерного анализа:
Следует отметить, что OLAP-функциональность может быть реализована различными способами, начиная с простейших средств анализа данных в офисных приложениях и заканчивая распределенными аналитическими системами, основанными на серверных продуктах. Т.е. OLAP — это не технология, а идеология.
Прежде чем говорить о различных реализациях OLAP, давайте подробнее рассмотрим, что же представляют собой кубы с логической точки зрения.
Многомерные понятия
Мы будем использовать для иллюстрации принципов OLAP базу данных Northwind, входящую в комплекты поставки Microsoft SQL Server и представляющую собой типичную базу данных, хранящую сведения о торговых операциях компании, занимающейся оптовыми поставками продовольствия. К таким данным относятся сведения о поставщиках, клиентах, список поставляемых товаров и их категорий, данные о заказах и заказанных товарах, список сотрудников компании.
Возьмем для примера таблицу Invoices1, которая содержит заказы фирмы. Поля в данной таблице будут следующие:
Какие агрегатные данные мы можем получить на основе этого представления? Обычно это ответы на вопросы типа:
Все эти данные можно получить из этой таблицы вполне очевидными SQL-запросами с группировкой.
Результатом этого запроса всегда будет столбец чисел и список атрибутов его описывающих (например, страна) – это одномерный набор данных или, говоря математическим языком, – вектор.
Представим себе, что нам надо получить информацию по суммарной стоимости заказов из всех стран и их распределение по компаниям доставщиков – мы получим уже таблицу (матрицу) из чисел, где в заголовках колонок будут перечислены доставщики, в заголовках строк – страны, а в ячейках будет сумма заказов. Это – двумерный массив данных. Такой набор данных называется сводной таблицей (pivot table) или кросс-таблицей.
Если же нам захочется получить те же данные, но еще в разрезе годов, тогда появится еще одно изменение, т.е. набор данных станет трехмерным (условным тензором 3-го порядка или 3-х мерным «кубом»).
Очевидно, что максимальное количество измерений – это количество всех атрибутов (Дата, Страна, Заказчик и т.д.), описывающих наши агрегируемые данные (сумму заказов, количество товаров и т.п).
Так мы приходим к понятию многомерности и его воплощению – многомерному кубу. Такая таблица будет у нас называться «таблицей фактов». Измерения или Оси куба (dimensions) – это атрибуты, координаты которых – выражаются индивидуальными значениями этих атрибутов, присутствующих в таблице фактов. Т.е. например, если информация о заказах велась в системе с 2003 по 2010 год, то эта ось годов будет состоять из 8 соответствующих точек. Если заказы приходят из трех стран, то ось стран будет содержать 3 точки и т.д. Независимо от того, сколько стран заложено в справочнике Стран. Точки на оси называются ее «членами» (Members).
Сами агрегируемые данные в данном случае буду назваться «мерами» (Measure). Чтобы избежать путаницы с «измерениями», последние предпочтительней называть «осями». Набор мер образует еще одну ось «Меры» (Measures). В ней столько членов (точек), сколько мер (агрегируемых столбцов) в таблице фактов.
Члены измерений или осей могут быть объединены одной или несколькими иерархиями (hierarchy). Что такое иерархия, поясним на примере: города из заказов могут быть объединены в районы, районы в области, области страны, страны в континенты или другие образования. Т.е. налицо иерархическая структура – континент-страна-область-район-город – 5 уровней (Level). Для района данные агрегируются по всем городам, которые в него входят. Для области по всем районам, которые содержат все города и т.п. Зачем нужно несколько иерархий? Например, по оси с датой заказа мы можем хотеть группировать точки (т.е. дни) по иерархии Год-Месяц-День или по Год-Неделя-День: в обоих случаях по три уровня. Очевидно, что Неделя и Месяц по-разному группируют дни. Бывают также иерархии, количество уровней в которых не детерминировано и зависит от данных. Например, папки на компьютерном диске.
Агрегация данных может происходить с использованием нескольких стандартных функций: сумма, минимум, максимум, среднее, количество.
Перейдем к языку запросов в многомерных данных.
Язык SQL изначально был спроектирован не для программистов, а для аналитиков (и поэтому имеет синтаксис, напоминающий естественный язык). Но он со временем все больше усложнялся и теперь мало кто из аналитиков хорошо умеет им пользоваться, если умеет вообще. Он стал инструментом программистов. Язык запросов MDX, разработанный по слухам нашим бывшим соотечественником Мойшей (или Мошей) Посуманским (Mosha Pasumansky) в дебрях корпорации Майкрософт, тоже изначально должен был ориентирован на аналитиков, но его концепции и синтаксис (который отдаленно напоминает SQL, причем совершенно зря, т.к. это только путает), еще сложнее чем SQL. Тем не менее его основы все же понять несложно.
Мы рассмотрим его подробно потому что это единственный язык, который получил статус стандартного в рамках общего стандарта протокола XMLA, а во вторых потому что существует его open-source реализация в виде проекта Mondrian от компании Pentaho. Другие системы OLAP-анализа (например, Oracle OLAP Option) обычно используют свои расширения синтаксиса языка SQL, впрочем, декларируют поддержку и MDX.
Работа с аналитическими массивами данных подразумевает только их чтение и не подразумевает запись. Т.о. в языке MDX нет предложений для изменения данных, а есть только одно предложение выборки — select.
В OLAP из многомерных кубов можно делать срезы – т.е. когда данные фильтруются по одной или нескольким осям, или проекции – когда по одному или нескольким осям куб «схлопывается», агрегируя данные. Например, наш первый пример с суммой заказов из стран – есть проекция куба на ось Страны. MDX запрос для этого случая будет выглядеть следующим образом:
Select – ключевое слово и в синтаксис входит исключительно для красоты.
[Territory] – это название оси. Все имена собственные в MDX пишутся в квадратных скобках.
[Cities by Countries] – это название иерархии. В нашем случае – это иерархия Страна-Город
[All] – это название члена оси на первом уровне иерархии (т.е. страны) All – это мета-член, объединяющий все члены оси. Такой мета-член есть в каждой оси. Например в оси годов есть «Все года» и т.п.
Children – это функция члена. У каждого члена есть несколько доступных функций. Таких как Parent. Level, Hierarchy, возвращающие соответственно предка, уровень в иерархии и саму иерархию, к которой относится в данном случае член. Children – возвращает набор членов-потомков данного члена. Т.е. в нашем случае – страны.
on rows – Указывает как расположить эти данные в итоговой таблице. В данном случае – в заголовке строк. Возможные значении здесь: on columns, on pages, on paragraphs и т.п. Возможно так же указание просто по индексам, начиная с 0.
from [invoices1] – это указание куба, из которого производится выборка.
Что если нам не нужны все страны, а нужно только пара конкретных? Для этого можно в запросе указать явно те страны которые нам нужны, а не выбирать все функцией Children.
Фигурные скобки в данном случае – обявление набора (Set). Набор – это список, перечисление членов из одной оси.
Теперь напишем запрос для нашего второго примера – вывод в разрезе доставщика:
.Members – функция оси, которая возвращает все члены на ней. Такая же функция есть и у иерархии и у уровня. Т.к. в данной оси иерархия одна, то ее указание можно опустить, т.к. уровень и иерархии тоже один, то можно выводить все члены одним списком.
Думаю, уже очевидно, как можно продолжить это на наш третий пример с детализацией по годам. Но давайте лучше не детализировать по годам, а фильтровать – т.е. строить срез. Для этого напишем следующий запрос:
А где же тут фильтрация?
where – ключевое слово
[2007] – это один член иерархии [Date]. Полное имя с учетом всех терминов было бы таким: [Date.By months].[All dates].[2007], но т.к. имя этого члена в рамках оси уникально, то все промежуточные уточнения имени можно опустить.
Почему член даты в скобках? Круглые скобки – это кортеж (tuple). Кортеж – это один или несколько координат по различным осям. Например для фильтрации сразу по двум осям в круглых скобках мы перечислим два члена из разных измерений через запятую. Т. е. кортеж определяет «срез» куба (или «фильтрацию», если такая терминология ближе).
Кортеж используется не только для фильтрации. Кортежи могут быть и в заголовках строк/колонок/страниц и т.п.
Это нужно, например, для того чтобы вывести в двумерную таблицу результат трехмерного запроса.
Crossjoin – это функция. Она возвращает набор (set) кортежей (да, набор может содержать кортежи!), полученный в результате декартового произведения двух наборов. Т.е. результирующий набор будет содержать все возможные сочетания Стран и Годов. Заголовки строк, таким образом, будут содержать пару значений: Страна-Год.
Вопрос, а где же указание какие числовые характеристики надо выводить? В данном случае используется мера по умолчанию, заданная для этого куба, т.е. Сумма заказа. Если мы хотим выводить другую меру, то мы вспоминаем, что меры – это члены измерения Measures. И действуем точно так же как и с остальными осями. Т.е. фильтрации запроса по одной из мер будет выводить именно эту меру в ячейках.
Вопрос: чем отличается фильтрация в where от фильтрации путем указания членов осей в on rows. Ответ: практически ничем. Просто в where указывается срез для тех осей, которые не участвуют в формировании заголовков. Т.е. одна и та же ось не может одновременно присутствовать и в on rows, и в where.
Вычисляемые члены
Для более сложных запросов можно объявлять вычисляемые члены. Члены как осей атрибутов, так и оси мер. Т.е. Можно объявить, например, новую меру, которая будет отображать вклад каждой страны в общую сумму заказов:
Вычисление происходит в контексте ячейки, у которой известные все ее атрибуты-координаты. Соответствующие координаты (члены) могут быть получены функцией CurrentMember у каждой из осей куба. Здесь надо понимать, что выражение [Territory].CurrentMember / [Territory].[Cities by Countries].[All]’ не делит один член на другой, а делит соответствующие агрегированный данные срезов куба! Т.е. срез по текущей территории разделится на срез по всем территориям, т.е. суммарное значение всех заказов. FORMAT_STRING – задает формат вывода значений, т.е. %.
Другой пример вычисляемого члена, но уже по оси годов:
Очевидно, что в отчете будет не единица, а разность соответствующих срезов, т.е. разность суммы заказов в эти два года.
Отображение в ROLAP
Системы OLAP так или иначе базируются на какой-нибудь системе хранения и организации данных. Когда речь идет о РСУБД, то говорят о ROLAP (MOLAP и HOLAP оставим для самостоятельного изучения). ROLAP – OLAP на реляционной БД, т.е. описанная в виде обычных двумерных таблиц. Системы ROLAP преобразуют MDX запросы в SQL. Основная вычислительная проблема для БД – быстрая агрегация. Чтобы быстрее агрегировать, данные в БД как правило сильно денормализованы, т.е. хранятся не очень эффективно с точки зрения занимаемого места на диске и контроля целостности БД. Плюс дополнительно содержат вспомогательные таблицы, хранящие частично агрегированные данные. Поэтому для OLAP обычно создается отдельная схема БД, которая лишь частично повторяет структуру исходных транзакционных БД в части справочников.
Навигация
Многие системы OLAP предлагают инструментарий интерактивной навигации по уже сформированному запросу (и соответственно выбранным данным). При этом используется так называемое «сверление» или «бурение» (drill). Более адекватным переводом на русский было бы слово «углубление». Но это дело вкуса., в некоторых средах закрепилось слово «дриллинг».
Drill – это детализация отчета с помощью уменьшения степени агрегации данных, совмещенное с фильтрацией по какой-нибудь другой оси (или нескольким осям). Сверление бывает нескольких видов:
На этом все. Теперь, если вы решили посвятить себя Business Intelligence и OLAP самое время приступать к чтению серьезной литературы.
Обзор гибких методологий проектирования DWH
Разработка хранилища — дело долгое и серьезное.
Многое в жизни проекта зависит от того, насколько хорошо продумана объектная модель и структура базы на старте.
Общепринятым подходом были и остаются различные варианты сочетания схемы “звезда” с третьей нормальной формой. Как правило, по принципу: исходные данные — 3NF, витрины — звезда. Этот подход, проверенный временем и подкрепленный большим количеством исследований — первое (а иногда и единственное), что приходит в голову опытному DWH-шнику при мысли о том, как должно выглядеть аналитическое хранилище.
С другой стороны — бизнесу в целом и требованиям заказчика в частности свойственно быстро меняться, а данным — расти как “вглубь”, так и “вширь”. И вот тут проявляется основной недостаток звезды — ограниченная гибкость.
И если в вашей тихой и уютной жизни DWH-разработчика внезапно:
Что значит «гибкость»
Для начала давайте определимся, какими свойствами должна обладать система, чтобы ее можно было назвать “гибкой”.
Отдельно стоит оговориться, что описываемые свойства должны относиться именно к системе, а не к процессу ее разработки. Поэтому если вы хотели почитать про Agile как методологию разработки, лучше ознакомиться с другими статьями. Например, тут же, на Хабре, есть масса интересных материалов (как обзорных и практических, так и проблемных).
Это не значит, что процесс разработки и структура ХД совсем никак не связаны. В целом разрабатывать по Agile хранилище гибкой архитектуры должно быть существенно легче. Однако на практике чаще встречаются варианты и с разработкой по Agile классического DWH по Кимбаллу и DataVault — по вотэрфолу, чем счастливые совпадения гибкости в двух ее ипостасях на одном проекте.
И так, какими же возможностями должно обладать гибкое хранилище? Тут можно выделить три пункта:
Ниже я рассмотрю две самых популярных для ХД методологии гибкого проектирования — Anchor model и Data Vault. За скобками остаются такие прекрасные приемы, как например EAV, 6NF(в чистом виде) и всё, относящееся к NoSQL решениям — не потому, что они чем-то хуже, и даже не потому, что в этом случае статья грозила бы приобрести объем среднестатистического дисера. Просто всё это относится к решениям несколько другого класса — либо к приемам, которые вы можете применять в специфических случаях, независимо от общей архитектуры вашего проекта (как EAV), либо к глобально другим парадигмам хранения информации (как, например, графовые БД и другие варианты NoSQL).
Проблемы “классического” подхода и их решения в гибких методологиях
1. Жесткая кардинальность связей
В основу такой модели закладывается четкое разделение данных на измерения (Dimension) и факты (Fact). И это, черт побери, логично — ведь анализ данных в подавляющем большинстве случаев сводится именно к анализу определенных численных показателей (фактов) в определенных разрезах (измерениях).
При этом связи между объектами закладываются в виде связей между таблицами по внешнему ключу. Это выглядит вполне естественно, но сразу же приводит к первому ограничению гибкости — жесткому определению кардинальности связей.
Это значит, что на этапе проектирования таблиц вы должны точно определить для каждой пары связанных объектов могут ли они относиться как многие-ко-многим, или только 1-ко-многим, и “в какую сторону”. От этого напрямую зависит в какой из таблиц будет первичный ключ а в какой — внешний. Изменение этого отношения при получении новых требований с большой вероятностью приведет к переработке базы.
Например, проектируя объект “кассовый чек” вы, опираясь на клятвенные заверения отдела продаж, заложили возможность действия одной промо-акции на несколько чековых позиций (но не наоборот):
А через некоторое время, коллеги ввели новую маркетинговую стратегию, в которой на одну и ту же позицию могут действовать несколько промо-акций одновременно. И теперь вам надо доработать таблицы, выделив связь в отдельный объект.
(Все производные объекты, в которых происходит джойн чека на промо, теперь тоже нуждаются в доработке).
Связи в Data Vault и Anchor Model
Избежать такой ситуации оказалось довольно просто: не надо верить отделу продаж для этого достаточно все связи изначально хранить в отдельных таблицах и обрабатывать как многие-ко-многим.
Такой подход был предложен Дэном Линстедтом (Dan Linstedt) как часть парадигмы Data Vault и полностью поддержан Ларсом Рённбэком (Lars Rönnbäck) в Якорной Модели (Anchor Model).
В итоге получаем первую отличительную особенность гибких методологий:
Связи между объектами не хранятся в атрибутах родительских сущностей, а представляют собой отдельный тип объектов.
В Data Vault такие таблицы-связки называются Link, а в Якорной Модели — Tie. На первый взгляд они очень похожи, хотя названием их различия не исчерпываются (о чем пойдет разговор ниже). В обеих архитектурах таблицы-связки могут связывать любое количество сущностей (не обязательно 2).
Эта на первый взгляд избыточность дает существенную гибкость при доработках. Такая структура становится толерантной не только к изменению кардинальностей существующих связей, но и к добавлению новых — если теперь у чековой позиции появится ещё и ссылка на пробившего ее кассира, появление такой связки станет просто надстройкой над существующими таблицами без влияния на какие-либо существующие объекты и процессы.
2. Дублирование данных
Вторая проблема, решаемая гибкими архитектурами, менее очевидна и свойственна в первую очередь измерениям типа SCD2 (медленно меняющиеся измерения второго типа), хотя и не только им.
В классическом хранилище измерение обычно представляет собой таблицу, которая содержит суррогатный ключ (в качестве PK) а также набор бизнес-ключей и атрибутов в отдельных колонках.
Если измерение поддерживает версионность, к стандартному набору полей добавляются границы времени действия версии, а на одну строку в источнике появляется несколько версий в хранилище (по одной на каждое изменение версионных атрибутов).
Если измерение содержит хотя бы один часто изменяющийся версионный атрибут, количество версий такого измерения будет внушительным (даже если остальные атрибуты не версионные, или никогда не изменяются), а если таких атрибутов несколько — количество версий может расти в геометрической прогрессии от их количества. Такое измерение может занимать существенный объем дискового пространства, хотя большая часть хранящихся в нем данных — просто дубли значений неизменных атрибутов из других строк.
При этом очень часто применяется ещё и денормализация — часть атрибутов намеренно хранятся в виде значения, а не ссылки на справочник или другое измерение. Такой подход ускоряет доступ к данным, снижая количество джойнов при обращении к измерению.
Как правило, это приводит к тому, что одна и та же информация хранится одновременно в нескольких местах. Например, информация о регионе проживания и принадлежности категории клиента может одновременно храниться в измерениях “Клиент”, и фактах “Покупка”, “Доставка” и “Обращения в колл-центр”, а также в таблице-связке “Клиент — Клиентский менеджер”.
В целом описанное выше относятся и к обычным (не версионным) измерениям, но в версионных могут иметь иной масштаб: появление новой версии объекта (особенно задним числом), приводит не просто к обновлению всех связанных таблиц, а к каскадному появлению новых версий связанных объектов — когда Таблица 1 используется при построении Таблицы 2, а Таблица 2 — при построении Таблицы 3 и т.д. Даже если ни один атрибут Таблицы 1 не участвует в построении Таблицы 3 (а участвуют другие атрибуты Таблицы 2, полученные из иных источников), версионное обновление этой конструкции как минимум приведет к дополнительным накладным расходам, а как максимум — к лишним версиям в Таблице 3, которая тут вообще “не при чем” и далее по цепочке.
3. Нелинейная сложность доработки
При этом каждая новая витрина, строящаяся на основании другой, увеличивает количество мест, в которых данные могут “разойтись” при внесении изменений в ETL. Это, в свою очередь, приводит к возрастанию сложности (и длительности) каждой следующей доработки.
Если вышеописанное касается систем с редко дорабатываемыми ETL-процессами, жить в такой парадигме можно — достаточно просто следить за тем, чтобы новые доработки корректно вносились во все связанные объекты. Если же доработки происходят часто, вероятность случайно “упустить” несколько связей существенно возрастает.
Если вдобавок учесть, что “версионный” ETL существенно сложнее, чем “не версионный”, избежать ошибок при частой доработке всего этого хозяйства становится достаточно сложно.
Хранение объектов и атрибутов в Data Vault и Anchor Model
Необходимо отделить то, что изменяется, от того, что остается неизменным. То есть хранить ключи отдельно от атрибутов.
При этом не стоит путать не версионный атрибут с неизменным: первый не хранит историю своего изменения, но может меняться (например, при исправлении ошибки ввода или получении новых данных) второй — не меняется никогда.
Точки зрения на то, что именно можно считать неизменным в Data Vault и Якорной модели расходятся.
С точки зрения архитектуры Data Vault, неизменным можно считать весь набор ключей — натуральные (ИНН организации, код товара в системе-источнике и т.п) и суррогатные. При этом остальные атрибуты можно разделить по группам по источнику и/или частоте изменений и для каждой группы вести отдельную таблицу с независимым набором версий.
В парадигме же Anchor Model неизменным считается только суррогатный ключ сущности. Всё остальное (включая натуральные ключи) — просто частный случай его атрибутов. При этом все атрибуты по умолчанию независимы друг от друга, поэтому для каждого атрибута должна быть создана отдельная таблица.
В Data Vault таблицы, содержащие ключи сущностей, называются Хабами (Hub). Хабы всегда содержат фиксированный набор полей:
Все остальные атрибуты сущностей хранятся в специальных таблицах, называемых Сателлитами (Satellit). Один хаб может иметь несколько сателлитов, хранящих разные наборы атрибутов.
Распределение атрибутов по сателлитам происходит по принципу совместного изменения — в одном сателлите могут храниться не версионные атрибуты (например, дата рождения и СНИЛС для физ.лица), в другом — редко изменяющиеся версионные (например, фамилия и номер паспорта), в третьем — часто изменяющиеся (например, адрес доставки, категория, дата последнего заказа и.т.п). Версионность при этом ведется на уровне отдельных сателлитов, а не сущности в целом, поэтому распределение атрибутов целесообразно проводить так, чтобы пересечение версий внутри одного сателлита было минимальным (что сокращает общее количество хранимых версий).
Также, для оптимизации процесса загрузки данных, в отдельные сателлиты часто выносятся атрибуты, получаемые из различных источников.
Сателлиты связываются с Хабом по внешнему ключу (что соответствует кардинальности 1-ко-многим). Это значит, что множественные значение атрибутов (например, несколько контактных номеров телефона у одного клиента) поддерживается такой архитектурой “по умолчанию”.
В Якорной модели (Anchor Model) таблицы, хранящие ключи, называются Якорями (Anchor). И хранят они:
Например, если данные об одной и той же сущности могут поступать из разных систем, в каждой из которых используется свой натуральный ключ. В Data Vault это может приводить к достаточно громоздким конструкциям из нескольких хабов (по одному на источник + объединяющая мастер-версия), в Якорной модели же натуральный ключ каждого источника попадает в свой атрибут и может использоваться при загрузке независимо от всех остальных.
Но тут кроется и один коварный момент: если в одной сущности объединяются атрибуты из различных систем, скорее всего существуют некоторые правила “склейки”, по которым система должна понимать, что записи из разных источников соответствуют одному экземпляру сущности.
В Data Vault эти правила скорее всего будут определять формирование “суррогатного хаба” мастер-сущности и никак не влиять на Хабы, хранящие натуральные ключи источников и их исходные атрибуты. Если в какой-то момент правила склейки поменяются (или придет обновление атрибутов, по которым она производится), достаточно будет переформировать суррогатные хабы.
В Якорной модели же такая сущность скорее всего будет храниться в единственном якоре. Это значит, что все атрибуты, независимо от того, из какого источника они получены, будут привязаны к одному и тому же суррогату. Разделить ошибочно слитые записи и в целом отслеживать актуальность склейки в такой системе может оказаться существенно труднее, особенно, если правила достаточно сложные и часто изменяются, а один и тот же атрибут может быть получен из разных источников (хотя точно возможно, т.к. каждая версия атрибута сохраняет ссылку на свой источник).
В любом случае, если в вашей системе предполагается реализация функционала дедубликации, слияния записей и других элементов MDM, стоит особенно внимательно ознакомиться с аспектами хранения натуральных ключей в гибких методологиях. Вероятно, более громоздкая конструкция Data Vault внезапно окажется более безопасной с точки зрения ошибок слияния.
Якорная модель также предусматривает дополнительный тип объекта, называемый Узлом (Knot) по сути это специальный вырожденный вид якоря, который может содержать всего один атрибут. Узлы предполагается использовать для хранения плоских справочников (например пол, семейное положение, категория обслуживания клиентов и т.п). В отличии от Якоря, Узел не имеет связанных таблиц атрибутов, а его единственный атрибут (название) всегда хранится в одной таблице с ключем. Узлы связываются с Якорями таблицами-связями (Tie) также, как якоря друг с другом.
Однозначного мнения по поводу использования Узлов нет. Например, Николай Голов, активно продвигающий применение Якорной модели в России, считает (не безосновательно), что ни для одного справочника нельзя точно утверждать, что он всегда будет статическим и одноуровневым, поэтому для всех объектов лучше сразу использовать полноценный Якорь.
Еще одно важное различие Data Vault и Якорной модели состоит в наличии атрибутов у связей:
В Data Vault Связи являются таким же полноценными объектами, как и Хабы, и могут иметь собственные атрибуты. В Якорной модели Связи используются только для соединения Якорей и собственных атрибутов иметь не могут. Это различие дает существенно разные подходы к моделированию фактов, о чем пойдет речь далее.
Хранение фактов
До этого мы говорили в основном про моделирование измерений. С фактами дело обстоит чуть менее однозначно.
Такой подход выглядит интуитивно понятным. Он дает простой доступ к анализируемым показателям и в целом похож на традиционную таблицу фактов (только показатели хранятся не в самой таблице, а в “соседней”). Но есть и подводные камни: одна из типовых доработок модели — расширение ключа факта — вызывает необходимость добавления в Link нового внешнего ключа. А это в свою очередь “ломает” модульность и потенциально вызывает необходимость доработок других объектов.
В Якорной модели Связь не может иметь собственных атрибутов, поэтому такой подход не прокатит — абсолютно все атрибуты и показатели обязаны иметь привязку к одному конкретному якорю. Вывод из этого простой — для каждого факта тоже нужен свой якорь. Для части того, что мы привыкли воспринимать как факты, это может выглядеть естественно — например, факт покупки прекрасно сводится к объекту “заказ” или “чек”, посещение сайта — к сессии и т.п. Но встречаются и факты, для которых найти такой естественный “объект-носитель” не так просто — например, остатки товаров на складах на начало каждого дня.
Соответственно, проблем с модульностью при расширении ключа факта в Якорной модели не возникает (достаточно просто добавить новую Связь к соответствующему Якорю), но проектирование модели для отображения фактов менее однозначно, могут появляться “искусственные” Якоря, отображающие объектную модель бизнеса не очевидно.
Как достигается гибкость
Получившаяся конструкция в обоих случаях содержит существенно больше таблиц, чем традиционное измерение. Но может занимать существенно меньше дискового пространства при том же наборе версионных атрибутов, что и традиционное измерение. Никакой магии тут, естественно, нет — всё дело в нормализации. Распределяя атрибуты по Сателлитам (в Data Vault) или отдельным таблицам (Anchor Model), мы уменьшаем (или совсем исключаем) дублирование значений одних атрибутов при изменении других.
Для Data Vault выигрыш будет зависеть от распределения атрибутов по Сателлитам, а для Якорной модели — практически прямо пропорционален среднему количеству версий на объект измерения.
Однако выигрыш по занимаемому месту — важное, но не главное преимущество отдельного хранения атрибутов. Вместе с отдельным хранением связей, такой подход делает хранилище модульной конструкцией. Это значит, что добавление как отдельных атрибутов, так и целых новых предметных областей в такой модели выглядит как надстройка над существующим набором объектов без их изменения. И это именно то, что делает описанные методологии гибкими.
Также это напоминает переход от штучного производства к массовому — если в традиционном подходе каждая таблица модели уникальна и требует отдельного внимания, то в гибких методологиях — это уже набор типовых “деталей”. С одной стороны, таблиц становится больше, процессы загрузки и выборки данных должны выглядеть сложнее. С другой — они становятся типовыми. А значит, могут быть автоматизированы и управляться метаданными. Вопрос “как будем укладывать?”, ответ на который мог занимать существенную часть работ по проектированию доработок, теперь просто не стоит (как и вопрос о влиянии изменения модели на работающие процессы).
Это не значит, что аналитики в такой системе совсем не нужны — кто-то все еще должен проработать набор объектов с атрибутами и разобраться откуда и как всё это загружать. Но объем работ, а также вероятность и цена ошибки существенно снижаются. Как на этапе анализа, так и при разработке ETL, которая в существенной части может свестись к редактированию метаданных.
Темная сторона
Всё вышеописанное делает оба подхода действительно гибкими, технологичными и пригодными для итеративной доработки. Разумеется есть и “бочка дегтя”, о которой вы, думаю, уже догадываетесь.
Декомпозиция данных, лежащая в основе модульности гибких архитектур, приводит к увеличению количества таблиц и, соответственно, накладных расходов на джойны при выборке. Для того, чтобы просто получить все атрибуты измерения, в классическом хранилище достаточного одного селекта, а гибкая архитектура потребует целого ряда джойнов. Причем если для отчетов все эти джойны можно написать заранее, то аналитики, привыкшие писать SQL руками, будут страдать вдвойне.
Есть несколько фактов, облегчающих такое положение:
При работе с большими измерениям почти никогда не используются одновременно все его атрибуты. Это значит, что джойнов может быть меньше, чем кажется при первом взгляде на модель. В Data Vault можно также учесть предполагаемую частоту совместного использования при распределении атрибутов по сателлитам. При этом сами Хабы или Якори нужны в первую очередь для генерации и маппинга суррогатов на этапе загрузки и редко используются в запросах (особенно это касается Якорей).
Все джойны — по ключу. Кроме того, более “сжатый” способ хранения данных снижает накладные расходы на сканирование таблиц там, где оно необходимо (например при фильтрации по значению атрибута). Это может приводить к тому, что выборка из нормализованной базы с кучей джойнов будет даже быстрее, чем сканирование одного тяжелого измерения с большим количеством версий на строку.
Например, вот в этой статье есть подробный сравнительный тест производительности Якорной модели с выборкой из одной таблицы.
Многое зависит от движка. У многих современных платформ есть внутренние механизмы оптимизации джойнов. Например, MS SQL и Oracle умеют “пропускать” джойны на таблицы, если их данные не используются нигде, кроме других джойнов и не влияют на финальную выборку (table/join elimination), а MPP Vertica по опыту коллег из Авито, показала себя как прекрасный движок для Якорной модели с учетом некоторой ручной оптимизации плана запроса. С другой стороны, хранить Якорную модель, например, на Click House, имеющем ограниченную поддержку join, пока выглядит не очень хорошей идеей.
Кроме того, для обеих архитектур существуют специальные приемы, облегчающие доступ к данным (как с точки зрения производительности запросов, так и для конечных пользователей). Например, Point-In-Time таблицы в Data Vault или специальные табличные функции в Якорной модели.
Итого
Основная суть рассмотренных гибких архитектур состоит в модульности их “конструкции”.
Именно это свойство позволяет:
Приложения
Типы сущности Data Vault
Типы сущностей Anchor Model
Подробнее про Anchor Model:
Сводная таблица с общими чертами и различиями рассмотренных подходов: