Коллеги, кто - нибудь реализовывал data vault 2.0? Насколько удобно было вам?

data vault не для того придумывался чтобы было удобно))

(извините)

Не удачно подобрал слово. При каком размере DWH  оправдано соблюдать этот стандарт? Вообще интересен любой опыт попыток реализации этого стандарта.

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

и, конечно, нормализация не бесплатная, вы заплатите за это производительностью процессов сборки ваших витрин

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

Наоборот

Сбор витрин сократится, за счет уменьшение бизнес-логики, т.к. у вас данные нормализованы

Ну и гибкость

Спасибо за развёрнутые ответы.

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

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

но да, в идеальном мире если мы сразу строим инмоновское ХД - витрины просто делают срез и представление для предметной области уже полностью интегрированных и историзованых данных

классический пример: маркетологи считают клиентов по CRM данным, финансисты по GL, а CEO хочет одно число и предлагает сделать целостное ХД)

Это не проблема хранилища и его нормализация

Не надо из крайности в крайность

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

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

Возможно, но я лично не видел такие хранилища... И я подразумеваю скорее гибрид кимбалла с инмоном 😉