做ppt图片用的网站有哪些,网站设计好以后怎么上线,html入门,长春百度seo简介
针对高耗跑批时间长的作业#xff0c;在公司近3个月做过一个优化专项#xff1b;优化成效#xff1a;综合cpu、内存、跑批耗时减少均在65%以上#xff1b;
cpu和内存消耗指的是#xff1a;vcoreseconds和memoryseconds
这里简单说下优化的一些思路#xff0c;至于…简介
针对高耗跑批时间长的作业在公司近3个月做过一个优化专项优化成效综合cpu、内存、跑批耗时减少均在65%以上
cpu和内存消耗指的是vcoreseconds和memoryseconds
这里简单说下优化的一些思路至于优化细节之前写过两篇或可参考 sparksql优化https://blog.csdn.net/me_to_007/article/details/130916946 hive优化https://blog.csdn.net/me_to_007/article/details/126921955
运行环境yarn调度hdfs存储orc格式表hive2spark2.4.3
大家有什么经验也欢迎补充、指正
什么样的任务值得关注
一个作业运行时间很长就值得关注吗不一定如果一个用户把n段逻辑全都整到一个作业里不是太长跑批时耗在数仓规范范围内可能也是可接受合理的
这里将时间界限监控到stage层面对应hive就是每一个job在sparksql里就是每一个stage一个作业跑批时间很长可能是合理的也许是逻辑复杂由很多个stage构成但是一个stage跑批时间很长在分布式计算里一般不正常
hive的stage可以只有map逻辑也可以是一段mr、union、limit语句sparksql的stage则根据有无shuffle划分遇到shuffle宽依赖则新划分一个stage
这个时间界限可以根据经验及要求灵活设置比如要尽可能地提升作业跑批时效和节省结算资源那这个界限可以设置小点比如一个小时一般几十亿的数据join没有倾斜、发散一个小时也够了
另外一方面是监控内存配置hive里边的map和reduce内存配置sparksql里的executor内置配置这些参数都不应该设置过大每个task的内存界限可以设置到4个g hive里边map和reduce内存是单独设置的sparksql单个task的内存约等于单个executor内存/每个executor cpu核数 * 每个task跑批cpu核数这个参数默认是1一般不做额外设置
hive-map内存参数mapreduce.map.memory.mb hive-reduce内存参数mapreduce.reduce.memory.mb sparksql-executor内存参数spark.executor.memory sparksql-executor核数spark.executor.cores sparksql-每task-cpu核数spark.task.cpus该参数默认为1一般无需额外设置 spark-driver的内存如果有广播和cahe缓存需要配置大些可根据实际情况设置
配置自动监控
这里可以根据yarn日志编写定时调度脚本解析作业日志将符合异常规则的作业发邮件出来筛查也可配置短信接口通知作业属主整改
这里可以手工配置一个白名单作业如果已经审查无太大优化空间则加入白名单避开筛查当然这个白名单也可以设置特定的规则比如把时间和资源界限的上限配大点而不是无限放大避免白名单后界限无限放大
内存监控则直接读取作业配置参数即可如触发条件则发邮件到相关团队优化在我们这是数据治理组
耗时长有两种情况一种的倾斜导致的这种就解决倾斜另外一种每个task处理数据量都很大这类情况一般把task数量调大点再多给点资源日志解析也比较好处理倾斜监控作业各个stage中最大task耗时相比一般水平差异这个界限也可以按需配置比如我们这里设定为最大task跑批时长-上四分位时长 3倍四分差
数据倾斜是一个相对的概念准确地说每个作业都有倾斜但对于一些跑批时间比较短的作业至于整个数仓盘面来说优化提升不大这里可以在监控里筛跳过
当然至于个别业务团队视重要性个别对待有的作业对时效要求比较高比如涉及到重大活动数据那就做精细化优化
考虑到yarn日志文件比较大解析耗时集群作业比较多解析日志应有筛选地进行那些跑批时间相对短的作业或可暂时搁置同时配置白名单防止日志重复读取解析
怎么去定位问题SQL段
主要是结合执行计划定位在hive里面执行计划map-tree里显示的表名如果sql中有写别名则显示的是别名为防止筛查混乱难以定位sql中的表别名尽量不要使用相同的没有关联逻辑情况尽量不要使用别名
比如下面一段sql
select group_name,count(1) as cnt
from tablename -- 这里不写表别名
group by group_name在hive中直接使用explain sql字符串打印执行计划即可看看日志里哪个stage异常再根据执行计划去定位异常sql段落进而进行作业分析
explain select dt,count(1) as cnt from tablename group by dthive中如果有配置join倾斜参数(set hive.optimize.skewjointrue)或者groupby倾斜参数(set hive.groupby.skewindatatrue)如果作业stage倾斜会额外生成一个stage这里在执行计划里是看不到的这个stage紧跟运行在原来的stage后面
这里需要注意的是调度环境和我们查看执行计划的环境引擎配置可能会不一样我们通过执行计划查看的stage号可能跟实际作业跑批不一致这里尽量在同一环境下去查看执行计划
一方面我们也可以通过yarn里map日志的syslog日志去查看map读取的表名然后根据使用的表名大概定位到sql段如果当前stage的数据源都是来自前依赖stage reduce的output则日志里看到的是临时文件名而不是表名
sparksql同样的查看sparkui中stage对应的执行计划stage二级页面spark2.4.3中stage的执行计划不是很详细可以结合数据量算子然后在sparkui全局执行计划里去找定位sql语句段
如果是作业跑批失败在执行计划中体现为上游依赖stage全跑完了而这个stage没有打印执行数据sparksql执行计划每个stage跑完都会显示跑批时间及输出数据
大概的一些优化方向 优化sql 每一个作业就好比一个成型的积木而成型的积木可由不同积木块不同方式拼凑而成条条大路通罗马使用怎样的积木块表以及怎样的拼凑方式是我们一个优化介入点比如join顺序使用不同的表先聚合在join等视具体场景具体处理 增加stage的task个数 这类体现为某个stage跑批时间很长但是又没有倾斜可以适当增加stage的reduce个数这类现象一般出现在多维聚合、countdistinct数据膨胀多个表关联包括开窗用的是一个mr表关联join字段和开窗partitionby字段是同一个字段计算会优化收拢到一个mr里具体看执行计划join数据发散多对多 题外数据量大一定要reduce个数设置大些吗 不一定如果存在map预聚合且预聚合能显著减少数据量的有时候恰恰要手动把reduce配置少点在hive里可以指定reduce个数mapred.reduce.tasks亦可结合每reduce处理数据量hive.exec.reducers.bytes.per.reducerhive.exec.reducers.max动态配置reduce个数但这个数据量是map逻辑前的数据量如果有filter筛选需适当增加.bytes.per.reducer参数减少reduce个数sparksql则直接设置spark.sql.shuffle.partitions个数和动态分区参数spark.sql.adaptive.enabled即可 有的跑批时间长可能是自定义函数优化做的不到位这种情况优先使用内置函数或者找相关开发优化自定义函数字符串处理能不正则的尽量不要用正则 解决倾斜 如果遇到倾斜则按常规倾斜处理即可在具体实践中我们发现hive倾斜参数机制优化效果不一定比手动处理要好比如groupby倾斜参数set hive.groupby.skewindatatrue大多时候并不比手工处理要好这里可以手动打散试试就是麻烦点如果逻辑复杂改起来会很耗时hive的join的倾斜参数不适用于外连接这里需要注意下此外mapjoin不适用于外连接主表是小表的情况比如小表 left join 大表 开启并行 这里主要是针对于hive计算如果存在stage没有依赖查看执行计划可以开启并行执行参数set hive.exec.paralleltrue无依赖的stage可以并行执行比如union all上下逻辑子句join中嵌套的子句等 sparksql可以通过堆资源来减少跑批时间但一般不建议设置的总cpu核数大于并发task数量的1/2官方推荐是task的数据大于cpu总核数的三倍。比如有300个task那cpu总核数尽量设置在150以下。
在数据体量很大时我们发现sparksql的map stage耗时比较长这里可以根据实际情况切换合适的计算引擎
此外基于整个作业链路去优化目标作业跑批时效要基于关键链路去优化非关键链路作业优化对结果作业产出时间没有影响
countdistinct每一个distinct数据都会膨胀一倍如果countdistinct数量过多但去重的都是同一个字段只是条件不同时改写下sqlshuffle数据量可以显著减少
比如假设flag是一个标签字段字段值只有0和1
selecet group_name,count(distinct case when flag11 then id end) as dis_cnt1,count(distinct case when flag21 then id end) as dis_cnt2-- ,...,count(distinct case when flagn1 then id end) as dis_cntn
from tablename
group by group_name这里的数据有n个countdistinct数据膨胀n倍但让若我们这么改写
selecet group_name,count(case when flag11 then id end) as dis_cnt1,count(case when flag21 then id end) as dis_cnt2-- ,...,count(case when flagn1 then id end) as dis_cntn
(select group_name,id,max(flag1) as flag1,max(flag2) as flag2--,..,max(flagn) as flagnfrom tablenamegroup by group_name,id
) t
group by group_name如此数据没有膨胀只是多了一个mr成本而已需注意的是hive在开启优化后该改写可能会合并到一个mr里具体看执行计划需求改写
