Почему аналитика в компаниях часто работает медленно — даже если ресурсов достаточно?
Обычно это выглядит так:
Бизнес: «Аналитика готовится слишком долго».
Аналитики: «Мы не можем напрямую работать с данными и ждем задач через инженеров».
Инженеры: «Нельзя пускать аналитиков в центральное DWH — один неудачный запрос может положить систему».
Такая ситуация встречается почти везде: в классических DWH Greenplum и Vertica, в современных системах вроде StarRocks и даже в lakehouse-инсталляциях на базе Spark. Причина — в архитектуре.
Где возникает проблема
Во многих аналитических СУБД есть общий компонент, через который проходит обработка запросов.
Из-за этого появляются узкие места. Например:
✔️ В Greenplum любой запрос проходит через ноду-координатор.
✔️ В Vertica нагрузка ложится на глобальный каталог.
✔️ В Spark и StarRocks один некорректный запрос может занять все вычислительные слоты.
В результате тяжелый запрос начинает тормозить работу всей системы. Ресурсные группы, квоты и другие механизмы лишь ограничивают ущерб, но не устраняют саму причину — конкуренцию за ресурсы.
Выход: изолировать вычисления
Если дать аналитикам полную свободу, идеальная система должна работать иначе.
Представьте, что каждый аналитик работает в своей персональной базе: он видит те же данные, но физически не делит вычислительные ресурсы с коллегами.
Именно такую архитектуру показал Snowflake с моделью shared data — independent compute.
Сессионные вычислители
Для каждой пользовательской сессии запускается отдельный легковесный SQL-вычислитель. Он стартует за доли секунды, подтягивает только нужные данные из хранилища и выполняет запрос, не мешая соседним сессиям.
Фактически каждый аналитик получает свой изолированный вычислитель.
Что это дает
При такой архитектуре пользователи перестают конкурировать за ресурсы:
✔️ Запросы аналитиков не мешают друг другу.
✔️ Тяжелые задачи не блокируют отчеты и ETL.
✔️ Систему можно масштабировать, просто добавляя вычислительные узлы.
Как это работает на практике
Такой подход реализован в аналитической системе Tengri, которую развивает Postgres Professional. Она использует архитектуру сессионных вычислителей и независимых SQL-воркеров.
В тестах на бенчмарке TPC-H система показала почти линейный рост производительности при увеличении числа параллельных пользователей и значительно более высокую эффективность при высокой нагрузке по сравнению с традиционными MPP-решениями.
Идея проста: если изолировать вычисления на уровне сессий, аналитика перестает бороться за ресурсы и начинает масштабироваться так, как этого ждут пользователи.
Читайте подробности на Хабре.
Убедиться в приведенных цифрах можно в документации.
Если любите смотреть, а не читать, сохраняйте плейлист на Youtube.
