Comments 11
А почему "Звезда и снежинка" у вас — это "нормализация до 3NF" на слайде "Подходы к проектированию"?.. Все же "Звезды и снежинки" — это скорее про витрины и денормализацию, а 3NF — про детальный слой хранилища. Поясните, плз, что вы имели в виду.
fact tables are typically normalized to 3NF in a dimensional
model because the related context is removed to dimension tables. The second step is
to denormalize the remaining tables into flat dimension tables with single-part keys
that connect directly to the fact table; dimension tables most often resemble second
normal form tables with many low cardinality descriptors.
В общем смысле, и измерения можно привести к 3NF, если мы уходим в снежинку\созвездие, но именно поэтому мы старались употреблять «нормализация ДО 3NF» и делали это скорее иллюстративно и обобщающе тем подходам, что вы написали, для контраста по сравнению с более современными.
На видео натыкался, но текст всегда круче).
Зато нашёл глагол «Транскрибировать», значением которого оказалось «Производить транскрипцию».
Значит правильно называется, спасибо.
Дождаться, когда мы это заопенсорсим.
Ждём :-)
Выглядит очень инетерсно. Спасибо за рассказ.
Почему бы ODS не делать историчным? Если вам по каким-то причинам придется заново воссоздать слой, который находится выше и не просто воссоздать, а воссоздать с историей изменения данных в источнике. Если ODS не историчный, то история у вас в верхним слое начнет накапливаться только с момента инициализирующей загрузки DDS.
При дешевом хранении нет никаких препятствий делать ODS историчным. Историчность должна быть настраиваемой те должна быть возможность выбора гранулярности историчности (минуты, часы, дни и тд) в зависимости от природы данных в источнике для любого объекта ODS
Мои слова можно проигнорировать только если у вас из источника приходит вся история изменений сама по себе.
DDS.
По DDS все верно написали. При небольшом кол-ве источников либо при одинаковых источниках DDS слой не нужен. Иначе он просто увеличивает тракт доставки данных.
Но есть и альтернативный вариант — когда DDS слой является частью CDM. При этом в 3NF намеренно вводится денормализация для удобства ad-hoc аналитики — те не требуется дополнительные join операции чтобы что-то подтянуть через соединение, тк все атрибуты избыточно добавлены в сущности.
Судите сами — есть быстрая MPP, есть колоночное хранение с хорошим сжатие, есть прямые руки, которые могут сделать этот «сложный ETL». Сложный с тз обработки инкремента, конечно.
Сейчас многие забывают, что изначальное история с Data Vault появлялась в том числе и из-за ограничения вычислительной мощности СУБД, существовавших на тот момент. Поэтому и была идея — а давайте резать атрибуты по сателлитам с тз их исторической гранулярности, чтобы каждый раз не пересчитывать SCD.
Сейчас, когда проблемы быстрой и масштабируемой обработки по сути нет, стараются приводить аргумент гибкости, при этом почему о забывают, что трудозатраты возрастают кратно, тк в звезду то все равно собирать придется, например, для какого нибудь коробочного аналитического приложения. Стремление идти в DV должны быть целесообразным, а не потому что это «стильно, модно, молодежно»
Спасибо за статью, очень интересно.
Всегда когда читаю про моделирование, сама модель как правило не вызывает вопросов, вопросы вызывает как загружаются данные. Например, каким образом достигается идемпотентность при загрузке.
По идее, чтобы понять, что значение историзированного атрибута изменилось, нужно загрузить новый батч, и потом сделать джойн по значению, что звучит как-то некрасиво и тяжело. Можете дать наводку, как у вас это работает? Где-то во внешней in-memory системе? Или внутри хранилища уже разруливаете? Пишете кастомные скрипты? Или на уровне фреймворка решается?
Как мы внедрили свою модель хранения данных — highly Normalized hybrid Model. Доклад Яндекса