[Yandex Cloud documentation](../../index.md) > [Yandex Managed Service for Trino](../index.md) > Concepts > Resource relationships

# Resource relationships in Yandex Managed Service for Trino

Trino is a high-performance distributed massively parallel query processing system. With Trino, you can run queries to various data storages and work with data in various formats using the standard SQL syntax.

Trino implements separated storage and compute layers. Trino works only with queries and their results. All data operations are delegated to the external data storage you are querying, so you do not need to upload data from the storage to Trino to run a query. This approach accelerates query processing and, in combination with the massively parallel architecture, simplifies Managed Service for Trino cluster scaling for various needs.

Each Managed Service for Trino cluster runs in a separate Kubernetes node group containing the required network infrastructure: a [virtual network](../../vpc/concepts/network.md#network), a [security group](../../vpc/concepts/security-groups.md), and a [service account](../../iam/concepts/users/service-accounts.md). Node groups are isolated from each other, both through virtual networks and through Kubernetes itself. Node groups are managed by a common Kubernetes master.

This diagram illustrates the relationship between service resources:

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

## Cluster architecture {#cluster-architecture}

The main entity in Managed Service for Trino is a cluster.

A Trino cluster consists of the _coordinator_ and _workers_. Workers access data sources via _catalogs_. _Connectors_ are used to establish connections to data sources.

This diagram illustrates how cluster components interact with each other and external services (clients and data sources):

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

### Coordinator {#coordinator}

The coordinator is the primary data processing node. It receives user queries, plans query execution, manages task distribution among workers, and processes task results they return.

The coordinator server runs a discovery service that monitors worker availability. If a worker becomes unavailable, the coordinator stops assigning new tasks to it.

A Trino cluster always has only one coordinator.

### Workers {#workers}

Workers are processing nodes. They handle coordinator queries, run data operations, and return results to the coordinator. When started, each worker registers itself with the discovery service running on the coordinator server. This way it becomes available for task assignment. From time to time, workers send availability signals to the discovery service. If the discovery service does not receive such a signal within the specified time, new tasks will not be assigned to that worker.

When [creating a cluster](../operations/cluster-create.md), you can either set a fixed number of workers (from 1 to 64) or autoscale the number of workers (between 0 and 64) based on workload.

### Trino catalog {#catalog}

A catalog is a set of parameters describing a connection to a data source. You can [create](../operations/catalog-create.md) one or more catalogs in a Managed Service for Trino cluster. Trino supports working with data from multiple catalogs within a single query.

Each catalog describes only one data source. The data source type is determined by the selected _connector_.

### Connector {#connector}

A _connector_ is an interface for accessing a specific type of data source. Connector provide data from the source as an abstract table which the workers can send queries to. This table supports the same workflow for all data sources regardless of what particular requirements they may have.

In Managed Service for Trino, the following connectors are available:

* 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

You select a connector when [creating a Trino catalog](../operations/catalog-create.md).

## Running a query in a Trino cluster {#query-execution}

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

  Client ->> Coordinator: 1. SQL quey SELECT ...
  activate Coordinator

  Coordinator ->> Coordinator: 2. Build logical plan
  Coordinator ->> Coordinator: 3. Split into Stages:<br/>- Stage 0 (root)<br/>- Stage 1 (leaf)
  Coordinator ->> Coordinator: 4. Create Tasks:<br/>Task-1A, Task-1B (Stage 1)

  Coordinator ->> Worker1: 5. Assign Task-1A<br/>(Stage 1, Partition A)
  activate Worker1
  Coordinator ->> Worker2: 5. Assign Task-1B<br/>(Stage 1, Partition B)
  activate Worker2

  Worker1 ->> Connector-hive: 6. Read data<br/>(via Hive conn)
  Connector-hive ->> Storage: 7. Access S3
  Storage -->> Connector-hive: Data
  Connector-hive -->> Worker1: Transfer to Task

  Worker2 ->> Connector-pg: 6. Read dataх<br/>(via PostgreSQL connector)
  Connector-pg ->> Pg-server: 7. SELECT ...
  Pg-server -->> Connector-pg: Result
  Connector-pg -->> Worker2: Transfer to Task

  Worker1 ->> Worker1: 8. Execute Task-1A:<br/>- Filter<br/>- Aggregate
  Worker2 ->> Worker2: 8. Execute Task-1B:<br/>- Filter<br/>- Aggregate

  Worker1 -->> Coordinator: 9. Task-1A result<br/>→ Stage 0
  deactivate Worker1
  Worker2 -->> Coordinator: 9. Task-1B result<br/>→ Stage 0
  deactivate Worker2

  Coordinator ->> Coordinator: 10. Execute Stage 0:<br/>Final aggregation

  Coordinator -->> Client: 11. Return result
  deactivate Coordinator
```

The user works with the Trino cluster via a client, e.g., the Trino CLI. The client sends queries to the coordinator and shows their results.

Running a query in a Trino cluster involves these stages:

1. The coordinator receives a query from the client as an SQL statement.

1. The coordinator plans query execution stages and converts it into a series of related tasks distributed among workers.

1. Workers run queries to data sources, process the incoming information, exchange intermediate task results, and submit the results of all tasks to the coordinator.

1. The coordinator collects task results from workers, generates the final result, and sends it to the client, which outputs the query result to the user.

Workers interact with each other and the coordinator via the REST API. Additionally, workers can exchange intermediate data through Exchange Manager, which servers as a temporary data storage. This way, if a worker fails, its active process may be completed on a different worker using the intermediate data from Exchange Manager.