干货 | 性能指标提升50%+，携程数据报表平台查询效率治理实践

作者简介

携程OLAP引擎开发组，专注于大数据OLAP引擎trino/starrocks的开发与大规模部署和运维。

团队热招岗位：资深大数据平台开发工程师、OLAP分析引擎高级/资深开发工程师

本文概述了面对公司数据报表平台遇到的查询性能挑战，数据平台组围绕数据缓存、物化视图、查询策略、SQL质量等方向所做的一系列治理工作，以提升平台的查询效率和稳定性。通过这些工作，平台的查询响应时间得到了显著的改善，其中平均响应时间从原来的8秒降低至4秒，响应时间90线由原先的约18秒降低至约8秒，总体性能指标提升幅度达50%以上。本文在各个小节中对各治理策略的关键原理和思路进行了阐述，希望能够为读者提供一定的参考和启发。

• 一、背景

• 二、平台设计概览

• 三、多维度数据缓存

• 3.1 底表Data Cache预热

• 3.2 HDFS元数据缓存

• 3.3 Router Redis 缓存

• 3.4 Download 缓存

• 3.5 小结

• 四、使用物化视图加速查询

• 4.1 视图定义：为数据集构建MV

• 4.2 视图利用：MV自动改写

• 4.3 视图维护：MV自动刷新

• 4.4 MV价值发掘

• 4.5 小结

• 五、查询策略优化和SQL质量治理

• 5.1 整点调度问题治理

• 5.2 查询流量切分

• 5.3 Max-d查询专项治理

• 5.4 SQL实现优化

• 5.5 潜在慢查询阻断机制

• 六、成效

• 七、总结

一、背景

数据报表平台（代称Nova，后同）用于支持携程内部数据分析、数据挖掘、数据可视化等业务需求，目前每日承载数十万Hive表AP查询，所涉数据量达万亿级别。随着用户基数逐步提升，承载查询量不断增大，平台查询性能面临挑战，具体表现如下：

1）平均响应时间延长，大查询在业务高峰期存在阻塞现象，超时数量增多；

2）查询所需时间不稳定，性能波动较大，在业务高峰期可能出现响应时间突增现象；

3）查询负载集群资源占用率高，CPU、内存资源吃紧，I/O 请求排队等待，进而导致集群稳定性下降，时有节点宕机现象出现。

针对上述现象，我们从平台自身服务、SQL路由分发组件、SQL执行引擎等方面入手，采用了一套“全方位组合拳”对平台的查询性能进行治理，目标有二：

1）从用户体验角度：改善查询性能，提升查询效率和稳定性；

2）从集群维护角度：提升集群稳定性，增强查询结果复用能力，提高算力使用效率。

二、平台设计概览

数据报表平台执行查询的主要链路如图1所示，其中有几个关键构件：

图1：Nova 数据查询链路

1）Nova：应用本体，提供可视化用户界面，包含报表即时查询、执行离线定时任务等功能；

2）Router：用于分离指向不同引擎的查询请求，起到SQL路由功能；

3）Starrocks & Hive：平台使用Starrocks作为主要查询引擎，向Hive外表发起查询请求。

三、多维度数据缓存

在硬件资源有限的情况下，要提升查询性能，最直观的思想是对重复的查询进行结果复用。在对平台的查询请求数据进行统计分析后，可发现存在相当数量的查询请求在不同时段内重复出现，这为我们引入缓存机制提供了实践基础。

若将在执行过程中可能遭遇瓶颈的查询进行划分，可将大致分为I/O型、计算型和高频型三类，其中I/O型查询对网络和磁盘带宽的要求较高，往往涉及大规模数据的扫描；计算型查询对CPU和内存资源的要求较高，往往涉及大量连接、分组、聚合、筛选、再计算操作；高频型查询的单次调用开销可能较小，但在单位时间内发起的次数显著高于均值，在涉及远程调用（