正文 

当前位置： 首页 > 代码 > java教程

hive在工作中的调优总结(代码片段)

fx67ll fx67ll     2023-03-03     767

关键词：

总结了一下在以往工作中，对于Hive SQL调优的一些实际应用，是日常积累的一些优化技巧，如有出入，欢迎在评论区留言探讨~

EXPLAIN 查看执行计划

建表优化

分区

  1. 分区表基本操作，partitioned
  2. 二级分区
  3. 动态分区

分桶

  1. 分桶表基本操作，clustered
  2. 分桶表主要是抽样查询，找出具有代表性的结果

选择合适的文件格式和压缩格式

  1. LZO，拉兹罗
  2. Snappy
  3. 压缩速度快，压缩比高

HiveSQL语法优化

单表查询优化

  1. 列裁剪和分区裁剪，全表和全列扫描效率都很差，生产环境绝对不要使用SELECT *，所谓列裁剪就是在查询时只读取需要的列，分区裁剪就是只读取需要的分区

    • 与列裁剪优化相关的配置项是hive.optimize.cp，默认是true
    • 与分区裁剪优化相关的则是hive.optimize.pruner，默认是true
    • 在HiveSQL解析阶段对应的则是ColumnPruner逻辑优化器

  2. Group By 配置调整，map阶段会把同一个key发给一个reduce，当一个key过大时就倾斜了，可以开启map端预聚合，可以有效减少shuffle数据量并

    # 是否在map端聚合，默认为true
set hive.map.aggr = true;

# 在map端聚合的条数
set hive.groupby.mapaggr.checkintervel = 100000;

# 在数据倾斜的时候进行均衡负载（默认是false），开启后会有 两个`mr任务`。
# 当选项设定为true时，第一个 `mr任务` 会将map输出的结果随机分配到`reduce`，
# 每个`reduce`会随机分布到`reduce`上，这样的处理结果是会使相同的`group by key`分到不同的`reduce`上。
# 第二个 `mr任务` 再根据预处理的结果按`group by key`分到`reduce`上，
# 保证相同`group by key`的数据分到同一个`reduce`上。

# *切记！！！* 
# 这样能解决数据倾斜，但是不能让运行速度更快  
# 在数据量小的时候，开始数据倾斜负载均衡可能反而会导致时间变长  
# 配置项毕竟是死的，单纯靠它有时不能根本上解决问题
# 因此还是建议自行了解数据倾斜的细节，并优化查询语句  
set hive.groupby.skewindata = true;

  3. Vectorization，矢量计算技术，通过设置批处理的增量大小为1024行单次来达到比单行单次更好的效率

    # 开启矢量计算  
set hive.vectorized.execution.enabled = true;

# 在reduce阶段开始矢量计算  
set hive.vectorized.execution.reduce.enabled = true;

  4. 多重模式，一次读取多次插入，同一张表的插入操作优化成先from table再insert

  5. in/exists或者join用left semi join代替（为什么替代扩展一下~）

多表查询优化

  1. CBO优化，成本优化器，代价最小的执行计划就是最好的执行计划

    • join的时候表的顺序关系，前面的表都会被加载到内存中，后面的表进行磁盘扫描
    • 通过hive.cbo.enable，自动优化hivesql中多个join的执行顺序
    • 可以通过查询一下参数，这些一般都是true，无需修改
    set hive.cbo.enable = true;
set hive.compute.query.using.stats = true;
set hive.stats.fetch.column.stats = true;
set hive.stats.fetch.partition.stats = true;

  2. 谓词下推（非常关键的一个优化），将sql语句中的where谓词逻辑都尽可能提前执行，减少下游处理的数据量，
    在关系型数据库如MySQL中，也有谓词下推（Predicate Pushdown，PPD）的概念，
    它就是将sql语句中的where谓词逻辑都尽可能提前执行，减少下游处理的数据量

    # 这个设置是默认开启的 
# 如果关闭了但是cbo开启，那么关闭依然不会生效 
# 因为cbo会自动使用更为高级的优化计划  
# 与它对应的逻辑优化器是PredicatePushDown
# 该优化器就是将OperatorTree中的FilterOperator向上提
set hive.optimize.pdd = true;

# 举个例子
# 对forum_topic做过滤的where语句写在子查询内部，而不是外部
select a.uid,a.event_type,b.topic_id,b.title
from calendar_record_log a
left outer join (
  select uid,topic_id,title from forum_topic
  where pt_date = 20220108 and length(content) >= 100
) b on a.uid = b.uid
where a.pt_date = 20220108 and status = 0;

  3. Map Join，map join是指将join操作两方中比较小的表直接分发到各个map进程的内存中，在map中进行join的操作。
    map join特别适合大小表join的情况，Hive会将build table和probe table在map端直接完成join过程，消灭了reduce，减少shuffle，所以会减少开销

    • set hive.auto.convert.join = true，配置开启，默认是true
    • 注意！！！ 如果执行小表join大表，小表作为主连接的主表，所有数据都要写出去，此时会走reduce阶段，mapjoin会失效
    • 大表join小表不受影响，上一条的原因主要是因为小表join大表的时候，map阶段不知道reduce的结果其他reduce是否有，
    • 所以必须在最后reduce聚合的时候再处理，就产生了reduce的开销
    # 举个例子
# 在最常见的`hash join`方法中，一般总有一张相对小的表和一张相对大的表，
# 小表叫`build table`，大表叫`probe table`  
# Hive在解析带join的SQL语句时，会默认将最后一个表作为`probe table`，
# 将前面的表作为`build table`并试图将它们读进内存  
# 如果表顺序写反，`probe table`在前面，引发`OOM（内存不足）`的风险就高了  
# 在维度建模数据仓库中，事实表就是`probe table`，维度表就是`build table`  
# 假设现在要将日历记录事实表和记录项编码维度表来`join`  
select a.event_type,a.event_code,a.event_desc,b.upload_time
from calendar_event_code a
inner join (
  select event_type,upload_time from calendar_record_log
  where pt_date = 20220108
) b on a.event_type = b.event_type;

  4. Map Join，大表和大表的MapReduce任务，可以使用SMB Join

    • 直接join耗时会很长，但是根据某字段分桶后，两个大表每一个桶就是一个小文件，两个表的每个小文件的分桶字段都应该能够一一对应（hash值取模的结果）
    • 总结就是分而治之，注意两个大表的分桶字段和数量都应该保持一致
    set hive.optimize.bucketmapjoin = true;
set hive.optimeize.bucketmapjoin.sortedmerge = true;
hive.input.format = org.apache.hadoop.hive.ql.io.BucketizedHiveInputFormat;

  5. 多表join时key相同，这种情况会将多个join合并为一个mr 任务来处理

    # 举个例子
# 如果下面两个join的条件不相同  
# 比如改成a.event_code = c.event_code  
# 就会拆成两个MR job计算
select a.event_type,a.event_code,a.event_desc,b.upload_time
from calendar_event_code a
inner join (
  select event_type,upload_time from calendar_record_log
  where pt_date = 20220108
) b on a.event_type = b.event_type
inner join (
  select event_type,upload_time from calendar_record_log_2
  where pt_date = 20220108
) c on a.event_type = c.event_type;

  6. 笛卡尔积，在生产环境中严禁使用

其他查询优化

  1. Sort By 代替 Order By，HiveQL中的order by与其他sql方言中的功能一样，就是将结果按某字段全局排序，这会导致所有map端数据都进入一个reducer中，
    在数据量大时可能会长时间计算不完。如果使用sort by，那么还是会视情况启动多个reducer进行排序，并且保证每个reducer内局部有序。
    为了控制map端数据分配到reducer的key，往往还要配合distribute by一同使用，如果不加distribute by的话，map端数据就会随机分配到reducer

    # 举个例子
select uid,upload_time,event_type,record_data
from calendar_record_log
where pt_date >= 20220108 and pt_date <= 20220131
distribute by uid
sort by upload_time desc,event_type desc;

  2. Group By代替Distinct，当要统计某一列的去重数时，如果数据量很大，count(distinct)就会非常慢，原因与order by类似，
    count(distinct)逻辑只会有很少的reducer来处理。但是这样写会启动两个mr任务（单纯distinct只会启动一个），
    所以要确保数据量大到启动mr任务的overhead远小于计算耗时，才考虑这种方法，当数据集很小或者key的倾斜比较明显时，group by还可能会比distinct慢

数据倾斜

注意要和数据过量的情况区分开，数据倾斜是大部分任务都已经执行完毕，但是某一个任务或者少数几个任务，一直未能完成，甚至执行失败，
而数据过量，是大部分任务都执行的很慢，这种情况需要通过扩充执行资源的方式来加快速度，大数据编程不怕数据量大，就怕数据倾斜，一旦数据倾斜，严重影响效率

单表携带了 Group By 字段的查询

  1. 任务中存在group by操作，同时聚合函数为count或sum，单个key导致的数据倾斜可以这样通过设置开启map端预聚合参数的方式来处理
    # 是否在map端聚合，默认为true
set hive.map.aggr = true;

# 在map端聚合的条数
set hive.groupby.mapaggr.checkintervel = 100000;

# 有数据倾斜的时候开启负载均衡，这样会生成两个mr任务
set hive.groupby.skewindata = true;
  2. 任务中存在group by操作，同时聚合函数为count或sum，多个key导致的数据倾斜可以通过增加reduce的数量来处理
    • 增加分区可以减少不同分区之间的数据量差距，而且增加的分区时候不能是之前分区数量的倍数，不然会导致取模结果相同继续分在相同分区
    • 第一种修改方式
    # 每个reduce处理的数量
set hive.exec.reduce.bytes.per.reducer = 256000000;

# 每个任务最大的reduce数量
set hive.exec.reducers.max = 1009;

# 计算reducer数的公式，根据任务的需要调整每个任务最大的reduce数量  
N = min（设置的最大数，总数量数/每个reduce处理的数量）
    • 第二种修改方式
    # 在hadoop的mapred-default.xml文件中修改
set mapreduce.job.reduces = 15;

两表或多表的 join 关联时，其中一个表较小，但是 key 集中

  1. 设置参数增加map数量
    # join的key对应记录条数超过该数量，会进行分拆  
set hive.skewjoin.key = 1000;

# 并设置该参数为true，默认是false
set hive.optimize.skewjoin = true;

# 上面的参数如果开启了会将计算数量超过阈值的key写进临时文件，再启动另外一个任务做map join  
# 可以通过设置这个参数，控制第二个任务的mapper数量，默认10000
set hive.skewjoin.mapjoin.map.tasks = 10000;
  2. 使用mapjoin，减少reduce从根本上解决数据倾斜，参考HiveSQL语法优化 -> 多表查询优化 -> Map Join，大表和大表的MapReduce任务，SMB Join

两表或多表的 join 关联时，有 Null值 或 无意义值

这种情况很常见，比如当事实表是日志类数据时，往往会有一些项没有记录到，我们视情况会将它置为null，或者空字符串、-1等，
如果缺失的项很多，在做join时这些空值就会非常集中，拖累进度，因此，若不需要空值数据，就提前写where语句过滤掉，
需要保留的话，将空值key用随机方式打散，例如将用户ID为null的记录随机改为负值：

select a.uid,a.event_type,b.nickname,b.age
from (
  select 
  (case when uid is null then cast(rand()*-10240 as int) else uid end) as uid,
  event_type from calendar_record_log
  where pt_date >= 20220108
) a left outer join (
  select uid,nickname,age from user_info where status = 4
) b on a.uid = b.uid;

两表或多表的 join 关联时，数据类型不统一

比如int类型和string类型进行关联，关联时候以小类型作为分区，这里int、string会到一个reduceTask中，如果数据量多，会造成数据倾斜

# 可以通过转换为同一的类型来处理
cast(user.id as string)

单独处理倾斜key

这其实是上面处理空值方法的拓展，不过倾斜的key变成了有意义的，一般来讲倾斜的key都很少，我们可以将它们抽样出来，
对应的行单独存入临时表中，然后打上一个较小的随机数前缀（比如0~9），最后再进行聚合

Hive Job 优化

Hive Map 优化

Map数量多少的影响

  1. Map数过大
    • map阶段输出文件太小，产生大量小文件
    • 初始化和创建map的开销很大
  2. Map数太小
    • 文件处理或查询并发度小，Job执行时间过长
    • 大量作业时，容易堵塞集群

控制Map数的原则

根据实际情况，控制map数量需要遵循两个原则

  1. 第一是使大数据量利用合适的map数
  2. 第二是使单个map任务处理合适的数据量

复杂文件适当增加Map数

  1. 当input的文件都很大，任务逻辑复杂，map执行非常慢的时候，可以考虑增加map数，来使得每个map处理的数据量减少，从而提高任务的执行效率
  2. 那么如何增加map的数量呢？在map阶段，文件先被切分成split块，而后每一个split切片对应一个Mapper任务，
    FileInputFormat这个类先对输入文件进行逻辑上的划分，以128m为单位，将原始数据从逻辑上分割成若干个split，每个split切片对应一个mapper任务，
    所以说减少切片的大小就可增加map数量
  3. 可以依据公式计算computeSliteSize(Math.max(minSize, Math.min(maxSize, blockSize))) = blockSize = 128m
  4. 执行语句：set mapreduce.input.fileinputformat.split.maxsize = 100;

小文件进行合并减少Map数

为什么要进行小文件合并？因为如果一个任务有很多小文件（远远小于块大小128m），则每个小文件也会被当做一个块，用一个map任务来完成，
而一个map任务启动和初始化的时间远远大于逻辑处理的时间，就会造成很大的资源浪费，同时可执行的map数是受限的
两种方式合并小文件

  1. 在Map执行前合并小文件，减少map数量
    // 每个Map最大输入大小(这个值决定了合并后文件的数量)
set mapred.max.split.size = 256000000;

// 一个节点上split的至少的大小(这个值决定了多个DataNode上的文件是否需要合并)
set mapred.min.split.size.per.node = 100000000;

// 一个交换机下split的至少的大小(这个值决定了多个交换机上的文件是否需要合并)
set mapred.min.split.size.per.rack = 100000000;

// 执行Map前进行小文件合并
set hive.input.format = org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;
  2. 在Map-Reduce任务执行结束时合并小文件，减少小文件输出
    // 设置map端输出进行合并，默认为true
set hive.merge.mapfiles = true;

// 设置reduce端输出进行合并，默认为false
set hive.merge.mapredfiles = true;

// 设置合并文件的大小，默认是256
set hive.merge.size.per.task = 256 * 1000 * 1000;

// 当输出文件的平均大小小于该值时，启动一个独立的`MapReduce任务`进行文件`merge`。
set hive.merge.smallfiles.avgsize = 16000000;

Map端预聚合减少Map数量

  1. 相当于在map端执行combiner，执行命令：set hive.map.aggr = true;
  2. combiners是对map端的数据进行适当的聚合，其好处是减少了从map端到reduce端的数据传输量
  3. 其作用的本质，是将map计算的结果进行二次聚合，使Key-Value<List>中List的数据量变小，从而达到减少数据量的目的

推测执行

  1. 在分布式集群环境下，因为程序Bug（包括Hadoop本身的bug），负载不均衡或者资源分布不均等原因，会造成同一个作业的多个任务之间运行速度不一致，
    有些任务的运行速度可能明显慢于其他任务（比如一个作业的某个任务进度只有50%，而其他所有任务已经运行完毕），则这些任务会拖慢作业的整体执行进度
  2. Hadoop采用了推测执行（Speculative Execution）机制，它根据一定的法则推测出拖后腿的任务，并为这样的任务启动一个备份任务，
    让该任务与原始任务同时处理同一份数据，并最终选用最先成功运行完成任务的计算结果作为最终结果
  3. 执行命令：set mapred.reduce.tasks.speculative.execution = true; # 默认是true
  4. 当然，如果用户对于运行时的偏差非常敏感的话，那么可以将这些功能关闭掉，如果用户因为输入数据量很大而需要执行长时间的map task或者reduce task的话，
    那么启动推测执行造成的浪费是非常巨大的

合理控制Map数量的实际案例

假设一个SQL任务：

SELECT COUNT(1) 
FROM fx67ll_alarm_count_copy
WHERE alarm_date = "2021-01-08";

该任务的输入目录inputdir是：/group/fx67ll_data/fx67ll_data_etl/date/fx67ll_alarm_count_copy/alarm_date=2021-01-08，共有194个文件，
其中很多是远远小于128m的小文件，总大小约9G，正常执行会用194个Map任务，map总共消耗的计算资源：SLOTS_MILLIS_MAPS= 610,023
通过在Map执行前合并小文件，减少Map数

# 前面三个参数确定合并文件块的大小
# 大于文件块大小128m的，按照128m来分隔 
# 小于128m,大于100m的，按照100m来分隔
# 把那些小于100m的（包括小文件和分隔大文件剩下的），进行合并，最终生成了74个块
set mapred.max.split.size=100000000;
set mapred.min.split.size.per.node=100000000;
set mapred.min.split.size.per.rack=100000000;
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFormat;

合并后，用了74个map任务，map消耗的计算资源：SLOTS_MILLIS_MAPS= 323,098，对于这个简单SQL任务，执行时间上可能差不多，但节省了一半的计算资源

再假设这样一个SQL任务：

SELECT data_fx67ll,
COUNT(1),
COUNT(DISTINCT id),
SUM(CASE WHEN …),
SUM(CASE WHEN …),
SUM(…)
FROM fx67ll_device_info_zs
GROUP data_fx67ll

如果表fx67ll_device_info_zs只有一个文件，大小为120m，但包含几千万的记录，如果用1个map去完成这个任务，肯定是比较耗时的，
这种情况下，我们要考虑将这一个文件合理的拆分成多个
增加Reduce数量，来增加Map数量

set mapred.reduce.tasks=10;
CREATE TABLE fx67ll_device_info_zs_temp
AS
SELECT * 
FROM fx67ll_device_info_zs
DISTRIBUTE BY RAND(123);

这样会将fx67ll_device_info_zs表的记录，随机的分散到包含10个文件的fx67ll_device_info_zs_temp表中，
再用fx67ll_device_info_zs_temp代替上面sql中的fx67ll_device_info_zs表，
则会用10个map任务去完成，每个map任务处理大于12m（几百万记录）的数据，效率肯定会好很多

Hive Reduce 优化

Reduce数量多少的影响

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

控制Reduce数的原则

和map一样，控制reduce数量需要遵循两个原则

  1. 第一是使大数据量利用合适的reduce数
  2. 第二是使单个reduce任务处理合适的数据量

Hive自己如何确定Reduce数

reduce个数的设定极大影响任务执行效率，不指定reduce个数的情况下，Hive会猜测确定一个reduce个数，基于以下两个设定：

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

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

计算reducer数的公式很简单N = min(参数2，总输入数据量 / 参数1)
即，如果reduce的输入（map的输出）总大小不超过1G，那么只会有一个reduce任务

举个例子：

SELECT alarm_date,
		COUNT(1) 
FROM fx67ll_alarm_count_copy
WHERE alarm_date = "2021-01-08"
GROUP BY alarm_date;

该任务的输入目录inputdir是：/group/fx67ll_data/fx67ll_data_etl/date/fx67ll_alarm_count_copy/alarm_date=2021-01-08，
总大小为9G多，因此这句有10个reduce

如何调整Reduce数量

注意！！！实际开发中，reduce的个数一般通过程序自动推定，而不人为干涉，因为人为控制的话，如果使用不当很容易造成结果不准确，且降低执行效率

  1. 通过调整每个reduce任务处理的数据量来调整reduce个数，处理的数据量少了，任务数就多了
    # 设置每个reduce任务处理的数据量500M，默认是1G
set hive.exec.reducers.bytes.per.reducer = 500000000;

SELECT alarm_date,
		COUNT(1) 
FROM fx67ll_alarm_count_copy
WHERE alarm_date = "2021-01-08"
GROUP BY alarm_date;

这次有20个reduce
  2. 直接调整每个Job中的最大reduce数量，过于简单粗暴，慎用，尽量不要，虽然设置了reduce的个数看起来好像执行速度变快了，但是实际并不是这样的
    # 设置每个任务最大的reduce数为15个，默认为999
set mapred.reduce.tasks = 15;

SELECT alarm_date,
		COUNT(1) 
FROM fx67ll_alarm_count_copy
WHERE alarm_date = "2021-01-08"
GROUP BY alarm_date;

这次有15个reduce

推测执行

参考map优化的最后一项

什么情况下只有一个Reduce

很多时候你会发现任务中不管数据量多大，不管你有没有设置调整reduce个数的参数，任务中一直都只有一个reduce任务，
其实只有一个reduce任务的情况，除了数据量小于hive.exec.reducers.bytes.per.reducer参数值的情况外，还有以下原因：

  1. 没有Group By的汇总，例如：
    SELECT alarm_date,
		COUNT(1) 
FROM fx67ll_alarm_count_copy
WHERE alarm_date = "2021-01-08"
GROUP BY alarm_date;

写成

SELECT COUNT(1) 
FROM fx67ll_alarm_count_copy
WHERE alarm_date = "2021-01-08";

注意避免这样情况的发生
  2. 用了Order by排序，因为它会对数据进行全局排序，所以数据量特别大的时候效率非常低，尽量避免
  3. 有笛卡尔积，生产环境必须严格避免

Hive 任务整体优化

Fetch抓取

Fetch抓取是指Hive在某些情况的查询可以不必使用mr 任务，例如在执行一个简单的select * from XX时，我们只需要简单的进行抓取对应目录下的数据即可。
在hive-default.xml.template中，hive.fetch.task.conversion（默认是morn），老版本中默认是minimal。
该属性为morn时，在全局查找，字段查找，limit查找等都不走mr 任务

本地模式

Hive也可以不将任务提交到集群进行运算，而是直接在一台节点上处理，因为消除了提交到集群的overhead，所以比较适合数据量很小，且逻辑不复杂的任务。
设置hive.exec.mode.local.auto为true可以开启本地模式，但任务的输入数据总量必须小于hive.exec.mode.local.auto.inputbytes.max（默认值128MB），
且mapper数必须小于hive.exec.mode.local.auto.tasks.max（默认值4），reducer数必须为0或1，才会真正用本地模式执行

并行执行

Hive中互相没有依赖关系的job间是可以并行执行的，最典型的就是多个子查询union all，
在集群资源相对充足的情况下，可以开启并行执行，即将参数hive.exec.parallel设为true，
另外hive.exec.parallel.thread.number可以设定并行执行的线程数，默认为8，一般都够用。
注意！！！没资源无法并行，且数据量小时开启可能还没不开启快，所以建议数据量大时开启

严格模式

要开启严格模式，需要将参数hive.mapred.mode设为strict。
所谓严格模式，就是强制不允许用户执行3种有风险的sql语句，一旦执行会直接失败，这3种语句是：

  1. 查询分区表时不限定分区列的语句
  2. 两表join产生了笛卡尔积的语句
  3. 用order by来排序但没有指定limit的语句

JVM重用

  1. 主要用于处理小文件过多的时候
  2. 在mr 任务中，默认是每执行一个task就启动一个JVM，如果task非常小而碎，那么JVM启动和关闭的耗时就会很长
  3. 可以通过调节参数mapred.job.reuse.jvm.num.tasks来重用
  4. 例如将这个参数设成5，那么就代表同一个mr 任务中顺序执行的5个task可以重复使用一个JVM，减少启动和关闭的开销，但它对不同mr 任务中的task无效

启用压缩

压缩job的中间结果数据和输出数据，可以用少量CPU时间节省很多空间，压缩方式一般选择Snappy，效率最高。
要启用中间压缩，需要设定hive.exec.compress.intermediate为true，
同时指定压缩方式hive.intermediate.compression.codec为org.apache.hadoop.io.compress.SnappyCodec。
另外，参数hive.intermediate.compression.type可以选择对块（BLOCK）还是记录（RECORD）压缩，BLOCK的压缩率比较高。
输出压缩的配置基本相同，打开hive.exec.compress.output即可

采用合适的存储格式

  1. 在Hive SQL的create table语句中，可以使用stored as ...指定表的存储格式。
    Hive表支持的存储格式有TextFile、SequenceFile、RCFile、Avro、ORC、Parquet等。
    存储格式一般需要根据业务进行选择，在我们的实操中，绝大多数表都采用TextFile与Parquet两种存储格式之一。
  2. TextFile是最简单的存储格式，它是纯文本记录，也是Hive的默认格式，虽然它的磁盘开销比较大，查询效率也低，但它更多地是作为跳板来使用。
  3. RCFile、ORC、Parquet等格式的表都不能由文件直接导入数据，必须由TextFile来做中转。
  4. Parquet和ORC都是Apache旗下的开源列式存储格式。列式存储比起传统的行式存储更适合批量OLAP查询，并且也支持更好的压缩和编码。
  5. 我们选择Parquet的原因主要是它支持Impala查询引擎，并且我们对update、delete和事务性操作需求很低。

Hive的小文件

什么情况下会产生小文件?

  1. 动态分区插入数据，产生大量的小文件，从而导致map数量剧增
  2. reduce数量越多，小文件也越多，有多少个reduce，就会有多少个输出文件，如果生成了很多小文件，那这些小文件作为下一次任务的输入
  3. 数据源本身就包含大量的小文件

小文件有什么样的危害？

  1. 从Hive的角度看，小文件会开很多map，一个map开一个java虚拟机jvm去执行，所以这些任务的初始化，启动，执行会浪费大量的资源，严重影响性能
  2. 在hdfs中，每个小文件对象约占150byte，如果小文件过多会占用大量内存，这样NameNode内存容量严重制约了集群的扩展
    • 每个hdfs上的文件，会消耗128字节记录其meta信息，所以大量小文件会占用大量内存

如何避免小文件带来的危害？

从小文件产生的途经就可以从源头上控制小文件数量

  1. 使用Sequencefile作为表存储格式，不要用textfile，在一定程度上可以减少小文件
  2. 减少reduce的数量(可以使用参数进行控制)
  3. 少用动态分区，用时记得按distribute by分区

对于已有的小文件

  1. 使用hadoop archive命令把小文件进行归档，采用archive命令不会减少文件存储大小，只会压缩NameNode的空间使用
  2. 重建表，建表时减少reduce数量

我是 fx67ll.com，如果您发现本文有什么错误，欢迎在评论区讨论指正，感谢您的阅读！
如果您喜欢这篇文章，欢迎访问我的 本文github仓库地址，为我点一颗Star，Thanks~ 😃
转发请注明参考文章地址，非常感谢！！！

hive调优总结2(代码片段)

无需MapReduce在hive-default.xml中hive.fetch.task.conversion默认是more，老版本是minimal，该属性改为more后，在全局查找、字段查找、limit查找等都不走mapreduce。Expectsoneof[none,minimal,more].Someselectqueriescanbeconvert 查看详情

入门」全方位盘点和总结调优技术专题指南(代码片段)

...们系统和全访问掌握应⽤系统调优的思路与方案以及相关的调优工具的使用，虽然未必会覆盖目前的所有的问题场景，但是还是提供了较为丰富的案例和调优理论，会帮助大家打开思维去⽀撑系统服务体系优化能力。... 查看详情

hive调优总结2(代码片段)

无需MapReduce在hive-default.xml中hive.fetch.task.conversion默认是more，老版本是minimal，该属性改为more后，在全局查找、字段查找、limit查找等都不走mapreduce。Expectsoneof[none,minimal,more].SomeselectqueriescanbeconvertedtosingleFETCHtaskminimizingl... 查看详情

hive调优总结2(代码片段)

无需MapReduce在hive-default.xml中hive.fetch.task.conversion默认是more，老版本是minimal，该属性改为more后，在全局查找、字段查找、limit查找等都不走mapreduce。Expectsoneof[none,minimal,more].SomeselectqueriescanbeconvertedtosingleFETCHtaskminimizingl... 查看详情

2021秋招最新java面试题|jvm剖析与常用的调优总结(代码片段)

JAVA基础篇面试题文章目录JAVA基础篇面试题1.什么是GCRoots2.JVM调优和参数配置3.常用的JVM调优参数4.分析GC日志5.四种引用强引用软引用弱引用虚引用6.常见的JVM异常/错误1.什么是GCRootsGCRoots是一组活跃的引用；常用于判断对象是... 查看详情

tomcat调优总结（tomcat自身优化linux内核优化jvm优化）(代码片段)

Tomcat自身的调优是针对conf/server.xml中的几个参数的调优设置。首先是对这几个参数的含义要有深刻而清楚的理解。以tomcat8.5为例，讲解参数。同时也得认识到一点，tomcat调优也受制于linux内核。linux内核对tcp连接也有几个参数可... 查看详情

jvm的调优(代码片段)

　　首先我们要知道jvm的调优，主要是对那些部分的优化。通过jvm内存模型我们可以，首先是分析遇到的问题，然后通过一些工具或者手段找到问题所在，然后通过一定的措施解决问题，下面我们也将按着这个思路来给出具体的... 查看详情

深度学习篇--神经网络中的调优

...型训练速度，准确率方面至关重要，所以本文对神经网络中的调优做一个总结。二、神经网络超参数调优1、适当调整隐藏层数对于许多问题，你可以开始只用一个隐藏层，就可以获得不错的结果，比如对于复杂的问题我们可以... 查看详情

spark记录sparkcore的调优之开发调优(代码片段)

...作业，并不是那么简单的。如果没有对Spark作业进行合理的调优，Spark作业的执行速度可能会很慢，这样就完全体现不出Spark作为一种快速大数据计算引擎的优势来。因此，想要用好Spark，就必须对其进行合理的性能优化。Spark的... 查看详情

自动调优工具aoe，让你的模型在昇腾平台上高效运行(代码片段)

...行环境上验证的闭环反馈机制，不断迭代，最终得到最佳的调优策略，从而更充分利用硬件资源，提升网络的性能。AOE的架构如下。Application层：调优入口，支持如下。AOE：这里的AOE表示AOE进程，是离线推理场景下的调优入口。T... 查看详情

spark学习之路sparkcore的调优之spark内存模型[转](代码片段)

...Task），在各个Executor进程间协调任务的调度，后者负责在工作节点上执行具体的计算任务，并将结果返回给Driver，同时为需要持久化的RDD提供存储功能[1]。由于Driver的内存管理相对来说较为简单，本文主要对Executor的内存管理进... 查看详情

工作常用之hive调优hql语法优化(代码片段)

 HQL语法优化3.1列裁剪与分区裁剪列裁剪就是在查询时只读取需要的列，分区裁剪就是只读取需要的分区。当列很多或者数据量很大时，如果select*或者不指定分区，全列扫描和全表扫描效率都很低。Hive在读数据的时... 查看详情

工作常用之hive调优hql语法优化(代码片段)

 HQL语法优化3.1列裁剪与分区裁剪列裁剪就是在查询时只读取需要的列，分区裁剪就是只读取需要的分区。当列很多或者数据量很大时，如果select*或者不指定分区，全列扫描和全表扫描效率都很低。Hive在读数据的时... 查看详情

工作常用之hive调优hql语法优化(代码片段)

 HQL语法优化3.1列裁剪与分区裁剪列裁剪就是在查询时只读取需要的列，分区裁剪就是只读取需要的分区。当列很多或者数据量很大时，如果select*或者不指定分区，全列扫描和全表扫描效率都很低。Hive在读数据的时... 查看详情

hive中控制文件生产个数(代码片段)

...是某些特殊情况下可能需要进行调优，下面列举两个常用的调优场景看看这两个 查看详情

spark学习之路sparkcore的调优之开发调优[转](代码片段)

...作业，并不是那么简单的。如果没有对Spark作业进行合理的调优，Spark作业的执行速度可能会很慢，这样就完全体现不出Spark作为一种快速大数据计算引擎的优势来。因此，想要用好Spark，就必须对其进行合理的性能优化。Spark的... 查看详情

spark记录sparkcore的调优之spark内存模型(代码片段)

...Task），在各个Executor进程间协调任务的调度，后者负责在工作节点上执行具体的计算任务，并将结果返回给Driver，同时为需要持久化的RDD提供存储功能[1]。由于Driver的内存管理相对来说较为简单，本文主要对Executor的内存管理进... 查看详情

hive调优集锦，让hive调优想法不再碎片化(代码片段)

...质就是一款基于HDFS的MapReduce计算框架，对存储在HDFS中的数据进行分析和管理。1.2架构1．用户接口：ClientCLI（hiveshel 查看详情