电竞之家_品味电竞生活移动版

原标题：Hive 0.13到Hive 2.1跨版本升级全姿势与避坑指南

Hive是业界大数据平台使用最广泛的SQL引擎，提供了一层SQL抽象接口和一套元数据规范， 将SQL查询翻译为分布式的计算作业，支持MapReduce/Spark/Tez等多种计算引擎。同时Hive定义的元数据标准已经成为了一种事实标准，业界流行的大数据SQL引擎均对Hive元数据进行了兼容和支持。

前一段时间我们团队对Hive进行了一次从0.13版本到2.1版本的跨版本升级，升级期间遇到了一些问题， 但基本做到了可灰度、可控制和升级期间稳定性保证，同时服务不停这个属性通过我们的分析和实践也可以达到。本文详细介绍一下我们在升级过程前后遇到的一些问题和解决思路，以供大家参考。

平台使用背景

深度使用Hive的各项服务。

生产环境每天SQL查询总量80000+，包含 各种正常的和奇葩的SQL语法和元数据存储。

同时使用Spark和Hive进行ETL，使用Presto、Kylin和Spark进行Adhoc查询加速。

下面从元数据、语法兼容性、Hive2.1新功能、UDF兼容性、Hive2.1的一些不足等几个方面， 来讨论下升级注意事项和升级期间踩过的一些坑。

一、元数据

Hive元数据是Hadoop平台的核心数据，如果只是使用Hive提供的Hive Schema Tools来进行元数据Schema升级的话，整个升级过程是黑盒，并不利于精确控制，在深度使用场景下还有可能爆各种奇葩错误。

例如：如果你同时在用Spark，那么元数据VERSION表中的版本可能被修改为1.2.1（实际版本是0.13），如果使用HiveSchemaMetaTools时候参数不注意设定，这货是会从1.2.1版本开始执行升级脚本，最后会一部分升级脚本成功，一部分失败，然后结果你懂得。

所以首先需要对Hive元数据从0.13到2.1的Schema升级脚本进行详细分析，再确定具体升级方式。

0.13到2.1的元数据Schema升级脚本，位于${HIVE_HOME}/metastore/s/upgrade/${DB_TYPE}/文件夹内，一共17个子升级脚本和对应的issue。

通过查看每一个脚本明细SQL、对应的issue信息以及适用场景，可以将Schema升级脚本分为以下几类：

1、建议升级：hive-13076（涉及到建表和修改表操作）

从代码分析上看不影响Hive正常操作，但是修改内容涉及到建表和修改表操作。另外，这个脚本的升级内容是一个建表操作，不涉及到修改数据库表操作，所以风险较小，建议在灰度2.1客户端之前先进行升级操作。

这个升级目的是让Hive支持表级别主键和外键，从而可以在CBO时候优化join的执行计划。目前社区完成了主键和外键的语法支持和存储，而CBO使用主键和外键功能还处理未开发状态。

Hive 2.1支持的新语法：

2、事务(Hive Transaction)相关修改（不启用Hive事务则不需要升级）

默认事务是不启用的，当通过配置启用Hive事务时候使用到。Hive事务的应用场景比较有限。

5. hive-12807

6. hive-12814

7. hive-12816

8. hive-12818

9. hive-12819

10. hive-12821

11. hive-12822

12. hive-12823

13. hive-12831

14. hive-12832

16. hive-13395

17. hive-13354

3、Hcatalog相关修改（不使用Hcatalog则不需要升级）

增加NOTIFICATION_LOG和NOTIFICATION_SEQUENCE表。支持hcatalog metastore notification机制。

2. hive-9296

4、其它非关键修改（一些特殊场景使用到）

1. hive-7784: 给`PART_COL_STATS`表增加索引，加快CBO查表速度。

3. hive-7018: 删除`TBLS`和`PARTITIONS`表在0.10后不用的`LINK_TARGET_ID`列。 0.13版本schema本身就不含有这个列。Oracle可能会遇到这个问题。不建议执行，因为这个操作危险性比较大。

4. hive-11970: 增加`COLUMNS_V2`等表的`COLUMN_NAME`列名长度到767，防止某些特殊情况例如Avro导出表情况下列名超过128个字符。一般情况遇不到。

5、总结

通过上述分类分析可知，0.13到2.1版本的元数据基本完全兼容，根据公司具体场景进行部分升级即可。

例如，如果不使用以上提到的Hive事务、Hcatalog、Avro导出等特殊功能，完全可以做到只升级Hive相关程序不升级元数据也没有使用问题。 但需要做以下前提工作：

关闭元数据VERISON校验相关功能

设置hive.metastore.schema.verification=false。必要时候修改代码，禁用Hive自身的Check机制。

配置禁止JDO框架来自动更新元数据schema

设置datanucleus.fixedDatastore=true和datanucleus.autoCreateSchema=false。

二、语法兼容性

Hive版本升级后，给人的感觉是语法要求越来越严格，越来越接近于ANSI SQL标准，所以很多在0.13可以跑成功的SQL，到了2.1会报错。 下面总结升级过程中遇到的一些语法兼容性问题。

1、Hive新增保留字问题

Hive随着版本变迁，保留字越来越多。 保留字的详细情况可以参考：Hive各个版本的保留字。

https://cwiki.apache.org/confluence/display/Hive/LanguageManual+DDL#LanguageManualDDL-Keywords,Non-reservedKeywordsandReservedKeywords

保留字问题有以下两种：

新增预留字

新的版本Hive会预留更多保留字，如果SQL用到产生语法问题，可以通过参数设置set hive.support.sql11.reserved.keywords=false来取消保留字校验， 达到不需要修改SQL，又能保证线上SQL稳定运行的兼容效果。

新增关键字

当SQL中含有Hive2.1中新增的关键字时候，只能修改SQL进行兼容了，需要将与关键字冲突的属性名用反引号包围。 新版本增加的关键字有：OFFSET、SUBQUERY、REWRITE、PRIMARY、FOREIGN、KEY、 REFERENCES、CONSTRAINT等。

2、其它兼容性问题和解决方法

（1）hive.开头的参数如果不在Hive2.1预定义配置中（可能已经被移除），或者大小写不对，set语句会直接报错。

例如：set hive.auto.convert.JOIN=true，大小写不对，执行会报错。解决方法：规范化语句，或者关闭强制校验参数。

（2）建表时不指定列的具体类型，在2.1会直接报错。

例如：

create table test_table_null_no_type as select null as id, "zhangsan" as name;

解决方法：规范化SQL，指定具体的列类型。

（3）通过函数等运算产生的列，没有指定明确的别名，在2.1会偶尔报错。

例如：

select id, `_c1` from (select id, get_json_object(deliver_geojson,'$.features') from tb) a

解决方法：规范化SQL，指定有业务含义的别名，不以下划线开头。

（4）在使用windows函数时，当列名在多个表都存在时，不指定列所属表，在2.1会报错。

例如：

select row_number() over(partition by user_id order by a.log_time desc) rank from a join b on a.id = b.id;

其中user_id在a表和b表中均存在。

解决方法：规范化SQL，指定列所属表名。

（5）在使用union all时，union起来的多个查询，含有orderBy、clusterBy、distributeBy sortBy、limit语法在2.1会报错。

例如：

select 1 from default.dual limit 1 union all select 2 from default.dual limit 1;

解决方法：只允许在最后一个语句中含有orderBy、clusterBy、distributeBy sortBy、limit语句。

（6）使用windows函数时，窗口的上限和下限必须大于0，否则在2.1会报错。