【有奖讨论】Hive性能调优的姿势正确【获奖名单公布】

飘絮絮絮丶

本次活动获得《Hive性能调优实战》奖励的用户是：
@aloki
@renxiao2003
@fenyun689
@wzl189189

请以上4位用户，请于7月30日前以站内的形式联系管理员飘絮絮絮丶，如无法发站内请加微信：itpubwxt


话题背景：   

随着互联网的发展和数字时代的到来，不同规模的公司都在建立自己的数据平台，希望收集尽可能多的数据，从中挖掘足够有价值的信息，供企业的生产决策使用。Hive凭借着简单、运行稳定、可计算数据量庞大而成为数据平台中关键核心组件。想要利用数据平台进行数据生产，那么掌握Hive就是必备的技能。Hive虽然简单，但是如果使用的姿势不对，不懂调优的技巧，那么写出来的程序效率就会大打折扣。近期机械工业出版社出版了《Hive性能调优实战》一书，是一本基于大数据生态的Hive性能调优图书。旨在分享Hive调优需要注意的技能和方法。本次活动也以此为契机和各讨论讨论Hive优化的相关话题，欢迎大家踊跃发言。

话题讨论：

（1）在平常工作中，各位是如何进行HiveSQL的优化，请简单说说你的优化过程？
（2）本书在介绍Hive优化时会从Hive所依赖的大数据组件YARN、计算引擎（MR）、HIVE SQL执行计划、Hive数据处理模式及Hive数据存储等方面介绍Hive的优化，读者朋友还可以分享哪些好的优化切入点？
（3）本书在介绍Hive优化时，不但有实际例子的演示，而且也侧重对背后原理的讲解，旨在建立一套优化的方法论。你觉得在实际的工作中，哪些地方需要更多、更深入的探讨和说明？

活动时间：2020年5月12日-2020年6月11日

本期奖品：最佳积极参与经验分享奖5名，奖励价值89元的《Hive性能调优实战》图书1本。

Hive性能调优实战
林志煌  编著
书号：978-7-111-64432-3
印张：18.5（共296页）
书脊：14mm
定价：89.00元
成品尺寸：186*240
上架建议：计算机/大数据



购买链接：

京东：https://item.jd.com/12792706.html
当当：http://product.dangdang.com/28507457.html

内容简介：

本书旨在介绍如何进行Hive性能调优，以及调优时所涉及的工具。书中重点介绍了Hive性能调优所涉及的Hadoop组件和Hive工具。考虑到很多调优方法的着眼点有一定的相似性，这些调优方法可以适用于多个Hive版本，所以本书在介绍Hive的相关内容时会穿插Hive 1.x、Hive 2.x及Hive 3.x等多个版本的内容。
本书共11章，涵盖的内容：举例感受Hive性能调优的多样性；Hive问题查与调优思路；环境搭建；Hive及其相关大数据组件；深入MapReduce计算引擎；Hive SQL执行计划；Hive数据处理模式；YARN日志；数据存储；发现并优化Hive中的性能问题；Hive知识体系总结。
本书内容实用，非常适合对大数据技术感兴趣的读者阅读，尤其是Hive进阶读者。另外，本书还适合IT培训机构的大数据培训学员和高校相关专业的学生阅读。

图书试读： 前言 目录.pdf (4.03 MB, 下载次数: 57)

2020-05-12 15:25 上传

点击文件名下载附件

第1章（试读）.pdf (10.32 MB, 下载次数: 67)

2020-05-12 15:41 上传

点击文件名下载附件

第2章（试读）.pdf (11.26 MB, 下载次数: 62)

2020-05-12 15:45 上传

点击文件名下载附件

飘絮絮絮丶

欢迎大家踊跃参与活动呦

oyzx_sp

很好的一本书，阿加积极发言哦。

aloki

（1）在平常工作中，各位是如何进行HiveSQL的优化，请简单说说你的优化过程？
·在SELECT中，只拿需要的列，如果有，尽量使用分区过滤，少用SELECT *。在分区剪裁中，当使用外关联时，如果将副表的过滤条件写在Where后面，那么就会先全表关联，之后再过滤。
·在数据量大的情况下，由于COUNT DISTINCT操作需要用一个Reduce Task来完成，这一个Reduce需要处理的数据量太大，就会导致整个Job很难完成，一般COUNT DISTINCT使用先GROUP BY再COUNT的方式替换。
·只要遇到表关联，就必须得调研一下，是否存在多对多的关联，起码得保证有一个表或者结果集的关联键不重复。如果某一个关联键的记录数非常多，那么分配到该Reduce Task中的数据量将非常大，导致整个Job很难完成，甚至根本跑不出来。


（2）本书在介绍Hive优化时会从Hive所依赖的大数据组件YARN、计算引擎（MR）、HIVE SQL执行计划、Hive数据处理模式及Hive数据存储等方面介绍Hive的优化，读者朋友还可以分享哪些好的优化切入点？
Hive除了支持MapReduce计算引擎，还支持Spark和Tez这两个分布式计算引擎。

（3）本书在介绍Hive优化时，不但有实际例子的演示，而且也侧重对背后原理的讲解，旨在建立一套优化的方法论。你觉得在实际的工作中，哪些地方需要更多、更深入的探讨和说明？
MapReduce编程十分繁琐，在大多情况下，每个MapReduce程序需要包含Mapper、Reduceer和一个Driver，之后需要打成jar包扔到集群上运 行。如果mr写完之后，且该项目已经上线，一旦业务逻辑发生了改变，可能就会带来大规模的改动代码，然后重新打包，发布，非常麻烦。

renxiao2003

（1）在平常工作中，各位是如何进行HiveSQL的优化，请简单说说你的优化过程？
一个Hive查询生成多个Map Reduce Job，一个Map Reduce Job又有Map，Reduce，Spill，Shuffle，Sort等多个阶段，所以针对Hive查询的优化可以大致分为针对MR中单个步骤的优化（其中又会有细分），针对MR全局的优化，和针对整个查询（多MR Job）的优化。
Map阶段的优化，主要是确定合适的Map数。
Reduce阶段，是指前面流程图中的Reduce phase（实际的Reduce计算）而非图中整个Reduce task。Reduce阶段优化的主要工作也是选择合适的Reduce task数量，跟上面的Map优化类似。
与Map优化不同的是，Reduce优化时，可以直接设置Mapred。Reduce。tasks参数从而直接指定Reduce的个数。当然直接指定Reduce个数虽然比较方便，但是不利于自动扩展。Reduce数的设置虽然相较Map更灵活，但是也可以像Map一样设定一个自动生成规则，这样运行定时Job的时候就不用担心原来设置的固定Reduce数会由于数据量的变化而不合适。
Map phase和Reduce phase之间主要有3道工序。首先要把Map输出的结果进行排序后做成中间文件，其次这个中间文件就能分发到各个Reduce，最后Reduce端在执行Reduce phase之前把收集到的排序子文件合并成一个排序文件。这个部分可以调的参数挺多，但是一般都是不要调整的，不必重点关注。
（2）本书在介绍Hive优化时会从Hive所依赖的大数据组件YARN、计算引擎（MR）、HIVE SQL执行计划、Hive数据处理模式及Hive数据存储等方面介绍Hive的优化，读者朋友还可以分享哪些好的优化切入点？
一、合理设计schema
1.使用分区，但避免使用大量的分区
2.合理设计临时表
3.合理设计buckets
4.针对不同的表，合理使用压缩特性
二、查询优化
1.使用适当的MAP与REDUCE数
2.使用普通的JOIN时，设计合理的表顺序
3.使用MAP JOIN
4.使用BUCKET MAP JOIN或SORT MERGE BUCKET MAP JOIN
5.合理设计索引
（3）本书在介绍Hive优化时，不但有实际例子的演示，而且也侧重对背后原理的讲解，旨在建立一套优化的方法论。你觉得在实际的工作中，哪些地方需要更多、更深入的探讨和说明？
Hive管理表，也叫内部表。Hive控制着管理表的整个生命周期，默认情况下Hive管理表的数据存放在hive的主目录：/user/hive/warehouse/下，并且当我们删除一张表时，这张表的数据也会相应的被删除掉，在文件层面上讲，就是在Hive主目录下的表目录以及目录里面的数据文件都会被删除掉。
      管理表能够有效的管理表的数据，但是不利于对数据的分享，同一份数据，我希望既能够指向表A，有能够分享给表B，但是相应的这些表不应该控制数据的生命周期，这种表在Hive里面成为外部表。在创建外部表的时候，需要指向数据的具体位置，相当于一个指针，外部表只是引用了数据的地址，访问表时再根据这个地址指针去找到相应的数据。
     在管理大型数据集时，分区是一个有效的解决办法，能够根据分区条件限制访问的数据量大小，能够达到优化数据的访问速度。

renxiao2003

（1）在平常工作中，各位是如何进行HiveSQL的优化，请简单说说你的优化过程？
一个Hive查询生成多个Map Reduce Job，一个Map Reduce Job又有Map，Reduce，Spill，Shuffle，Sort等多个阶段，所以针对Hive查询的优化可以大致分为针对MR中单个步骤的优化（其中又会有细分），针对MR全局的优化，和针对整个查询（多MR Job）的优化。
Map阶段的优化，主要是确定合适的Map数。
Reduce阶段，是指前面流程图中的Reduce phase（实际的Reduce计算）而非图中整个Reduce task。Reduce阶段优化的主要工作也是选择合适的Reduce task数量，跟上面的Map优化类似。
与Map优化不同的是，Reduce优化时，可以直接设置Mapred。Reduce。tasks参数从而直接指定Reduce的个数。当然直接指定Reduce个数虽然比较方便，但是不利于自动扩展。Reduce数的设置虽然相较Map更灵活，但是也可以像Map一样设定一个自动生成规则，这样运行定时Job的时候就不用担心原来设置的固定Reduce数会由于数据量的变化而不合适。
Map phase和Reduce phase之间主要有3道工序。首先要把Map输出的结果进行排序后做成中间文件，其次这个中间文件就能分发到各个Reduce，最后Reduce端在执行Reduce phase之前把收集到的排序子文件合并成一个排序文件。这个部分可以调的参数挺多，但是一般都是不要调整的，不必重点关注。
（2）本书在介绍Hive优化时会从Hive所依赖的大数据组件YARN、计算引擎（MR）、HIVE SQL执行计划、Hive数据处理模式及Hive数据存储等方面介绍Hive的优化，读者朋友还可以分享哪些好的优化切入点？
一、合理设计schema
1.使用分区，但避免使用大量的分区
2.合理设计临时表
3.合理设计buckets
4.针对不同的表，合理使用压缩特性
二、查询优化
1.使用适当的MAP与REDUCE数
2.使用普通的JOIN时，设计合理的表顺序
3.使用MAP JOIN
4.使用BUCKET MAP JOIN或SORT MERGE BUCKET MAP JOIN
5.合理设计索引
（3）本书在介绍Hive优化时，不但有实际例子的演示，而且也侧重对背后原理的讲解，旨在建立一套优化的方法论。你觉得在实际的工作中，哪些地方需要更多、更深入的探讨和说明？
Hive管理表，也叫内部表。Hive控制着管理表的整个生命周期，默认情况下Hive管理表的数据存放在hive的主目录：/user/hive/warehouse/下，并且当我们删除一张表时，这张表的数据也会相应的被删除掉，在文件层面上讲，就是在Hive主目录下的表目录以及目录里面的数据文件都会被删除掉。
      管理表能够有效的管理表的数据，但是不利于对数据的分享，同一份数据，我希望既能够指向表A，有能够分享给表B，但是相应的这些表不应该控制数据的生命周期，这种表在Hive里面成为外部表。在创建外部表的时候，需要指向数据的具体位置，相当于一个指针，外部表只是引用了数据的地址，访问表时再根据这个地址指针去找到相应的数据。
     在管理大型数据集时，分区是一个有效的解决办法，能够根据分区条件限制访问的数据量大小，能够达到优化数据的访问速度。

renxiao2003

（1）在平常工作中，各位是如何进行HiveSQL的优化，请简单说说你的优化过程？
一个Hive查询生成多个Map Reduce Job，一个Map Reduce Job又有Map，Reduce，Spill，Shuffle，Sort等多个阶段，所以针对Hive查询的优化可以大致分为针对MR中单个步骤的优化（其中又会有细分），针对MR全局的优化，和针对整个查询（多MR Job）的优化。
Map阶段的优化，主要是确定合适的Map数。
Reduce阶段，是指前面流程图中的Reduce phase（实际的Reduce计算）而非图中整个Reduce task。Reduce阶段优化的主要工作也是选择合适的Reduce task数量，跟上面的Map优化类似。
与Map优化不同的是，Reduce优化时，可以直接设置Mapred。Reduce。tasks参数从而直接指定Reduce的个数。当然直接指定Reduce个数虽然比较方便，但是不利于自动扩展。Reduce数的设置虽然相较Map更灵活，但是也可以像Map一样设定一个自动生成规则，这样运行定时Job的时候就不用担心原来设置的固定Reduce数会由于数据量的变化而不合适。
Map phase和Reduce phase之间主要有3道工序。首先要把Map输出的结果进行排序后做成中间文件，其次这个中间文件就能分发到各个Reduce，最后Reduce端在执行Reduce phase之前把收集到的排序子文件合并成一个排序文件。这个部分可以调的参数挺多，但是一般都是不要调整的，不必重点关注。
（2）本书在介绍Hive优化时会从Hive所依赖的大数据组件YARN、计算引擎（MR）、HIVE SQL执行计划、Hive数据处理模式及Hive数据存储等方面介绍Hive的优化，读者朋友还可以分享哪些好的优化切入点？
一、合理设计schema
1.使用分区，但避免使用大量的分区
2.合理设计临时表
3.合理设计buckets
4.针对不同的表，合理使用压缩特性
二、查询优化
1.使用适当的MAP与REDUCE数
2.使用普通的JOIN时，设计合理的表顺序
3.使用MAP JOIN
4.使用BUCKET MAP JOIN或SORT MERGE BUCKET MAP JOIN
5.合理设计索引
（3）本书在介绍Hive优化时，不但有实际例子的演示，而且也侧重对背后原理的讲解，旨在建立一套优化的方法论。你觉得在实际的工作中，哪些地方需要更多、更深入的探讨和说明？
Hive管理表，也叫内部表。Hive控制着管理表的整个生命周期，默认情况下Hive管理表的数据存放在hive的主目录：/user/hive/warehouse/下，并且当我们删除一张表时，这张表的数据也会相应的被删除掉，在文件层面上讲，就是在Hive主目录下的表目录以及目录里面的数据文件都会被删除掉。
      管理表能够有效的管理表的数据，但是不利于对数据的分享，同一份数据，我希望既能够指向表A，有能够分享给表B，但是相应的这些表不应该控制数据的生命周期，这种表在Hive里面成为外部表。在创建外部表的时候，需要指向数据的具体位置，相当于一个指针，外部表只是引用了数据的地址，访问表时再根据这个地址指针去找到相应的数据。
     在管理大型数据集时，分区是一个有效的解决办法，能够根据分区条件限制访问的数据量大小，能够达到优化数据的访问速度。

fenyun689

（1）在平常工作中，各位是如何进行HiveSQL的优化，请简单说说你的优化过程？
1、使用union+group by 替代 union ,大小表使用map join 、用in 替代join查询
2、如果是分区的表，查询时一定要使用分区限制，如果没有分区限制，会从该表的所有数据里面遍历
3、尽量不用order by，因为order by是全局的，会只有一个reduce



（2）本书在介绍Hive优化时会从Hive所依赖的大数据组件YARN、计算引擎（MR）、HIVE SQL执行计划、Hive数据处理模式及Hive数据存储等方面介绍Hive的优化，读者朋友还可以分享哪些好的优化切入点？
1、作业有多个可并行的job时，设置任务并行及并行个数。
2、设置执行引擎
如果设置执行引擎为mr，那么就会调用Hadoop的maprecude来运行需要执行job的程序；如果设置执行引擎为spark，那么就会调用spark来执行任务。有条件的话，就设置执行引擎为Spark，因为实在是运行的比Hadoop的MapReduce快了很多。


（3）本书在介绍Hive优化时，不但有实际例子的演示，而且也侧重对背后原理的讲解，旨在建立一套优化的方法论。你觉得在实际的工作中，哪些地方需要更多、更深入的探讨和说明？
对 hive 计算的原理多了解下。对于查找分析问题，优化sql很有帮助。

wzl189189

好书，支持

wzl189189

（1）在平常工作中，各位是如何进行HiveSQL的优化，请简单说说你的优化过程？
1、使用union+group by 替代 union ,大小表使用map join 、用in 替代join查询
2、如果是分区的表，查询时一定要使用分区限制，如果没有分区限制，会从该表的所有数据里面遍历
3、尽量不用order by，因为order by是全局的，会只有一个reduce



（2）本书在介绍Hive优化时会从Hive所依赖的大数据组件YARN、计算引擎（MR）、HIVE SQL执行计划、Hive数据处理模式及Hive数据存储等方面介绍Hive的优化，读者朋友还可以分享哪些好的优化切入点？
1、作业有多个可并行的job时，设置任务并行及并行个数。
2、设置执行引擎
如果设置执行引擎为mr，那么就会调用Hadoop的maprecude来运行需要执行job的程序；如果设置执行引擎为spark，那么就会调用spark来执行任务。有条件的话，就设置执行引擎为Spark，因为实在是运行的比Hadoop的MapReduce快了很多。


（3）本书在介绍Hive优化时，不但有实际例子的演示，而且也侧重对背后原理的讲解，旨在建立一套优化的方法论。你觉得在实际的工作中，哪些地方需要更多、更深入的探讨和说明？
对 hive 计算的原理多了解下。对于查找分析问题，优化sql很有帮助。