Uber使用Presto优化快速查询的探索与实践

Uber采用开源的分布式SQL查询引擎Presto，用于跨多个数据源（如Apache Hive、Apache Pinot、MySQL和Apache Kafka）提供分析服务。为了提升性能，Uber工程师特别针对快速查询（即express queries）进行了优化，显著提高了Presto的利用率和响应时间。

快速查询的定义与挑战

快速查询指的是在2分钟内完成的查询，约占Uber分析处理查询的一半。工程师发现，如果将这些查询与其他查询同等处理，会导致系统资源利用率低和延迟高，因为系统为了防止过载会对查询进行限流。

预测快速查询的方法

为了避免快速查询被限流，Uber工程师首先需要预测哪些查询属于快速查询。他们基于历史数据，为每个查询分配了一个精确指纹，即去除注释、空格和字面值后计算的唯一哈希值。通过测试不同指纹类型（精确指纹和抽象指纹）和回溯窗口（2天、5天和7天）下的P90和P95查询执行时间，工程师确定使用5天回溯窗口的抽象指纹P90值，可以最准确地预测查询是否能在2分钟内完成。

系统设计的迭代与优化

在设计快速查询处理系统时，Uber工程师经历了多次迭代：

1. 初始设计：将快速查询和非快速查询根据用户优先级放入同一队列，每个队列对应一个Presto集群，其中一部分集群专门处理快速查询。然而，这种设计导致快速查询集群利用率低，因为慢查询仍然影响快速查询的处理速度。
2. 改进设计：工程师尝试为快速查询创建专用队列，使其在进入系统后立即路由到专用集群。这一改进显著提高了75%以上调度查询的端到端SLA，并提升了集群利用率和快速查询的运行时间。
3. 进一步优化：在生产环境中运行后，工程师发现快速查询处理速度极快，无需根据优先级路由到不同队列。因此，他们开始设计一个完全独立的子系统，专门处理快速查询，以进一步提高集群利用率并简化路由逻辑。

总结

通过预测快速查询并优化其处理流程，Uber显著提升了Presto的性能。工程师将快速查询与非快速查询分离，并逐步优化系统设计，最终实现了更高的集群利用率和更快的查询响应时间。未来，Uber计划进一步简化快速查询的处理逻辑，以持续提升系统效率。