Сценарии: query federation, data lake analytics, интерактивная аналитика

В предыдущих уроках модуля мы разобрали, что такое Trino архитектурно и где он стоит среди других инструментов. Этот урок — итоговый и самый прикладной: мы разберём три главных сценария, ради которых компании внедряют Trino. Это не абстрактные «возможности из документации», а конкретные классы задач, каждый из которых снимает конкретную боль.

Понимать сценарии важно по двум причинам. Во-первых, это словарь, на котором обсуждают Trino: когда коллега говорит «мы используем Trino для федерации» или «у нас Trino поверх lakehouse», вы должны точно понимать, что за этим стоит. Во-вторых, именно через эти сценарии вы будете объяснять, зачем Trino нужен вашей команде, и без них Trino остаётся красивой технологией без понятного применения.

Три сценария: query federation, data lake analytics и интерактивная аналитика. Разберём каждый.

Сценарий 1: query federation

Query federation — это выполнение одного SQL-запроса поверх нескольких разных источников данных одновременно, без физического перемещения этих данных.

Боль, которую он снимает, знакома любой компании с зрелой инфраструктурой. Данные не лежат в одном месте. Заказы — в PostgreSQL приложения. События продукта — в Parquet на S3. Справочник пользователей — в MySQL. Логи — в Elasticsearch. Аналитику нужен отчёт, соединяющий заказы с событиями и со справочником. В классическом мире путь один: построить ETL-пайплайн, который физически перельёт данные из всех источников в одно хранилище, и только потом писать запрос. Это новый код, новая инфраструктура, дни или недели работы — ради, возможно, разового отчёта.

Trino убирает этот шаг. Каждый источник подключается к Trino как каталог. Дальше аналитик пишет обычный SQL, где в FROM и JOIN просто указывает таблицы из разных каталогов:

SELECT
    c.segment,
    count(DISTINCT o.order_id) AS orders,
    sum(o.amount)              AS revenue
FROM postgresql.public.orders o
JOIN mysql.crm.customers c
    ON o.customer_id = c.id
WHERE o.order_date >= DATE '2026-01-01'
GROUP BY c.segment;

Здесь postgresql.public.orders живёт в PostgreSQL, а mysql.crm.customers — в MySQL. Trino сам сходит в обе базы, прочитает нужные данные, соединит их в памяти кластера и вернёт результат. Источники не тронуты, ETL-пайплайн не построен.

Важная честная оговорка. Федерация удобна, но не бесплатна. Если запрос вынужден тащить через сеть огромные объёмы из медленного источника, он будет медленным — federation не делает медленный источник быстрым. Поэтому Trino так старается применять pushdown: переложить фильтрацию и агрегацию на сам источник, чтобы по сети ехало меньше. Где федерация уместна, а где превращается в антипаттерн — подробная тема модуля 11. Здесь главное: федерация снимает боль «построй ETL ради соединения источников».

Сценарий 2: data lake analytics

Data lake analytics — это быстрый SQL прямо поверх файлов данных, лежащих на объектном хранилище, без загрузки их в отдельную базу или хранилище.

Чтобы понять боль, вспомним, что такое data lake. Это подход, при котором данные хранятся как файлы в открытых форматах — Parquet, ORC — на дешёвом объектном хранилище: S3, GCS, Azure Blob. Хранить там петабайты дёшево. Но сами по себе файлы на S3 — это не таблицы: нет схемы, нет понятия строк и столбцов для SQL-движка, нет атомарных операций. Просто файлы в бакете.

Эту проблему решают открытые табличные форматы — прежде всего Apache Iceberg, а также Delta Lake и Hudi. Табличный формат — это слой метаданных поверх файлов: он описывает, какие файлы образуют таблицу, какая у неё схема, как она партиционирована, и даёт атомарность операций и историю изменений (снапшоты). Файлы плюс табличный формат превращают набор файлов на S3 в настоящую таблицу. Связку «дешёвое объектное хранилище + открытый табличный формат + SQL-движок поверх» называют lakehouse — она объединяет дешевизну data lake с табличной семантикой хранилища.

Trino в этой картине — движок запросов поверх lakehouse. Через коннекторы Iceberg, Delta Lake и Hive он читает табличные форматы напрямую и даёт по ним полноценный SQL: SELECT, джойны, агрегации, а с современными форматами — и запись, и time travel (запросы к историческим снапшотам таблицы).

Боль, которую снимает этот сценарий: не нужно копировать данные из дешёвого озера в отдельное дорогое хранилище, чтобы их анализировать. Данные остаются в открытых форматах на S3 — дёшево и доступно другим движкам, — а Trino даёт по ним быстрый SQL прямо на месте. Подробно lakehouse и Iceberg — это модули 9 и 10, а полноценную lakehouse-практику вы соберёте в первой лабе и в capstone.

Сценарий 3: интерактивная аналитика

Интерактивная аналитика — это быстрые ad-hoc SQL-запросы, на которые человек получает ответ за секунды и сразу пишет следующий.

Боль здесь — про скорость обратной связи. Аналитик исследует данные: посмотрел на выручку по регионам, увидел странность в одном регионе, тут же хочет копнуть глубже — разбить по неделям, отфильтровать сегмент, добавить ещё одно измерение. Это диалог с данными, и он работает, только если каждый запрос возвращается быстро. Если ответа ждать минуты, мысль теряется, а если запросы уходят в ночной пакетный пайплайн — диалога нет вообще, есть переписка с задержкой в сутки. То же самое с BI-дашбордами: пользователь открыл дашборд, поменял фильтр и ждёт обновления здесь и сейчас.

Trino создан ровно под это. Его pipelined-модель исполнения нацелена на минимальную задержку до результата: данные не материализуются на диск между этапами, а текут через конвейер операторов. MPP-параллелизм распределяет тяжёлый запрос по десяткам узлов. Запросы заранее не известны и постоянно меняются — Trino не требует их предопределять, любой корректный SQL исполняется сразу.

Боль, которую снимает сценарий: аналитик и BI-инструменты получают ответ за секунды, а не ждут ночного пайплайна. Это превращает работу с данными в живой диалог.

Как сценарии складываются вместе

Три сценария — не отдельные продукты, это грани одного движка, и в реальной платформе они часто работают одновременно. Очень типичная картина: основная масса данных лежит в lakehouse на Iceberg (сценарий 2), часть нужных данных остаётся в оперативных базах вроде PostgreSQL, и Trino через федерацию соединяет lakehouse с этими базами в одном запросе (сценарий 1), а аналитики и BI-дашборды работают со всем этим интерактивно, получая ответ за секунды (сценарий 3). Один движок, один SQL — три боли сняты сразу.

Чего Trino в этих сценариях не делает

Чтобы картина была честной, повторим границы из прошлых уроков в привязке к сценариям. Trino не заменяет OLTP-базу — ни один из трёх сценариев не про транзакционную нагрузку. Trino не заменяет тяжёлый пакетный ETL — для многочасовых отказоустойчивых джобов остаётся Spark. Trino не делает медленный источник быстрым — федерация поверх медленной базы будет медленной. И Trino не хранит данные — во всех трёх сценариях данные живут снаружи, а Trino лишь движок поверх них. Сценарии показывают, где Trino силён; границы показывают, где нужны другие инструменты.

Попробуй сам

Откройте на сайте trino.io страницу документации «Use cases» (overview/use-cases) и сравните, как три сценария сформулированы там, с тем, как мы разобрали их в уроке. Отметьте, что в официальной формулировке вынесено на первый план.

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