Когда Trino, когда Spark SQL, когда хранилище
Trino редко работает в одиночку. В реальной data-платформе он соседствует с другими инструментами: Apache Spark, классическим хранилищем вроде Snowflake или BigQuery, а часто и с PostgreSQL. У начинающего инженера возникает естественный вопрос: эти инструменты конкурируют между собой? Когда выбрать один, когда другой? И не получится ли, что Trino делает то же, что Spark, только хуже или лучше?
Ответ важно дать точно, потому что неправильный выбор инструмента — это дорогая ошибка на уровне архитектуры платформы. Этот урок даёт честную систему координат: что каждый инструмент делает хорошо, чего не делает, и как выбирать под конкретную задачу. Trino, Spark и хранилище — не конкуренты «кто лучше», а инструменты с разными сильными сторонами, которые часто стоят в одной платформе рядом.
Первая ось координат: OLTP против OLAP
Прежде чем сравнивать Trino со Spark, нужно отсечь то, к чему Trino вообще не относится. Это разделение OLTP и OLAP.
OLTP (online transaction processing) — транзакционная нагрузка приложений: создать заказ, обновить баланс, прочитать профиль по id. Запросы короткие, точечные, их много, нужны транзакции и низкая задержка на одну операцию. Это мир PostgreSQL, MySQL, Oracle.
OLAP (online analytical processing) — аналитическая нагрузка: посчитать выручку по регионам за год, построить воронку, найти аномалии. Запросы сканируют миллионы и миллиарды строк, агрегируют, джойнят; их меньше по количеству, но каждый тяжёлый. Это мир Trino, Spark, аналитических хранилищ.
Вывод первой оси: Trino живёт целиком в мире OLAP. Сравнивать Trino с PostgreSQL по принципу «что лучше» бессмысленно — они решают разные задачи. Если задача транзакционная, ответ всегда классическая база, и Trino из рассмотрения выпадает сразу. Реальный выбор — Trino, Spark или хранилище — возникает только внутри OLAP.
Самая дорогая ошибка выбора — попытка обслуживать OLTP-нагрузку аналитическим движком или наоборот. Trino на потоке точечных запросов по id будет неэффективен и не даст транзакций; PostgreSQL на запросе, сканирующем миллиард строк, ляжет. Сначала определите класс нагрузки, и только потом выбирайте инструмент внутри класса.
Вторая ось: интерактивные запросы против пакетной обработки
Внутри OLAP первое и главное различие между Trino и Spark — это интерактивность против пакетности.
Trino заточен под интерактивные запросы. Его модель исполнения — pipelined: данные текут через операторы потоком, без материализации промежуточных результатов на диск. Цель — отдать результат как можно быстрее, в идеале за секунды. Это идеально для дашбордов, ad-hoc исследования данных, аналитики, где человек ждёт ответа здесь и сейчас. Цена этой модели — по умолчанию нет fault tolerance: если воркер падает посреди запроса, запрос падает целиком. Для коротких интерактивных запросов это приемлемо — просто перезапустить.
Spark заточен под пакетную обработку. Его классическая модель материализует промежуточные результаты, что позволяет повторить упавший кусок работы, не начиная всё заново. Это даёт встроенную отказоустойчивость и делает Spark пригодным для многочасовых ETL-джобов на огромных объёмах, где сбой узла за пять часов работы недопустим. Цена — материализация добавляет накладные расходы, поэтому на коротких запросах Spark обычно проигрывает Trino по задержке. Кроме того, Spark — это не только SQL: это полноценный фреймворк с DataFrame API и поддержкой произвольного кода, в том числе для машинного обучения.
Shuffle в Spark: самая дорогая операцияСтоит оговориться: граница не абсолютная. У Trino есть опциональный fault-tolerant execution для длинных запросов (модуль 13), а Spark научился работать достаточно быстро для части интерактивных сценариев. Но по умолчанию и по основному назначению Trino — про интерактив, Spark — про пакет. Это рабочее эвристическое правило.
Третья ось: где Trino, а где хранилище
Третий участник — классическое аналитическое хранилище: Snowflake, BigQuery, Redshift. Здесь разница не в скорости, а в модели владения данными.
Хранилище — это связка storage и compute в одном продукте: данные загружаются внутрь, в проприетарный формат хранилища, и оно же их обрабатывает. Это даёт удобство и предсказуемую производительность, но данные оказываются заперты в одном продукте.
Trino, как мы знаем из прошлых уроков, — чистый compute без своего storage. Данные остаются снаружи, в открытых форматах на объектном хранилище, и Trino — лишь движок поверх них.
ClickHouse: смена ментальных моделей Это даёт открытость и федерацию, но требует, чтобы кто-то отдельно занимался самими данными и их форматом.
| Критерий | Классическое хранилище | Trino (lakehouse-подход) |
|---|---|---|
| Где данные | Внутри, проприетарный формат | Снаружи, открытые форматы (Parquet, Iceberg) |
| Storage и compute | Связаны | Разделены |
| Доступ к данным | Через само хранилище | Любым движком, понимающим формат |
| Запрос к нескольким источникам | Сначала загрузить всё внутрь | Федерация без перемещения данных |
| Кто отвечает за данные | Хранилище | Вы (формат, партиционирование, обслуживание) |
Это не противопоставление «лучше/хуже». Часто хранилище и Trino сосуществуют: хранилище — для основного, тщательно смоделированного слоя, Trino — для федеративного доступа к данным, которые в хранилище не лежат, или для аналитики прямо поверх data lake без загрузки.
Как выбирать: рабочая логика
Сведём три оси в практический порядок принятия решения. Когда перед вами задача, проходите по осям сверху вниз.
Шаг 1. Какой класс нагрузки? Если задача транзакционная (OLTP) — это классическая база (PostgreSQL, MySQL), и Trino со Spark из рассмотрения выпадают. Дальше — только если задача аналитическая (OLAP).
Шаг 2. Интерактив или пакет? Если нужен быстрый ответ человеку — дашборд, ad-hoc запрос, исследование, интерактивная аналитика — это сильная сторона Trino. Если это тяжёлый многочасовой ETL, пайплайн трансформаций, машинное обучение, обработка, где критична отказоустойчивость — это сильная сторона Spark.
Шаг 3. Откуда данные и кто ими владеет? Если данные лежат в открытых форматах на data lake, или нужно соединить несколько разных источников одним запросом без их перемещения — это сценарий Trino. Если нужен закрытый управляемый аналитический слой с предсказуемой производительностью и данные не жалко держать внутри одного продукта — это сценарий хранилища.
В реальной платформе ответ — почти всегда «и то, и другое». Типичный современный стек: данные в открытых форматах на объектном хранилище; Spark делает тяжёлые пакетные трансформации и подготовку данных; Trino даёт быстрый интерактивный SQL и федерацию поверх того же data lake; классическое хранилище или PostgreSQL закрывают то, для чего нужны они. Инструменты дополняют друг друга, а не вытесняют.
Где Trino однозначно лучший выбор
Чтобы закрепить, назовём сценарии, где Trino — именно тот инструмент, и альтернативы проигрывают.
Первый — федерация: нужно соединить данные из нескольких разных источников одним запросом, не строя ETL ради этого. Хранилище потребовало бы сначала всё в себя загрузить; Trino делает это на месте.
Второй — интерактивная аналитика поверх data lake: данные уже лежат в Parquet или ORC на объектном хранилище через Iceberg, нужен быстрый SQL по ним без копирования в отдельное хранилище.
Третий — ad-hoc исследование и BI-дашборды: человеку нужен ответ за секунды, запросы заранее не известны и постоянно меняются. Pipelined-модель Trino создана ровно для этого.
В следующем уроке мы разберём эти сценарии Trino подробно и предметно.
Типичные ошибки выбора
Полезно назвать и обратную сторону — ошибки, которые чаще всего совершают при выборе инструмента, потому что узнавать их в чужих и своих решениях так же важно, как знать правильную логику.
Ошибка «один инструмент на всё». Команда выбирает Trino (или Spark, или хранилище) и пытается решать им вообще все задачи с данными. Результат предсказуем: на части задач инструмент работает плохо, потому что не для них создан. Trino, которым пытаются делать тяжёлый отказоустойчивый ETL, будет ронять долгие джобы; Spark, которым обслуживают интерактивные дашборды, будет медленно отвечать. Лекарство — принимать решение на уровне отдельной задачи, проходя по трём осям, а не выбирать «главный инструмент платформы» раз и навсегда.
Ошибка «модно, значит подходит». Инструмент выбирают потому, что о нём много говорят, а не потому, что он решает конкретную задачу команды. Trino — отличный движок, но если у компании одна небольшая база и весь анализ — это десяток запросов к ней, разворачивать распределённый MPP-кластер незачем: с задачей справится сама эта база. Технология должна следовать за задачей, а не наоборот.
Ошибка «Trino быстрый, давайте всё в Trino». Из того, что Trino быстр на аналитике, иногда делают вывод, что и транзакционную нагрузку стоит перевести на него. Это возврат к первой оси: OLTP — не его класс задач, и скорость на аналитике тут ни при чём. Быстрый аналитический движок не становится от этого хорошей транзакционной базой.
Общий корень всех трёх ошибок — выбор инструмента в отрыве от задачи. Дисциплина «сначала задача и три оси, потом инструмент» защищает от каждой из них.
Попробуй сам
Возьмите четыре конкретные задачи и для каждой определите подходящий инструмент, проходя по трём осям выбора из урока:
- Дашборд, который аналитик открывает по 50 раз в день и ждёт обновления за секунды.
- Ночной ETL-джоб, который 4 часа пересчитывает миллиарды событий и не должен падать целиком из-за сбоя одного узла.
- Разовый отчёт, соединяющий таблицу из PostgreSQL с Parquet-файлами на S3.
- Сервис интернет-магазина, который записывает заказы и читает корзину пользователя по id.
Для каждой задачи запишите выбранный инструмент и обоснование по осям: класс нагрузки, интерактив или пакет, владение данными. Затем придумайте пятую задачу из своего опыта и проведите её через тот же анализ.