大数据学习11之Hive优化篇

大数据学习11之Hive优化篇

引用

CSDN

1.

https://m.blog.csdn.net/qq_64407249/article/details/143630231

在大数据处理领域，Apache Hive是一个基于Hadoop的数据仓库工具，用于查询和管理大规模数据集。随着数据量的不断增长，如何优化Hive的性能成为了一个重要的课题。本文将从压缩、存储方式、SQL优化等多个维度，深入探讨Hive的优化策略，帮助读者更好地理解和应用Hive。

1. Hive压缩

1.1 概述

在大数据环境下，虽然机器性能不断提升，节点数量不断增加，但我们仍然需要对数据进行压缩处理。压缩处理能有效减少存储系统的字节读取数，提高网络带宽和磁盘空间的效率。

Hive相当于Hadoop的客户端，Hive和Hadoop都可以进行压缩操作。Hive压缩主要体现在数据文件的最终存储格式是否启用压缩。压缩使用得当会提高性能，运用不当也会降低性能。

1.2 条件

• 优点：压缩减少系统读取字节数，提高网络宽带和磁盘空间效率。
• 缺点：使用文件时需要解压，加重CPU负载，算法复杂度决定解压时间。
• 适用条件：空间和CPU资源充裕。

压缩技术分为有损压缩（LOSSY COMPRESSION）和无损压缩（LOSSLESS COMPRESSION）。有损压缩适用于视频数据，无损压缩适用于日志数据。此外，压缩技术还可以分为对称和非对称压缩。

1.3 基本原则

• 计算密集型作业少用压缩，因为计算密集需要大量CPU资源，解压需要CPU资源，加重CPU负载。
• IO密集型作业多用压缩，因为CPU消耗少，IO操作多。

重点记住常用的压缩算法：Gzip，Bzip2，Snappy，Zstd。

2. Hive存储

2.1 存储方式

• OLTP（联机事务处理）：传统关系型数据库的主要应用，计算与存储分开，实时性好，但并发性低，连表代价大，一般使用行式存储。
• OLAP（联机分析处理）：分布式数据库的主要应用，将事务数据库数据复制到数据仓库，然后对数据进行查询和分析，帮助决策，实时性要求不高，使用列式存储。

2.2 行式存储与列式存储

• 行式存储：查询时返回表的一行，方便插入、更新操作，数量小时性能良好；但查询指定列数据时可能会返回大量无用数据，数据量较大时效率急剧降低，空间利用率不高。
• 列式存储：查询时返回表的一列，同一列中的数据属于同一类型，压缩算法自由，压缩效果显著，压缩比高，查询指定列时不会出现大量无用数据；但插入、更新操作不方便，不小量数据。

2.3 存储格式

• Text File：默认格式，存储方式为行存储，数据不做压缩，磁盘开销大，数据解析开销大。仅在需要从 Hadoop 中直接提取数据，或直接从文件中加载大量数据的情况下，才建议使用纯文本格式或 CSV。
• Sequence File：支持二进制格式存储，存储方式为行存储，具有使用方便、可分割、可压缩的特点。支持三种压缩选择：NONE，RECORD，BLOCK。Record 压缩率低，一般建议使用 BLOCK 压缩。
• Map File：排序后的 Sequence File，由 data 和 index 两部分组成，Sequence File 的优缺点就是 Map File 的优缺点。
• Avro File：与语言无关的数据序列化系统，以 JSON 格式存储 Schema ，数据本身以二进制格式存储，序列化和反序列化速度很快。但行式存储效率较低。
• RC File：基于MR，结合行列存储优势，保证同一行数据位于同一节点；元组重构成本低，可跳过不必要的列读取。
• ORC File：Apache ORC（Optimized Row Columnar，优化行列）是 Apache Hadoop 生态系统面向列的开源数据存储格式，提供了一种非常有效的方式来存储关系数据，存储 RC 文件。ORC 将原始数据的大小最多减少 75％，数据处理的速度大大提高。
• Parquet File：另一种列式存储的结构，由 Twitter + Cloudera 开源，被 Hive、SparkDrill、Impala、Pig 等支持，目前已成为 Apache 的顶级项目。和 ORC File 一样，Parquet 也是基于列的二进制存储格式，可以存储嵌套的数据结构。

3. Hive优化

3.1 EXPLAIN 执行计划

通过查看explain执行计划可用了解到SQL语句的执行过程是怎样的，进而对SQL语句进行优化。

3.2 SQL优化

3.2.1 RBO优化

Rule-Based Optimization，简称 RBO：基于规则优化的优化器，是一种经验式、启发式的优化思路，优化规则都已经预先定义好了，只需要将 SQL 往这些规则上套即可。简单的说，RBO 就像是一个经验丰富的老司机，基本优化套路全都知道。例如谓词下推、列裁剪、常量折叠等。

• 谓词下推：将过滤表达式尽可能移动至靠近数据源的位置，以使真正执行时能直接跳过无关的数据。在文件格式使用 Parquet 或 ORC 时，甚至可能整块跳过不相关的文件。
• 列裁剪（投影下推）：表示扫描数据源的时候，只读取那些与查询相关的字段。
• 常量折叠：将一些常量计算提前完成，减少运行时的计算量。

3.2.2 CBO 优化

CBO（Cost-Based Optimization）意为基于代价优化的策略，它需要计算所有可能执行计划的代价，并挑选出代价最小的执行计划。RBO 就像一个老司机，基本优化套路全都知道。然而世界上有一种东西叫做——不按套路出牌。

3.2.3 JOIN优化

• Map Join：就是在 Map 阶段进行表之间的连接。而不需要进入到 Reduce 阶段才进行连接。这样就节省了在 Shuffle 阶段时要进行的大量数据传输。从而起到了优化作业的作用。实现原理：Map Join 会把小表全部读入内存中，在 Map 阶段直接拿另外一个表的数据和内存中的表数据做匹配，由于在 Map 阶段进行了 JOIN 操作，底层不需要经过 Shuffle，这样就不会由于数据倾斜导致某个 Reduce 上落数据太多而失败，但是需要占用内存空间存放小表数据。
• Reduce Join（Shuffle Join）：Map 端的主要工作：为来自不同表或文件的数据，进行打标签以区别不同来源的记录。然后用 JOIN 字段作为 Key，其余部分数据和新加的标志作为 Value，最后进行输出。Reduce 端的主要工作：在 Reduce 端以 JOIN 字段作为 Key 完成分组，接下来只需要在每一个分组中，将那些来源于不同 Map 端的文件的记录进行合并即可。
• Bucket Map Join：大表对小表应该使用 Map Join 来进行优化，但是如果是大表（相较于 Reduce Join 大表的数据更大）对大表（相较于 Reduce Join 大表的数据更大），如果进行 Shuffle，那就非常怕，第一个慢不用说，第二个容易出异常。此时就可以使用 Bucket Join 来进行优化，而 Bucket Join 又分为：Bucket Map Join、Sort Merge Bucket Join（SMB Join）。
• SMB Join：SMB Join 是基于 Bucket Map Join 的有序 Bucket，可实现在 Map 端完成 JOIN 操作，只要桶内的下一条不是，就不用再比较了，有效地减少或避免 Shuffle 的数据量。SMB Join 的条件和 Map Join 类似但又不同：所有要 JOIN 的表必须分桶，如果表不是 Bucket 的，则只是做普通 JOIN；大表的 Bucket 数 = 大表的 Bucket 数；Bucket 列 == JOIN 列 == SORT 列；必须是应用在 Bucket Map Join 的场景中。

3.3 数据倾斜

3.3.1 定义

数据倾斜，即单个节点任务所处理的数据量远大于同类型任务所处理的数据量，导致该节点成为整个作业的瓶颈，这是分布式系统不可能避免的问题。MapReduce 模型中，数据倾斜问题是很常见的，因为同一个 Key 的 Values，在进GroupByKey、CountByKey、ReduceByKey、Join 等操作时一定是分配到某一个节点上的一个 Task 中进行处理的，如果某个 Key 对应的数据量特别大的话，就会造成某个节点的堵塞甚至宕机的情况。在并行计算的作业中，整个作业的进度是由运行时间最长的那个 Task 决定的，在出现数据倾斜时，整个作业的运行将会非常缓慢，甚至会发生 OOM 异常。

3.3.2 原因

• 读取的大文件不可分割；
• 任务需要处理大量相同的键；

3.3.3 解决

• 压缩引发的数据倾斜：采用支持文件分割的压缩算法；
• 单表聚合数据倾斜优化：加盐去盐操作；
• JOIN数据倾斜优化：
• Map Join：在map阶段进行表的连接操作；map阶段将小表读入内存，顺序扫描大表完成join
• 适用于小表join大表，小表足够小
• 解决方案：在小表 JOIN 大表时如果产生数据倾斜，那么 Map JOIN 可以直接规避掉 Shuffle 阶段（默认开启）。
• 大小表 Join：采样倾斜key 并拆分join
• 适用于join时出现数据倾斜
• 将存在倾斜的表，根据抽样结果，拆分为倾斜 Key（Skew 表） 和没有倾斜 Key（Normal 表）的两个数据集。
• 将 Skew 表的 Key 全部加上随机前缀，然后对另外一个不存在严重数据倾斜的数据集整体与随机前缀集做笛卡尔乘积（即将数据量扩大 N 倍，得到 New 表）。
• 打散的 Skew 表 JOIN 扩容的 New 表，普通表 JOIN 未扩容的 Old 表，最后将这两部分结果 UNION ALL。
• 业务无关数据引发的数据倾斜：实际业务中有些大量的 NULL 值（空 Key）或者一些无意义的数据参与到计算作业中，这些数据可能来自业务为了上报或因数据规范将某类数据进行归一化变成空值或空字符等形式，这些与业务无关的数据导致在进行分组聚合或者在执行表连接时发生数据倾斜。对于这类问题引发的数据倾斜，在计算过程中排除含有这类“异常”数据即可。

3.4 聚合优化

3.4.1 GROUP BY

例如在 student 表中，假设 age 有数据倾斜，可以通过开启 hive.groupby.skewindata 将作业拆解成两个作业，第一个作业会尽可能将 Map 的数据平均分发到不同的 Reduce，每个 Reduce 实现预聚合，这样的处理结果是相同的 Key 会被分发到不同的 Reduce 中，从而达到负载均衡的目的；第二个作业在第一个作业处理的数据基础上，按 Key 分发到 Reduce中，这个过程可以保证相同的 Key 会被分发到同一个 Reduce，完成最终聚合。

3.4.2 ORDER BY

早排序，避免全局排序；

3.4.3 COUNT(DISTINCT)

3.5 资源优化

3.5.1 向量化查询

多核并发执行操作；

3.5.2 存储优化

HDFS小文件合并

3.5.3 YARN 优化

配置每个容器请求被分配的最小内存。如果容器请求的资源小于该值，会以 1024MB 进行分配；如果 NodeManager 可被分配的内存小于该值，则该 NodeManager 将会被 ResouceManager 给关闭。默认值 1024MB。

3.5.4 并行执行

Hive 在实现 HQL 计算运行时，会解析为多个 Stage，有时候 Stage 彼此之间有依赖关系，只能挨个执行。但有些时候，很多 Stage 之间是没有依赖关系的，例如 UNION 语句，JOIN 语句等等，这些 Stage 没有依赖关系，但是 Hive 依旧会挨个执行每个 Stage，这样会导致性能非常的差。我们可以通过修改参数，开启并行执行，当多个 Stage 之间没有依赖关系时，允许多个 Stage 并行执行，提高性能。

需要注意的是，在共享集群中，如果 Job 中并行阶段增多，那么集群利用率就会增加。系统资源比较空闲的时候才会有优势，如果系统资源比较吃紧，没资源意味着并行也无法启动。

3.5.5 JVM 重用

当一个 Task 运行结束以后，JVM 不会进行释放，而是继续供下一个 Task 运行，直到运行了 N 个 Task 以后，就会释放。

3.6 Job优化

3.6.1 Map 优化

减少或增加MapTask数量，即改变块（不是HDFS的块）的大小，增大 改minSize参数 减小 改maxSize参数

3.6.2 Reduce 优化

3.6.3 Shuffle 优化

目的：压缩中间数据，从而减少磁盘操作以及减少网络传输数据量。参考Hive压缩/存储

3.7 其它优化

3.7.1 Fetch 模式

当我们执行一个简单的 HQL 语句时，例如 SELECT * FROM emp; ，发现数据可以很快的返回，这其实涉及到 Fetch抓取的概念。相关配置为：该配置默认值为 more ，如果设置为 none ，那么每次执行 HQL 都会执行 MapReduce 程序。

3.7.2 多重模式

3.7.3 关联优化

当一个程序中有一些操作彼此之间有关联性的时候，是可以在一个 MapReduce 中完成的，但是 Hive 会不智能的选择使用两个 MapReduce 来完成这两个操作。

3.7.4 本地模式

3.7.5 严格模式

分区表不允许全局查询了；

3.7.6 推测执行

老师叫班长去办公室拿作业，但班长去了十分钟还没回来，所以老师决定再派副班长去拿。推测执行(Speculative Execution)是指在集群环境下运行 MapReduce，可能是程序 Bug，负载不均或者其他的一些问题，导致在一个 Job 下的多个 Task 速度不一致，比如有的任务已经完成，但是有些任务可能只跑了 10%，根据木桶原理，这些任务将成为整个 Job 的短板，如果集群启动了推测执行，这时为了最大限度的提高短板，Hadoop 会为该 Task 启动备份任务，让 Speculative Task 与原始 Task 同时处理一份数据，哪个先运行完，则将谁的结果作为最终结果，并且在运行完成后 Kill 掉另外一个任务。