HiveServer2
这是一个服务端接口，可以使用远程客户端执行对hive的查询，并返回结果。
Hive的调优策略
作为大数据领域的数据仓库组件，在设计和开发的时候，都需要注意效率。这个时候调优就显得很重要了。数据倾斜、数据冗余、job或者I/O过多、MapReduce分配不合理都会导致hive的效率降低。
而如何对hive进行调优呢？其实主要就是架构优化，参数优化和SQL优化。
那我们一个一个来看吧，首先是架构优化。
架构优化
执行引擎
既然是架构，那么先从核心引擎来看，hive本身呢是支持多种引擎的，MapReduce、TeZ、spark、flink。都是hive可以支持的引擎。这些在hivesite.xml中的hive.execution.engine来控制。
相对来说Tez是一个比较好的选择，可以拆分MapReduce的过程，减少文件的储存，提高性能。
优化器
这点就和sql很像，在执行计算之前，生成和优化逻辑执行计划与物理执行计划。hive有两种优化器。
其一是向量优化器，就是执行变成一批1024行，而不是一行一行来执行。这样就缩短了时间，但是缺陷不明。。。并且数据储存必须用ORC格式。
其二就是成本优化器。。。具体不详。。。
除了优化器，还有的就是我们之前就知道的分区表和分桶表了，通过切割数据来降低时耗。
其实做到这一步了，基本也调优的差不多了，在架构上如果想继续优化，就得改变数据的储存格式了，毕竟这就要牺牲掉一些信息了。
文件格式里面最简单的就是TextFile（纯文本储存格式），不过我想一般应该走不到这步吧。
最后还不行，就只能对数据进行压缩了，减少map和reduce间的数据传输，从而提升性能。
参数优化
本地模式
前面讨论的都是hive处理的数据量较大时的调优，当然了，hive大多时应该都是处理大数据集的。那么当数据集小的时候，hive用分布式去处理其实是有些牛刀杀鸡了，因为分布式启动的时间甚至都比数据处理的时间要长，这个时候就需要将hive转至本地模式（前面提到过）了。
严格模式
听起来好像还挺厉害的，本质就是禁止三种有风险的语句，第一就是查询时不限定分区；第二是join时的重复；第三是order by排序后不使用limit来限制。说实话感觉效果就那样。
SQL优化
列裁剪和分区裁剪
简单理解就是查询的时候只取需要的列和分区，多余的碰都不碰。将节俭进行到底
sort by 代替 order by
就是排序方法的一个替换，个人觉得加个limit就可以了，不必这么大费周章吧。
group by代替count
这个count的确得谨慎使用，不过大哥你group by也没好到哪去吧，数据倾斜你group by比count还恶心。
明天写个优化的实战吧，待我先看一看
