场景描述,
一个普通的sql,因为查询条件过多,导致task一直在filter, 假死的状态。spark的版本为spark-2.3
sql语句
CREATE TABLE `temp.tmp_st_loan_bfm_crdamt_slast_xray20210727`(
`userid` bigint,
`flag_type` string,
`score_bairong` bigint,
`bfm_used_rate` double,
`lrm_credit_amt` bigint,
`r3` int,
`r4` int,
`r5` int,
`r6` int,
`r8` int,
`r9` int,
`r10` int,
`r11` int,
`r12` int,
`r13` int,
`r14` int,
`r15` int,
`r16` int,
`r17` int,
`r18` int)
ROW FORMAT SERDE
'org.apache.hadoop.hive.ql.io.orc.OrcSerde'
STORED AS INPUTFORMAT
'org.apache.hadoop.hive.ql.io.orc.OrcInputFormat'
OUTPUTFORMAT
'org.apache.hadoop.hive.ql.io.orc.OrcOutputFormat'
TBLPROPERTIES (
'transient_lastDdlTime'='1627429670');
select
*
from
temp.tmp_st_loan_bfm_crdamt_slast_xray20210727
where
r3 = 1
and r4 = 1
and r5 = 1
and r6 = 1
and r8 = 1
and r9 = 1
and r10 = 1
and r11 = 1
and r12 = 1
and r13 = 1
and r14 = 1
and r15 = 1
and r16 = 1
and r17 = 1
and r18 = 1
查看执行计划
发现过滤条件除了判断eq,还判断了每个值不等于空。 另外一个点是过滤条件使用了下推功能。 
查看driver中threaddump日志。

发现在OrcFilters.createFilter这段代码之后,后续代码一直在循环,长达8mins,
查看OrcFileFormat类
发现这段代码其实走了orc过滤条件下推的功能(set spark.sql.orc.filterPushdown=true 
查看OrcFilters
这个类的意思就是把Filter树结构进行一个解析, 初步确认为spark的bug,在嵌套比较多层次的时候,会比较慢,但是具体慢的原因,暂时没有找到,对比了一下spark-2.4, 其实并没有太大差异。 
查看执行计划

解决方案
添加配置
- set spark.sql.orc.filterPushdown=false; 不使用过滤条件下推功能。
- set spark.sql.hive.convertMetastoreOrc=false; 不使用矢量化读取orc文件的功能。
这两个配置在spark-2.4都是默认打开的,和spark-2.3有一定的差异。这个后面再补充。
|