Евгений Ермаков: Есть 2 стула - Data Vault и Anchor Modeling, на какой сядешь, на какой DWH посадишь
Ғылым және технология
Data Fest Online 2020
SysML track ods.ai/tracks/sysml-df2020
Общепринятым и проверенным временем подходом к построению DWH является схема «Звезда» или «Снежинка». Такой подход каноничен, фундаментален, вотрефоллен и совсем не отвечает той гибкости, к которой призывает Agile.
Для того, чтобы сделать структуру DWH гибкой, существуют современные подходы к проектированию: Data Vault и Anchor modeling - похожие и разные одновременно.
Задавшись вопросом, который вынесен в заголовок доклада, мы пришли к неожиданному ответу: выбирать надо не между подходами, выбирать надо лучшее из двух подходов.
В своем докладе я расскажу:
- DV и AM - в чем разница и где точки соприкосновения;
- наш «гибридный» подход к построению хранилища;
- покажу примеры кода, как это работает.
Посмотреть эфир и список треков и организаторов: datafest.ru/2020/
Зарегистрироваться на фест и получить доступ к трекам: ods.ai/events/datafest2020
Вступить в сообщество: ods.ai/
Соцсети Data Fest:
t.me/datafest
datafest
Пікірлер: 14
Название - топ!
@paulfunigga
28 күн бұрын
для школьников, которые любят мемы и тикток
А зачем в центральной таблице сущности, где хранится сам бизнес-ключ нужно версионирование по utc_from_dttm? Изменяться же могут только атрибуты конкретной сущности в контексте определяющего ее бизнес-ключа.
Хранилище строится не по водопаду а по спирали. Я первый в России построил ХД по data vault, всего мною их построено три штуки, одно на 10 ТБ на технологиях ms sql, консультировался с Линстедтом, в конце концов я понял, что это полная хрень имеющая кучу недостатков в т.ч. и на загрузке - каждый сателлит - это по сути межленноменяющаяся размерность 2-го типа, при таблице в сотню гигабайт что бы закрыть датой предыдущую запись нужно её искать по всей таблице - это тяжелая операция. Второе dv не укладывается на MPP, некоторые пробуют, но получается плохо. Третье хешключи плохо индексируются, они и на простых базах то размазыватся по дискам в беспорядке, а что будет если их ещё и размещать по разным нодам MPP серверов? Разница между DV и Anchor в том, что первый строится от источника - снизу вверх, а второй сверху вниз т.е. от требований к анализу данных.
@paulfunigga
28 күн бұрын
молодец, всем посрать, как видишь
Такое впечатление что быстрая массовая загрузка данных - единственная цель многих оптимизаций. Это ж один раз делается, нужно ли подгонять под параллельную загрузку?
@ivani3237
Жыл бұрын
в смысле один раз? Один раз в сутки ты имел ввиду?? А зачастую вообще непрерывно, real-time. Но да, оптимизация под загрузку - это как авто для драг-рейсинга. Едет быстро, но юзерам пользоваться невозможно
непонятно, зачем атрибуты разбивать по разным таблицам. Вам разве нужно анализировать персон, у которых менялось только имя, а ничего другого не менялось? Почему имя и фамилия например в разных таблицах?
А зачем волосы красить
А куда вы кладёте атрибуты связей между сущностями (Hub) в hNhM?
@antonbondar5632
3 жыл бұрын
тоже не понятно. Разве что атрибуты связи - это отдельный Hub и его добавляем к связи
@ivani3237
Жыл бұрын
он сказал же, в отдельный саттелит прикрепленный к линку
А вот здесь 7:50 вообще на "Звезду" похожа "... не мышонка, не лягушку, а неведому зверушку..." Русская сказка Главное чтобы работало. Я тоже сторонник гремучих смесей. 👌
Почему у спикера лицо, как будто его через петушиную хату прогнали?