Trino 是什么
Trino 是不带存储的分布式 SQL 查询引擎，通过 Connector 连接 Hive、Iceberg、JDBC 数据库、Kafka、ClickHouse 等数据源，用一条 SQL 完成跨源查询。表名采用 catalog.schema.table 三级结构，因此同一句 SQL 里可以同时出现 Hive 明细表和 MySQL 维表。它的定位是交互式与即席分析：查询在内存中完成 join 与聚合，结果直接返回客户端，所以大结果集容易把 worker 内存打满，重批处理应当交给 Spark 或 Hive。
基本信息
| 定位 | 无存储的分布式查询引擎，以读为主 |
|---|---|
| 连接方式 | Connector 体系，Hive、Iceberg、JDBC、Kafka、ClickHouse 等 |
| 命名结构 | catalog.schema.table 三级命名，可跨源引用 |
| 典型场景 | 跨源联邦查询、即席分析、多源比对 |
| 下推能力 | 谓词、投影与部分聚合可下推，取决于各 Connector |
| 内存约束 | join 与结果集在集群内存中处理，超限报错或导致 worker 异常 |
| 资源管理 | 支持资源组与查询队列，隔离不同团队的负载 |
| 定位边界 | 面向交互式查询，不是大规模 ETL 的执行引擎 |
典型使用场景
- 跨源分析：Hive 明细关联 MySQL 维表，一条 SQL 出结果，不必先同步数据
- 即席探索：分析师直接连湖表查询，避免把数据下载到本地
- BI 统一入口：BI 工具通过 Trino 访问多个数据源，减少每源一套连接
- 跨引擎对账：同一时刻用 Trino 读两端表做逐项比对，验证迁移结果
- 临时查看流数据：通过对应 Connector 读取消息中的样本数据用于排查
跨源查询写法
跨源查询写法
-- catalog.schema.table 三级命名，一句 SQL 跨源 join
SELECT h.store_id, m.store_name, sum(h.pay_amt) AS pay_amt
FROM hive.dw.dwd_trade_order_hive h
JOIN mysql.dw.dim_store m ON h.store_id = m.store_id
WHERE h.dt = DATE '2026-10-12' -- 源侧先过滤，减少进入 join 的数据量
GROUP BY h.store_id, m.store_name
ORDER BY pay_amt DESC
LIMIT 100; -- 交互式查询带 limit，避免结果集撑爆内存
-- 先看执行计划确认下推情况，再决定是否需要改写 SQL
EXPLAIN (TYPE DISTRIBUTED)
SELECT count(*) FROM hive.dw.dwd_trade_order_hive WHERE dt = DATE '2026-10-12';常见 Connector 与下推
| Connector | 典型用途 | 下推能力 |
|---|---|---|
| Hive | 离线数仓表查询 | 谓词与分区裁剪下推 |
| Iceberg | 湖表分析 | 分区与文件统计裁剪 |
| JDBC 类 | 维表与业务库 | 谓词与投影下推，join 一般留在 Trino 侧 |
| Kafka | 流数据临时查看 | 有限，主要用于读取 |
| ClickHouse | 实时分析库 | 谓词可下推，聚合下推依赖写法 |
跨源 join 会把两端数据都拉到 Trino 侧处理。大表直接 join 容易让 worker 内存溢出，查询失败之外还可能影响同集群上其他正在跑的查询。
Trino 面向交互式查询，缺少大规模写入与失败重跑所需的能力。需要产出正式数据的重批处理仍应交给 Spark 或 Hive，用 Trino 做探索与验证。