Что такое Trino и кому нужен этот курс

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

Trino решает эту задачу иначе. Это движок, который умеет выполнить один SQL-запрос поверх всех источников сразу, не перемещая данные. Аналитик пишет SELECT ... FROM postgresql.public.orders o JOIN hive.events.clicks c ON ... — и Trino сам сходит в Postgres, сам прочитает Parquet с S3, соединит результаты в памяти кластера и вернёт ответ. Источники остаются на месте. Пайплайн не нужен.

Этот урок отвечает на два вопроса: что именно такое Trino с инженерной точки зрения, и кому стоит проходить этот курс.

Trino — это движок запросов, а не база данных

Главную мысль про Trino нужно усвоить сразу, потому что почти все ошибки в его понимании растут именно отсюда. Trino — это распределённый SQL query engine. Это не база данных.

База данных — это две вещи в одном продукте: хранилище (storage), которое держит данные на диске, и движок (engine), который выполняет запросы к этим данным. PostgreSQL хранит ваши таблицы в своих файлах и сам же исполняет SQL над ними. Trino же — это только вторая половина: чистый движок исполнения запросов. Своего хранилища у него нет вообще. Он не держит ни байта пользовательских данных на диске. Данные всегда живут в подключённых внешних источниках, а Trino в момент запроса вычитывает их, обрабатывает в оперативной памяти своих узлов и отдаёт результат.

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

Trino не предназначен для OLTP — для транзакционной нагрузки. Если задача — записать один заказ, обновить баланс, прочитать профиль пользователя по id, это работа для PostgreSQL или MySQL. Trino не имеет транзакций уровня СУБД, не имеет индексов в привычном смысле, не оптимизирован для точечных операций над одной строкой. Его стихия — OLAP: аналитические запросы, которые сканируют миллионы и миллиарды строк, агрегируют, джойнят, считают метрики.

Trino не заменяет ваше хранилище. Он не альтернатива Snowflake или BigQuery как месту, где данные лежат. Он альтернатива тому, как вы эти данные запрашиваете. Часто Trino работает в связке с data lake: данные в открытых форматах (Parquet, ORC) на объектном хранилище плюс табличный формат вроде Apache Iceberg, а Trino — движок поверх этого озера.

Откуда берётся скорость

Если Trino не хранит данные и каждый раз читает их заново из внешних источников, откуда тогда скорость? Ответ — не из кэша и не из «данных в памяти». Скорость Trino складывается из четырёх инженерных решений, и весь этот курс посвящён их разбору.

Первое — MPP, massively parallel processing. Trino работает как кластер из множества узлов по модели shared-nothing: каждый узел обрабатывает свой кусок данных независимо, узлы не делят между собой ни диск, ни память. Запрос на 1 ТБ данных разбивается на тысячи мелких задач, которые исполняются параллельно на десятках машин.

Второе — pipelined-исполнение. Trino не материализует промежуточные результаты целиком на диск между этапами, как это делает классический MapReduce. Данные текут через операторы потоком: пока одни строки ещё читаются с диска, другие уже фильтруются, а третьи уже агрегируются. Конвейер не простаивает.

Третье — колоночная векторизованная обработка в памяти. Внутри Trino данные движутся колоночными блоками, а операторы обрабатывают их батчами значений, а не по одной строке. Это даёт эффективное использование кэшей процессора и инструкций SIMD.

Четвёртое — pushdown. Trino старается переложить часть работы на сам источник. Если можно отдать фильтр WHERE country = 'RU' в PostgreSQL, чтобы база вернула только нужные строки, Trino так и сделает — вместо того чтобы тащить через сеть всю таблицу и фильтровать у себя.

Обратите внимание, чего в этом списке нет. Нет «Trino держит все данные в RAM» — он стримит их. Нет «Trino кэширует результаты» — по умолчанию не кэширует. Скорость здесь архитектурная, а не за счёт хранения.

Что Trino умеет делать

Сведём в таблицу три главных сценария, ради которых компании внедряют Trino. Подробно мы разберём их в первом модуле, здесь — обзорно.

Объединяет их одно: везде нужен быстрый SQL-доступ к большим объёмам данных, которые не лежат и не должны лежать внутри одной классической СУБД.

Где Trino применяется на практике

Trino — не нишевый инструмент. Он создан в Facebook для интерактивной аналитики поверх их хранилища на Hadoop и сегодня используется в очень крупных компаниях для обработки эксабайтов данных. Вокруг Trino выросла отдельная компания — Starburst — с коммерческим дистрибутивом. Trino входит в стандартный стек современной data-инженерии рядом с Apache Spark, dbt, Apache Airflow и форматом Apache Iceberg.

Для вас как для инженера это значит простую вещь: понимание Trino — это понимание целого класса распределённых движков запросов. Многие идеи, которые мы разберём (MPP, фрагментация плана, exchange, cost-based-оптимизация, pushdown), повторяются в Spark SQL, в Presto, в облачных движках. Trino — отличная модель для изучения всего класса.

Стоит развеять и распространённое заблуждение, что Trino — нишевая или экзотическая технология. Это не так. Trino решает массовую и повторяющуюся задачу: в любой компании с зрелой инфраструктурой данные неизбежно оказываются разбросаны по разным системам, и так же неизбежно появляется потребность в быстром едином SQL поверх них. Поэтому Trino встречается в самых разных индустриях — от крупных интернет-компаний до банков и ритейла — везде, где есть и data lake, и аналитики, и желание не строить ETL под каждый отчёт. Навык работы с Trino — это не узкая специализация под один продукт, а востребованная часть профессии data-инженера.

Ещё одна причина, по которой Trino стоит изучать именно глубоко: он живёт не сам по себе, а в экосистеме. Его постоянно ставят в связке с форматом Apache Iceberg, с объектными хранилищами, с оркестраторами вроде Apache Airflow, с инструментом трансформаций dbt. Понимая Trino «до железа», вы понимаете и то, как он стыкуется с этими соседями — а значит, способны проектировать и отлаживать платформу целиком, а не только отдельный её кусок.

Кому нужен этот курс

Курс рассчитан на middle-уровень data-инженерии и идёт «до железа» — мы не ограничиваемся тем, как пользоваться Trino, а разбираем, почему он устроен именно так: как план запроса превращается в задачи на узлах, как данные физически летают между ними, как работает оптимизатор, как устроена модель памяти.

Курс будет полезен, если вы:

• Data-инженер, который проектирует или эксплуатирует аналитическую платформу и хочет понимать Trino глубоко, а не на уровне «запустил запрос — получил ответ».
• Аналитик или analytics engineer, который уже пишет SQL в Trino и хочет понимать, почему один запрос летает, а другой висит, и как читать EXPLAIN.
• Backend- или платформенный инженер, которому предстоит развернуть, настроить и поддерживать кластер Trino.
• Инженер, который хочет разобраться в архитектуре распределённых query engine на конкретном живом примере.

Что предполагается, что вы уже знаете: уверенный SQL (JOIN, GROUP BY, оконные функции), базовое понимание, что такое распределённая система и что такое объектное хранилище вроде S3, и навык работы в командной строке и с Docker. Глубокого знания именно Trino не требуется — с этого мы и начинаем.

Попробуй сам

Зайдите на сайт trino.io и откройте раздел документации (Docs). В правом верхнем углу страницы документации указана текущая версия — посмотрите, какая она сейчас, и сравните с числом 481 из этого урока. Прикиньте, сколько релизов вышло с момента написания курса (помните: примерно один релиз в 1-4 недели).

Затем найдите в документации страницу «Use cases» (overview/use-cases). Прочитайте её и для каждого из трёх сценариев из таблицы выше — federation, data lake analytics, интерактивная аналитика — сформулируйте одним предложением, какую боль он снимает. Это будет вашей опорой для первого модуля.

Как создавался курс

Курс создан при участии Claude (Anthropic) как соавтора: ИИ помогал писать материалы, структурировать темы, генерировать примеры кода и диаграммы. Каждая глава проходила ручную сверку с первоисточниками — спецификациями, документацией, исходным кодом рассматриваемых систем — но гарантировать 100% точность невозможно.

Если вы заметили неточность, опечатку или хотите предложить улучшение — напишите в Telegram-группу курса. Это самый ценный вклад в курс, который вы можете сделать.

Углублённое изучение с Claude

Курс рассчитан на самостоятельное изучение, но любая теория быстрее ложится, если задавать вопросы. Рекомендую держать рядом браузерное расширение Claude (claude.com/download) — оно работает с контентом открытой страницы: выделяете кусок урока и спрашиваете напрямую.

Сценарии, которые особенно хорошо работают для углублённого погружения:

• «Объясни проще» / «дай ещё один пример» — когда формулировка из урока не дошла с первого раза.
• «Покажи, как это устроено на уровне кода / железа» — когда хочется спуститься на слой ниже того, что даёт урок.
• «Как это связано с [другая тема курса]» — когда нужно увязать концепцию с тем, что было раньше.
• «У меня в проекте стек X — как применить?» — когда хочется примерить материал на свой реальный кейс.

Это не замена курсу, а способ ускорить интеграцию материала в вашу картину мира. Если что-то из ответов Claude расходится с уроком — присылайте в Telegram-группу, курс будет уточнён.

Нашли ошибку?

Если заметили неточность, опечатку или хотите предложить улучшение:

Telegram-канал

Подписывайтесь, чтобы узнавать об обновлениях и новых курсах: