Аа, так он есть во втором?) Век живи, век учись...)

Спасибо за инфу)

Ага. Но у меня тут 2 стула либо 2 но на питоне либо 3 но без этого параметра и в кубе

С учётом количества патчей, которые не включены в ванилла спарк, надо свой спарк собирать)

Кто-нибудь занимался задачей загрузки версионных данных из MDM в Data Vault или Anchor Modelling модель хранилища?
Поясню: есть справочник, ключи которого находятся во временных интервалах с разными значениями.

| key | value_1 | value_2 | value_3 | effective_from_dttm | effective_to_dttm | tstamp  |
|-----|---------|---------|---------|---------------------|-------------------|------------|
| 1   | 1       | 1       | 1       | 01.01.2019          | 01.01.2020        | 01.01.2019 |
| 1   | 1       | 2       | 1       | 01.03.2021          | 31.05.2021        | 01.01.2020 |
| 1   | 1       | 2       | 4       | 01.06.2021          | 31.12.2021        | 01.01.2021 |
| 1   | 1       | 2       | 3       | 01.06.2021          | 31.12.2021        | 01.02.2021 |

С одной стороны казалось бы что можно просто взять и считать дату effective_from_dttm как SCD2 историчность для хранилища,
но что если в MDM системе ошибутся и для существующего интервала изменят какое-то значение атрибута (тогда те же интервалы из MDM придут с новыми значениями и новым tstamp).
Получается что ключем хаба будет поле "key" (дату нельзя добавлять в ключ, т.к. дат MDM системы нет на источниках + на интервалы хочется смотреть под разными бизнес датами), а как уложить саттелиты, когда у них формально может изменяться история что-то ума не приложу.
Историчность по tstamp сделать можно, но тогда PK саллетитов будет ключ + дата (но я что-то таких паттернов при проектировании нигде не видел).
Может кто-то сталкивался с таким?

решайте проблему в месте ее возникновения , а не ее симптомы (последствия)

всмысле? тут нет никакой проблемы

—
но что если в MDM системе ошибутся
—

я имею ввиду когда юзеры MDM в интерфейсе ошибаются со значениями, нельзя человека заставить не ошибаться:)
MDM же не знает сам какое значение правильное, а какое нет

ну вот , и решайте это контролями в MDM

делайте для MDM аналитические отчеты

Все таки чаще MDM в детальном слое моделируют через события, а снимки на разные даты формируют в витринах

Иначе историзм теряется, MDM же мог эти “ошибочные” данные кому то отдавать, а вы в хранилище их не увидите

Ну и плох тот MDM где такой историзм не ведётся

В DV методологии MDM живет отдельно. В Anchor это напрямую не говорится, но по примерам можно заметить, что никто не запрещает образовывать несколько «ядер» с данными.

Если все-таки есть желание перелить, то рекомендую историю не вычислять, как это делается обычно, а реплицировать с источника (MDM).

Ибо вот правильное замечание. Если в MDM такие косяки, то это не MDM 🙈

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

Ну да, я полностью согласен. Тут наверняка просто стоит типичная проблема федеративных обращений. Т.е. MDM живёт в одной базе,  а хранилище в другой. И вот возникает естественное желание сделать так, чтобы MDM был в хранилище.
Я боюсь, что в моей текущей практике, например, это будет сделано именно так. Реплицировать всю модель MDM - это то ещё занятие, очень сложное )) А к организации федеративных SQL, когда часть запроса относящаяся к MDM будет улетать в MDM, обычно требует большей развитости технологической.

Что-то не очень понимаю ваш посыл) т.е. мой кейс - это какой-то неверный юзкейс MDM? А можно поподробней почему?
Мне казалось что атрибуты справочников могут находится в разных состояниях на временных интервалах которые задают пользователи, и логично что они могут ошибиться при заполнении

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

может это больно слышать, но мы живем в мире, в котором с ненулевой вероятностью может произойти любое событие. Вы же не строите свое решение , которое должно восстановиться после  rm -f от пьяного админа ?