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

本文涉及的产品
函数计算FC,每月15万CU 3个月
Serverless 应用引擎免费试用套餐包,4320000 CU,有效期3个月
简介: 如今,全球经济增长放缓、市场需求疲软,企业加强数字化建设提高运营效率是降低成本的有效手段,在这样的背景下云原生数仓AnalyticDB MySQL湖仓版(以下简称ADB MySQL)可以做到弹性按需的使用。

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


背景


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


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

1.JPG


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的能力,构建多引擎的混部调度,同时管理包括存储、计算、网络基础设施;

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

2.JPG

3.Serverless弹性的技术解析


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

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

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

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

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

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

3.JPG

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

支持负载的弹性除了库存供给技术外,另外一个重要技术是弹性效率。如果启动一个离线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左右。

4.JPG

弹得准-贴合业务负载按需弹性技术

在线负载按需弹性技术

离在线负载解耦后,离线负载可以按Query进行极致的资源弹性,但在线的Query对RT要求比较高,更加适合通过实例节点弹性来满足负载的变化。ADB MySQL在线负载的按需弹性通过构建负载感知-> 库存供给-> 实例弹性的闭环反馈链路来做到自动弹性。

 负载感知:包含用户设定定时弹性规则(已经产品化)、ADB Workload Manager自感知业务负载进行弹性(研发中)两种模式;

 库存供给:负载感知模块生成具体资源扩缩的需求后,库存供给模块会提前或者实时的准备资源;

 实例弹性:当资源准备好后,实例弹性模块进行实例的扩缩容,支持业务负载感知对资源的需求。

5.JPG

离线负载解耦按需弹性技术

在使用ADB MySQL的时候,混部负载场景既有在线分析,也会有ETL离线分析,“离在线负载不解耦”的架构下在线查询和离线分析的执行task会混用计算节点,这样会出现两个问题:

 离线影响在线负载稳定性:当离线跑起来的时候,离线task的cpu等资源消耗较大,而在线的task对于节点的抖动比较敏感,出现在线业务抖动的问题;

 成本高:为了保证离线Query运行的时候有足够的资源,就需要提前启动常驻资源,当离线Query运行完成后,这些资源会空跑,用户需要承担这些空跑的成本。


为了解决这样的问题,ADB MySQL支持了离线Query级别的弹性资源供给。离线Query需要的资源和在线资源完全隔离,在线负载不受影响;离线Query的资源按需申请使用,用户不需要承担资源空跑的成本。

6.JPG

目前ADB MySQL具备了上面四块支持Serverless 弹性的基础技术能力,未来会在更智能、更快、更省钱等方面持续加强技术建设。


4.Serverless弹性效果及最佳实践


基于上面的技术,ADB MySQL的Serverless 弹性可以带来如下的效果:

 负载感知:支持按规则和按负载弹性伸缩;

 计费:支持分钟级计费,批处理任务提供SQL作业级别计费信息;

 成本:支持按量计费,使用成本比预留最高可降低80%

 弹性能力:单计算任务支持0~10000个ACU范围秒级弹性扩展;


AnalyticDB MySQL湖仓版已于11月1日正式开放公测,对于低成本离线处理ETL有需求,同时又需要使用高性能在线分析支撑BI报表/交互式查询/APP应用的用户,欢迎点击文末「阅读原文」进行公测申请


引用

[1] The Berkeley Paper:https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf


 / End /  

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
16天前
|
监控 关系型数据库 MySQL
MySQL自增ID耗尽应对策略:技术解决方案全解析
在数据库管理中,MySQL的自增ID(AUTO_INCREMENT)属性为表中的每一行提供了一个唯一的标识符。然而,当自增ID达到其最大值时,如何处理这一情况成为了数据库管理员和开发者必须面对的问题。本文将探讨MySQL自增ID耗尽的原因、影响以及有效的应对策略。
55 3
|
17天前
|
存储 关系型数据库 MySQL
MySQL 字段类型深度解析:VARCHAR(50) 与 VARCHAR(500) 的差异
在MySQL数据库中,`VARCHAR`类型是一种非常灵活的字符串存储类型,它允许存储可变长度的字符串。然而,`VARCHAR(50)`和`VARCHAR(500)`之间的差异不仅仅是长度的不同,它们在存储效率、性能和使用场景上也有所不同。本文将深入探讨这两种字段类型的区别及其对数据库设计的影响。
30 2
|
21天前
|
存储 关系型数据库 MySQL
PHP与MySQL动态网站开发深度解析####
本文作为技术性文章,深入探讨了PHP与MySQL结合在动态网站开发中的应用实践,从环境搭建到具体案例实现,旨在为开发者提供一套详尽的实战指南。不同于常规摘要仅概述内容,本文将以“手把手”的教学方式,引导读者逐步构建一个功能完备的动态网站,涵盖前端用户界面设计、后端逻辑处理及数据库高效管理等关键环节,确保读者能够全面掌握PHP与MySQL在动态网站开发中的精髓。 ####
|
1月前
|
监控 数据挖掘 OLAP
深入解析:AnalyticDB中的高级查询优化与性能调优
【10月更文挑战第22天】 AnalyticDB(ADB)是阿里云推出的一款实时OLAP数据库服务,它能够处理大规模的数据分析任务,提供亚秒级的查询响应时间。对于已经熟悉AnalyticDB基本操作的用户来说,如何通过查询优化和性能调优来提高数据处理效率,是进一步提升系统性能的关键。本文将从个人的角度出发,结合实际经验,深入探讨AnalyticDB中的高级查询优化与性能调优技巧。
71 4
|
27天前
|
存储 SQL 缓存
AnalyticDB 实时数仓架构解析
AnalyticDB 是阿里云自研的 OLAP 数据库,广泛应用于行为分析、数据报表、金融风控等应用场景,可支持 100 trillion 行记录、10PB 量级的数据规模,亚秒级完成交互式分析查询。本文是对 《 AnalyticDB: Real-time OLAP Database System at Alibaba Cloud 》的学习总结。
47 1
|
29天前
|
存储 关系型数据库 MySQL
MySQL MVCC深度解析:掌握并发控制的艺术
【10月更文挑战第23天】 在数据库领域,MVCC(Multi-Version Concurrency Control,多版本并发控制)是一种重要的并发控制机制,它允许多个事务并发执行而不产生冲突。MySQL作为广泛使用的数据库系统,其InnoDB存储引擎就采用了MVCC来处理事务。本文将深入探讨MySQL中的MVCC机制,帮助你在面试中自信应对相关问题。
91 3
|
29天前
|
缓存 关系型数据库 MySQL
MySQL执行计划深度解析:如何做出最优选择
【10月更文挑战第23天】 在数据库查询性能优化中,执行计划的选择至关重要。MySQL通过查询优化器来生成执行计划,但有时不同的执行计划会导致性能差异。理解如何选择合适的执行计划,以及为什么某些计划更优,对于数据库管理员和开发者来说是一项必备技能。
42 2
|
2月前
|
Java 关系型数据库 MySQL
【编程基础知识】Eclipse连接MySQL 8.0时的JDK版本和驱动问题全解析
本文详细解析了在使用Eclipse连接MySQL 8.0时常见的JDK版本不兼容、驱动类错误和时区设置问题,并提供了清晰的解决方案。通过正确配置JDK版本、选择合适的驱动类和设置时区,确保Java应用能够顺利连接MySQL 8.0。
181 1
|
2月前
|
架构师 关系型数据库 MySQL
MySQL最左前缀优化原则:深入解析与实战应用
【10月更文挑战第12天】在数据库架构设计与优化中,索引的使用是提升查询性能的关键手段之一。其中,MySQL的最左前缀优化原则(Leftmost Prefix Principle)是复合索引(Composite Index)应用中的核心策略。作为资深架构师,深入理解并掌握这一原则,对于平衡数据库性能与维护成本至关重要。本文将详细解读最左前缀优化原则的功能特点、业务场景、优缺点、底层原理,并通过Java示例展示其实现方式。
90 1
|
2月前
|
存储 SQL 分布式计算
湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
【10月更文挑战第7天】湖仓一体架构深度解析:构建企业级数据管理与分析的新基石
97 1

热门文章

最新文章

相关产品

  • 函数计算
  • 推荐镜像

    更多
    下一篇
    无影云桌面