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

--错误信息：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 Hive Schema Tools from tb01;

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

（7）case when语法中的数据类型不一致，在2.1会报错

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

3、构建大数据SQL预上线测试环境

语法兼容性问题，可以提前拿到线上一段时间的SQL语句，启动一个2.1版本的HiveServer2， 通过批量Explain去校验是否存在语法兼容性问题，从而把所有问题解决到事前。

我们这边的做法是构建一个通用的大数据SQL测试环境，具体做法是：

数据集和Workload

通过客户端自定义的Hook和重放MapReduceLog/SparkEventlog等方法，拿到生产环境所有的SQL语句。

数据集合使用线上数据，事实一再证明，生产数据+生产SQL才能完全表征一个生产环境。

将数据输出关键字(Create Table/Insert into)统一修改为指向测试库表。按需提取所需要的SQL，例如全集、按照特征提取采样、Adhoc、生产ETL等维度来提取。

一键化测试

可以对比性能、数据质量、执行计划和错误分类等。融合成一个Hive/Spark/Presto新功能上线前的回归测试工具来使用。

三、Hive2.1新feature

1、ORC&Parquet文件格式

0.13对于2.1产生的ORC文件，存在读取兼容性问题。另外hive2.xx之前，ORCInputformat存在一个UGI错误的bug比较严重，在HiveServer2里会遇到， 原因是ORCReader使用了多线程加载ORC文件的footer，而UGI的继承是不能跨线程的。

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

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

Uber: Parquert + snappy

Linkedin: ORC + zlib

Didi: ORC + zlib

GrowingIO: ORC + zlib

我们倾向于主要文件格式选择ORC，因为ORC和Parquet测试下来速度差不多。 但Spark对于Parquet的一些加速特性需要DataSource API，因为不支持混合文件格式表而被我们关闭。而Hive/Presto对于ORC的支持更友好，例如读取速度、向量化、快速合并和统计信息优化等。

至于压缩算法的选择，我们倾向于对不同场景选择不同的压缩算法， 例如对数仓的ODS层，数据量很大、使用频率很低，考虑使用zlib压缩算法，达到最高压缩比。而DM层数据，数据量相对小但访问频率高，则考虑使用snappy压缩算法，在压缩比和解压缩速度之间取得一个tradeoff。

目前文件格式和压缩算法的选择正在逐步推广上线阶段。 我们的推广方法是改表格式+生命周期，使得数据从之前的格式逐渐滚动到ORC格式。

2、CBO

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

3、向量化执行

Hive的向量化执行目前只支持ORC文件格式，Parquet支持正在开发。在和文件格式推广同步测试和推广阶段。

4、Hive On Spark/Tez

On Spark目前看来社区还不成熟，目前发现只有Uber等在维护和使用。Tez目前更加冷清，之前用过一些效果还是很不错的，但一直没有火起来。

我们的方法是逐渐推广SparkSQL加速部分的ETL语句和Adhoc查询，并计划作为未来的主执行引擎，目前我们已经把SparkSQL 对原来HiveSQL的语法兼容性和运行成功率做到92%+，这样让我们的线上ETL SQL可以更加平滑低成本进行迁移。

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

5、其他

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

HiveServer2的Heap和PermGen内存泄露问题。

大量存储类型bug修复。参考社区的相关的issue list。

四、UDF兼容性

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

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

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。

https://cwiki.apache.org/confluence/display/Hive/LanguageManual+UDF#LanguageManualUDF-DateFunctions

五、Hive2.1存在的一些问题

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的功能屏蔽掉。

2、Metastore Server内存泄露问题

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

3、HiveServer2的多用户模拟问题

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

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

https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-common/Superusers.html。

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

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

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

https://issues.apache.org/jira/browse/HIVE-14183

5、Hive客户端PermGen OOM的问题

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

6、HiveServer2的性能问题