作者 | 百度 MEG 离线优化团队
导读
近些年挪动互联网的高速倒退驱动了数据爆发式的增长，各大公司之间都在通过竞争取得更大的增长空间，大数据计算的成果间接影响到公司的倒退，而这背地其实依赖宏大的算力及数据作为撑持，因而在满足业务迭代的前提下如何管制老本是公司十分重要的一环。
本文将介绍百度 MEG（挪动生态事业群组）在离线资源降本增效方面用到的一些技术以及获得的一些成绩。
全文 4478 字，预计浏览工夫 12 分钟。
01 业务背景
随着百度 App 的日活用户的持续增长，为了满足宽广用户对信息资讯更加精准的需要，MEG 的各个业务模块对于离线算力和存储的需要也一直减少通过其驱动下层模型取得更好的成果，因而离线老本也逐年减少，如何满足业务增长的状况下最小化机器资源老本是本文重点关注的问题。就拿百度 App 后端举荐服务（后简称 Feed）举例，领有离线大数据计算数百万核、分布式存储数百 PB，老本以亿为单位，而且还在持续增长，因而咱们心愿可能在满足举荐成果的前提下优化升高离线的老本。整体离线计算次要分为两大类，即数据挖掘类和数据分析类，其中开掘类场景次要是通过 python 脚本提交的 MapReduce 工作为主，剖析类场景次要是 Spark 及 SQL 类为主，底层集群资源都是 EMR，存储对立应用百度公司分布式文件存储 Appendonly File Storage（后简称 AFS）。
02 优化思路
上面介绍下咱们的优化思路，在此之前说下整个离线的业务背景，次要从三个方面阐明，第一是管理混乱，队列失控、工作失控；第二是老本高，千万核计算、EB 级的存储使用率低，同时增量的需要无奈满足；第三是效率，包含工作运行的效率和资源交付的效率，次要体现为队列拥挤，工作跑不动。
针对以上问题及痛点，首先针对管理混乱的问题咱们通过平台进行离线资源工作的全生命周期治理；其次是针对资源使用率低成本高的问题，咱们自研智能调度机制实现对不同使用率队列的削峰填谷，基于存算拆散技术实现疾速合池，通过潮汐算力分时调度优化白天缓和的算力供应增量业务，再就是与 INF 共建 RSS 技术并规模化落地优化混部资源的稳定性，还有就是针对 EB 级的存储进行动静扩缩容实现存储的优化和供应。整体的挑战是如何利用无限的资源满足有限的需要。
03 算力优化
3.1 合池技术
接下来介绍下算力优化的第一个优化点，合池技术，首先说下为什么要合池，因为碎片化的队列会导致弹性有余、使用率很难最大化，保护老本高。如下图所示，一个大概 5w 核的队列，它的峰值是达到下限了，然而均值很低，很难满足更大资源量然而执行较快的需要，因而一方面是冀望能把小的这种队列合并，另一方面晋升整体的使用率，如下图第二个队列，最终实现降本增效。
合池最大的挑战分两块，一是合池后如何保障工作的性能不进化，同时如何保障资源效率，二如何对业务无感通明合池。
接下来大抵粗略的说一下合池的过程，如下图所示：就是将等量资源的几个小队列进行合并，晋升队列的使用率下限，满足业务需要的同时退订一部分资源。
整体的技术计划次要包含两局部，一是智能调度，二是存算拆散技术，上面会离开介绍下这两项技术的实现。
3.1.1 智能调度
如下图所示，智能调度的整体架构如下，首先一个基于 python 的 client，负责将用户的程序、参数、环境依赖等等进行打包，而后通过智能调度零碎异步提交，零碎会依据工作维度多维的特色，比方优先级、并发、所需资源等信息联合资源实时的水位进行智能最优匹配，其中调度零碎比拟外围的也是首要的就是排序，即要解决先调度谁后调度谁的问题，如下图中的排序策略，首先是一个 FIFO 的队列模型，排序策略会依据工作的优先级、期待轮数进行加权，而后联合工作的并发系数进而计算出来先后顺序，优先级分位三挡，VERY-HIGH、HIGH、NORMAL，优先级越高权重越大，其次是期待的时长越长权重越大，越优先调度；有了程序后前面会依据工作要读取数据的地区就近匹配计算队列，缩小跨地区网络 IO 的开销，此外还有队列资源打满或异样等过滤策略，以及工作应用资源超限降级等策略，最初是针对排好序的工作进行队列调配，依据实时获取的队列资源水位联合工作提交所须要的资源量（并发数 * 单并发核数），调配好队列，工作会被 worker 正式提交到集群下面去。智能调度在整个合池过程中充当十分重要的角色，它能保障工作在合池后性能不进化，通过正当的编排，针对峰谷不一的资源进行打平调度，反复利用闲散资源晋升整体资源利用率。
3.1.2 存算拆散
方才介绍的是调度提交的过程，此外在合池过程中另外一项外围的技术是存算拆散，它是解决碎片化队列疾速合池的要害，外围的点是说咱们会提前在各个集群新建一个计算的 ugi，并且给这个 ugi 调配好计算所须要的长期存储并开明合池队列的计算权限，UGI 存算拆散后，原来用户的 UGI 只作为读写数据应用，代理计算的 UGI 提前开明各集群的权限，并调配好两头存储，调度零碎会主动调度到有资源的合池队列，用户不须要改代码，合池透明化。
总结下合池当前的成果，资源池化当前，千万核计算资源整体的使用率从 55% 晋升到 80%，增量供应和优化退订了数百万核资源，老本年化升高数千万。此外池化是得资源的交付效率大幅晋升，从之前周级、月级缩短到天级，工作的整体耗时通过正当的调度和编排也升高了 30%。
3.2 潮汐算力
接下来我介绍下算力优化的第二个优化点，潮汐，它的特点是体量大、数百万核、夜间特定时间段供应，成本低，收费用。能够用潮汐技术的场景包含策略模型调研类，数据回溯类等。如何把这部分资源充分利用好是我的项目的外围，次要通过如下三种形式实现潮汐的规模化利用，第一是显式的注册疏导，第二是对存量可在夜间运行工作的画像开掘，第三是对资源应用超限的分时管控，如下图所示：
△潮汐规模化利用的形式
潮汐的挑战有两个，第一是如何对存量工作画像、怎么尽可能保障在潮汐登场前执行完，如下图所示，接下来重点介绍下计划，就是通过隐式开掘存量工作转潮汐，因为潮汐资源是 0 点供应 5 点准时登场，因而咱们冀望对一些存量例行的工作进行画像让它可能通过潮汐时间段减速实现算力优化，开释更多白天的算力，这里画像次要包含执行周期、频次、并发数、task 总量等，利用这些信息给工作打一个潮汐的 tag，在这个工作下次提交的时候应用一个工夫减速模型判断其是否能在潮汐登场前执行完，该模型次要是通过例行工作惯例的运行工夫以及 map、reduce 的数量、并发量等计算出一轮计算缩须要的工夫，而后乘以晋升并发量当前要跑的轮数，算进去减速后的预期实现工夫，而后判断是否能在潮汐登场前执行完，这块分两种状况，0- 5 点，5-24 点，公式略有差别。
△潮汐工夫减速模型
上面介绍一下潮汐的第二个技术点，也即是后面提到的另一个挑战，如何保障潮汐工作刹时登场后不失败，第二天潮汐窗口降临后持续跑，解决方案是在现有的合池队列上进行扩大，在潮汐登场前提前升高并发，白天低速运行。
总结下潮汐在离线大规模利用的成果，首先是规模，目前潮汐的资源规模达到 300W 核，通过画像开掘存量转夜间实现了年化约 600 万老本的节俭。业务方面的话，有 100+ 回溯、调研类工作通过潮汐实现了资源的满足，减速了模型调研的效率，晋升了模型的成果。
△潮汐队列断点续跑
3.3 RSS 技术
接下来我介绍下算力优化的第三个优化点，RSS（Remote Shuffle Service）技术的规模化利用，大背景是离线标准型资源稳固，但老本高、稀缺，而混部资源成本低容易供应，但稳定性差、失败率高容易被抢占，如下图所示，失败率比拟高。
△混部资源 task 失败率高
如果 reduce2 运行中被抢占，须要从所有上游 map 从新拉取数据，而上游 map 曾经被另一个工作占用，也须要从新排队计算因而造成时长减少，因而 RSS 技术的外围是把 shuffle 数据存近程文件系统，这样 reduce 被抢占的话间接从 afs 拉取 map 产出，map 不须要重算，开启 RSS 的工作执行工夫根本与标准型资源性能持平。
04 贮存优化
4.1 背景介绍
存储资源估算逐年收紧，为应答接下来的业务增长，需要根本靠优化来满足。以后整个公司贮存空间的使用率大概为 60%，从使用率维度看任然有肯定的晋升空间。Google Research 于 2021 年发表了一篇名为 Autopilot 的论文《Autopilot: Workload Autoscaling at Google Scale》，核心思想是 Quota Auto Resize By workloads，即依据理论 quota 应用状况动态分配，可引入一些简略的模型预测 quota 的需要变动量，该思维是咱们实现 AFS Quota 超售的根本技术撑持，即按理论应用调配同时保障应用的时候能调配到，这样最大的益处就是存储是一个可被全局调度的大池，既能最大化进步存储流转回收的效率又能够晋升整体存储的使用率进而达到老本优化的目标还能节俭大量的运维老本，堪称一箭三雕。
回到咱们理论的业务场景，大部分状况下业务申请估算都是依照全年需要的总量申请 quota，理论交付后须要较长的工夫能力将资源的使用率晋升上来，这样就导致很大一部分 quota 的价值没有施展进去，闲置在那，其他人也不起来，因而咱们要实现 quota 的动态分配，实现资源全局最优。
4.2 Quota Resize
上面介绍下基于 quota resize 的优化模型，它会针对使用率低的存量账号进行动静的缩容，增量需要不再一次性调配，而是初始大量，依据理论应用状况逐渐调配。
△quota resize 简版计划
上面介绍下 resize 的整体流程，首先是收口增量需要，所有的需要申请通过平台流程核心进行，例如申请 1P 先初始化 300T，容量治理服务会依据实时的资源应用水位联合滑动窗口通过团体云的升降配接口进行动静扩缩，外围的技术点是分钟级感知资源水位，和 buffer 池的预留设计以及基于滑动窗口的阶梯缩容机制。
△afs quota resize 流程架构
总结下 resize 我的项目的成果，首先是 EB 级存储的使用率从 63% 晋升到 78%，老本升高数千万，同时使用率方面与业界持平，此外资源的交付效率也大幅晋升。
05 总结
本文次要介绍了百度 MEG 离线大数据计算和分布式文件存储的治理及优化思路，获得了阶段性的优化成果，业务笼罩方面目前笼罩了 MEG 超过 80% 的离线资源，优化使得每年计算成本升高约 4000 万，存储老本升高约 3000 万，降本的同时很好的撑持了增量一直的业务需要。离线资源的治理是个长期长久的工作，须要一直优化一直开掘新的形式，技术方面也须要不断创新，后续会继续更新分享优化教训。
——END——
举荐浏览：
百度 APP iOS 端包体积 50M 优化实际 (三) 资源优化
代码级品质技术之根本框架介绍
基于 openfaas 托管脚本的实际
百度工程师挪动开发避坑指南——Swift 语言篇
百度工程师挪动开发避坑指南——内存透露篇
增强型语言模型——走向通用智能的路线？