1. Hive数据倾斜
原因
- key分布不均匀
- 业务数据本身的特性
- SQL语句造成数据倾斜
解决方法
- hive设置hive.map.aggr=true和hive.groupby.skewindata=true
- 有数据倾斜的时候进行负载均衡,当选项设定为true,生成的查询计划会有两个MR Job。第一个MR Job中,Map的输出结果集合会随机分布到Reduce中,每个Reduce做部分聚合操作,并输出结果,这样处理的结果是相同Group By Key有可能被分发到不同的Reduce中,从而达到负载均衡的目的;第二个MR Job在根据预处理的数据结果按照 Group By Key 分布到Reduce中(这个过程可以保证相同的 Group By Key 被分布到同一个Reduce中),最后完成最终的聚合操作。
SQL语句调整:
- 选用join key 分布最均匀的表作为驱动表。做好列裁剪和filter操作,以达到两表join的时候,数据量相对变小的效果。
- 大小表Join: 使用map join让小的维度表(1000条以下的记录条数)先进内存。在Map端完成Reduce。
- 大表Join大表:把空值的Key变成一个字符串加上一个随机数,把倾斜的数据分到不同的reduce上,由于null值关联不上,处理后并不影响最终的结果。
- count distinct大量相同特殊值:count distinct时,将值为空的情况单独处理,如果是计算count distinct,可以不用处理,直接过滤,在做后结果中加1。如果还有其他计算,需要进行group by,可以先将值为空的记录单独处理,再和其他计算结果进行union.
2. Hive中的排序关键字有哪些
sort by ,order by ,cluster by ,distribute by
- sort by :不是全局排序,其在数据进入reducer前完成排序
- order by :会对输入做全局排序,因此只有一个reducer(多个reducer无法保证全局有序).只有一个reducer,会导致当输入规模较大时,需要较长的计算时间。
- cluster by : 当distribute by 和sort by的字段相同时,等同于cluster by.可以看做特殊的distribute + sort
- distribute by :按照指定的字段对数据进行划分输出到不同的reduce中
3. 海量数据分布在100台电脑中,想个办法高效统计出这批数据的TOP10
方案1:
- 在每台电脑上求出TOP10,可以采用包含10个元素的堆完成(TOP10小,用最大堆,TOP10大,用最小堆)。
- 比如求TOP10大,我们首先取前10个元素调整成最小堆,如果发现,然后扫描后面的数据,并与堆顶元素比较,如果比堆顶元素大,那么用该元素替换堆顶,然后再调整为最小堆。
- 最后堆中的元素就是TOP10大。
方案2
- 求出每台电脑上的TOP10后,然后把这100台电脑上的TOP10组合起来,共1000个数据
- 再利用上面类似的方法求出TOP10就可以了。
4. Hive中追加导入数据的4种方式是什么?请写出简要语法
- 从本地导入: load data local inpath ‘/home/1.txt’ (overwrite)into table student;
- 从Hdfs导入: load data inpath ‘/user/hive/warehouse/1.txt’ (overwrite)into table student;
- 查询导入: create table student1 as select * from student;(也可以具体查询某项数据)
- 查询结果导入:insert (overwrite)into table staff select * from track_log;
5. Hive导出数据有几种方式?如何导出数据
- 用insert overwrite导出方式
- 导出到本地:
- insert overwrite local directory ‘/home/robot/1/2’ rom format delimited fields terminated by ‘\t’ select * from staff;(递归创建目录)
- 导出到HDFS
- insert overwrite directory ‘/user/hive/1/2’ rom format delimited fields terminated by ‘\t’ select * from staff;
- Bash shell覆盖追加导出
- 例如:$ bin/hive -e “select * from staff;” > /home/z/backup.log
- Sqoop把hive数据导出到外部
6. hive 内部表和外部表区别
- 创建表时:创建内部表时,会将数据移动到数据仓库指向的路径;若创建外部表,仅记录数据所在的路径, 不对数据的位置做任何改变。
- 删除表时:在删除表的时候,内部表的元数据和数据会被一起删除, 而外部表只删除元数据,不删除数据。这样外部表相对来说更加安全些,数据组织也更加灵活,方便共享源数据。
7. 分区和分桶的区别
分区
- 是指按照数据表的某列或某些列分为多个区,区从形式上可以理解为文件夹,比如我们要收集某个大型网站的日志数据,一个网站每天的日志数据存在同一张表上,由于每天会生成大量的日志,导致数据表的内容巨大,在查询时进行全表扫描耗费的资源非常多。
- 那其实这个情况下,我们可以按照日期对数据表进行分区,不同日期的数据存放在不同的分区,在查询时只要指定分区字段的值就可以直接从该分区查找。
分桶
- 分桶是相对分区进行更细粒度的划分。
- 分桶将整个数据内容安装某列属性值得hash值进行区分,如要按照name属性分为3个桶,就是对name属性值的hash值对3取摸,按照取模结果对数据分桶。
- 如取模结果为0的数据记录存放到一个文件,取模为1的数据存放到一个文件,取模为2的数据存放到一个文件。
8. Hive优化
通用设置
- hive.optimize.cp=true:列裁剪
- hive.optimize.prunner:分区裁剪
- hive.limit.optimize.enable=true:优化LIMIT n语句
- hive.limit.row.max.size=1000000:
- hive.limit.optimize.limit.file=10:最大文件数
本地模式(小任务)
- job的输入数据大小必须小于参数:hive.exec.mode.local.auto.inputbytes.max(默认128MB)
- job的map数必须小于参数:hive.exec.mode.local.auto.tasks.max(默认4)
- job的reduce数必须为0或者1
- hive.exec.mode.local.auto.inputbytes.max=134217728
- hive.exec.mode.local.auto.tasks.max=4
- hive.exec.mode.local.auto=true
- hive.mapred.local.mem:本地模式启动的JVM内存大小
并发执行
- hive.exec.parallel=true ,默认为false
- hive.exec.parallel.thread.number=8
- Strict Mode:
- hive.mapred.mode=true,严格模式不允许执行以下查询:
- 分区表上没有指定了分区
- 没有limit限制的order by语句
- 笛卡尔积:JOIN时没有ON语句
动态分区
- hive.exec.dynamic.partition.mode=strict:该模式下必须指定一个静态分区
- hive.exec.max.dynamic.partitions=1000
- hive.exec.max.dynamic.partitions.pernode=100:在每一个mapper/reducer节点允许创建的最大分区数
- DATANODE:dfs.datanode.max.xceivers=8192:允许DATANODE打开多少个文件
推测执行
- mapred.map.tasks.speculative.execution=true
- mapred.reduce.tasks.speculative.execution=true
- hive.mapred.reduce.tasks.speculative.execution=true;
多个group by合并
- hive.multigroupby.singlemar=true:当多个GROUP BY语句有相同的分组列,则会优化为一个MR任务
虚拟列
- hive.exec.rowoffset:是否提供虚拟列
分组
- 两个聚集函数不能有不同的DISTINCT列,以下表达式是错误的:INSERT OVERWRITE TABLE pv_gender_agg SELECT pv_users.gender, count(DISTINCT pv_users.userid), count(DISTINCT pv_users.ip) FROM pv_users GROUP BY pv_users.gender;
- SELECT语句中只能有GROUP BY的列或者聚集函数。
Combiner聚合
- hive.map.aggr=true;在map中会做部分聚集操作,效率更高但需要更多的内存。
- hive.groupby.mapaggr.checkinterval:在Map端进行聚合操作的条目数目
数据倾斜
- hive.groupby.skewindata=true:数据倾斜时负载均衡,当选项设定为true,生成的查询计划会有两个MRJob。
- 第一个MRJob 中,Map的输出结果集合会随机分布到Reduce中,每个Reduce做部分聚合操作,并输出结果,这样处理的结果是相同的GroupBy Key
- 有可能被分发到不同的Reduce中,从而达到负载均衡的目的;
- 第二个MRJob再根据预处理的数据结果按照GroupBy Key分布到Reduce中(这个过程可以保证相同的GroupBy Key被分布到同一个Reduce中),最后完成最终的聚合操作。
排序
- ORDER BY colName ASC/DESC
- hive.mapred.mode=strict时需要跟limit子句
- hive.mapred.mode=nonstrict时使用单个reduce完成排序
- SORT BY colName ASC/DESC :每个reduce内排序
- DISTRIBUTE BY(子查询情况下使用 ):控制特定行应该到哪个reducer,并不保证reduce内数据的顺序
- CLUSTER BY :当SORT BY 、DISTRIBUTE BY使用相同的列时。
合并小文件
- hive.merg.mapfiles=true:合并map输出
- hive.merge.mapredfiles=false:合并reduce输出
- hive.merge.size.per.task=256*1000*1000:合并文件的大小
- hive.mergejob.maponly=true:如果支持CombineHiveInputFormat则生成只有Map的任务执行merge
- hive.merge.smallfiles.avgsize=16000000:文件的平均大小小于该值时,会启动一个MR任务执行merge。
自定义map/reduce数目
- 减少map数目:
- set mapred.max.split.size
- set mapred.min.split.size
- set mapred.min.split.size.per.node
- set mapred.min.split.size.per.rack
- set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat
2. 增加map数目:
- 当input的文件都很大,任务逻辑复杂,map执行非常慢的时候,可以考虑增加Map数,来使得每个map处理的数据量减少,从而提高任务的执行效率。
- 假设有这样一个任务:select data_desc, count(1), count(distinct id),sum(case when …),sum(case when ...),sum(…) from a group by data_desc
如果表a只有一个文件,大小为120M,但包含几千万的记录,如果用1个map去完成这个任务,肯定是比较耗时的,这种情况下,我们要考虑将这一个文件 合理的拆分成多个,这样就可以用多个map任务去完成。
set mapred.reduce.tasks=10;
create table a_1 as select * from a distribute by rand(123);
3.这样会将a表的记录,随机的分散到包含10个文件的a_1表中,再用a_1代替上面sql中的a表,则会用10个map任务去完成。每个map任务处理大于12M(几百 万记录)的数据,效率肯定会好很多。
3.reduce数目设置:
- 参数1:hive.exec.reducers.bytes.per.reducer=1G:每个reduce任务处理的数据量
- 参数2:hive.exec.reducers.max=999(0.95*TaskTracker数):每个任务最大的reduce数目
- reducer数=min(参数2,总输入数据量/参数1)
- set mapred.reduce.tasks:每个任务默认的reduce数目。典型为0.99*reduce槽数,hive将其设置为-1,自动确定reduce数目。
使用索引:
- hive.optimize.index.filter:自动使用索引
- hive.optimize.index.groupby:使用聚合索引优化GROUP BY操作
原文链接:https://blog.csdn.net/wxfghy/article/details/81361400
来源:oschina
链接:https://my.oschina.net/u/4101357/blog/3229802