大数据做「AI大模型」数据清洗调优基础篇

关于本文

近期一直在协助做AI大模型数据清洗调优的工作，主要就是使用大数据计算引擎Spark做一些原始数据的清洗工作，整体数据量大约6PB-8PB之间，那么对于整个大数据量的处理性能将是一个重大的挑战，关于具体的调优参数配置项暂时不在本文内容之中，因为调优还在进行时，等事情结束之后，再将相关参数以及说明发布出来。

通常来说，基础大数据集群部署之后不需要做一些调优之类的事情，可以应对几十GB或者几百GB的数据处理诉求（还要结合计算资源多少），但是当数据量和计算任务量级上了一个梯队之后（TB级别），调优有几个基本核心点需要掌握，在更多数据量、更多节点数、更多作业量级的时候，那么就要关注一些组件配置项的默认值是否合理了，一般的默认配置都是保证基本可用的，具体要改哪些配置，修改到多大的阈值要结合很多因素来考虑，本文就根据笔者的一些实战经验来概述三点（仅供参考！）

整体来说，应该关注哪些因素
存储量上升，需要关注哪些指标来应对读写瓶颈
计算并发应该怎么设定合理？遇到瓶颈怎么办？

一：整体来说，应该关注哪些因素？

对于一个大数据集群来说，无非是包含两种类的服务，一种是计算服务（MR、Spark、Flink）、一种是存储服务（HDFS、对象存储），这些服务所运行的介质都是在某些硬件资源之上的，所以，在执行大作业、大数据量的准备工作之前我们要先评估硬件设备是否合理。

从本次调优来说，服务器单台的配置是128C2TB16TB*10 节点数在100台的规模（后续还在扩容），从机器配置来看，基本上已经满配了，但是并不是配置高了就足够了，我们还要关注CPU的调优、内存分配、硬盘盘位和硬盘类型、网络带宽大小（出入带宽流量）等等，硬件配置决定了整体软件处理性能的上限，即便软件写的很厉害，但是硬件配置跟不上的话那其实就等同于巧妇难为无米之炊。

从CPU层面需要关注那些指标：CPU是整个计算系统的核心，我们所启动的计算作业都是通过CPU的核心来进行计算的，一般大数据作业我们要关心CPU的型号、核心数，更多的核心意味着可以同时处理更多任务，尤其在大数据多线程应用中作用更大一些。其次就是主频，主频表示CPU每秒钟所能执行的基本运算次数，更高的主频通常意味着单线程任务处理速度更快。
从硬盘层面需要关注那些指标:磁盘选型是作为整个存储吞吐的核心要素之一，同时，硬盘的选型也决定了计算性能的瓶颈，当硬盘吞吐小于计算所产出的数据时，那么硬盘将为作为一个瓶颈问题, 关于硬盘首先是SSD、HDD、云盘这些来选择，你可以使用一些硬盘类的压测工具来测试每块盘的吞吐量和IOPS，比如 dd 、 CrystalDiskMark 等等。
从网卡流量方面需要关注那些：网卡是整个分布式系统做数据交换必须经过的介质，现在基本都是万兆网卡，整个流量吞吐能到几十Gb/s，在集群部署之前可以选择使用iperf3进行压测，看看整个网卡带宽的阈值是多大。在大数据量的计算过程中各个节点之间的数据传输都要经过网卡来传输，所以，如果网卡的吞吐值很小的话，就会影响整个作业的运行速度。当数据长期积压之后，那么极大可能这个container就会被failed了。

二：存储量上升，需要关注哪些指标来应对读写瓶颈？

当进行数据持续大量导入的时候，那么这里我们就要面临几个问题？除了上面几个硬件瓶颈的问题解决之外，还要查看关于底层存储系统（比如：HDFS、对象存储），对于分布式存储来说，底层都是通过RPC协议来通信的，那么这里就要判断服务本身对于RPC处理线程的大小，一般默认值都是500-1000之间，这个值就会限制大规模集群的数据同步效率。

其次，对于像HDFS这种分布式文件系统来说，为了控制数据同步的速率，可以通过DN的bandwith来控制台数据复制的带宽大小，如果服务本身的这种带宽限制比较小的话呢，也会影响数据同步的效率，所以一般而言，要根据整个集群的规模大小，所处的场景是单纯存储还是单纯计算还是存储和计算都有，如果是单存储场景的话，那么这个值就建议调大一些，可以放到Gb级别（注意：HDFS里面的带宽单位是大B，一个Byte等于8个bit，通常网卡传输是bit来传输的）

在数据量快速上升的时候，即便我们的磁盘空间足够大，也要做好空闲资源的预留，避免有热点问题的时候造成某些节点一直被写入，一直到磁盘写满影响服务的稳定性，那么这时候我们要提前设置好存储系统在写入本地磁盘的时候的预留值，我们至少要预留10%-20%的buffer，或者150G-300G的空间。

最后，就是存储选型是选择本地存储还是云端存储，这两个根本区别就是成本高低和对性能的追求，毋庸置疑，本地存储的性能是高于云端对象存储的，但是成本方面也是远远大于对象存储成本的，所以，对于这块的选型我们需要根据实际情况来判断，是空间换时间，还是成本换性能，或者说二者结合的方式也可以是一个方案，最终的数据存储还是建议留存在对象存储中的，毕竟长期来看成本更低。

三：计算并发应该怎么设定合理？遇到瓶颈怎么办？

关于计算资源这块其实涉及到的因素很多，比如硬件资源的CPU核心数，并发计算的任务多指定的虚拟核心数不能超过物理CPU核心数太多，否则会影响整个计算任务频繁的上下文切换，以及其它计算任务获取不到线程，比如内存的容量，每个并发执行的Task都需要一定的内存资源，来进行数据的加载和处理，我们需要合理的每个Map的内存大小，设置太小容易OOM，设置太大的话则资源浪费，也会触发系统级的内存交换（SWAP）影响性能，比如网络带宽和磁盘IO，如果任务需要频繁的数据同步，那么网络和磁盘的IO会比较高，这时候需要判断是否要进行数据局部加载或者分区/分块计算。

除了上面提到的硬件资源的合理配比之外，对于计算引擎本身的调优也是需要着重考虑，当然不同的计算引擎的调优参数项都不太相同，这里就提及一些能够代表一些共性的点出来吧！

根据所要计算的文件数量大小，来合理分配并发数，最好是文件数是并发数的整数倍，比如50个文件可以设定50并发或者25并发，避免设定太小影响任务执行时长，设置太大的并发度导致过多的上下文切换和通信开销。
要监控整个集群的核心指标，来判断那块会是瓶颈，如果发现某个资源使用率持续达到100%，例如CPU一直满载或内存频繁溢出，则可能是资源瓶颈。此时应考虑优化作业代码、提高硬件资源配置或调整资源分配策略。
如果并行计算任务之间存在大量等待和阻塞，可能是由于并行度设置不合理、任务间依赖关系复杂、锁竞争激烈等原因造成的，需要重新设计任务划分和执行策略。

四：结尾

综上而言，简单的概述了一下关于调优方面的基本面，当作近期调优工作的一个简单记录，后面针对每个组件的调优项以及硬件资源的配比可以单独输出一篇，毕竟目前还在进行时，针对不同的作业不同的数据及规模不同的计算引擎类别都需要针对性的进行调整。

但是，总体而言，掌握基本面之后，在上面进行具象的分析调整，基本上能够找到核心问题点以及对应的解决措施。

最后，就是关于工具的时候，在一些服务运行过程中，可能会有很多难以解释的现象，比如死锁问题、链接池问题、CPU过高问题、内存溢出问题等等，我们需要解决一些工具来排查服务里面具体是哪个类和那个函数出现了问题，一般Java常用的就是jstat、jprofiler，golang常用的就是pprof等。