😮На Trino строят:
🔘ad-hoc аналитику поверх data lake
🔘витрины и BI (Presto/Trino + Superset/Tableau)
🔘федеративные запросы между DWH и OLTP
🔘feature-engineering для ML
🔘проверку и валидацию данных без ETL
🤔Как Trino устроен ?
✏️MPP-архитектура (Coordinator + Workers)
Trino — это распределённый движок.
➡️Coordinator парсит SQL, строит план запроса и управляет выполнением
➡️Workers исполняют куски плана (stages / tasks) параллельно
➡️Запрос автоматически масштабируется на десятки и сотни нод — чем больше воркеров, тем выше throughput.
➡️Федеративные запросы через коннекторы
Trino не хранит данные сам. Он читает их через connectors:
Hive, Iceberg, Delta, Kafka, ClickHouse, Postgres и десятки других.
Можно спокойно написать:
SELECT *
FROM hive.events e
JOIN postgres.users u ON e.user_id = u.id
JOIN clickhouse.orders o ON o.user_id = u.id;
И всё это выполнится в одном SQL-запросе.
➡️ Векторизованное выполнение и columnar-подход
Trino читает данные батчами, работает с колонками и активно использует CPU cache.
Минимум overhead — максимум скорости для агрегаций, join’ов и window-функций.
Поэтому Trino отлично чувствует себя на Parquet / ORC / Iceberg.
➡️Умный query planner и cost-based optimization
Trino умеет:
✅pushdown фильтров и агрегаций в источники
✅reordering join’ов
✅dynamic filtering (сильно ускоряет star-schema)
✅spill на диск при нехватке памяти
В результате сложные аналитические запросы выполняются на порядки быстрее, чем «в лоб».
➡️Memory-based execution (и за это его любят и боятся)
Trino очень быстрый, потому что активно использует память.
Но:
плохо настроенные запросы → OOM
JOIN без фильтров → боль
Поэтому в проде важны:
memory limits, query queues, resource groups и грамотный SQL.
💡Когда Trino — лучший выбор?
🔘данные уже лежат в data lake
🔘нужен быстрый SQL без ETL
🔘много источников и много аналитиков
🔘BI и ad-hoc важнее batch-процессинга
Было интересно? Ставьте 🔥