[Документация Yandex Cloud](../../index.md) > [Yandex Managed Service for Trino](../index.md) > Концепции > Взаимосвязь ресурсов сервиса

# Взаимосвязь ресурсов в Yandex Managed Service for Trino

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

В Trino реализовано разделение storage- и compute-слоев. Trino работает только с запросами и результатами их выполнения. Все операции с данными делегируются внешнему хранилищу данных, к которому направлен запрос, поэтому для выполнения запроса данные из хранилища не нужно загружать в Trino. Такой подход ускоряет обработку запросов и в сочетании с массивно-параллельной архитектурой облегчает масштабирование кластера Managed Service for Trino под различные задачи.

Каждый кластер Managed Service for Trino запускается в отдельной группе узлов Kubernetes, которая включает в себя необходимую сетевую инфраструктуру: [виртуальную сеть](../../vpc/concepts/network.md#network), [группу безопасности](../../vpc/concepts/security-groups.md) и [сервисный аккаунт](../../iam/concepts/users/service-accounts.md). Группы узлов изолированы друг от друга как средствами виртуальных сетей, так и средствами самого Kubernetes. Группы узлов управляются общим Kubernetes-мастером.

Взаимосвязь ресурсов сервиса представлена на схеме:

![cluster-architecture](../../_assets/managed-trino/cluster-architecture.svg)

## Архитектура кластера {#cluster-architecture}

Основная сущность, которой оперирует сервис Managed Service for Trino — кластер. 

Кластер Trino  состоит из _координатора_ и _воркеров_. Воркеры обращаются к источникам данных через _каталоги_. Связь с источниками данных осуществляется через _коннекторы_.

Взаимодействие компонентов кластера между собой и со внешними сервисами (клиентами и источниками данных) представлено на схеме:

![cluster-architecture](../../_assets/managed-trino/components-interaction.svg)

### Координатор {#coordinator}

Координатор — это основной узел обработки данных. Он принимает запросы от пользователей, планирует выполнение запросов, управляет распределением заданий между воркерами и обрабатывает результаты выполнения заданий, полученные от воркеров.

На сервере координатора запущена служба обнаружения, которая отслеживает доступность воркеров. Если воркер становится недоступен, координатор не назначает на него новые задания.

В кластере Trino всегда только один координатор.

### Воркеры {#workers}

Воркеры — это рабочие узлы. Они обрабатывают запросы от координатора, выполняют операции с данными и возвращают полученные результаты координатору. При запуске воркер регистрирует себя в службе обнаружения, запущенной на сервере координатора. Таким образом воркер становится доступен для назначения заданий. Периодически воркер отправляет в службу обнаружения сигнал о доступности. Если служба обнаружения не получает такой сигнал в установленное время, на воркер не назначаются новые задания.

При [создании кластера](../operations/cluster-create.md) вы можете задать фиксированное количество воркеров от 1 до 64 или настроить автоматическое изменение количества воркеров в диапазоне от 0 до 64 в зависимости от нагрузки.

### Каталог Trino {#catalog}

Каталог — это набор параметров, которые описывают подключение к источнику данных. В кластере Managed Service for Trino можно [создать](../operations/catalog-create.md) один или несколько каталогов. При этом Trino поддерживает работу с данными из разных каталогов в одном запросе.

Каждый каталог описывает только один источник данных. Тип источника данных определяется выбранным _коннектором_.

### Коннектор {#connector}

_Коннектор_ — это интерфейс для доступа к источнику данных определенного типа. Коннектор представляет данные из источника в виде абстрактной таблицы, к которой воркеры выполняют запросы. Эта таблица позволяет работать одинаково со всеми источниками данных, вне зависимости от их специфических требований.

В Managed Service for Trino доступны следующие коннекторы:

* ClickHouse®
* Delta Lake
* [Greenplum®/Cloudberry](greenplum-connector.md) <code><b><small>Preview</small></b></code>
* Hive
* Hudi <code><b><small>Preview</small></b></code>
* Iceberg
* Oracle <code><b><small>Preview</small></b></code>
* PostgreSQL
* MySQL® <code><b><small>Preview</small></b></code>
* MS SQL Server <code><b><small>Preview</small></b></code>
* TPC-DS
* TPC-H

Коннектор выбирается во время [создания каталога Trino](../operations/catalog-create.md).

## Выполнение запроса в кластере Trino {#query-execution}

```mermaid
sequenceDiagram
  actor Client as Клиент (JDBC, WebSQL, DBeaver)
  participant Coordinator as Координатор
  participant Worker1 as Воркер 1
  participant Worker2 as Воркер 2
  participant Connector-hive as Коннектор<br/>Hive / Iceberg
  participant Connector-pg as Коннектор<br/>PostgreSQL
  participant Storage as S3
  participant Pg-server as Сервер PostgreSQL

  Client ->> Coordinator: 1. SQL-запрос SELECT ...
  activate Coordinator

  Coordinator ->> Coordinator: 2. Построение логического плана
  Coordinator ->> Coordinator: 3. Разбиение на Stages:<br/>- Stage 0 (root)<br/>- Stage 1 (leaf)
  Coordinator ->> Coordinator: 4. Создание Tasks:<br/>Task-1A, Task-1B (Stage 1)

  Coordinator ->> Worker1: 5. Назначение Task-1A<br/>(Stage 1, Partition A)
  activate Worker1
  Coordinator ->> Worker2: 5. Назначение Task-1B<br/>(Stage 1, Partition B)
  activate Worker2

  Worker1 ->> Connector-hive: 6. Чтение данных<br/>(через Hive-коннектор)
  Connector-hive ->> Storage: 7. Доступ к S3
  Storage -->> Connector-hive: Данные
  Connector-hive -->> Worker1: Передача в Task

  Worker2 ->> Connector-pg: 6. Чтение данных<br/>(через PostgreSQL-коннектор)
  Connector-pg ->> Pg-server: 7. SELECT ...
  Pg-server -->> Connector-pg: Результат
  Connector-pg -->> Worker2: Передача в Task

  Worker1 ->> Worker1: 8. Выполнение Task-1A:<br/>- Фильтрация<br/>- Агрегация
  Worker2 ->> Worker2: 8. Выполнение Task-1B:<br/>- Фильтрация<br/>- Агрегация

  Worker1 -->> Coordinator: 9. Результат Task-1A<br/>→ Stage 0
  deactivate Worker1
  Worker2 -->> Coordinator: 9. Результат Task-1B<br/>→ Stage 0
  deactivate Worker2

  Coordinator ->> Coordinator: 10. Выполнение Stage 0:<br/>Финальная агрегация

  Coordinator -->> Client: 11. Возврат результата
  deactivate Coordinator
```

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

Выполнение запроса в кластере Trino происходит по следующей схеме:

1. Координатор получает от клиента запрос в виде SQL-выражения.

1. Координатор планирует стадии выполнения запроса и преобразует его в серию связанных заданий, которые распределяются между воркерами.

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

1. Координатор собирает результаты заданий от воркеров, формирует финальный результат и передает его клиенту, который отображает результат выполнения запроса для пользователя.

Воркеры взаимодействуют друг с другом и с координатором через REST API. Помимо этого, воркеры могут обмениваться промежуточными данными через Exchange Manager, который выполняет роль хранилища временных данных. Таким образом, если воркер выйдет из строя, выполнявшийся на нем процесс может быть выполнен на другом воркере с использованием промежуточных данных из Exchange Manager.