Комментарии 14
Вот вроде отличная статья, но не покидает ощущение что уж очень устаревшие подходы к проектированию DWH. Все-таки в 2020 живём и количество данных растёт огромными темпами, подобные решения просто не выживут даже на десятках ТБ, что уж говорить о более серьёзных хранилищах. Очень рекомендую ознакомиться с https://youtu.be/4Spo2QRTz1k
Насколько понимаю, подход FDE относится больше к организации ETL, чем к структуре данных, т.е. может применяться к разным вариантам архитектуры хранилищ (в том числе и к описанным в статье) с учетом некоторых дополнительных требований (например к партиционированию).
А вот по поводу того, что описанные в статье подходы устаревшие и на десятках ТБ не выживают — я бы поспорила (особенно относительно якорной модели, которая по опыту Авито, вполне здравствует на многотеррабайтном хранилище)).
- Оба описанных подхода, хотя и существуют уже больше десяти лет, хорошо соответствуют общему нынешнему «духу микросервисов» — стремлению к изоляции блоков функционала (или данных), модульности и уменьшению связности (как, между прочим и FDE). А нормализация, лежащая в их основе, способствует более сжатому хранению данных, что полезно при больших объемах.
- Со временем не только растут объемы данных, но и эволюционируют платформы и дешевеют вычислительные мощности. А основные преимущества описанных методологий (ранняя поставка, быстрая и простая доработка) лежат в плоскости времени удовлетворения хотелок бизнеса и трудозатрат специалистов, которые как раз не особо дешевеют.)
- Я бы ещё не стала мешать в одну кучу структурированные аналитические хранилища и системы класса big data. Имхо объемы анализируемых данных особенно активно растут именно в системах второго типа, в которых подходы к хранению и приемы обработки принципиально другие (возможно, у коллег, занимающихся этой темой, тоже дойдут руки о них написать).
- Ну и разумеется всё очень сильно зависит от назначения системы и предметной области.
То, что будет эффективно, в биллинге (где только объем транзакций может измеряться сотнями гигабайт в день, измерения имеют достаточно простую структуру, а объектный и атрибутный состав данных меняется не так часто), скорее всего плохо подойдет для ритэйла с относительно небольшим объемом транзакций, но широкой и неоднородной по атрибутному составу товарной номенклатурой и постоянно перерабатываемыми бизнес-стратегиями.
Имхо тут важно иметь представления о существующих инструментах (как самых инновационных, так и «проверенных временем») и уметь подобрать из них наиболее рабочие в заданных условиях. Так что ещё раз спасибо за ссылку.)
При больших объемах как раз таки более выгодно хранить данные в максимально денормализованном виде, так как стоимость вычислений (джойнов) на порядок выше стоимости хранения этих дублирующих данных. Я согласен, это больше разговор про Big Data, но ведь сейчас все стараются двигаться в этом направлении. Даже те же ритейлы, которые вы упомянули, в текущих реалиях заинтересованы не столько в анализе самих транзакций, сколько в анализе поведения клиентов (и почему они не совершают транзакции). И здесь они могут серьезно поспорить с биллингом, у кого данных больше :)
В Авито сотни ТБ, Anchor Modeling ManyChat, на базе Snowflake - уже более 100 Тб.
Самое забавное, что как раз подход в видео по ссылке - уже немного устаревший. Он сильно упрощает работу дата-инженеров, но аналитикам с этим работать - сложно. Точнее так, там две части:
1. подход функционального инжиниринга, only-insert, идемпотентный код - полнстью поддерживаю. Все это очень помогает для любых методологий, как инструмент, особенно для Anchor Modeling (или для Data Vault с однодатной историчностью SCD2, без апдейтов).
2. Подход подневных снапшотов для отражения историчности - это фантастика для дата инженера, но ад для аналитика. В ManyChat такой подход сосуществовал с Anchor Modeling на протяжении года, мы его хорошо распробовали. Чтобы понять сложность для аналитиков - предлагаю такое упражнение: измерение Клиентов, с подневными снапшотам, где для клиента хранится, например, регион. Попытайтесь посчитать количество клиентов, которые за 2 года более чем 4 раз меняли регион...
Кажется нужно добавить, что ETL процессы в подобных моделях не просто хорошо автоматизируются, а просто не могут существовать без инструмента автоматизации, если число объектов превышает пару десятков
Интересно, а как те кто пишет ad-hoc уживаются с такими гибкими методологиями?
На самом деле, на мой взгляд, с data vault в плане ad-goc работать не так уж сложно (хотя безусловно сложнее, чем со звездой) — надо только привыкнуть к связкам через линк, не забывать дату в версионных сателлитах и примерно помнить какие атрибуты в каком сателлите искать. +Бывают ещё Point-In-Time таблицы, в которых уже сделана часть джойнов.
А вот писать руками запросы к якорной модели — действительно должно быть больно. Поэтому для ad-hoc тут можно либо (если такое позволяет движок) создать специальные представления и табличные функции, возвращающие все атрибуты измерения на заданную дату (описание есть вот тут со стр.15), либо разработать и использовать специальный конструктор запросов (насколько знаю, коллеги из Авито прошли именно этим путем).
И, кстати, оба варианта могут содержать слой отчетных витрин поверх основного слоя данных. А там, в отчетах, конечно может быть не всё и не в том разрезе, который нужен прямо сейчас, зато в уже посчитанных человеческих таблицах).
Вот и у меня такие ощущения, что поверх гибкости идёт привычный 3NF или денормализованные витрины, то и все вместе.
Кажется, сначала надо отталкиваться от бизнес задач и предметной области. Data vault, якорная модель, это не панацея. Что может работать для сайта с объявлениями, может быть губительно для банковского хд и наоборот.
Если поверх слоя в гибкой архитектуре позарез нужна ещё и 3НФ (особенно с зависимостями внутри слоя), и только поверх неё — витрины, смысл модульности и гибкости теряется — все проблемы 3NF просто перемещаются на слой выше.
Т.е. если такое случилось — скорее всего выбранная методология в данном случае просто не подходит.
Потому что, да, абсолютно согласна, что гибкие методологии — не панацея, как и 3NF, или звезда или что-либо другое. Думаю, что панацеи тут, к сожалению, просто нет и всё действительно зависит от конкретных задач (или к счастью, т.к. иначе не нужны были бы архитекторы))).
Большое спасибо за статью, хорошее структурирование подходов, хочу ее показать коллегам, чтобы не пересказывать своими словами плюсы подхода именно в контексте гибкости.
PS. В августе планирую написать следующую статью, про новую, четвертую, сущность (кроме сущностей/атрибутов/связей), которая очень помогает работать с кликстримом... В Авито она сформировалась сама по себе, в ManyChat мы ее внедрили осознанно, и оказалось очень удобно.
PPS. Anchor Modeling ManyChat - уже больше 100Тб :)
Обзор гибких методологий проектирования DWH