【BoostKit实战】踩过无数坑后，我总结的鲲鹏大数据集群调优干货

【BoostKit 实战】踩过无数坑后，我总结的鲲鹏大数据集群调优干货

发布版块：鲲鹏社区 - 鲲鹏 BoostKit 版块 适配版本：BoostKit 23.0.RC2 + openEuler 22.03 LTS 集群规模：三十二节点鲲鹏 920

前言

说实话，最开始的时候对 BoostKit 没抱太大期望，觉得就是个普通的加速包。结果真正用起来才发现，用好和用不好，性能差距能有一倍多。今天把这半年踩过的坑、总结的经验全部分享出来，都是生产环境验证过的干货。

这篇文章不讲理论，全是实操经验。觉得有用的兄弟欢迎点赞，有问题评论区一起交流。

一、先说说 BoostKit 到底是什么

很多人刚接触 BoostKit 的时候都搞不清楚，这东西到底和普通的开源组件有什么区别？

简单说，BoostKit 就是华为针对鲲鹏 ARM 架构，对大数据、分布式存储、数据库这些基础组件做的深度优化。不是简单重新编译一遍，而是从内核层面、指令集层面、算法层面都做了针对性改造。

具体到我们大数据场景，BoostKit 主要包含这几块：

1. 鲲鹏原生加速库：针对 ARMv8.2 指令集优化的压缩、加密、数学运算库，像 zlib、snappy、openssl 这些，比开源版本快 30%-200%
2. Hadoop 生态组件优化版：HDFS、YARN、HBase、Spark 这些都有专门的鲲鹏优化版，不是社区原生的
3. 内核参数调优工具：一键配置鲲鹏平台最优的系统参数
4. 运维监控工具：专门针对鲲鹏架构的性能监控和问题定位工具

最开始我们图省事，直接用社区原生的 Hadoop 在鲲鹏上跑，结果性能比 x86 还慢。后来全部换成 BoostKit 优化版，同样的硬件，整体性能提升了 40% 多，这才真正发挥出鲲鹏的优势。

二、环境部署：第一个坑就卡了我们三天

2.1 版本匹配是重中之重

这是第一个，也是最容易踩的坑。

BoostKit 的版本和操作系统、JDK、组件版本的匹配要求非常严格，差一个小版本都可能出问题。我们最开始用的是 BoostKit 23.0.RC1，搭配 JDK 1.8.0_362，结果 HDFS 启动的时候直接崩溃，报 JNI 调用错误。

查日志、抓堆栈，折腾了三天，最后发现就是 JDK 版本不匹配。BoostKit 23.0.RC1 只支持到 JDK 1.8.0_342，用更新的版本就会出问题。

给大家一个我们验证过的、最稳定的版本组合：

血泪教训：不要擅自升级任何组件的版本，严格按照配套表来。

2.2 安装顺序千万别错

BoostKit 的安装顺序很有讲究，错了就会各种依赖报错：

1. 先装操作系统，配置好网络和 YUM 源
2. 再装毕昇 JDK，配置好 JAVA_HOME 环境变量
3. 然后装 BoostKit 基础加速库（zlib、openssl、KAE 等）
4. 最后装 Hadoop、Spark 这些上层组件

我们最开始反过来装，先装了 Hadoop 再装加速库，结果加速库根本不生效，Hadoop 还是用的系统原生库。全部重装一遍才解决。

安装完一定要验证加速库有没有生效：

# 检查zlib加速
ldd /usr/bin/hadoop | grep zlib
# 如果输出的是/usr/local/lib/libkadzlib.so就是对的

# 检查openssl加速
openssl speed -evp aes-128-cbc
# 鲲鹏920上单核应该能跑到8Gbps以上，没加速的话只有2Gbps

三、核心加速库：性能提升的关键

3.1 KAE 加密加速库，必开！

KAE（Kunpeng Accelerator Engine）是 BoostKit 里最有用的一个加速库，直接调用鲲鹏 920 的硬件加密引擎，AES、SHA 这些算法全部硬件加速。

这个东西默认是不开启的！很多人装完 BoostKit 就不管了，等于白装。

开启方法：

# 安装KAE驱动和引擎
yum install kae kae-provider openssl-kAE-engine

# 配置openssl使用KAE引擎
echo "openssl_conf = openssl_def" >> /etc/pki/tls/openssl.cnf
echo "" >> /etc/pki/tls/openssl.cnf
echo "[openssl_def]" >> /etc/pki/tls/openssl.cnf
echo "engines = engine_section" >> /etc/pki/tls/openssl.cnf
echo "" >> /etc/pki/tls/openssl.cnf
echo "[engine_section]" >> /etc/pki/tls/openssl.cnf
echo "kae = kae_section" >> /etc/pki/tls/openssl.cnf
echo "" >> /etc/pki/tls/openssl.cnf
echo "[kae_section]" >> /etc/pki/tls/openssl.cnf
echo "engine_id = kae" >> /etc/pki/tls/openssl.cnf
echo "dynamic_path = /usr/lib64/engines-1.1/kae.so" >> /etc/pki/tls/openssl.cnf
echo "init = 0" >> /etc/pki/tls/openssl.cnf

开启前后的性能对比（单核心）：

开启 KAE 之后，我们集群的 HDFS 数据传输加密、Spark Shuffle 加密的 CPU 占用直接从 30% 降到了 5%，整个集群的吞吐量提升了 25%。

3.2 zlib 加速：压缩性能翻倍

大数据场景下大量的数据压缩解压，zlib 的性能直接影响整个集群的效率。BoostKit 的 kad-zlib 针对鲲鹏 NEON 指令集做了深度优化。

我们实测的压缩性能对比（压缩级别 6）：

性能直接翻倍，压缩率还完全一样。这个对我们的 HBase 和 Spark 任务提升特别明显，平均任务执行时间缩短了 30%。

3.3 一个巨坑：KAE 和 Java 的配合

KAE 虽然好，但和 Java 配合有个大坑 —— 默认情况下 JDK 不会用系统的 openssl，也就用不了 KAE 加速。

必须用毕昇 JDK，然后加上这两个 JVM 参数：

-XX:+UseKAEProvider
-XX:KAEEnginePath=/usr/lib64/engines-1.1/kae.so

不加这两个参数，Java 进程的加密还是用软件实现，KAE 等于白开。我们最开始就是漏了这个，查了快一周才发现为什么 Java 进程的 CPU 占用还是那么高。

四、HDFS 调优：从卡顿到丝滑

4.1 短路读取一定要开

鲲鹏平台上，HDFS 的短路读取（Short Circuit Read）性能提升特别明显。因为鲲鹏的内存带宽高，本地读取的优势更大。

配置参数：

<property>
  <name>dfs.client.read.shortcircuit</name>
  <value>true</value>
</property>
<property>
  <name>dfs.domain.socket.path</name>
  <value>/var/lib/hadoop-hdfs/dn_socket</value>
</property>
<property>
  <name>dfs.client.domain.socket.data.traffic</name>
  <value>true</value>
</property>

开启之后，本地读取的性能从 350MB/s 提升到了 850MB/s，提升了一倍还多。

4.2 DataNode 内存调优

鲲鹏 920 的内存大，通道多，DataNode 可以配置更多的处理线程：

<!-- 数据节点处理线程数，x86一般配16，鲲鹏配更多 -->
<property>
  <name>dfs.datanode.max.transfer.threads</name>
  <value>65536</value>
</property>

<!-- 心跳并发数 -->
<property>
  <name>dfs.namenode.handler.count</name>
  <value>128</value>
</property>

我们最开始用 x86 的配置，DataNode 经常出现线程不够用的情况，大量 IO 请求排队。增大线程数之后，排队现象直接消失。

4.3 磁盘调度器一定要改

这个也是很多人忽略的点。鲲鹏服务器一般用的是 NVMe SSD，磁盘调度器一定要改成 none 或者 mq-deadline，不要用默认的 cfq。

# 临时生效
echo none > /sys/block/nvme0n1/queue/scheduler

# 永久生效，写到/etc/rc.local
for dev in nvme0n1 nvme1n1 nvme2n1 nvme3n1
do
  echo none > /sys/block/$dev/queue/scheduler
done

改完之后，磁盘随机 IO 的延迟从 12ms 降到了 2ms，HDFS 的写入性能提升了 40%。

五、Spark 调优：任务速度提升一倍

5.1 必须用 BoostKit 优化版 Spark

这个一定要强调：不要用社区原生的 Spark！

BoostKit 优化版的 Spark 做了大量的 ARM 适配和性能优化，特别是 Shuffle 阶段。我们对比过，同样的代码，同样的数据，优化版比社区版快 40% 以上。

几个关键的优化点：

• Shuffle 合并算法优化，减少了大量的内存拷贝
• 基于 NEON 指令集优化的排序算法
• 序列化和反序列化加速
• 更高效的内存管理

5.2 executor 配置最佳实践

鲲鹏 920 核心数多，内存带宽高，executor 的配置和 x86 不一样：

# 每个executor的核数，x86一般配5，鲲鹏配8
spark.executor.cores=8

# 每个executor的内存，鲲鹏可以配大一点
spark.executor.memory=32g

# 每个节点的executor数量，留足够核心给系统和HDFS
spark.executor.instances=7

# 开启动态资源分配
spark.dynamicAllocation.enabled=true
spark.dynamicAllocation.minExecutors=7
spark.dynamicAllocation.maxExecutors=28

我们最开始按照 x86 的经验，每个 executor 配 5 核 16G，结果资源利用率只有 60%。改成上面的配置之后，资源利用率稳定在 90% 以上，任务执行时间缩短了 30%。

5.3 Shuffle 调优

Spark 的 Shuffle 是性能瓶颈重灾区，鲲鹏平台上有几个专属优化：

# 用BoostKit优化的Shuffle管理器
spark.shuffle.manager=org.apache.spark.shuffle.sort.BoostKitSortShuffleManager

# 开启Shuffle压缩加速
spark.shuffle.compress=true
spark.io.compression.codec=snappy

# 增大Shuffle缓冲区
spark.shuffle.file.buffer=128k
spark.reducer.maxSizeInFlight=96m

开启 BoostKit 的 Shuffle 优化之后，我们的 TPC-DS 1TB 测试，整体执行时间从 2100 秒降到了 1200 秒，提升了 43%。

六、我们踩过的十大坑总结

最后给大家总结一下我们遇到的最高频的十个坑，遇到了直接对照解决：

1. 装完 BoostKit 性能没提升

   • 检查是不是用了社区原生组件，没装优化版
   • 检查 KAE 加速有没有开启
   • 检查 JVM 参数有没有加 UseKAEProvider

2. HDFS 写入慢，CPU 高

   • 检查磁盘调度器是不是改成了 none
   • 检查 DataNode 的传输线程数是不是够
   • 检查 zlib 加速有没有生效

3. Spark 任务经常 OOM

   • 检查 executor 内存是不是配小了
   • 检查是不是开了动态资源分配
   • 鲲鹏的内存虽然大，但也不是无限的

4. 加密传输 CPU 占用高

   • 肯定是 KAE 没开，回去看 3.1 节的配置
   • 检查 JVM 有没有加 UseKAEProvider 参数

5. 节点之间网络传输慢

   • 检查 TCP 参数有没有优化
   • 检查网卡是不是跑满了
   • 鲲鹏的网卡多队列一定要开

6. 启动报错 JNI 调用失败

   • 版本不匹配，严格按照版本配套表来
   • 不要随便升级 JDK 和组件

7. YARN 资源分配不均

   • 检查 NUMA 绑定有没有做
   • 每个 NUMA 节点分配的 container 数量不要超过合理值
   • 不要跨 NUMA 分配内存

8. HBase RegionServer 卡顿

   • 检查 GC 参数是不是用了 G1
   • 增大 RegionServer 的堆内存到足够大
   • 开 BuckectCache，用堆外内存

9. 压缩解压慢

   • 检查是不是用了系统原生的 zlib
   • 换成 BoostKit 的 kad-zlib
   • Snappy 也要用优化版

10. 升级组件后各种报错

    • BoostKit 的组件不要随便升级
    • 升级前一定要看版本配套说明
    • 生产环境能用就行，不要追新

七、最后说几句心里话

用了半年 BoostKit，最大的感受就是：这东西确实能显著提升鲲鹏平台的性能，但前提是你得会用。很多人装完就不管了，各种优化开关都没开，然后说鲲鹏性能不行，这真的是冤枉鲲鹏了。

把所有优化都打开之后，我们多节点的鲲鹏集群，整体性能已经超过了原来更多节点的 x86 集群，而且功耗还低了 30%。对于信创改造来说，这个结果已经超出预期了。

当然，BoostKit 也不是完美的，文档不够详细，很多坑需要自己踩，版本兼容性也还有提升空间。但总的来说，对于想在鲲鹏平台上跑大数据业务的团队，BoostKit 是必装的，没有之一。

如果大家在使用 BoostKit 的过程中有什么问题，欢迎在评论区留言，我会尽量解答。也欢迎大家分享自己的调优经验，一起把鲲鹏的大数据生态做起来。