为了更好地方便各位开发者和用户了解并应用ECS倚天实例，由阿里云弹性计算联合基础软件团队 & 平头哥 & 安谋科技（arm），共同发起了【倚天实例迁移课程】，本系列课程共计10节课程，共分为基础篇、架构迁移篇和性能优化篇三大篇章，从不同角度为用户带来更加丰富和专业的讲解。
2023年9月14日，系列课程第八节《基于ECS倚天实例的大数据加速最佳实践》正式播出，阿里云弹性计算大数据优化负责人李腾飞主讲，内容涵盖倚天大数据场景迁移适配、倚天大数据性能加速实践和倚天大数据场景落地实践。
本期节目在阿里云官网、阿里云钉钉视频号、InfoQ官网、阿里云开发者微信视频号、阿里云创新中心直播平台&微信视频号同步播出，同时可以点击【https://developer.aliyun.com/topic/ecs-yitian】进入【倚天实例迁移课程官网】了解更多内容。
以下内容根据李腾飞演讲内容整理而成，供阅览：
一、基于ECS倚天实例的大数据场景迁移适配
首先，来看一下在大数据场景，如何使用ECS倚天实例。从上图中，可以看到在大数据存算分离的场景中，我们一般会使用远端HDFS集群或者OSS对象存储作为存储集群，通过专线或者VPC网络来连接计算集群。在计算集群中，我们可以使用ECS倚天实例作为计算节点，在上面运行大数据的一些组件，比如Spark、Hive、Flink、Presto、Kafka等等，这样我们可以获得很好的性能和性价比。
下面我们具体分析一下ECS倚天实例的优势。
第一，ECS实例是基于倚天CPU的，倚天CPU是ARM架构的，相比X86平台它提供的是物理核，没有HT，能够提供比较强的算力。特别是在CPU负载比较高的情况下，依然能够保持性能的稳定和线性增长，这对于大数据场景来说，不管是离线还是在线业务，它能够保持CPU利用率非常高，这是一个很好的优势。后面我们在分享Spark、Flink的性能的时候也会讲到，同时相比X86平台，倚天有20%以上的大幅度性能提升。
第二，ECS倚天实例基于DDR5的高性能内存，在实际使用过程中，能够提供比较高的内存带宽和比较低的内存时延。也可以根据业务不同的需要来使用不同规格的ECS实例，来匹配内存容量的需求。对于大数据基于内存计算的框架，比如Spark、Presto、Flink可以发挥出很好的性能优势。
第三，ECS倚天实例相比X86平台的g7实例，L1/L2/L3的cache大一些，这样可以在大数据计算的场景中提升性能。
第四，ECS倚天实例搭载阿里云最新的CIPU计算架构，能够提供超低延时的eRDMA网络和高性能ESSD云盘，对于大数据业务网络和磁盘IO压力较大的场景，比如数据的shuffle和HDFS文件的读写，都可以提供稳定、高性能的保障。
第五，在成本方面，ECS倚天实例相比同等算力的X86实例，有接近30%的成本优势。
从上面的分析，我们可以看出，ECS倚天实例在大数据场景确实有很好的性能和性价比优势，可以帮助客户实现大数据场景降本增效的目标。
接下来看一下，我们怎样才能把我们的大数据业务在倚天实例上跑起来？其实随着ARM生态的不断发展，到今天为止，大部分主流的大数据平台的组件都可以在ECS倚天实例上做到比较好的适配，并且能够做到比较平滑的从X86平台到ARM平台的迁移。
我们基于内外部的实践经验，给大家介绍一下大数据在ARM的迁移适配实践。从图一可以看到，是一个比较典型的基于ECS倚天实例底座的大数据平台。在OS层面可以使用CentOS，也可以使用阿里云自研的Alinux的ARM版本来获得更高性能、性价比、稳定性的收益。在Java运行时层面，也可以使用Open JDK，或者阿里自研的Dragonwell引擎来获得更好的性能和稳定性的收益。在平台层面，我们基于主流有的Hadoop、Spark、Hive、Flink版本构建分布式离线及实时计算、存储、调度引擎。
在这样的大数据软件平台架构下，对于基础的软件和大数据的业务软件都会有一些基础的依赖。举个例子，基础软件使用CentOS 7.9版本，Python 3.6.8，JDK 1.8，还有GCC和JDC的一些版本。
在大数据业务的软件里，比如Hadoop3.3社区版本已经官方支持了ARM，所以我们直接在社区下载ARM版本就可以直接使用。还有一些比较低的版本，我们需要重新编译代码，或者将不兼容的Jar包进行替换。这里主要是因为Spark、FLink版本里的Jar包，包含一些Native的so包，这些里面可能有不兼容倚天ARM的代码。
如果我们在实际迁移的过程中，不清楚自己的软件版本以及Jar包是否兼容倚天ARM，阿里云在实践的过程中，也积累了一些代码扫描、分析的工具。PTG团队有一个叫做Yoda的工具，可以帮助客户分析组件的代码中有哪些是不兼容ARM的包和代码。我们可以对它进行扫描，并给出分析和建议。
通过分析建议以后从具体的实践来看，需要替换Jar包的是有Native的so包的，比如LevelDB、Netty、RocksDB的一些包。这里面有一些是可以通过升级版本来替换，有一些需要针对源码做重新的编译构建。
如果我们在实际的迁移过程中，大数据组件的版本可以做升级或者替换，我们也有一些推荐使用的组件版本。比如Hadoop推荐3.3以上，Spark推荐3.2以上，Hive推荐3.1以上，Flink推荐1.13以上，JDK推荐openjdk11或者dragonwell11，这样能带来更好的性能收益。OS层面我们推荐使用阿里云的Alinux3，这样能将已经做好ARM适配的版本和工作在迁移的过程中省略掉，让大数据在ARM迁移的过程中更加平滑。
二、神龙大数据应用加速套件的介绍
首先，介绍一下神龙大数据应用性能加速套件，它是我们专门为基于ECS倚天实例的大数据场景打造的。为了让使用ECS倚天实例的客户在大数据场景下能够快速地获得更高的性能和性价比体验，我们基于ECS Booster+CADT 打造了一个开箱即用的最佳实践，目前我们支持Spark、Flink、ElasticSearch、Kafka。
目前，神龙大数据应用加速套件主要包括三个主体部分。
第一，FASTMR，大数据集群部署及性能测试套件，它主要在大数据场景评测ECS倚天实例的性能。在大数据集群部署中，我们支持存算分离的、容器化的、存算一体的架构的一键化部署。
在性能的Benchmark套件中支持TPCDS这种决策支持类SQL分析的Benchmark，它也是大数据目前评测的比较主流的Benchmark；支持TPCx-HS这种针对整体大数据组件的IO和系统性能的评测；支持Hadoop pi这种针对计算性能的评测；支持TPCx-BB这种针对SQL分析和机器学习相关的性能评测；支持Nexmark这种针对Flink吞吐能力的评测等等。让我们比较方便的通过FASTMR在倚天上进行大数据集群的各种Benchmark的性能评测。
第二，APAK，大数据性能监控分析套件，它主要为了方便进行后面的性能调优，在大数据业务运行中，不管是在倚天ECS的VM层面，还有大数据应用的层面，都需要进行指标的监控和分析。
在VM层面，我们主要针对CPU的一些指标，比如CPU的利用率，包括sys、user、iowait等指标；CPU上下文切换；内存的指标，包括内存的使用率、内存带宽；磁盘的指标，包括带宽、IOPS、时延；网络的指标，包括带宽、PPS、时延的指标。还有我们比较个性化的针对eRDMA的带宽的监测。
针对大数据应用层面，为了能够看到大数据业务运行中的性能表现，我们支持包括火焰图热点分析，看一下在运行过程中的热点函数；在E2E性能评测中，计算、存储、网络在整个过程中的时间占比；IO Pattern分布，看任务运行过程中IO的模型；还有系统瓶颈点、硬件瓶颈点的自动化分析，内存性能的监控分析。
第三，MRACC，大数据性能加速套件，它主要为了加速常用的大数据组件。我们针对Spark、Presto、Hive、Alluxio、Flink等组件做了一些插件化的引擎；针对Spark做了向量化加速的引擎；针对Spark、Presto、Hive做了近存储加速的引擎，去降低网络带宽的影响；针对Spark的Shuffle做了eRDMA的加速；针对Alluxio做了OSS读写的加速。这些引擎都是以客户无感的插件化的形式提供出来的，在很多场景里也都拿到了很好的性能收益。
最下面的是ECS的神龙架构，它基于CIPU、CPU、内存、网络、存储提供基础能力，整个性能加速套件也是在底座的基础上做的性能优化。
有了大数据性能加速套件以后，我们就能对具体的大数据场景和问题针对性地设计优化方案，来解决我们的性能问题了。
在应用层，我们可以通过Spark层面的应用优化，包括Spark的 Native引擎，是我们针对Spark SQL模块做的算法优化和向量化优化，我们在实测过程中也能提升接近2倍以上的性能。比如在压缩层面可以做一些zstd的压缩优化，降低临时数据的存储容量，从而降低大数据场景下使用倚天实例过程中的云盘大小，提升性价比。
如果碰到专线的瓶颈或者OSS带宽瓶颈，我们可以引入近存储加速来解决问题。如果系统的资源利用率未完全利用，我们可以通过应用层的优化，比如参数的配置，资源超发策略的优化来提升ECS倚天实例整体的计算效率和资源的使用效率，充分利用ECS倚天实例CPU和内存的资源提升性能。
在系统层面，我们也做了很多优化，比如内核补丁、内核参数，内存预取、JDK层面的优化。比如在过程中碰到CPU sys占比比较高的情况，我们可以在系统层和基础硬件层做一些优化，比如应用ARM的一个E0PD补丁，这样可以在做好安全防护的同时，降低系统调用的开销，将客户实测的性能提升5%。
在中断比较高的场景，我们可以针对性做IO的优化，包括软中断的优化，线程切换的优化，rps、xps 网络IO的优化，在实测中我们可以提升Spark的性能。还有一些内存预取，包括文件缓存相关的优化也都能够带来不错的性能提升。
从JVM的角度，目前广泛使用的1.8版本，针对ARM的支持不是很完善，这会导致我们在倚天上的性能退化。因此Dragonwell也针对倚天做了一些稳定性的优化，包括openjdk以及一些新的版本，在ARM上的适配也会更好，这也是我们推荐使用的。
因为倚天CPU的ARM架构和X86指令级的架构差异还是比较大的，所以在系统OS、JVM层面、编译层面，能够做的优化也还是比较多的，在大数据场景带来的收益也不少。
在基础硬件层，ECS倚天实例也在不停的演进中，包括从CPU的主频、内存的频率等都有提升的动作，这对于整个大数据场景也是非常有用的。如果碰到一些IO带宽的瓶颈，我们可以使用基于倚天的带宽增强型的实例，这样也能对我们的性能有一些提升。
从我们结合内外部客户实践的结果可以看到，大部分应用在经过我们的优化方案的组合以后、性能都能提升30%以上。
我们针对数据库存算分离的场景，做过一次性价比的评估模型。在模型的评测过程中，针对TPC-DS3T的性能和性价比做了测试，ECS倚天实例g8y在所有评测性能的实例中性价比是最高的。在无缓存的场景里，它相对于baseline性能提升了87%；在有缓存的场景里，性能提升了99%。
接下来我们在具体的场景中，看一看刚刚我们讲到的加速套件和优化手段的应用的情况。
在Spark场景，我们在TPCDS 3T的1+6的环境下测试了基础性能，我们在基础性能上，ECS倚天实例基本上和g7实例是持平的。在测试过程中，我们发现计算密集型的SQL，CPU的利用率到达了80%以上，我们认为可以充分发挥倚天ARM架构的多硬核的优势。我们通过OS层面缓存策略的调优、网卡的调优、预取策略的调优，提升了10%以上的性能优势。
但我们也没有完全把刚刚讲到的所有优化手段都叠加在测试中，如果我们再叠加其他的优化手段，我们的性能还会有更高的性能表现。我们在客户的实践中应用了其他的优化手段，我们倚天CPU相比原cpu架构在核心数减少一半的情况下，从落后25%提升到了30%~40%。
在这里我们使用了框架参数的优化，实例、云盘选型的优化，内存带宽的优化，OS的优化，JDK版本的优化，加速库的优化等等优化手段。可以看到，我们用的优化手段越多，ECS倚天实例在Spark场景中的性能表现就会越好。
在Flink场景nexmark的测试中，我们使用了6个节点的集群。在这个场景的测试中，Flink场景在基础性能里，相对g7已经有17%的性能提升了。通过网卡的IO策略的调优和预取策略的调优以后，相对g7就达到22%的性能提升了，且有一部分SQL达到了50%以上的性能提升。
在这个过程中，我们发现计算越密集的场景，性能就越好。在测试过程中，整个CPU的利用率能够达到80%以上。这里我们也和Spark一样，没有把所有的优化手段都用上。我们在其他的客户实践中，在核心数少一半的情况下，从落后20%提升到了66%。我们在这里使用了OS层面的优化，内核层面的优化，资源配比的优化手段。
Hive的场景优化也是一样，我们在hive on TPC-DS的测试中，我们发现g8y倚天实例相比于g7经有21%的性能提升。我们通过一些网卡的优化手段，大部分场景CPU利用率达到80%以上，基本和第八代g8i的性能持平。
通过刚刚讲的几个场景可以看到，在Spark、Hive的场景里，CPU利用率都是非常高的，在80%以上。在这样的场景中，倚天有非常大的优势。我们通过一些简单的OS底层的、应用层完全无感的优化方法，就可以拿到相对于X86平台的很明显的性能收益。
当然，为了更好的发挥倚天的性能优势，我们在大数据场景也针对应用层做了很多的性能优化。比如在Spark SQL场景，向量化加速也是非常流行的技术，databricks也在做服务层的向量化加速。
我们针对Spark SQL场景基于ECS的NEON和SVE/SVE2的指令集适配了Velox的向量化引擎。我们针对Spark SQL引擎做了向量化的改造，在整个向量化的SQL引擎的测试中，我们在TPCDS的1TB测试集中，相对于原始的Spark提升了1.7倍，在3TB的测试中提升的1.9倍。
对于愿意尝试用Native引擎的客户来说，我们只需要把Native引擎在倚天ARM的架构上做一次编译，然后在配置文件里修改几行代码，就可以把整个引擎使能起来了，对于业务程序其实是可以做到零改造的。
还有一种是前面提到的近存储加速的方案，在解决存算分离的架构中，我们一般会使用OSS或者远程的HDFS来存储数据，但计算集群和存储集群之间就会存在大量的数据交互和搬移。随着集群规模的扩大，两者之间的网络带宽就会逐渐成为瓶颈点。而且我们已经在一些客户的真实场景中碰到了这种问题。
而我们开发的近存储计算就是针对这个问题做的解决方案。它的原理是基于数据就近计算的理念，把计算搬到存储集群一部分，利用存储和缓存节点富余的算力提前完成过滤和聚合的计算。这样我们可以大幅度的减少数据的搬移，从而降低计算集群和存储集群之间的网络带宽的使用，实现整体的效率提升。
在这个架构图上大家可以看到，我们已经支持Spark、Presto、Hive的客户端，可以通过插件化的形式提供给客户来使用。我们把Spark、Presto、Hive的算子卸载到近存储服务端上。
在近存储服务端这里，我们也做了一些向量化的加速，和刚刚讲到的Spark向量化加速引擎里用到的Velox进行了整合，充分发挥ARM的simd指令集的优势进行高效的数据过滤和聚合的操作。在这样的架构中，我们在tpch 1T的测试中，在点查场景中，性能提升了2.16倍，在模糊查询的场景中，提升了2.1倍，在Q6的E2E测试中，提升了2.5倍。在网络带宽减少的数据上，我们在点查场景降低了99%。
近存储要使用起来也非常简单。首先需要在存储或者缓存节点上部署我们的存储服务。客户端只需要把插件通过配置文件的方式，配置到Spark、Presto、Hive的计算引擎里去，客户的SQL和客户的业务代码是不需要改造的。
然后我们再看一下的eRDMA网络加速。前面我们提到ECS倚天实例搭载的是阿里云最新的CIPU计算架构，所以它能够提供eRDMA的能力。我们在Spark Shuffle的场景中，做了适配和优化，增加了eRDMA Shuffle的Manager，并适配了Spark Shuffle和Yarn的ECS服务。
通信层我们通过Jverbs和UCX方案去适配兼容eRDMA的能力。将Shuffle整个过程中的网络从TCP替换为eRDMA。在这里测试的TPCx-HS的source的Benchmark中，我们调整了一下RDMA的memory region。在不同的情况下，在reduce阶段获取远端数据的过程中，提升了19%。在E2E的测试中，提升了13%。
三、倚天大数据场景落地实践
根据我们在大数据场景的客户迁移实践经验，总结了一下比较典型的大数据迁移的流程，大概包含五个步骤：
首先启动POC，我们需要进行迁移适配的工作，包括对技术软件和应用软件兼容的扫描。对于不兼容的代码，我们需要重新编译或者Jar包的升级。在这个过程中，我们可以去设计测试的实例、测试的用例和测试方案。在这个基础上我们完成整个POC测试环境的构建，这里可以使用前面性能加速套件里面提到的FASTMR一键构建，并开始性能优化和加速导入，来得到最佳的性能。
这里我们可以将性能加速套件里提到的APAK监控和分析的工具进行部署，找到系统的瓶颈点，针对性的做一些优化方案。在POC结束以后，我们可以选取客户的一些真实的线上业务进行测试，针对业务自有的特点进行验证。也可以在这个过程中针对性的做一些优化，比如基础硬件的优化、OS的优化、应用层的优化等角度验证一下优化方案的有效性。
在业务运行的稳定性验证以后，我们就可以开始真正的进行线上集群的构建和线上业务的灰度测试了。在持续上量的过程中，我们还可以不断地调整我们的优化方案，包括我们比较有特色的JDK、OS、Spark等等组件的引入和大数据业务的兼容适配。
在这个迁移的过程中，有一块业务的代码迁移是刚刚上面没有提到的，UDF的迁移适配。这里补充一下，我们以阿里云ODPS的迁移实践经验为例，UDF的任务在很多大数据客户的平台里面占比还是比较大的。这一类的任务的情况比较复杂，因为它的依赖也比较多。
针对这些UDF的任务我们需要进行分类的检测，再给出不同的迁移建议。我们把这个任务大概分成了五类：
第一类，完全兼容（jar/tar包）。我们建议直接进行验证，在倚天上跑一下，确定它的兼容性。
第二类，jar包不兼容，开源jar版本升级。我们建议升级对应的maven仓库中兼容ARM版本的，并引入对应的so。
第三类，jar包不兼容，开源jar版本升级+开源库编译。我们建议升级maven仓库中兼容arm版本的，并引入对应的so，然后重新编译开源代码仓库，提供兼容arm的so。
第四类，python库不兼容，重新编译对应的python库。我们建议重新编译对应的python库，或者搜寻编译好的python aarch64的依赖库安装包，通过安装获取对应的so。
第五类，so不兼容，无开源代码，业务方重新编译。我们建议推动业务方重新编译，在倚天实例上重新进行兼容性的验证。
我们前面已经把大数据场景里在ECS倚天实例的迁移适配、性能优化、UDF适配的工作都简单介绍了一遍，看起来还是比较简单的，可以做到比较平滑的迁移。但为了让用户能够更好的开箱启用，体验到刚刚讲到的适配和优化的成果。我们基于ECS Boost和CADT开发了MRACC加速和ECS实例Spark集群性能的最佳实践。
大家可以通过http://bp.aliyun.com/detail/346 链接，看到一键就能拉起我们向左边图里介绍的1个master+6个worker的Spark集群。这里面我们也会把前面讲到的适配和推荐的版本以及性能优化的OS层面的优化、JDK的优化、应用层面的优化、应用参数的优化，形成一个整体的优化方案。我们一键就能把这个集群开起来，运行里面提供的TPCDS的benchmark测试，快速拿到基于ECS倚天实例的大数据场景下Spark的最佳性能。
也可以根据这个性能结果和X86平台进行对比，这样我们就可以将整个迁移流程缩短到小时级别。我们也真实的希望客户通过这种方式快速了解ECS倚天实例在大数据场景Spark的性能的最佳体验，也可以通过这个来了解到神龙大数据加速引擎MRACC在Spark提升的性能的最佳体验。
整个方案是可视化的架构模板，操作起来也是比较方便的，这里就不带大家操作了。大家可以通过文档上的链接进去，里面有一个比较详细的操作文档，可以根据这个文档进行实践。
和Spark类似，我们也开发了一个MRACC加速ECS倚天实例Flink集群性能的最佳实践。根据这个文档我们也可以一键拉起一个1+6的Flink的集群，并在里面运行nexmark的测试。同样我们也会在这里面与预置前面讲到的性能优化的点，客户可以一键拉起以后开箱即用，快速的验证MRACC加速倚天ECS实例Flink集群性能。
和Spark、FLink类似，我们也有针对其他的大数据组件的最佳实践，比如Kafka、ES，欢迎大家试用。以上就是本次课程的全部内容，想要关注更多【倚天实例迁移课程】直播的同学可以点击链接/扫描下方二维码进入活动官网了解更多资讯！
