Data vault что это

Введение в Data Vault

Большинство компаний сегодня накапливают различные данные, полученные в процессе работы. Часто данные приходят из различных источников — структурированные и не очень, иногда в режиме реального времени, а иногда они доступны в строго определенные периоды. Все это разнообразие нужно структурированно хранить, чтоб потом успешно анализировать, рисовать красивые отчеты и вовремя замечать аномалии. Для этих целей проектируется хранилище данных (Data Warehouse, DWH).

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

Кому будет интересна эта статья?

• Ищете более функциональную альтернативу схеме «звезды» и Третьей Нормальной Форме?
• У Вас уже есть хранилище данных, но его тяжело дорабатывать?
• Нужна хорошая поддержка историчности, а текущая архитектура для этого не подходит?
• Возникают проблемы при сборе данных из нескольких источников?

Data Vault состоит из трех основных компонентов — Хаб (Hub), Ссылка (Link) и Сателлит (Satellite).

Хаб — основное представление сущности (Клиент, Продукт, Заказ) с позиции бизнеса. Таблица-Хаб содержит одно или несколько полей, отражающих сущность в понятиях бизнеса. В совокупности эти поля называются «бизнес ключ». Идеальный кандидат на звание бизнес-ключа это ИНН организации или VIN номер автомобиля, а сгенерированный системой ID будет наихудшим вариантом. Бизнес ключ всегда должен быть уникальным и неизменным.
Хаб так же содержит мета-поля load timestamp и record source, в которых хранятся время первоначальной загрузки сущности в хранилище и ее источник (название системы, базы или файла, откуда данные были загружены). В качестве первичного ключа Хаба рекомендуется использовать MD5 или SHA-1 хеш от бизнес ключа.

Ссылка

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

Сателлит

Все описательные атрибуты Хаба или Ссылки (контекст) помещаются в таблицы-Сателлиты. Помимо контекста Сателлит содержит стандартный набор метаданных (load timestamp и record source) и один и только один ключ «родителя». В Сателлитах можно без проблем хранить историю изменения контекста, каждый раз добавляя новую запись при обновлении контекста в системе-источнике. Для упрощения процесса обновления большого сателлита в таблицу можно добавить поле hash diff: MD5 или SHA-1 хеш от всех его описательных атрибутов. Для Хаба или Ссылки может быть сколь угодно Сателлитов, обычно контекст разбивается по частоте обновления. Контекст из разных систем-источников принято класть в отдельные Сателлиты.

Как с этим работать?

* Картинка основана на иллюстрации из книги Building a Scalable Data Warehouse with Data Vault 2.0

Сначала данные из операционных систем поступают в staging area. Staging area используется как промежуточное звено в процессе загрузки данных. Одна из основных функций Staging зоны это уменьшение нагрузки на операционные базы при выполнении запросов. Таблицы здесь полностью повторяют исходную структуру, но любые ограничения на вставку данных, вроде not null или проверки целостности внешних ключей, должны быть выключены с целью оставить возможность вставить даже поврежденные или неполные данные (особенно это актуально для excel-таблиц и прочих файлов). Дополнительно в stage таблицах содержатся хеши бизнес ключей и информация о времени загрузки и источнике данных.

После этого данные разбиваются на Хабы, Ссылки и Сателлиты и загружаются в Raw Data Vault. В процессе загрузки они никак не агрегируются и не пересчитываются.

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

b_sat_order_total_price

Когда нужные таблицы созданы и заполнены, наступает очередь витрин данных (Data Marts). Каждая витрина это отдельная база данных или схема, предназначенная для решения задач различных пользователей или отделов. В ней может быть специально собранная «звезда» или коллекция денормализованных таблиц. Если возможно, таблицы внутри витрин лучше делать виртуальными, то есть вычисляемыми «на лету». Для этого обычно используются SQL представления (SQL views).

Заполнение Data Vault

Здесь все довольно просто: сначала загружаются Хабы, потом Ссылки и затем Сателлиты. Хабы можно загружать параллельно, так же как и Сателлиты и Ссылки, если конечно не используется связь link-to-link.

Есть вариант и вовсе выключить проверку целостности и загружать все данные одновременно. Как раз такой подход соответствует одному из основных постулатов DV — «Загружать все доступные данные все время (Load all of the data, all of the time)» и именно здесь играют решающую роль бизнес ключи. Суть в том, что возможные проблемы при загрузке данных должны быть минимизированы, а одна из наиболее распространенных проблем это нарушение целостности. Подход, конечно, спорный, но лично я им пользуюсь и нахожу действительно удобным: данные все равно проверяются, но после загрузки. Часто можно столкнуться с проблемой отсутствия записей в нескольких Хабах при загрузке Ссылок и последовательно разбираться, почему тот или иной Хаб не заполнен до конца, перезапуская процесс и изучая новую ошибку. Альтернативный вариант — вывести недостающие данные уже после загрузки и увидеть все проблемы за один раз. Бонусом получаем устойчивость к ошибкам и возможность не следить за порядком загрузки таблиц.

Преимущества и недостатки

[+] Гибкость и расширяемость.
С Data Vault перестает быть проблемой как расширение структуры хранилища, так и добавление и сопоставление данных из новых источников. Максимально полное хранилище «сырых» данных и удобная структура их хранения позволяют нам сформировать витрину под любые требования бизнеса, а существующие решения на рынке СУБД хорошо справляются с огромными объемами информации и быстро выполняют даже очень сложные запросы, что дает возможность виртуализировать большинство витрин.
[+] Agile-подход из коробки.
Моделировать хранилище по методологии Data Vault довольно просто. Новые данные просто «подключаются» к существующей модели, не ломая и не модифицируя существующую структуру. При этом мы будем решать поставленную задачу максимально изолированно, загружая только необходимый минимум, и, вероятно, наша временнáя оценка для такой задачи станет точнее. Планирование спринтов будет проще, а результаты предсказуемы с первой же итерации.
[–] Обилие JOIN’ов
За счет большого количества операций join запросы могут быть медленнее, чем в традиционных хранилищах данных, где таблицы денормализованы.
[–] Сложность.
В описанной выше методологии есть множество важных деталей, разобраться в которых вряд ли получится за пару часов. К этому можно прибавить малое количество информации в интернете и почти полное отсутствие материалов на русском языке (надеюсь это исправить). Как следствие, при внедрении Data Vault возникают проблемы с обучением команды, появляется много вопросов относительно нюансов конкретного бизнеса. К счастью, существуют ресурсы, на которых можно задать эти вопросы. Большой недостаток сложности это обязательное требование к наличию витрин данных, так как сам по себе Data Vault плохо подходит для прямых запросов.
[–] Избыточность.
Довольно спорный недостаток, но я часто вижу вопросы об избыточности, поэтому прокомментирую этот момент со своей точки зрения.

Многим не нравится идея создания прослойки перед витринами данных, особенно если учесть, что таблиц в этой прослойке примерно в 3 раза больше, чем могло бы быть в третьей нормальной форме, а значит в 3 раза больше ETL-процессов. Это так, но и сами ETL процессы будут значительно проще за счет своего однообразия, а все объекты в хранилище достаточно просты для понимания.

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

Что такое Data Vault: моделирование КХД для архитектора Big Data

Вчера мы рассмотрели, что такое Data Vault, почему возникла эта модель и чем она полезна при проектировании архитектуры корпоративных хранилищ данных (КХД) и озер данных (Data Lake). Сегодня разберем ключевые понятия Data Vault и поговорим про возможности Data Vault 2.0 для области больших данных (Big Data).

Ключевые понятия Data Vault

Напомним, Data Vault — это один из методов моделирования данных, который используется при проектировании КХД. Этот гибридный подход, впервые представленный в 2000 году, объединяет достоинства схемы «звезды» и 3-ей нормальной формы. Данный метод был придуман Дэном Линстедтом (Dan Linstedt) в процессе разработки Data Warehouse (DWH) для Министерства Обороны США и хорошо себя зарекомендовал на практике. В 2013 году Дэн Линстедт анонсировал новую версию подхода, Data Vault 2.0, доработанную с учетом технологий Big Data (NoSQL, Apache Hadoop) и новых требований к современному DWH [1].

Для сохранения простоты дизайна и обеспечения максимальной гибкости КХД используется минимум базовых понятий [2]:

· Хаб (Hub) — таблица, хранящая основное представление бизнес-сущности с функциональной позиции предметной области, например, Клиент, Продукт, Заказ и пр. Хаб содержит уникальный и неизменный бизнес-ключ — одно или несколько полей, идентифицирующих сущность в понятиях бизнеса. При потере бизнес-ключа теряется ссылка на контекст или окружающую информацию. Помимо бизнес-ключа хаб содержит мета-поля: время первоначальной загрузки сущности в хранилище (load timestamp) и ее источник (record source) — название системы, базы или файла, откуда были взяты данные. В качестве первичного ключа Хаба рекомендуется хэш бизнес-ключа, сгенерированный с помощью алгоритмов MD5 или SHA-1.

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

· Спутник (Satellite) — таблица с контекстной (описательной) информацией ключа Хаба. Для обеспечения гибкости структура Спутников должна позволять хранить новые или измененные детальные данные. Кроме единственного ключа родительского хаба и его контекстных данных таблица-Спутник также содержит типовой набор метаданных: load timestamp и record source. Таким образом, в Спутниках можно хранить историю изменения контекста, добавляя новую запись при обновлении в системе-источнике. Чтобы упростить процесс обновления большой таблицы-сателлита можно добавить в нее поле хэш-слепок (HashDiff), полученный с помощью алгоритмов MD5 или SHA-1 от всех его описательных атрибутов. По сути, HashDiff — это хэш-функция, применённая к набору бизнес-атрибутов из таблицы-Спутника. Контекст из разных систем-источников принято хранить в отдельных таблицах-Спутниках.

Таблицы Data Vault: хабы, ссылки, спутники

Как смоделировать Хабы, Связи и Спутники: правила построения модели

Модель Data Vault создается по следующему алгоритму [2]:

определение Хабов на основе ключевых бизнес-сущностей и их использованию в предметной области; определение Ссылок через выявление возможных отношений между бизнес-ключами — и понимание контекста его работы; определение Спутников — моделирование контекста каждой бизнес-сущности и транзакции (Ссылки), соединяющий Хабы; моделирование point-in-time таблиц, производных от Спутников.

При этом необходимо придерживаться следующих ссылочных правил [2]:

ключи Хабов не могут мигрировать в другие Хабы, чтобы не нарушать гибкость и расширяемость техники моделирования Data Vault; Бизнес-ключи и первичные ключи Хаба никогда не меняются; Хабы связываются только с помощью сущностей типа Ссылка; Ссылка должна связывать не менее двух Хабов и может связываться с другими сущностями типа Ссылка; Суррогатные ключи могут использоваться в Хабах и Ссылках, но не в Спутниках; Ключи Хаба всегда мигрируют в Ссылки и дочерний Спутник с контекстными данными; Спутник может быть связан с Хабами и с Ссылками; Спутник всегда содержит временную метку даты загрузки (Load Date Time Stamp) или числовой внешний ключ, ссылающийся на автономную таблицу с последовательностью временных меток, например, календарь; Если Хаб имеет 2 или более Спутника, для удобства операций объединения (join) можно создать point-in-time таблицу; Спутники фиксируют только изменения без дублирования строк; Данные распределяются по структуре Спутников на основе типа информации и темпах ее изменения.

Дата Волт для Big Data: итоги версии 2.0

Вышеописанные правила моделирования, на первый взгляд, поддерживают только реляционную парадигму, которая не слишком коррелирует с большими данными. Однако, несмотря на часто используемое в Data Vault понятие «таблица», термин сущность скорее соответствует документу в документо-ориентированных NoSQL-СУБД [3]. Кроме того, как мы уже отметили, версия Data Vault 2.0 привнесла следующие важные для Big Data нововведения [4]:

· возможность распараллеливания загрузки ядра КХД, что позволяет использовать массивно-параллельную архитектуру (massive parallel processing, MPP) для повышения производительности;

· использование суррогатного хеш-ключа как основного способа идентификации объектов вместо инкрементальных ID. Так идентификатор строится на основе входных, а не уже имеющихся, данных. Кроме того, использование хеш-ключей позволяет напрямую интегрироваться с NoSQL-СУБД, где хеш-ключи идентифицируют объекты.

Наконец, примечательно, что методология Data Vault 2.0, как и лучшие практики Big Data, поддерживают Agile-принципы и популярные подходы управления качеством: 6 сигм, TQM и SDLC. В частности, проекты Data Vault должны иметь короткий, управляемый цикла релиза длительностью 2–3 недели. Кроме того, команды, использующие методологию Data Vault, должны легко адаптироваться к повторяемым, последовательным и измеримым проектам, соответствующим 5-му уровню модели управленческой зрелости CMMI. Благодаря этому корпоративные данные в DWH будут следовать жизненному циклу TQM (полное управление качеством, Total Quality Management), обеспечивая выполнение процессов Data Governance [5]. Например, идея метаданных (time stamp и record source), а также отслеживаемых дельт изменений в таблицах-спутниках поддержана в понятиях lineage и provenance, о которых мы рассказывали здесь.

В следующей статье мы рассмотрим особенности ETL-процессов по методу Data Vault и поговорим про достоинства и недостатки этой концепции. А технические подробности организации КХД и Data Lake для эффективного хранения больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Развитие 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 таблица:

Таким образом у нас есть информация об актуальности данных по всем сателлитам на каждый момент времени. Используя 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 modeling

Моделирование хранилища данных — это метод моделирования базы данных, предназначенный для получения долгосрочных хронологических данных. хранение данных, поступающих из нескольких операционных систем. Это также метод просмотра исторических данных, который касается таких вопросов, как аудит, отслеживание данных, скорость загрузки и устойчивость к изменениям, а также подчеркивает необходимость отслеживания происхождения всех данных в базе данных. Это означает, что каждая строка строка в хранилище данных должна сопровождаться атрибутами источника записи и даты загрузки, что позволяет аудитору отслеживать значения до источника. Он был разработан в 2000 году.

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

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

Содержание

• 1 История и философия
  • 1.1 История
  • 1.2 Альтернативные интерпретации
  • 2.1 Хабы
    • 2.1.1 Пример хаба
    • 2.2.1 Пример связи
    • 2.3.1 Пример спутника
    • 2.4.1 Справочный пример
    • 7.1 Цитирования
    • 7.2 Источники

    История и философия

    В хранилище данных Моделирование существует два хорошо известных конкурирующих варианта моделирования слоя, на котором хранятся данные. Либо вы моделируете в соответствии с Ральфом Кимбаллом, с согласованными размерами и корпоративной шиной данных, либо вы моделируете в соответствии с Биллом Инмоном с базой данных нормализованной. У обоих методов есть проблемы при работе с изменениями в системах, питающих хранилище данных. Для согласованных размеров вам также необходимо очистить данные (чтобы согласовать их), и это нежелательно в ряде случаев, поскольку это неизбежно приведет к потере информации. Хранилище данных предназначено для предотвращения или сведения к минимуму воздействия этих проблем путем перемещения их в области хранилища данных, которые находятся за пределами области исторического хранения (очистка выполняется в витринах данных) и путем разделения структурных элементов (бизнес-ключи и ассоциации между бизнес-ключами) из описательных атрибутов.

    Дэн Линстедт, создатель метода, описывает получившуюся базу данных следующим образом:

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

    Философия Data vault заключается в том, что все данные являются релевантными данными, даже если они не соответствуют установленным определениям и бизнес-правилам. Если данные не соответствуют этим определениям и правилам, то это проблема для бизнеса, а не для хранилища данных. Определение «неверных» данных — это интерпретация данных, основанная на определенной точке зрения, которая может не быть действительной для всех или в любой момент времени. Следовательно, хранилище данных должно захватывать все данные, и только при составлении отчета или извлечении данных из хранилища данные интерпретируются.

    Другая проблема, на которую отвечает хранилище данных, заключается в том, что все больше и больше возникает потребность в полной проверяемости и отслеживаемости всех данных в хранилище данных. Из-за требований Сарбейнса-Оксли в США и аналогичных мер в Европе это актуальная тема для многих реализаций бизнес-аналитики, поэтому в центре внимания любой реализации хранилища данных является полная прослеживаемость и проверяемость всей информации.

    Data Vault 2.0 — это новая спецификация, это открытый стандарт. Новая спецификация содержит компоненты, которые определяют передовой опыт реализации, методологию (SEI / CMMI, Six Sigma, SDLC и т. Д.), Архитектуру и модель. Data Vault 2.0 ориентирован на включение новых компонентов, таких как Big Data, NoSQL, а также на производительность существующей модели. Старая спецификация (по большей части задокументированная здесь) сосредоточена на моделировании хранилищ данных. Это описано в книге: Создание масштабируемого хранилища данных с помощью Data Vault 2.0.

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

    История

    Моделирование хранилища данных было первоначально задумано Дэном Линстедтом в 1990-х годах и было выпущено в 2000 году как метод моделирования общественного достояния. В серии из пяти статей в информационном бюллетене администрирования данных расширены и объяснены основные правила метода Data Vault. Они содержат общий обзор, обзор компонентов, обсуждение конечных дат и объединений, таблицы ссылок и статью о методах загрузки.

    Альтернативное (и редко используемое) название метода — «Общее Базовая архитектура моделирования интеграции ».

    Data Vault 2.0 появился на сцене в 2013 году и предлагает большие данные, NoSQL, неструктурированную, полуструктурированную бесшовную интеграцию, а также наилучшую методологию, архитектуру и реализацию. практики.

    Альтернативные интерпретации

    Согласно Дэну Линстедту, Модель данных основана на упрощенном представлении о нейронах, дендритах и ​​синапсах, где нейроны связаны с концентраторами и сателлитами-концентраторами., Ссылки — это дендриты (векторы информации), а другие Ссылки — это синапсы (векторы в противоположном направлении). Используя набор алгоритмов интеллектуального анализа данных, ссылки можно оценивать по степени уверенности и прочности. Их можно создавать и удалять на лету в соответствии с изучением отношений, которых в настоящее время не существует. Модель может быть автоматически преобразована, адаптирована и скорректирована по мере ее использования и загрузки новых структур.

    Еще одно мнение состоит в том, что модель хранилища данных предоставляет онтологию предприятия в том смысле, что он описывает термины в домене предприятия (концентраторы) и отношения между ними (ссылки), при необходимости добавляя описательные атрибуты (сателлиты).

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

    Основные понятия

    Простая модель хранилища данных с двумя концентраторами (синий), одним каналом (зеленый) и четырьмя спутниками (желтый)

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

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

    Концентраторы

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

    Хаб содержит как минимум следующие поля:

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

    Хабу не разрешается содержать несколько бизнес-ключей, за исключением случаев, когда две системы предоставляют один и тот же бизнес-ключ, но с конфликтами, имеющими разные значения.

    Концентраторы обычно должны иметь хотя бы один спутник.

    Пример концентратора

    Это пример таблицы концентраторов, содержащей автомобили, под названием «Автомобиль» (H_CAR). Ключ вождения: идентификационный номер автомобиля.

    Имя поля	Описание	Обязательное?	Комментарий
    H_CAR_ID	Идентификатор последовательности и суррогат ключ для концентратора	No	Рекомендуемый, но необязательный
    VEHICLE_ID_NR	Бизнес-ключ, который управляет этим концентратором. Может быть более одного поля для составного бизнес-ключа	Да
    H_RSRC	Источник записи этого ключа при первой загрузке	Да
    LOAD_AUDIT_ID	Идентификатор в таблице с информацией аудита, такой как время загрузки, продолжительность загрузки, количество строк и т. Д.	Нет

    Ссылки

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

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

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

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

    Пример ссылки

    Это пример таблицы ссылок между двумя концентраторами для автомобилей (H_CAR) и людей (H_PERSON). Ссылка называется «Драйвер» (L_DRIVER).

    Имя поля	Описание	Обязательно?	Комментарий
    L_DRIVER_ID	Идентификатор последовательности и суррогатный ключ для ссылки	No	Рекомендуется, но необязательно
    H_CAR_ID	суррогатный ключ для автомобильного концентратора, первый якорь ссылки	Да
    H_PERSON_ID	суррогатный ключ для персонального концентратора, второй якорь ссылки	Да
    L_RSRC	Источник записей этой связи при первой загрузке	Да
    LOAD_AUDIT_ID	Идентификатор в таблице с аудиторской информацией, такой как время загрузки, продолжительность загрузки, количество линий и т. д.	No

    Сателлиты

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

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

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

    Пример сателлита

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

    Имя поля	Описание	Обязательно?	Комментарий
    S_DRIVER_INSURANCE_ID	Идентификатор последовательности и суррогатный ключ для спутника на канале	No	Рекомендуемый, но необязательный
    L_DRIVER_ID	(суррогатный) первичный ключ для ссылки на драйвер, родительский для сателлита	Да
    S_SEQ_NR	Порядковый или порядковый номер, для обеспечения уникальности при наличии нескольких допустимых спутников для одного родительского ключа	Нет (**)	Это может произойти, если, например, у вас есть хаб COURSE, а название курса атрибут, но на нескольких разных языках.
    S_LDTS	Дата загрузки (начальная дата) для действительности этой комбинации значений атрибутов для родительского ключа L_DRIVER_ID	Да
    S_LEDTS	Дата окончания загрузки (конечная дата) для действительности этой комбинации значений атрибутов для родительского ключа L_DRIVER_ID	Нет
    IND_PRIMARY_DRIVER	Индикатор, является ли водитель основным водителем для этой машины	Нет ( *)
    INSURANCE_COMPANY	Название страховой компании для этого транспортного средства и этого водителя	Нет (*)
    NR_OF_ACCIDENTS	Количество ДТП по этому водитель в этом транспортном средстве	Нет (*)
    R_RISK_CATEGORY_CD	Категория риска для водителя. Это ссылка на R_RISK_CATEGORY	Нет (*)
    S_RSRC	Источник записей информации в этом сателлите при первой загрузке	Да
    LOAD_AUDIT_ID	Идентификатор в таблице с аудиторской информацией, такой как время загрузки, продолжительность загрузки, количество строк и т. Д.	Нет

    (*) по крайней мере один атрибут является обязательным. (**) порядковый номер становится обязательным, если он необходим для обеспечения уникальности нескольких допустимых спутников на одном концентраторе или канале.

    Справочные таблицы

    Справочные таблицы — обычная часть исправной модели хранилища данных. Они предназначены для предотвращения избыточного хранения простых справочных данных, на которые часто ссылаются. Более формально Дэн Линстедт определяет справочные данные следующим образом:

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

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

    Справочный пример

    Это пример справочной таблицы с категориями риска для водителей транспортных средств. На него можно ссылаться с любого спутника в хранилище данных. Пока мы ссылаемся на него со спутника S_DRIVER_INSURANCE. Справочная таблица — R_RISK_CATEGORY.

    Имя поля	Описание	Обязательно?
    R_RISK_CATEGORY_CD	Код для категории риска	Да
    RISK_CATEGORY_DESC	Описание категории риска	Нет (*)

    (*) по крайней мере один атрибут является обязательным.

    Практика загрузки

    ETL для обновления модели хранилища данных довольно прост (см. Data Vault Series 5 — Loading Practices). Сначала вам нужно загрузить все концентраторы, создав суррогатные идентификаторы для любых новых бизнес-ключей. Сделав это, вы можете преобразовать все бизнес-ключи в суррогатные идентификаторы, если запросите концентратор. Второй шаг — разрешить связи между концентраторами и создать суррогатные идентификаторы для любых новых ассоциаций. В то же время вы также можете создать все спутники, подключенные к концентраторам, поскольку вы можете разрешить ключ в суррогатный идентификатор. После того, как вы создали все новые ссылки с их суррогатными ключами, вы можете добавить спутники ко всем ссылкам.

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

    ETL довольно прост и легко поддается автоматизации или шаблону. Проблемы возникают только со ссылками, относящимися к другим ссылкам, поскольку разрешение бизнес-ключей в ссылке приводит только к другой ссылке, которую также необходимо разрешить. Из-за того, что эта ситуация эквивалентна связи с несколькими концентраторами, этой трудности можно избежать, изменив такие случаи, и это, по сути, рекомендуемая практика.

    Данные никогда не удаляются из хранилища данных, если вы не техническая ошибка при загрузке данных.

    Хранилище данных и многомерное моделирование

    Смоделированный слой хранилища данных обычно используется для хранения данных. Он не оптимизирован для производительности запросов, и его нелегко выполнять с помощью хорошо известных инструментов запросов, таких как Cognos, OBIEE, SAP Business Objects, Pentaho и др. Поскольку эти вычислительные инструменты для конечных пользователей ожидают или предпочитают, чтобы их данные содержались в размерной модели, преобразование обычно необходимо.

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

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

    Методология хранилища данных

    Методология хранилища данных основана на передовых практиках SEI / CMMI уровня 5. Он включает в себя несколько компонентов CMMI уровня 5 и объединяет их с лучшими практиками из Six Sigma, TQM и SDLC. В частности, он ориентирован на гибкую методологию построения и развертывания Скотта Амблера. У проектов хранилищ данных короткий цикл выпуска с контролируемой областью, который должен состоять из производственного выпуска каждые 2–3 недели.

    Команды, использующие методологию хранилища данных, должны легко адаптироваться к повторяемым, согласованным и измеримым проектам, которые ожидаются на уровне 5 CMMI. Данные, проходящие через систему хранилища данных EDW, начнут соответствовать TQM (общее качество управление) жизненный цикл, который давно отсутствует в проектах BI (бизнес-аналитики).