计算优化

中台 数据优化  收藏
0 / 348

image.png

一、前言

   贝贝大数据平台发展到今天已经有350+台机器的规模,但随着业务的发展,数据量的增长和数据需求的增加,导致集群需要面对每天15000+任务的挑战,资源紧张的问题日益凸显。为了保障数据的按时产出,在物理扩展的预算有限的情况下,贝贝大数据平台灯塔计划应运而生。灯塔计划旨在于构建面向大数据平台的,自动化,智能化的任务优化平台。通过优化mapreduce任务的计算资源消耗,尽可能的让资源有效的使用起来,从而来提高集群资源的使用率。

   当前整个大数据平台的任务均运行在统一的配置环境中,而统一的配置并不能满足个性化任务的实际需求,在日常开发和维护过程中,经常发现任务配置资源过剩,无法实际利用的情况。因此针对不同的任务给予不同的配置是势在必行的,通过自动化的方式测算任务实际需要的资源,并给予相应调整后的配置,让任务可以真正的“经济适用”,这是整个灯塔计划的基本思路。

二、服务架构

   本系统主要是基于大数据集群hive组件进行构建的,分为筛选,优化,验证和评估四个部分,分别对应四个优化阶段。需要依赖的外部系统是调度系统,所有的优化对象都是调度系统中的hive任务,而优化的部分是hive转换成的mapreduce任务。优化所需要的计算资源数据全部来自于owl数据库,该数据库采集了整个大数据平台中各个组件的元数据与运行数据。

image.png

三、优化技术原理

   本系统进行优化的理论基础是基于yarn内存分配机制,通过计算出合理的内存参数来实现的。

image.png

   NodeManager是yarn的执行服务节点,container的上限不能超过nodemanager的最大值。因此yarn.nodemanager.resource.memory-mb参数决定来当个节点可以分配资源的上限,任何单个任务的内存分配理论上限为yarn.nodemanager.resource.memory-mb的值。

   Yarn container是yarn分配资源的基本单位,container的最大上限是由yarn.scheduler.maximum-allocation-mb参数决定的,而实际分配的值是由任务申请,并由resourcemanager批准的值,而申请值是由mapreduce的内存配置参数mapreduce.map.memory.mb和mapreduce.reduce.memory.mb决定的,该参数值在mapreduce启动前就已经决定。真正运行任务的jvm的内存大小是由mapreduce.map.java.opts和mapreduce.reduce.java.opts两个参数决定的,这取决于实际任务对内存的需求。

   这个内存分配体系存在一定的缺陷,即当container分配后,不管任务是或实际使用了内存资源,都需要等到任务运行结束或异常退出后,才能通知resourcemanager回收资源。大部分情况下mapreduce.map.memory.mb>mapreduce.map.java.opts和mapreduce.reduce.memory.mb>mapreduce.reduce.java.opts,甚至有时候是远大于,这会导致资源浪费的问题,因为这部分内存即使未实际被使用,但因为yarn内存分配机制,这部分内存在任务运行期间无法分配给其他任务使用,这对负载高的集群会有很大的影响。另外一方面,根据mapreduce.map.java.opts和mapreduce.reduce.java.opts参数启动的jvm在运行任务时,同样也会出现申请的值和实际使用值差距很大的问题,同样也会造成资源浪费。

   根据container和jvm两个层面的内存分配机制,若无法合理的设置参数,会出现严重的内存资源浪费。

image.png

图一为实际物理内存使用情况

image.png

图二为yarn分配内存使用情况
   图一是集群中所有350台机器的物理内存使用情况,可以看出即使在0-8点集群任务计算的高峰期,使用负载并不是很高,而图二为yarn上的内存分配使用情况,可以看到0-8点高峰期资源很紧张,同时该时期还有很多任务因无法分配到资源,而处于等待的状态。

   通过两张图的对比,可以看出大量的内存资源并未被合理的使用起来,但在yarn端确出现资源紧缺的情况,本系统的重点优化部分就是图中的差值。(GAP 很大,资源利用率在 20-30%)

四、实现流程

image.png

   本系统的基础流程是一个拥有筛选,优化,验证和评估四个阶段的生态闭环。

1、筛选阶段

   筛选阶段是整个流程的开始,作为第一个阶段,筛选顾名思义是要对任务进行基于条件的过滤行为。该阶段主要是选出符合优化条件的任务,因为每个任务的配置参数,数据量,计算逻辑都不相同。根据任务实际情况,并不是每个任务都可以进行优化或者说优化后可以产生明显的正向收益。所以我们要将不合适的任务过滤出来,只让适合本系统优化的任务进入到下一个阶段。

2、优化阶段

   优化阶段是通过接收从筛选阶段出来的任务,这部分符合优化条件的任务,会在该阶段基于自身的计算资源数据,通过选择合适的优化模型,来计算出优化后的配置参数,这部分参数会保存在系统的数据库中,方便后续配合调度系统的使用。完成优化参数生成后,任务才可以进入下一个阶段,若发生必要数据的缺失,或者模型无法计算出有效的结果,任务将会被判定成无法优化而退出整个流程。

3、验证阶段

   验证阶段会通过选取完成上一个阶段的任务,来发送到调度系统,通过生成试跑实例,来验证任务是否在优化后可以正常运行。为了保证当日的计算与数据不受影响,试跑实例使用的是三天前的数据,并且验证时间段选择在白天进行,白天集群资源相对充裕,且重要的任务相对较少,对平台正常任务运行的影响较小。验证阶段会让试跑实例在调度系统上运行完成后,会获取运行的结果去判断验证是否成功。小部分任务可能会出现,添加优化参数后,任务无法正常运行的情况,若出现该情况,系统会标记该任务为验证阶段失败,然后让任务推出整个优化流程,该机制主要是保证优化后的任务可以正常运行,防止异常任务上线导致集群稳定性问题和数据产出问题。只有验证结果正常的任务才可以进行下一个阶段。图三为灯塔系统与调度系统交互流程,该流程为验证阶段的核心交互。

image.png

图三灯塔系统与调度系统交互流程

4、评估阶段

   评估阶段是整个流程的最后一个阶段,该阶段只会选取上个阶段验证正常的任务,将其发布到线上进行正式的运行,每天任务运行的计算资源数据会被采集下来,保存在数据库中,以对比优化前后的差异和评估优化的实际效果。该阶段若出现任务变更,任务失败等异常情况,系统会标识任务的状态,并让其自动退出整个优化流程。若其中有适合二次优化的任务,会通过优化模型调整参数后重新进行优化,即会重新进行优化阶段,验证阶段,评估阶段,直到其正常运行或者不在适合优化而退出整个流程。评估阶段是有时间限制的,当到达评估截止时间后,任务会被标记正常结束了评估阶段,正常退出整个流程。

   本系统是一个生态闭环,即在上一个流程的评估阶段完成后,任务会进入到下一个流程,循环往复。一个流程的时间长度为30天,完成30天的流程后,任务会自动进入到下一个30天的优化流程中。这样的设计主要是针对任务数据量的变化,因为随着时间的推移,任务即使计算逻辑未进行修改,但数据量会随业务发展而增加,故优化需要在一定时间段后,再次进行调整。

五、优化模型详解

image.png

表格一为本系统采用的3种优化模型

1、map数量优化

   map数量优化模型是基于控制map数量来实现的优化方式。因为map阶段,task是按数量去申请资源的。比如100个map的任务,需要申请100个map的资源,假设每个map申请1GB资源,总共需要申请100GB资源。但在集群实际计算中,通过分析资源消耗的数据和任务运行的数据,可以发现大部分情况下任务并不需要1GB的资源,实际利用率比较低,大量资源被浪费。这时将100个map的申请削减至50个时,即仅仅只需要申请50GB资源即可。当然每个任务的数据量与计算逻辑不同,实际需要的资源也千差万别,因此通过全局设置一个统一的map内存配置大小,并不十分的合理,通过每个任务的实际情况计算出合理的map数量是比较科学的方式。这种方式唯一的问题是当map数量减少时,任务计算可能会变慢,因为计算并大量被降低,因此控制map数量需要在一个合理的区间内。详见图四图五为优化前后的内存占用示意图。

image.png

图四优化前Map数量为4

image.png

图五优化后Map数量为2
   通过对比图四与图五可以发现,减少两个map可以节约2GB的资源,而计算本身的预定目的同样可以达成。

2、map内存优化

   map内存优化模型是基于调整map内存配置大小来实现的优化方式。假设每个map需要1GB的内存资源,当发现资源浪费时,降低到每个map512MB,同样可以节省50%的资源。但与map数量优化模型不同的是,当map的内存配置值被降低,内存容错的空间同时变小,当数据量突增时,会出现map task oom的情况,这时会导致整个任务失败,这是一个十分致命的问题。而优势在于减少每个map的内存配置大小,并不会减少map的数量,即计算并发量不会减少,因此任务计算速度理论上不会受到太大的影响。

3、reduce内存优化

   reduce内存优化模型同map内存优化模型原理相同,都是通过降低内存配置值来实现资源优化。不同的地方在于,reduce是计算聚合端,相对map端而言,受数据量波动影响较小,因此该种优化方式带来的oom风险较小,故在reduce阶段,这是目前最优的优化方式。详情见图六图七为优化前后的示意图。

image.png

图六优化前内存占用

image.png

图七优化后内存占用
   通过图六图七的对比可以看出,内存整体优化了512MB,任务仍然可以正常运行,集群中有成千上万的任务可以进行优化,从而节约相当客观的资源。

   综合分析map数量优化模型和map内存优化模型,可以发现都有各自的优缺点,需要根据不同的情况去选择使用,任务规模的大小不同,对不同模型的优化效果也不同。合理选择模型是本系统优化的关键所在。

六、在贝贝的运用

   目前贝贝大数据平台灯塔计划,通过两期的建设,已经收到初步的成效,目前已累计优化整体资源的15%,约为公司节省服务器资源50+台。且优化对象不局限于历史存量任务,由于系统为周期性的优化方式,故当新任务进入大数据集群后,经过一段时间,也会被灯塔平台所优化。平台还提供了可视化界面,方便优化情况的查询与提高维护的效率。

七、未来展望

   目前灯塔计划仅针对与mapreduce任务,在我们贝贝的大数据集群中还存在spark引擎,随着spark使用推进的深入,自动化任务转化,包括对spark任务的优化等,都是平台未来建设的重要方向。除此之外,不仅仅优化的方式可以通过这种自动化的系统来实现,故障自愈也是一个探索的方向,在很多大厂都有故障自检与自愈的相关系统服务,特别是一些简单,常见,重复性的问题,可以提供规范化,自动化的解决方案,减少人力成本,提高服务稳定性,都有很大的益处。

   在未来,灯塔平台会朝着更加自动化,覆盖更广阔的范围,提供更多的功能,建设一个自动化的任务优化,故障自愈等多样化功能的大数据集群综合辅助平台而努力。