Trino（前 PrestoSQL）是分布式 SQL 查询引擎，2012 年起源于 Facebook，2019 年从 PrestoDB 分叉，2020 年改名 Trino，2021 年 Trino Foundation 加入 Linux Foundation。7 年间凭借 联邦查询（一个 SQL 查多个异构数据源）+ 30+ connector（Hive / Iceberg / Delta Lake / ClickHouse / MySQL / S3 / Kafka 等）+ ANSI SQL 兼容，成为大数据查询的事实标准。本文带你深入 Trino 的核心能力、版本演化、生态，以及它跟 ClickHouse / Doris / StarRocks / Spark SQL 的对比选型。
写在前面
“ 大数据查询 ” 这事儿，国内国外走了三条路。
国外老牌：Hadoop 生态（Hive / Pig / Presto / Spark SQL）—— 大数据查询的事实标准，2010-2020 主导
国内新锐：MPP 数据库（Apache Doris / StarRocks）—— 2018-2026 崛起，主打实时数仓
专用引擎：ClickHouse / DuckDB / Druid / Pinot —— 2016-2026 涌现，各有专长
Trino 是 ” 国外老牌路线 ” 的 现代继承者 ——它不存储数据， 纯查询层 ，通过 30+ connector 把 Hive / Iceberg / Delta Lake / MySQL / ClickHouse / S3 / Kafka 当成 ” 虚拟表 ”， 一个 SQL 查所有数据源。
但 Trino 跟 ClickHouse / Doris 是 互补不是竞争——ClickHouse 是 ” 存 + 查 ” 一体，Trino 是 ” 只查不存 ”。
飞熊做技术咨询，如果客户的数仓是 数据湖架构 （Iceberg / Delta Lake / Hudi）+ 多种数据源需要 联邦查询——Trino 是默认答案。
一、它解决什么问题
一句话 ：Trino 让你 一个 SQL 同时查多个异构数据源 （Hive + MySQL + ClickHouse + Kafka + S3 …）， 不需要数据复制，结果直接 JOIN 出来。
| 场景 | 例子 | Trino 表现 |
|---|---|---|
| 数据湖查询 | Iceberg / Delta Lake / Hudi on S3 | 直接查 lakehouse 表，无需 ETL |
| 跨源联邦查询 | Hive ⨝ MySQL ⨝ Kafka ⨝ ClickHouse | 一个 SQL，跨源 JOIN |
| Hive 替代 | 替代 Hive + MapReduce 慢查询 | 10-100 倍提速 |
| 数仓加速 | Snowflake / BigQuery / Redshift 前置查询 | 不动数仓，Trino 直查原始数据 |
| 实时分析 | Kafka 流数据查询 | Kafka connector，毫秒延迟 |
| 临时分析 | 分析师自由查询（ad-hoc） | 标准 ANSI SQL + JDBC / ODBC |
基本信息：
| 维度 | 数据 |
|---|---|
| GitHub | trinodb/trino |
| Stars | 13,148（比池子里标的 11K 多 2K） |
| Forks | 3,731 |
| Open Issues | 2,700（量大但健康） |
| License | Apache-2.0 ✅（无任何商用风险） |
| 首次 commit | 2019-01-19（Trino 分叉点，PrestoSQL 历史从 2012 起） |
| 最近 commit | 2026-08-16（今天还在推代码） |
| 仓库大小 | 311 MB（Java 巨型单体） |
| 主语言 | Java 96%+ |
| 最新版本 | Trino 483+（2026.8 当前稳定版） |
| 项目状态 | Linux Foundation 旗下 Trino Foundation（2021 成立） |
| 出身 | Facebook 2012 开源 → 2019 PrestoSQL 分叉 → 2020 改名 Trino → 2021 LF |
二、核心能力全景：5 大特性 + 30+ connector
1. Federated Query（联邦查询）⭐ 核心
Trino 不是数据库，是查询引擎
Trino 不存储数据——它通过 connector 把外部数据源抽象成 schema，把表 / 列 / 行映射成 Trino 的数据模型。
-- 一个 SQL 同时查 Hive + MySQL + Kafka + ClickHouse
SELECT
o.order_id,
o.amount,
c.name AS customer_name,
i.product_name,
k.click_count
FROM hive.sales.orders o
JOIN mysql.customers.users c ON o.user_id = c.id
JOIN kafka.events.clicks k ON o.session_id = k.session_id
JOIN clickhouse.products.items i ON o.product_id = i.sku
WHERE o.order_date >= CURRENT_DATE - INTERVAL '7' DAY;
30+ 内置 connector（按类型分组）：
| 类别 | connector |
|---|---|
| 数据湖 | Hive / Iceberg / Delta Lake / Hudi |
| 关系数据库 | MySQL / PostgreSQL / Oracle / SQL Server / MariaDB / Redshift / Snowflake / BigQuery |
| 专用引擎 | ClickHouse / Elasticsearch / OpenSearch / Pinot / Druid |
| 消息队列 | Kafka / RabbitMQ / Kinesis / Pulsar |
| 文件 / 对象存储 | S3 / GCS / Azure Blob / HDFS / Local File |
| NoSQL | MongoDB / Cassandra / Redis / Memcached / Prometheus |
| 其他 | JMX / TPC-H / TPC-DS / Black Hole（测试用） |
特别亮点：ClickHouse connector——Trino 可以直接联邦查询 ClickHouse 数据，跟 ClickHouse (322) 形成完美组合
2. ANSI SQL 兼容
Trino 支持完整 ANSI SQL（包括窗口函数、CTE、JOIN、GROUP BY、ORDER BY、LIMIT、EXPLAIN）：
-- 窗口函数
SELECT
user_id,
order_date,
amount,
SUM(amount) OVER (PARTITION BY user_id ORDER BY order_date) AS cumulative_amount
FROM hive.sales.orders;
-- CTE
WITH monthly_revenue AS (
SELECT
DATE_TRUNC('month', order_date) AS month,
SUM(amount) AS revenue
FROM hive.sales.orders
GROUP BY 1
)
SELECT * FROM monthly_revenue ORDER BY month;
跟 ANSI 差异：方言名为 Trino SQL（部分语法兼容 PostgreSQL）。
3. Cost-Based Optimizer（CBO）
Trino 的优化器是 基于成本的优化器：
- 统计信息收集（ANALYZE TABLE）—— 自动 / 手动
- Join 重排—— 自动选择最优 Join 顺序
- 谓词下推（Predicate Pushdown）—— 把 WHERE 推到 source connector 减少数据传输
- 分区裁剪（Partition Pruning）—— 跳过无关分区
- 连接下推（Pushdown）—— 把整个查询下推到 source（如 ClickHouse 直查）
4. MPP 分布式架构
┌─────────────────────────────────────────┐
│ Trino Cluster │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ Coordinator │◄──►│ Worker × N │ │
│ │ (调度 + 优化) │ │ (执行 +IO) │ │
│ └──────────────┘ └──────────────┘ │
│ ▲ ▲ │
└────────────┼──────────────────┼─────────┘
│ │
┌────┴────┐ ┌────┴────┐
│ Hive │ │ MySQL │
│ Iceberg │ │ Kafka │
│ S3 │ │ ... │
└─────────┘ └─────────┘
- Coordinator：解析 SQL + 优化 + 调度 + 监控（单点，可 HA）
- Worker：执行 stage + 拉数据（可横向扩展 到几百节点）
- 内存计算 ：数据 不落盘，worker 之间用 shuffle 协议交换
- Stage + Task：查询被切成 stage，每个 stage 切成 task 并行执行
5. 多语言客户端 + 协议
| 客户端 | 语言 | 包 |
|---|---|---|
| JDBC | Java | io.trinosql:trino-jdbc |
| ODBC | Windows | 官方 ODBC driver |
| Python | Python | trino-python-client |
| R | R | trino / dplyr |
| Golang | Go | trino-go-client |
| Node.js | JS | presto-client-js |
| CLI | — | trino-cli |
REST 协议：HTTP + JSON + SOCKS（兼容 Presto 协议）。
三、版本演化：Presto → Trino → Linux Foundation
2012 - Facebook 开源 Presto（PrestoDB 路线）↓
2013 - 0.x → 0.100+（快速增长，被 Netflix / Airbnb / 京东广泛采用）↓
2018 - 社区分裂：PrestoDB（Meta 主导，闭源路线）vs PrestoSQL（社区主导，开源路线）↓
2019-01 - PrestoSQL 分叉仓库成立
↓
2020-12 - PrestoSQL 改名 Trino（避免混淆）↓
2021 - Trino Foundation 成立，加入 **Linux Foundation**
↓
2022-2024 - 持续演进：向量化执行 / CBO / Iceberg 集成
↓
2026 - Trino 483+（持续滚动，3 周 1 个 release）重点八卦：
- PrestoDB vs PrestoSQL：2018 年社区因为治理分歧分裂，PrestoDB 由 Meta 主导走闭源路线，PrestoSQL 由社区主导走开源路线。2020 年 PrestoSQL 改名 Trino——Trino 是 PrestoSQL 的延续，不是 PrestoDB 的延续。
- Linux Foundation 治理 ：2021 年 Trino Foundation 加入 LF，避免被任何单一公司（Meta / AWS / Google）控制， 保证开源中立性。
- 生态盟友：AWS Athena / Starburst / Ahana 都是基于 Trino 的商业化产品。
四、生态系统：商业化 + 数据湖 + 工具链
1. 商业化产品（基于 Trino）
| 产品 | 公司 | 定位 |
|---|---|---|
| Starburst Enterprise | Starburst Data | 企业级 Trino + 安全 + 多集群 + 商业支持 |
| AWS Athena | AWS | 托管 Trino（兼容 Presto 协议） |
| Starburst Galaxy | Starburst Data | SaaS 版 Starburst |
| Ahana Cloud | Ahana | 托管 Trino（开源 Presto 兼容） |
| Trino on K8s | 社区 + 各厂商 | Kubernetes Operator 部署 |
2. 数据湖生态
| 表格式 | 集成度 | 说明 |
|---|---|---|
| Apache Iceberg | ⭐⭐⭐ 深度集成 | Trino 是 Iceberg 的 事实查询引擎之一 |
| Delta Lake | ⭐⭐⭐ 深度集成 | Trino 直接查 Delta 表 |
| Apache Hudi | ⭐⭐ 支持 | Trino 0.309+ 起 |
| Apache Hive | ⭐⭐⭐ 经典集成 | Presto 时代的标配 |
Iceberg + Trino 是 2026 数据湖的事实标准——Iceberg 提供 ACID 表格式，Trino 提供高性能查询
3. 工具链集成
| 工具 | 集成 |
|---|---|
| dbt | ✅ dbt-trino adapter（跟 290 dbt-core 直接对接） |
| Apache Airflow | ✅ trino hook / operator |
| Dagster | ✅ dagster-trino |
| Great Expectations | ✅ trino execution engine（跟 262 Great Expectations 对接） |
| Apache Superset | ✅ Trino database spec（跟 270 Superset 直接对接） |
| Metabase | ✅ Trino database spec（跟 274 Metabase 直接对接） |
| Lightdash | ✅ Trino connector（跟 272 Lightdash 直接对接） |
| Jupyter / Superset / Streamlit | ✅ JDBC / trino-python-client |
五、对比 ClickHouse / Doris / StarRocks / Spark SQL / PrestoDB
| 维度 | Trino | ClickHouse | Apache Doris | StarRocks | Spark SQL | PrestoDB |
|---|---|---|---|---|---|---|
| Stars | 13,148 | 49K | ~30K | ~9K | ~40K | ~16K |
| 协议 | Apache-2.0 ✅ | Apache-2.0 ✅ | Apache-2.0 ✅ | ELv2 ⚠️ | Apache-2.0 ✅ | Apache-2.0 ✅ |
| 类型 | 查询引擎 | 存储 + 查询 | 存储 + 查询 | 存储 + 查询 | 通用计算 | 查询引擎 |
| 存储数据 | ❌ 不存 | ✅ 列存 | ✅ 列存 | ✅ 列存 | ❌ 不存 | ❌ 不存 |
| 联邦查询 | ✅ 核心 | ❌ | ❌ | ❌ | ⚠️ 弱 | ✅ |
| 跨源 JOIN | ✅ | ⚠️ 弱 | ✅ | ✅ | ✅ | ✅ |
| Iceberg | ✅ 事实标准 | ⚠️ 实验 | ✅ | ✅ | ✅ | ✅ |
| 实时分析 | ✅ | ✅ 极强 | ✅ 强 | ✅ 强 | ⚠️ 弱 | ✅ |
| 单表聚合 | ⚠️ 中等 | ✅ 王座 | ✅ 强 | ✅ 极强 | ⚠️ 中等 | ⚠️ 中等 |
| 多表 JOIN | ✅ | ⚠️ 弱 | ✅ 强 | ✅ 强 | ✅ 强 | ✅ |
| ANSI SQL | ✅ | ✅（方言差异） | ✅（MySQL 兼容） | ✅（MySQL 兼容） | ⚠️ HiveQL | ✅ |
| 数据湖 | ✅ 极强 | ⚠️ 弱 | ✅ 中等 | ✅ 中等 | ✅ 极强 | ✅ 极强 |
| 流数据 | ✅ Kafka | ✅ Kafka | ✅ Routine Load | ✅ Routine Load | ✅ Structured Streaming | ✅ Kafka |
| 学习曲线 | ⚠️ 中（ANSI SQL） | ⚠️ 中 | ✅ 低（MySQL 兼容） | ✅ 低 | ❌ 高 | ⚠️ 中 |
| 资源占用 | ⚠️ 高（内存） | ⚠️ 高 | ⚠️ 高 | ⚠️ 高 | ❌ 极高 | ⚠️ 高 |
| 部署 | 集群 / K8s / 托管 | 集群 / 嵌入式 | 集群 / 托管 | 集群 / 托管 | 集群 / EMR / Databricks | 集群 |
结论怎么选：
| 你的场景 | 选谁 |
|---|---|
| 数据湖 / Iceberg / 跨源联邦查询 | Trino ✅ |
| 实时数仓 / 高并发点查 / MySQL 兼容 | Doris / StarRocks |
| 极致单表聚合 / 时序数据 / IoT | ClickHouse |
| 超大规模数据 + 复杂 ETL + 机器学习 | Spark SQL |
| 联邦查询 + Trino 协议兼容 + 商业支持 | Starburst / AWS Athena |
| 数仓原始表 + 不动数仓直接查 | Trino / PrestoDB |
对比已调研的飞熊 8 月 BI 栈：
| 已调研项目 | 跟 Trino 的关系 |
|---|---|
| ClickHouse (322) | 完美互补 ——Trino 是查询层（不存），ClickHouse 是存储 + 查询层；Trino 可以 联邦查询 ClickHouse |
| Apache Doris (296) | 同位竞争 + 互补——Doris 是 MPP 数仓（存 + 查），Trino 是查询引擎（不存） |
| Apache Iceberg (296 提过) | 事实搭档——Trino 是 Iceberg 头号查询引擎 |
| dbt-core (290) | 完美对接——dbt-trino adapter 直接在 Trino 上做 ELT |
| sqlmesh (292) | dbt 替代品——同样支持 Trino |
| Airflow (306) | 上游编排——Airflow 调度 Trino SQL 任务 |
| Great Expectations (262) | 数据质量——Great Expectations 用 Trino 做校验引擎 |
| Apache Superset (270) / Metabase (274) / Lightdash (272) | 下游可视化——都支持 Trino 作为数据源 |
| Apache ECharts (324) | 下游渲染——ECharts 渲染 Trino 查询结果 |
| Evidence.dev (314) / WrenAI (316) / DB-GPT (318) | 下游分析——AI 原生 BI 工具查 Trino 联邦查询的结果 |
Trino 在飞熊 BI 栈的位置：
数据源（API/DB/Files）↓
Airbyte (326) ── ETL ──► 数据湖（Iceberg / Delta Lake / Hive）↓
Trino (联邦查询) ◄── ClickHouse (322) [下推]
↓
dbt (290) ── 转换 ──► 数仓 / 视图
↓
Superset (270) / Metabase (274) / Lightdash (272) / Evidence (314) / WrenAI (316) / DB-GPT (318)
↓
ECharts (324) [渲染]
Trino 是 ” 查询中枢 ”——所有数据通过它统一暴露给下游。
六、实战：3 步跑通 Trino
Step 1：本地安装（Tarball 模式）
# 1. 下载最新版本
wget https://repo1.maven.org/maven2/io/trino/trino-server/483/trino-server-483.tar.gz
# 2. 解压
tar -xvf trino-server-483.tar.gz
mv trino-server-483 trino-server
# 3. 创建配置目录
mkdir -p /etc/trino
# 4. 配置 config.properties
cat > /etc/trino/config.properties <<EOF
coordinator=true
node-scheduler.include-coordinator=true
http-server.http.port=8080
discovery.uri=http://localhost:8080
EOF
# 5. 配置 jvm.config
cat > /etc/trino/jvm.config <<EOF
-server
-Xmx16G
-XX:+UseG1GC
-XX:+ExplicitGCInvokesConcurrent
EOF
# 6. 配置 node.properties
cat > /etc/trino/node.properties <<EOF
node.environment=dev
node.id=uuid-abc-123
node.data-directory=/var/trino/data
EOF
# 7. 启动
bin/launcher start
# tail -F /var/log/trino/server.log
# 8. 下载 CLI（可选）wget https://repo1.maven.org/maven2/io/trino/trino-cli/483/trino-cli-483-executable.jar
chmod +x trino-cli-483-executable.jar
./trino-cli-483-executable.jar --server localhost:8080
Step 2：配置 connector（Iceberg + MySQL + ClickHouse）
# 在 etc/trino/catalog/ 目录创建 catalog 配置
# Iceberg on S3
cat > etc/trino/catalog/iceberg.properties <<EOF
connector.name=iceberg
hive.metastore.uri=thrift://metastore-host:9083
fs.native-s3.enabled=true
s3.endpoint=https://s3.amazonaws.com
s3.region=us-east-1
s3.access-key=${S3_ACCESS_KEY}
s3.secret-key=${S3_SECRET_KEY}
EOF
# MySQL
cat > etc/trino/catalog/mysql.properties <<EOF
connector.name=mysql
connection-url=jdbc:mysql://mysql-host:3306
connection-user=trino
connection-password=${MYSQL_PASSWORD}
EOF
# ClickHouse（联邦查询！跟 ClickHouse 322 配合）cat > etc/trino/catalog/clickhouse.properties <<EOF
connector.name=clickhouse
connection-url=jdbc:clickhouse://clickhouse-host:8123
connection-user=default
connection-password=
EOF
Step 3：联邦查询
-- 列出所有 catalog
SHOW CATALOGS;
-- iceberg | mysql | clickhouse | system | ...
-- 跨源 JOIN：Iceberg 订单 + MySQL 用户 + ClickHouse 商品
SELECT
o.order_id,
o.amount,
u.name AS customer_name,
p.product_name
FROM iceberg.sales.orders o
JOIN mysql.crm.users u ON o.user_id = u.id
JOIN clickhouse.products.items p ON o.product_id = p.sku
WHERE o.order_date >= DATE '2026-01-01'
ORDER BY o.amount DESC
LIMIT 100;
-- 窗口函数 + CTE
WITH monthly_revenue AS (
SELECT
DATE_TRUNC('month', order_date) AS month,
SUM(amount) AS revenue,
COUNT(*) AS order_count
FROM iceberg.sales.orders
GROUP BY 1
)
SELECT
month,
revenue,
order_count,
SUM(revenue) OVER (ORDER BY month) AS cumulative_revenue
FROM monthly_revenue
ORDER BY month;
-- 物化视图（v435+ 支持 Iceberg 物化视图）CREATE MATERIALIZED VIEW iceberg.sales.monthly_revenue_mv AS
SELECT
DATE_TRUNC('month', order_date) AS month,
SUM(amount) AS revenue,
COUNT(*) AS order_count
FROM iceberg.sales.orders
GROUP BY 1;
七、风险与坑
1. 内存占用极高
Trino 是 内存计算——查询运行期间所有数据在内存，复杂查询（如大表 JOIN）可能 OOM。
缓解：单 Worker 配置 32-128 GB 内存；查询超过内存会自动 spill 到磁盘（v427+）
2. 集群部署复杂
Trino 集群 至少需要 1 Coordinator + N Worker，单机模式（coordinator+worker 同机）适合测试，生产必须分离。
缓解：用 K8s Operator（trinodb/trino-kubernetes-operator）或托管服务（Starburst / Ahana）
3. 元数据依赖（Iceberg/Hive 需要 metastore）
Iceberg 和 Hive connector 需要外部 metastore（HMS / Glue / Unity Catalog）—— 增加了部署复杂度。
缓解：用 Nessie 或 Polaris 替代 HMS（catalog-rest 服务）
4. 2,700 open issues
issue 量多——但绝大多数是 feature request 和边缘 bug。
5. 实时性受 connector 限制
Trino 自身的查询性能极强，但 数据源的实时性 取决于 connector。比如 Kafka connector 毫秒级，Hive 可能有分钟级延迟。
6. 不存储数据 = 没有事务
Trino 没有事务、没有 UPDATE / DELETE（联邦查询模式下）——这些需要数据源自己支持。
7. Iceberg 物化视图是 2026 新功能
v435+ 才稳定，生产环境建议先用 dbt 物化。
八、总结
Trino 不是 ” 又一个 OLAP 引擎 ”——它是 “ 大数据查询层 ” 的事实标准 ，跟 ClickHouse / Doris 形成 查询层 vs 存储层 分工。
3 个最值得用的理由：
- 联邦查询王者 ：一个 SQL 查 30+ 异构数据源（Iceberg / Hive / MySQL / ClickHouse / Kafka / S3 …）， 不需要数据复制，跨源 JOIN
- 数据湖事实标准：Apache Iceberg + Trino 是 2026 数据湖架构的标配，比 Spark SQL 更轻量
- 生态完整 + Apache 2.0：跟 dbt(290) / Airflow(306) / Great Expectations(262) / Superset(270) / Metabase(274) / Lightdash(272) / Evidence(314) / WrenAI(316) / DB-GPT(318) / ECharts(324) 天然对接，无 License 风险
1 句建议：
如果你的数据架构是数据湖（Iceberg / Delta Lake）+ 多数据源需要联邦查询——用 Trino（Apache 2.0 ✅ / 13K stars / Linux Foundation 治理）。
如果你的场景是纯实时数仓 / 高并发点查——看 Doris (296) / StarRocks。
如果你的场景是极致单表聚合 / IoT 时序——看 ClickHouse (322)。
如果你的场景是 Spark 全家桶 + 机器学习 + ETL——看 Spark SQL。
Trino + ClickHouse + dbt 是飞熊 BI 栈里 最值得推荐的三件套：Trino 查跨源数据 → dbt 转换 → ClickHouse 加速热查询。
参考
- Trino GitHub · 13K stars / Apache-2.0 / Java
- Trino 官方文档 · 完整 setup + connector 文档
- Trino 官网 · 项目主页
- Trino Foundation · Linux Foundation 旗下
- Trino Use Cases · 官方场景说明
- Starburst Enterprise · 基于 Trino 的商业产品
- Apache Iceberg · Trino 的头号数据湖搭档
- PrestoDB GitHub · Presto 原始分支（已闭源路线）
- dbt-trino · dbt 的 Trino adapter
- Trino Kubernetes Operator · K8s 部署
- AWS Athena · 基于 Trino 协议的托管服务
- Trino 演进史 · 2020-12-27 改名公告
正文完