После добавления нескольких срезов дашборд стал медленным. Какой механизм модели позволяет ускорить запросы без изменения показателей?
Используют предагрегации: заранее рассчитанные таблицы или представления на нужном уровне детализации. BI-система направляет подходящий запрос к такой агрегированной структуре вместо повторного чтения большого набора детальных фактов.
По мере роста объёма данных интерактивный пересчёт показателей по детальным фактам стал слишком дорогим для пользовательских запросов. Предагрегации появились как способ перенести часть вычислений на этап подготовки данных и сохранить приемлемое время отклика аналитических систем.
Каждый срез может менять фильтры по периоду, региону, продукту или другим измерениям. Если для каждого сочетания система заново сканирует детальные записи и группирует их, время ответа и нагрузка на хранилище растут.
Предагрегация помогает только тогда, когда её зерно содержит необходимые измерения, а мера корректно вычисляется на этом уровне. Неподходящая агрегатная таблица может не ускорить запрос или, что опаснее, привести к неверному результату при ошибочной маршрутизации.
Сначала определяют наиболее частые аналитические срезы и создают агрегатную структуру, например с данными по дню, региону и категории товара. В ней заранее хранят аддитивные показатели: сумму продаж, количество заказов и другие меры, которые можно безопасно повторно агрегировать.
Семантический слой или механизм оптимизации должен распознать, что запрос совместим с этой структурой, и выбрать её автоматически. Если пользователь запрашивает более детальный уровень, отсутствующее измерение или меру, которую нельзя корректно восстановить из агрегата, запрос должен обратиться к детальным данным.
Особое внимание нужно уделить зерну, составу измерений и определению мер. Сумму и количество обычно можно складывать повторно, а уникальных клиентов нельзя корректно получить простым суммированием уникальных значений по дням: один клиент может встречаться в нескольких группах.
Предагрегации требуют обновления при поступлении новых данных и контроля согласованности с детальным слоем. Их минусы — дополнительное место хранения, усложнение конвейера обновления и риск устаревших результатов; поэтому выигрыш в скорости нужно сопоставлять с требованиями к свежести.
В отчёте по заказам пользователи фильтровали данные по месяцу, региону и каналу продаж. После роста фактов время открытия страницы увеличилось до нескольких десятков секунд.
Рассматривались три варианта. Увеличение ресурсов хранилища могло дать быстрый эффект, но не устраняло повторные вычисления и повышало стоимость. Ограничение числа фильтров ускорило бы отчёт, однако ухудшило бы пользовательский сценарий. Создание агрегата по месяцу, региону и каналу сохранило функциональность, но потребовало настройки обновления и проверки мер.
Выбрали третий вариант. Для показателей, совместимых с этим зерном, BI-система стала использовать агрегат, а для детальных заказов — исходную таблицу. После сверки итогов на нескольких периодах время ответа сократилось, при этом значения агрегированных показателей остались согласованными с детальными данными.
Нет. Если фильтр содержит измерение, которого нет в агрегате, или запрос требует детализации ниже его зерна, система не сможет использовать эту структуру. Кроме того, небольшой объём данных, сложная логика соединений или неудачно выбранный набор измерений могут сделать обращение к агрегату невыгодным.
В общем случае нельзя. Один клиент может быть активен в нескольких днях, поэтому сумма дневных уникальных клиентов посчитает его несколько раз. Для точного результата нужен расчёт по детальным данным либо специальная агрегатная структура, сохраняющая информацию, достаточную для корректного объединения уникальных значений.
Нужно сравнить результаты агрегированного и детального путей на контрольных срезах: по периодам, измерениям, граничным датам и случаям с пропусками. Проверяют не только общий итог, но и совпадение определения фильтров, зерна, обработки null-значений, часовых зон и момента обновления. Производительность измеряют отдельно после прогрева кэша и без него, иначе эффект может быть ошибочно приписан предагрегации.