1. 引言
日前，2024年数据库领域顶会ACM SIGMOD/PODS会议在智利圣地亚哥举行，来自阿里云瑶池数据库团队的论文《Flux: Decoupled Auto-Scaling for Heterogeneous Query Workload in Alibaba AnalyticDB》成功入选SIGMOD Industrial Track（工业赛道）。
云数据仓库的混合查询负载的波动性会导致负载峰值资源不足以及低谷资源空闲，从而影响云数仓的性能及资源效率。在保证混合查询负载性能的同时，实现大规模CPU资源的高效调度，是一项极具挑战的任务。
论文提出的Flux通过使用AI技术将短时和长时查询解耦进行自动弹性，解决了云数据仓库的性能瓶颈，同时支持了资源按需预留。Flux优于传统的方法，查询响应时间 (RT) 最多可减少75%，资源利用率提高19.0%，成本开销降低77.8%。
该技术已应用在CPU百万核规模的AnalyticDB调度场景中，AnalyticDB是阿里云2014年推出的自研云原生数据仓库，AnalyticDB MySQL版为千万家企业级客户提供了数据处理ETL、实时在线分析、核心报表、大屏和监控能力，服务的场景包括实时数仓、精准营销、商业智能报表、多源联合分析、交互式查询等。
2. 论文背景
云数据仓库中查询工作负载的多样性导致资源利用率随时间而变化。如下图所示，AnalyticDB实例的实时CPU使用情况（蓝线）在五天内显著波动。混合查询工作负载的执行会导致长时间运行的查询性能不佳，长时查询影响短时查询的性能，保障峰值资源使用会导致资源的浪费。
3. Flux的整体架构
下图所示的 Flux 架构说明了我们以实用有效的方式实现解耦自动扩展的创新方法。Flux 的实现围绕两个核心设计目标：
- 目标G1：工作负载分离。在执行之前，应将长时间运行的查询与短时间运行的查询区分开来，然后在隔离的集群上执行。
- 目标G2：解耦自动扩展。运行短时间运行的查询和长时间运行的查询的集群采用不同的自动扩展机制并独立扩展。
这些目标是通过以下过程实现的。在每个 AnalyticDB 实例中，混合的异构工作负载首先由查询调度程序进行分类，然后分离独立的进行资源弹性。在多个 AnalyticDB 实例下，为了提高弹性和效率，我们构建了共享资源池和按需资源池。具体的架构如下图，包括查询调度器、多集群组的自动扩展、Job资源调度、共享资源池自动伸缩等组件构成。
4. Flux的设计和实现
4.1 查询调度器
Flux的查询调度器负责对短期运行和长期运行的查询（例如，RT 超过 3 分钟）进行分类，然后进行调度。此外，查询调度器有望实现三个设计目标：高精度、轻量级(900 QPS)、增量训练。
为了实现设计目标，我们开发了一个查询调度器，它由模板分类器和级联AI机器学习分类器组成。下图展示了查询调度器的工作流程，所有 SQL 查询都传递给模板分类器。如果 SQL 查询无法匹配任何模板，或者模板很少见，则将其交给 ML 分类器。
4.2 多集群组的自动扩展
当长时运行的查询解耦出来后，短时查询的负载波动平缓，使用AI时序预测算法可以获得较好的预测准确性。我们开发了一个多集群自动扩展器，以提高多集群组的查询性能和资源利用率。首先，它由工作负载预测器启用，支持主动自动扩展；其次，它支持性能触发的被动自动扩展。
4.3 自动扩展路径
在 Flux 中，多集群自动扩展器和作业资源调度器独立做出扩展/调度决策（例如，请求更多资源）。为了满足资源请求，资源调度器决定是从共享资源池还是从按需资源池中获取资源。资源调度器会考虑弹性容忍度和资源成本来做出决策。
在Flux中，资源调度程序旨在管理不同紧急程度的资源请求，如下图中的弹性容忍轴所示。此轴将请求分为两层。第 1 层（红色）请求预计资源将在 5 秒内配置完毕。在Flux中，当工作负载预测器未按预期执行且启用了被动自动扩展时，就会发生第 1 层请求。这表明查询性能下降，因此应尽快配置资源。第 2 层（蓝色）请求预计资源将在 30 秒内配置完毕。第 2 层包含来自多集群自动扩展器的主动扩展请求，这些请求基于 30 秒工作负载预测器的预测。
4.4 共享资源池自动伸缩
为了最小化共享资源池和按需资源池的资源总成本，我们首先建立一个成本模型，评估云供应商为了保障资源的弹性需要付出的资源成本。接下来，基于成本模型，我们提出了一种定期调整共享资源池规模的AI自动扩展算法。
成本模型：让我们用一个例子来介绍两个资源池的成本模型。在下图中，蓝色曲线表示所有实例共享同一个共享资源池的区域内所有AnalyticDB实例的总CPU分配；橙色曲线表示所有 Tier 1 请求的 CPU 分配（工作负载分离后）；虚线表示共享资源池的大小。𝑆1 表示共享资源池中搁置的资源。𝑆2 表示按需资源池中更昂贵的资源。成本开销定义为 𝑆1 和 𝑆2 的组合，即其中 𝑘 是按需资源价格与共享资源价格的比率。例如，当 𝑘 = 1.2 时，表示按需资源比共享资源贵 1.2 倍。因此，𝑆2 的额外成本开销应为 0.2 × 𝑆2。
共享资源池弹性算法：成本模型不仅评估资源成本，还指导如何最小化成本开销。例如，在上图中，𝑆1 和 𝑆2 随着共享资源池（用 𝑙 表示）的大小而变化。在公式 5 中，有一个最小化成本的最佳大小。具体算法如下：
5. 实验分析
使用AnalyticDB MySQL购买出来的多集群弹性实例，结合Job资源组投递进行性能评估。
5.1 查询RT
Flux对比被动式自动扩展：对于在多集群组上执行的短时间运行查询（下图a、b 和 c），与被动式自动扩展相比，Flux将 P99 查询RT降低了38%-75%。此外，平均查询RT降低了17%-54%。
Flux对比主动式自动扩展：与没有工作负载分离的主动式自动扩展相比，Flux将 P99 查询RT降低了30%-55%，将平均查询RT降低了11%-19%。
Flux将长时间运行查询的查询RT降低了约50%。
5.2 资源利用率
Flux相比于被动伸缩（黄线），闲置资源分配减少了48.5%，资源利用率提升了12.2%。相比于主动预测（绿线），闲置资源分配减少了约61.9%，资源利用率提升了19.0%。
5.3 资源成本
我们统计了阿里云某个区域内1700多个AnalyticDB实例的总资源分配情况。通过结合两个区域的成本模型计算，Flux相比基线可以节省约77.8%的成本开销。
6. AnalyticDB MySQL弹性能力的使用手册
论文相关功能使用手册参考点击前往