请说明 Presto 实现跨数据源联合查询的具体方式和原理。

回答思路

1. 【回答框架 1】Presto 的跨数据源联合查询依赖 Connector 架构，每个 Connector 负责接入一种外部数据源，将数据源中的表抽象为可查询的关系表。通过统一的 SQL 接口，用户可以在同一查询中关联来自不同 Connector 的表，实现联邦查询。
2. 【回答框架 2】核心机制是 Connector 提供元数据（表结构、分区信息）和数据读取能力，查询引擎通过 SPI 接口与 Connector 交互。在执行跨源查询时，Presto 的 Coordinator 生成分布式执行计划，将涉及不同数据源的表分别下推给对应 Connector 进行数据读取，并在引擎内部进行连接、聚合等后续计算。
3. 【回答框架 3】典型场景包括关联 Hive 中的维度表与 MySQL 中的业务表，或关联 Kafka 流数据与对象存储中的历史数据。联合查询的关键在于 Connector 的元数据 API 和数据源能力，例如是否支持谓词下推、分区裁剪等，这直接影响查询性能。
4. 【回答框架 4】配置上需要对每个数据源创建对应的 Catalog，例如在 etc/catalog 下配置 hive.properties、mysql.properties 等文件，指定连接信息和 Connector 类型。查询时使用 catalog.schema.table 的三段式命名来引用不同数据源的表。
5. 【回答框架 5】权限管理方面，Presto 可以在 Connector 级别配置认证，但跨源查询的权限控制需要数据源自身支持，Presto 本身不提供统一的跨源权限模型，实际部署中需注意安全边界和控制访问。
6. 【关键点 1】Presto 通过 Connector 架构实现跨源查询，每个数据源对应一个 Connector。
7. 【关键点 2】联合查询依赖统一 SQL 接口和 SPI 元数据抽象。
8. 【关键点 3】执行时各数据源表下推给对应 Connector 读取，引擎负责后续计算。
9. 【关键点 4】使用 catalog.schema.table 命名引用不同源的表。
10. 【关键点 5】性能受数据源下推能力影响，如谓词下推和分区裁剪。
11. 【易错点 1】不要误以为联合查询会全量拉取数据到 Presto 再计算，实际会尽量下推过滤条件。
12. 【易错点 2】不要忽略 Connector 配置缺失导致的查询失败，每个源都需要正确配置 Catalog。
13. 【易错点 3】跨源查询的权限控制需依赖各数据源自身安全机制，Presto 不统一管理。