降本增效｜云原生数仓AnalyticDB MySQL的Serverless弹性技术解析

阿里云数据库 2022-11-19

288

作者信息
李伟（花名：沐远），云原生数据仓库AnalyticDB MySQL核心研发人员，10年数据仓库、数据湖、大数据、云原生研发经验，目前专注于数据仓库的云原生及Serverless弹性。

背景

如今，全球经济增长放缓、市场需求疲软，企业加强数字化建设提高运营效率是降低成本的有效手段，在这样的背景下云原生数仓AnalyticDB MySQL湖仓版（以下简称ADB MySQL）可以做到弹性按需的使用。

下面是湖仓版的产品大图，橙色部分是「湖仓版」相对于「数仓版」新增的功能，灰色部分是「湖仓版」相对于「数仓版」迭代升级的功能。

1.Serverless弹性的价值及挑战

Serverless的定义

Serverless相比serverful，有以下3个改变（来自 Berkeley 的总结 [1]）

● 资源的解耦：弱化了存储和计算之间的联系。服务的储存和计算被分开部署，存储不再是服务本身的一部分，而是演变成了独立的服务，这使得计算变得无状态化，更容易调度和扩缩容。

● 自动弹性伸缩：代码的执行不再需要手动分配资源。不需要为服务的运行指定需要的资源（比如使用几台机器、多大的带宽、多大的磁盘等），只需要提供一份代码，剩下的交由Serverless平台处理。

● 按使用量计费：Serverless按照服务的使用量（调用次数、时长、归一化资源等）计费，而不是像传统的serverful服务那样，按照使用的资源（ECS实例、VM的规格等）计费。

Serverless弹性的价值

你在使用云原生数仓服务的时候，是否遇到过下面问题并期望服务方能够帮忙你解决呢？

Case 1：业务的混合SQL负载包含短查询和离线ETL，当离线ETL运行的时候影响短查询的响应时间

Case 2：为了能够运行一个大的离线SQL，对实例进行了扩容，当离线SQL不运行的时候实例的资源浪费

Case 3：在线负载高峰期需要人肉去进行实例的扩容，手忙脚乱

Case 4：紧急情况扩容实例应对负载提高，遇到底层资源不足，扩容失败

Case 5：实例弹性效率低，启动时间相比业务资源使用时间难以忽略

......

这些问题以及更多和Serverless弹性相关的业务问题，ADB MySQL团队都在持续关注，并通过技术的产品化能力来帮助企业建设具有更好Serverless 弹性能力的数字基础设施。

Serverless弹性的挑战

通过Serverless弹性帮助用户解决上面的问题，在调度、成本、库存、弹性效率等服务上，对ADB MySQL也有相应的挑战。比如：

● 库存供给：对于大规模的弹性需求是否有足够的资源能够支撑

● 负载解耦：对于同实例的SQL怎么智能识别在线&离线的SQL并进行解耦

● 离线弹性：当负载解耦后，如何将常驻实例资源配额让离线计算按需使用

● 在线弹性：在线弹性如何智能的感知负载变化进行弹性

● 弹性效率：弹性效率怎么降低弹性本身的时间开销及成本

这些挑战ADB MySQL已经逐步解决，我们也期望将技术分享出来，让大家更好的使用ADB MySQL相关产品能力来满足业务需求。

2.Serverless弹性的架构

为了提供Serverless弹性的产品能力，在架构上需要有两方面的基础建设，包括细粒度的弹性单位定义、引擎&资源调度&资源库存端到端的池化调度架构。

ACU归一化的资源定义

引入了“1ACU约等于1Core 4GB”的归一化资源定义，来度量计算弹性资源的使用量。1ACU的资源单元较小，可以较好支撑ADB MySQL做到最细粒度的弹性，帮助用户将成本降低到极致。

端到端的池化调度架构

当要满足弹性的库存保障、弹性效率、细粒度资源弹性的需求，传统基于ECS来独占部署的架构难以支撑。ADB MySQL在构建弹性能力的湖仓版本中，资源调度基于ACK/K8s来构建，同时资源池使用两级库存(固定+弹性)。整体的架构可以分为三层：

● 引擎调度层：不同引擎的弹性资源编排，比如离线计算的按需弹性、在线计算的分时弹性资源申请等；

● 统一调度层：基于ACK/K8s的能力，构建多引擎的混部调度，同时管理包括存储、计算、网络基础设施；

● 弹性库存调度：用来管理固定资源池、弹性资源池的两级资源池，从而保障弹性过程中的资源供给，以及弹性效率的优化。

3.Serverless弹性的技术解析

从产品能力来看，ADB MySQL弹性技术建设包括弹得起(两级库存保障)、弹得快(弹性效率高)、弹得准(贴合业务不浪费)。

弹得起-池化弹性库存供给技术

不管是离线负载的Query弹性，还是在线实例级别节点的弹性，都需要有库存的保障。如果囤一批机器来满足弹性需求，当用户资源缩容的时候，会给ADB MySQL服务带来巨大的库存成本负担。为了既满足在离线的弹性资源供给，同时最小化ADB MySQL的成本，构建了基于画像运营的两级弹性库存供给能力。

● 资源需求：从用户查询负载转化过来的资源需求，包括定时弹性、自动弹性两种模式；

● 库存运营：库存包括固定池、弹性池两部分，其中固定池的库存供给周期在0.5天-15天，提供更好的弹性效率且库存可估计；弹性池的库存供给周期在7s-180s级别，成本较高且库存不可估计。库存运营模块通过不同资源的库存水位画像进行预测，从而来决策不同资源的购买释放数量；

● 库存供给：在接收到库存运营的资源需求后，库存供给模块会选择合适的神龙、ECS、ECI机型来满足资源需求，这里会考虑机型本身的库存、不同机型的组合、机型的性价比等因素。

弹得快-池化弹性效率优化技术

支持负载的弹性除了库存供给技术外，另外一个重要技术是弹性效率。如果启动一个离线Query的资源需要10分钟，这样的效率会影响用户体验，且会有较大的额外成本。在ADB MySQL的离线Query按需启动资源的模式下，可以做到1200ACU规模的Query，弹性时间仅在10s左右。达到这样的效率，ADB MySQL团队做了从Query执行模型、Pod的存储、Pod的网络等端到端的优化。

● Master Pod缓存池：一条Query执行需要一个Master Pod及若干个Executor Pod，Master Pod启动是前置的时间开销，多个Executor Pod是可以并发启动。为了降低启动Master Pod的开销，我们做了Master Pod的缓存池，从而将这部分的启动开销降低到100ms级别；

● Cache 盘缓存池：ADB MySQL的Executor Pod在执行过程中，会生成Spill、shuffle等数据存储到Pod的Cache盘中，如果Cache盘按需去挂载云盘链路上调用云盘服务开销较大。我们在固定池的节点上面构建了Cache盘的缓存池，Pod启动时候挂盘的开销降低到0.5s左右；

● 网卡缓存池：ADB MySQL的执行Pod的网络使用的是云原生的ENI方案，按需挂载会调用VPC服务开销较大，我们在固定池的节点上面构建了ENI的缓存池，网卡的挂载时间降低到0.5s左右。