网页开发网站,景观做文本常用的网站,合肥建设网站查询系统,WordPress生成图片关于本文 近期一直在协助做AI大模型数据清洗调优的工作#xff0c;主要就是使用大数据计算引擎Spark做一些原始数据的清洗工作#xff0c;整体数据量大约6PB-8PB之间#xff0c;那么对于整个大数据量的处理性能将是一个重大的挑战#xff0c;关于具体的调优参数配置项暂时不…关于本文 近期一直在协助做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、jprofilergolang常用的就是pprof等。
