С момента выхода книги Ральфа Кимбалла «The Data Warehouse Toolkit» в 1996 году star schema остаётся золотым стандартом аналитических моделей данных. Однако с появлением современных облачных платформ снова обсуждают snowflake schema и даже более радикальные формы. На чём должно основываться решение?
Star Schema
В центре — fact-таблица (sales_fact), вокруг денормализованные dimension-таблицы (dim_customer, dim_product, dim_date). Каждое измерение собрано в одной таблице; количество JOIN минимально. Плюсы: простота, производительность, форма, которую естественно любят BI-инструменты.
sales_fact ←→ dim_customer ←→ dim_product ←→ dim_date ←→ dim_store
Snowflake Schema
Dimensions нормализуются — возникают подчинённые отношения вроде dim_product → dim_category → dim_department. Плюс: меньше места на диске, проще поддержка. Минус: больше JOIN-ов, сложнее запросы, тяжелее семантическое моделирование в BI.
Современная облачная перспектива
В эпоху колоночного хранения (Snowflake, BigQuery, Synapse) размер денормализованной таблицы уже не так важен, как раньше. dim_customer на 1 ТБ сжимается до 50 ГБ благодаря колоночному сжатию. Аргумент «snowflake экономит место» заметно ослаб.
С другой стороны, в платформах вроде GCP BigQuery и AWS Athena стоимость JOIN-ов по-прежнему велика; там star schema работает экономичнее.
Практическое руководство
- DWH под BI (Power BI, Tableau, Qlik): star schema — естественная интеграция, стабильная производительность.
- Гибрид data science + аналитика: star, но с небольшими связанными таблицами для иерархий внутри dimensions (лёгкий snowflake).
- Очень динамичный каталог товаров (ритейл, e-commerce): денормализованный
dim_productпри ежедневной пересборке бьёт по производительности; нужен либо incremental rebuild, либо snowflake. - Регуляторная отчётность: snapshot fact + датированные SCD Type 2 dimensions (поверх любой из моделей).
Поля, которые стоит денормализовать
- Иерархии дат (год/квартал/месяц/день): всегда денормализованы в
dim_date. - Демография клиента: как правило, уплощается в
dim_customer. - Путь категорий продукта: если уровней 4 и больше — snowflake может выиграть.
Подход One Big Table (OBT)
Современные ML-пайплайны и часть сценариев self-service BI предпочитают одну широкую таблицу вместо размерной модели. JOIN нет, весь контекст в одной строке. Минус: высокая стоимость поддержки; любое изменение расходится по всей таблице. Наша рекомендация: OBT — только для ML feature store; для общего BI размерная модель по-прежнему впереди.
