《离线和实时大数据开发实战》（五）Hive 优化实践_大数据hive离线计算开发实战(1)

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

Hive 的优化正是采用各种措施和方法对上述场景的倾斜问题进行优化和处理。

二、Hive 的优化

其实在实际 Hive SQL 开发的过程中， Hive SQL 性能的问题上实际只有一小部分和数据倾相关。

很多时候， Hive SQL 运行得慢是由开发人员对于使用的数据了解不够以及一些不良的使用习惯引起的。

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

• 需要计算的指标真的需要从数据仓库的公共明细层来自行汇总么？ 是不是数据公共层团队开发的公共汇总层已经可以满足自己的需求？对于大众的、 KPI 相关的指标等通常设计良好的数据仓库公共层肯定已经包含了，直接使用即可。
• 真的需要扫描这么多分区么？ 比如对于销售明细事务表来说，扫描一年的分区和扫描一周的分区所带来的计算、 IO 开销完全是两个量级，所耗费的时间肯定也是不同的。作为开发人员，我们需要仔细考虑业务的需求，尽量不要浪费计算和存储资源！
• 尽量不要使用 select * from your_table 这样的方式，用到哪些列就指定哪些列。 如 select coll, col2 from your_table ，另外， where 条件中也尽量添加过滤条件，以去掉无关的数据行，从而减少整个 MapReduce 任务中需要处理、分发的数据量。
• 输入文件不要是大量的小文件。 Hive 的默认 Input Split 是 128MB （可配置），小文件可先合并成大文件。

在保证了上述几点之后，有的时候发现 Hive SQL 还是要运行很长时间，甚至运行不出来， 这时就需要真正的 Hive 优化技术了！

三、Join 无关的优化

Hive SQL 性能问题基本上大部分都和 join 相关，对于和 join 无关的问题主要有 groupby 相关的倾斜和 count distinct 相关的优化。

3.1 group by 引起的倾斜优化

group by 引起的倾斜主要是输入数据行按照 gr