Hive报错not in the vectorization context column map分析及解决方法

/*

先说结论,我不知道为什么报错,但是我知道怎么解决。抛砖引玉,期待高人指路。

*/

1.问题出现

近日,在提交下面这段Hive SQL时,会报出SemanticException错误

SELECT

? ? APP_TP? ? ? ? ? ? ? ? ? ? ? ? ? ? ? as APP_TP,

? ? TOUCH_TP? ? ? ? ? ? ? ? ? ? ? ? ? ? as TOUCH_TP,

? ? ext_card_attr_cd? ? ? ? ? ? ? ? ? ? as CARD_ATTR_ID,

? ? ext_card_brand_cd? ? ? ? ? ? ? ? ? as CARD_BRAND_ID,

? ? ISS_INTNL_ORG_ID_CD? ? ? ? ? ? ? ? as ISS_INTNL_ORG_ID_CD,

? ? ISS_ROOT_INS_ID_CD? ? ? ? ? ? ? ? ? as ISS_ROOT_INS_ID_CD,

? ? count(distinct pri_acct_no_conv)? ? as ACTIVE_CARD_NUM

from table_test_mon a

where trim(a.hp_settle_month) = '202402'

group by APP_TP? ? ? ? ? ? ?

? ? ? ? ,TOUCH_TP? ? ? ? ? ?

? ? ? ? ,ext_card_attr_cd? ? ? ?

? ? ? ? ,ext_card_brand_cd? ? ?

? ? ? ? ,ISS_INTNL_ORG_ID_CD

? ? ? ? ,ISS_ROOT_INS_ID_CD

union all

select

? APP_TP? ? ? ? ? ? ? ? ? ? ? ? ? ? ? as APP_TP,

? '0'? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? as TOUCH_TP,

? ext_card_attr_cd? ? ? ? ? ? ? ? ? ? as CARD_ATTR_ID,

? ext_card_brand_cd? ? ? ? ? ? ? ? ? as CARD_BRAND_ID,

? ISS_INTNL_ORG_ID_CD? ? ? ? ? ? ? ? as ISS_INTNL_ORG_ID_CD,

? ISS_ROOT_INS_ID_CD? ? ? ? ? ? ? ? ? as ISS_ROOT_INS_ID_CD,

? count(distinct pri_acct_no_conv)? ? as ACTIVE_CARD_NUM

from table_test_mon a

where trim(a.hp_settle_month) = '202402'

group by? APP_TP? ? ? ? ? ? ?

? ? ? ? ,ext_card_attr_cd? ? ? ?

? ? ? ? ,ext_card_brand_cd? ? ?

? ? ? ? ,ISS_INTNL_ORG_ID_CD

? ? ? ? ,ISS_ROOT_INS_ID_CD;

错误信息是

Error while compiling statement: FAILED: SemanticException org.apache.hadoop.hive.ql.metadata.HiveException: The column KEY._col6:0._col0 is not in the vectorization context column map {KEY._col0=0, KEY._col1=1, KEY._col2=2, KEY._col3=3, KEY._col4=4, KEY._col5=5, KEY._col6=6}. (state=42000,code=40000)

2.原因分析

第一次看见这个报错时,我是十分疑惑的,因为这段SQL并不复杂,只是简单的group by、count,最后将两端结果union all连接在一起。另外KEY._col0、KEY._col1等名称不是常规的字段名、表名,从字面上看不出什么端倪。我猜想这可能是执行计划中的临时别名,于是我对union all前面的一段SQL查看执行计划,发现其中有下面这一段

Reducer 2

? ? Needs Tagging: false? ? ? ? ? ? ? ? ?

? ? Reduce Operator Tree:? ? ? ? ? ? ? ? ?

? ? ? Group By Operator? ? ? ? ? ? ? ? ? ?

? ? ? ? aggregations: count(DISTINCT KEY._col6:0._col0)

? ? ? ? keys: KEY._col0 (type: string), KEY._col1 (type: string), KEY._col2 (type: string), KEY._col3 (type: string), KEY._col4 (type: string), KEY._col5 (type: string)

? ? ? ? mode: mergepartial? ? ? ? ? ? ? ?

? ? ? ? outputColumnNames: _col0, _col1, _col2, _col3, _col4, _col5, _col6

? ? ? ? Statistics: Num rows: 997 Data size: 183055 Basic stats: COMPLETE Column stats: NONE

? ? ? ? File Output Operator? ? ? ? ? ? ?

与报错信息对比,可以得出KEY._col6:0._col0是DISTINCT.pri_acct_no_conv的别名,而KEY._col0~KEY._col5是select从句中其他的六个字段。而执行计划中的outputColumnNames(reduce阶段输出的键值对的key名)则是_col0, _col1, _col2, _col3, _col4, _col5, _col6,没有_col6:0._col0,这就是The column KEY._col6:0._col0 is not in the vectorization context column map的字面解读。

但是经过上面的简单翻译,还是不明白为什么会报错。所以我将union两端SQL中的distinct去掉,再次查看整段SQL的执行计划。发现其中有下面这一段

Reducer 2

? ? Execution mode: vectorized? ? ? ? ? ?

? ? Needs Tagging: false? ? ? ? ? ? ? ? ?

? ? Reduce Operator Tree:? ? ? ? ? ? ? ? ?

? ? ? Group By Operator? ? ? ? ? ? ? ? ? ?

? ? ? ? aggregations: count(VALUE._col0)?

? ? ? ? keys: KEY._col0 (type: string), KEY._col1 (type: string), KEY._col2 (type: string), KEY._col3 (type: string), KEY._col4 (type: string), KEY._col5 (type: string)

? ? ? ? mode: mergepartial? ? ? ? ? ? ? ?

? ? ? ? outputColumnNames: _col0, _col1, _col2, _col3, _col4, _col5, _col6

? ? ? ? Statistics: Num rows: 997 Data size: 183055 Basic stats: COMPLETE Column stats: NONE

? ? ? ? File Output Operator? ? ? ? ? ? ?

执行计划中加粗的一行表明这一个reduce阶段是以向量化查询的方式执行(Vectorized Query Execution)。Hive wiki上对向量化查询执行的解释(https://cwiki.apache.org/confluence/display/Hive/Vectorized+Query+Execution#app-switcher)是

向量化查询执行是Hive的一项功能,可大大减少典型查询操作(如扫描,过滤器,聚合和联接)的CPU使用率。标准查询执行系统一次处理一行。这在执行的内部循环中涉及长代码路径和重要的元数据解释。向量化查询执行通过一次处理一个1024行的块来简化操作。在该块内,每一列都存储为向量(原始数据类型的数组)。诸如算术和比较之类的简单操作是通过在一个紧密的循环中快速迭代向量而完成的,循环内没有或只有很少的函数调用或条件分支。平均而言,这些循环以精简的方式编译,使用相对较少的指令,并以较少的时钟周期完成每条指令,通过有效地使用处理器管道和高速缓存。

所以我猜想问题出在向量化执行上面。union all两端的SQL都分别可以顺利执行,但是union all到一起就不行。推测是在union all的过程中自动触发了向量化执行优化,尝试将两端的SQL group by的结果拼接到一起组成batch,过程中编译器突然发现聚合函数之外本来应该只有六个字段,即KEY._col0~KEY._col5,有5个键。而此时眼前却分明还有一个distinct出来的KEY._col6:0._col0,故无法顺利将每一列都转化为向量,遂报错。而如果去掉distinct,count的结果是VALUE._col0,是键值对中的值,不会增加键的个数,于是可以顺利执行。

注:以上都是我瞎想的。

3.解决方法

推测出了大概原因,那么我们可以通过关闭向量化执行来解决问题,以下语句亲测可用。

set hive.vectorized.execution.enabled = false;

另外,如果是Hive on spark报出以上错误,还可以将引擎切换为MapReduce试试,我也试过可以用。

set hive.execution.engine=mr;

上网搜一搜,发现其实也有人提出了类似的问题(https://community.cloudera.com/t5/Support-Questions/hive-vectorization-union-all-problem/m-p/183179),但是一直没有人正面解答。在hive社区中,有一个类似问题作为bug被提出https://issues.apache.org/jira/browse/HIVE-17978,其中一名开发者表示

在后续操作中,我们将允许合并两个都具有半联接分支的TS。此外,我们应该考虑在删除半联接分支之后运行共享工作优化器。

页面显示该问题会在Hive3.0中修复,期待公司升级为Hive3.0的时候。

唉,我还是太菜了,要继续学习啊。