Hive升级全姿势

Hive0.13到2.1跨版本升级全姿势

前一段时间我们团队对Hive进行了一次从0.13版本到2.1版本的跨版本升级，升级期间也遇到了一些问题，
但是基本做到了可灰度、可控制和升级期间稳定性保证。不停服务这个属性通过本文分析也可以达到，
但是我们的场景下接受服务暂停，所以停服务花了一个小时来进行最终的升级。

使用背景：

1. 深度使用Hive的各项服务。
2. 线上每天SQL总量80000+，包含各种正常的和奇葩的SQL语法。
3. 同时使用Spark和Hive进行ETL

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

1. 元数据

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

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

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

0.13到2.1的元数据Schema升级脚本，位于${HIVE_HOME}/metastore/scripts/upgrade/${DB_TYPE}/文件夹内。
一共17个子升级脚本和对应的issue，通过查看每一个脚本明细SQL，和对应的issue信息以及适用场景，
可以将schema升级脚本分为以下几类：

升级脚本归类明细请参考附录，我们元数据使用MySQL数据库，使用其他类型数据库例如Oracle，升级脚本有细微差别，请仔细review升级脚本。

1.1 建议修改：hive-13076（涉及到建表和修改表）

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

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

Hive2.1支持的新语法：

CREATE TABLE vendor( vendor_id int, PRIMARY KEY (vendor_id)  DISABLE NOVALIDATE RELY);

CREATE TABLE product ( product_id int, product_vendor_id int,
    PRIMARY KEY (product_id)  DISABLE NOVALIDATE,
    CONSTRAINT product_fk_1 FOREIGN KEY (product_vendor_id) REFERENCES vendor(vendor_id)
    DISABLE NOVALIDATE
);

ALTER TABLE table2 ADD CONSTRAINT pkt2 primary key (a) disable novalidate;
ALTER TABLE table3 ADD CONSTRAINT fk1 FOREIGN KEY ( x ) REFERENCES table2(a) DISABLE NOVALIDATE RELY;
ALTER TABLE table6 ADD CONSTRAINT fk4 FOREIGN KEY ( y ) REFERENCES table1(a) DISABLE NOVALIDATE;

1.2. 事务(Hive Transaction)相关修改（不启用Hive事务则不需要）

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

5. hive-12807
6. hive-12814
7. hive-12816
8. hive-12818
9. hive-12819
107. hive-12821
11. hive-12822
12. hive-12823
13. hive-12831
14. hive-12832
16. hive-13395
17. hive-13354

1.3. Hcatalog相关修改（不使用Hcatalog则不需要）

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

2. hive-9296

1.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个字符。一般情况遇不到

总结

通过分析可以知道，0.13到2.1的元数据基本完全兼容，根据公司具体场景进行局部升级即可。
例如，如果不使用以上提到的事务、Hcatalog、Avro导出等特殊功能，完全可以做到只升级程序不升级元数据也没有使用问题。
但是前提是：

1. 关闭元数据VERISON校验相关功能：设置hive.metastore.schema.verification=false。必要时候修改代码，禁用Hive自身的Check机制。
2. 配置禁止JDO框架来自动更新元数据schema：设置datanucleus.fixedDatastore=true和datanucleus.autoCreateSchema=false。

2. 语法兼容性

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

2.1 Hive新增保留字问题

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

保留字问题有以下两种：

2.1.1 新增预留字

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

2.1.2 新增关键字

当SQL中含有Hive中的关键字时候，只能修改SQL进行兼容了，需要将与关键字冲突的属性名用反引号包围。
新版本增加的关键字请参考附录1。

2.2 其他兼容性问题和解决方法

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

例如：set hive.auto.convert.JOIN=true执行会报错。

解决方法：规范化语句，或者关闭强制校验参数。

1. 建表时候不指定列的具体类型在2.1会直接报错。

例如：

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

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

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

例如：

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

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

1. 在使用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，指定列所属表名。

1. 在使用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语句。

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

--错误信息：SemanticException Window Frame Boundary Amount must be a positive integer, provided amount is: 0
select order_date  ,order_date_new ,restaurant_id ,phone_1 ,count(phone_1)
    over(PARTITION BY restaurant_id,phone_1 order by days range between 0 preceding and 30 following) buy_num
from tb01;

解决方法：规范化SQL，避免窗口函数上限和下限为0，例如将0 preceding修改为current row

1. case when类型不一致，在2.1会报错

解决方法：将case when里类型转换为一致。

2.3 总结

语法兼容性问题，可以提前拿到线上一段时间的SQL语句，启动一个2.1版本的HiveServer2，
然后去批量Explain去校验是否存在语法兼容性问题，从而把问题解决到事前。
我们这边的做法通过客户端自定义的Hook和Dr-elephant等工具能很方便的拿到线上所有的SQL语句，
同时将获取线上SQL、批量Explain检查、错误分析等步骤，融合成一个Hive/Spark新功能上线前的回归测试工具来使用。

3. Hive2.1新feature

3.1 ORC&Parquet

Hive0.13对于2.1产生的ORC文件，存在读取兼容性问题。

hive2.xx之前，ORC存在一个UGI错误的bug比较严重，在HiveServer2里会遇到，
原因是ORCReader使用了多线程加载ORC文件的footer，而UGI的机制是不能跨线程的。相关issue：

另外hive2.xx之前，Parquet也存在诸多的bug。可以参考社区相关的issue。

文件格式的选择上，目前可参考的范例有：

• Uber: Parquert + snappy
• Linkedin: ORC + zlib
• Didi: ORC + zlib
• GrowingIO: ORC + zlib

我们倾向于主要文件格式选择parquet，因为ORC和Parquet测试下来速度差不多，但是Spark对于ORC的支持比较不好。

至于压缩算法的选择，我们倾向于对不同场景选择不同的压缩算法，
例如对数仓的ODS层，数据量很大，使用频率很低，考虑使用zlib压缩算法，达到最高压缩比。
而DM层，数据量小且访问频率高，则考虑使用snappy压缩算法，在压缩比和解压缩速度之间取一个tradeoff。
目前文件格式和压缩算法的选择正在测试上线阶段。

3.2 CBO

目前我们还在测试阶段。原因是CBO会在某一些SQL语句解析时候报错Assert Error。
另外CBO的适用场景主要在于Join顺序的选择上，这个还需要在自己的线上场景上进行测试一番。

3.3 向量化执行

Hive的向量化执行目前只支持ORC文件格式，Parquet支持正在开发。在文件格式推广前效果不大。

3.4 Hive On Spark/Tez

目前看来社区还不成熟，目前发现只有Uber在维护和使用。

Tez目前更加冷清，之前用过一些效果还是很不错的，但是一直没有火起来。

我们的方法是用SparkSQL来加速部分的ETL语句，目前我们已经把SparkSQL
对原来HiveSQL的语法兼容性和运行成功率做到92%+，这样让我们的线上ETL SQL可以更加平滑低成本进行迁移。

我们在Spark上进行的一些工作会有专门文章进行详细介绍。

3.5 其他

Hive2.1提供了大量的bug修复。除了上面提到的还有：

1. HiveServer2的Heap和PermGen内存泄露问题。
2. 大量存储类型bug修复。参考社区的issue list。

4. UDF兼容性

1. trim函数在2.1不支持string之外的类型。

0.13支持，但是2.1不支持，想要兼容的拷贝0.13代码就可以解决。

1. date_add和date_sub函数2.1和0.13返回的类型不一致

2.1之前返回String类型，2.1之后返回date类型。如果where语句中有data_add函数与String比较，可能导致数据查询不出来。
想要兼容的话，可以回滚到0.13版本的date_add和date_sub代码。具体请参考HiveUDF Date Functions

5. Hive2.1存在的一些问题

5.1 Hive Schema Version问题

如果元数据与Hive版本不同步升级，或用到Spark，因为Spark依赖的Hive默认是1.2.1。所以元数据也中的VERSION表，
会被改来改去，导致各种报错，例如：MetaException(message:Hive Schema version 2.1.0 does not match metastore's schema version 1.2.0 Metastore is not upgraded or corrupt)

一种方法是设置hive.metastore.schema.verification=false。

还有一种彻底的方法是把Hive启动时候检查Schema的功能屏蔽掉。

5.2 Metastore Server内存泄露问题

BoneCP+DirectSql开启时候Metastore Server内存泄露问题，
参考HIVE-15551，这个issue在2.2才完全解决，在Metastore Server端长期运行可能遇到，可以提前打patch来解决。

5.3 HiveServer2的多用户模拟问题

2.1后的HS2模拟多用户代码里，UGI的impersonation方式从CreateRemoteUser变为CreateProxyUser。

好处是可以获取到代理用户和被代理用户的信息，缺点是这种机制需要在Namenode端为每个被代理用户进行配置。
具体请参考：Hadoop Impersonation

如果不想这么麻烦，可以从CreateProxyUser回滚到CreateRemoteUser的方式，可以参考Hive1.2.1代码。

5.4 HiveServer2的operationlog不打印到客户端问题

参考HIVE-14183，
设置hive.async.log.enabled=false来解决。

5.5 Hive客户端PermGen OOM的问题

hive-env.sh设置export HADOOP_OPTS="$HADOOP_OPTS -XX:MaxPermSize=128m"解决。

5.6 HiveServer2的性能问题

hive.driver.parallel.compilation=true，默认为false，HS2只允许同时一个Query编译，
有操作元数据比较多的查询编译读取元数据会比较慢，会卡住所有其他查询。
打开允许多个Query同时编译。

5.7 基于Database的Stats收集策略被弃用

Hive2.1的Stats只能使用基于HDFS的策略，而StatsTask是单线程运行读取HDFS上的统计文件（文件数量等于Mapper数量），因为HDFS抖动导致了很多性能问题。
极端情况下，发现过一个statsTask会执行1个小时之久。

我们正在考虑把Stats Task禁掉，或者切换回基于Database的Stats收集策略。

5.8 Column Pruning时候导致列顺序错误问题

Column Pruning时候导致列顺序错误，造成处理时候ArrayIndexOutOfBoundsException。
在一些复杂的SQL里增加limit会发生，参考HIVE-14564来解决。

5.9 我们Team回馈社区的一些patch

1. Alter table Cascade时候的NPE问题：HIVE-16877
2. Drop掉分区后执行insert overwrite报错问题（这个问题比较严重，有可能不报错，但是会引入脏数据）：HIVE-17063
3. 非当前库内Alter partition的异常问题：HIVE-17309

6. 其他一些踩过的坑

6.1 元数据数据库连接数打满问题

元数据直连数据库方式下，当并发服务量非常巨大时候，MySQL默认连接数是4000，比较容易打满。

解决方法：

1. 直连使用BoneCP连接池方式下，maxConnectionsPerPartition默认值为10，一个客户端会建立20个连接，可以降低为2，并且降低连接池的活跃度。
   可以考虑在$HIVE_CONF_DIR下增加一个bonecp-config.xml：

   <?xml version="1.0" encoding="UTF-8"?>
   <bonecp-config>
    <default-config>
           <property name="maxConnectionAgeInSeconds">5</property>
           <property name="acquireIncrement">1</property>
           <property name="maxConnectionsPerPartition">2</property>
           <property name="lazyInit">true</property>
    </default-config>
   </bonecp-config>

2. 提升数据库连接数最大值，可能会有稳定性风险。

3. 使用Metastore Server，这是比较通用的做法，一个Metastore Server扛10000个客户端连接，后端400个数据库连接毫无压力。

7. 升级流程总结

总结之前的分析，从Hive0.13升级到2.1，升级过程可以达到完全灰度和平滑。

具体的升级流程如下：

1. 元数据schema备份。
2. 提前批量校验线上SQL，解决语法兼容性问题。
3. 元数据只升级hive-13076中的脚本，建立KEY_CONSTRAINTS表和表上的索引。
4. 定制Hive代码，根据使用场景解决2.1里面存在的UDF和其他的一些问题。
5. 开始灰度升级Hive 2.1客户端，HiveServer2，最后是Metastore Server。
6. Hive2.1客户端稳定后，根据需要部分或者全量来将元数据schema升级到2.1.1版本。
7. 最后依次升级Hive JDBC客户端。（非必需）

8. 附录

8.1 Hive1.2之后新版本新增的关键字

xlateMap.put("KW_OFFSET", "OFFSET");
xlateMap.put("KW_SUBQUERY", "SUBQUERY");
xlateMap.put("KW_REWRITE", "REWRITE");
xlateMap.put("KW_UPDATE", "UPDATE");
xlateMap.put("KW_VALUES", "VALUES");
xlateMap.put("KW_PURGE", "PURGE");
xlateMap.put("KW_PRIMARY", "PRIMARY");
xlateMap.put("KW_FOREIGN", "FOREIGN");
xlateMap.put("KW_KEY", "KEY");
xlateMap.put("KW_REFERENCES", "REFERENCES");
xlateMap.put("KW_CONSTRAINT", "CONSTRAINT");
xlateMap.put("KW_ENABLE", "ENABLE");
xlateMap.put("KW_DISABLE", "DISABLE");
xlateMap.put("KW_VALIDATE", "VALIDATE");
xlateMap.put("KW_NOVALIDATE", "NOVALIDATE");
xlateMap.put("KW_RELY", "RELY");
xlateMap.put("KW_NORELY", "NORELY");
xlateMap.put("KW_ABORT", "ABORT");
xlateMap.put("KW_TRANSACTIONS", "TRANSACTIONS");

TOK_NULLS_FIRST;
TOK_NULLS_LAST;
TOK_REPLICATION;
TOK_METADATA;
TOK_PRIMARY_KEY;
TOK_FOREIGN_KEY;
TOK_VALIDATE;
TOK_NOVALIDATE;
TOK_RELY;
TOK_NORELY;
TOK_TIMESTAMPLITERAL;
TOK_INTERVAL_YEAR_MONTH;
TOK_INTERVAL_YEAR_MONTH_LITERAL;
TOK_INTERVAL_DAY_TIME;
TOK_INTERVAL_DAY_TIME_LITERAL;
TOK_INTERVAL_YEAR_LITERAL;
TOK_INTERVAL_MONTH_LITERAL;
TOK_INTERVAL_DAY_LITERAL;
TOK_INTERVAL_HOUR_LITERAL;
TOK_INTERVAL_MINUTE_LITERAL;
TOK_INTERVAL_SECOND_LITERAL;

8.2 Hive JDBC和HiveServer2各版本之间兼容性

name	server0.13	server1.2	server2.1
jdbc0.13	兼容	兼容	兼容
jdbc1.2.1	兼容	兼容	兼容
jdbc2.1.0	兼容	兼容	兼容
jdbc2.1.1	不兼容	不兼容	兼容

8.3 从0.13开始的元数据Schema升级明细和影响分析

--****0.13.0 to 0.14.0****
--1. hive-7784 非必须
--hive-8715 这张表在0.13.1环境已经存在，升级过程只需要加一个索引
CREATE TABLE IF NOT EXISTS `PART_COL_STATS` (
 `CS_ID` bigint(20) NOT NULL,
 `DB_NAME` varchar(128) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
 `TABLE_NAME` varchar(128) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
 `PARTITION_NAME` varchar(767) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
 `COLUMN_NAME` varchar(128) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
 `COLUMN_TYPE` varchar(128) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL,
 `PART_ID` bigint(20) NOT NULL,
 `LONG_LOW_VALUE` bigint(20),
 `LONG_HIGH_VALUE` bigint(20),
 `DOUBLE_HIGH_VALUE` double(53,4),
 `DOUBLE_LOW_VALUE` double(53,4),
 `BIG_DECIMAL_LOW_VALUE` varchar(4000) CHARACTER SET latin1 COLLATE latin1_bin,
 `BIG_DECIMAL_HIGH_VALUE` varchar(4000) CHARACTER SET latin1 COLLATE latin1_bin,
 `NUM_NULLS` bigint(20) NOT NULL,
 `NUM_DISTINCTS` bigint(20),
 `AVG_COL_LEN` double(53,4),
 `MAX_COL_LEN` bigint(20),
 `NUM_TRUES` bigint(20),
 `NUM_FALSES` bigint(20),
 `LAST_ANALYZED` bigint(20) NOT NULL,
  PRIMARY KEY (`CS_ID`),
  CONSTRAINT `PART_COL_STATS_FK` FOREIGN KEY (`PART_ID`) REFERENCES `PARTITIONS` (`PART_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

CREATE INDEX PCS_STATS_IDX ON PART_COL_STATS (DB_NAME,TABLE_NAME,COLUMN_NAME,PARTITION_NAME) USING BTREE;

--****0.14.0 to 1.1.0****
--2. hive-9296 非必须修改
--Hcatalog Notification会使用到这张表，否则用不到。参考： https://issues.apache.org/jira/browse/HIVE-9174
--Hcatalog Notification的机制允许修改表和分区等事件广播，允许下游消费者来消费。具体请参考：
--https://cwiki.apache.org/confluence/display/Hive/HCatalog+Notification
CREATE TABLE IF NOT EXISTS `NOTIFICATION_LOG`
(
    `NL_ID` BIGINT(20) NOT NULL,
    `EVENT_ID` BIGINT(20) NOT NULL,
    `EVENT_TIME` INT(11) NOT NULL,
    `EVENT_TYPE` varchar(32) NOT NULL,
    `DB_NAME` varchar(128),
    `TBL_NAME` varchar(128),
    `MESSAGE` mediumtext,
    PRIMARY KEY (`NL_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
--同上
CREATE TABLE IF NOT EXISTS `NOTIFICATION_SEQUENCE`
(
    `NNI_ID` BIGINT(20) NOT NULL,
    `NEXT_EVENT_ID` BIGINT(20) NOT NULL,
    PRIMARY KEY (`NNI_ID`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;

--****1.1.0 to 1.2.0****
--no op

--****1.2.0 to 2.0.0****
--3. hive-7018，非必须修改
--删除 TBLS表和PARTITIONS表上的LINK_TARGET_ID列：https://issues.apache.org/jira/browse/HIVE-7018
--Hive只有在0.10之前会用到这个列。之后版本，如果没有使用schemaTool建表（线上0.13.1就没有用到），这列没有被建出来，因而这列也不需要删除。另外，本身保留也没有副作用。
--脚本本身有是否含有列的判断，因此执行也没有副作用。
SELECT '< HIVE-7018 Remove Table and Partition tables column LINK_TARGET_ID from Mysql for other DBs do not have it >' AS ' ';
DELIMITER $$
DROP PROCEDURE IF EXISTS RM_TLBS_LINKID $$
DROP PROCEDURE IF EXISTS RM_PARTITIONS_LINKID $$
DROP PROCEDURE IF EXISTS RM_LINKID $$
/* Call this procedure to drop column LINK_TARGET_ID for TBLS */
CREATE PROCEDURE RM_TLBS_LINKID()
  BEGIN
    IF EXISTS (SELECT * FROM `INFORMATION_SCHEMA`.`COLUMNS` WHERE `TABLE_NAME` = 'TBLS' AND `COLUMN_NAME` = 'LINK_TARGET_ID') THEN
      ALTER TABLE `TBLS`
        DROP FOREIGN KEY `TBLS_FK3`
      ;
      ALTER TABLE `TBLS`
        DROP KEY `TBLS_N51`
      ;
      ALTER TABLE `TBLS`
        DROP COLUMN `LINK_TARGET_ID`
      ;
    END IF;
  END $$x
/* Call this procedure to drop column LINK_TARGET_ID for PARTITIONS */
CREATE PROCEDURE RM_PARTITIONS_LINKID()
  BEGIN
    IF EXISTS (SELECT * FROM `INFORMATION_SCHEMA`.`COLUMNS` WHERE `TABLE_NAME` = 'PARTITIONS' AND `COLUMN_NAME` = 'LINK_TARGET_ID') THEN
      ALTER TABLE `PARTITIONS`
        DROP FOREIGN KEY `PARTITIONS_FK3`
      ;
      ALTER TABLE `PARTITIONS`
        DROP KEY `PARTITIONS_N51`
      ;
      ALTER TABLE `PARTITIONS`
        DROP COLUMN `LINK_TARGET_ID`
      ;
    END IF;
  END $$
/*
 * Check and drop column LINK_TARGET_ID
 */
CREATE PROCEDURE RM_LINKID()
  BEGIN
    call RM_PARTITIONS_LINKID();
    call RM_TLBS_LINKID();
    SELECT 'Completed remove LINK_TARGET_ID';
  END $$

DELIMITER ;
CALL RM_LINKID();

--4. hive-11970 非必须修改。
--某些情况下一些列名称非常长，例如avro导出的列名，所以需要增加COLUMN_NAME的长度，从128增加到767
--参考：https://issues.apache.org/jira/browse/HIVE-11970
ALTER TABLE `COLUMNS_V2` MODIFY `COLUMN_NAME` varchar(767) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL;
ALTER TABLE `PART_COL_PRIVS` MODIFY `COLUMN_NAME` varchar(767) CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL;
ALTER TABLE `TBL_COL_PRIVS` MODIFY `COLUMN_NAME` varchar(767) CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL;
ALTER TABLE `SORT_COLS` MODIFY `COLUMN_NAME` varchar(767) CHARACTER SET latin1 COLLATE latin1_bin DEFAULT NULL;
ALTER TABLE `TAB_COL_STATS` MODIFY `COLUMN_NAME` varchar(767) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL;
ALTER TABLE `PART_COL_STATS` MODIFY `COLUMN_NAME` varchar(767) CHARACTER SET latin1 COLLATE latin1_bin NOT NULL;
--5. hive-12807 非必须修改。NOTICE：元数据升级时候可能报错，因为COMPACTION_QUEUE表可能未被创建
--当通过配置启用hive事务时候使用到，默认事务不启用。具体是增加字段记录事务序列中的一些信息。
--参考：https://issues.apache.org/jira/browse/HIVE-12352
ALTER TABLE `COMPACTION_QUEUE` ADD `CQ_HIGHEST_TXN_ID` bigint;
--6. hive-12814 非必须修改
--当通过配置启用hive事务时候使用到，默认事务不启用。具体是增加字段，记录compaction时候的一些统计信息。
--参考：https://issues.apache.org/jira/browse/HIVE-11444
ALTER TABLE `COMPACTION_QUEUE` ADD `CQ_META_INFO` varbinary(2048);
--7. hive-12816 非必须修改
--当通过配置启用hive事务时候使用到，默认事务不启用。具体是增加字段，保存compaction时候的MR作业id，防止metastore重启时候无法kill过期作业。
--参考：https://issues.apache.org/jira/browse/HIVE-11685
ALTER TABLE `COMPACTION_QUEUE` ADD `CQ_HADOOP_JOB_ID` varchar(32);
--8. hive-12818 非必须修改
--当通过配置启用hive事务时候使用到，默认事务不启用。
--参考：https://issues.apache.org/jira/browse/HIVE-12353
CREATE TABLE COMPLETED_COMPACTIONS (
  CC_ID bigint PRIMARY KEY,
  CC_DATABASE varchar(128) NOT NULL,
  CC_TABLE varchar(128) NOT NULL,
  CC_PARTITION varchar(767),
  CC_STATE char(1) NOT NULL,
  CC_TYPE char(1) NOT NULL,
  CC_WORKER_ID varchar(128),
  CC_START bigint,
  CC_END bigint,
  CC_RUN_AS varchar(128),
  CC_HIGHEST_TXN_ID bigint,
  CC_META_INFO varbinary(2048),
  CC_HADOOP_JOB_ID varchar(32)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
--9. hive-12819 非必须修改
--当通过配置启用hive事务时候使用到，默认事务不启用。具体是增加show transactions时候的输出信息。
--参考：https://issues.apache.org/jira/browse/HIVE-12353
ALTER TABLE `TXNS` ADD `TXN_AGENT_INFO` varchar(128);
--10. hive-12821 非必须修改
--当通过配置启用hive事务时候使用到，默认事务不启用。
--参考：https://issues.apache.org/jira/browse/HIVE-11965
ALTER TABLE `TXNS` ADD `TXN_HEARTBEAT_COUNT` int;
ALTER TABLE `HIVE_LOCKS` ADD `HL_HEARTBEAT_COUNT` int;
--11. hive-12822 非必须修改，同上
ALTER TABLE `TXNS` ADD `TXN_META_INFO` varchar(128);
--12. hive-12823 非必须修改，同上
ALTER TABLE `HIVE_LOCKS` ADD `HL_AGENT_INFO` varchar(128);
--13. hive-12831 非必须修改，同上
ALTER TABLE `HIVE_LOCKS` ADD `HL_BLOCKEDBY_EXT_ID` bigint;
ALTER TABLE `HIVE_LOCKS` ADD `HL_BLOCKEDBY_INT_ID` bigint;
--14. hive-12832 非必须修改，同上
CREATE TABLE AUX_TABLE (
  MT_KEY1 varchar(128) NOT NULL,
  MT_KEY2 bigint NOT NULL,
  MT_COMMENT varchar(255),
  PRIMARY KEY(MT_KEY1, MT_KEY2)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
--****2.0.0 to 2.1.0****
--15. hive-13076 从代码上看不影响，但是涉及到建表和修改表操作，另外建议先打上补丁
--让hive支持表级别主键和外键，从而可以在CBO时候优化执行计划。目前完成了主键和外键的存储，CBO使用主键和外键功能还未开发完成。
--语法：CREATE TABLE vendor( vendor_id int, PRIMARY KEY (vendor_id)  DISABLE NOVALIDATE RELY);
--CREATE TABLE product ( product_id int, product_vendor_id int, PRIMARY KEY (product_id)  DISABLE NOVALIDATE, CONSTRAINT product_fk_1 FOREIGN KEY (product_vendor_id) REFERENCES vendor(vendor_id)  DISABLE NOVALIDATE);
--参考：https://issues.apache.org/jira/browse/HIVE-13350
CREATE TABLE IF NOT EXISTS `KEY_CONSTRAINTS`
(
  `CHILD_CD_ID` BIGINT,
  `CHILD_INTEGER_IDX` INT(11),
  `CHILD_TBL_ID` BIGINT,
  `PARENT_CD_ID` BIGINT NOT NULL,
  `PARENT_INTEGER_IDX` INT(11) NOT NULL,
  `PARENT_TBL_ID` BIGINT NOT NULL,
  `POSITION` BIGINT NOT NULL,
  `CONSTRAINT_NAME` VARCHAR(400) NOT NULL,
  `CONSTRAINT_TYPE` SMALLINT(6)  NOT NULL,
  `UPDATE_RULE` SMALLINT(6),
  `DELETE_RULE` SMALLINT(6),
  `ENABLE_VALIDATE_RELY` SMALLINT(6) NOT NULL,
  PRIMARY KEY (`CONSTRAINT_NAME`, `POSITION`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
CREATE INDEX `CONSTRAINTS_PARENT_TABLE_ID_INDEX` ON KEY_CONSTRAINTS (`PARENT_TBL_ID`) USING BTREE;
--16. hive-13395 不必须修改
--当通过配置启用hive事务时候使用到，默认事务不启用。
--参考：https://issues.apache.org/jira/browse/HIVE-13395
CREATE TABLE WRITE_SET (
  WS_DATABASE varchar(128) NOT NULL,
  WS_TABLE varchar(128) NOT NULL,
  WS_PARTITION varchar(767),
  WS_TXNID bigint NOT NULL,
  WS_COMMIT_ID bigint NOT NULL,
  WS_OPERATION_TYPE char(1) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
ALTER TABLE TXN_COMPONENTS ADD TC_OPERATION_TYPE char(1);
--17. hive-13354 不必须修改
--当通过配置启用hive事务时候使用到，默认事务不启用。
ALTER TABLE COMPACTION_QUEUE ADD CQ_TBLPROPERTIES varchar(2048);
ALTER TABLE COMPLETED_COMPACTIONS ADD CC_TBLPROPERTIES varchar(2048);