Хранилище данных — не просто большая база. Оно устроено так, чтобы хорошо отвечать на аналитические вопросы по сводным данным, а не обслуживать продуктовые операции.
Особенности
- Колоночное хранение и сжатие — быстрые своды по миллионам строк.
- Слои данных: сырой, промежуточный и слой готовых бизнес-витрин.
- Регулярные процессы загрузки, которые обновляют данные с разной периодичностью.
- Управление доступом по командам и ролям.
Что обычно лежит
- События продукта.
- Финансовые операции и выручка.
- Маркетинг и рекламные расходы.
- Воронки продаж, сделки, поддержка.
- Кадровые, операционные и другие справочные данные.
- Источников данных больше двух и они нужны вместе
- Аналитика в рабочей базе уже мешает работе продукта
- Нужна история данных без оглядки на удаления и обновления в источниках
- Только один источник данных и команда из 3–5 человек — пока хватит грамотных представлений в самой продуктовой базе
До хранилища аналитика стартапа жила в рабочей базе на Postgres и ломала отчёты при больших запросах. После переезда на BigQuery с регулярным копированием через Fivetran база продукта перестала падать от тяжёлых SQL-отчётов. Все рекламные расходы и события продукта теперь в одном месте, и команда может быстро отвечать на вопросы вроде «какая окупаемость у новой кампании на горизонте 90 дней» без ручной сшивки выгрузок.
Не путайте хранилище данных и базу продукта: у них разные задачи и разная нагрузка. Попытки делать тяжёлую аналитику в рабочей базе, которая обслуживает операции пользователей, обычно заканчиваются либо тормозами продукта, либо урезанием отчётов до неинформативных.