Основы Data Vault

[am-habr]

Хороший пост про основы этой новой методологии. Три года назад мне повезло её опробовать.
Результат в сравнении с хранением в нормальной форме (по Инмону, где нормализуются сущности в централизованных хранилищах):

• объектов в базе нужно примерно в два раза больше -> больше ресурсов для поддержки
• создавать вручную объекты HUB, LINK и SAT очень сложно, возникает много ошибок, которые нужно искать и исправлять -> нужно сначала создать фреймворк для автоматической генерации объектов и процедур загрузки. Кто-нибудь встречал готовые? Я не нашёл.
• На базе raw data vаult создаём историческое измерение для отчёта — в реляционной базе происходит cartesian product. Да, мы знаем, что набор комбинаций ограничен, но связи n:m энтерпрайз-сущностей в недельном промежутке времени вводит базу данных в невыводимый ступор.
• Для решения этой проблемы придумали бизнес data vаult — это ещё один уровень абстракции, не отменяющий витрину данных (data mart), потому что он всё ещё медленный. Уровень абстракции добавляет объектов и усложняет поиск ошибок в логике бизнес процессов.
• Бизнес анализ на базе business data vault получается весьма неэффективным. Причина: источники данных разлагаются на простые формы HUB, LINK и SAT. На следующем уровне снова воссоздаётся бизнес логика.
  Например, в отчёте вы видите ошибку и спускаетесь по-уровням хранилища до data vault, а тут нет бизнес логики, проследить ошибку часто бывает невозможным.

Всё ещё считаю, что самая дешёвая и эффективная методология от Кимбалла.

[ASenterprise]

Спасибо за ваш комментарий.

Все сказанное верно:

• Если есть возможность выстроить хранилище на RDBMS, эффективнее использовать Кимбалла;
  
• Без витрин не обойтись;
• Аналитика со стороны бизнес-пользователей, это условность, но для них есть BI

Думаю, что Data Vault — история про Big Data, я сталкивался с таким подходом на databricks.
Но тем не менее обозначенная методология существует и дополнительная информация не будет лишней.