自动弹性，QPS 线性提升｜一文读懂云原生数仓 AnalyticDB 弹性技术原理

前言

在全球经济增长放缓的大背景之下，企业在加强数字化建设的过程中，实现效益最大化成为一个绕不开的话题。阿里云瑶池旗下的云原生数仓 AnalyticDB MySQL 湖仓版（以下简称 AnalyticDB MySQL）在发布之初提供了定时弹性功能，帮助业务有规律的客户定时升降配计算资源以节省成本。时隔一年，AnalyticDB MySQL 针对用户痛点，再推出 Multi-Cluster 弹性资源模式，它具备贴合用户负载、自动配置、性能线性提升等优点，进一步帮用户节省成本，提高计算效率。

弹性模型介绍

弹性模型分为两种，分别是 Min-Max 弹性模型和 Multi-Cluster 弹性模型。

▶︎ Min-Max 弹性模型：

单个 SQL 可使用的资源量在 Min 和 Max 资源量之间进行扩缩，该模型适用于 ETL 场景，用于提升单个 SQL 的性能。例如，Min=16 cores，Max=32cores，单个 SQL 可使用的资源量在区间[16cores, 32cores]中。

▶︎ Multi-Cluster 弹性模型：

以 Cluster 粒度进行资源扩缩，单个 SQL 可使用的资源量为单个 Cluster，Cluster 之间资源隔离，该模型适用于在线分析和交互式分析场景，用于提升 SQL 的并发度。

例如，单个 Cluster 大小=16cores，最小 Cluster 和最大 Cluster 个数分别为 1 和 2，那么，每个 SQL 可使用的资源量为 16cores（单个 Cluster），随着 SQL 并发度的提高或降低，Cluster 个数可以在 1 和 2 之间自动进行调整，Cluster1 中运行的 SQL 不会影响 Cluster2 中的 SQL。

Multi-Cluster 弹性模式优势

AnalyticDB MySQL 在没有 Multi-Cluster 弹性模型之前，采用的是 Min-Max 弹性模型，通过定时弹性实现资源的弹起和释放，存在不少限制，具体表现在以下方面：

• 易用性：用户只能根据业务规律，在固定时间段将资源弹升，弹性计划生效间隔长（最短间隔 10 分钟）；

• 性能：小查询的性能容易受到大查询的干扰， 查询并发数不随资源组大小变化，查询可能排队；

• 成本：用户需要指定固定时间段的弹升规格，难以贴合实时的业务负载，短时间段的业务波谷无法缩容。

为了解决上述问题，应对查询的高并发实时分析场景，AnalyticDB MySQL 引入了 Multi-Cluster 弹性模型。Multi-Cluster 弹性模型作用在 AnalyticDB MySQL 在线资源组内部，一个在线资源组由一个或者多个 Cluster 组成，相比 Min-Max 弹性模型，在易用性、性能和成本上均有了较大提升。

易用性

自动根据当前实例的负载进行 Cluster 个数的扩缩，无需手动设置资源扩缩时间，更灵活地应对不同的业务流量。用户只需设置好 Cluster 个数的上限、下限及每个 Cluster 大小即可。

性能

Cluster 之间资源隔离，单个 SQL 只会影响其所在的 Cluster，不影响其余 Cluster 中 SQL 的运行，避免了单个大 SQL 对其它小 SQL 的干扰，进而影响资源组内查询的整体性能。根据实验结果，随着 Cluster 个数的增多，查询并发数呈线性增长趋势。与 Min-Max 弹性模型相比，Multi-Cluster 弹性模型下在同等计算资源下，查询并发度可提升高达 28%。

成本

贴合用户负载，动态选择最优 Cluster 个数，应对业务的波峰波谷。为了更直观地展示 Multi-Cluster 弹性模型和 Min-Max 弹性模型在成本上的收益，我们这里举个实际应用的案例：

• 0-7 点：某客户在晚上 0-7 点的时候，处于业务低峰期，用户采用定时弹性，将计算资源缩小至 48ACU；

• 7-24 点：客户业务处于间歇性高峰期，用户采用定时弹性将计算资源保持在 192ACU，以应对随时可能到来的波峰；

• 全天使用的总资源量为 3600ACU。

注：ACU（AnalyticDB Compute Unit）是 AnalyticDB MySQL 湖仓版资源分配的最小单位。一个 ACU 约等于 1 核 4GB。

应用 Multi-Cluster 弹性模型之后：

• 0-7 点：用户将 Cluster 大小缩小为 48ACU，保持和定时弹性的资源使用量一直；

• 7-24 点：用户将 Cluster 大小变为 96ACU，并设置最小 Cluster 个数为 1，最大 Cluster 为 2；

• 全天使用的总资源量为 2208ACU，相比定时弹性节省资源约 38.7%。

可以看到相对定时弹性，Multi-Cluster 弹性模型可以在业务两个高峰之间的波谷，为用户减少 Cluster 个数，节省成本，当用户的业务波峰到来后，Cluster 个数随之弹升，满足业务负载。

总的来说，相比 Min-Max 弹性模型，Multi-Cluster 弹性模型更适合高并发实时分析场景，体现在易用性、性能和成本等维度。下面我们将深入地了解 Multi-Cluster 的技术架构，以及如何实现“弹得准、弹得快、弹得好”的目标。

Multi-Cluster 技术架构

在设计 Multi-Cluster 技术架构的时候，我们的核心目标有三个：弹得准、弹得快、弹得好。下图是 AnalyticDB MySQL Multi-Cluster 的整体架构图，从上至下可分为三层:

• 接入层：负责将用户的查询投递到特定的资源组，再根据 Cluster 的负载情况分配到具体的 Cluster 上去执行；

• 执行层：资源组内部划分为相同大小的多个 Cluster，每个 query 只在其中一个 Cluster 上执行；

• 决策层：通过实时读取 AnalyticDB MySQL 资源的负载情况，进行 Multi-Cluster 资源组的扩缩容决策。

弹得快：实时数据链路

为了保障扩容的时效性，快速应对用户查询的到来，AnalyticDB MySQL 建立了 Region 级别的指标采集系统。AnalyticDB MySQL 实例也进行了改造，能实时地更新内部的业务指标（如 Query 排队数、CPU 使用等），并被指标采集进程采集到中心的存储端。目前整个数据链路的延迟在 10s 左右。

弹得准：稳定的扩缩容策略

AnalyticDB MySQL 实例是由接入层节点、计算节点、存储节点共同构成的复杂系统，在对计算资源进行扩缩容决策的时候面临如下挑战：

• 多组件交互的系统，如何识别外部组件瓶颈；

• 实例指标繁多，基于什么指标来进行扩缩容决策；

• 如何防止指标短时间的抖动，导致扩缩容策略不准；

• 如何判断扩缩容决策是否合理。

为此，我们将整个 Cluster 个数计算分为三个阶段：决策、执行、反馈。

决策

▶︎ 瓶颈识别

我们在决策系统中，将指标分为两类：

正向指标：反馈要扩容目标的负载情况，决定扩容目标的扩缩容。

负向指标：反馈除扩容目标外的其余组件的负载情况，用于判断外部瓶颈。

当负向指标达到设定的阈值时，我们认为计算节点扩容对于 AnalyticDB MySQL 实例整体而言已经无法起到加速查询，提升并发数的作用。对于这种情况，决策系统将会报警直至瓶颈解除。

▶︎ Cluster 个数预估

对 AnalyticDB MySQL 实例的负载分析后，我们发现对于扩缩容的决策并不能由单个指标决定，随着用户负载类型不同，决定扩缩容的指标也不一样。主要用到的指标有：用户 CPU 使用率，用户内存使用率，用户查询排队数等。

因此在扩缩容的预估的过程中，我们会先根据每个指标计算得出一个候选 Cluster 数，最后再选择所有指标中最大的 Cluster 数作为最终候选项。

• 对于和 Cluster 挂钩的指标（如 CPU 利用率）我们采用如下计算公式：

• 对于和资源组挂钩、但不和 Cluster 挂钩的指标（如查询排队数和并发数）我们采用如下公式计算：

• 最终我们取所有算出来的目标 Cluster 数的较大值：

▶︎ 稳定窗口

为避免因为实例负载抖动等因素造成的 metric 抖动，我们采用了稳定窗口的算法来避免抖动

在稳定窗口期间，每次预估的 Cluster 个数都会记录下来，并使用当前的 Cluster 个数和稳定窗口中推荐的个数进行对比。

a) 若窗口 Min ≤ 当前 Cluster 个数 ≤ 窗口 Max，则当前 Cluster 个数保持不变；

b) 若当前 Cluster 个数 < 窗口 Min，则说明应当将当前 Cluster 个数应当扩容至窗口 Min；

c) 若当前 Cluster 个数 > 窗口 Max，说明当前 Cluster 个数应当缩到稳定窗口 Max。

执行

资源组内部的 Cluster，在 AnalyticDB MySQL 内部对应的 K8s 的自定义资源(Custom Resource)，由自研的 Operator 进行管理，这些自定义资源实现了 K8s 的 Scale SubResource。当决策系统作出决策后，会通过 K8s 的 Scale API，将目标 Cluster 个数下发给自定义 Operator 进行扩缩容。

反馈：有效性评估

在执行完扩（缩）容后，决策系统会记录扩容之前的 metric 指标的值，并在扩（缩）容完成后持续观察用户负载的指标。

• 扩容评估: 决策系统持续观察扩容后用户查询的 qps 是否按照 Cluster 的比例增长了，或者用户查询的 rt 是否按照 Cluster 的比例降低了，如果没有明显增长，则认为扩容无效，决策将 Cluster 个数恢复成扩容前的个数，停止扩容决策运行，并预警。

• 缩容评估：决策系统持续观察缩容后用户查询的 qps 和 rt 是否均有明显变化，如果变化超过了一定的阈值，则将 Cluster 恢复成缩容前的个数，决策系统将 Cluster 个数恢复成缩容前的个数，停止缩容决策，并预警。

弹得好：负载均衡路由策略

在 Cluster 个数提升之后，用户无需指定查询路由到的 Cluster，AnalyticDB MySQL 自动根据负载均衡算法将查询路由到负载最小的 Cluster 中。

下图是一个根据 Cluster 负载均衡路由的示意图。

1. 当 Q5 到来时，由于 Cluster0 的负载是 2，Cluster1 的负载是 1，Cluster2 的负载是 1。Q5 会优先分配给 Cluster1 执行。

2. 当 Q6 到来时，由于 Cluster0 的负载是 2，Cluster1 的负载是 2，Q6 会分配给 Cluster2 执行。

总结及未来规划

为了更好地贴合业务负载，充分利用资源，实现效益最大化，我们推出了 AnalyticDB MySQL Multi-Cluster 弹性模型，完成了自动化、智能化扩缩容。AnalyticDB MySQL Multi-Cluster 形态有如下特点：

1. 成本：贴合业务负载自动扩缩容，相比单 Cluster 资源组固定资源，可以节省更多的成本；

2. 查询性能：线性增加，查询的隔离性相比 Min-Max 模型资源组要更优越；

3. 自动弹性：避免了用户手动调整资源组大小。

未来，我们还将在以下几个方面继续打磨和增强:

• 主动弹性：基于预测的主动弹性，查询延迟最小化；

• 负载解耦：基于 WorkLoadManager，大 query 自动投递到离线资源组减少对在线资源组的资源抢占；

• 弹性效率：资源 Pod 热池加速弹性效率；

• 效果展示：性能优化及成本节省可视化。