Spider — всё! Новый движок Polars: прорыв в скорости работы FineBI 6.1

В 6.0, если строить визуализацию из датасетов, которые находятся в Public data (позволяет различным отделам и командам работать с одними и теми же данными, обеспечивая согласованность и единообразие в отчетности), все работало раз в 10 быстрее, чем с использованием модели данных в проекте дашборда. Поэтому заявления, что новый движок Polars быстрее в 3−5-10 раз, очень заинтересовали. Следовательно, в первую очередь хотелось сделать бенчмарки, чтобы понять, соответствуют ли обещания действительности или нет.
Итак, у нас есть модель данных: fact_table таблица фактов, связанная с dim_calendar календарем и справочником dim_drug.

Объемы данных:

• таблица фактов 150 миллионов строк,
• календарь 2000 строк,
• справочник 400 тысяч строк.

Это простой дашборд, он состоит из даты справочника, поля «Продажи». Бренд берется из справочников. Всего использовали топ-10 брендов.

Для измерения скорости работы выбираем различные года.

В версии 6.0.17 мы видим разброс 15−24 секунды, на всем объеме данных — 50 секунд.

В версии 6.1 тот же самый дашборд, те же самые данные показывают лучше значения.

Получаем, что в среднем в версии 6.1 дашборды будут работать в 5 раз быстрее «просто так» и ничего не нужно модифицировать, не нужно вносить никакие изменения. Обычно все радуются ускорением на каких-то 10−20%. Здесь же разница в 5 раз!

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

Чем отличается внутри дашборд от предыдущего? Тем, что мы, например, выносим не просто поле даты, а поле с Switch ()-функцией, которое в зависимости от значения в этом переключателе будет группировать либо по месяцу, либо по кварталу, либо по году.

То же самое в поле «Показатель». Мы можем посмотреть в рублях, можем — в количестве упаковок. Вместо бренда будет измерение, выбранное пользователем. Назовем этот дашборд advanced.

Подобный дашборд работал в версии FineBI 6.0.17 раз в 5, наверное, медленнее. В 6.1 было примерно так же.

Согласитесь, что, по сути, если человек выбрал группировку по кварталу, бренду и выбрал определенный год, то конечный запрос должен выполняться дольше лишь на ту часть, которая у машины уйдет на определение этих параметров, то есть на квартал и на определение того, по какому столбцу группировать по бренду. Но в данном случае нет «ленивых вычислений» (улучшение продукта «ленивыми вычислениями» запланировано на 3−4 кв. 2024 в версиях 6.1.3−6.1.4). FineBI просто считает сразу и по кварталу, и по годам, и по месяцам, и по брендам, и по всем тем измерениям, которые есть во всех функциях switch (). Это эмпирически подтверждается.

Чем больше мы добавляем в switch () возможных вариантов выбора, тем больше растет время загрузки дашборда. Например, ClickHouse лишен такой проблемы, потому что сам ClickHouse поддерживает «ленивые вычисления».

По результатам быстродействия наблюдаем, что теперь скорость работы увеличилась не в 5 раз, а в 2,8 раза, что тоже очень хорошо. То есть на ровном месте мы получаем просто в 3 раза более быстрые дашборды.

Круто, но очень ждем улучшения продукта в виде внедрения «ленивых вычислений». Так как любую базу, даже самую быструю, можно нагрузить кривыми запросами, которые генерируются при простой условной логике.

Давайте посмотрим результаты работы при Direct/прямом подключении к ClickHouse: добавление в поле со Switch, количество измерений никак практически не влияет.