Хватит гонять данные - как Trino запрашивает Big Data прямо на месте

Знакомая ситуация? Данные о пользователях лежат в PostgreSQL, логи кликов — в ClickHouse, а архивные данные за прошлый год — в S3 в виде Parquet-файлов. Бизнес-аналитик просит сделать отчет, который требует данных из всех трех источников. Что делать? Начинается классическая эпопея с ETL: пишем скрипты, настраиваем Airflow, гоняем терабайты данных в единое хранилище (DWH), ждем... А что, если я скажу, что можно просто написать один SQL-запрос, который объединит данные из всех этих источников прямо на лету?

Именно эту, на первый взгляд, магическую задачу и решает проект, о котором сегодня пойдет речь — Trino.

Что такое Trino и зачем он нужен?

Если коротко, Trino — это распределенный SQL-движок для аналитики больших данных. А теперь по-человечески.

Важно понимать: Trino — это не база данных. Он не хранит данные. Его работа — принимать от вас стандартный SQL-запрос, "понимать", где лежат нужные данные (в PostgreSQL, S3, Kafka или десятках других систем), и выполнять этот запрос, собирая информацию из разных мест.

Представьте, что у вас есть универсальный пульт управления для всей вашей техники. Вам не нужно искать пульт от телевизора, потом от кондиционера, потом от музыкального центра. Вы просто нажимаете кнопки на одном устройстве. Trino — это такой "универсальный пульт" для всех ваших хранилищ данных. Он дает единую точку доступа ко всей вашей информации через язык, который знают все — SQL.

Исторически Trino вырос из проекта Presto, созданного в недрах Facebook* (*признана экстремистской организацией и запрещена в РФ) для интерактивной аналитики петабайтных хранилищ. Со временем проект разделился, и команда оригинальных создателей продолжила развивать его под новым именем Trino.

Ключевые возможности: федерация, а не миграция

Главная философия Trino — федеративные запросы. Вместо того чтобы мигрировать все данные в одно место, вы "объединяете" их на уровне запросов. Это становится возможным благодаря нескольким ключевым особенностям.

1. Архитектура на коннекторах

Сердце Trino — это его коннекторы. Коннектор — это, по сути, "драйвер", который учит Trino общаться с конкретным источником данных. Хотите читать данные из MySQL? Подключаете коннектор для MySQL. Из Kafka? Есть и такой. Из Google Sheets? Да, и такое возможно!

Это позволяет делать невероятные вещи. Например, вы можете одним запросом объединить (JOIN) данные из реляционной базы с данными из NoSQL-хранилища:

SELECT
    u.name,
    p.product_name,
    l.action
FROM
    postgresql.public.users u
JOIN
    hive.datalake.purchases p ON u.id = p.user_id
JOIN
    kafka.logs.user_actions l ON u.id = l.user_id
WHERE
    p.purchase_date > '2023-10-01';

Только вдумайтесь: здесь мы соединяем данные из PostgreSQL, озера данных на Hive и стримингового топика Kafka. Без единой строчки ETL-кода!

2. Масштабируемость и параллелизм

Trino изначально спроектирован для работы с огромными объемами данных. Он работает в виде кластера, состоящего из двух типов узлов:

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

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

3. Оптимизация для аналитики (OLAP)

Trino — это инструмент для аналитических запросов (OLAP), а не для транзакционных (OLTP). Он использует техники векторизованной обработки и выполнения в памяти (in-memory), чтобы максимально ускорить сканирование больших объемов данных и сложные агрегации, характерные для аналитики. Не стоит пытаться использовать его как замену вашей основной PostgreSQL для бэкенда приложения, его стихия — это BI-отчеты, ad-hoc анализ и data science.

Где Trino пригодится на практике?

Интерактивная аналитика для Data Lake. У вас есть "озеро данных" на S3 или HDFS? Trino — идеальный способ дать аналитикам и дата-сайентистам быстрый SQL-доступ к этим данным, не требуя их предварительной загрузки в DWH. Он отлично работает с форматами вроде Parquet, ORC, Avro и современными табличными форматами, такими как Apache Iceberg и Delta Lake.
Построение Data Mesh. В концепции Data Mesh каждая команда владеет своими данными и предоставляет их как "продукт". Trino может выступать в роли универсального слоя доступа, который позволяет потребителям легко комбинировать данные из разных доменов, не задумываясь об их физическом расположении.
Ускорение BI-дашбордов. Вместо того чтобы строить сложные и медленные витрины данных, можно подключить BI-инструменты (например, Superset или Tableau) напрямую к Trino. Дашборды будут запрашивать данные из первоисточников практически в реальном времени.

Как попробовать?

Разработчики позаботились о том, чтобы начать работу с Trino было несложно. Поскольку это стандартный Maven-проект, его можно собрать одной командой:

./mvnw clean install -DskipTests

Самый простой способ запустить сервер для разработки — использовать готовый класс TpchQueryRunner прямо в вашей IDE (в README рекомендуется IntelliJ IDEA). Он поднимет локальный сервер с тестовыми данными.

После запуска сервера можно подключиться к нему с помощью CLI:

# Путь к исполняемому файлу CLI
client/trino-cli/target/trino-cli-*-executable.jar

И выполнить первые запросы:

-- Проверим, какие узлы есть в нашем мини-кластере
SELECT * FROM system.runtime.nodes;

-- Сделаем запрос к тестовым данным TPC-H
SELECT * FROM tpch.tiny.region;

Это отличная отправная точка, чтобы "пощупать" технологию и понять ее базовые принципы.

Выводы: кому стоит присмотреться к Trino?

Trino — это не "серебряная пуля", но невероятно мощный инструмент в правильных руках. Если ваша IT-инфраструктура — это не один монолитный склад данных, а скорее "архипелаг" из множества разных систем, Trino может стать тем самым мостом, который их свяжет.

Особенно полезным он будет для:

Data-инженеров, которые устали строить и поддерживать хрупкие ETL-пайплайны.
Аналитиков данных, которым нужен быстрый доступ к данным из разных источников для проверки гипотез.
Архитекторов, проектирующих современные платформы данных на основе концепций Data Lakehouse или Data Mesh.

Проект активно развивается, имеет большое сообщество и используется в таких гигантах, как Netflix, LinkedIn и Lyft. Если идея запрашивать данные там, где они лежат, кажется вам привлекательной, обязательно загляните в репозиторий Trino на GitHub. Возможно, это именно тот инструмент, которого не хватало в вашем стеке.