Глоссарий — Trino

Распределённый SQL query engine для интерактивной аналитики над data lake и федерации источников. НЕ база данных: своего хранилища нет, данные живут в подключённых источниках. Понимает ANSI SQL, заточен под OLAP. Актуальная версия — 481 (релиз 11 мая 2026); номер версии целочисленный и монотонно растёт.

Движок распределённых SQL-запросов, созданный в 2012 в Facebook (Martin Traverso, Dain Sundstrom, David Phillips, Eric Hwang) для интерактивной аналитики поверх Hadoop-хранилища Facebook. Общий предок современных PrestoDB и Trino.

Имя форка Presto, который в конце 2018 создали ушедшие из Facebook авторы движка. 27 декабря 2020 PrestoSQL был переименован в Trino из-за trademark-спора вокруг имени «Presto».

Оригинальный репозиторий Presto, развивается Facebook/Meta при Linux Foundation. Имеет общий исторический код с Trino, но проекты сильно разошлись. Это два разных движка с общим прошлым, не синонимы.

Распределённый движок SQL-запросов — система, которая исполняет SQL поверх внешних источников данных на кластере машин, не имея собственного хранилища. Trino относится к этому классу: он считает, а хранят данные коннекторы.

Massively Parallel Processing — модель массово-параллельной обработки на кластере независимых нод (shared-nothing). Запрос разбивается на части, исполняемые параллельно на множестве воркеров. Архитектурная основа масштабируемости Trino.

Сервер Trino, который парсит statement'ы, планирует запросы и управляет воркерами. Точка входа для клиентов. Сам данные не обрабатывает, если явно не включён как воркер через node-scheduler.include-coordinator. В кластере ровно один.

Сервер Trino, исполняющий задачи и обрабатывающий данные: забирает данные из коннекторов и обменивается промежуточными результатами с другими нодами. Воркеров в кластере ноль или больше; они дают горизонтальную масштабируемость.

Сервис обнаружения, встроенный в coordinator. При старте воркеры регистрируются в нём, чтобы координатор знал актуальный список нод и кому раздавать работу.

REST-протокол общения клиента с координатором. Клиент отправляет statement, получает nextUri и опрашивает (polling) его, постранично забирая результат. На этом протоколе работают Trino CLI, JDBC-драйвер и trino-python-client.

Реализация Trino SPI, адаптирующая конкретный тип источника данных к стандартному API движка. По коннектору на каждый тип источника: Hive, Iceberg, PostgreSQL, Kafka и так далее. Коннектор делает источник «видимым» для SQL.

Service Provider Interface — набор интерфейсов, которые реализует коннектор, чтобы движок мог с ним работать. Ключевые части: Metadata (метаданные схем и таблиц), SplitManager (генерация сплитов), PageSource (чтение Page), PageSink (запись).

Набор свойств конфигурации, определяющий доступ к конкретному источнику данных: какой коннектор использовать плюс параметры подключения и креды. Описывается catalog properties file. В кластере может быть много каталогов.

Способ группировки таблиц внутри каталога. Обычно мапится на аналогичное понятие в источнике (database или schema). Полное имя таблицы в Trino — catalog.schema.table.

Набор неупорядоченных строк, организованных в именованные типизированные столбцы. Базовая единица данных в модели Trino, доступная через SQL.

Текст SQL, переданный в Trino. Statement — это просто строка запроса; при его обработке создаётся рантайм-объект query.

Рантайм-инстанс, созданный при парсинге statement'а. Объединяет stages, tasks, splits, операторы и задействованные коннекторы — всё, что работает на кластере ради одного запроса.

Фаза распределённого плана запроса. Стадии образуют дерево: корневая агрегирует вывод дочерних. Stage — концептуальная модель и НЕ исполняется напрямую на воркерах; её реализуют task'и.

Исполняемая реализация стадии на конкретном воркере — «рабочая лошадка» исполнения. Стадия распараллеливается на множество задач на разных воркерах; задача обрабатывает один или несколько сплитов.

Секция (кусок) большого набора данных, над которой работает одна задача. Сплиты для source-стадий поставляет коннектор (файл, row-group, диапазон), для промежуточных — вышестоящие стадии.

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

Элемент, который потребляет, трансформирует и производит данные. Примеры: table scan (чтение из коннектора), filter (предикат), project, aggregation, join, exchange. Операторы соединяются в драйвер.

Механизм передачи данных между нодами Trino для разных стадий запроса. Использует output buffers на стороне продьюсера и exchange clients на стороне консьюмера. Бывает удалённым (между стадиями) и локальным (внутри задачи).

Единица передачи данных между операторами — набор Block'ов. Операторы потребляют входящие Page и производят исходящие. Page-ориентированная обработка батчами лежит в основе векторизации Trino.

Структура, хранящая данные одного столбца внутри Page. Бывают обычные, dictionary blocks (словарное/RLE-кодирование, экономят память и CPU) и колоночные ColumnarArray/ColumnarMap/ColumnarRow.

Буфер на стороне продьюсера в exchange-модели, куда задача складывает произведённые Page до того, как их заберут exchange clients консьюмера. Размер буфера создаёт backpressure: продьюсер тормозит, если буфер полон.

Фрагмент распределённого плана, соответствующий стадии. Тип фрагмента задаёт, как он исполняется и как распределяются данные: SOURCE, HASH, BROADCAST, ROUND_ROBIN, SINGLE. Виден в выводе EXPLAIN.

Тип фрагмента, исполняемого на нодах, где доступны входные сплиты, ради data locality. Обычно это нижние стадии плана, читающие данные из коннектора.

Тип фрагмента (partitioned), исполняемого на фиксированном числе нод; входные данные распределены по хэш-функции от ключа. Применяется для partitioned join и hash-агрегаций.

Тип фрагмента, при котором данные транслируются (копируются целиком) на все ноды. Используется для broadcast join, когда build-side мал и помещается в память каждой ноды.

Тип фрагмента, при котором данные распределяются по нодам по кругу, равномерно и без привязки к ключу. Применяется, когда нужно просто сбалансировать нагрузку.

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

Компонент координатора, назначающий сплиты на ноды. Политика задаётся node-scheduler.policy: uniform (равномерное распределение с учётом локальности данных) или topology (по topology-расстоянию между нодами и сплитами).

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

Жизненный цикл запроса: SQL-текст -> AST (parser) -> Analysis (разрешение имён, типы) -> логический план (Plan IR) -> iterative optimizer -> CBO -> распределённый план (фрагментация на stages) -> tasks -> splits -> drivers -> operators -> exchanges -> результат клиенту.

Компонент, превращающий текст SQL-statement'а в AST (абстрактное синтаксическое дерево). Первый шаг обработки запроса на координаторе.

Этап семантического анализа: разрешение имён каталогов/схем/таблиц/столбцов, проверка типов, формирование объекта Analysis. Выполняется после парсинга, до логического планирования.

Логический план запроса — дерево PlanNode (Plan IR, intermediate representation), описывающее операции без привязки к распределённому исполнению. Вход для iterative optimizer.

Rule-based оптимизатор Trino. Правило — это пара «паттерн в дереве плана + трансформация». Оптимизатор многопроходно применяет правила, пока план меняется, последовательно улучшая логический план.

CBO — оптимизатор, принимающий решения на основе оценки стоимости по статистике таблиц. Отвечает за join reordering и выбор join distribution. Из статистики (row count, NDV, nulls fraction) считает cardinality и cost альтернативных планов.

Статистика таблиц, используемая CBO: на уровне таблицы — total row count; на уровне столбца — data size, nulls fraction, number of distinct values (NDV), min/max. Собирается командой ANALYZE, показывается через SHOW STATS.

Number of Distinct Values — оценка числа уникальных значений в столбце. Ключевой вход CBO: по NDV оценивается селективность фильтров и кардинальность результата join. Неверный NDV ведёт к плохому плану.

Автоматическое переупорядочивание джойнов оптимизатором по статистике. Управляется optimizer.join-reordering-strategy: AUTOMATIC (полная enumeration, по умолчанию), ELIMINATE_CROSS_JOINS, NONE. Без статистики AUTOMATIC откатывается к ELIMINATE_CROSS_JOINS.

Способ распределения джойна по кластеру: BROADCAST или PARTITIONED. Управляется join-distribution-type (сессия join_distribution_type): AUTOMATIC (по умолчанию), BROADCAST, PARTITIONED.

Стратегия джойна, при которой build-side (правая таблица) копируется целиком на каждую ноду как хэш-таблица. Быстро, без шаффла, но build-side должен влезать в память каждой ноды. Порог — join-max-broadcast-table-size (по умолчанию 100MB).

Стратегия джойна (hash join), при которой обе таблицы перераспределяются по хэшу join-ключа. Медленнее из-за шаффла, но позволяет джойнить большие таблицы, используя суммарную память кластера.

Оптимизация, при которой фильтрация строк (условие WHERE) проталкивается в источник данных, чтобы он вернул меньше строк. Поддержка специфична для коннектора и реализуется через SPI (applyFilter).

Оптимизация, ограничивающая набор читаемых из источника столбцов. Dereference pushdown — её разновидность: достаёт из ROW только нужные вложенные поля. Реализуется через SPI (applyProjection).

Оптимизация, при которой агрегатные функции вычисляются в источнике данных, если коннектор это поддерживает через SPI (applyAggregation). Снижает объём передаваемых в Trino данных.

Механизм рантайм-фильтрации: Trino собирает значения join-ключей с отфильтрованной build-side, формирует динамический предикат и применяет его к scan'у fact-таблицы, чтобы не читать заведомо отсеиваемые данные. Включает dynamic partition pruning.

Архитектура, объединяющая дешёвое object storage и открытые форматы таблиц (Iceberg, Delta Lake, Hudi) с возможностями warehouse: ACID, time travel, schema evolution. Trino — типичный движок запросов для lakehouse.

HMS — сервис каталога метаданных: хранит описания схем, таблиц, партиций, расположение файлов. Используется коннекторами Hive, Iceberg, Delta Lake для разрешения, где и в каком виде лежат данные.

AWS Glue Data Catalog — управляемый облачный каталог метаданных, совместимая альтернатива Hive Metastore. Подключается к коннекторам Hive/Iceberg/Delta через hive.metastore=glue.

Тип каталога Iceberg, работающий по стандартному Iceberg REST API. Указывается через iceberg.catalog.type=rest. Не требует Hive Metastore, упрощает развёртывание lakehouse.

Коннектор Trino для таблиц Apache Iceberg. Поддерживает каталоги Hive Metastore, Glue, REST, Nessie, JDBC; snapshots, time travel, schema evolution, обслуживание таблиц через ALTER TABLE EXECUTE, metadata-таблицы.

Коннектор Trino для таблиц Delta Lake. Полный read/write (INSERT, DELETE, UPDATE, MERGE), time travel, deletion vectors, change data feed, процедуры OPTIMIZE/VACUUM/register_table. Метасторы — HMS и Glue.

Коннектор Trino для таблиц Hive поверх object storage. Требует Hive Metastore или Glue. Форматы ORC, Parquet, Avro и другие; партиционирование и бакетинг; чтение/запись ACID-таблиц с HMS 3.x.

Новый единый коннектор Trino, объединяющий функциональность Hive, Iceberg, Delta Lake и Hudi в одном каталоге. Позволяет работать с таблицами разных форматов через один коннектор вместо четырёх отдельных каталогов.

Возможность читать таблицу в её прошлом состоянии. В Trino: SELECT ... FOR VERSION AS OF <snapshot_id> и FOR TIMESTAMP AS OF TIMESTAMP '...'. Iceberg также поддерживает branches и tags как версионные идентификаторы.

Снапшот — зафиксированное состояние таблицы Iceberg на момент коммита. Каждая запись создаёт новый снапшот; на снапшоты опираются time travel и инкрементальные операции. Видны в metadata-таблице $snapshots.

Процедура обслуживания таблицы (ALTER TABLE ... EXECUTE optimize), выполняющая компакцию мелких файлов в крупные. Параметр file_size_threshold (по умолчанию 100MB), опциональный WHERE для фильтра партиций. Лечит проблему too many small files.

Процедура обслуживания Iceberg (ALTER TABLE ... EXECUTE expire_snapshots), удаляющая старые снапшоты и связанные метаданные и файлы данных. Минимальный retention по умолчанию 7 дней, параметр retain_last.

Особенность Iceberg: партиционирование задаётся через transforms (year, month, day, hour, bucket, truncate) и не требует отдельного столбца в запросах. Движок сам сопоставляет фильтр по столбцу с партициями.

Изменение схемы таблицы без перезаписи данных: добавление, удаление, переименование столбцов, type widening (INTEGER->BIGINT, REAL->DOUBLE, расширение DECIMAL precision), изменение схемы партиционирования. Полноценно поддержано в Iceberg.

Федерация запросов — выполнение одного SQL-запроса поверх нескольких разнородных источников (например, join таблицы PostgreSQL с Parquet на S3) без физического перемещения данных. Один из ключевых сценариев Trino.

Семейство коннекторов Trino к реляционным источникам через JDBC (PostgreSQL, MySQL, SQL Server, Oracle и другие). Отвечает за маппинг типов, чтение метаданных, connection pooling и pushdown в источник.

Память, выделяемая запросом явно под свои нужды: хэш-таблицы джойнов, буферы сортировки и агрегации. Учитывается лимитами query.max-memory и query.max-memory-per-node.

Память, которую движок может отозвать у запроса, выгрузив её содержимое на диск (spill). Даёт запросу шанс завершиться вместо падения по OOM ценой замедления на disk I/O.

Резерв heap под неучтённые Trino аллокации (system memory). Задаётся memory.heap-headroom-per-node, по умолчанию 30% максимального heap. Сумма query.max-memory-per-node и headroom должна быть меньше -Xmx JVM.

Выгрузка revocable memory на диск, когда запрос упирается в лимит памяти. Поддержан для aggregations, joins, sort, window functions. Узкое место — disk I/O; нельзя спилить на системный диск или диск с JVM-логами.

Механизм управления нагрузкой: иерархия групп с лимитами, очередями и приоритетами запросов. Позволяет изолировать нагрузки (например, дашборды от ad-hoc). Конфигурация file-based (JSON) или database-based.

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

FTE — опциональный режим отказоустойчивости. Промежуточные данные обмена спулятся через exchange manager и могут быть переиспованы другим воркером при сбое. Покрывает инфраструктурные сбои, но не ошибки пользователя.

Политика повторов при FTE: NONE (по умолчанию, без отказоустойчивости), QUERY (ретрай всего запроса, для множества мелких запросов), TASK (ретрай отдельных задач, для больших batch-запросов; требует exchange manager).

Компонент FTE, спулящий промежуточные данные обмена во внешнее надёжное хранилище. Настраивается в etc/exchange-manager.properties; хранилища: filesystem (S3, GCS, Azure Blob, HDFS, локальная ФС только не для прода).

Кодовое имя проекта, в рамках которого в Trino реализовали fault-tolerant execution. Тихоходка (tardigrade) — символ выживаемости: запрос переживает сбой воркера.

Отдельный продукт (репозиторий trinodb/trino-gateway): балансировщик, прокси и routing-шлюз для нескольких кластеров Trino. Один URL для клиентов, маршрутизация по правилам, no-downtime blue/green апгрейды кластеров.

Команда, которая исполняет запрос и показывает распределённый план с фактической стоимостью операций: CPU-время по стадиям, объём данных, относительную стоимость нод. EXPLAIN ANALYZE VERBOSE добавляет низкоуровневую статистику операторов.

Java Management Extensions — стандартный механизм метрик JVM-приложения. Trino экспонирует через JMX большое число внутренних метрик; коннектор jmx позволяет запрашивать их прямо как SQL-таблицы.

Веб-интерфейс координатора Trino: список запросов, их детали, стадии, статистика, live-план. Базовый инструмент наблюдаемости — позволяет увидеть очереди, прогресс и dynamicFiltersStats.

PTF — полиморфная табличная функция: функция, возвращающая таблицу, чья схема определяется в момент вызова. Применяется в том числе для query pass-through — отправки нативного запроса прямо в источник.

SQL user-defined function — пользовательская функция на SQL. Объявляется через WITH FUNCTION (inline в одном запросе) или CREATE FUNCTION (catalog routine, переиспользуемая). В старых материалах термин звучал как «SQL routines».

Новый числовой тип данных, добавленный в Trino в релизе 480 (24 марта 2026). Часть развития системы типов наряду с DECIMAL и TIMESTAMP с precision.

Online Analytical Processing — аналитическая нагрузка: тяжёлые сканирующие запросы, агрегации, join больших таблиц. Целевой класс задач для Trino. Противоположность OLTP (транзакционная нагрузка), для которой Trino не предназначен.

Архитектурный принцип: ноды кластера не делят между собой память и диск, общаются только по сети. Каждый воркер обрабатывает свою часть данных независимо. Основа горизонтальной масштабируемости MPP-систем.

SQL-команда Trino, собирающая и обновляющая статистику таблицы (row count, NDV, nulls fraction, data size, min/max). Нужна, когда данные изменили в обход Trino, чтобы CBO строил планы по актуальным цифрам.

Команда SHOW STATS FOR <table>, выводящая текущую статистику таблицы, которую видит CBO. Первый инструмент диагностики, когда оптимизатор выбрал плохой join order.

Процедура обслуживания Iceberg (ALTER TABLE ... EXECUTE remove_orphan_files), удаляющая из хранилища файлы, не связанные ни с одним снапшотом таблицы. Освобождает место после сбоев и откатов.

Механизм row-level удаления без перезаписи файлов данных: позиции удалённых строк хранятся отдельно. Поддержаны в Delta Lake (deletion_vectors_enabled) и в Iceberg v3 (binary deletion vectors).

CDC-возможность Delta Lake: при записи фиксируются change-события (вставки, удаления, обновления строк), которые потом можно прочитать. У Iceberg аналогичную роль играет функция table_changes().

Системная таблица Iceberg, дающая доступ к метаданным через SQL: $snapshots, $files, $history, $partitions, $manifests, $properties и другие. Инструмент инспекции состояния и обслуживания таблицы.

Версия формата таблиц Iceberg (экспериментальная в актуальных релизах Trino): column default values, шифрование, тип VARIANT, binary deletion vectors, nanosecond timestamps, row lineage. v2 остаётся версией по умолчанию.

Полуструктурированный тип данных для Iceberg v3, добавленный в Trino экспериментально (чтение — с релиза 471, развитие — в 481). Хранит произвольные JSON-подобные структуры без фиксированной схемы.

Optimized Row Columnar — колоночный формат файлов хранения. Поддержан коннекторами Hive и другими; в ORC и Parquet работают динамические фильтры с stripe/row-group pruning. Транзакционные Hive ACID-таблицы используют ORC.

Широко распространённый колоночный формат файлов хранения. Основной формат для таблиц Iceberg и Delta Lake, поддержан Hive. В Parquet динамические фильтры дают row-group pruning, экономя дисковый I/O.

Модель исполнения Trino: данные стримятся через цепочку операторов Page за Page, не материализуясь целиком между стадиями. Вместе с MPP и векторизацией даёт низкую латентность интерактивных запросов.

Файл etc/node.properties: настройки конкретной ноды. node.environment одинаков для всего кластера, node.id уникален, node.data-dir — путь к данным. Обязателен на каждой ноде.

Файл etc/config.properties: конфигурация сервера Trino. Ключевые свойства: coordinator (true/false), node-scheduler.include-coordinator, http-server.http.port, discovery.uri, лимиты памяти.

Файл etc/jvm.config: опции JVM по одной на строку (-Xmx, настройки GC, -XX:...). Для прода heap обычно 32GB и больше; каталог временных файлов JVM не должен иметь флаг noexec.

Системный коннектор tpch, генерирующий на лету данные одноимённого аналитического бенчмарка. Не требует внешнего источника — удобен для обучения, демонстраций и проверки кластера без настройки хранилища.

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

Свойство, ограничивающее максимум распределённой user memory на один запрос по всему кластеру. По умолчанию 20GB. При превышении запрос убивается с ошибкой нехватки памяти.

Код ошибки Trino: запрос превысил лимит user memory на одной ноде (query.max-memory-per-node, по умолчанию 30% heap). Типичная причина — broadcast join слишком большой build-side. Лечится статистикой, PARTITIONED join или spill.

Адаптер dbt для Trino: позволяет описывать аналитические трансформации как dbt-модели и материализовать их через Trino. Один из стандартных клиентов в data-engineering-стеке поверх Trino.