Comments 12
Очень интересно все, что связано с Data Vault, особенно из практики. Спасибо за статью, пишите еще!
А вы коллизии хэшей отслеживаете?
Хранится ли где-нибудь история загрузок в staging слой?
Несколько вопросов:
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 слоя. (код вставки и описание кластера есть в статье)
В целом - одна из основных проблем ,что во многих запросах нужно смотреть вглубь и нет возможности полноценно использовать оптимизации, связанные с партициями
что помогло ?
Ключи для связи (хабы, линки, сателлиты) с одним типом и размерностью.
Используем партиции. Фреймворк имеет механизм управления партициями. Руками не делаем.
Задумывались ли о том чтобы не тащить данные в GP в процесить на озером? Все таки 32 сегмент хоста GP в облаке это дорого
Как мы в Циане готовим Data Vault на GreenPlum