Комментарии 8
Не понятно как связан объем поступающих новых данных и Anchor modeling. Классический пример, click stream, данных очень много, и скорее всего это будет одна таблица, никак не нормализованная.
Кажется, большие таблицы противопоказаны для Anchor modeling. База просто их не соединит.
Тезис про значительную экономию места в связи с отсутствием нулевых значений (null) и дублирования у Anchor modeling тоже сомнительный. Это скорее характерно для колочного хранения, и без дублирования ключа у каждого атрибута.
Думаю, Anchor modeling это про небольшие хранилища в смысле объема, но с большим разнообразием атрибутов, их источников и "текучести".
DV не предназначен для того, что бы строить по ней отчёты- это слой хранения данных. Что бы строить отчёты ещё нужен слой представления данных - это витрины. Главная цель DV - хранить данные и историю изменений данных в источнике. Строится она от источника данных, т.е. снизу вверх, строится как "предметно-ориентированое хд" иногда об этом забывают, подходят к моделированию ХД технически, лепят сущности без разбору, видят связь между двумя таблицами - тяп ляп слепили линк, а к линку ведь ещё нужна пара сателлитов но об этом никто не знает. Потом бросают - не получилось, плохая технология давайте по Инмону ХД теперь строить, или даталайк.
Анкер был разработан и впервые применен для страховой компании, где бизнес постоянно рос. Строится она от бизнес-требований к отчётам т.е.сверху вниз.
Есть ещё смесь dv и анкера, ещё её называют голландской моделью данных, применяется для слабосвязанных источников данных.
К минусам якорной модели я бы добавил еще - очень выскую нагрузку на словарь данных. Посчитайте сколько у вас будет объектов если вы загрузите 10тыс таблиц источника по 30 атрибутов в каждом. Ведь ваш фреймворк загрузки будет работать со словарем данных очень интенсивно при таком подходе.
олды помнят что изначально DV разрабатывали не для "гибкости", а потому что в те годы СУБД и аппаратное обеспечение с трудом переваривали изменения. Идея DV была в том, чтобы атрибуты измерений разбивать по сателитам в зависимости от временной гранулярности изменений. Те, условно, те что загружаются\обновляются раз в час в одном сателите, те что раз в 4 часа в другом, раз в сутки в третьем. В теории это позволяло не обновлять длинную строку очень часто. С приходом эры MPP необходимость в таком подходе просто отпала.
При написании этой статьи присутствует конфликт интересов. Судить можно по выводу, который не является нейтральным: исходя из картинки, фактически выбор осуществляется между anchor и DV. При этом минусом обоих указана сложность проверки качества данных. Сложно себе представить такое хранилище в финансовом секторе.
А что с другими, динамично развивающимися? Успех развития сложно представить с плохим качеством данных. Может поэтому куда ни глянь - сплошное надурилово, может оттого и нужно динамично развиваться, чтобы надурилово не бросалось в глаза.
к сожалению картинки для последних двух моделей нечитаемые. я хотела понять чем там отличается представление данных от выбора модели - но по этим картинкам это не поймешь.
кажется, важным фактором при выборе модели будет ещё предполагаемое использование данных: насколько широкая аудитория пользователей, какие у них средства автоматизации и интерфейсы, как много дата-инженеров будут вносить изменения
Снежинка, Data Vault, Anchor Modeling. Какая методология проектирования DWH подойдет для вашего бизнеса?