Основы Data Vault
В настоящее время, в сфере анализа данных и BI, уже не возможно не встретить такое понятия как DATA VAULT. Однако, на мой взгляд, есть некоторый недостаток информации по этой теме, особенно в русскоязычном сегменте интернета.
Можно найти интересные статьи о применении DATA VAULT в компаниях, однако основы и методология освещены недостаточно.
В англоязычном сегменте, дела обстоят значительно лучше. Можно купить книги авторов-изобретателей методологии DATA VAULT, но есть и статьи в открытом доступе, которые уделяют внимание именно основам.
Будучи вдохновленным одной из таких статей, я попытаюсь передать базовые вещи методологии DATA VAULT на русском языке.
DATA VAULT – истоки
Основной предпосылкой появление DATA VAULT стала возрастающая изменчивость окружающей среды и необходимость быстро реагировать на эти изменения. Например, появляется новый источник данных с нехарактерной до этого момента грануляцией данных в EDW (Enterprise Data Warehouse). Предполагается, что методология DATA VAULT позволит быстрее добавить данные нового источника. Кроме того, использую DATA VAULT легче построить систему, позволяющую хранить исторические данные.
Анатомия DATA VAULT
Важным отличием DATA VAULT от других подходов к построению хранилищ данных является необходимость загрузки данных в идентичном источнику состоянии. Процесс переноса данных из источников в DATA VAULT не предполагает никаких преобразований и дополнений. Подход DATA VAULT подразумевает возможность сверки с источником. Процесс трансформации данных будет осуществлен позже, при построении витрин данных основанных на DATA VAULT.
Концентраторы (HUBS)
HUB являются ядром DATA VAULT. Сформированные должным образом HUB’ы позволяют объединить различные источники данных в вашем корпоративном хранилище. Важно, чтобы источники были независимы. Исходя из этого, каждый HUB должен иметь свой собственный уникальный бизнес ключ (Business Key), не ассоциированный с иными бизнес объектами.
При формировании записей HUB’а не следует использовать суррогатные ключи, ключи должны быть основаны на идентифицируемом бизнес объекте или бизнес объектах.
Идентифицируемым бизнес объектом может являться колонка или совокупность колонок, с помощью которых бизнес может идентифицировать требуемый объект, например, VIN код автомобиля.
Это важнейший аспект методологии DATA VAULT, построение модели должно базироваться на существующих бизнес процессах и соответственно бизнес терминологии и объектах. Такой подход позволит выстроить необходимое для реализации бизнес целей хранилище, а не просто перенести логику существующих источников.
Структура HUB’а очень простая, он содержит:
- Хэш бизнес ключа – первичный ключ;
- Бизнес ключ – уникальный идентификатор бизнес объекта;
- Дату загрузки данных в HUB – это дата, когда запись с обозначенным бизнес ключом впервые попала в DATA VAULT, поле никогда не изменяется и не обновляется;
- Идентификатор источника из которого была загружена информация – показывает из какого источника бизнес ключ пришел впервые, если источников у HUB’а будет несколько.
Связи (LINKS)
Связи – это основа гибкости и способности к масштабированию моделей DATA VAULT. Связи создаются таким образом, чтобы позволить изменять и расширять модель по прошествии времени, добавлять новые объекты и устанавливать новые связи, не изменяя уже существующих и работающих структур и процессов загрузки данных.
В DATA VAULT связи между всеми элементами реализованы посредством LINK’ов. Важно отметить, что HUB’ы не имеют внешних ключей и для связи между ними следует использовать LINK’и. Функция LINK’а заключается в фиксации связи между элементами данных на самом нижнем уровне грануляции.
Другим примером использования LINK’ов являются транзакции, так как транзакции затрагивают несколько HUB’ов.
LINK является таблицей пересечения бизнес ключей нескольких HUB’ов обеспечивающих связь типа многие ко многим. LINK таблица обеспечивающая связь должна иметь как минимум два родительских HUB’а, в случае представления транзакций LINK содержит несколько HUB’ов.
Также, как и HUB LINK таблица имеет простую структуру:
- Первичный ключ он, как правило, формируется из данных соединяемы HUB’ов, например, при объединении страны и региона, ключом LINK’а может быть захэшированное объединение наименования страны и региона;
- Бизнес ключи объединяемых HUB’ов;
- Содержание полей, объединяемых HUB’ов;
- Дата появления связи в системе;
- Источника из которого была загружена информация.
Сателлиты (SATELLITES)
В этой структуре хранятся все описательные, не используемые в ключах, атрибуты. Важной функцией SATELLITE является поддержание истории изменения данных.
Для достижения этих целей первичный ключ состоит из двух частей:
- Первичный ключ родительского HUB’а;
- Дата загрузки данных в SATELLITE — при каждой загрузки данных в SATELLITE необходимо добавлять timestamp.
SATELLITE – единственный элемент имеющих двухкомпонентный ключ.
При необходимости можно добавить источник формирования записи, однако следует отметить, что это не одинаковый с HUB’ом источник, в HUB’ах фиксируется источник первой записи, а в SATELLITE источник каждой записи, который может меняться.
Выводы
Я попытался описать базовые понятия DATA VAULT, его основные элементы, которые в кратце можно охарактеризовать:
- Концентратор (HUB) = таблица содержащая бизнес ключи;
- Связь (LINK) = таблицы для хранения взаимоотношений между сущностями, а также обеспечивающие хранение транзакций;
- Сателлит (SATELLITE) = таблицы хранения характеристик.
HUB — позволяют обеспечить бизнес-ориентированность хранилища и обеспечивают возможность интеграции дополнительных источников данных.
LINK — обеспечивают связь между сущностями.
SATELLITE — хранят характеристики и обеспечивают историческое хранение данных.
Все это в совокупности наделяет DATA VAULT большей чем стандартные подходы к разработке хранилищ данных гибкостью и приспособляемостью, обеспечивает возможностью контроля над данными и их историей, а также позволяет масштабировать хранилище.
Но, как правило DATA VAULT или Raw DATA VAULT, имеет дальнейшее развитие, обусловленное достаточной сложностью аналитических запросов к нему. И следующим этапом эволюции является Business DATA VAULT, здесь уже имеют место дополнительные сущности, такие как: PIT и BRIDGE таблицы. Речь о Business DATA VAULT пойдет в следующих статьях, если эта публикация будет иметь положительный отклик.
Материалы статьи основаны:
- На публикации Кента Грациано, в которой помимо детального описания содержатся схемы модели;
- Книге: «Building a Scalable Data Warehouse with DATA VAULT 2.0».
