'/%3e%3cpath%20d='M83.8172%20112C100.688%20112%20111.886%2098.2694%20112%2083.8882H44.0245C25.8409%2083.8882%2016.001%2094.3169%2016.001%20112H83.8172Z'%20fill='url(%23paint1_linear_101_577)'/%3e%3cpath%20d='M44.1725%2044.1138H16.0008C15.9465%2051.0963%2018.504%2058.2306%2024.2977%2064.0225L44.1706%2083.8881L52.8986%2075.3569L61.7636%2066.7019C63.2767%2065.2244%2063.2786%2062.7888%2061.7636%2061.3094L44.1725%2044.1138Z'%20fill='%233A5FFF'/%3e%3cpath%20d='M83.8248%2083.8862H111.996C112.051%2076.9037%20109.493%2069.7693%20103.7%2063.9774L83.8267%2044.1118L75.0986%2052.6431L66.2337%2061.2981C64.7206%2062.7756%2064.7187%2065.2112%2066.2337%2066.6906L83.8248%2083.8862Z'%20fill='%233A5FFF'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_101_577'%20x1='16.001'%20y1='30.055'%20x2='111.998'%20y2='30.055'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_101_577'%20x1='111.998'%20y1='97.9451'%20x2='16.001'%20y2='97.9451'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
Хранилище данных (Data Warehouse)
Хранилище данных — не просто «большая база». Оно устроено так, чтобы хорошо отвечать на аналитические вопросы по агрегированным данным, а не обслуживать продуктовые транзакции.
Особенности
- Колонное хранение и сжатие — быстрые агрегаты по миллионам строк.
- Слои данных: сырой (raw), промежуточный (staging), бизнес-витрина (marts).
- Регулярные ELT-процессы, которые обновляют данные на разном частотном интервале.
- Управление доступом по командам и ролям.
Что обычно лежит
- События продукта (events).
- Финансовые транзакции и выручка.
- Маркетинг и рекламные расходы.
- Воронки продаж, сделки, поддержка.
- HR, операционные и другие справочные данные.
Когда применять и когда нет
Применять
- Источников данных больше двух и они нужны вместе
- Аналитика в боевой базе уже мешает работе продукта
- Нужна история данных без оглядки на удаления и обновления в источниках
Не применять
- Только один источник данных и команда из 3–5 человек — пока хватит грамотных представлений в самой продуктовой базе
Примеры применения
До хранилища аналитика стартапа жила в боевой Postgres-базе и ломала отчёты при больших запросах. После переезда на BigQuery с регулярной репликацией через Fivetran продуктовая база перестала «лежать» от тяжёлых SQL-отчётов. Все маркетинговые расходы и события продукта теперь в одном месте, и команда может быстро отвечать на вопросы вроде «какой ROAS у новой кампании на горизонте 90 дней» без ручной сшивки выгрузок.
Часто задаваемые вопросы
Обычная база (OLTP) заточена под быстрые транзакции: добавил заказ, обновил профиль, перевёл деньги. DWH (OLAP) — под быстрые ответы на тяжёлые аналитические запросы по миллионам и миллиардам строк. Структуры данных и движки у них разные, и пытаться делать аналитику в OLTP обычно плохая идея.
Среди облачных популярны BigQuery (Google), Snowflake, Redshift (AWS), ClickHouse и его managed-варианты. Выбор обычно идёт от того, где уже живёт ваша инфраструктура и какой у команды опыт. Для большинства небольших продуктовых компаний разница между ними не критична.