Хранилище данных (Data Warehouse)

Хранилище данных (data warehouse) — это система баз данных, специально оптимизированная для аналитических запросов — агрегации, фильтрации и объединения по большим объёмам исторических данных, — в отличие от операционной (OLTP) базы данных, обеспечивающей чтение и запись приложения в реальном времени. Различие важно архитектурно: production-база Postgres приложения настроена на быстрые, небольшие, транзакционные операции (вставить один заказ, найти одного пользователя), тогда как хранилище вроде Snowflake, BigQuery или Redshift настроено на противоположное — сканирование миллионов или миллиардов строк, чтобы ответить на вопрос «какой была наша ежемесячная регулярная выручка по тарифным планам за последние 24 месяца?». Запуск такого запроса напрямую к production OLTP-базе может заблокировать таблицы и снизить производительность приложения для реальных пользователей — именно поэтому хранилища существуют как отдельная система, питаемая конвейером ETL/ELT. Почему это важно для разработчиков AI/SaaS: любая функция продукта, связанная с историческими трендами, сравнительным анализом между клиентами, когортным анализом или подачей агрегированных данных в AI-модель для генерации инсайтов («резюмируй тренд использования этого аккаунта за последний квартал»), — это нагрузка на хранилище, а не на production-базу данных. Попытка обслуживать такие запросы прямо из живой базы приложения — распространённая ранняя ошибка, вызывающая замедление production по мере роста компании. Как это работает: хранилища используют колоночное хранение (данные организованы по столбцам, а не по строкам), что делает агрегатные запросы по нескольким столбцам среди миллионов строк значительно быстрее, чем в строково-ориентированной базе данных, ценой слабой производительности при поиске отдельных строк. Современные облачные хранилища разделяют хранение и вычисления — вы платите за хранимые данные и отдельно за вычисления при запросах (часто по секундам или по объёму просканированных байт), что позволяет компании дёшево хранить годы истории, платя ощутимо только тогда, когда запросы реально выполняются. Хранилища обычно питаются ELT-конвейерами, заполняющими сырые и трансформированные таблицы, а затем запрашиваются BI-инструментами (Looker, Metabase, Tableau) или напрямую кодом приложения для клиентских аналитических функций. Практический пример: AI SaaS хочет предоставить в продукте отчёт «самые используемые AI-функции вашей команды в этом квартале». Вместо запуска этой агрегации к живой базе данных приложения (что конкурировало бы за ресурсы с реальным пользовательским трафиком), события использования функций поступают в таблицу `usage_events` хранилища BigQuery через ночной конвейер; эндпоинт отчёта выполняет предварительно агрегированный запрос `SELECT feature_name, COUNT(*) FROM usage_events WHERE customer_id = @id AND event_date >= @quarter_start GROUP BY feature_name ORDER BY COUNT(*) DESC` к BigQuery, оставляя production-базу нетронутой.