Data vault что это

Обзор гибких методологий проектирования DWH

Многое в жизни проекта зависит от того, насколько хорошо продумана объектная модель и структура базы на старте.

Общепринятым подходом были и остаются различные варианты сочетания схемы “звезда” с третьей нормальной формой. Как правило, по принципу: исходные данные — 3NF, витрины — звезда. Этот подход, проверенный временем и подкрепленный большим количеством исследований — первое (а иногда и единственное), что приходит в голову опытному DWH-шнику при мысле о том, как должно выглядеть аналитическое хранилище.

С другой стороны — бизнесу в целом и требованиям заказчика в частности свойственно быстро меняться, а данным — расти как “вглубь”, так и “вширь”. И вот тут проявляется основной недостаток звезды — ограниченная гибкость.

И если в вашей тихой и уютной жизни DWH-разработчика внезапно:

  • возникла задача “сделать быстро хоть что-то, а потом посмотрим”;
  • появился бурно развивающийся проект, с подключением новых источников и переделкой бизнес-модели минимум раз в неделю;
  • появился заказчик, который не представляет как система должна выглядеть и какие функции выполнять в конечном итоге, но готов к экспериментам и последовательному уточнению желаемого результата с последовательным же приближением к нему;
  • заглянул менеджер проектов с радостной вестью: “А теперь у нас аджайл!”.

Что значит «гибкость»

Для начала давайте определимся, какими свойствами должна обладать система, чтобы ее можно было назвать “гибкой”.

Отдельно стоит оговориться, что описываемые свойства должны относиться именно к системе, а не к процессу ее разработки. Поэтому если вы хотели почитать про Agile как методологию разработки, лучше ознакомиться с другими статьями. Например, тут же, на Хабре, есть масса интересных материалов (как обзорных и практических, так и проблемных).

Это не значит, что процесс разработки и структура ХД совсем никак не связаны. В целом разрабатывать по Agile хранилище гибкой архитектуры должно быть существенно легче. Однако на практике чаще встречаются варианты и с разработкой по Agile классического DWH по Кимбалу и DataVault — по вотэрфолу, чем счастливые совпадения гибкости в двух ее ипостасях на одном проекте.

И так, какими же возможностями должно обладать гибкое хранилище? Тут можно выделить три пункта:

  1. Ранняя поставка и быстрая доработка — это значит, что в идеале первый бизнес-результат (например, первые работающие отчеты) должен быть получен как можно раньше, то есть еще до того, как полностью спроектирована и внедрена система целиком. При этом каждая следующая доработка тоже должна занимать как можно меньше времени.
  2. Итеративная доработка — это значит, что каждая следующая доработка в идеале не должна затрагивать уже работающий функционал. Именно этот момент часто становится самым большим кошмаром на крупных проектах — рано или поздно отдельные объекты начинают обрастать таким количеством связей, что становится проще полностью повторить логику в копии рядом, чем добавить поле в существующую таблицу. И если вас удивляет, что анализ влияния доработки на существующие объекты может занимать больше времени, чем сама доработка — вы скорее всего ещё не работали с крупными ХД в банкинге или телекоме.
  3. Постоянная адаптация к меняющимся требованиям бизнеса — общая объектная структура должна быть спроектирована не просто с учетом возможного расширения а с расчетом на то, что направление этого очередного расширения не могло бы вам даже присниться на этапе проектирования.

Ниже я рассмотрю две самых популярных для ХД методологии гибкого проектирования — Anchor model и Data Vault. За скобками остаются такие прекрасные приемы, как например EAV, 6NF(в чистом виде) и всё, относящееся к NoSQL решениям — не потому, что они чем-то хуже, и даже не потому, что в этом случае статья грозила бы приобрести объем среднестатистического дисера. Просто всё это относится к решениям несколько другого класса — либо к приемам, которые вы можете применять в специфических случаях, независимо от общей архитектуры вашего проекта (как EAV), либо к глобально другим парадигмам хранения информации (как, например, графовые БД и другие варианты NoSQL).

Проблемы “классического” подхода и их решения в гибких методологиях

1. Жесткая кардинальность связей

В основу такой модели закладывается четкое разделение данных на измерения (Dimension) и факты (Fact). И это, черт побери, логично — ведь анализ данных в подавляющем большинстве случаев сводится именно к анализу определенных численных показателей (фактов) в определенных разрезах (измерениях).

При этом связи между объектами закладываются в виде связей между таблицами по внешнему ключу. Это выглядит вполне естественно, но сразу же приводит к первому ограничению гибкости — жесткому определению кардинальности связей.

Это значит, что на этапе проектирования таблиц вы должны точно определить для каждой пары связанных объектов могут ли они относиться как многие-ко-многим, или только 1-ко-многим, и “в какую сторону”. От этого напрямую зависит в какой из таблиц будет первичный ключ а в какой — внешний. Изменение этого отношения при получении новых требований с большой вероятностью приведет к переработке базы.

Например, проектируя объект “кассовый чек” вы, опираясь на клятвенные заверения отдела продаж, заложили возможность действия одной промо-акции на несколько чековых позиций (но не наоборот):

image

А через некоторое время, коллеги ввели новую маркетинговую стратегию, в которой на одну и ту же позицию могут действовать несколько промо-акций одновременно. И теперь вам надо доработать таблицы, выделив связь в отдельный объект.

(Все производные объекты, в которых происходит джойн чека на промо, теперь тоже нуждаются в доработке).

Связи в 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 Связи являются таким же полноценными объектами, как и Хабы, и могут иметь собственные атрибуты. В Якорной модели Связи используются только для соединения Якорей и собственных атрибутов иметь не могут. Это различие дает существенно разные подходы к моделированию фактов, о чем пойдет речь далее.

Хранение фактов

До этого мы говорили в основном про моделирование измерений. С фактами дело обстоит чуть менее однозначно.

В Data Vault типичный объект для хранения фактов — Связь (Link), в Сателлиты которой складываются вещественные показатели.

Такой подход выглядит интуитивно понятным. Он дает простой доступ к анализируемым показателям и в целом похож на традиционную таблицу фактов (только показатели хранятся не в самой таблице, а в “соседней”). Но есть и подводные камни: одна из типовых доработок модели — расширение ключа факта — вызывает необходимость добавления в 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 или специальные табличные функции в Якорной модели.

Итого

Основная суть рассмотренных гибких архитектур состоит в модульности их “конструкции”.

Именно это свойство позволяет:

  • После некоторой начальной подготовки, связанной с развертыванием метаданных и написанием базовых алгоритмов ETL, быстро предоставить заказчику первый результат в виде парочки отчетов, содержащих данные всего нескольких объектов источников. Полностью продумывать (даже верхнеуровнево) всю объектную модель для этого не обязательно.
  • Модель данных может начать работать (и приносить пользу) всего с 2-3 объектами, а потом постепенно разрастаться (относительно Якорной модели Николай применил красивое сравнение с грибницей).
  • Большинство доработок, включая расширение предметной области и добавление новых источников не затрагивает существующий функционал и не вызывает опасность сломать что-то уже работающее.
  • Благодаря декомпозиции на стандартные элементы, ETL-процессы в таких системах выглядят однотипно, их написание поддается алгоритмизации и, в конечном счете, автоматизации.

Приложения

Типы сущности Data Vault

Подробнее про Data Vault:
Сайт Дэна Листэдта
Всё о Data Vault на русском
О Data Vault на Хабре

Типы сущностей Anchor Model

Подробнее про Anchor Model:

Сайт создателей Anchor Model
Статья про опыт внедрения Anchor Model в Avito

Метод моделирования «Свод данных»

Свод данных ( Data Vault) как метод моделирования данных для ХД был предложен в конце 2002 года Dan Linstedt [57]. Метод моделирования «Свод данных» — это методология проектирования, разработанная для глобальных ХД масштаба предприятия и имеющая в основе набор связанных нормализованных таблиц, ориентированных на поддержку функциональных областей бизнеса с возможностью отражения истории. Метод удачно сочетает требования нормализации и возможности схемы » звезда «.

Использование этого метода предполагает наличие у проектировщика ХД базового уровня знаний в области моделирования данных, т.е. понимание таких терминов, как таблица ( table ), взаимосвязь ( relationship ), родитель ( parent ), потомок ( child ), ключ (primary/foreign key), измерение ( dimension ) и факт ( fact ).

Исследователи в области обработки данных постоянно ищут структуры данных для приложений искусственного интеллекта ( artificial intelligence — AI) и извлечения знаний ( data mining — DM). Большинство технологий DM предполагает импорт данных из подающих информационных систем в плоский файл ( flat file ) для того, чтобы объединить форму представления данных с функцией извлечения знаний . Поскольку объем данных в ХД растет быстро, экспорт информации для приложений DM становится затруднительным. Таким образом, возникает разрыв между формой представления (структурой), функцией (AI) и выполнением (DM).

Такой разрыв между формой, функцией и выполнением снижает эффективность использования методов AI и DM. Поэтому задача разработки структур данных, которые математически позволяют использовать технологии AI непосредственно в базах данных, остается очень актуальной. С точки зрения моделирования структур данных метод Data Vault основан на математических принципах, которые позволяют эффективно управлять большими объемами информации. Особенно этот метод эффективен для создания структур данных для динамического управления изменениями во взаимосвязях между данными как единицами представления информации в компьютерных системах. Он позволяет динамически управлять изменением взаимосвязей между данными в системе в процессе эволюции сохраняемых в ней данных.

Метод моделирования «Свод данных» (Data Vault)

Определение метода проектирования «Свод данных» (Data Vault)

Свод данных (Data Vault), по определению, является ориентированным на детали набором нормализованных связанных таблиц, которые обеспечивают информационную поддержку одной или более предметных областей деятельности организации. Этот подход является комбинацией методики реляционного проектирования (до третьей нормальной формы — 3NF ) и методики многомерного проектирования. Метод моделирования «Свод данных» был разработан для создания моделей данных глобальных ХД масштаба предприятия. Он основан на математических принципах, которые поддерживают нормализованные модели данных. По существу модель «Свод данных» соответствует нормализованной до 3NF схеме «звезда», включая измерения, связи «многие ко многим» и таблицы стандартной структуры. Различие лежит в более детальном представлении взаимосвязей и элементов данных, структурированных и детализованных во временном изменении. Этот метод проектирования был разработан, чтобы объединить гибкость структур обработки данных OLTP-систем с мощностью аналитической обработки данных в OLAP-системах. Он является масштабируемым и легко адаптируемым методом разработки структур данных для решения задач анализа данных в масштабах предприятия.

Проблемы моделирования данных для хранилищ данных

Обычно применение известных методик проектирования к разработке модели ХД масштаба предприятия, например, таких как нормализация, сталкивается с рядом трудностей.

В частности, использование 3NF для структур данных приводит к следующему.

  • Временная зависимость в первичном ключе (time-driven primary key) приводит к увеличению сложности поддержки отношения «родитель-потомок» и учету влияния каскадных изменений в таких отношениях.
  • Сложно обеспечить высокую производительность при загрузке данных в реальном времени в структуру в 3NF .
  • Во многих случаях усложняется доступ к данным при обработке запросов.
  • Возникают проблемы при использовании анализа на основе свертки-развертки данных ( drill -down analysis).

На рис. 18.1 показана попытка адаптировать структуру данных в 3NF к использованию в ХД. Одна из проблем этой структуры связана с размещением временной метки (data/ time stamp ) в первичном ключе родительской таблицы, для того чтобы представить изменения детальных данных во времени. Это проблема масштабируемости и гибкости структуры. Если данные добавляются в родительскую таблицу, изменения каскадно распространяются через все подчиненные таблицы . Например, когда новая строка вставляется с родительским ключом (parent key), у которого изменяется только поле временной метки, все дочерние строки должны быть переназначены на новый родительский ключ. Этот каскадный эффект имеет отрицательное влияние на обработку данных в таких таблицах, причем чем сложнее и больше структура, тем сильнее влияние каскадного эффекта. Для модели данных масштаба предприятия это создает трудности в расширении и сопровождении модели данных, и, как следствие, усложняется процесс проектирования.

Временная метка в третьей нормальной форме

Существует проблема и для взаимосвязанных киосков данных ( conformed data marts ). Такая архитектура глобального ХД представляет собой набор таблиц фактов, которые связаны между собой посредством первичных и внешних ключей или, другими словами, набор взаимосвязанных схем «звезда». При такой реализации ХД возникает ряд проблем, таких как изолированное представление предметно-ориентированных областей, возможное дублирование данных ( data redundancy ), различие представления таблиц фактов по уровню структурированности (детализуемости или гранулированности) данных , синхронизация данных во время загрузки в реальном времени, ограниченность использования технологии DM в масштабах предприятия и др. Схема «звезда» является типичной архитектурой, которая проектируется и реализуется по методологии «снизу вверх», и взаимосвязанные киоски данных создаются на основе подхода «снизу вверх», а реализуются на основе подхода «сверху вниз».

Одной из наиболее сложных проблем взаимосвязанных киосков данных является выбор правильного уровня гранулированности данных ( grain ) для таблиц фактов. Это означает, что агрегирование данных во всех таблицах будет согласованным по измерению времени, а структура каждой таблицы фактов не будет изменяться с точки зрения добавления новых измерений. Такой подход к проектированию ограничивает масштабируемость и гибкость модели данных. Другой проблемой могут быть вспомогательные таблицы в измерениях, которые обслуживают ссылки для взаимоотношений между измерениями. Гранулированность и стабильность измерений являются важными факторами успешного проектирования ХД.

Например, если гранулированность факта «Суммарный доход» таблицы «Суммарный доход» ( рис. 18.2) изменяется, то это должно привести к дублированию таблицы фактов с добавлением дополнительных атрибутов. Предположим, что таблицы фактов связаны между собой только посредством одних и тех же ключей измерений. При добавлении нового измерения к одной из таблиц фактов (например, к таблице фактов «Суммарный доход» добавим измерение «Контракт») факты в таблице «История контрактов» также должны измениться. Таблицы фактов не изменятся, только если они имеют одну и ту же гранулированность .

Взаимосвязанные киоски данных

Среди практиков-разработчиков ХД сложилось мнение, что архитектура ХД должна проектироваться на основе методологии «сверху вниз», а реализация выполняться на основе методологии «снизу вверх». Такой подход позволяет максимально приблизить архитектуру к пониманию задач предметной области ХД, в то время как реализация может поэтапно включать фрагменты предметной области в общее ХД, не нарушая миссию и видение системы складирования данных . Подходы к проектированию и разработке архитектуры ХД должны быть гибкими, чтобы быстро адаптироваться к росту объема данных и расширению или изменению предметных областей в системе.

Одним из подходов к решению задач разработки типовых моделей и архитектур данных является определенная нормализация структур данных. Так же, как и структуры БД OLTP-систем ( 1NF , 2NF , 3NF ; 4NF , 5NF ), БД ХД должны иметь определенную степень нормализации структуры данных. Модель «Свод данных» и является одной из таких нормализованных структур данных для ХД. Она включает методы построения структур данных для отношений «многие ко многим», ссылочной целостности, минимизации дублирования данных и установления семантических связей между ключевыми бизнес-функциями предметной области через концентраторы (hubs).

Элементы модели «Свод данных»

Модель проектирования «Свод данных», аналогично методам многомерного моделирования или » сущность-связь «, содержит ряд структурных компонент, новыми из которых являются сущности-концентраторы , или хабы, сущности-связи и сущности-сателлиты . Проектирование этим методом фокусируется на функциональных предметных областях деятельности организации. Каждая такая область характеризуется бизнес-ключом и представляется в концентраторе первичным ключом. Сущности-связи обеспечивают интеграцию операций между хабами. Сущности-сателлиты обеспечивают контекст первичного ключа хаба. Каждая из этих сущностей сконструирована для обеспечения максимальной гибкости и масштабируемости модели данных ХД масштаба предприятия.

Сущности-концентраторы (Hub Entities). Сущности-концентраторы , или просто хабы (hubs), являются таблицей, которая содержит минимальный список бизнес-ключей (натуральных ключей). Это ключи, которые используются организацией в каждой ежедневной операции: например, номер счета, табельный номер сотрудника, номер покупателя, номер изделия и номер автомобиля. Если в процессе деятельности такой ключ был потерян, то, как правило, теряются и ссылка на контекст, и сопутствующая информация. Помимо натуральных ключей (на рис. 18.3 – атрибут «Номер покупателя в источнике данных»), концентраторы могут иметь следующие атрибуты:

  • суррогатный ключ – опциональный атрибут, который является обычно членом числовой последовательности. На рис. 18.3 – атрибут «Номер»;
  • временная метка загрузки (Load Data/ Time Stamp ) – это дата и время, когда ключ впервые появился в БД. На рис. 18.3 — атрибут «Время загрузки из источника»;
  • источник данных (Record Source) – записывается для трассировки данных. На рис. 18.3 — атрибут «Наименование источника данных».

Пример концентратора для покупателей

Рис. 18.3 показывает пример сущности «Концентратор для покупателей». В этой сущности атрибут «Номер покупателя в источнике данных» является первичным бизнес- ключом, а атрибут «Номер» является суррогатным ключом, назначенным для покупателей внутри системы. В табл. 18.1 приведен пример контекста для сущности «Концентратор для покупателей».

Таблица 18.1. Контекст сущности «Концентратор для покупателей»
Номер Номер покупателя в источнике данных Время загрузки из источника Наименование источника данных
1 1234 23.01.2009 Продажи
2 1235 24.01.2009 Контракты
3 2266 26.01.2009 Финансы
4 2344 28.01.2009 Продажи

Cущности-концентраторы не могут быть связаны отношением «один ко многим» (родитель-потомок). Для построения взаимосвязей между концентраторами используются сущности-связи .

Связывающая сущность, или сущность-связь (Link Entitiy) . Сущности-связи являются физическим представлением взаимосвязи «многие ко многим» в 3NF. Связь представляет собой взаимоотношение или операцию между двумя или более бизнес-компонентами или бизнес-ключами. Сущности-связи содержат следующие атрибуты (см. рис. 18.4):

  • суррогатный ключ – опциональный атрибут, который используется при связывании более двух концентраторов (на рис. 18.4 не показан);
  • ключи концентраторов (Hub Key) – ключи концентраторов, которые мигрируют в сущность-связь для формирования составного ключа , связывающего эти концентраторы;
  • временная метка загрузки (Load Data/ Time Stamp ) – дата и время записи связи в БД;
  • источник данных (Record Source) – используется для трассировки данных.

Пример сущности-связи

Этот компонент модели предназначен для разрешения проблемы отношения «многие ко многим» для ХД. Вместе с сущностями-концентраторами связывающие сущности описывают поток данных предметной области ХД. Табл. 18.2 иллюстрирует содержание соответствующих сущностям таблиц БД.

Развитие DATA VAULT и переход к BUSINESS DATA VAULT

В предыдущей статье я рассказал об основах DATA VAULT, описал основные элементы DATA VAULT и их назначение. На этом нельзя считать тему DATA VAULT исчерпанной, необходимо поговорить о следующих ступенях эволюции DATA VAULT.

И в этой статье я сконцентрируюсь на развитии DATA VAULT и переходу к BUSINESS DATA VAULT или просто BUSINESS VAULT.

Причины появления BUSINESS DATA VAULT

Следует отметить, DATA VAULT имея определенные сильные стороны не лишен недостатков. Одним из таких недостатков является сложность в написании аналитических запросов. Запросы имеют значительное количество JOIN’ов, код получается длинным и громоздким. Также данные попадающие в DATA VAULT не подвергаются никаким преобразованиям, поэтому с точки зрения бизнеса DATA VAULT в чистом виде не имеет безусловной ценности.

Именно для устранения этих недостатков методология DATA VAULT была расширена такими элементами как:

  • PIT (point in time) таблицы;
  • BRIDGE таблицы;
  • PREDEFINED DERIVATIONS.

Давайте более детально разберем назначение этих элементов.

PIT таблицы

Как правило один бизнес объект (HUB) может иметь в своем составе данные с различной частотой обновления, например, если мы говорим о данных характеризующих человека, мы можем сказать, что информация о номере телефона, адресе или электронной почте имеет более высокую частоту обновления, чем скажем, ФИО, данные паспорта, семейное положение или пол.

Поэтому, при определении сателлитов, следует иметь ввиду частоту их обновления. Почему это важно?

Если в одной таблице хранить атрибуты с различной частотой обновления, придется добавлять строку в таблицу при каждом обновлении самого часто изменяемого атрибута. Как следствия – рост объема дискового пространства, увеличение времени исполнения запросов.

Теперь, когда мы разделили сателлиты по частоте обновления, и можем загружать в них данные независимо, следует обеспечить возможность получения актуальных данных. Лучше, без использования излишних JOIN’ов.

Поясню, например, требуется получить актуальную (по дате последнего обновления) информацию из сателлитов имеющих разную частоту обновления. Для этого потребуется не только сделать JOIN, но и создать несколько вложенных запросов (к каждому сателлиту содержащему информацию) с выбором максимальной даты обновления MAX(Дата обновления). С каждым новым JOIN’ом такой код разрастается, и очень быстро становится сложным для понимания.

PIT таблица призвана упростить такие запросы, PIT таблицы заполняются одновременно с записью новых данных в DATA VAULT. PIT таблица:

Развитие DATA VAULT и переход к BUSINESS DATA VAULT

Таким образом у нас есть информация об актуальности данных по всем сателлитам на каждый момент времени. Используя JOIN’ы к PIT таблице, мы можем полностью исключить вложенные запросы, естественно с условие, что PIT заполняется каждый день и без пропусков. Даже, если пропуски в PIT имеют место, получить актуальные данные можно лишь используя один вложенный запрос к самому PIT’у. Один вложенный запрос отработает быстрее чем вложенные запросы к каждому сателлиту.

BRIDGE

Таблицы типа BRIDGE также используется для упрощения аналитических запросов. Однако отличием от PIT является средством упрощения и ускорения запросов между различными хабами, линками и их сателлитами.

Таблица содержит все необходимы ключи для всех сателлитов, которые часто используются в запросах. Кроме того, при необходимости хешированные бизнес ключи могут дополняться ключами в текстовом виде, если наименования ключей нужны для анализа.

Дело в том, что без использования BRIDGE, в процессе получения данных находящихся в сателлитах принадлежащим разным хабам, потребуется произвести JOIN не только самих сателлитов, но и линков связывающих хабы.

Наличие или отсутствие BRIDGE определяется конфигурацией хранилища, необходимостью оптимизации скорости исполнения запросов. Универсального пример BRIGE придумать сложно.

PREDEFINED DERIVATIONS

Еще одним типом объектов, который приближает нас к BUSINESS DATA VAULT являются таблицы содержащие предварительно рассчитанные показатели. Такие таблицы действительно важны для бизнеса, они содержат информацию, агрегированную по заданным правилам и позволяют получить к ней доступ относительно просто.

Архитектурно PREDEFINED DERIVATIONS представляют из себя, ничто иное, как еще один сателлит определенного хаба. Он, как и обычный сателлит содержит бизнес ключ и дату формирования записи в сателлите. На этом, однако, сходства заканчиваются. Дальнейший состав атрибутов такого «специализированного» сателлита определяется бизнес пользователями на основе наиболее востребованных, предварительно рассчитанных показателей.

Например, хаб содержащий информацию о сотруднике, может включать в себя сателлит с такими показателями, как:

  • Минимальная зарплата;
  • Максимальная зарплата;
  • Средняя зарплата;
  • Накопительный итог начисленной зарплаты и т.д.

Логично включать PREDEFINED DERIVATIONS в состав PIT таблицы этого же хаба, тогда можно без труда получить срезы данных по сотрудника на конкретно выбранную дату.

ВЫВОДЫ

Как показывает практика использование DATA VAULT бизнес пользователями несколько затруднительно по нескольким причинам:

  • Код запросов сложный и громоздкий;
  • Обилие JOIN’ов влияет на быстродействие запросов;
  • Для написания аналитических запросов требуется выдающееся знание структуры хранилища.

Чтобы упростить доступ к данным, DATA VAULT расширяется дополнительными объектами:

  • PIT (point in time) таблицы;
  • BRIDGE таблицы;
  • PREDEFINED DERIVATIONS.

В следующей статье я планирую рассказать, на мой взгляд, самое интересное, для тех, кто работает с BI. Я представлю способы создания таблиц – фактов и таблиц – измерений на базе DATA VAULT.

Data Vault: Знакомство с Data Vault

Назначение этого документа – представить и обсудить заявленную на патент технологию под названием Data Vault™ (прим. переводчика: статья была написана в 2001 году, в предоставлении патента было отказано в январе 2005; сейчас архитектура Data Vault – общедоступна – FREE and PUBLIC DOMAIN). Data Vault™ – новый этап эволюции моделирования данных для хранилищ данных масштаба предприятия. Этот, сугубо технический документ, предназначен для аудитории, состоящей из проектировщиков данных, архитекторов данных и администраторов баз данных. Документ не предназначен для бизнес-аналитиков, менеджеров проектов и программистов. Рекомендуется, чтобы читатель обладал базовым уровнем знаний в области моделирования данных и хорошо понимал термины: таблицы, отношения, родитель, потомок, ключ (первичный / внешний), измерения и факты. Предметы обсуждения этой статьи следующие:

  • Определение Data Vault.
  • Краткая история моделирования данных для хранилищ.
  • Архитектурные проблемы существующих моделей хранилищ данных.
  • Важность архитектуры и дизайна для корпоративных хранилищ данных.
  • Компоненты Data Vault.
  • Решение существующих проблем архитектуры хранилищ данных.
  • Основы архитектуры Data Vault.
  • Возможные применения Data Vault.

Прочитав это документ, Вы можете узнать:

  • Что такое Data Vault и какое она имеет значение.
  • Как самому создать небольшое хранилище Data Vault.
  • Какие перспективы хранилищ данных несостоятельны.

Слишком долго мы ждали структур данных, которые, наконец-то, приблизятся к приложениям искусственного интеллекта и приложениям интеллектуального анализа данных (data mining). Большинство технологий интеллектуального анализа данных (data mining) требуют импортировать информацию в плоские файлы, чтобы соединить форму с функцией. К сожалению, объемы хранилищ данных растут быстро, и экспортировать эту информацию, предназначенную для интеллектуального поиска данных, становится все труднее. Просто не имеет смысла иметь эту неоднородность/разрыв между формой (структурой данных), функцией (искусственным интеллектом), и выполнением (осуществлением добычи данных).

Объединение формы, функции и выполнения имеет огромное значение для сообщества искусственного интеллекта (AI) и интеллектуального анализа данных. Найдена структура данных, которая математически обоснованно увеличивает возможность вернуть эти технологии к использованию баз данных, а не файлов. Модель Data Vault основана на математических принципах, которые позволяют ей быть расширяемой и способной к обработке огромных объемов информации. Эти архитектура и структура данных предназначены для обработки динамических меняющихся отношений между информацией.

Мы надеемся, что напряженное мышление в один прекрасный день инкапсулирует данные с функциями интеллектуального анализа данных, чтобы приблизиться к образцу «обладающей самосознанием» независимой информации, но это – пока только мечта. Но можно динамически формировать, понижать, и оценивать отношения между наборами данных. Таким образом, изменяя ландшафт возможностей модели данных, по существу, мы приводим модель данных в динамически меняющееся состояние (благодаря использованию интеллектуального анализа данных / искусственного интеллекта).

Благодаря реализации эталонной архитектуры (reference architecture) поверх структуры Data Vault функции, имеющие доступ к контенту, могут начать выполняться в параллельном и автоматическом режиме. Data Vault решает часть структурных проблем Корпоративного Хранилища Данных и проблемы хранения, причем, используя нормализованный, лучший в своем роде, подход. Эти концепции предоставляют целый ряд возможностей применения этой уникальной технологии.

«Вы должны стремиться делать то что, по Вашему мнению, Вы не сможете сделать»,
Элеонора Рузвельт.

2.0 Определение Data Vault

Определение:
Data Vault – набор уникально связанных нормализованных таблиц, содержащих детальные данные, отслеживающих историю изменений и предназначенных для поддержки одной или нескольких функциональных областей бизнеса.

Это — гибридный подход, обобщающий лучшие свойства третьей нормальной формы (3NF) и схемы Звезда (Star schema).
Дизайн Data Vault – гибок, масштабируем, последователен и приспосабливаем к потребностям предприятия. Это – модель данных, спроектированная специально для удовлетворения потребностей хранилищ данных предприятия.

Архитектура Data Vault предназначена для удовлетворения потребностей хранилищ данных (data warehouse), не путайте с витринами данных (data mart). Также может исполнять вторую роль – Operational Data Store (ODS), при условии применения для поддержки этого правильных аппаратных средств и ядра базы данных. Data Vault может обрабатывать большие наборы детальных данных используя меньшие физические объемы, по сравнению и с 3-ей нормальной формой (3NF), и по сравнению со схемой Звезда (Star schema). Data Vault имеет твердый «фундамент», основанный на математических принципах, которые поддерживают нормализованные модели данных. В модели Data Vault содержаться структуры, которые знакомые и соответствуют традиционным определениям схемы звезда и 3NF, включая: измерения, связи многие ко многим и стандартные табличные структуры. Различия заключаются в представлении отношений, структурировании полей и хранении детальных данных, основанных на времени. Методы моделирования, встроенные в Data Vault, испытаны годами проектирования и тестирования в самых различных сценариях, а также твердым подходом к хранилищам данных.

2.1 Краткая история моделей для хранилищ данных

Подход 3NF – третья нормальная форма – был первоначально создан в начале 1960-ых (см. Эдгар Кодд (Edgar F. Codd) и Кристофер Дейт (Christopher J. Date)) для систем оперативной обработки транзакций (OLTP). В начале 1980-ых это подход был приспособлен к возрастающим потребностям хранилищ данных. По существу, доработка заключалась в добавлении временной метки (date-time stamp) к первичным ключам каждой таблицы (см. иллюстрацию 1 ниже).

Со второй половине 1980-х в моделировании данных стали применять схему Звезда (Star schema). Эта схема была спроектирована, чтобы решить предметно-ориентированные проблемы, включая (но, не ограничиваясь): агрегирование, изменение структуры модели данных, производительность запросов, повторное или совместное использование информации, простоту использования, и способность поддерживать аналитическую обработку в реальном времени (OLAP). Эта, сконцентрированная на едином предмете архитектура, стала известна как витрина данных (data mart). Вскоре схема Звезда также была приспособлена для мульти-предметных хранилищ данных, как попытка удовлетворить возрастающие потребности хранилищ данных предприятия, и получила название Согласованные витрины данных (Conformed Data Marts).

Рисунок 1. История моделей для хранилищ данных

Низкая производительность и другие слабости, как третьей нормальной формы (3NF), так и схемы Звезда, при использовании в хранилищах данных предприятия, начали проявлять себя в 90-ых, поскольку объемы данных увеличились. Модель Data Vault спроектирована, чтобы преодолеть эти недостатки, сохраняя сильные стороны архитектуры 3NF и архитектуры звезда. В течение прошлого года (от даты этой статьи, т.е. в 2001-02), эта техника была благосклонно принята индустриальными экспертами. Data Vault – следующее шаг в эволюции моделирования данных, потому что это создавалось специально для корпоративных хранилищ данных.

2.2 Проблемы существующих архитектур и моделей данных для хранилищ данных

Все техники моделирования имеет ряд ограничений при их применении в архитектуре хранилищ данных масштаба предприятия. Это происходит из-за того, что используется адаптация, а не дизайн, первоначально созданный специально для этой задачи. Эти ограничения уменьшают удобство и простоту использования и постоянно являются поводом к «священным войнам» в мире хранилищ данных. Следующие строки касаются этих архитектур, применяемых не в их первоначальных целях, а для хранилищ данных.

Третья нормальная форма (3NF) имеет следующие осложняющие жизнь проблемы: проблемы первичного ключа, зависимого от времени и от сложных родительско-детских отношений; воздействие каскадных изменений; трудности загрузки в режиме близком к реальному времени; трудоемкие запросы; проблематичный drill-down анализ; проектирование «сверху вниз» и неизбежная нисходящая «сверху вниз» реализация (top-down). Следующий рисунок представляет собой оригинальную 3NF модель, приспособленную к архитектуре хранилища данных. Особенно острая проблема очевидна – когда временная отметка (date-time stamp) помещается в первичный ключ родительской таблицы (см. рисунок 2). Это необходимо, чтобы отображать историю происходящих со временем изменений детальных данных.

Проблемой является масштабируемость и гибкость. Если добавить дополнительную родительскую таблицу, такое изменение вызовет каскадные изменения всех нижележащих подчиненных таблиц. Кроме того, если вставлена новая строка с существующим родительским ключом (единственное измененное поле – временная отметка), то все дочерние строки должны быть повторно переназначены на новый родительский ключ. Этот каскадный эффект оказывает огромное влияние на процессы и модель данных, причем чем больше модель, тем больше воздействия. Это мешает (или делает невозможным) расширять и поддерживать модель данных масштаба предприятия. От этого в результате страдают архитектура и дизайн.

Рисунок 2. Временная отметка в 3NF

У согласованных витрин данных также есть проблемы. Согласованные витрины данных – набор таблиц фактов, которые связаны через первичные / внешние ключи – другими словами, набор нескольких взаимосвязанных схем Звезда. Это создает многочисленные проблемы: изолированная предметно ориентированная информация; возможная избыточность данных; несовместимые структуры запросов; проблемы масштабируемости; трудности со связыванием таблиц фактов (несовместимая степень детализации); проблемы синхронизации при загрузках близких к реальному времени; ограниченные представления корпоративной информации и неудобная среда для интеллектуального анализа данных (data mining). Хотя схема звезда, как правило, проектируется и реализуется «снизу вверх» (bottom up) по восходящей, однако согласованные витрины данных должны проектироваться «сверху вниз», а реализовываться по восходящей «снизу вверх». Однако, неофициальный опрос показал, что они фактически и проектируются, и реализуются «снизу вверх».

Одной из самых трудных проблем согласованных витрин данных (или согласованных таблиц фактов) является получение правильной степени детализации. Это означает понимать, как данные агрегируются для каждой таблицы фактов, и гарантировать, что агрегирование останется согласованным всегда (все время жизни отношений), и структура каждой таблицы фактов не изменится, то есть, никакие новые измерения не будут добавлены ни к одной таблице фактов. Это ограничивает дизайн, масштабируемость и гибкость модели данных. Другая проблема – «вспомогательная таблица». Эта таблица предназначена, чтобы быть связью между взаимозависимыми измерениями. Степень детализации очень важна, так как это – стабильность конструкции измерений. Это также ограничивает дизайн, масштабируемость и гибкость модели данных.

Рисунок 3. Согласованные витрины данных

Если степень детализации таблицы фактов «Revenue» (Доход) изменится, то это уже будет не та же самая таблица фактов. При добавлении измерения к одной из таблиц фактов степень детализации часто меняется. Предполагается также, чтобы таблицы фактов могут быть связаны друг с другом потому, что они содержат одни и те же ключи измерений. Это верно только в том случае, если факты агрегированы с одной и той же степенью детализации во всех таблицах, что чрезвычайно трудно поддерживать, так как система растет и развивается.

2.3 Важность архитектуры и дизайна для корпоративных хранилищ данных

Хранилище данных следует проектировать «сверху вниз» (top down) и реализовывать «снизу вверх» (bottom up). Это позволяет архитектуре достигать максимально известных границ знания, в то же время, позволяя реализации оставаться в контролируемых рамках, что все вместе может способствовать быстрым срокам поставки. Поэтому реализация должна быть проектированием набора plug-and-play таблиц, не становясь при этом «узким местом» сразу после поставки. Дизайн и архитектура хранилища данных должно быть достаточно гибким, чтобы расти и меняться с потребностями бизнеса, потому что потребности сегодняшнего дня – не обязательно потребности завтрашнего дня.

Наша индустрия испытывает потребность в формализованной архитектуре моделирования данных и дизайне, которые способны к точному представлению хранилищ данных. Архитектура должна иметь нормализацию, определенную именно для хранилищ данных, а не для систем OLTP. Например, для OLTP определена нормализация 1-ой, 2-ой и третьей нормальных форм; а так же есть 4-ая, 5-ая и возможно 6-ая нормальные формы. У Хранилища данных сегодня нет таких структурированных или предопределенных форм нормализации для моделирования данных. Также очевидно, что уже не достаточно случайных усилий по нормализации архитектуры корпоративных хранилищ данных. Несогласованности методов моделирования приводят к напряженной реализации.

Data Vault – определение нормализации моделей данных для хранилищ. Ее сила заключается в использовании определенной структуры, из которой строится модель. Data Vault использует некоторые из следующих методов моделирования данных: отношения многие ко многим, ссылочная целостность, минимально избыточный набор данных и информационные хабы с ключевыми бизнес-функциями. Эти методы делают модель данных Data Vault гибкой, расширяемой и согласованной. Подход к построению модели данных является итеративным, предоставляющим архитекторам данных и деловым пользователям платформу для построения хранилища данных на компонентной основе (см. статью Билла Инмона: Data Mart Does Not Equal Data Warehouse, DMReview.com).

3.0 Компоненты Data Vault

Для того чтобы сохранить дизайн простым и изящным, используется минимальное количество типов сущностей: Хаб (Hub), Связь (Link) и Спутник (Satellite). Дизайн Data Vault сосредоточен вокруг функциональных областей бизнеса представленных первичным ключом сущности Хаб (Hub). Сущность Связь (Link) обеспечивает транзакционную интеграцию между Хабами. Сущность Спутник (Satellite) предоставляет контекст первичного ключа Хаба. Каждый сущность предназначена для обеспечения максимальной гибкости и масштабируемости, сохраняя при этом большинство традиционных навыков моделирования данных.

3.1 Сущность Хаб (Hub)

Хабы (Hub), являются отдельными таблицами, содержащими как минимум уникальный список бизнес ключей. Эти ключи — то, что бизнес используют в повседневных операциях. Например, номер счета-фактуры, номер сотрудника, номер клиента, номер компонента и VIN (vehicle identification number — идентификационный номер транспортного средства). Если бизнес потеряет ключ, то они потеряют ссылку на контекст или окружающую информацию. Другие атрибуты Хаба включают:

  • Суррогатный ключ (Surrogate Key) – необязательный компонент, возможно смарт-ключ или порядковый номер.
  • Временная отметка даты загрузки (Load Date Time Stamp), регистрирующая, когда ключ впервые был загружен в хранилище.
  • Источник данных (Record Source) – регистрация исходной системы, используется для обратной трассировки (отслеживания) данных.

Например, требования заключаются в том, чтобы собирать номера клиентов по всей компании. Бухгалтерия может иметь номер клиента, представленный в цифровом стиле (12345) а отдел контрактов может иметь тот же номер клиента с буквенной приставкой (AC12345). В данном случае, представление номера клиента в Хабе будет алфавитно-цифровым и с максимальной длинной, чтобы хранить все номера клиента из разных функциональных областей бизнеса. В Хабе будет два вхождения: 12345 и AC12345, каждое будет иметь свой собственный источник данных: один из бухгалтерского учета и один из отдела контрактов. Очевидно, предпочтительнее было бы выполнить очистку и сопоставление этих номеров и интегрировать их в одну запись. Но это выходит за рамки данного документа. Первичный ключ Хаба всегда мигрирует из Хаба. Как только мы правильно идентифицируем бизнес посредством ключей (например, клиенты и счета), то могут быть построены сущности Связи.

3.2 Сущность Связь (Link)

Сущности Связи (или просто Связи) – физическое представление связей «многие ко многим» третьей нормальной формы (3NF). Сущность Связь представляет отношения или транзакцию между двумя или более компонентами бизнеса (два или более бизнес ключа). Связь содержит следующие атрибуты:

  • Суррогатный ключ (Surrogate Key) – необязательный компонент, возможно смарт-ключ или порядковый номер. Используются только, если существует более двух Хабов связанных этой Связью, или если составной первичный ключ может привести к проблемам производительности.
  • Ключи Хабов: от 1-го Хаба до N-го Хаба – ключи Хабов мигрируют в сущность Связь, образуя составной ключ, и представляют взаимодействия и связи между Хабами.
  • Временная отметка даты загрузки (Load Date Time Stamp), регистрирующая, когда связь/транзакция впервые была создана в хранилище.
  • Источник данных (Record Source) – регистрация исходной системы, используется для обратной трассировки (отслеживания) данных.

Это – адаптация отношений «многие ко многим» третьей нормальной формы (3NF), решающая проблемы, связанные с масштабируемостью и гибкостью. Эта техника моделирования разработана для хранилищ данных, а не для OLTP систем. Имейте в виду, что некоторые из основополагающих правил для моделирования Data Vault будут перечислены в конце этого документа. С помощью только нескольких Хабов и Связей модель данных начнет описание потоков бизнеса (business flow). Следующий наш компонент должен объяснить: «когда?», «почему?», «что?», «где?» и «кто?» создал, как сделки, так и, собственно, ключевые объекты. Например, недостаточно знать, что есть некоторый VIN у транспортного средства, или что есть водитель номер 5. Заказчик хочет знать, что именно представляет собой определенный VIN (например, синяя Тойота, пикап, 4WD и т.д.), и что водителя номер 5 зовут Джейн, и что это и есть водитель автомобиля с конкретным VIN.

3.3 Сущность Спутник (Satellite)

Сущности Спутники (или просто Спутники), являются контекстной (описательной) информацией ключа Хаба. Описание подвергается изменениям с течением времени, и поэтому структура Спутников должна быть способна хранить новые или измененные детальные данные. Значение VIN не должно меняться, но если ремонтная бригада, восстанавливая Тойоту, уберет верх и добавит трубчатый каркас (ролл-бар), машина не будет больше пикапом. Что делать, если Джейн продаст машину, кому-то еще, скажем, водителю под номером 6? Спутник состоит из следующих обязательных атрибутов:

  • Первичный ключ Спутника: Первичный ключ Хаба или первичный ключ Связи – мигрирует в Спутник из Хаба или Связи.
  • Первичный ключ Спутника: Временная отметка даты загрузки (Load Date Time Stamp) – регистрация, когда информация контекстная стала доступна в хранилище (всегда вставляется новая строка).
  • Первичный ключ Спутника (необязательное поле): Последовательный (sequence) суррогатный номер – используется для Спутников, которые имеют несколько значений (например, адрес выставление счетов и домашний адрес); или номер позиции строки, используется для поддержки подгрупп и порядка.
  • Источник данных (Record Source) – регистрация исходной системы, используется для обратной трассировки (отслеживания) данных.

Спутник наиболее близок медленноменяющимся измерениям 2-го Типа в определении Ральфа Кимбалла. Он хранит изменения на детальном уровне, а его функция заключается в обеспечении описательного контекста экземплярам Хаба или Связи. Например, факт, что VIN 1234567 представлял собой синий грузовик Тойота вчера, а сегодня это – красный грузовик Тойота (перекрасили). Цвет может храниться в Спутнике автомобиля. Проектирование Спутников должно основываться на математических принципах сокращения избыточности данных и на скорости изменения данных. Например, если автомобиль арендуется, то дата доступности / аренды может меняться ежедневно, что гораздо чаще, чем скорость изменения цвета, шин или владельца. Проблема, решаемая Спутником, определяется следующим образом:

Автомобильное измерение может содержать более 160-ти атрибутов. Если используется 2-ой тип размерности, то при изменении цвета или замене шин, все 160 с лишним атрибутов должны копироваться в новую строку. Почему данные копируются, если остальная часть атрибутов меняется медленнее? При использовании измерений 1-го Типа или 3-го Типа можно частично или полностью потерять историю изменений. В таком случае проектировщик данных должен построить как минимум два Спутника: один с датами наличия автомобиля, второй, описывающий техническое обслуживание / комплектующие элементы. Если первый день арендует автомобиль клиент Дэн, а второй день – Джейн, то сущности Связи отвечают за представление этих отношений. Проектировщик данных может добавить к Связи один или несколько Спутников, которые представляют даты аренды (от / до), состояние транспортного средства и замечания со стороны арендатора.

3.4 Создание Data Vault

Модель Data Vault должна строиться следующим образом:

  1. 1. Смоделируйте Хабы. Для этого требуется понимать основные бизнес сущности (бизнес ключи) и как они используются в выбранной области.
  2. 2. Смоделируйте Связи. Выявление возможных отношений между ключами – требует формулировки, как бизнес работает сегодня в контексте каждого бизнес ключа.
  3. 3. Смоделируйте Спутники. Обеспечение контекста, как каждой бизнес сущности (бизнес ключу), так и транзакциям/сделкам (Связи), соединяющим Хабы вместе. С этого начинается проявляться полная картина о бизнесе.
  4. 4. Смоделируйте point-in-time таблицы. Это – производные Спутников, структура и определение которых выходят за рамки этого документа (из-за ограничений по объему).

Существуют методы, для представления внешних источников, таких как плоские файлы, Excel и пользовательские файлы с разделителями — из-за нехватки времени и объема, эти вопросы не будут здесь обсуждаться. Все структуры и методы моделирования применяются независимо от типа источника.

Ссылочные правила для Data Vault:

  1. 1. Ключи Хабов не могут мигрировать в другие Хабы (никаких Хабов подобных родитель/потомок не должно быть). Моделирование в такой манере нарушает гибкость и расширяемость техники моделирования Data Vault.
  2. 2. Хабы должны быть связаны с помощью сущностей типа Связь.
  3. 3. С помощью Связей может быть связано более двух Хабов.
  4. 4. Сущности Связи могут быть связаны с другими сущностями типа Связи.
  5. 5. Связи должны иметь, по крайней мере, два связанных с ними Хаба.
  6. 6. Суррогатные ключи могут быть использованы в Хабах и Связях.
  7. 7. Суррогатные ключи не могут быть использованы в Спутниках.
  8. 8. Ключи Хаба всегда мигрируют наружу.
  9. 9. Бизнес-ключи Хаба никогда не меняются, первичные ключи Хабов никогда не меняются.
  10. 10. Спутники могут быть связаны как с Хабами, так и со Связями.
  11. 11. Спутники всегда содержать либо временную отметку даты загрузки (Load Date Time Stamp), или числовой внешний ключ, ссылающийся на автономную таблицу, содержащую последовательность временных отметок загрузки.
  12. 12. Могут быть использованы автономные таблицы, такие как календари, время, коды и описания.
  13. 13. Сущности Связи (Links) могут иметь суррогатный ключ.
  14. 14. Если Хаб имеет два или более Спутника, point-in-time таблица может быть создана для удобства операций соединения (join).
  15. 15. Спутники фиксируют только изменения, дублирования строк не должно быть.
  16. 16. Данные распределяются по структуре Спутников, основываясь на: 1) типе информации, 2) темпах изменения.

Эти простые компоненты Хаб (Hub), Связь (Link) и Спутник (Satellite) в совокупности образуют Data Vault. Хранилища Data Vault могут быть как малыми, с одним Хабом и с одним Спутником, так и настолько большими насколько требуют рамки применения. В последствии рамки всегда могут быть изменены, и ни масштабируемость, ни степень детализации информации не являются проблемой. Проектировщик данных может конвертировать отдельные компоненты существующей модели хранилища данных в архитектуру Data Vault только один раз. Потому что эти изменения обособят Хабы и Спутники. Связи представляют бизнес (как взаимодействие функциональных областей). Таким образом, Связи могут быть с ограниченным периодом действия, пересмотрены, перестроены и так далее.

4.0 Решение архитектурных недостатков хранилищ данных

3NF и схема Звезда, когда они используются для хранилищ данных предприятия, могут причинять бизнесу боль, потому что они не были изначально предназначены для целей хранилищ. Есть проблемы, связанные с масштабируемостью, гибкостью и степенью детализации данных, интеграцией и объемом. Объем информации, которую хранилища обязаны хранить сегодня, увеличивается по экспоненте каждый год. Приложения CRM, SCM, ERP и все другие большие системы приводят к увеличению объемов информации в хранилищах. Существующие модели данных, основанные на 3NF или схеме Звезда, оказывается, трудно изменять, поддерживать и анализировать, не говоря уже о резервном копировании и восстановлении.

В ранее приведенном примере мы реализовали хранилище Data Vault, состоящее из единственного Хаба и нескольких Спутников и ограниченное рамками хранения истории о транспортных средствах и соответствующих им атрибутах. Если год спустя бизнес захочет видеть в хранилище контракты по этим транспортным средствам, то необходимые Хабы и Связи могут быть легко добавлены. Не беспокойтесь о степени детализации. Этот тип модели расширяем верх и вширь (реализация «снизу вверх», проектирование «сверху вниз»). Конечный результат всегда строго фундаментирован и может создаваться итерационным подходом к разработке.

Другой пример – сильные возможности сущности Связь. Предположим, что сегодня компания, продающая продукцию, имеет Хаб Продукты, Хаб Счет и Связь между ними. Затем компания решает продавать услуги. Модель данных позволяет ввести новый Хаб Услуги, заполнить дату окончания в продуктовые Связи и начать новую Связь между услугами и счетами. Никакие данные не потеряны, и все данные, накопленные в течение долгого времени сохранены и отражают изменения бизнеса. Это лишь одна из многочисленных возможностей для обработки подобной ситуации.

Большой объем данных приводит к проблемам с запросами, особенно это касается схем Звезда, но в меньшей степени и 3NF. Нарушается производительность запросов при больших объемах информации в согласованных измерениях и согласованных таблицах фактов. Часто требуется делать партиционирование и непрерывно переделывать структуры, чтобы предоставить дополнительную степень детализации бизнес пользователям. Это обеспечивает кошмар обслуживания и управления. Перезагрузка постоянно меняющихся звезд является трудной задачей – не говоря уже о попытке выполнить это с большим объемом данных (свыше 1 Терабайт, например). Data Vault уходит корнями в математические основы нормализованной модели данных. Сокращения избыточности и учет темпов изменения наборов данных способствует повышению производительности и простоте в управлении. Архитектура Data Vault не ограничивается применением какой-либо одной платформы. Архитектура так же позволяет использовать распределенный взаимосвязанный набор информации.

Хранилищам данных часто приходится дело с утверждением: «То, что я (пользователь) дам Вам – это никогда не приходит из исходных систем». И они предоставляют крупноформатную таблицу со своей ежедневно поддерживаемой интерпретацией информации. Другими словами: «Я (заказчик) хочу видеть все номера VIN, которые начинаются с «X», сгруппированными под названием «BIG TRUCKS» («БОЛЬШИЕ ГРУЗОВИКИ»)». В Data Vault предусмотрена такая возможность с помощью Набора Пользовательских Группировок (User Grouping Set). Это еще один Хаб (с названием Big Trucks) со Спутником, описывающим номера VIN, группируемые под этим лейблом, и Связь с номерами VIN. Таким образом, сохранены оригинальные данные из исходной системы, в то же время можно получить информацию в манере, соответствующей пользовательским потребностям. Когда все будет сказано и сделано, хранилище данных является успешным, так как оно отвечает потребностям пользователей.

5.0 Основы архитектуры Data Vault

Архитектура уходит корнями в математику сокращения избыточности. Спутники предназначены только для хранения дельты или изменившейся информации. Если один из спутников начинает быстро расти, очень легко создать два новых спутника и запустить процесс, разделяющий дельту; процесс, который будет разделять информацию в два новых спутника, каждый процесс выполняет другой дельта-процесс перед вставкой новых строк. Этот процесс может сократить процент дублирования колоночных данных до минимума. Это приравнивается к использованию меньшего объема хранения. Спутники по своей природе могут быть очень длинными, и в большинстве случаев узкими (имеют не много столбцов). Для сравнения, измерения 2-го типа могут реплицировать данные во многих столбцах, делать копии информации снова и снова, а также создавая новые ключи.

Хабы хранят по одному экземпляру бизнес ключа. Бизнес ключи, как правило, имеют очень низкую склонность к изменениям. Поэтому суррогатные ключи отображаются один к одному на бизнес ключи (если используются суррогаты) и никогда не меняются. Первичный ключ Хаба (независимо от типа — бизнес или суррогатный) является единственным компонентом информации, реплицированным между Спутниками и Связями. Поэтому Спутники всегда привязываются непосредственно к бизнес ключу. Таким образом, Спутникам отводится роль описывать бизнес ключи на наиболее доступном детальном уровне. Это обеспечивает основу для развития контекста, описывающего бизнес.

Другим уникальным результатом Data Vault является возможность динамически представлять отношения. Отношения создаются структурой Связей сразу же как «ассоциированные» бизнес ключи поступают из источника данных. Эта связь существует, пока они не датированы датой окончания (в Спутнике), либо не удалены из набора данных полностью. Тот факт, что эти отношения представлены таким образом, открывает новые возможности в области динамического создания отношений. Если в результате интеллектуального анализа данных обнаружены новые отношения между двумя хабами (или их контекстом), то новые Связи могут быть сформированы автоматически.

Кроме того, структуры Связи и информация могут быть отмечены конечной датой или удалены, когда они утратят свою актуальность. Например: сегодня компания продает продукцию, и имеет таблицу связи между продуктами и счетами-фактурами. Завтра, они начинают продавать услуги. Это очень просто реализуется, путем создания Хаба «Услуги» и связи между счетами и услугами, затем все отношения между товарами и счетами-фактурами датируются как оконченные. В этом примере, процесс изменения модели данных можно начать исследовать с программной точки зрения. Если это автоматизировать, то можно будет динамически изменять и адаптировать структуру хранилища данных, чтобы удовлетворить потребности деловых пользователей.

Темпы изменения и сокращение избыточности наряду с гибкостью потенциально неограниченных динамических изменений отношений формируют мощную основу. Эти слагаемые открывают двери применению структур Data Vault для множества различных целей.

6.0 Возможные применения Data Vault

Благодаря фундаментальности может быть рассмотрено много различных приложений Data Vault. Некоторые из них уже разработке. Небольшой перечень этих возможностей ниже:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *