Trino

Что такое Trino?

Trino — это распределённый SQL-движок для интерактивных запросов по данным, которые лежат в разных системах.

Проще говоря, Trino нужен, когда:

данные лежат в PostgreSQL, S3, Iceberg, Hive, ClickHouse и других источниках;
нужен один SQL поверх разных хранилищ;
не хочется заранее тащить всё в одну БД или строить тяжёлый ETL только ради анализа;
важно быстро читать данные и объединять их между собой.

Trino — это не хранилище и не СУБД. Он не хранит данные как база и не заменяет DWH. Он читает данные из источников, объединяет их и отдаёт результат пользователю.

Какая проблема решается

На практике данные часто лежат в разных местах:

реляционные БД;
озёра данных в S3;
таблицы Iceberg / Hive;
NoSQL-хранилища;
иногда кэши или внешние сервисы.

Без Trino приходится либо:

собирать всё в одно хранилище;
либо писать много отдельных выгрузок и скриптов;
либо руками соединять данные на стороне приложения.

Trino даёт другой подход: один SQL для множества источников.

Как выглядит запрос

SELECT
    o.order_id,
    o.order_dt,
    c.customer_name
FROM iceberg.analytics.orders o
JOIN postgres.public.customers c
    ON o.customer_id = c.id
WHERE o.order_dt >= DATE '2026-07-01';

Здесь:

iceberg.analytics.orders — таблица в каталоге iceberg;
postgres.public.customers — таблица в каталоге postgres;
Trino сам строит план выполнения и забирает данные из обоих источников.

Базовая терминология

Catalog

Catalog — это подключённый источник данных.

Например:

postgres;
iceberg;
hive;
s3 и т.д.

Schema

Schema — это логическая группа таблиц внутри catalog.

Table

Table — это уже конкретная таблица, которую Trino видит через connector.

Типичный путь выглядит так:

catalog.schema.table

Архитектура Trino

У Trino есть две ключевые роли:

Coordinator

Coordinator принимает SQL, разбирает его, строит план и распределяет работу.

Он отвечает за:

парсинг запроса;
анализ и оптимизацию;
разбиение запроса на стадии;
распределение задач между worker-ами.

Workers

Workers выполняют саму работу:

читают данные из источников;
фильтруют строки;
считают агрегации;
делают join;
передают промежуточные результаты дальше.

Именно поэтому Trino хорошо подходит для распределённых запросов.

Как выполняется запрос

Очень упрощённо запрос проходит такие этапы:

Пользователь отправляет SQL в Trino.
Coordinator строит план.
Запрос разбивается на stages.
Stages делятся на tasks.
Tasks работают на workers.
Каждый worker читает свои splits.
Результат собирается обратно и отдаётся пользователю.

Что такое split?

Split — это маленький кусок данных, который можно читать параллельно.

Именно splits позволяют Trino распараллеливать чтение и не упираться в один поток.

Почему Trino быстрый

Trino старается не тащить лишние данные туда-сюда по сети.

Для этого он использует:

projection pushdown — читает только нужные колонки;
predicate pushdown — проталкивает фильтры в источник;
aggregation pushdown — если connector умеет, часть агрегаций делается на стороне источника;
parallel execution — чтение и обработка идёт параллельно на workers.

Pushdown на практике

Если запросу нужны только 3 колонки из 50, Trino постарается забрать только их.

Если есть условие WHERE order_dt >= '2026-07-01', Trino может протолкнуть фильтр в источник, чтобы не читать лишнее.

Это особенно важно для больших таблиц в S3, Iceberg и других lakehouse-источниках.

Слишком много мелких файлов

Когда Trino читает данные из Data Lake или Iceberg, проблема часто не в SQL, а в самих файлах.

Если файлов слишком много и они слишком маленькие, запросы становятся медленнее:

больше метаданных;
больше обращений к storage;
больше накладных расходов на планирование и чтение.

Поэтому рядом с Trino обычно нужна нормальная гигиена данных:

compact / optimize мелких файлов;
удаление старых snapshot-ов;
очистка orphan-файлов;
контроль размера партиций.

Trino сам это не чинит, он только читает то, что ему отдали источники.

Как читать план запроса

Для Trino очень важны EXPLAIN и EXPLAIN ANALYZE.

EXPLAIN
SELECT *
FROM iceberg.analytics.orders;
 
EXPLAIN ANALYZE
SELECT *
FROM iceberg.analytics.orders;

Что смотреть в плане

какие таблицы читаются;
где происходит join;
где стоит exchange и почему данные двигаются между workers;
какие узлы самые тяжёлые;
совпадают ли оценка и реальное число строк;
есть ли filter и pushdown.

`EXPLAIN` vs `EXPLAIN ANALYZE`

EXPLAIN показывает план и оценку;
EXPLAIN ANALYZE показывает реальное выполнение с фактическими метриками.

Если план выглядит нормально на бумаге, но ANALYZE показывает огромный рост строк или дорогой exchange, значит узкое место не там, где казалось сначала.

Что важно понять из архитектуры

Главная идея Trino простая:

SQL пишется один;
источников может быть много;
Coordinator строит план;
Workers исполняют его параллельно;
максимум фильтрации и чтения стараются протолкнуть ближе к источнику.

Когда Trino особенно полезен

Trino хорошо подходит, если нужно:

быстро объединить данные из разных систем;
делать ad-hoc аналитику;
читать lakehouse-таблицы без промежуточной загрузки;
смотреть данные через один SQL-интерфейс;
уменьшить количество ручных выгрузок.

Когда Trino не заменяет хранилище

Trino не подходит как замена DWH, если тебе нужно:

хранить данные как основную систему записи;
строить сложные витрины с тяжёлой трансформацией;
делать постоянную загрузку и управление качеством данных;
хранить бизнес-логику только внутри SQL-движка.

В таких задачах Trino обычно работает поверх уже подготовленных таблиц и файлов.

Коротко

Trino — это распределённый SQL-движок для запросов по разным источникам.
Он использует catalog / schema / table и работает через connectors.
Запрос выполняют coordinator и workers.
Важные слова: stages, tasks, splits, pushdown.
EXPLAIN и EXPLAIN ANALYZE нужны, чтобы понимать, где запрос дорогой.
Trino не хранит данные, а читает их из источников и объединяет в один результат.

Продвинутый Spark Теория про dbt