|
背景
如今，全球经济增长放缓、市场需求疲软，企业加强数字化建设提高运营效率是降低成本的有效手段，在这样的背景下云原生数仓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左右。
弹得准-贴合业务负载按需弹性技术
在线负载按需弹性技术
离在线负载解耦后，离线负载可以按Query进行极致的资源弹性，但在线的Query对RT要求比较高，更加适合通过实例节点弹性来满足负载的变化。ADB MySQL在线负载的按需弹性通过构建负载感知-> 库存供给-> 实例弹性的闭环反馈链路来做到自动弹性。
● 负载感知：包含用户设定定时弹性规则(已经产品化)、ADB Workload Manager自感知业务负载进行弹性(研发中)两种模式；
● 库存供给：负载感知模块生成具体资源扩缩的需求后，库存供给模块会提前或者实时的准备资源；
● 实例弹性：当资源准备好后，实例弹性模块进行实例的扩缩容，支持业务负载感知对资源的需求。
离线负载解耦按需弹性技术
在使用ADB MySQL的时候，混部负载场景既有在线分析，也会有ETL离线分析，“离在线负载不解耦”的架构下在线查询和离线分析的执行task会混用计算节点，这样会出现两个问题：
● 离线影响在线负载稳定性：当离线跑起来的时候，离线task的cpu等资源消耗较大，而在线的task对于节点的抖动比较敏感，出现在线业务抖动的问题；
● 成本高：为了保证离线Query运行的时候有足够的资源，就需要提前启动常驻资源，当离线Query运行完成后，这些资源会空跑，用户需要承担这些空跑的成本
为了解决这样的问题，ADB MySQL支持了离线Query级别的弹性资源供给。离线Query需要的资源和在线资源完全隔离，在线负载不受影响；离线Query的资源按需申请使用，用户不需要承担资源空跑的成本。
目前ADB MySQL具备了上面四块支持Serverless 弹性的基础技术能力，未来会在更智能、更快、更省钱等方面持续加强技术建设。
基于上面的技术，ADB MySQL的Serverless 弹性可以带来如下的效果： ● 计费：支持分钟级计费，批处理任务提供SQL作业级别计费信息； ● 成本：支持按量计费，使用成本比预留最高可降低80% ● 弹性能力：单计算任务支持0~10000个ACU范围秒级弹性扩展； AnalyticDB MySQL湖仓版已于11月1日正式开放公测，对于低成本离线处理ETL有需求，同时又需要使用高性能在线分析支撑BI报表/交互式查询/APP应用的用户，欢迎点击文末「阅读原文」进行公测申请。 引用
（文章来自阿里云数据，如有违权请联系删除！）
| 
私信
