Компания растёт, объём данных для BI увеличился в 50 раз за два года, и текущие live-дашборды на прямых запросах к OLTP-базе стали нестабильными и дорогими. Как вы спроектируете масштабируемую BI-архитектуру и какие компромиссы при этом возникают?

Короткий ответ

Единой правильной архитектуры нет; типичное направление — перенести отчётность с OLTP на отдельное аналитическое хранилище, с трансформационным слоем, строящим предагрегированные/материализованные модели, и семантическим слоем для согласованных определений метрик, при явном выборе компромисса между свежестью данных, стоимостью и сложностью.

Как это работает подробнее

OLTP-базы оптимизированы под множество мелких транзакционных операций, а не под крупные сканирующие агрегации, типичные для BI; перенос аналитической нагрузки в отдельное хранилище (через CDC/ETL/ELT) изолирует отчётность от продакшн-нагрузки, а материализованные агрегаты на фактической гранулярности дашбордов убирают повторное сканирование детальных данных.

Что использовать на практике

• Применение. Спроектируйте слоистую архитектуру (сырые/staging-данные → смоделированные/агрегированные витрины → семантический слой/BI-инструмент), выберите частоту обновления под каждую реальную потребность в задержке решения (не «максимально свежо» по умолчанию), подберите хранилище/вычисления (колоночное хранилище, партиционирование, кластеризация) под объём и паттерны запросов; валидируйте новые агрегаты против прежних live-чисел в переходный период.
• Пример. Поэтапная миграция: сначала перенос самых тяжёлых дашбордов на агрегированные таблицы в хранилище (например, BigQuery/ClickHouse) с ежедневным обновлением, при этом параллельно считать прежним способом (прямой запрос к OLTP) в течение 2 недель и сверять расхождения, прежде чем полностью отключать старый путь — это и есть проверка корректности миграции.

Подводные камни

• Частые ошибки. Попытка сделать всё «в реальном времени», когда большинство дашбордов реально просматриваются раз в день/неделю, создавая лишнюю стоимость и сложность; построение витрин на слишком грубой гранулярности, вынуждающее переделку при новых потребностях в разрезах; миграция без периода параллельной валидации, незаметно меняющая исторические числа и подрывающая доверие; отсутствие плана эволюции схемы/управления по мере подключения новых команд.