MPP-архитектура: почему распределённая обработка выигрывает у монолита

Когда аналитический запрос сканирует сотни миллионов строк, монолитная СУБД упирается в один пул ресурсов: память, сокеты и шины делят между собой все запросы разом. MPP-архитектура (Massively Parallel Processing) обходит эту проблему: запрос дробится на части, каждая уходит на отдельный узел, и все узлы считают одновременно. На терабайтах разница становится кратной.

Разберём, как именно устроен этот параллелизм, где монолит остаётся правильным выбором и какие MPP-движки покрывают реальные сценарии.

Что такое MPP-архитектура и как она работает

MPP — подход к обработке данных, при котором один SQL-запрос разбивается на части и выполняется параллельно на множестве независимых узлов. Каждый узел работает со своей долей данных и не делит ресурсы с соседями. Такая модель называется shared-nothing: у каждого узла собственные CPU, память и локальные диски, а связь между ними идёт через межузловой интерконнект с передачей сообщений.

MPP рассчитана на OLAP-запросы — длинные сканы, объёмные объединения таблиц и агрегации по большим массивам. Там, где монолиту приходится прогонять весь объём через один узел, MPP раскладывает работу по нескольким узлам и считает её одновременно.

Распределённый SQL-движок принимает запрос, делит данные между узлами и выполняет вычисления на всех узлах сразу, а затем собирает результат. Чем больше узлов, тем больше данных система обрабатывает за то же время. На объёмах от терабайт до петабайт MPP считает кратно быстрее монолитной СУБД.

Основные компоненты MPP

MPP-кластер состоит из четырёх элементов.

Координатор (мастер-нода). Принимает SQL-запрос, строит и компилирует план выполнения, нарезает данные по узлам, а в конце собирает частичные результаты в финальный ответ. Сам тяжёлые данные не хранит.

Вычислительные узлы. Хранят сегменты данных на локальных дисках и параллельно выполняют куски плана: сканирование, фильтрацию, частичную агрегацию.

Хранилище данных. Сегменты распределены между узлами; на аналитике обычно применяют колоночное хранение — оно ускоряет чтение нужных столбцов.

Сеть (интерконнект). Соединение для обмена промежуточными данными между узлами и передачи результатов координатору.

Как MPP обрабатывает запросы

Обработка запроса идёт в три шага.

1. Координатор разбирает SQL, строит план и нарезает задачу по узлам.
2. Вычислительные узлы параллельно выполняют свои куски — сканируют сегменты, фильтруют строки, считают частичные агрегаты, каждый на своих данных.
3. Координатор собирает частичные результаты и объединяет их в один ответ.

Скорость достигается за счет того, что узлы работают одновременно и независимо. Запрос, который монолит выполнял бы последовательно по всему объёму, MPP делит на параллельные потоки. На терабайтах и петабайтах разница в скорости становится кратной.

Преимущества MPP-архитектуры

Сильные стороны MPP вытекают из shared-nothing и параллелизма: система масштабируется горизонтально, держит высокую производительность на больших данных, говорит на привычном SQL и гибко подключает разные источники. Разберём отдельно каждое преимущество.

Масштабируемость

Монолит масштабируется вертикально — наращиванием ресурсов одного сервера. Этот путь дорогой и конечный: у любой машины есть предел по числу сокетов, объёму памяти и пропускной способности шин. Когда данные растут быстрее, чем железо, вертикаль упирается в стену.

MPP масштабируется горизонтально: чтобы поднять производительность, в кластер добавляют новые узлы. Каждый новый узел приносит свои CPU, память и диски — растут и вычислительная мощность, и ёмкость хранения. Жёсткого потолка у такого роста нет: кластер расширяют под объём данных.

Высокая производительность

Производительность MPP держится на двух механизмах: параллельной обработке и оптимизации запросов.

Параллелизм означает, что тяжёлый аналитический запрос дробится и считается на всех узлах сразу, а не прогоняется через один пул ресурсов. Чем шире кластер, тем больше работы идёт одновременно.

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

В монолите запросы с длинными сканами, join и агрегациями конкурируют за общие ресурсы узла: CPU, память, ввод-вывод, дескрипторы и пр. Один тяжёлый запрос тормозит всех или забирает все доступные ресурсы. В MPP такой проблемы практически нет: нагрузка распределена по независимым узлам.

Поддержка SQL

MPP-движки работают на SQL — языке, который аналитики данных и так используют каждый день. Не нужно осваивать новый интерфейс или переписывать запросы под особый API: привычный SQL ложится на распределённую обработку напрямую.

Это упрощает и интеграцию с BI-инструментами. Системы визуализации и отчётности подключаются к MPP-движку по тем же стандартным протоколам, что и к обычной СУБД, и сразу получают доступ к аналитике на больших данных. Для команды это означает короткий порог входа: знания SQL переносятся на MPP без переучивания.

Гибкость в управлении

MPP-кластером гибко управляют по нагрузке: узлы добавляют и выводят, подстраивая ресурсы под текущий объём данных и интенсивность запросов. Платить за пиковую конфигурацию постоянно не нужно — мощность наращивают тогда, когда она требуется.

Гибкость касается и источников данных. MPP-движки подключают данные из разных систем, а решения класса Trino поддерживают федеративные запросы — один SQL-запрос обращается сразу к нескольким источникам, не сводя их предварительно в одно хранилище. Это снимает часть работы по перекладыванию данных и даёт аналитику доступ к разрозненным системам через единый интерфейс.

Когда стоит использовать MPP-движок

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

Сценарии использования MPP

MPP-движок оправдан, когда нагрузка сходится сразу по нескольким признакам:

• Обработка ТБ и ПБ данных. Аналитика на терабайтах (ТБ) и петабайтах (ПБ, 1 ПБ = 1024 ТБ) — основной случай для MPP. Данные не помещаются в один сервер, и горизонтальное масштабирование становится единственным способом удержать время отклика.
• Сложные OLAP-запросы. Полные сканы таблиц, многотабличные объединения, агрегации по большим наборам — нагрузка, под которую MPP проектировался. Параллельное выполнение по узлам кластера разбивает такой запрос на части и собирает результат быстрее, чем монолит на одном процессоре.
• Аналитика в режиме близком к реальному времени. BI-дашборды, которым нужен свежий срез данных на больших объёмах, выигрывают от распределённой обработки: запрос не упирается в один сервер.
• Федерация к разным источникам. Object storage, реляционные базы, потоковые системы — в одном SQL-запросе без предварительной выгрузки данных в отдельное хранилище.

Когда лучше использовать монолитные решения

Монолитная (SMP, симметричная многопроцессорная) база — инструмент под другую нагрузку, и на своём поле она выигрывает у MPP по простоте и стоимости. Вот это поле:

• Маленькие объёмы. Если данные измеряются единицами и десятками гигабайт, распределять нечего. Монолит обрабатывает такой объём в пределах одного сервера, и MPP здесь только добавляет накладные расходы.
• Точечные транзакции OLTP. Операции вставки, обновления и чтения отдельных записей — поле классических OLTP-баз. MPP оптимизирован под массовое сканирование, а не под тысячи коротких транзакций в секунду.
• Ограниченные ресурсы. Кластер MPP требует координации узлов, сетевого обмена между ними и эксплуатации распределённой системы. Для небольшой команды с ограниченным бюджетом это лишняя сложность.

Накладные расходы MPP — координация узлов, сетевой трафик, эксплуатация кластера — окупаются только тогда, когда объём данных и тяжесть запросов действительно этого требуют. На старте и на малых объёмах монолит дешевле и предсказуемее.

MPP-движки: популярные решения

Рынок MPP-движков для OLAP сложился вокруг нескольких решений с разной моделью лицензирования и эксплуатации.

Trino (бывший Presto SQL)

Trino — это open-source распределённый SQL-движок с MPP-архитектурой, известный до декабря 2020 года под именем PrestoSQL. Проект распространяется под лицензией Apache 2.0, поддерживается активным сообществом и регулярно получает обновления.

Главная сила Trino — федеративные запросы: движок умеет обращаться к множеству источников данных через коннекторы, не перемещая данные в общее хранилище. В их числе объектные хранилища вроде S3, реляционные базы PostgreSQL и MySQL, а также Cassandra, Kafka, MongoDB и Elasticsearch. Один SQL-запрос способен одновременно затронуть сразу несколько таких систем. Коннектор Iceberg дополнительно привносит поддержку ACID-транзакций прямо на данных в объектном хранилище.

Но у такой гибкости есть обратная сторона — высокий порог входа в production-эксплуатацию. Грамотная настройка требует серьёзной экспертизы: высокая доступность, отказоустойчивое выполнение запросов, тюнинг под реальную нагрузку — всё это не делается из коробки. Поддержку можно получить либо от сообщества, либо на коммерческой основе через Starburst.

CedrusData Engine

CedrusData Engine — коммерческий форк Trino от VK Tech. Движок наследует MPP-архитектуру и разделение вычислений и хранения: кластеры выполняют SQL-запросы, но не хранят данные, поэтому вычислительный слой масштабируется независимо от хранилища.

Относительно чистого Trino вендор добавил улучшения производительности и безопасности, расширенную интеграцию и готовую коммерческую поддержку. Упор делается на производительность и гибкость настройки, а также поддержку пользователей на всех этапах и оперативном исправлении инцидентов. За стабильность платят гибкостью. CedrusData Engine интегрирован в экосистему VK Cloud — он распространяется и как самостоятельный базовый продукт, и как часть VK Data Platform

Amazon Redshift Spectrum

Amazon Redshift Spectrum — облачный сервис AWS, позволяющий выполнять запросы к данным прямо в S3, минуя их загрузку в кластер Redshift. Запросы выполняются с массовым параллелизмом, а внешние таблицы описываются через AWS Glue, Athena catalog или Hive metastore.

Производительность во многом определяется тем, как устроено хранение данных: колоночный формат Parquet, партиционирование и файлы размером от 64 МБ заметно ускоряют работу. Сервис также поддерживает Delta Lake — правда, через manifest-файлы — и Hudi, что делает его удобным инструментом для аналитики поверх данных, которые уже лежат в S3. Плата за эту простоту — жёсткая привязка к экосистеме AWS: свободы меньше, чем у self-hosted Trino, зато настройка значительно проще, а поддержку целиком берёт на себя облачный провайдер.

Snowflake

Snowflake — облачный MPP-движок с архитектурой multi-cluster shared-data, в которой storage и compute полностью разделены. Три независимых слоя — вычисления, хранение и сервисы — масштабируются по отдельности, а мульти-кластерные warehouse умеют автоматически подстраиваться под пиковую нагрузку.

Биллинг строится по фактическому потреблению, что удобно при неравномерной нагрузке, однако без контроля затрат счета легко выходят за ожидаемые рамки. Snowflake — полностью управляемый сервис: возиться с инфраструктурой не придётся, но warehouse под конкретные паттерны запросов всё же потребуют настройки. Поддержку SQL обеспечивает сам вендор.

Сравнительная таблица MPP-движков

Как выбрать MPP-движок: критерии оценки

Выбор MPP-движка — это сопоставление профиля нагрузки с возможностями движка. Один и тот же движок может быть оптимальным для одной команды и избыточным для другой.

Критерии выбора:

• Объём данных. Сколько данных обрабатывается сейчас и какой рост ожидается — от этого зависит, нужна ли распределённость вообще и какой запас по масштабированию заложить.
• Требуемая производительность. Целевое время отклика на типовых OLAP-запросах и допустимая задержка для near real-time сценариев.
• Поддержка SQL. Полнота диалекта и совместимость с уже написанными запросами и BI-инструментами.
• Гибкость и масштабируемость. Нужна ли федерация к разным источникам, насколько независимо масштабируется compute относительно storage.
• Поддержка и документация. Что доступно — сообщество, коммерческий вендор или облачный провайдер; зрелость документации под production-эксплуатацию.
• Интеграции с другими системами. Коннекторы к источникам данных, BI-платформам и оркестраторам в вашем стеке.
• Стоимость и лицензия. Модель лицензирования (open-source против коммерческой), биллинг по потреблению против фиксированной стоимости, совокупная стоимость эксплуатации кластера.
• Импортозамещение. Для российского контура — наличие движка и вендора в реестре отечественного ПО и готовность к локальной поддержке.

Рекомендации по выбору

Выбор зависит от задачи, а не от рейтинга движков.

Для корпоративной аналитики с готовой коммерческой поддержкой и работы в российском контуре подходит CedrusData Engine: настройка проще, ответственность на вендоре, есть закрытие требований по импортозамещению. При этом CedrusData Engine обладает всем функционалом Trino, а ещё содержит значительно доработанное ядро с нативным движком на Rust, кэшированием и автоматической оптимизацией запросов.

Когда нужна максимальная гибкость и федерация к разнородным источникам, а в команде есть инженеры с экспертизой в распределённых системах, оправдан Trino: open-source, широкий набор коннекторов, но самостоятельная эксплуатация.

Для облачной аналитики выбор между Snowflake и Redshift Spectrum определяется текущей экосистемой: Redshift Spectrum логичен поверх данных в AWS S3, Snowflake — когда нужен managed-сервис с автомасштабированием и биллингом по потреблению. В каждом из этих случаев решение опирается на профиль нагрузки и стек, а не на абстрактное «какой движок лучше».

MPP в экосистеме VK Tech

MPP-архитектура в VK Tech собрана вокруг VK Data Platform — программного комплекса, предназначенного для построения и управления продуктами для работы с данными, каталогом услуг и сервисов, устанавливаемым на аппаратные мощности. Это готовое решение: инфраструктуру, движки и хранилище не нужно собирать вручную, они работают как PaaS под единым вендором.

В составе VK Data Platform роль MPP-движка выполняет CedrusData — инструмент для ad-hoc- и BI-запросов с массово-параллельной обработкой. Принцип работы классический: координатор разбивает SQL-запрос и распределяет части по вычислительным узлам, каждый из которых читает свой фрагмент данных из объектного хранилища, после чего результаты собираются воедино. Стандартный SQL и федеративные запросы к разным источникам доступны сразу, без дополнительной настройки.

Помимо Trino, платформа включает Managed ClickHouse для сверхбыстрых ad-hoc-запросов и Managed Spark для ETL-задач и машинного обучения. Ядро хранения — VK Object Storage, собственная разработка VK с сертификатом ФСТЭК 4-го уровня, входящая в число лидеров среди российских S3-провайдеров.

Преимущества использования MPP в VK Tech

• Готовое решение. VK Data Platform работает по PaaS-модели с единым вендором: движок и хранилище разворачиваются без ручной сборки кластера.
• Поддержка и эксплуатация. Сервис покрыт SLA и сопровождением на уровнях L1–L4, так что держать собственную команду по эксплуатации MPP-кластера не нужно.
• Интеграция с облачной инфраструктурой. VK Object Storage служит ядром хранения, managed-движки работают поверх него, а storage и compute масштабируются независимо. Холодные данные на S3 держат TCO низким даже при росте объёмов.

Ориентиром по производительности служит внутренний бенчмарк VK Tech, проведённый по методике TPC-DS — отраслевому стандарту оценки хранилищ, включающему 99 запросов. Стенд для обоих участников был одинаковым: 1 мастер и 3 сегмент-сервера, суммарно 64 CPU и 512 ГБ RAM, датасет объёмом 1 ТБ. Единственное различие — дисковая подсистема: Managed Trino работал на SSD high-iops в связке с S3, Greenplum — только на SSD high-iops. По результатам замеров лицензионный Greenplum прошёл все 99 запросов за 4 часа 56 минут, тогда как Managed Trino справился за 46 минут 47 секунд — то есть оказался быстрее в 6,34 раза. Результаты на иных данных, окружении и сценариях могут отличаться.

По стоимости картина схожая: согласно расчётам вендора за 30 дней без скидок, VK Data Platform обходится в 225 тыс. ₽ против 260 тыс. ₽ за лицензионный Greenplum. Итоговое соотношение performance/TCO у VK Data Platform выше в 7,3 раза.

Есть и дополнительный аргумент, актуальный для российского рынка: в мае 2024 года open-source-версия Greenplum была архивирована на GitHub после того, как VMware перешла под контроль Broadcom, — проект лишился обновлений и какого-либо развития. VK Data Platform, напротив, входит в реестр отечественного ПО через портфель VK Tech и продолжает развиваться при полноценной поддержке вендора.

Сценарии использования

• Аналитика транзакций. OLAP-запросы поверх больших объёмов транзакционных данных: агрегаты, срезы, отчётность по выгрузкам из OLTP-систем.
• Обработка логов. Сбор и анализ логов на S3 с запросами через Trino — без отдельного DWH под логовый поток.
• Машинное обучение. Managed Spark и JupyterHub с прямым доступом к сырым данным в VK Object Storage: подготовка датасетов и обучение моделей рядом с хранилищем.

Заключение

MPP-движки — рабочий инструмент для обработки больших данных в тех случаях, когда одиночный сервер уже не справляется с объёмом. Преимущества MPP-архитектуры раскрываются на OLAP-аналитике: массово-параллельная обработка, колоночное хранение и независимое масштабирование compute обеспечивают быстрый отклик на запросах к терабайтным датасетам. Монолитная СУБД при этом никуда не уходит — она остаётся оптимальным выбором для OLTP, транзакций и небольших объёмов данных, где параллелизм просто избыточен. Выбор между CedrusData Engine, Trino, Snowflake и другими движками высоконагруженных систем определяется объёмом данных, сценариями использования и требованиями к импортозамещению.

Если нужен готовый MPP-движок для аналитики больших данных, стоит обратить внимание на VK Data Platform с CedrusData в VK Cloud: Lakehouse поверх VK Object Storage с managed-движками и поддержкой вендора.