Hive优化（一）—概念介绍

介绍

  Hive是基于Hadoop的一个数据仓库工具，可以将结构化的数据文件映射为一张数据库表，并提供简单的sql查询功能，可以将sql语句转换为MapReduce任务进行运行 。Hive本身是不能存储数据的，它只是记录数据的一些路径信息，最终所有的操作都转换成MapReduce操作，所以Hive的优化其本质上是对Hadoop的优化。

Hadoop的特点

  做过大数据开发的都知道，Hadoop在处理数据的过程中有几个特点。

  1、数据多不是问题，就怕出现数据倾斜。

  2、对job较多的作业运行效率相对比较低，即使只有几百行数据的表，如果多次关联汇总，产生几十个job的话，至少也要跑个半小时。这是因为，map reduce的作业初始化的时间本身就比较长。

  3、对于sum，max，min和count的UDAF来讲不怕数据倾斜问题，因为hadoop会在map端对计算出来的结果进行汇总并优化，使得数据倾斜不成问题。

  4、count（distinct），在数据量大的时候，效率会变得较低，这主要是因为count（distinct）是按照group by来对字段进行分组的，并且按照distinct的字段进行排序，一般是很容易造成数据倾斜的。例如一个大型的购物网站，如果按照男女对访问量进行分组的话，而这个网站一天有20亿的浏览量，按照那女分成两组，由两个reduce来分别进行处理，这样每个reduce处理10亿数据，显然这样的资源分配是不合理的，效率是比较低下的（就像一堆砖，有10个人可以安排搬这些砖，然后你只安排2个搬搬砖，这样就会造成资源的浪费，降低工作的效率）。

影响Hive性能的因素

  在考虑hive性能优化时，把HiveQL当做M/R程序来读会有一种意想不到的收获。也就是从M/R的运行角度来考虑优化性能，从更底层思考如何优化运算性能，而不仅仅局限于逻辑代码的替换层面。

  RAC（Real Application Cluster）的应用集群就像一辆机动灵活的小货车，响应快。Hadoop就像吞吐量巨大的轮船，启动开销大，如果每次只做小数量的输入输出有点杀鸡用牛刀的感觉，会使得Hadoop的特性得不到充分发挥，降低利用率。所以要想用好Hadoop使Hadoop的性能得到充分，最先要做的就是增大每次任务所搭载的数据量。

  Hadoop的核心能力是parition和sort，在MapReduce的shuffle阶段，会对数据进行打乱->排序->再打乱->再排序，因次这也是优化的根本。

  Hadoop的作业初始化需要很长的时间，因此当job数量过多时，会导致整体的作业运行时间偏长，从而影响整体的效率，因此这也是在实际生产环境中需要注意的地方，要尽量使job数量变少。

  count（distinct）是按照group by来对字段进行分组的，但数据量较大而对应的分区字段较少时，或导致每个分组的数据量过大，从而造成数据倾斜，因此在数据量较大的时候要谨慎考虑使用count(distinct).

  我们知道在Hadoop中，数据倾斜是造成效率低下的主要原因，因此在实际环境中，需要尽量避免数据的倾斜问题。

  结论：在对hive进行优化时，应该要注意上述问题，针对上述问题来对Hive进行优化。在做优化的过程中我们要做到避实就虚，尽量使用最少的job 数来执行任务，充分利用空闲 CPU 等各种方法，分解数据倾斜造成的负担。

hive优化的原则

  那么，面对这些问题我们应该如何处理呢？我们能够采取哪些有效手段，来对这些问题进行优化呢？我们可以从一下几个大方面来进行考虑：

  1、设计一个好的模型，因为一个好的模型能够做到事半功倍。

  2、从数据倾斜问题来考虑，可以采取有效措施解决数据倾斜问题。

  3、尽量减少job的个数，能用一个job完成的，就坚决不用两个job。

  4、设置合理的map reduce的task个数，可以有效地提升性能。

  5、了解数据的分布，自己动手解决数据的倾斜是个不错的选择

  6、对于数据量较大的时候，要慎用count（distinct），因为容易产生数据倾斜。

  7、对小文件进行合并，是一种比较行之有效提高效率的方法。

  8、在优化时，要注意把握整体最优原则。

针对上述提出的问题，根据hive的特点在下一篇当中将具体介对于hive优化的一些具体细节。