解读

面试官抛出“30 秒跨数据中心延迟”这一极端场景，核心想验证三件事：

1. 能否把“30 秒”拆成可量化指标（网络 RTT、元数据拉取、数据拉取、计算排队、序列化/反序列化），并定位哪一段占大头；
2. 是否熟悉 Presto 的分布式架构（Coordinator–Worker、Discovery、Hive Metastore、RaptorX、Alluxio 本地缓存、Exchange 传输机制）；
3. 能否结合国内多活、两地三中心、专线带宽昂贵、合规数据不出境等现实约束，给出“可落地的”缓存+调度组合拳，而不是背官网参数。

知识点

1. Presto 查询生命周期：SQL 解析 → 计划拆分 → 调度 Split → Worker 通过 Hive/Hudi Connector 读远端存储 → 跨 DC Exchange Shuffle → 结果返回到 Client。
2. 延迟构成：①元数据请求（Metastore 跨 DC RTT 40 ms×N 次）；②原始数据请求（S3/OSS 跨 DC 下载 500 MB+ 大文件）；③ Exchange 数据跨 DC 传输（Hash Join 中间结果 1 GB+）；④ Coordinator 全局调度无感知拓扑，把 Task 发到“异地”Worker。
3. 缓存层级：
   • 元数据缓存：Hive Metastore cache、Glue cache、Coordinator 的 Partition cache；
   • 数据缓存：Alluxio Local Cache、RaptorX Node-local Cache、ORC/Parquet Footer Cache、FileSystem Cache；
   • 结果缓存：Presto Router 的 SELECT 级缓存、Bi 报表缓存、ETL 中间表物化。
4. 调度策略：
   • Soft Affinity Schedule：同 DC、同机架、同节点优先；
   • Resource Group + 队列隔离：按业务线、只读/写、跨 DC 查询打标签，限制并发度；
   • Split 调度感知：Coordinator 读取 Worker 的拓扑标签（如 availability-zone=sh-1），优先本地 Split；
   • Failback 策略：本地 DC 资源不足才溢出到远端 DC，避免 30 s 延迟常态化。
5. 国内合规与网络：金融、政企客户要求“数据不跨省”“专线带宽 200 M 共享”，必须让缓存命中率 > 95%，否则专线被打满，云厂商侧还会限速。

答案

回答采用“三步法”：先量化、再缓存、再调度，全程给出可验证指标，符合国内落地习惯。

第一步：量化瓶颈

1. 在 Presto 侧打开 DEBUG 级日志（query-execution-policy=LOG），拉取 30 s 慢查询的 Timeline：
   • Metadata Call Duration：若单分区 20 ms，跨 DC 1000 次调用即 20 s，占 60% 以上；
   • External Scan Data Size：若单 Worker 拉取 800 MB，跨 DC 带宽 100 Mbps，理论耗时 64 s；
   • Exchange Data Size：Hash Join 把 2 GB 中间结果发到对端 DC，RTT 40 ms，TCP 拥塞窗口小，实际 25 s。
2. 用 tcpdump 抓包，确认是否走公网；若走云厂商跨域对等连接，记录实际 RTT、重传率。
3. 输出《跨 DC 查询延迟拆解报告》，作为后续优化基线。

第二步：缓存策略
目标：把 95% 以上“冷”路径变成“本地”路径，专线流量下降 80%，查询 P99 从 30 s 降到 3 s。

1. 元数据缓存
   • 在 Coordinator 配置 hive.metastore-cache-ttl=30min，hive.metastore-refresh-interval=5min；
   • 对分区数 > 5 万的超大表，开启 hive.partition-projection-enabled=true，避免一次性拉全量分区。
2. 数据缓存
   • 部署 Alluxio 2.9 集群与 Presto Worker 同节点，配置 alluxio.user.local.reader.chunk.size=8MB，缓存磁盘采用 NVMe Raft 盘，单节点 2 TB；
   • 打开 Presto 的 cache.enabled=true，cache.base-directory=/alluxio/cache，缓存粒度 1 MB Block；
   • 对 500 MB 以上的事实表，提前用 presto-cache warmup 工具按“最近 7 天分区”预热，每天凌晨 3 点触发，命中率达到 96%。
3. 结果缓存
   • 在 Gateway 层加 Presto Router，配置 router.cache-ttl=300s，对 BI 仪表盘类 SQL（WHERE 条件带 dt=between 7 days）直接返回缓存，减少重复计算。
4. 缓存一致性
   • 采用 Hive Metastore Event Listener + Kafka 通知，Alluxio 收到 alter table 事件后 30 s 内失效对应缓存块，保证“数据更新即可见”。

第三步：调度策略
目标：让 Coordinator“看得见”机房拓扑，优先本地，溢出远端，同时防止热点。

1. 给 Worker 打标签
   • 启动参数 -Dnode.location=sh-1-a, -Dnode.location=bj-2-b，Coordinator 通过 discovery.uri 拿到标签；
   • 配置 scheduler.node-selection-strategy=TOPOLOGY，调度器优先选择同 location 的 Worker。
2. Resource Group 隔离
   • 在 resource-groups.json 新建 cross-dc 队列，maxRunning=3，把跨 DC 查询路由到该队列，防止把本地 DC 资源挤爆；
   • 对核心业务（支付对账）设置 hardConcurrencyLimit=1，保证最高优先级。
3. Split 级别拓扑感知
   • 修改 Hive Connector，让 Split 携带 location=sh-1-a 信息；Coordinator 只把 Split 发给同 location Worker，若无可用 Worker 再放宽到同 DC，最后才跨 DC。
4. 动态降级
   • 监控 Alluxio 缓存命中率 < 90% 或专线带宽使用率 > 70%，自动关闭跨 DC 查询入口，返回“请重试”提示，保护系统。
5. 灰度验证
   • 用 Presto TPC-DS 1 TB 数据集，在测试环境模拟 200 并发，跨 DC 查询 P99 从 28 s 降到 2.8 s，专线流量下降 82%，缓存命中率 97%，满足金融客户 SLA（P99 < 5 s）。

拓展思考

1. 如果客户要求“零数据落地”怎么办？
   可把 Alluxio 换成 MEMKIND 纯内存分布式缓存，单节点 512 GB，重启即失效，满足证券行业“数据不落地”合规，但需接受预热时间更长。
2. 当两个 DC 数据副本不一致时，如何保证结果正确？
   可在 Hive 表级增加 version 字段，每次写入递增；Presto 缓存 key 带上 version，发现 version 变化立即失效，防止读到旧数据。
3. 未来升级到 Trino 400+ 版本，联邦查询加入 Iceberg REST Catalog，如何继续复用上述缓存？
   Iceberg 的 Snapshot 机制天然带 version，可直接作为缓存 key；同时 Trino 的 Task Retry 支持 speculative execution，可结合 TOPOLOGY 策略，把重试 Task 发到本地 DC，进一步降低跨 DC 延迟。