瓜瓜头条

Hive 在工作中的调优总结

2023-02-13 14:19 由 fx67ll 发表于 #数据库

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

一、EXPLAIN 查看执行计划

二、建表优化

2.1 分区

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

2.2 分桶

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

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

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

三、HiveSQL语法优化

3.1 单表查询优化

  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代替（为什么替代扩展一下~）

3.2 多表查询优化

  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. 笛卡尔积，在生产环境中严禁使用

3.3 其他查询优化

  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慢

四、数据倾斜

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

4.1 单表携带了 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;

4.2 两表或多表的 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

4.3 两表或多表的 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;

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

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

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

4.5 单独处理倾斜key

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

五、Hive Job 优化

5.1 Hive Map 优化

5.1.1 Map数量多少的影响

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

5.1.2 控制Map数的原则

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

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

5.1.3 复杂文件适当增加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;

5.1.4 小文件进行合并减少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;

5.1.5 Map端预聚合减少Map数量

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

5.1.6 推测执行

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

5.1.7 合理控制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（几百万记录）的数据，效率肯定会好很多

5.2 Hive Reduce 优化

5.2.1 Reduce数量多少的影响

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

5.2.2 控制Reduce数的原则

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

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

5.2.3 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

5.2.4 如何调整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

5.2.5 推测执行

参考map优化的最后一项

5.2.6 什么情况下只有一个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. 有笛卡尔积，生产环境必须严格避免

5.3 Hive 任务整体优化

5.3.1 Fetch抓取

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

5.3.2 本地模式

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，才会真正用本地模式执行

5.3.3 并行执行

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

5.3.4 严格模式

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

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

5.3.5 JVM重用

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

5.3.6 启用压缩

压缩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即可

5.3.7 采用合适的存储格式

  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的小文件

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

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

6.2 小文件有什么样的危害？

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

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

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

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

6.3.2 对于已有的小文件

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

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

热门相关：地球第一剑   刺客之王   网游之逆天飞扬   薄先生，情不由己   刺客之王