总第8期
2016年12月刊
Test Theory    测论
Test Theory    测论
H3C DataEngine大数据平台性能调优
文/郑睿
分享

H3C DataEngine大数据平台是一个包含了运维管理、数据ETL、数据计算以及数据服务的综合业务平台。针对存储密集型、计算密集型等典型应用场景,H3C DataEngine已进行了整体调优并提供一体机解决方案,但是由于大数据平台内部结构的复杂性,往往还不能发挥平台的全部性能,存在着巨大的调优空间。另一方面,在一些部署场景中,硬件环境往往先于软件确定,在已有硬件环境上如何提升性能,充分利用已有资源也是在工作中经常要碰到的问题。

从提高效率和节省投资两个方面,平台调优都是必不可少的工作。本文试对此需求进行简单的探讨。

一、大数据平台性能优化整体思路

大数据集群作为一个统一的生态系统,其各服务之间相互依赖,牵一发而动全身。面对这样状态繁多,无法穷尽的情况,性能调优从一些通用思路上来考虑,再在实际业务中逐一细化。

概括来讲,大数据平台调优,可以从硬件环境、系统资源、集群资源、数据存储和分布、应用代码优化的层面,自下而上考虑,越往下通用性越强,效果越有限;越往上,定制性越强,效果越明显。在大数据调优的过程中,为了高效的完成调优工作,不仅需要监控集群中CPU、内存、磁盘I/O、网络传输,整体负载等静态指标,还需要具备跟踪重要指标动态变化趋势的能力。只有这样才能及时发现瓶颈,指导调优。

H3C DataEngine大数据平台自带有强大的性能监控工具,可以从主机、服务等多个维度提供及时详尽的监控手段;同时,一些业界常用的开源工具如Ganglia和Nmon也可以为性能监控提供很多帮助。

  • Ganglia可以收集集群中所有节点的度量数据,并随时跟踪;从节点、集群、CPU、内存、磁盘、网络等不同维度,直观的用视图反映集群负载的变化情况。
  • Nmon是一个精准定位到单个节点的即时监控工具,对度量指标的反馈更加细化和及时。

二、硬件环境的优化

硬件环境是性能的基础。大数据平台是由多种服务组成的体系,资源的使用是多样的,一个比较简单的办法是预留出保证任务运行的最大化资源。存储容量可以根据数据量、备份机制,预留空间的信息大致算出;磁盘吞吐量和网络带宽具有刚需的特点,调优空间有限;而CPU和内存资源具有一定弹性,可以进一步调优。

  • 磁盘I/O的优化

磁盘I/O是性能问题的高发区,为了尽量避免性能瓶颈的发生,在将磁盘挂载到服务器时,选择每磁盘独立挂载的方式。单个磁盘可以做成RAID0或JBOD(Just a Bunch ofDisk),由于当前CPU可支持的线程数基本上可保证大于磁盘I/O数,这样做可以将每个独立磁盘的I/O吞吐发挥到最大,并且避免整体做RAID0时性能受某个磁盘短板的限制,或者是单磁盘故障造成整体不可用的问题。

在HDD与SSD磁盘的使用上,不考虑成本因素,也要进行合理组合。SSD硬盘的优势在于磁盘I/0吞吐量有明显提升,但是缺点也同样明显,主要是故障率随空间占用和频繁读写次数明显上升的问题。因此SSD磁盘多作为整体架构中的高速缓存,还不能取代HDD磁盘的主力存储地位。

  • 磁盘I/O与网络的平衡部署

在配置磁盘I/O与网络时,需要注意两者的平衡。当磁盘使用独立JBOD或独立RAID0的方式挂载时,使

(磁盘I/0吞吐量×磁盘数)×8÷网络带宽≈1

是比较平衡的选择。例如单个节点硬盘为8块7200转硬盘作为数据存储,每块硬盘读写速度预估在80-120兆之间,这样在发生集群数据拷贝的情况,需要的网络峰值带宽是960MB,万兆交换网络可满足要求。

  • 选择够用的CPU

大数据平台的基础原理是发挥分布式并行计算的优势,当配置CPU时,有两点建议,第一是建议计算节点间能力的平衡;第二也不建议购买高端芯片,以避免投资成本、维护成本的无谓消耗。当然这需要根据具体的业务需要来挑选合适的硬件,对于计算密集型应用,如聚类分类、复杂文本挖掘、自然语言处理、特征提取等,适当提高CPU的处理性能也是必要的。

  • l预留内存空间,优化带宽通道

大数据平台的大部分服务以JAVA开发,运行在JVM环境中,当计算需要多少内存的时候,Java本身要使用高达10%的内存来管理虚拟机。与CPU多线程配合,集群中节点间、节点内CPU间,CPU内线程间,每一个并发运行的程序以及参数和变量都需要占用JAVA堆栈。虽然因程序的不同吃掉内存的大小很难统一计算。但是从每节点总的线程数出发来考虑是一个可参考的思路。线程数越多,需要的内存越多。‘

调优是在既定硬件资源的情况下进行的,不同的硬件资源,相同的调优方法,取得的效果不一定相同。客户需要完全理解他们的工作负载,这样才能选择最优的硬件,为发挥大数据平台的性能优势打好基础。

三、系统资源的优化

大数据平台不是万能的,它的主要业务范围聚焦于统计分析、数据挖掘、机器学习,而操作系统在设计时,需要考虑的是对各种业务的支持,没有针对具体业务加以区分。从这个角度上讲,操作系统中对大数据主流业务没有帮助的特性,可考虑适当关闭。

  • 在操作系统上做减法

安装操作系统时,采用minimal安装。在此基础上只安装集群需要的服务。避免在数据节点的机器上使用LVM操作,规避可能的额外开销。在内存满足需要的情况下,关闭swap分区,提高进程的执行效率。

在数据节点上,使用noatime选项挂载磁盘,对文件的读取不再更新文件属性中的atime信息,提高服务器性能。

  • 进阶调优

增大同时打开的文件数和进程数,保证对大规模并行作业的支持设置合理的预读取缓冲区大小,改进磁盘读I/0根据应用特点选择合适的I/O调度器。内核修改,配合网络设备优化服务器与服务器间,服务器与客户端间的RPC通信。

四、集群资源参数的优化

集群资源参数需要依据各个服务自身的特点来进行,参数配置的结果,决定了是否可以将集群提供的性能资源充分动员起来。下面列举一些通用的资源优化方法。

  • 优化JVM的基础配置

JVM参数是各服务中较为通用的基本配置。大数据集群的主要服务都运行在JVM环境上,需要配置Java heap size的大小。内存资源如果分配过小,会发现程序响应速度变慢,GC占用了过多时间,应用分配到的执行时间变少。这在各服务的调优过程中是需要时刻关注的问题。

  • 优化并行度

在集群资源允许的范围内,尽可能增加任务的并行度,是大数据集群调优的核心思想。在以HDFS分布式文件系统为基础的集群中,HDFS的文件块大小是与并行度强相关的配置,它是MapReduce、SPARK等计算架构默认配置的处理数据的基本单元,可以通过调整文件块的大小使集群资源得到充分利用。

例如在标准的MapReduce+Yarn的Hadoop集群中,考虑极简情况:

  • 每节点可以运行计算任务的Container=CPU的线程数(超线程乘以2)
  • 每Container分配的内存=节点总内存÷Container数量

由此可以大致通过测试验证出,当HDFS的块大小≤Container内存的哪一种配置时,可以最大限度的发挥并行计算的优势。

在spark计算架构中,也是将任务分解成多个spark_worker_instance来处理,可以用相似的思路调整并行度和验证测试。

需要注意的是,这里提到的方法只是在极简情况下的简单推导,考虑每个程序计算复杂度对CPU的消耗,系统的额外开销,尤其是大数据任务大多分为多个并行阶段,对某一个阶段有效的配置不一定适用于全部阶段。因此真正的调优还是要通过深入分析任务流程,不断调整、测试验证来完成。

  • 合理配置压缩算法,将负载在磁盘I/0与CPU间调整

在大多数情况下,大数据集群的性能短板出现在磁盘I/0上,跟不上的磁盘吞吐量使CPU经常处于等待状态。在这种情况下,可以考虑调用CPU对数据进行压缩。此时压缩后的数据对于磁盘I/0的需求减少,同时增加了CPU的开销,这种任务分担的结果使性能在整体上获得了提升。

目前已有的压缩方式有:GzipCodec,LzoCodec,BZip2Codec等,它们对于压缩率、CPU的开销各不相同。可以根据集群中实际的CPU、磁盘使用情况恰当的选择。

  • 从全流程考虑,预先规避可能出现的额外资源开销

例如,在HBase中,可以配置预分Region建表,防止表增大后Region分裂带来的额外开销以及并行载入的瓶颈。

在MapReduce中,可以启动推测执行机制。当一个作业的某些任务运行速度明显慢于同作业的其他任务时,Hadoop会在另一个节点上为“慢任务”启动一个备份任务,这样两个任务同时处理一份数据,而Hadoop最终会将优先完成的那个任务的结果作为最终结果,并将另一个任务杀掉。

五、数据分布和存储的优化

数据在加载到大数据集群时,根据业务需求完成一定的预先处理可以极大的提升业务处理时的性能。

  • 数据分布的优化

数据倾斜是分布式架构的大忌。在执行具体业务前,根据大数据集群将计算推向本地的总体设计思想,做好数据分布,尽量使节点内数据业务强相关,节点间数据业务弱相关。这需要深入分析业务的执行计划和数据特点,例如结构化数据的表分布,Spark RDD中的键值对分布,有针对性的进行设计。

  • 对于结构化数据,恰当的数据分布尤为重要,将小表做成复制表,大表根据常用查询列,做成哈希分布表在各个节点上。
  • 对于非结构化数据,为防止多个任务并行读取一个文件内容造成瓶颈,用户可根据需要增加输入文件的副本数目。
  • 数据存储的优化

数据存储方式和数据存储类型都会对性能产生影响。

对于非结构化数据,选择恰当的存储格式,也会对提升性能有所帮助。例如在MapReduce中为应用程序处理的数据选择合适的Writable类型可大大提升性能。通过使用Text类型,比String类型在消除字符串拆分花更少的时间;处理整数类型数据时,直接采用IntWritable比先以Text类型读入在转换为整数类型要高效;若输出整数的大部分可用一个或两个字节保存,直接采用VIntWritable或者VLongWritable,利用此变长整型的编码方式,可以大大减少输出数据量。

六、应用开发的优化

应用开发是最具有灵活性的,考虑在不同层级,做好任务分解和并行,负载均衡,实现从上到下的顶层设计。

  • 防止任务倾斜

产生任务倾斜的原因较为隐蔽,一般源于服务器架构、JVM、线程池,执行计划的问题等。应用开发时,要注意检查和规避这种情况。

根据系统资源控制执行过程根据数据量、系统资源的实际情况,应用程序的处理流程可以不同。例如对于spark内存计算来说,原始数据在生成RDD后可能需要被多次调用,是否将RDD持久化,避免每次读取时从磁盘的重复调用,就需要根据数据量和系统资源来决定。若在程序中实现RDD持久化后,系统仍然有足够的资源供程序使用,会明显提升业务处理的性能。

序列化优化序列化对于提高分布式程序的性能起到非常重要的作用。一个不好的序列化方式(如序列化模式的速度非常慢或者序列化结果非常大)会极大降低计算速度。目前两个主要的序列化类库是Java序列化和Kryo序列化。前者被支持的更好,后者性能更好。可以根据实际情况来选择。

结束语

“阵而再战,军之所长,运用之妙,存乎一心”。不管是“一力降十会”,还是“四两拨千斤”,调优方法的选择来自于长时间经验的积累。随着开源社区对技术的不断推进,也会不断出现新的方法和工具。

名词解释:

RDD:Resilient Distributed Dataset,弹性分布式数据集,是Spark对于分布式数据和计算的基本抽象

GC:Garbage Collection,是Java检测和回收垃圾内存的机制

分享到
关闭