Clickhouse is a realtime system where Trino is a batch-oriented system. There are tradeoffs for doing realtime vs batch.
Realtime is generally more expensive to run as you process every individual row as it comes, batch is when you can deal with minute latency and want to handle a lot of data in chunks.
It also happens to connect to Clickhouse and it's very common that people will use Trino to query clickhouse realtime data and join it with data in big query, an object store data lake, or Snowflake: https://trino.io/docs/current/connector/clickhouse.html
You can consider that ClickHouse allows both to query a lot of supported external data sources(s3/hdfs/mysql/postgre/...) and to store data in pretty efficient columnar way with compression, indexes and all the bells and whistles. Native storage allows to use all the information about keys/indices to build query plan faster.
With trino you can't store data inside trino. You can't even insert data using trino which allows you to solve scenarios like 'readonly analytics'. Trino allows you to use single query language for all the supported systems. So if you have a zoo of DBMS and object storages that you can just query it can help you to hide this complexity.
Realtime is generally more expensive to run as you process every individual row as it comes, batch is when you can deal with minute latency and want to handle a lot of data in chunks.
Trino is also a query engine rather than a database and it connects to many different systems: https://trino.io/docs/current/connector.html
It also happens to connect to Clickhouse and it's very common that people will use Trino to query clickhouse realtime data and join it with data in big query, an object store data lake, or Snowflake: https://trino.io/docs/current/connector/clickhouse.html