Введение в Trino

Краткая история

Проект родился как форк PrestoDB. Чтобы избежать путаницы с оригинальным проектом PrestoDB (который развивался компанией Meta), сообщество PrestoSQL в 2020 году решило выделиться в независимый проект под названием Trino. Сегодня Trino развивается под эгидой некоммерческого фонда Trino Software Foundation и обладает одним из самых активных и быстрорастущих комьюнити в мире данных.

Архитектура в двух словах

Архитектура Trino построена по принципу master-worker и масштабируется горизонтально (как хороший ресторан: один шеф-повар командует, а много поваров готовят параллельно):

1. Coordinator (Координатор): Принимает SQL-запрос от клиента, парсит его, оптимизирует план выполнения и распределяет задачи (тот самый менеджер, который раздает ТЗ и пьёт кофе).
2. Workers (Воркеры): Получают задачи от координатора, подключаются к источникам данных, считывают нужные блоки информации и выполняют вычисления (это те самые трудяги, которые делают всю тяжёлую работу).

Запрос разбивается на стадии (stages), которые выполняются параллельно на множестве воркеров, что обеспечивает высокую скорость обработки даже на больших объемах данных (как если бы каждый повар готовил только один ингредиент, а в итоге получался целый ужин).

Схема архитектуры

Ниже представлена упрощенная схема того, как запрос проходит через систему:

graph LR
    Client[🖥️ Клиент / BI-инструмент / dbt] -->|SQL Запрос| Coordinator[⚙️ Координатор]
    Coordinator -->|План задач| Worker1[👷 Воркер 1]
    Coordinator -->|План задач| Worker2[👷 Воркер 2]
    Coordinator -->|План задач| Worker3[👷 Воркер 3]

    Worker1 -->|Чтение/Запись| Source1[(🗄️ Источник 1<br/>S3 / Hive)]
    Worker2 -->|Чтение/Запись| Source2[(🗄️ Источник 2<br/>PostgreSQL)]
    Worker3 -->|Чтение/Запись| Source3[(🗄️ Источник 3<br/>ClickHouse)]

    Worker1 -->|Результат| Coordinator
    Worker2 -->|Результат| Coordinator
    Worker3 -->|Результат| Coordinator
    Coordinator -->|Ответ| Client

Клиент отправляет SQL-запрос Координатору, который распределяет нагрузку между Воркерами. Воркеры обращаются напрямую к Источникам данных и возвращают результаты для агрегации.

Почему кролик-космонавт?

Я не знаю. Говорят, так решило коммьюнити. Есть ли у работников Trino связь с космосом? Вызывают ли они Хъюстон, когда дропают таблицу? Надо ли их поздравлять 12 апреля? Решайте сами.

Преимущества Trino для Data-инженера

Интеграция Trino в SubQuery открывает новые горизонты для построения архитектуры данных. Почему мы решили поддержать именно этот движок? Потому что для Data-инженера Trino — это не просто еще один инструмент выполнения запросов, а стратегический актив. Вот ключевые причины, почему стоит присмотреться к связке dbt + Trino.

1. Федеративные запросы (Query Federation)

Это главная киллер-фича Trino. Забудьте о сложных ETL-процессах, когда нужно сначала перегнать данные из одной системы в другую, чтобы просто соединить таблицы (это как собирать пазл, предварительно перерисовав все его части на один холст). Trino позволяет делать JOIN между источниками разной природы в рамках одного SQL-запроса.

Представьте ситуацию: вам нужно обогатить транзакции из PostgreSQL данными о кликах из S3 и профилями пользователей из MongoDB. В классическом подходе это потребовало бы создания промежуточного хранилища. С Trino вы пишете обычный SQL-запрос в dbt-модели, а движок сам маршрутизирует данные между коннекторами (как курьер-мультипоток, который за один забег забирает посылки из трёх разных стран). Это ускоряет разработку и снижает нагрузку на инфраструктуру.

2. Производительность на основе MPP

Trino построен на архитектуре Massively Parallel Processing (MPP). Это означает, что запросы разбиваются на множество задач, которые выполняются параллельно на разных узлах кластера (как если бы вы разрезали пиццу на 8 кусков и раздали друзьям — каждый съедает свой кусок одновременно, и пицца исчезает мгновенно). Для Data-инженера это translates в высокую скорость обработки больших объемов данных. Даже сложные аналитические запросы, которые раньше могли выполняться минутами, в Trino часто отрабатываются за секунды, что делает итерации в dbt-проектах значительно быстрее (и оставляет больше времени на ту самую пиццу).

3. Стандарт ANSI SQL

Вам не придется учить новый синтаксис или переписывать логику трансформаций. Trino строго следует стандарту ANSI SQL (это как английский язык: если вы знаете basics, вас поймут и в Лондоне, и в Нью-Йорке, и в нашем кластере Trino).

• Для аналитиков: Порог входа минимален (не нужно вспоминать диалекты типа «а как здесь делать PIVOT?»).
• Для инженеров: Код, который вы написали для dbt на Snowflake или BigQuery, с минимальными правками (или вовсе без них) заработает на Trino. Это обеспечивает легкую миграцию и гибкость в выборе инфраструктуры без риска технического долга на уровне SQL-кода (и без ночных кошмаров, где WITH вдруг превращается в WITH RECURSIVE).

4. Богатая экосистема коннекторов

Trino известен своей способностью подключаться практически ко всему (если бы существовал коннектор к холодильнику, Trino мог бы рассказать, сколько там осталось пива). В SubQuery вы получаете доступ к десяткам нативных коннекторов «из коробки». Помимо упомянутых выше, это поддержка современных форматов озер данных (Iceberg, Delta Lake), работу с очередями событий (Kafka), классическими хранилищами (Hive) и многими другими системами. Вы больше не ограничены стенами одного хранилища данных (теперь ваши данные могут «дружить» через границы систем, как пени-палы из разных стран).

Почему это критически важно для dbt?

dbt живет за счет SQL, а Trino дает SQL «сверхспособности» (представьте, что ваш SQL внезапно научился телепортироваться между базами данных). Главная философия dbt — трансформация данных средствами SQL. Добавляя поддержку Trino, мы убираем главное ограничение этого подхода: необходимость предварительного копирования всех данных в единое хранилище (Data Warehouse).

Теперь dbt-модели могут работать напрямую с данными там, где они лежат. Вы получаете единую точку доступа ко всем данным компании, сохраняя при этом все преимущества версионирования, тестирования и документирования, которые дает dbt. Это шаг к настоящей архитектуре Data Mesh, где данные доступны везде, а управляет ими единый слой трансформации.

Простой пример — JOIN через три системы в одной dbt-модели:

-- dbt-модель: enriched_transactions.sql-- Объединяем транзакции из PostgreSQL и логи из S3SELECT    t.id,    t.amount,    t.user_id,    l.click_time,    l.page_url,    u.user_segmentFROM postgres_schema.transactions tLEFT JOIN s3_catalog.click_logs l    ON t.user_id = l.user_id    AND l.event_date = t.transaction_dateLEFT JOIN mysql_catalog.users u    ON t.user_id = u.idWHERE t.status = 'completed'

Этот запрос выполняется одним движением — Trino сам «сбегает» в PostgreSQL и в S3, соберёт данные и вернёт результат. Никаких ETL, никаких промежуточных таблиц. Просто SQL, как вы и любите, но с суперсилой.

Trino vs. PrestoDB и Spark SQL: Когда что выбрать?

Вы могли слышать о других движках для распределённых запросов — давайте быстро расставим точки над «i» (и над «JOIN»).

• Trino vs. PrestoDB: Это как близнецы, которые разошлись после университета. Оба унаследовали общую кодобазу, но сегодня Trino фокусируется на аналитических workload'ах, федеративных запросах и активном комьюнити. PrestoDB больше ориентирован на внутренние нужды Meta. Если вам нужны федеративные запросы и активное развитие — Trino.
• Trino vs. Spark SQL: Spark SQL — это тяжёлая артиллерия для сложных ETL-пайплайнов с поддержкой Machine Learning и Graph-обработки. Trino — это снайпер для быстрых интерактивных запросов. Нужно подготовить данные для ML-модели? Возможно, Spark SQL. Нужно быстро ответить на бизнес-вопрос, соединив данные из пяти разных источников? Определённо Trino.

Короче: если вам нужно «спросить» данные — Trino. Если нужно «перемешать и испечь» данные — Spark. А если вы хотите и то, и другое — можно использовать оба (данные же не спросят, кто их обрабатывает).

Как начать работать с Trino: Два пути

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

Self-hosted

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

trino:  image: trinodb/trino  container_name: trino  restart: unless-stopped  networks:    iceberg-net:  ports:    - 8080:8080  volumes:    - './catalog:/etc/trino/catalog'    - './config/log.properties:/etc/trino/log.properties'  env_file:    - .env

И некоторые настройки Trino

# ./config/log.propertiesio.trino=ERRORio.trino.plugin.iceberg=ERRORio.trino.parquet=ERROR

Managed Service

Выбор для команд, которые хотят фокусироваться на аналитике и бизнес-логике, а не на поддержке инфраструктуры.

Мы являемся партнерами по внедрению Yandex Cloud, так что в первую очередь рекламирую Yandex Managed Service for Trino.

Есть варианты и у других вендоров:

• Cloud.ru - Evolution Managed Trino
• VK - Cloud Trino
• MTS - MWS Data Query

Какой путь выбрать?

Если у вас есть ресурсы на поддержку инфраструктуры и нужны специфические настройки безопасности — выбирайте Self-hosted. Если приоритет — скорость запуска и отсутствие головной боли с серверами — ваш выбор Managed Service.

🔧 Подключение Trino к SubQuery

1. Создайте новый проект
2. Перейдите в dbt
3. Заполните Хост, Порт, БД, Логин, Пароль
4. По желанию укажите настройки для адаптера
5. Готово!

Всё действительно укладывается в 5 минут (если не считать время на выбор, какой чай пить во время настройки).

Хорошая новость в том, что наш сервис поддерживает работу с Trino независимо от выбранного пути. Мы абстрагируем сложность подключения, позволяя вам писать качественные dbt-модели, пока инфраструктура работает на вас.

🚀 Готовы попробовать?

Не нужно ждать понедельника, полнолуния или завершения квартала. Попробуйте Trino в SubQuery прямо сейчас — это бесплатно на старте, а подключение займёт те самые 5 минут (мы засекали).