赋能Arm大数据开源生态，华为的探索之路

1 .赋能ARM大数据开源生态， 华为的探索之路 郑振宇 姜逸坤 华为计算开源开发与运营部 部门： 作者： 日期： 

2 .自我介绍 华为计算开源开发与运营部 华为计算开源开发与运营部 高级软件工程师 开源软件工程师 目前致力于鲲鹏开源软件生态拓展。 目前负责鲲鹏开源软件生态使能。 2 Huawei Confidential 

3 . 目录 1. 主流开源社区Arm使能情况概览 2. Hadoop on Arm探索之路 3 Huawei Confidential 

4 . 多样性架构成为计算产业发展的趋势 PC 时代(互联网、企业网) 移动互联网时代 云、AI、5G等新技术加持的时代 1985 2007 2016 2018 2019 Windows 1.x发布 第一代苹果手机 5G Polar code 全球公有云服务和基础设施 中国5G牌照发放 在3GPP第87次 支出达到1696.28亿美元 会议确定为控制 信道编码方案 算力多元汇聚 业务软件 业务软件 云服务 云端算力 小机/X86 Server X86 Server X86 Server Arm Server GPU xPU 2G 低时延 网络虚拟化 网络虚拟化 网络 固定网络 SDN 3G SDN 5G 超高带宽 4G 终端算力 X86 PC X86 PC Arm智能终端 嵌入式人工智能 X86 PC Arm智能终端 IoT 终端 低功耗 技术生态： 单一封闭 → 逐步开放 → 拥抱开源 4 Huawei Confidential 

5 .全栈使能开源软件 Big Data Web AI 生态全栈 … … … 应用/行业 … 数据库、中间件 … 云、虚拟化、容器 … OS、基础库 glibc Zstandard … 硬件平台 … 鲲鹏 + 昇腾 5 Huawei Confidential 

6 .开源软件使能两部曲 Step1. 可用 Step2. 好用 Arm CI 前置开源社区，端到 鲲鹏/Arm优化合入开源社区 端持续使能开源开发流程。 上游，从源头释放鲲鹏算力， 性能高，成本低 开源社区官方Arm软件包发布， 易获得，来源可信。 6 Huawei Confidential 

7 .Arm CI 前置开源社区，持续使能开发流程 开发调试 编译构建 集成验证 打包发布 开发者 √ 开发流程基于X86 x86用户 平台，软件在Arm X86 CI环境 （X86硬件/OS/lib/配置） 平台使用需要二次 X86 ? 适配 Arm用户 ARM CI环境 （ARM硬件/OS/lib/配置） √ ARM用户 ARM 开发调试 编译构建 集成验证 打包发布 开发者 x86 CI环境 （x86硬件/OS/lib/配置） √ x86用户 7 Huawei Confidential x86 

8 .Arm CI 前置开源社区，持续使能开发流程 开发调试 编译构建 集成验证 打包发布 开发者 √ x86用户 x86 CI环境 （x86硬件/OS/lib/配置） x86 ? ARM用户 Arm CI环境 （Arm硬件/OS/lib/配置） √ Arm用户 Arm CI 前置开源社区，与 Arm X86的CI环境并行验证，适 开发调试 编译构建 集成验证 打包发布 配问题在开源社区上游闭 环，官方原生Arm软件包 开发者 发布，端到端持续使能开 X86 CI环境 发流程，一次投入，持续 （X86硬件/OS/lib/配置） √ 受益 X86用户 8 Huawei Confidential X86 

9 .Arm CI 前置开源社区，持续使能开发流程 Hadoop trunk分支每日构建，发送测试结果到开发者邮件列表，测试用例 24000+，持平X86平台，3.3.0版本起官方支持Arm64平台 Spark master分支每日构建，测试用例(Java, Scala, Python) 25000+，持 平X86平台，3.0.0版本起官方声明支持ARM64平台 Hbase master分支每日构建，测试用例8000+，持平X86平台 大数据 Big Data Hive trunk分支每日构建，测试用例(静态测试+qtests) 17000+，持平X86 平台 Flink master分支每日构建，测试用例35000+，覆盖全量单元测试、端到端 测试，持平X86平台 Kudu master分支每日构建，覆盖Debug, Release, IWYU, LINT 4种场景， C，Java, Python 3种测试语言，测试用例10000+，持平X86平台 9 Huawei Confidential 

10 .开源社区Arm版本发布，易获得，来源可信 2020年7月14日，Hadoop社 区发布首个原生支持ARM架构 的版本3.3.0，并在官方页面提 供Arm版本二进制软件包下载 10 Huawei Confidential 

11 . Arm ready projects glibc OpenSSL Zstd Hadoop Gzip Spark 已 Zlib HBase 识 x265 Hive 别 grpc-java Kafka 的 Snappy Flink MySQL K8S 被 主 Storm PostgreSQL OpenStack 依 jemalloc Netty 流 Zookeeper 主 MariaDB 主 Libvirt 赖 OpenCV 公 Oozie 流 MongoDB 流 Qemu/KVM 库 Hyperscan 有 Flume 公 Redis 公 Docker Nginx DPDK 可 Sqoop 有 Greenplum 有 CoreDNS Apache Boost 云 Phoenix 可 ElasticSearch 可 Containerd 99% Tomcat BLAS 提 Ambari 云 RocksDB 云 Prometheus HAproxy FFTW 供 Druid 提 Cassandra 提 Fluentd Jboss SPDK Impala 供 Memcached 供 Envoy Lighttpd 按 RDMA Presto InfluxDB Ceph Varnish 需 libm Solr Percona GlusterFS LVS TensorFlow 实 bigDL Tez scyllaDB BeeGfs 1% Squid PyTorch 现 math Kudu Gridgain Ovirt HHVM PaddlePaddle MKL … … … … … … 大数据(30+) 数据库(15+) 云计算&存储(20+) Web(15+) AI(5+) 基础库&中间件(30+) Project TOPN 11 Huawei Confidential 

12 .开发者支持 开发调试 持续集成 + https://openlabtesting.org 12 Huawei Confidential 

13 . 华为全联接2020线上分会场 《开源软件助力鲲鹏算力释放》 9月28日 15:00 13 Huawei Confidential 

14 . Hadoop on Arm探索之路 14 Huawei Confidential 

15 . Step1. 可用 15 Huawei Confidential 

16 .Hadoop on Arm之路——关键历程 开始使能ARM CI 介绍ARM支持进展 讨论CI落地方案 Arm CI启用 发布第一个Arm版本 2019.06.11 2019.08.22 2019.11.13 2020.01.06 2020.07.14 2019.06.11 创建“Add an Arm CI for Hadoop”的Issue。 2019.08.22 在Hadoop Community Meetup @Beijing 同步Arm支持进展。 2019.11.13 在Hadoop Online Community Sync上介绍Arm CI落地方案。 2020.01.06 Hadoop Arm CI在社区正式启用。 2020.07.14 Hadoop社区于3.3.0版本发布第一个Arm包。 16 Huawei Confidential 

17 .Hadoop on Arm之路——我们做了哪些工作？ 完成Hadoop Arm适配的主要工作： - Protocolbuf： 在Hadoop社区推动升级至3.7.1版本[1]。 - gRPC：在gRPC上游完成Arm适配，在Hadoop社区推动grpc升级至1.26.0版本[2]。 - LevelDB：在LevelDB上游完成Arm适配，并推动社区增加1.8适配版本的依赖[3][4]。 - Netty：在Netty上游完成后Arm适配后，在Hadoop社区推动升级4.1.50[6][7]。 - Build dockerfile：start-build-env aarch64 Dockerfile，帮助Release Manager发布Arm版本[8]。 [1] https://issues.apache.org/jira/browse/HADOOP-13363 [2] https://github.com/grpc/grpc-java/issues/6364 [3] https://issues.apache.org/jira/browse/YARN-10042 [4] https://search.maven.org/artifact/org.openlabtesting.leveldbjni/leveldbjni-all/1.8/bundle [5] https://issues.apache.org/jira/browse/HADOOP-16614 [6] https://github.com/netty/netty/pull/9804 [7] https://github.com/netty/netty-tcnative/pull/517 [8] https://issues.apache.org/jira/browse/HADOOP-16797 17 Huawei Confidential 

18 .Hadoop Arm适配实例——Java Math的“兼容性” 1. 现象： 3. 原理分析： Arm CI运行起来后有些数学库相关的用例挂了，算 出来值和用例有差异。在Hive、Spark、Flink中均 出现过类似问题。 2. 问题简化：小数点后第16位的问题 # on x86 - java 8 Math.log(3): 1.0986122886681098 数值不一致 StrictMath.log(3): 1.0986122886681096 Math.log默认会调用到通用实现，并为各种架构提供动态替换机制： # on aarch64 - java 8 Math.log(3): 1.0986122886681096 - x86 的汇编实现，精度不准确。 StrictMath.log(3): 1.0986122886681096 - Arm64的计算准确，JDK8直接用通用接口，JDK11汇编性能提升。 解决建议： - 对精度要求高场景，更换为StrictMath。 发现其他架构场景下的隐藏问题 - 对精度无要求场景，对测试用例进行优化。 完善多架构场景下健壮性 18 Huawei Confidential 

19 . Step2. 好用 19 Huawei Confidential 

20 .Hadoop压缩性能优化——Hadoop哪个阶段压缩了？ Map spill Split Ring Map.out MTask.out spill Map Split Input … … … … Merge Reduce Output Split Map spill Split Ring Map.out MTask.out spill Map 压缩1 解压1 压缩2 解压2/压缩3 解压3/压缩4 解压4 压缩5 Hadoop MapReduce流程中共涉及： 1. 压缩1：用户输入文件为压缩格式。 2. 解压1：在用户自定义的Map执行前进行解压。 - 5次压缩 3. 压缩2：Map执行后，从数据环形缓冲区落盘时，进行压缩。 - 4次解压 4. 解压2/压缩3：spill文件解压后，再合成为一个压缩map.out。 5. 解压3/压缩4：解压读取Map阶段输出，最终合并为一个压缩文件。 6. 解压4：Reduce读取前，对文件进行解压。 20 Huawei Confidential 7. 压缩5：最终Reduce的输出文件进行压缩 

21 .Hadoop压缩性能优化——Hadoop压缩如何配置？ Map spill Split Ring Map.out MTask.out spill Map Split Input … … … … Merge Reduce Output Split Map spill Split Ring Map.out MTask.out spill Map 压缩1 解压1 压缩2 解压2/压缩3 解压3/压缩4 解压4 压缩5 MapReduce阶段 关键阶段 涉及配置项 Map的输入数据 压缩1 无，用户对输入文件压缩，Hadoop根据格式自动解压 mapreduce.map.output.compress、 中间输出（MAP） 压缩2-4 mapreduce.map.output.compress.codec 解压缩配置方式 mapreduce.output.fileoutputformat.compress 最终输出（Reduce） 压缩5 mapreduce.output.fileoutputformat.compress.codec mapreduce.output.fileoutputformat.compress.type 21 Huawei Confidential 

22 .Hadoop压缩性能优化——从“底层”做起 ZSTD解压缩性能测试 1.2 性能提升(倍) ZSTD性能优化[1] [2] ： 1.1 1 - 在不同压缩比场景，压缩性能提升约3.3%，解压性能约提升13+% 0.9 - 利用Prefetching机制、Neon指令优化，代码全部贡献上游 压缩 解压 [1] https://github.com/facebook/zstd/pull/2040 ZSTD ZSTD(优化后) [2] https://github.com/facebook/zstd/pull/2041 Snappy解压缩性能测试 Snappy性能优化[3]： 1.2 性能提升(倍) 1.1 - 压缩率保持不变，压缩性能提升10+%、解压性能提升9+% 1 - 利用Prefetching 机制、Neon指令优化，代码全部开源 0.9 压缩 解压 [3] https://github.com/kunpengcompute/snappy Snappy Snappy(优化后) Zlib/GZip性能优化[4]： Zlib解压缩性能测试 15 - 压缩性能提升30+倍，解压性能升7+倍 压缩速率(GB/s) 10 - 利用鲲鹏专用硬压缩模块，降低CPU利用率 5 0 - 配套KAE加速引擎及KAEZip实现，代码全部开源 1核压缩 8核压缩 1核解压 8核解压 [4] https://www.huaweicloud.com/kunpeng/software/kaezip.html Zlib KAEZip 22 Huawei Confidential 

23 .Hadoop压缩性能优化——从“底层”做起 测试环境（同规格32u/64GB）： TeraSort 50GB on Ubuntu 18.04， 5 Mbit/s, 500GB SSD Arm VM: kae1.8xlarge.2 | 32vCPUs Huawei Kunpeng 920 7260 2.6Ghz | 64GB 测试结论： TeraSort端到端场景，Zlib(KAE)加速开启后，提升14+%；Snappy优化后，提升10+% Hadoop TeraSort 性能测试(Zlib) 2 性能提升(倍) 开启压缩后性能提升 1.5 Zip Total Map Shuffle Reduce 1 No codec base base base base 0.5 Zlib 32.15% 31.03% 29.40% 24.87% 0 Total Map Shuffle Reduce Zlib(KAE) 46.53% 59.61% 50.98% 35.28% NoCodec Zlib Zlib(KAE) Hadoop TeraSort 性能测试(Snappy) 2 开启压缩后性能提升 性能提升(倍) 1.5 Zip Total Map Shuffle Reduce 1 No codec base base base base 0.5 Snappy 39.45% 56.16% 45.35% 5.37% 0 Snappy(优化) 49.90% 52.71% 52.57% 28.27% Total Map Shuffle Reduce 23 Huawei Confidential NoCodec Snappy Snappy(优化) 

24 .Hadoop压缩性能优化——ARM64和x86的对比 测试环境（同规格32u/64GB）： 性能： TeraSort 50GB on Ubuntu 18.04， 5 Mbit/s, 500GB SSD - 非压缩场景 - 3.8% - Arm VM: kae1.8xlarge.2 | 32vCPUs Huawei Kunpeng 920 7260 2.6Ghz | 64GB - Snappy场景 - 1.95% - X86 VM: c6.8xlarge.2 | 32vCPUs Intel Cascade Lake 6626c 3.0GHz | 64GB - Zlib场景 - 11.44% （开启KAE加速后，+12.18%） Hadoop TeraSort 性能测试(Snappy) 价格： 1.5 性能提升(倍) 1 Huawei Cloud AWS packet.com 23040 RMB (yearly) 3384 USD (yearly) 8760* USD (yearly) 0.5 ARM 32 vCPU/64GB 16 vCPU/64GB 32 vCPU/128GB 2.6 Ghz Kunpeng 920 2.5 Ghz Graviton 2 3.3 Ghz Ampere eMAG 0 No Codec Snappy Zlib Zlib(加速后) 30473 RMB (yearly) 4239 USD (yearly) 17520 USD (yearly) 32 vCPU/64GB 16 vCPU/64GB x86 ARM x86 32 vCPU/256GB 3.0/3.4 Ghz Intel Xeon 2.5/3.1 Ghz Intel Xeon 2.5 Ghz AMD EPYC 7502P 6266C Cascade Lake 8175M Skylake Arm vs x86 (No Codec) Arm vs x86 (Snappy) 节省 24% 20% ~50% (with storage) Total Map Shuffle Reduce Total Map Shuffle Reduce -15.4s -5.8s -1.6s -5.2s -4.0 -4.8 -8.0 4.2 -3.80% -7.69% -0.99% -6.47% -1.95% -14.29% -11.49% 6.40% Arm vs x86 (Zlib) Arm(KAE) vs x86（Zlib） Total Map Shuffle Reduce Total Map Shuffle Reduce 同规格Flavor，ARM整体比x86价格便宜20~50%左右。 -29.3 -3.0 -10.5 -9.4 31.2 20.2 24.8 -9.0 https://www.huaweicloud.com/intl/en-us/pricing/index.html?tab=detail#/ecs -11.44% -5.66% -10.00% -20.15% 12.18% 38.11% 23.62% -19.40% https://aws.amazon.com/ec2/pricing/on-demand/ https://www.packet.com/cloud/servers/ 24 Huawei Confidential 

25 .Hadoop多样性算力混合部署（扩容场景） Master：X86 NameNode ARM64：多核优势 ResourceManager X86：单核性能 X86 X86 NodeLabel：Arm64 NodeLabel：Arm64 DataNode DataNode DataNode DataNode NodeManager NodeManager NodeManager NodeManager Default Partition Arm64 Partition • mapreduce.job.node-label-expression 原有业务流程可以继续在 default partition（X86）中执 • mapreduce.job.am.node-label-expression 行，新的 Arm64 partition 可平滑扩容至新集群，利用 • mapreduce.map.node-label-expression node label 将 job 调度到算力优势节点，通过多样性算 • mapreduce.reduce.node-label-expression 力，提升集群整体性价比。 25 Huawei Confidential 

26 .Hadoop多样性算力混合部署（实际环境截图） X86节点 * 3 ARM节点 * 3 

27 .Hadoop多样性算力混合部署性价比对比 X86 部署规格： 9.1 万元/年 - Arm VM: kc1.8xlarge.2 | 32vCPUs Huawei Kunpeng 920 7260 2.6Ghz | 64GB X86 X86 X86 - X86 VM: c6.8xlarge.2 | 32vCPUs Intel Cascade Lake 6626c 3.0GHz | 64GB X86 X86 Hadoop TeraSort 性能测试 混合部署价格估算 8.4 万元/年 1.5 Arm X86 X86 10 性能提升(倍) (节省7%) 集群价格（万元/年） 1 混部1 5 0.5 X86 0 0 Total Map Shuffle Reduce 价格 7.7 万元/年 X86 混部1 混部2 Arm Arm Arm X86 X86 混部1 混部2 Arm (节省15%) 混部2 X86 结论： 经验证，多样性算力混合部署场景可行，且性能与单一算力场景持平， 6.9 万元/年 混合部署场景更具性价比 Arm Arm Arm Arm 27 Huawei Confidential 

28 . 测试结论： - 非压缩场景、启用Snappy场景性能基本与X86持平 - 启用Zlib场景性能差距-11%左右，开启硬件加速后领先+12% - 同规格云主机价格Arm比X86便宜20%~50%左右 - 新增Arm节点可以平滑扩容至原有集群 - 多样性算力混合部署可行，与单一算力性能场景持平，更具性价比 28 Huawei Confidential 

29 .共筑开源社区繁荣 • 计算魔方微信公众号 鲲鹏软件开源： - Github：https://github.com/kunpengcompute - 技术博客: https://kunpengcompute.github.io/ Thank you. 29 Huawei Confidential