статью еще не читал, но мне кажется наоборот DV всё чаще выбирают при построении dwh

Где то в МСК и СПб может быть)

важное замечание

"Я Пастернака не читал, но осуждаю"

если честно то лучше в оригинале
https://www.vertabelo.com/blog/data-vault-series-data-vault-2-0-modeling-basics/

Data Vault Data Modeling Standards v2.0.1 | Accelerated Business Intelligence
https://danlinstedt.com/allposts/datavaultcat/data-vault-data-modeling-standards-v2-0-1/

2.0.1 only insert data vault

Выбирают гибриды. DV не очень хорошо ложится в MPP систем, у которых shared nothing подход к расчётам.

Митя, можно поподробнее ? может ссылочку на какую нибудь статью

Зато в мердж джоин отлично ложится

Можно.
Давай представим, что мы соберёмся делать классический DV в MPP.
У него есть несколько свойств, которые на мой, да и видимо не только на мой взгляд, не нужны в MPP.
Во-первых - хэши в качестве ключей.
Самый их большой плюс - полное расщепление источника в независимых задачах на загрузку H, S, L. Нужно знать только хэш ключа, при этом совершенно не обязательно, чтобы для каждой записи в S была запись в H в каждый момент времени. Ничего не сломается.
Следовательно - можно грузить параллельно.
Самый большой минус - возможное появление дубликатов на "высоких" или "широких" ключах при использовании слабых хэшфункций.
А также кейсы, связанные с хранением натурального ключа в хабе вместе с хэшом, в примерах хренового качества данных - ИНН в ключе лежит месяц, но тут вдруг становится понятно, что он неправильный. И надо как-то поменять (а это значит только перезалить все S_, L_ структуры).

Чтобы избавиться от последнего минуса можно воспользоваться двумя (но может и больше) подходами:
1. Вместо хэша использовать sequence, а при вставке в S_, L_ структуры кодировать id с помощью уже вставленных записей в хаб.
2. Вообще в качетве хаба использовать голый sequence, а натуральный ключ сложить в отдельный сателит (ближе к Anchor).

Оба этих подхода решают минус хэшей, но, разумеется, портят плюс. В теории.
Но на практике, кайфа от параллельной загрузки HSL немного. Особенно если у вас не ночью 1 раз всё грузится, а в течение дня в  real-time микробатчами и все объекты асинхронно. Поэтому для синхронизации надо всё равно выделять кусок инкремента и либо врубать изоляцию на serializable для невозможности записи в источник, либо вручную отслеживать окна загрузки. Но это - точка синхронизации. И она портит картинку с параллельностью немного (но незначительно).

Кроме того, без хэшей и на натуральных ключах в MPP возникает дополнительный позитивный эффект:
* Не надо считать хэши
* Можно одинаково сегменитровать/сортировать данные по нодам у таблиц источника и у целевых сателитов/хабов.

Кстати, в Merge join при использовании нескольких хабов через линк ложится только одно соединение (по дефолту сегментация делается по id/hash хаба). Так что увы, если где-то вылетит две high-cardinality сущности в запросе, всё равно придётся по хэшу лепить.

Дополню, что sequence'ы реализуют более мощный концепт immutable, чем hash натурального ключа.
Один раз объект появился - вы зафиксили id и он действительно не может измениться.
Даже если вы поменяли натуральный ключ потом.

В Anchor modelling даже натуральный ключ является "свойством", которое может легко измениться. При этом никакие связи разрушены не будут.

Кроме этой темы в методологии DV много полезных архитектурных шаблонов, которые можно использовать в любой модели.

хм, мне казалось, до линка должны были мерджи от хабов дойти 🤔

Ну один хаб по своим хэшам лежит, другой по своим

Линк связывает два хэша

Соответственно, если в Vertica, то делают 2 проекции - с сортировкой по одному, вторая - по другому. Оптимизатор сам решит, где использовать MErge join

ааа, ты про направленность, я понял, да