2. Trino基础概念
在金融湖仓场景中，Trino 常被用作统一查询入口，向上承接 BI、即席分析、风控探查与数据服务，向下连接 Hive、Iceberg、Hudi、关系库、Kafka、对象存储等多类数据源。要真正用好 Trino，必须先理解它的基础概念：它不是一个传统数据库，而是一个分布式 MPP SQL 查询引擎。它不存储数据，而是通过 Connector 把外部系统映射成可查询的表，再把一条 SQL 拆解成多个阶段，在集群中并行执行。
一、核心原理：Coordinator、Worker 与 MPP 模型
Trino 集群由两类角色组成：Coordinator 和 Worker。Coordinator 是大脑，负责接收客户端连接、解析 SQL、生成执行计划、优化计划、调度任务并汇总最终结果；Worker 是执行者，负责实际读取数据、计算、过滤、聚合、连接和交换中间结果。一个集群通常只有一个 Coordinator，但可以有多个 Worker。Coordinator 也可以配置为同时承担计算任务，但在生产环境中更建议让它专注调度，避免资源争抢。
Trino 采用 MPP（Massively Parallel Processing，大规模并行处理）模型。一条查询会被拆成多个 Stage，每个 Stage 又拆成多个 Task，Task 再拆成多个 Driver，Driver 内部由 Operator 组成。Stage 之间通过 Exchange 交换数据，形成流水线。这样做的关键价值是：当数据量从 GB 增长到 TB 甚至 PB 时，查询不是靠单机堆资源，而是靠横向扩展 Worker 来提升吞吐。
关键理解：Trino 的并行不是“多个线程读同一张表”这么简单，而是“把查询计划切成可并行的片段，再让多个 Worker 同时处理不同数据分片”。因此，表是否可切分、Connector 是否支持并行读取、数据布局是否合理，都会直接影响性能。
二、Connector、Catalog 与 Schema：Trino 如何“看见”数据
Trino 本身不存数据，它通过 Connector 连接外部系统。Connector 是适配器，决定 Trino 能否读取某类数据源、支持哪些操作、如何下推谓词、如何切分数据。例如 Hive Connector 可以读取 HDFS 或对象存储上的 Hive 表，Iceberg Connector 支持 Iceberg 表格式与快照查询，MySQL Connector 可以访问关系库表，Kafka Connector 可以把 Topic 映射成表。
在 Trino 中，Catalog 是 Connector 的命名空间。一个 Catalog 通常对应一个数据源实例，例如 hive、iceberg、mysql。每个 Catalog 下可以有多个 Schema，Schema 下才是 Table、View 等对象。因此，Trino 中一张表的完整限定名是：
catalog.schema.table
-- 例如：
hive.finance.orders
iceberg.risk.txn_detail
mysql.crm.customer_profile这种三层命名方式让联邦查询变得自然：一条 SQL 可以同时关联 Hive 中的订单表、MySQL 中的客户表和 Iceberg 中的风控明细表。对金融场景来说，这意味着无需先把所有数据搬运到同一个存储，就能完成跨系统分析。
| 概念 | 作用 | 金融场景示例 |
|---|---|---|
| Connector | 连接外部数据源的适配器 | Hive、Iceberg、MySQL、Kafka |
| Catalog | Connector 的命名空间与配置入口 | hive、iceberg、mysql |
| Schema | Catalog 下的库/命名空间 | finance、risk、crm |
| Table | 实际可查询的数据对象 | orders、txn_detail、customer_profile |
三、查询执行流程：从 SQL 到分布式任务
当客户端提交一条 SQL 后，Trino 的执行流程大致如下：
- 解析与校验：Coordinator 解析 SQL 文本，生成抽象语法树，并校验表、列、函数是否存在。
- 逻辑计划与优化：生成逻辑执行计划，进行谓词下推、列裁剪、连接重排、分区裁剪等优化。
- Stage 划分：根据数据交换边界把查询拆成多个 Stage，例如 Source Stage、Join Stage、Aggregation Stage、Output Stage。
- Task 调度：每个 Stage 拆成多个 Task，分配到不同 Worker 上执行。
- 并行执行：Worker 内部通过 Driver 和 Operator 读取数据、过滤、聚合、连接，并通过 Exchange 交换中间结果。
- 结果汇总：Coordinator 收集最终结果并返回客户端。
提示：在排查慢查询时，不要只看 SQL 文本。应结合 EXPLAIN 或 EXPLAIN ANALYZE 观察 Stage 划分、数据交换量、Task 分布和算子耗时，判断瓶颈是在扫描、连接、聚合还是网络交换。
四、案例与误区复盘
假设某金融公司需要分析“高风险客户的交易行为”，数据分散在 Hive 订单表、Iceberg 风控明细表和 MySQL 客户表。使用 Trino 可以这样查询：
SELECT c.customer_id,
c.risk_level,
o.order_amount,
t.txn_type
FROM mysql.crm.customer_profile c
JOIN hive.finance.orders o
ON c.customer_id = o.customer_id
JOIN iceberg.risk.txn_detail t
ON o.order_id = t.order_id
WHERE c.risk_level = 'HIGH'
AND o.dt = DATE '2025-01-15';这条 SQL 体现了 Trino 联邦分析的价值：一次查询跨三个系统。但常见误区也需要警惕：
- 误区一：把 Trino 当存储引擎。Trino 不负责持久化数据，不能替代 Hive、Iceberg 或关系库。
- 误区二：忽视 Connector 能力差异。不同 Connector 对谓词下推、分区裁剪、并发读取的支持不同，性能差异可能很大。
- 误区三：小文件过多。在 Hive 或 Iceberg 场景中，大量小文件会导致 Task 数量膨胀，调度开销超过计算收益。
- 误区四：只看 Coordinator。Coordinator 负责调度，Worker 才是算力主体；Worker 不足或数据倾斜时，查询会明显变慢。
复盘建议：在金融湖仓中，优先把大表放在支持分区裁剪和列式读取的 Connector 上；跨源 Join 时，尽量让过滤条件尽早下推，减少 Exchange 数据量；对高频查询，关注 Stage 并行度与 Worker 负载是否均衡。
理解 Coordinator 与 Worker 的分工、Connector/Catalog/Schema 的映射关系，以及 MPP 模型下 Stage、Task、Driver 的执行方式，是后续学习 Trino 查询优化、联邦分析与生产运维的基础。只有把“查询如何被拆解、数据如何被读取、结果如何被汇总”这条链路看清楚，才能在金融湖仓的复杂场景中写出稳定高效的 SQL。