共计 1763 个字符,预计需要花费 5 分钟才能阅读完成。
自定义函数
- hive 内置函数不满足业务能够应用 java 写自定义函数导入 hive
-
UDF 函数:大部分都是,
- 一进一出
-
UDAF
-
多进一出
- 如:聚合函数
-
-
UDTF
-
一进多出
- 如:explode
-
hive 调优
压缩
- 压缩计划罕用的 gzip,bzip2,lzo,snappy,思考的不仅是压缩后体积,而应该再联合解压和压缩的速度
-
设置不同阶段的输入
- 输出 map,
- map 输入到 reduce 时,
- reduce 输入时能够压缩
-
配置压缩参数能够到 mapred-site.xml,core-site.xml 中
- io.compression.codecs
- mapreduce.map.output.compress
- mapreduce.output
存储格局
- textFile 行,sequenceFile 行,orc 列,parquet 列是
-
罕用 textFile,orc
- 只有 textFile 反对 load 加载
-
行式存储,列式存储
-
空间,查问速度
- 行存储在查找时只须要找到其中一个值其余的数据在相邻地位
-
列存储能够有针对性的查找,而舍弃一些无关数据查找的损耗
- 压缩显著
- 缩小不必要的 io 开销
- 数据空间小,读盘更快
- 自在的压缩算法,更灵便
-
其余优化
- fetch 本地抓去,能不走 mr 尽量不走
- 能本地 mr 尽量本地 mr
hive join 优化
- 编写 sql 时:1.x 之前小表在 join 后面。之后都一样
-
小表和大表 join
- hdfs 提供 distribute block cache 分布式块缓存
- 主动开启 mapjoin
- 配置大小表阈值
-
中大型表 join 大表
- 先过滤(看是否能够转为小表)再 join
- bucket join: 分桶的 mapjoin 计划
-
大表和大表
- 先过滤再 join,缩小 map 到 reduce 数据传输量
-
如果大表中的数据有很多空值,须要解决,因为空值会导致 reduce 容易呈现数据歪斜
- 计划一:提前过滤 null
- 计划二:随机数替换 null
- SMB JOIN:分桶表排序 MAPJOIN 计划
sql 优化
- 列裁剪
-
分区裁剪
- 操作分区表,倡议携带上分区字段,从而缩小扫描量,晋升效率,同时如果表能过滤,就先过滤再 join
- combiner 解决数据歪斜
- 两次 mr,将数据不管男女平均分发给两个 reduce
- 防止 count(distinct),对整个表进行聚合操作翻译后只有一个 reduce,若此时执行一个 distinct(reduce 中执行),而去重操作必须在 reduce 端才能够,数据量大的话,reduce 端会接受大量数据,导致执行效率变慢
select count(ip) from (select ip from table group by ip) tmp;
执行两个 mr 前面那个可用于去重,先 group by 再 count 尽管会多一个 job 然而在数据量大的状况下会更优
- 笛卡尔积:hive 中多表 join 不给 on(一边关联,一边过滤),不能用 where(先笛卡尔再条件过滤)
动静分区
- sql 查问原始表中,必须要将分区字段搁置在整个表后果最初面
- 敞开 hive 严格语法模式
insert into table 分区表 2 partition(month) select * from 分区表 1;
动静歪斜
-
如何调整 map 数量和 reduce 数量
-
放大 map 数:
- map 之前合并文件
- 调大文件切片
- 增大 map 数:
–
- combiner
-
默认 hive 会主动调整 reduce 数量
- hive.exec.reducers.max 默认 999
- hive.exec.reducers.bytes.per.reducer 调小 reducer 增多
- order by 只有一个 reduce, 没有 group by 的聚合只有一个 reduce, 笛卡尔积也只有一个 (关联的时候用了 where)
-
并行执行
- 执行 hive sql 时可能会被翻译为多个 mr,并且多个 mr 之间没有任何关联,那么此时能够运行多个 mr 并行执行晋升效率
- set hive.exec.parallel=true; — 关上工作并行执行执行
- set hive.exec.parallel.thread.number = 16; — 最大并行读,默认为 8
select * from A
union all
select * from B;
严格模式(数据量大的状况下):限度(执行效率差的)sql 的申请
- 分区表查问,不携带分区字段
- 应用 order by 不必 limit
- sql 中呈现笛卡尔
内置的 jvm 重用
- 让 mr 可重复使用资源容器
揣测执行
- 关掉,否则失败反复申请资源做雷同的工作,依然有大概率失败
正文完