请说明 Presto 在执行涉及多个数据源的 JOIN 操作时的底层实现机制，并给出针对这类跨源查询的优化策略。
考察说明
考查对 Presto 分布式查询引擎中跨数据源连接实现原理及性能调优方法的理解。
回答思路
- 【回答框架 1】Presto 是一个分布式 SQL 查询引擎，跨数据源 JOIN 通过 Connector 抽象实现。每个数据源对应一个 Connector，负责提供 Split（数据分片）和 RecordSet。查询时，协调节点解析 SQL，生成逻辑执行计划，然后通过规则优化为物理执行计划，将 Join 操作分布在多个 Worker 节点上并行执行。
- 【回答框架 2】跨源 JOIN 实现的关键是数据在 Worker 间的传输。Presto 将涉及的表按 Join 键进行分区（Hash Partitioning），确保相同键的数据落到同一 Worker，然后进行 Hash Join。若一个源数据量较大，可构建 Hash Table，另一个源作为 Probe 端流式读取，减少内存压力。若数据分布不均，可能使用 Broadcast Join，将小表复制到所有 Worker，避免数据 Shuffle。
- 【回答框架 3】优化跨源查询可从减少数据移动和提升并行度入手。首先，使用 Connector 的谓词下推功能，尽量在数据源端过滤和投影，减少传输量。其次，通过 Table Statistics 选择正确的 Join 策略（Broadcast 或 Hash）。还可利用 Bucketed Table 和分桶键对齐，使 Join 在本地完成，避免网络传输。
- 【回答框架 4】此外，可调整会话参数如 join_distribution_type，或通过 Explain 分析执行计划，定位数据倾斜和低效操作。对于频繁使用的跨源视图，可考虑物化或引入缓存层，但需注意数据一致性。最后，合理配置 Worker 数量和内存参数，均衡负载。
- 【回答框架 5】实际优化需结合具体场景，比较不同策略的执行时间，持续迭代。Presto 的跨源能力强大，但成本集中在网络 I/O 和序列化，核心是让数据在正确的位置进行连接。
- 【关键点 1】跨源 JOIN 通过 Connector 抽象和分布式 Hash Join 实现，涉及数据分区和 Shuffle。
- 【关键点 2】谓词下推和列裁剪是减少跨源数据传输的基本优化手段。
- 【关键点 3】Join 策略选择（Broadcast 或 Hash）依赖表统计信息和数据分布。
- 【关键点 4】利用分桶表或本地亲和性可减少网络开销。
- 【关键点 5】通过 Explain 和会话参数调整可精细化优化查询。
- 【易错点 1】跨源 JOIN 不一定保证一致性快照，不同数据源的事务隔离级别可能不同。
- 【易错点 2】过度依赖 Broadcast Join 可能导致内存溢出，需限制小表大小。
- 【易错点 3】谓词下推受限于数据源能力，并非所有过滤器都能下推，需验证实际效果。