hive优化经验

hive是数据仓库，主要涉及到对海量数据的存储和读取，以及数据的处理。

数据的存储和读取基本是基于hadoop的hdfs，所以要进行的优化就是提高数据的传输速度，可以通过配置参数（map和reduce阶段），优化hive的性能（如：在map阶段设置task的数量

mapred.min.split.size:通过调整max可以起到调整map数的作用，减小max可以增加map数，增大max可以减少map数。）。

数据的处理就是hsql，hsql本质上是转换为mapreduce来处理数据，对于性能的优化，就是一些较为复杂的hsql，实现功能并提高运行效率。（比如大表和小表进行jion，将小表写在前面，通过先将小表读入内存中，顺序扫描大表，就可以在map端进行join避免了shuffle）            

问题扩展

数据倾斜问题也会影响到我们对于数据处理的时效性，所以因为一些人员开发时语句编写不当或者一些业务问题都可能对我们产生影响；

        在实际的Hive SQL开发的过程中，Hive SQL 性能的问题上实际上只有一小部分和数据倾斜有关，很多时候，Hive SQL运行慢是由于开发人员对于使用的数据了解不够以及一些不良的习惯引起的。

开发人员需要确定以下几点：

1、 需要计算的指标真的需要从数据仓库公共明细层来自行汇总吗？ 是不是数据公共层团队开发公共汇总层已经可以满足自己的需求？对应大众的、KPI相关的指标等通常设计良好的数据仓库公共层肯定已经包含了，直接使用即可。

2、真的需要扫描那么多分区吗，比如对于销售事务明细表来说，扫描一年的分区和扫描一周的分区所带来的计算、IO开销完全是两个数量级，所耗费时间肯定是不同的，所以开发人员要仔细考虑因为需求，尽量不浪费计算和存储资源。

3、尽量不要使用select * from your_table这样的方式，用到哪些列就指定哪些列，另外WHERE条件中尽量添加过滤条件，以去掉无关的行，从而减少整个MapReduce任务宠需要处理、分发的数据量。

4、输入文件不要是大量的小文件，Hive默认的Input Split是128MB（可配置），小文件可先合并成大文件。