。

为了确保代码的可读性、维护性和性能#xff0c;制定一套规范化的

Hive

的基础知识#xff0c;并提供一些规范化的开发指…在大数据领域Hive

SQL

Hadoop上进行数据分析和处理。

为了确保代码的可读性、维护性和性能制定一套规范化的

Hive

在使用Hive进行数据查询和处理时执行日志是一个重要的组成部分它帮助开发者和管理员理解SQL执行的细节、性能瓶颈以及可能出现的错误。

开启和查看执行日志

CLI中执行SQL时可以直接在控制台输出中看到日志信息。

Beeline使用Beeline连接Hive时也可以设置不同的日志级别来查看执行过程中的详细信息。

HiveServer2日志如果通过HiveServer2服务执行SQL可以在HiveServer2的日志文件中找到执行日志。

YARN日志对于提交到YARN上运行的Hive作业可以通过YARN的ResourceManager界面或使用yarn

logs

Hive支持不同的日志级别这些级别从详细到简洁依次为DEBUG、INFO、WARN、ERROR。

在调试SQL性能问题或错误时DEBUG或INFO级别的日志通常最为有用但它们会产生大量的输出。

在生产环境中通常使用WARN或ERROR级别以减少日志文件的大小。

配置日志级别

hive.root.loggerINFO,console这样的参数来设置日志级别。

修改Hive配置文件在hive-site.xml中设置hive.root.logger属性来全局改变日志级别。

尽量尽早地过滤数据减少每个阶段的数据量,对于分区表要加分区同时只选择需要使用到的字段。

select

慎重使用mapjoin,一般行数小于2000行大小小于25M(扩容后可以适当放大)的表才能使用,小表要注意放在join的左边。

否则会引起磁盘和内存的大量消耗

四、禁止使用笛卡尔积

笛卡尔积只有1个reduce任务会导致计算超慢甚至可能计算不出来或者导致节点挂掉。

五、列修剪和分区修剪

在读数据的时候只读取查询中需要用到的列而忽略其他列。

例如对于查询

SELECT

此选项参数默认为真hive.optimize.prunertrue

explain命令对于我们优化查询语句很重要针对某些查询语句我们可以通过它查看各个执行计划针对耗时的地方优化之。

EXPLAIN

当需要把几个数据集的结果合并时能使用join的话就不要使用union

all时通常需要加入大量的0这会导致中间结果膨胀增加系统负担。

八、数据膨胀导致reduce任务数不合理

数据膨胀很多时候也会导致reduce任务个数过少。

reduce数目是否合理可以从任务的mr监控页面发现端倪。

请注意job监控页面的一个参数

Reduce

一般情况下reduce任务的个数应大致等于上面这个参数的大小请换算成GB如果该参数大小是reduce任务数的数倍那就意味着reduce任务数不合理。

解决方法

注意请合理设置N的大小最好设置为上述参数的大小。

不要超过999

九、合并小文件

1某些情况下job运行过程中reduce个数太少导致任务执行太慢默认reduce的个数由下面配置控制

hive.exec.reducers.bytes.per.reducer每个reduce任务处理的数据量默认为1000^31G

hive.exec.reducers.max每个任务最大的reduce数默认为999

计算reducer数的公式很简单Nmin(参数2总输入数据量/参数1)

2调整reduce个数方法一

调整hive.exec.reducers.bytes.per.reducer参数的值

set

hive.exec.reducers.bytes.per.reducer500000000;

500M

同map一样启动和初始化reduce也会消耗时间和资源另外有多少个reduce,就会有多少个输出文件如果生成了很多个小文件那么如果这些小文件作为下一个任务的输入则也会出现小文件过多的问题

5什么情况下只有一个reduce

很多时候你会发现任务中不管数据量多大不管你有没有设置调整reduce个数的参数任务中一直都只有一个reduce任务

其实只有一个reduce任务的情况除了数据量小于hive.exec.reducers.bytes.per.reducer参数值的情况外还有以下原因

a)没有group

实现部分有序单个reduce输出的结果是有序的效率高通常和DISTRIBUTE

BY关键字一起使用DISTRIBUTE

在hive中有时候会希望根据输入的key把结果自动输出到不同的目录中这可以通过动态分区来实现就是把每一个key当作一个分区。

set

hive.exec.dynamic.partitiontrue;

set

hive.exec.dynamic.partition.modenonstrict;

hive.exec.dynamic.partitions.pernode

参数指的是每个节点上能够生成的最大分区这个在最坏情况下应该是跟最大分区一样的值

hive.exec.dynamic.partitions.partitions

3、最后要注意的是select语句中要把distribute的key也select出来

4、适当设置reduce个数

数据倾斜的外在表现是执行时间超长。

查看任务的监控页面可以发现除了一个或几个任务外其他reduce任务都执行的很快。

这种情况下只有一个解释数据倾斜。

在做Shuffle阶段的优化过程中遇到了数据倾斜的问题造成了对一些情况下优化效果不明显。

主要是因为在Job完成后的所得到的Counters是整个Job的总和优化是基于这些Counters得出的平均值而由于数据倾斜的原因造成map处理数据量的差异过大使得这些平均值能代表的价值降低。

Hive的执行是分阶段的map处理数据量的差异取决于上一个stage的reduce输出所以如何将数据均匀的分配到各个reduce中就是解决数据倾斜的根本所在。

规避错误来更好的运行比解决错误更高效。

在查看了一些资料后总结如下。

数据倾斜原因

任务进度长时间维持在99%或100%查看任务监控页面发现只有少量1个或几个reduce子任务未完成。

因为其处理的数据量和其他reduce差异过大。

单一reduce的记录数与平均记录数差异过大通常可能达到3倍甚至更多。

参数调节

做好列裁剪和filter操作以达到两表做join的时候数据量相对变小的效果。

大小表Join

把空值的key变成一个字符串加上随机数把倾斜的数据分到不同的reduce上由于null值关联不上处理后并不影响最终结果。

count

distinct可以不用处理直接过滤在最后结果中加1。

如果还有其他计算需要进行group

by可以先将值为空的记录单独处理再和其他计算结果进行union。

group

在业务逻辑优化效果的不大情况下有些时候是可以将倾斜的数据单独拿出来处理。

最后union回去。

user_id

结论方法2比方法1效率更好不但io少了而且作业数也少了。

解决方法1中

(比如

变成一个字符串加上随机数就能把倾斜的数据分到不同的reduce上

不同数据类型关联产生数据倾斜

场景用户表中user_id字段为intlog表中user_id字段既有string类型也有int类型。

当按照user_id进行两个表的Join操作时默认的Hash操作会按int型的id来进行分配这样会导致所有string类型id的记录都分配到一个Reducer中。

解决方法把数字类型转换成字符串类型

解决小表(记录数少)关联大表的数据倾斜问题这个方法使用的频率非常高但如果小表很大大到map

select

join问题。

所幸每日的会员uv不会太多有交易的会员不会太多有点击的会员不会太多有佣金的会员不会太多等等。

所以这个方法能解决很多场景下的数据倾斜问题。

使map的输出数据更均匀的分布到reduce中去是我们的最终目标。

由于Hash算法的局限性按key

Hash会或多或少的造成数据倾斜。

大量经验表明数据倾斜的原因是人为的建表疏忽或业务逻辑可以规避的。

在此给出较为通用的步骤

1、采样log表哪些user_id比较倾斜得到一个结果表tmp1。

由于对计算框架来说所有的数据过来他都是不知道数据分布情况的所以采样是并不可少的。

2、数据的分布符合社会学统计规则贫富不均。

倾斜的key不会太多就像一个社会的富人不多奇特的人不多一样。

所以tmp1记录数会很少。

把tmp1和users做map

file

3、map读入users和log假如记录来自log,则检查user_id是否在tmp2里如果是输出到本地文件a,否则生成user_id,value的key,value对假如记录来自member,生成user_id,value的key,value对进入reduce阶段。

4、最终把a文件把Stage3