Trino federation queries на собеседовании Data Engineer

Зачем federation

В реальной компании данные почти никогда не лежат в одном месте — они размазаны по разным системам, у каждой своя роль:

• Postgres (OLTP) — текущие заказы и оперативные данные приложения.
• Hive / Iceberg (data lake) — исторические данные, большие объёмы.
• Kafka — события в реальном времени.
• ClickHouse — аналитические витрины.
• Elasticsearch — логи и полнотекстовый поиск.

Trino — распределённый SQL-движок, который позволяет выполнить один запрос сразу по нескольким таким источникам, не перекладывая данные предварительно через ETL. В этом и есть federation: вы джойните таблицу из Postgres с таблицей из Iceberg одним SQL, как будто они лежат в одной базе. На собесе про это спрашивают, когда в вакансии есть Trino или Presto и слова «федерация источников», «ad-hoc аналитика» или «единый доступ к разрозненным данным».

Catalog и connector

Trino описывает каждый источник как catalog, а знает, как с ним общаться, через connector — плагин под конкретную систему.

catalog "postgres_prod"  (connector: postgresql)
catalog "iceberg_lake"   (connector: iceberg)
catalog "kafka_events"   (connector: kafka)
catalog "clickhouse_dwh" (connector: clickhouse)

Connector — это адаптер: он знает протокол источника, умеет читать его метаданные и транслировать часть SQL в родные запросы к нему. Catalog — это уже настроенное подключение к конкретному источнику через такой connector. В запросе к таблице обращаются по полному имени catalog.schema.table:

SELECT * FROM postgres_prod.public.users LIMIT 10;
SELECT * FROM iceberg_lake.warehouse.orders WHERE DATE = '2026-05-01';

Полезно проговорить на интервью, что смена источника в запросе — это просто смена префикса каталога, а не переписывание кода: SQL-диалект остаётся trino-шным, а connector сам транслирует его в специфику источника.

Cross-source join

Главная фишка federation — джойн таблиц из разных источников в одном запросе:

SELECT
  u.name,
  COUNT(o.id)   AS orders,
  SUM(o.amount) AS revenue
FROM postgres_prod.public.users u
JOIN iceberg_lake.warehouse.orders o ON u.id = o.user_id
WHERE u.country = 'RU'
  AND o.created_at >= DATE '2026-01-01'
GROUP BY u.name;

Здесь Trino читает пользователей из Postgres, заказы из Iceberg и джойнит их у себя — распределённо, в памяти воркеров. Важно понимать, что сам джойн выполняется в Trino, а не в источниках: данные из каждого каталога стягиваются в движок и соединяются там. Именно поэтому эффективность федеративного запроса упирается в то, сколько данных придётся вытянуть из источников, — и здесь на сцену выходит pushdown.

Pushdown

Чтобы не тянуть в движок лишнее, Trino старается «протолкнуть» части запроса в сам источник — это и называется pushdown. Идея простая: пусть фильтрацию и отбор колонок сделает источник, а в Trino приедет уже урезанный набор данных.

Пример. Условие WHERE u.country = 'RU' Trino отправит в Postgres, и оттуда вернутся только российские пользователи, а не вся таблица.

Что обычно проталкивается вниз:

• Предикаты — фильтры из WHERE, чтобы источник вернул только нужные строки.
• Проекции — конкретные колонки вместо SELECT *, чтобы не тащить лишние поля.
• Агрегации — часть агрегаций (зависит от connector'а и источника).
• Limits — ограничение числа строк.

Правило для собеса: чем больше работы удалось спустить в источники, тем меньше данных едет по сети и тем быстрее запрос. Если весь фильтр и агрегация ушли в Postgres или ClickHouse, Trino останется только собрать небольшой результат.

Когда работает плохо

Federation ломается на больших джойнах между источниками, когда промежуточный результат огромный и pushdown не спасает:

SELECT a.x, b.y
FROM big_postgres a
JOIN big_lake b ON a.id = b.id;

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

• Сначала фильтруйте меньшую сторону. Чем раньше отсечь строки, тем меньше данных участвует в джойне.
• Предагрегируйте в источнике. Если в ClickHouse можно свернуть данные до нужной гранулярности — сделайте это до федеративного джойна.
• Регулярные тяжёлые отчёты уносите в ETL. Данные, которые считаются каждый день, лучше один раз сложить в одно хранилище, а не гонять federation по расписанию.

Ключевой вывод, который ждёт интервьюер: Trino — инструмент для ad-hoc и интерактивной аналитики поверх разрозненных источников, а не замена ETL для ежедневных продакшн-агрегаций.

Связанные темы

• Trino и Presto для DE
• Hive Metastore для DE
• Iceberg deep для DE
• Spark RDD vs DataFrame для DE
• Подготовка к собесу Data Engineer

FAQ

Что такое catalog и connector в Trino?

Connector — это плагин под конкретный тип источника (postgresql, iceberg, kafka, clickhouse и т.д.), который умеет читать его метаданные и транслировать SQL в родные запросы. Catalog — настроенное подключение к конкретному источнику через такой connector. К таблице обращаются по полному имени catalog.schema.table.

Где выполняется cross-source join?

В самом Trino. Движок читает данные из каждого источника через его connector и джойнит их распределённо в памяти воркеров. Источники джойн не выполняют — они только отдают данные. Поэтому важно, чтобы через pushdown в Trino приезжало как можно меньше строк.

Что такое pushdown и почему он важен?

Pushdown — это когда Trino отправляет часть запроса (фильтры, выбор колонок, лимиты, иногда агрегации) в сам источник, чтобы тот вернул уже урезанные данные. Это резко сокращает объём передаваемых данных и ускоряет запрос. Если pushdown не сработал, Trino вынужден тянуть всё целиком и фильтровать у себя.

Подходит ли Trino для ежедневных продакшн-агрегаций?

Нет, это его слабое место. Тяжёлые регулярные отчёты с большими cross-source джойнами лучше считать через ETL, один раз сложив данные в одно хранилище. Trino сильнее в ad-hoc и интерактивных запросах поверх разных источников, где не нужно каждый день гонять один и тот же дорогой джойн.

Чем Trino отличается от Presto?

Trino — это форк проекта, ранее известного как PrestoSQL: команда основателей Presto продолжила разработку под новым именем. По архитектуре (coordinator + воркеры, federation через connectors, pushdown) они близки, но Trino активно развивается отдельно, и у него шире набор коннекторов и оптимизаций. На собесе достаточно знать, что это одно семейство движков с общими корнями.

Тренируйте Data Engineering — откройте тренажёр с 1500+ вопросами для собесов.