Как Business Intelligence «купается» в озёрах данных: практика платформы «Форсайт» / Comments / Habr

expdxx Nov 27 2021 at 04:25

Большой и интересный материал, спасибо. С первого раза полностью не смог осилить при том, что довольно глубоко нахожусь в теме BI, поэтому вернусь обязательно завтра)

Возможно, ответ на мое замечание есть в тексте, но я не обнаружил. Окей, заниматься дублированием данных в каком-либо внутреннем хранилище BI-системы действительно не всегда правильно, но получается, что для быстрого отклика системы у вас либо данные постоянно подняты в ОЗУ, либо множество пользователей бесконечно генерирует SQL-запросы. Какое быстродействие в подобных условиях обеспечивает BI-решение и какого масштаба требуются сервера? На примере таблицы в 2млн строк * 15 полей и порядка 15-20 пользователей в единицу времени. Не лучше ли предусмотреть для больших дашбордов (для которых требуется хранить только агрегаты, инкрементируемые к примеру раз в сутки, быстро поднимаемые в ОЗУ при открытии отчета) хранение во внутренних файлах а-ля Qlik QVD, а уже для ad-hoc отчетности live-connection к озеру? Заодно довольно просто решается вопрос одновременного доступа к данным большого числа пользователей. Вопрос быстродействия интерфейса у крупного руководства обычно стоит острее актуальности данных, сегодня им редко нужна информация младше сегодня-1 день.

Но в любом случае здорово, что у нас есть такое мощное BI-решение. Никогда не слышал ранее, ознакомлюсь, спасибо.

kvsman Nov 27 2021 at 22:16

Спасибо большое за позитивный отзыв. Отвечая на вопросы:

1) Во многом быстродействие и аппаратные требования зависят от сложности проекта и объемов отчетов (кол-ва данных в них).Минимальные требования к BI- и веб-серверам представлены в нашей онлайн-справке (ссылка). Для отказоустойчивой и распределенной нагрузки мы рекомендуем использовать горизонтальное масштабирование и собирать кластер. Подробнее об этом можно посмотреть тут (ссылка). При очень «экономичных» отчетах/дэшбордах каждая нода кластера выдерживает 200-250 одновременных пользователей. Для «средних/сложных» отчетов мы рекомендуем исходить уже из нагрузки в 50-150 одновременных подключений на одну ноду.

2) Для обозначенного примера (2 млн записей в исходной таблице, 15-20 пользователей) с обращениями к СУБД раз в 2-3 сек проблем точно не возникнет. При тестовых испытаниях мы обычно ориентируемся на несколько сотен одновременных пользователей и объемы данных от 1 млрд. записей. Тут правда разные СУБД по-разному реагируют на такие эксперименты. Oracle/Teradata пока самые «стрессоустойчивые». PostgreSQL/Greenplum – если часами непрерывно и постоянно их «мучать», начинают «хандрить». Clickhouse – где то посередине. В след. статьях я планировал привести некоторые графики нагрузки в разрезе отклика нашего BI на отчеты с разным количеством данных. Думаю, там все будет наглядно.

3) «агрегаты, инкрементируемые к примеру раз в сутки…» - да, тут все верно. Прямое обращение из BI к исходным (первичным) данным не единственное решение. Когда частота обращение к агрегатам на порядки превышает регулярность обновления самих первичных данных, то адаптированная витрина – это самый оптимальный вариант. Кассовая (чековая) аналитика в ритейле или банковские платежи, наверное одни из показательных примеров. Но наш ROLAP как раз подходит для всех задач: и первичные данные и выделенная витрина.

4) Qlik QVD. Да, такой режим мы тоже практикуем. In-memory в нашей Платформе реализовано в двух вариантах: a) все данные сразу целиком загружаются в ОЗУ с полным предварительным прогревом или b) создается файловый кэш и далее из него в ОЗУ все время «переподкачивается» востребованная часть данных, а невостребованная постепенно вытесняется. У обоих этих вариантов есть свои плюсы и минусы, свои «уместные» сценарии использования, свои требования к оборудованию. Про эту нашу технологию я тоже планировал сделать отдельную публикацию. Если кратко, основной плюс файлового кэша – это очень высокая (по сравнению с sql-запросами) скорость работы, особенно при сложных условиях фильтрации (при «отметках» в сотни тыс. элементов - это секунды по сравнению с минутами при sql-запросах). Основной минус – длительное обновление маленьких фрагментов данных, т.к. приходится проводить сложную переиндексацию. В итоге – мы рекомендуем файловый кэш использовать для режима только чтения (например, в случае с дэшбордами). А "прогрев" полного кэша – для режима расчетов или загрузки данных.