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

本文涉及的产品
阿里云百炼推荐规格 ADB PostgreSQL,4核16GB 100GB 1个月
云原生数据仓库AnalyticDB MySQL版,基础版 8ACU 100GB 1个月
简介: 作者:李伟(花名:沐远), 云原生数据仓库AnalyticDB MySQL核心研发人员,专注于数据仓库的云原生及Serverless弹性。通过此文带你深入了解ADB MySQL湖仓版弹性技术解密!

【先打一波小广告】

阿里云AnalyticDB MySQL升级为湖仓一体架构,支持高吞吐离线处理和高性能在线分析,可无缝替换CDH/TDH/Databricks/Presto/Spark/Hive等。试用活动(5000ACU时+100GB存储)正在火热申请中,申请链接:https://free.aliyun.com/?searchKey=AnalyticDB%20MySQL,群号:33600023146


背景

如今,企业加强数字化建设提高运营效率是降低成本的有效手段,云原生数仓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的能力,构建多引擎的混部调度,同时管理包括存储、计算、网络基础设施;

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

image.png


3.Serverless弹性的技术解析

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

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

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

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

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

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

image.png


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

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

image.png


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

在线负载按需弹性技术

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

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

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

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


image.png


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

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

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

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

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

image.png


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

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

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

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

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

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

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


AnalyticDB MySQL湖仓版在2023年1月份已正式商用,支持低成本离线处理ETL,同时也支持高性能在线分析,并可替换自建CDH/TDH/Databricks/Spark/Hive/Presto等。

🔥目前ADB湖仓版免费试用正在火热进行中!欢迎积极申请试用

  https://free.aliyun.com/?searchKey=AnalyticDB%20MySQL

279


相关实践学习
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
相关文章
|
4天前
|
消息中间件 存储 Cloud Native
云消息队列 Kafka 版 V3 系列荣获信通院“云原生技术创新标杆案例”
2024 年 12 月 24 日,由中国信息通信研究院(以下简称“中国信通院”)主办的“2025 中国信通院深度观察报告会:算力互联网分论坛”,在北京隆重召开。本次论坛以“算力互联网 新质生产力”为主题,全面展示中国信通院在算力互联网产业领域的研究、实践与业界共识,与产业先行者共同探索算力互联网产业未来发展的方向。会议公布了“2024 年度云原生与应用现代化标杆案例”评选结果,“云消息队列 Kafka 版 V3 系列”荣获“云原生技术创新标杆案例”。
|
1月前
|
Kubernetes Cloud Native 微服务
探索云原生技术:容器化与微服务架构的融合之旅
本文将带领读者深入了解云原生技术的核心概念,特别是容器化和微服务架构如何相辅相成,共同构建现代软件系统。我们将通过实际代码示例,探讨如何在云平台上部署和管理微服务,以及如何使用容器编排工具来自动化这一过程。文章旨在为开发者和技术决策者提供实用的指导,帮助他们在云原生时代中更好地设计、部署和维护应用。
|
1月前
|
Cloud Native 持续交付 开发者
云原生技术在现代企业中的应用与实践####
本文深入探讨了云原生技术的核心概念及其在现代企业IT架构转型中的关键作用,通过具体案例分析展示了云原生如何促进企业的敏捷开发、高效运维及成本优化。不同于传统摘要仅概述内容,本部分旨在激发读者对云原生领域的兴趣,强调其在加速数字化转型过程中的不可或缺性,为后续详细论述奠定基础。 ####
|
12天前
|
运维 Cloud Native Serverless
Serverless Argo Workflows大规模计算工作流平台荣获信通院“云原生技术创新标杆案例”
2024年12月24日,阿里云Serverless Argo Workflows大规模计算工作流平台荣获由中国信息通信研究院颁发的「云原生技术创新案例」奖。
|
12天前
|
人工智能 Cloud Native 大数据
DataWorks深度技术解读:构建开放的云原生数据开发平台
Dateworks是一款阿里云推出的云原生数据处理产品,旨在解决数据治理和数仓管理中的挑战。它强调数据的准确性与一致性,确保商业决策的有效性。然而,严格的治理模式限制了开发者的灵活性,尤其是在面对多模态数据和AI应用时。为应对这些挑战,Dateworks进行了重大革新,包括云原生化、开放性增强及面向开发者的改进。通过Kubernetes作为资源底座,Dateworks实现了更灵活的任务调度和容器化支持,连接更多云产品,并提供开源Flowspec和Open API,提升用户体验。
|
26天前
|
Cloud Native
邀您参加云原生高可用技术沙龙丨云上高可用体系构建:从理论到实践
云原生高可用技术专场,邀您从理论到实践一起交流,探索云上高可用体系构建!
|
23天前
|
数据挖掘 OLAP BI
OLAP技术:数据分析的修仙秘籍初探
OLAP(联机分析处理)是一种多维数据分析技术,能够从不同角度洞察数据,揭示隐藏的趋势和模式。它最早由Edgar F. Codd在1993年提出,旨在弥补传统OLTP系统的不足,支持复杂的数据分析与决策支持。OLAP操作包括钻取、上卷、切片、切块和旋转等,帮助用户灵活地探索数据。广泛应用于财务报告、市场分析、库存管理和预测分析等领域,是现代商业智能的重要工具。
66 7
|
1月前
|
Cloud Native 持续交付 云计算
云原生技术的崛起与未来展望
本文探讨了云原生技术的核心概念、发展历程及其在现代IT架构中的关键作用。随着云计算的普及,云原生作为一种优化云应用构建和部署的方法,正逐渐成为企业数字化转型的重要推力。文章分析了容器化、微服务、持续集成/持续部署(CI/CD)等关键技术如何支撑起灵活、高效、可扩展的云原生架构,并讨论了面临的挑战与未来的发展趋势。
70 12
|
1月前
|
Cloud Native JavaScript Docker
云原生技术:构建现代应用的基石
在数字化转型的浪潮中,云原生技术如同一艘承载梦想的航船,引领企业驶向创新与效率的新海域。本文将深入探索云原生技术的核心价值,揭示其如何重塑软件开发、部署和运维模式,同时通过一个简易代码示例,展现云原生应用的构建过程,让读者领略到云原生技术的魅力所在。
|
1月前
|
运维 Cloud Native 持续交付
云原生技术深度探索:重塑现代IT架构的无形之力####
本文深入剖析了云原生技术的核心概念、关键技术组件及其对现代IT架构变革的深远影响。通过实例解析,揭示云原生如何促进企业实现敏捷开发、弹性伸缩与成本优化,为数字化转型提供强有力的技术支撑。不同于传统综述,本摘要直接聚焦于云原生技术的价值本质,旨在为读者构建一个宏观且具体的技术蓝图。 ####

热门文章

最新文章

相关产品

  • 云原生数据仓库AnalyticDB MySQL版
  • 云原生数据仓库 AnalyticDB PostgreSQL版
  • 推荐镜像

    更多