Наверняка многие из вас слышали про эту технологию в последнее время, её часто видно на митапах, поэтому давайте разберемся, почему же Trino сейчас становится таким популярным?
Trino (раньше назывался PrestoSQL) — федеративный SQL-движок для запросов к разным источникам: S3, Iceberg, Hive, PostgreSQL, Kafka и др. Он не хранит данные, а исполняет запросы напрямую — туда, где данные лежат. Сейчас часто используют его именно в Lakehouse архитектуре, как основной инструмент взаимодействия с данными.
Давайте же разберемся, из чего он состоит.
Coordinator — планирует запросы
Главный процесс в Trino: принимает SQL-запрос, строит логический и физический план, применяет оптимизации (pushdown, partition pruning, join-стратегии), разбивает план на фрагменты и распределяет их воркерам
Coordinator чем-то похож на Spark Driver — но проще: не участвует в shuffle, не управляет состоянием, не держит данные. Его задача — распланировать и отдать.
Workers — исполняют задачи
Воркеры получают части плана и исполняют их: читают данные, фильтруют, джойнят, считают. Stateless — не кэшируют и не сохраняют контекст между запросами. Просто получили задачу, сделали, отдали результат.
В отличие от executors в Spark, Trino workers не привязаны к приложению или сессии. Один запрос — одна жизнь.
Catalogs — подключение к источникам
Trino сам по себе ничего не знает про таблицы. Всё взаимодействие с данными идёт через каталоги. Каталог — это конфигурация, в которой описано, где лежат данные, как их читать и какие метаданные использовать (HMS, Iceberg REST, JDBC и т. д.).
Это одно из ключевых отличий от Spark. В Spark чаще всего используется один Hive Metastore как основной каталог, а подключения к внешним базам делаются отдельно — через JDBC внутри SparkSession. В Trino — наоборот: всё подключается через каталоги. Хочешь работать с PostgreSQL? Подключаешь каталог postgres.properties. Нужно S3 с Iceberg? Заводишь каталог iceberg.properties. Trino обрабатывает всё единообразно.
Пример:
SELECT o.user_id, o.order_id, u.region
FROM postgres.sales.orders o
JOIN iceberg.analytics.users u
ON o.user_id = u.user_id
WHERE u.region = 'eu-west'
Здесь Trino:
1. читает таблицу orders из PostgreSQL
2. читает таблицу users в формате iceberg в S3
3. применяет фильтр (Trino умеет передавать фильтры в источники данных)
5. делает join
6. возвращает результат
Это одна из главных причин использовать Trino. В Spark такое возможно, но требует ручного объединения DataFrame’ов, подключения JDBC, прописывания схем и довольно много обвязки.
Кроме того, он прекрасно интегрирован с Iceberg(как и Spark): умеет не только читать данные, но и модифицировать их — в связке с Iceberg доступны DELETE, MERGE, UPDATE.
Поэтому Trino стоит использовать как единую точку входа в ваш lakehouse, а также инструмент для построения BI-отчетов и дашбордов (он хорошо работает с Superset, Metabase и другими)
Тrino + Iceberg это сейчас довольно модная связка, которую обкатывают многие компании, и сами по себе технологии активно развиваются (можно хотя бы по активности на GitHub удостовериться). Поэтому рекомендую поизучать, ведь она все чаще встречается в архитектуре и всплывает на собеседованиях.
Полезно и в теории, и в проде 🤓
А также рекомендую подписаться на наш канал, чтобы первыми узнавать про всё самое интересное в Big Data 😎
Ставьте ❤️ если хотите еще разборов технологий
Ставьте 🔥 если уже работали с Trino
Также записывайтесь на наш курс по инженерии данных, чтобы стать крутым DE 🔥
@bigdata_postupashki