All streams
Search
Write a publication
Pull to refresh

Comments 12

Очень интересно все, что связано с Data Vault, особенно из практики. Спасибо за статью, пишите еще!

А вы коллизии хэшей отслеживаете?

Хранится ли где-нибудь история загрузок в staging слой?

Через row_insert_process_id отслеживаем каждую загрузку и храним в специальной таблице

Несколько вопросов:
1. используете ли для генерации структур и/или ETL фреймворк, или все руками?

2. возможны ли у вас сателлиты на линки?

3. как отслеживаете удаление на источнике?

4. используете ли продвинутые техники: MSAT, REF, PITR и так далее?

1. используете ли для генерации структур и/или ETL фреймворк, или все руками?

Да, для загрузки в каждый слой используем свой кастомный оператор (LoadToStage, LoadToDDS, LoadToDM). Параметром для каждого из них является название yaml файла с конфигом. Сам yaml файл также можно сгенерить. По сути нужно лишь написать sql запрос

2. возможны ли у вас сателлиты на линки?

Технических ограничений нет

3. как отслеживаете удаление на источнике?

В линках можно подключить механизм отслеживания таких записей (через yaml конфиг)

4. используете ли продвинутые техники: MSAT, REF, PITR и так далее?

PITR не используем

REF - да используем. Фреймворк позволяет создавать объекты не только по DV

MSAT - если это про несколько сателлитов для хаба, то у нас ограничений нет

Спасибо за детальный ответ!
Очень хотелось бы от вас более детального рассказа про ваш фреймворк, а не про базу DV.

По удалению, а как с хабами? Если статус трекинг сателлиты?

MSAT - это не несколько сателлитов на хаб, это саттелиты допускающие несколько состояний объекта одновременно (MULTI-ACTIVE SATELLITES), например, не плодя слабые хабы (weak hubs) и линки на них, организовать хранение нескольких телефонных номеров для клиента.

По удалению, а как с хабами? Если статус трекинг сателлиты?

Нет, не используем. Можно джоинить с линком, в котором трекается статус

MSAT - это не несколько сателлитов на хаб, это саттелиты допускающие несколько состояний объекта одновременно (MULTI-ACTIVE SATELLITES), например, не плодя слабые хабы (weak hubs) и линки на них, организовать хранение нескольких телефонных номеров для клиента.

Не используем. В данном случае придется создавать сателлит с ключом Клиент+Тип тел. номера. И в линке связывать

Хотелось бы понять, что помогло и "обо что ударились" при реализации DV именно на Greenplum?

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

Да, через row_number(). На больших сателлитах появляются проблемы. В нашем случае, например, это сателлит с объявлениями, где нужно хранить всю историю.

Ежедневное обновление этого сателлита размером 150 Гб занимает около 15 минут при вставке 3 млн записей из stage слоя. (код вставки и описание кластера есть в статье)

В целом - одна из основных проблем ,что во многих запросах нужно смотреть вглубь и нет возможности полноценно использовать оптимизации, связанные с партициями

что помогло ?

Ключи для связи (хабы, линки, сателлиты) с одним типом и размерностью.

Используем партиции. Фреймворк имеет механизм управления партициями. Руками не делаем.

Да, через row_number(). На больших сателлитах появляются проблемы. В нашем случае, например, это сателлит с объявлениями, где нужно хранить всю историю.

Вот тут PITR должен помочь...

Задумывались ли о том чтобы не тащить данные в GP в процесить на озером? Все таки 32 сегмент хоста GP в облаке это дорого

Sign up to leave a comment.

Articles