Почему аналитика в компаниях часто работает медленно — даже если ресурсов достаточно?

Обычно это выглядит так:

Бизнес: «Аналитика готовится слишком долго».

Аналитики: «Мы не можем напрямую работать с данными и ждем задач через инженеров».

Инженеры: «Нельзя пускать аналитиков в центральное 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.