爱奇艺大数据异构计算实践

　　在公司降本增效的目标下，压力传感器电路原理图爱奇艺大数据计算团队推进了离在线混部、弹性调度、资源治理等不同层面的优化措施，大幅降低计算成本。为了进一步降本，我们从 2024 年开始引入公有云 AMD、ARM 等高性价比计算机型，加快机型迭代、提升单机计算密度，进而实现单机性价比大幅提升。

　　在此之前，爱奇艺大数据计算几乎都在私有云物理机集群上，全部采用多年前的 Intel CPU 型号，存在硬件配置老旧等问题。近些年，AMD、ARM 在数据中心服务器领域表现优异，我们也关注到这一趋势，考虑引入提升计算性价比。

　　在机器选型阶段，我们综合评估了私有云、公有云的优缺点，以及考虑到爱奇艺大数据计算下一步的演进方向，决定使用公有云上的新机型：

　　私有云物理机须用满多年才能报废，而云上机器租赁时间灵活，可以贴合业务周期性的资源需求。

　　公有云引入新型硬件较快，可随时租、随时退，有助于我们加快机型迭代，不断提升单机性价比。

　　公有云提供丰富的计算机型，可选择适合大数据计算场景需求的机器配置，尤其是 CPU 核数和内存配比，我们从原先的 1 核 : 4~5 GB 提高到 1 核 : 8 GB，通过超分部署（即大数据计算层面 2 vcores = 操作系统层面 1 core）来拉高 CPU 利用率，进而提升单机性价比。

　　我们评估了多家公有云的数十款机型，包括 Intel Xeon、AMD Genoa、ARM 等不同 CPU 型号，本地盘、云盘等不同配置，虚拟机、裸金属等不同规格，最终选择了 AMD、ARM 两款裸金属机型。

　　由于 AMD 和 Intel 都采用 x86 架构，不需要特别的适配，而 ARM 的 CPU 架构和指令集与 x86 不同，需要适配改造，并支持异构计算调度，因此本文重点阐述我们引入 ARM 的过程与实践情况。

　　ARM 的上线经历了机器选型、大数据组件适配及业务代码兼容改造、大数据异构计算调度等几个环节，以下将分别展开介绍。

　　02# 公有云机器选型

　　由于公有云厂商有大量可供选择的机型，为了提高选型效率，我们制定了统一的准入标准对机型进行粗筛，并使用可复现的标准化性能测试用例来进行量化评估，通过后再进行生产负载性能量化评估，最终形成机型性能评估报告，再结合机器价格计算出机器的性价比，来决策机型的选择。

　　2.1 机型的准入门槛

　　我们统计了大数据集群当前的各项性能指标，整理出单机所需 CPU 核数、磁盘容量、单核所需内存/磁盘大小/磁盘带宽/网络带宽、单盘带宽、磁盘总带宽（云盘有总带宽限制，可能低于所有单盘带宽之和）等关键指标，用于设定机器准入门槛，adxl335 原理对候选机型进行粗筛，极大减少测试人力。

　　2.2 可复现的标准化性能测试用例

　　性能测试分为基础的 CPU 和磁盘测试，和典型的大数据 TPC-DS SQL 测试：

　　基础性能测试：使用计算密集型整数、浮点数运算，来评估 CPU 性能；通过 dd、fio 并行写入测试，来测试 IO 并发带宽；

　　典型 SQL 测试：选择 10 TB 规格 TPC-DS 的部分 SQL 耗时来评估性能，通过异构计算调度将测试任务定向调度到测试机器上。

　　在完成上述离线性能测试后，只有整体性能表现显著优于当前私有云在用机型的，才会进入下一轮的线上生产负载测试。

　　2.3 生产负载性能量化评估

　　线上生产负载更为多样，对稳定性和性能要求更高，并且在相同负载下对比机型性能，更具有说服力，但是如何对不同机型进行性能评估是一个长期存在的问题。在私有云环境中，机型较为单一，此问题不明显，但在大规模使用公有云异构机型时，长期的性能追踪和评估，更有利于对需求、性能和成本进行把控，及时发现并处理性能缓慢恶化的情况。

　　为此，我们构建了统一的可观测性系统：

　　给不同机型打上不同的标签，例如节点 A 的标签：vendor=xxx_cloud，cpuarch=aarch64 (ARM CPU 架构，有别于 x86_64) 等

　　采集线上单日 Spark SQL 的全部任务，按照计算节点维度聚合统计每核每秒的平均处理数据量 ( total input bytes / total (vcore * seconds) )

　　根据计算节点维度聚合的数据，以及节点上的标签进行再次实时聚合，绘制不同的维度的机型性能数据。如下：　

图 1 不同机型的性能观测

　　同时基于单个计算节点维度的性能统计，我们可以快速发现同批次机型下的快慢节点，进行异常分析　

图 2 慢节点分析

　　线上负载测试：

　　将公有云测试机型超分部署后加入到线上生产集群（位于私有云）中，运行一周，观察负载情况

　　公有云测试机器与私有云生产集群中的其他节点之间的通信通过混合云专线网络，延时较低，对测试结果的影响可忽略不计（延时对性能测试结果的影响程度，最终会体现在机器性价比上，在我们的环境中，这部分占比微乎其微）

　　通过可观测性系统，计算得出测试机型对比基准机型的性能指数，即从性能方面考虑，一台测试机型可以兑换几台基准机型

　　根据测试机型的性能指数、价格指数来计算机器的性价比，从中选取最具性价比的机型。

　　基于上述测试流程，我们完成了国内主流公有云厂商数十款计算机型的评估，选择了 AMD、ARM 等机型，并对 ARM 进行了适配改造。

　　03# ARM 的兼容适配

　　ARM 架构和指令集不同于 x86，大数据组件、业务代码均需改造，无法进行完全无感升级。

　　3.1 大数据组件适配

　　大数据兼容适配 aarch64 架构的主要改造项：

　　Hadoop 3.2.2：在 ARM 节点上编译 RPM，确保 HDFS native 库的兼容性，并且将 leveldbjni 等依赖升级到支持 ARM 的内部版本

　　Flink Connector：存在大量适配需求，共计改造适配 20+ connectors

　　Spark 3.5.0、Iceberg、Paimon 等组件适配良好，不需要太多改造

　　3.2 业务代码兼容性检测和改造

　　业务任务分为三类：Jar、SQL、DAG 配置型。其中 SQL 和 DAG 配置型任务只需大数据平台进行适配，无需业务对每个任务逐一改造适配。而 Jar 任务可能包含不支持 ARM 的依赖（如低版本 Netty）或 Native 库（如自研 C++ 算法库），需要进行升级或改造。

　　我们通过工具扫描线上 Jar 任务，发现不兼容率达到 10%。针对检测结果，逐一进行归类、附上升级建议，如果不兼容的依赖的开源版本无法支持 aarch64，则由我们维护内部版本。升级文档覆盖了 Netty、Couchbase client、HBase client、Jansi 等常见大数据依赖的版本升级建议。

　　同时，我们在大数据开发平台上增加了对增量 Jar 任务的准入检测与拦截，提醒开发者按照提示信息进行适配。

　　04# 异构计算调度

　　由于业务 Jar 任务的改造需要较长的周期，在上线初期，我们需要将已完成改造的任务（包括 SQL 任务）允许调度到 ARM 节点上，而未完成改造的任务只能运行在 x86 节点上。　　

图 3 统一调度将导致未适配任务失败

　　我们引入 YARN 节点属性 （YARN Node Attribute）调度功能，对不同节点加上不同的属性标签，并利用计算任务调度放置约束的设定 (YARN Placement Constraint)，来实现指哪打哪的定向调度功能。　　

图 4 基于节点属性的异构计算调度

　　4.1 基于 YARN 节点属性调度

　　计算节点属性设置

　　为了给异构调度提供基础，我们对不同机型的计算机器设置了如下的属性标签：

　　计算资源生命周期：lifecycle=[reserved/on-demand]，区分是固定节点，还是临时节点（如离在线混部弹性资源）

　　CPU架构：cpuarch=[x86_64/aarch64]，其中 aarch64 即为 ARM

　　CPU型号：cpumodel=[Intel-xxx/AMD-xxx/...]，主要用于性能观测

　　CPU性能：cpuperf=[high/medium/low]，根据单核计算性能划分为高、中、低三档

　　磁盘类型：disktype=[ssd/hdd]

　　计算框架适配

　　YARN Node Attribute 特性需要结合计算任务设定 task 放置约束 (YARN Placement Constraint) 来实现，但是各个计算引擎均未支持此功能，因此我们对 Flink、Spark、MapReduce 等计算引擎进行了改造适配（尚未贡献给开源社区）。

　　由于 YARN Node Attribute 的特性较新，社区的使用者较少，我们做了大量的生产试错和代码改造，也向 YARN、Spark、Paimon 等开源社区贡献了十几个通用性的改进和修复。

　　4.2 任务无感迁移策略

　　ARM 计算机型加入到线上集群后，需要逐步灰度调度任务到这些节点。为了保障任务稳定性，我们对不同任务进行了精细化无感调度：

　　未适配 ARM 的 Jar 任务，统一在 YARN ResourceManager 侧通过黑名单避免调度到 ARM 计算节点上执行。对于这些任务，自动配置添加 constraint 为 nm.yarn.io/cpuarch=x86_64

　　对于已适配的任务，则默认放通，可使用全部的计算节点

　　同时，我们实现任务灰度的白名单机制，通过动态变更配置文件，对任务按照 Hadoop 用户来进行无感的灰度。

　　4.3 自定义均衡调度策略

　　在 ARM 计算节点上线后，我们发现因为 YARN CapacityScheduler 任务调度默认采用 Round-Robin 分配策略，依次轮询每个节点进行调度，导致 CPU 核数较少的大量低性能节点首先被用满，而 ARM 和 AMD 大容量机型 CPU 核数多、分配率低，未被充分利用。

　　如下图所示，Round-Robin 模式类似大水漫灌，处于 level 1、level 2 范围内的节点会依次先被打满。　　

图 5 Round-Robin 资源分配

　　因此，我们基于Yarn multi node placement 实现了自定义的均衡调度策略（默认的 ResourceUsageMultiNodeLookupPolicy 策略无法满足我们的调度需求）：

　　在后台对单机 vcore 使用率按照从小到大进行排序，提升大容量节点的优先分配权

　　在低性能节点 vcore 使用率达到较高水位，在资源充足情况下，则降低调度权重，保证性能

　　在优化后，在资源利用高峰时，高性能节点将会优先被利用，而低性能节点则会处于较低的资源分配水位线上。　　

图 6 自定义均衡调度策略

　　05# 异构计算落地情况

　　因为 ARM 架构特点，在超分的环境下，CPU 利用率稳定安全水位可以达到 90%，相较于 x86（一般在 70% 以下）大幅提升计算密度，同时 Spark 和 Flink 作业速度提升 30% 以上，单机性价比大幅提升。

　　目前，爱奇艺大数据已上线数万核 ARM 机器，平稳运行半年以上。

　　06# 未来计划

　　通过上述标准化的公有云机器选型流程及异构计算调度系统，我们可以比较快速地评估、引入新机型，在公有云上验证可行后，可以进一步引入私有云，持续迭代机型，不断提升单机性价比。

　　未来我们会逐步扩大 ARM、AMD 等高性价比计算资源的比例，逐步替换掉私有云内报废的机器，构建混合云分级计算资源池：

　　固定计算（X%)：保留 X% 在私有云机房内，逐步将部分旧机器替换成 AMD 等新机器；

　　实时弹性计算（Y%）：Y% 计算资源通过 YARN + K8S 离在线混部体系以 K8S 容器方式提供，与在线业务共用私有云或公有云上的宿主机，根据大数据资源需求及在线业务空闲资源情况实时弹性调度，削峰填谷；

　　长周期弹性计算（Z%）：Z% 私有云机器待过保后替换成公有云 AMD 或 ARM 机器，实现更长周期的按需弹性，比如应对寒暑假高峰，在业务需求减少后，可以当月就腾退掉，及时降本；

　　X + Y + Z = 100%，将根据业务需求、公私有云成本、技术等因素动态调整。

　　另外，由于引入了多家公有云的计算机型，在混合多云统一调度框架下，存在大量的跨云数据读写，给混合云网络专线带宽带来挑战，为避免影响到线上业务，我们正在开发混合云流量精细化调度，让任务的读写尽可能在同一家云内实现闭环，同时改进混合云缓存系统，减少跨云数据传输。