Тяжёлые дашборды: high-cardinality и ускорение BI

Медленный дашборд часто кажется проблемой интерфейса: долго крутится фильтр, таблица не открывается, график обновляется после паузы. Но в статье причина переносится глубже — в устройство данных и запросов, которые стоят за визуализацией.

Ключевое понятие материала — high-cardinality. Это поля с большим числом уникальных значений: клиенты, SKU, заказы, чеки, маршруты, договоры. Когда такие поля попадают в фильтры и детализацию без подготовки, BI-система вынуждена каждый раз обрабатывать слишком большой объём данных.

Дальше разбирается типовая ошибка: бизнес хочет видеть максимум детализации в одном экране, а команда пытается ускорить уже готовый отчёт за счёт железа или косметической оптимизации. Но если дашборд напрямую тянет сырые строки из источников, проблема остаётся.

Решение описывается через архитектуру: хранилище данных, ETL, предварительные агрегаты, инкрементальные загрузки, materialized views, кэширование и перенос тяжёлых расчётов туда, где они выполняются быстрее и стабильнее.

Финальная часть касается дизайна BI. Количество визуализаций, набор фильтров, глубина детализации, частота обновлений и сценарий использования должны быть спроектированы заранее, иначе даже полезный отчёт превращается в инструмент, которым невозможно пользоваться каждый день.