Открыть список
Как стать автором
Обновить

Комментарии 10

Хороший материал, спасибо!

Вот вроде отличная статья, но не покидает ощущение что уж очень устаревшие подходы к проектированию DWH. Все-таки в 2020 живём и количество данных растёт огромными темпами, подобные решения просто не выживут даже на десятках ТБ, что уж говорить о более серьёзных хранилищах. Очень рекомендую ознакомиться с https://youtu.be/4Spo2QRTz1k

Спасибо за ссылку, материал действительно интересный! Для других интересующихся вот ещё статья по Functional Data Engineering на мембране.

Насколько понимаю, подход FDE относится больше к организации ETL, чем к структуре данных, т.е. может применяться к разным вариантам архитектуры хранилищ (в том числе и к описанным в статье) с учетом некоторых дополнительных требований (например к партиционированию).

А вот по поводу того, что описанные в статье подходы устаревшие и на десятках ТБ не выживают — я бы поспорила (особенно относительно якорной модели, которая по опыту Авито, вполне здравствует на многотеррабайтном хранилище)).

  1. Оба описанных подхода, хотя и существуют уже больше десяти лет, хорошо соответствуют общему нынешнему «духу микросервисов» — стремлению к изоляции блоков функционала (или данных), модульности и уменьшению связности (как, между прочим и FDE). А нормализация, лежащая в их основе, способствует более сжатому хранению данных, что полезно при больших объемах.
  2. Со временем не только растут объемы данных, но и эволюционируют платформы и дешевеют вычислительные мощности. А основные преимущества описанных методологий (ранняя поставка, быстрая и простая доработка) лежат в плоскости времени удовлетворения хотелок бизнеса и трудозатрат специалистов, которые как раз не особо дешевеют.)
  3. Я бы ещё не стала мешать в одну кучу структурированные аналитические хранилища и системы класса big data. Имхо объемы анализируемых данных особенно активно растут именно в системах второго типа, в которых подходы к хранению и приемы обработки принципиально другие (возможно, у коллег, занимающихся этой темой, тоже дойдут руки о них написать).
  4. Ну и разумеется всё очень сильно зависит от назначения системы и предметной области.
    То, что будет эффективно, в биллинге (где только объем транзакций может измеряться сотнями гигабайт в день, измерения имеют достаточно простую структуру, а объектный и атрибутный состав данных меняется не так часто), скорее всего плохо подойдет для ритэйла с относительно небольшим объемом транзакций, но широкой и неоднородной по атрибутному составу товарной номенклатурой и постоянно перерабатываемыми бизнес-стратегиями.

Имхо тут важно иметь представления о существующих инструментах (как самых инновационных, так и «проверенных временем») и уметь подобрать из них наиболее рабочие в заданных условиях. Так что ещё раз спасибо за ссылку.)

При больших объемах как раз таки более выгодно хранить данные в максимально денормализованном виде, так как стоимость вычислений (джойнов) на порядок выше стоимости хранения этих дублирующих данных. Я согласен, это больше разговор про Big Data, но ведь сейчас все стараются двигаться в этом направлении. Даже те же ритейлы, которые вы упомянули, в текущих реалиях заинтересованы не столько в анализе самих транзакций, сколько в анализе поведения клиентов (и почему они не совершают транзакции). И здесь они могут серьезно поспорить с биллингом, у кого данных больше :)

Кажется нужно добавить, что ETL процессы в подобных моделях не просто хорошо автоматизируются, а просто не могут существовать без инструмента автоматизации, если число объектов превышает пару десятков

Интересно, а как те кто пишет ad-hoc уживаются с такими гибкими методологиями?

Думаю, что страдают.)

На самом деле, на мой взгляд, с data vault в плане ad-goc работать не так уж сложно (хотя безусловно сложнее, чем со звездой) — надо только привыкнуть к связкам через линк, не забывать дату в версионных сателлитах и примерно помнить какие атрибуты в каком сателлите искать. +Бывают ещё Point-In-Time таблицы, в которых уже сделана часть джойнов.

А вот писать руками запросы к якорной модели — действительно должно быть больно. Поэтому для ad-hoc тут можно либо (если такое позволяет движок) создать специальные представления и табличные функции, возвращающие все атрибуты измерения на заданную дату (описание есть вот тут со стр.15), либо разработать и использовать специальный конструктор запросов (насколько знаю, коллеги из Авито прошли именно этим путем).

И, кстати, оба варианта могут содержать слой отчетных витрин поверх основного слоя данных. А там, в отчетах, конечно может быть не всё и не в том разрезе, который нужен прямо сейчас, зато в уже посчитанных человеческих таблицах).

Вот и у меня такие ощущения, что поверх гибкости идёт привычный 3NF или денормализованные витрины, то и все вместе.


Кажется, сначала надо отталкиваться от бизнес задач и предметной области. Data vault, якорная модель, это не панацея. Что может работать для сайта с объявлениями, может быть губительно для банковского хд и наоборот.

Денормализованные витрины или звезда — да. 3НФ — имхо уже перебор.)

Если поверх слоя в гибкой архитектуре позарез нужна ещё и 3НФ (особенно с зависимостями внутри слоя), и только поверх неё — витрины, смысл модульности и гибкости теряется — все проблемы 3NF просто перемещаются на слой выше.
Т.е. если такое случилось — скорее всего выбранная методология в данном случае просто не подходит.

Потому что, да, абсолютно согласна, что гибкие методологии — не панацея, как и 3NF, или звезда или что-либо другое. Думаю, что панацеи тут, к сожалению, просто нет и всё действительно зависит от конкретных задач (или к счастью, т.к. иначе не нужны были бы архитекторы))).

Жалко, что тезис про не панацею, как-то теряется в статье.


Создаётся обратное ощущение, и это удивительно читать от компании, которые 15 лет проектирует и разрабатывает хранилища почти половине российского крупного бизнеса.

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Информация

Дата основания
2002
Местоположение
Россия
Сайт
glowbyteconsulting.com
Численность
1 001–5 000 человек
Дата регистрации
Представитель
IraMefedova

Блог на Хабре