Разделение compute и storage: основа современной аналитики

Разделение compute и storage начинается с боли, знакомой каждому архитектору данных: аналитический запрос по таблице на 10 ТБ выполняется 40 минут, потому что вычисления и хранение находятся на одних и тех же серверах. Диск не успевает отдавать данные быстрее, чем узел успевает их обрабатывать, а нарастить мощность отдельно от места хранения нельзя — масштабируется всё сразу, вместе с ценой.

Современная архитектура данных решает проблему иначе. Данные хранятся в объектном хранилище S3, дёшево и практически без ограничений по объёму. Вычисления выполняются в отдельном кластере, который масштабируется независимо от хранилища: можно добавить узлы под пиковую нагрузку и убрать их, когда запросов нет. Хранение и обработка перестают конкурировать за одно и то же железо.

Расскажем, как устроена связка compute и storage в классических СУБД и почему она обходится дорого, расчёт экономии при переходе на разделённую архитектуру и то, как принцип реализован в CedrusData Engine поверх S3.

Связка compute+storage в классических СУБД

Классическая СУБД хранит данные на тех же серверах, где выполняются запросы, — в этом и корень ограничений монолитной архитектуры. В Teradata, Greenplum или Vertica на собственном железе диск, CPU и оперативная память находятся на одном узле. Масштабировать вычисления значит добавить узел с диском, масштабировать хранение значит сделать то же самое: отдельно одно от другого не получится. Похожая проблема решалась ещё на заре больших данных: подход lambda architecture появился как способ разделить платформу данных на пакетный и потоковый слои именно потому, что монолитная обработка не справлялась с ростом объёмов и разнородностью нагрузки.

У монолитной СУБД есть три признака:

• Ограничения масштабирования: покупка узла означает оплату CPU, RAM и дисков сразу, даже если нужна только одна из этих составляющих.
• Ограничения эластичности: нельзя добавить вычислительные мощности на два часа под пиковую нагрузку и снять их сразу после — провижининг рассчитан на постоянную нагрузку.
• Конкуренция за ресурсы: аналитический запрос конкурирует по CPU с ETL-процессом, и оба замедляются.

Что значит разделить compute и storage

Архитектурный принцип простой: хранение данных и вычисления над ними физически разнесены и масштабируются отдельно друг от друга. Данные лежат в объектном хранилище — S3 или аналогичном. Вычислительный кластер — это отдельный пул узлов без локальных дисков с данными. Запрос идёт так: compute-слой читает нужные данные из storage по сети, вычисляет результат и возвращает его. Нет активных запросов — compute-кластер останавливают, а данные в S3 продолжают храниться без изменений.

Эволюцию этого подхода в потоковой и пакетной обработке часто описывают через kappa architecture — практику big data, где единый поток обработки заменяет раздельные пакетный и потоковый конвейеры lambda-подхода.

Против разделённой архитектуры обычно возражают одним аргументом: сеть медленнее локального диска. На практике это компенсируют следующие механизмы, которые снижают объём читаемых/передаваемых по сети данных. Колоночные форматы Parquet и ORC поддерживают predicate pushdown — движок читает footer файла Parquet и по min/max-статистике row group пропускает группы строк, которые заведомо не подходят под условие запроса. Projection pushdown работает похожим образом, но на уровне колонок: из хранилища читаются только нужные поля, а не вся строка целиком. Кэш позволяет быстро получать уже прочитанные ранее данные, не передавая их по общей сети.

Преимущества: эластичность, стоимость, независимость

Принципы современной архитектуры данных строятся на трёх эффектах, которые разделение compute и storage даёт напрямую: оплата по факту использования, независимое масштабирование и изоляция нагрузок.

Платим за вычисления, храним дёшево в S3

S3 берёт плату за фактически занятый объём, provisioned capacity здесь не нужна. Compute-кластер запускается под нагрузку и останавливается в простое. Пример: ночной batch-расчёт поднимает кластер на 4 часа и выключает его сразу после завершения — счёт выставляется за эти 4 часа, а не за 24.

Разные задачи — разные кластеры

Один и тот же бакет S3 одновременно читают ETL-кластер на Spark, SQL-аналитика на CedrusData или Trino и BI-инструменты. Каждый из них масштабируется отдельно от других, конкуренции за CPU нет — только за полосу пропускания хранилища. На уровне организации данных та же логика заложена в подход data mesh: архитектура данных, где домены владеют своими продуктами данных, но опираются на общий слой хранения.

Монолит против разделённой архитектуры

S3 как фундамент storage-слоя

Storage-слой разделённой архитектуры почти всегда строится на объектном хранилище — оно даёт неограниченный объём без provisioned capacity и обходится дешевле SAN или NAS. Объектное хранилище масштабируется без верхнего предела по объёму, стоит дешевле локальных дисков и SAN/NAS, отдаёт высокую пропускную способность при параллельном чтении и совместимо с открытыми форматами — Parquet, ORC, Avro.

Открытые форматы: данные не привязаны к вендору

Данные в S3, записанные в Parquet и организованные через Apache Iceberg, читает любой движок: Spark, Trino, CedrusData, Flink, DuckDB. Vendor lock-in на уровне хранилища не возникает — формат остаётся открытым независимо от того, какой SQL-движок подключён сверху. В CedrusData поддерживают Apache Iceberg через CedrusData Catalog: это Iceberg REST-каталог, бесплатный, с метаданными в PostgreSQL или SQLite.

Trino как compute-слой: масштабирование независимо от данных

Trino — MPP SQL-движок для аналитики, который читает данные из S3, не перемещая и не копируя их на локальные диски. MPP-архитектура Trino строится на двух ролях. Coordinator принимает SQL-запрос, строит план выполнения и рассылает фрагменты плана worker-узлам. Каждый worker параллельно читает свою партицию данных из S3, выполняет вычисления на своей части и передаёт промежуточный результат обратно на coordinator, где данные агрегируются в финальный ответ. Масштабирование вычислений здесь означает добавление worker-узлов, а данные в S3 при этом не перемещаются ни на шаг.

Сколько стоит масштабирование вычислений

Узел монолитной СУБД несёт на себе CPU, RAM и SAN-диск одновременно, поэтому его цена включает стоимость хранения даже тогда, когда узел добавляется исключительно ради вычислительной мощности. Compute-only узел без локального хранения данных обходится дешевле full-stack узла той же вычислительной мощности — платить приходится только за CPU и RAM. Точную кратность экономии не приводим.

Разделение compute и storage в CedrusData Engine

В CedrusData этот принцип реализован как готовый дистрибутив: Trino в связке с S3-совместимым хранилищем, упакованные для production-развёртывания. CedrusData Engine — коммерческий дистрибутив Trino с нативным Rust-рантаймом, форк от Querify Labs. Разворачивается в Kubernetes или Docker за 10–20 минут, storage-слой — любое S3-совместимое хранилище, масштаб — от десятков терабайт до сотен петабайт. Продукт внесён в Реестр отечественного программного обеспечения под номером 15789. Оптимизатор запросов построен на cost-based подходе семейства Cascades.

Важно не путать рантаймы внутри продукта: Rust — у CedrusData Engine, а CedrusData Catalog написан на Java 21 и хранит метаданные в PostgreSQL или SQLite. Такая связка подходит для задач, которые описывают как архитектуру lakehouse для аналитики и архитектуру платформы данных в реальном времени: данные лежат в открытом формате в S3, а SQL-слой масштабируется отдельно от них.

CedrusData читает данные из любых источников

CedrusData поддерживает десятки коннекторов к внешним системам, среди ключевых — PostgreSQL, Greenplum, Teradata, Kafka, S3. Федеративные запросы позволяют выполнить JOIN между данными в S3 и таблицами PostgreSQL в одном SQL-запросе, без ETL и промежуточного копирования данных. MPP-архитектура при этом остаётся той же, что и в чистом Trino — coordinator и worker-узлы, только с оптимизатором и рантаймом CedrusData поверх.

Заключение

Разделение compute и storage снимает три ограничения монолитной СУБД: потолок масштабирования, оплату простаивающих ресурсов и конкуренцию нагрузок за compute-оборудование. S3 берёт на себя хранение данных в открытом формате, Trino и CedrusData — вычисления поверх него, и вместе они реализуют advanced data architecture в production на масштабе от десятков терабайт до сотен петабайт. Именно для задач вроде real-time аналитики (что это на практике, а не в теории) эта связка storage и compute и становится отправной точкой всей архитектуры.