Закрыть
МЕНЮ
Отличие DataVault 2.0 от 1.0
МЕНЮ
Статья для тех, кто в какой-то момент времени задумался: «А чем DataVault 2.0 отличается от первой версии?» Вторая версия появилась аж через 15 лет после выхода первой и несла в себе кардинальные отличия. Это была попытка адаптировать методологию DataVault под современные подходы и технологии – в особенности под MPP СУБД, которые массово стали использоваться для построения масштабных аналитических решений. Была ли это успешная попытка?
Использование Hash-ключей
Самым заметным отличием стала, на мой взгляд, гениальная по своей простоте идея – вычислять суррогатные ключи в качестве hash-значений. Как было раньше? Классический подход – генерировать (обычно банальным автоинкрементом + 1) суррогатный ключ и сохранять соответствие суррогатного ключа и натурального ключа в hub.
Но у него есть значительные ограничения. Первое заключается в том, что в ETL hub, satellite, link приходится делать join на hub, чтобы вытащить суррогатный ключ. Сами понимаете, дополнительный join может замедлить (в некоторых случаях весьма замедлить) время отработки ETL. А теперь представьте, что у вас сотни, а то и тысячи хабов и сателлитов, следовательно тысячи дополнительных join.
Хотя дополнительные join еще полбеды. Главная же проблема состоит в том, при таком подходе вам требуется последовательно сначала обновлять hub, потом link и satellite. Потому что суррогатные ключи генерируются и записываются именно в hub, что вызывает зависимость link и satellite от hub.
Хэш-ключи позволяет же запускать все ETL в параллель, так как хэш-значение натурального ключа рассчитывается на лету.
Отличие DataVault 2.0 от 1.0
Естественно, у такого подхода есть минусы:
• Риск коллизии. MD5 больше подвержен коллизиям, но зато занимает меньше места и рассчитывается быстрее, в отличие от SHA.
• Скорость join. Целочисленные ключи в памяти занимают меньше места, а следовательно (в теории) по ним join будет проходить быстрее.
Business Vault
С версией 2.0 появляется понятие Business Vault и Raw Vault.
Raw Vault – слой сырых данных. Более привычное определение – STAGE слой. Загруженные с источника данные без каких-либо преобразований.
Business Vault уже слой преобразованных данных: с рассчитанными показателями, фильтрами и т.д.
Одним из существенных недостатков классического DataVault является сложность для аналитиков в части написания запросов. Именно поэтому Business Vault был расширен новыми типами таблиц:
- PIT
- Bridge
- Reference
При join-е на версионный сателлит и получения актуальной версии данных потребуется сперва с помощью оконной функции в подзапросе вычислить дату окончания действия записи (effective_to_dttm). Это весьма трудоемко, особенно если речь заходит про множество join. Я уже не говорю про скорость отработки таких запросов, если речь касается больших объемов данных.
Решением для этого стали PIT-таблицы.
Для упрощения таких запросов используется PIT-таблица — она формируется при загрузке данных и позволяет получать актуальные значения без сложных вложенных запросов.
Такую структуру имеет PIT-таблица и представляет собой указание значений актуальных дат для каждого сателлита на каждый момент времени (PIT_LDTS). Тем самым можно просто заджойнится на PIT-таблицу, чтобы определить актуальную дату для конкретного сателлита и ключа и не писать оконные функции.
Bridge-таблицы также призваны упростить и ускорить SQL-запросы. Они имеют следующую структуру.
Это по сути своей связка разных бизнес-сущностей в одной таблице, чтобы не писать множество join к link-таблицам. Чем-то напоминает всем знакомые таблицы фактов из звездочки, не правда ли?
Reference
Тут и объяснять нечего – это обычные справочники (города, валюты, категории т.д.) для которых не требуются заморачиваться и разбивать их на хабы и сателлиты. Возвращение к 3-ей нормальной форме.
закажите
демо-версию
datapulse
оставьте ваши контакты и наш менеджер свяжется с вами
Закрыть
Получить бесплатный доступ к DataPulse
Наш менеджер свяжется с вами для предоставления бесплатного доступа и презентует наш сервис
Made on
Tilda