Денормализованные витрины или звезда — да. 3НФ — имхо уже перебор.)
Если поверх слоя в гибкой архитектуре позарез нужна ещё и 3НФ (особенно с зависимостями внутри слоя), и только поверх неё — витрины, смысл модульности и гибкости теряется — все проблемы 3NF просто перемещаются на слой выше.
Т.е. если такое случилось — скорее всего выбранная методология в данном случае просто не подходит.
Потому что, да, абсолютно согласна, что гибкие методологии — не панацея, как и 3NF, или звезда или что-либо другое. Думаю, что панацеи тут, к сожалению, просто нет и всё действительно зависит от конкретных задач (или к счастью, т.к. иначе не нужны были бы архитекторы))).
На самом деле, на мой взгляд, с data vault в плане ad-goc работать не так уж сложно (хотя безусловно сложнее, чем со звездой) — надо только привыкнуть к связкам через линк, не забывать дату в версионных сателлитах и примерно помнить какие атрибуты в каком сателлите искать. +Бывают ещё Point-In-Time таблицы, в которых уже сделана часть джойнов.
А вот писать руками запросы к якорной модели — действительно должно быть больно. Поэтому для ad-hoc тут можно либо (если такое позволяет движок) создать специальные представления и табличные функции, возвращающие все атрибуты измерения на заданную дату (описание есть вот тут со стр.15), либо разработать и использовать специальный конструктор запросов (насколько знаю, коллеги из Авито прошли именно этим путем).
И, кстати, оба варианта могут содержать слой отчетных витрин поверх основного слоя данных. А там, в отчетах, конечно может быть не всё и не в том разрезе, который нужен прямо сейчас, зато в уже посчитанных человеческих таблицах).
Насколько понимаю, подход FDE относится больше к организации ETL, чем к структуре данных, т.е. может применяться к разным вариантам архитектуры хранилищ (в том числе и к описанным в статье) с учетом некоторых дополнительных требований (например к партиционированию).
А вот по поводу того, что описанные в статье подходы устаревшие и на десятках ТБ не выживают — я бы поспорила (особенно относительно якорной модели, которая по опыту Авито, вполне здравствует на многотеррабайтном хранилище)).
Оба описанных подхода, хотя и существуют уже больше десяти лет, хорошо соответствуют общему нынешнему «духу микросервисов» — стремлению к изоляции блоков функционала (или данных), модульности и уменьшению связности (как, между прочим и FDE). А нормализация, лежащая в их основе, способствует более сжатому хранению данных, что полезно при больших объемах.
Со временем не только растут объемы данных, но и эволюционируют платформы и дешевеют вычислительные мощности. А основные преимущества описанных методологий (ранняя поставка, быстрая и простая доработка) лежат в плоскости времени удовлетворения хотелок бизнеса и трудозатрат специалистов, которые как раз не особо дешевеют.)
Я бы ещё не стала мешать в одну кучу структурированные аналитические хранилища и системы класса big data. Имхо объемы анализируемых данных особенно активно растут именно в системах второго типа, в которых подходы к хранению и приемы обработки принципиально другие (возможно, у коллег, занимающихся этой темой, тоже дойдут руки о них написать).
Ну и разумеется всё очень сильно зависит от назначения системы и предметной области.
То, что будет эффективно, в биллинге (где только объем транзакций может измеряться сотнями гигабайт в день, измерения имеют достаточно простую структуру, а объектный и атрибутный состав данных меняется не так часто), скорее всего плохо подойдет для ритэйла с относительно небольшим объемом транзакций, но широкой и неоднородной по атрибутному составу товарной номенклатурой и постоянно перерабатываемыми бизнес-стратегиями.
Имхо тут важно иметь представления о существующих инструментах (как самых инновационных, так и «проверенных временем») и уметь подобрать из них наиболее рабочие в заданных условиях. Так что ещё раз спасибо за ссылку.)
Если поверх слоя в гибкой архитектуре позарез нужна ещё и 3НФ (особенно с зависимостями внутри слоя), и только поверх неё — витрины, смысл модульности и гибкости теряется — все проблемы 3NF просто перемещаются на слой выше.
Т.е. если такое случилось — скорее всего выбранная методология в данном случае просто не подходит.
Потому что, да, абсолютно согласна, что гибкие методологии — не панацея, как и 3NF, или звезда или что-либо другое. Думаю, что панацеи тут, к сожалению, просто нет и всё действительно зависит от конкретных задач (или к счастью, т.к. иначе не нужны были бы архитекторы))).
На самом деле, на мой взгляд, с data vault в плане ad-goc работать не так уж сложно (хотя безусловно сложнее, чем со звездой) — надо только привыкнуть к связкам через линк, не забывать дату в версионных сателлитах и примерно помнить какие атрибуты в каком сателлите искать. +Бывают ещё Point-In-Time таблицы, в которых уже сделана часть джойнов.
А вот писать руками запросы к якорной модели — действительно должно быть больно. Поэтому для ad-hoc тут можно либо (если такое позволяет движок) создать специальные представления и табличные функции, возвращающие все атрибуты измерения на заданную дату (описание есть вот тут со стр.15), либо разработать и использовать специальный конструктор запросов (насколько знаю, коллеги из Авито прошли именно этим путем).
И, кстати, оба варианта могут содержать слой отчетных витрин поверх основного слоя данных. А там, в отчетах, конечно может быть не всё и не в том разрезе, который нужен прямо сейчас, зато в уже посчитанных человеческих таблицах).
Насколько понимаю, подход FDE относится больше к организации ETL, чем к структуре данных, т.е. может применяться к разным вариантам архитектуры хранилищ (в том числе и к описанным в статье) с учетом некоторых дополнительных требований (например к партиционированию).
А вот по поводу того, что описанные в статье подходы устаревшие и на десятках ТБ не выживают — я бы поспорила (особенно относительно якорной модели, которая по опыту Авито, вполне здравствует на многотеррабайтном хранилище)).
То, что будет эффективно, в биллинге (где только объем транзакций может измеряться сотнями гигабайт в день, измерения имеют достаточно простую структуру, а объектный и атрибутный состав данных меняется не так часто), скорее всего плохо подойдет для ритэйла с относительно небольшим объемом транзакций, но широкой и неоднородной по атрибутному составу товарной номенклатурой и постоянно перерабатываемыми бизнес-стратегиями.
Имхо тут важно иметь представления о существующих инструментах (как самых инновационных, так и «проверенных временем») и уметь подобрать из них наиболее рабочие в заданных условиях. Так что ещё раз спасибо за ссылку.)